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 <[email protected]> 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 <[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
