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.5 required=5.0 tests=AWL,RP_MATCHES_RCVD 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 9A13A2968AC for ; Mon, 10 Oct 2011 22:11:47 +0000 (UTC) Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 232B93C8041; Mon, 10 Oct 2011 18:11:47 -0400 (EDT) X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id 9050E185837B for ; Mon, 10 Oct 2011 17:53:25 -0400 (EDT) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id D0CEC1F4CB; Mon, 10 Oct 2011 21:53:24 +0000 (UTC) Date: Mon, 10 Oct 2011 14:53:24 -0700 From: Eric Wong To: unicorn list Subject: Re: Peformance up - using OobGC & GC.disable Message-ID: <20111010215324.GA6378@dcvr.yhbt.net> References: <20111004225305.GA5373@dcvr.yhbt.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 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