Tuning the Garbage Collector with Ruby 1.9.2

• ruby 1.9.2

This is a follow up post to our Ruby 1.9.2 general availability announcement. As mentioned, the 1.9.2 ruby that we have available includes customizable GC extensions. You can see the patch here. We’ve patched our Ruby 1.9.2 version with this, so there isn’t anything you need to do to take advantage of the functionality. Essentially this patch allows us to set three environment variables (meaning nearly the same thing as they do in REE) in order to tune GC behavior.

You should be able to test this patched Ruby locally if you are using the excellent RVM. You can check out and follow this useful guide from Ken Collins.

Without further ado, the environment variables available are:

RUBY_GC_MALLOC_LIMIT

The amount of C data structures which can be allocated without triggering a garbage collection. If this is set too low, the garbage collector will start even if there are empty heap slots available. The default value is 8000000.

RUBY_HEAP_MIN_SLOTS

This specifies the initial number of heap slots. The default value is 10000.

RUBY_FREE_MIN

The number of heap slots that should be available after a garbage collector run. If fewer heap slots are available, then Ruby will allocate a new heap. The default value is 4096.

We also applied another patch allowing you to use class methods on GC in order to query or set those values.

GC.malloc_limit
GC.malloc_limit=(val)
GC.heap_min_slots
GC.heap_min_slots=(val)
GC.free_min
GC.free_min=(val)

Typically, we wouldn’t use these methods, and would instead do it exactly the same way that one tunes REE set the environment variables before Ruby is invoked. The methods are available, however.

Kirk Haines wrote a very deep technical post about MRI memory allocation in Ruby 1.8 which you can read also. The main concepts are generally applicable in Ruby 1.9 as well.

Joe Damato has a good Garbage Collection and the Ruby Heap screencast about memprof. It provides a little more insight into Ruby’s GC and how you can debug it within your application.

Lastly it’s also worth mentioning that while helpful, GC optimizations aren’t necessarily a magic solution. Depending on why you want GC optimizations, you may just be experiencing overall bloat and create more objects than you really need. Sudara Williams’s post That’s Not a Memory Leak, It’s Bloat explains the symptoms and common use cases quite well.

In any case, you should be able to use these options on the available Ruby 1.9.2 version we support. As always, customers can file a ticket to find out more and seek help with any further questions. Of course, feel free to share your thoughts with us in the comments as well!