From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS14383 205.234.109.0/24 X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,FREEMAIL_FROM, RP_MATCHES_RCVD,T_DKIM_INVALID shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: archivist@yhbt.net Delivered-To: archivist@dcvr.yhbt.net Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by dcvr.yhbt.net (Postfix) with ESMTP id A01D51F869 for ; Wed, 12 Oct 2011 16:24:20 +0000 (UTC) Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 84D151678369; Wed, 12 Oct 2011 12:24:15 -0400 (EDT) X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org Received: from mail-yw0-f50.google.com (mail-yw0-f50.google.com [209.85.213.50]) by rubyforge.org (Postfix) with ESMTP id 73ABA1858379 for ; Wed, 12 Oct 2011 12:00:55 -0400 (EDT) Received: by ywm13 with SMTP id 13so200487ywm.23 for ; Wed, 12 Oct 2011 09:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NW+VN14rcz7fxoiUj/j4kh5QHyZ0NPAT0dgWi2bool8=; b=kIXhlzgjrb0VZSHgGCel0AtkMO3bDiqvmfFMylfBCz2ZJ3hCji1FuYyBupZQ3p5uGY mdwUcj2rfaR3hIjQN/klNH4SxCVq2ahFb4DvetNGYiokxcnOZCTvyjmxXPEjJCHF6Le4 IKlCQfvv2Tx0Webn+tD1Wa5y14LQvwbVf2jEM= MIME-Version: 1.0 Received: by 10.150.196.13 with SMTP id t13mr1241822ybf.69.1318435254965; Wed, 12 Oct 2011 09:00:54 -0700 (PDT) Received: by 10.151.13.5 with HTTP; Wed, 12 Oct 2011 09:00:54 -0700 (PDT) In-Reply-To: References: <20111004225305.GA5373@dcvr.yhbt.net> <20111010215324.GA6378@dcvr.yhbt.net> Date: Wed, 12 Oct 2011 17:00:54 +0100 Message-ID: Subject: Re: Peformance up - using OobGC & GC.disable From: Tatsuya Ono To: unicorn list X-BeenThere: mongrel-unicorn@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mongrel-unicorn-bounces@rubyforge.org Errors-To: mongrel-unicorn-bounces@rubyforge.org 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 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 wrote: >> Tatsuya Ono 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