Peformance up - using OobGC & GC.disable
ononoma at gmail.com
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 yhbt.net> wrote:
> Tatsuya Ono <ononoma at gmail.com> 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:
>> (do something)
>> 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
> There was discussion of this on the usp.ruby mailing list starting at
> Message-ID: 20110914234917.GA2480 at dcvr.yhbt.net
> usp.ruby archives are at http://bogomips.org/usp.ruby/archives/2011.mbox.gz
> Unicorn mailing list - mongrel-unicorn at rubyforge.org
> Do not quote signatures (like this one) or top post when replying
More information about the mongrel-unicorn