If you're running Ruby 1.9.3, go upgrade to 2.1.2. It is such an improvement all around - deploy time, restart time, test time, console startup (if you're using Rails), etc. Just a whole different experience.
And if you've done a 1.8.7 to 1.9.3 upgrade, going from 1.9 to 2.1 is nothing. Piece of cake by comparison.
Maybe this will help someone, as well...we've been trying to collect all of the different tuning and implementation information on the Ruby GC in one place:
That's actually a huge help. What I've also been looking for (and haven't been able to find) is a good guide on How to Tune your GC settings. Aman Gupta has gotten the closest so far* (I think), but I'd really love a step-by-step of "OK, open your console, run `GC.start`, take note of this property because it means X and indicates that Y would be a good setting for Z, etc. etc"
It would be interesting or useful to know more about it, but what I think is that ideally a right impementation of a GC should not require any tweeks from the outside... and I am pretty sure you are not going to get any signifcant performance boost by using different GC values than default.
I wish there was a "webapp" environment flag you could set that would tell Ruby to apply reasonable GC/memory settings for a larger / constantly running app.
Ruby 2.1's GC is worlds faster, for most applications-- especially with a minor amount of tuning. I saw GC time drop from 20ms to under 5ms (using new relic). Memory usage until GC has gone up a bit though.
I can only hope, and have good reason to after 2.1, that future improvements are so good.
Why not to let the user decide when he wants to achieve full GC (As Passenger is doing it between requests) and so avoid the performance regression this patch brings?
And if you've done a 1.8.7 to 1.9.3 upgrade, going from 1.9 to 2.1 is nothing. Piece of cake by comparison.