This post originated from an RSS feed registered with Ruby Buzz
by Philippe Hanrigou.
Original Post: caller_for_all_threads now in Ruby Enterprise Edition
Feed Title: Latest updates from PH7
Feed URL: http://ph7spot.com/updates/atom
Feed Description: Tips and resources on Ruby, Java, Unix, Object-Oriented Programming, Design Patterns and Agile methodologies.
If you are unfamiliar with caller_for_all_threads, it provides a handy way to gain a comprehensive understanding of the state of your Ruby application when it starts to misbehave. I have found it to be a quick and invaluable troubleshooter of tough Ruby on Rails production problems.
As for Ruby Enterprise Edition, if you haven’t evaluated it yet, you should:
When you use Ruby Enterprise Edition with Phusion Passenger you can save your Rails application memory usage by 33%1, which translates into tangible financial savings. This amazing result stems from tactical tweaks in the Ruby interpreter code 2, which makes it so that a significant portion of the interpreter representation in memory remains unchanged over the course of the application life-cycle. By leveraging the copy-on-write mechanism available on modern operating systems, this invariant memory representation of the Ruby interpreter can then be shared transparently between multiple Ruby processes3.
For 32-bits platforms, this Ruby Enterprise Edition release also includes significant improvement for Ruby memory allocation and garbage collection, which constitute the most overlooked performance problems in Ruby applications today. So progress in these areas is crucial! With Ruby Enteprise Edition memory handling enhancements you can expect something like a 20% speedup out-of-the-box for typical Ruby applications. Even better, since this release also integrates RailsBench GC patches, you can also tweak various garbage collector settings to your liking and go even further!
Finally, you can use Ruby Enterprise Edition in production today without changing a line of code: This is simply good old M.R.I. 1.8.6 bundled with a couple of clever and well-chosen patches that make a world of difference. Even better, it is production-grade: many high-profile and high-traffic websites including the New York Times, MTV, Shopify and 37signals already use Ruby Enteprise Edition today.
In conclusion, I am flattered to have my work incorporated into the core of what constitutes today’s state-of-the-art deployment infrastructure for Ruby web applications (Phusion Passenger + Ruby Enterprise Edition). Hopefully, you will also find my work useful. Please send me your feedback – I’d love to learn about how you use it and your ideas on ways to improve it!
Especially its mark-and-sweep garbage collection implementation, which is the worst offender. It holds the mark/sweep flag inside the nodes themselves, not in a separate list maintained in parallel. This inlined flag triggers quick memory changes in anything but the very core of the Ruby interpreter. As a consequence almost all the pages that a Ruby child process inherits from its parent change quickly, unnecessarily defeating copy-on-write optimizations.
Copy-On-Write is a transparent optimization technique where a memory copy operation defers the actual copy until a change occurs (either in the original or the copy). Until then, a read-only pointer to the original memory page is provided. Eventually, if/when a process attempts to change the original or the copy, a page protection fault occurs, the O.S. intercepts the page fault and end up allocating physical memory for the copy. So, as long as the copied data is only read and not written too, memory is shared, effectively saving time and physical memory. You typically benefit from copy-on-write optimizations in a transparent manner every time you fork a (Ruby) process.
Previous Topic
