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.


Tatsuya

On 10 October 2011 22:53, Eric Wong <[email protected]> wrote:
> Tatsuya Ono <[email protected]> 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: [email protected]
>
> usp.ruby archives are at http://bogomips.org/usp.ruby/archives/2011.mbox.gz
> _______________________________________________
> Unicorn mailing list - [email protected]
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Reply via email to