Peformance up - using OobGC & GC.disable

Tatsuya Ono ononoma at
Mon Oct 10 19:03:23 EDT 2011

Thanks Eric for the feedback.

I actually had read that email and I think I understand it. But what I
am experiencing seems a different story. Our rails app uses around
250MB memory usually. After applying this patch and calling
GC.disabled on after_fork, the usage of memory increases on every
request and goes up to 1GB easily.

However, yes, I must say that I need to test more carefully. Let me
come back later. I am going to have some stress test and monitor if
Unicorn introduces swapping on VM with this solution. Hopefully I can
do it tomorrow or later this week.


On 10 October 2011 22:53, Eric Wong <normalperson at> wrote:
> Tatsuya Ono <ononoma at> wrote:
>> I don't actually understand is why GC.disable solution could introduce
>> more memory leak. If I simplify the problem, the code is something
>> like bellow:
>> ---------------
>> GC.disable
>> (do something)
>> GC.enable
>> GC.start
>> ---------------
>> When the code block finishes, I expect that memory size should be
>> (almost) equal with the case GC is enabled at begging. But it doesn't
>> seems so from our experience.
>> Do anyone know why there could be significant difference on memory
>> usage because of timing of GC? It might be a question on Ruby rather
>> than Unicorn, though, I thought even just sharing my experience could
>> be worth to someone here.
> Basically, the free(3) function in the C standard library does not
> guarantee memory is released back to the kernel (speed vs memory usage
> tradeoff).
> There was discussion of this on the usp.ruby mailing list starting at
> Message-ID: 20110914234917.GA2480 at
> usp.ruby archives are at
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn at
> Do not quote signatures (like this one) or top post when replying

More information about the mongrel-unicorn mailing list