Re: Peformance up - using OobGC & GC.disable

From: Tatsuya Ono <ononoma@gmail.com>
To: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: Peformance up - using OobGC & GC.disable
Date: Wed, 12 Oct 2011 17:00:54 +0100	[thread overview]
Message-ID: <CAHBuKRhLiu260cWFcqzsFhETKQ4Nc3GQ+x+fxDL7dg0sG+XBvQ@mail.gmail.com> (raw)
In-Reply-To: <CAHBuKRii9X+b4V0ehV+4cC_UgKPEuYdk-WH1CtvdO4A0rkjrqw@mail.gmail.com>

Yes, you are right, Eric. The usage of memory stops increasing at a
certain point. Besides I do not see any significant page I/O with it.

I give the patch go for our live service without the UnicornKiller. I
will report if we experience any issues occurred in the wild.

Thanks Yuichi again for submitting the patch and sharing your knowledge.

By the way, I tested this with Rails 2.3/Ruby 1.8.7/FreeBSD 8.2

Tatsuya

On 11 October 2011 00:03, Tatsuya Ono <ononoma@gmail.com> wrote:
> 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 <normalperson@yhbt.net> wrote:
>> Tatsuya Ono <ononoma@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:
>>>
>>> ---------------
>>> 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@dcvr.yhbt.net
>>
>> usp.ruby archives are at http://bogomips.org/usp.ruby/archives/2011.mbox.gz
>> _______________________________________________
>> Unicorn mailing list - mongrel-unicorn@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>> Do not quote signatures (like this one) or top post when replying
>>
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying