From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: * X-Spam-ASN: AS33070 50.56.128.0/17 X-Spam-Status: No, score=1.0 required=3.0 tests=AWL,HK_RANDOM_FROM, MSGID_FROM_MTA_HEADER,TVD_RCVD_IP shortcircuit=no autolearn=no version=3.3.2 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: How to manage growing memory with Rainbows! Date: Tue, 12 Feb 2013 05:00:21 +0000 Message-ID: <20130212050021.GA18443@dcvr.yhbt.net> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1360645459 4212 80.91.229.3 (12 Feb 2013 05:04:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Feb 2013 05:04:19 +0000 (UTC) To: Rainbows! list Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Tue Feb 12 06:04:40 2013 Return-path: Envelope-to: gclrrg-rainbows-talk@m.gmane.org X-Original-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Delivered-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Xref: news.gmane.org gmane.comp.lang.ruby.rainbows.general:447 Archived-At: Received: from 50-56-192-79.static.cloud-ips.com ([50.56.192.79] helo=rubyforge.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U582n-0001WJ-61 for gclrrg-rainbows-talk@m.gmane.org; Tue, 12 Feb 2013 06:04:37 +0100 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id B0C852E09E; Tue, 12 Feb 2013 05:04:17 +0000 (UTC) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id C5E4A2E09A for ; Tue, 12 Feb 2013 05:00:24 +0000 (UTC) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id A06E91F6BF; Tue, 12 Feb 2013 05:00:23 +0000 (UTC) Claudio Poli wrote: > My only concern is the growing memory, as we know Ruby does not really > do a good job at it (at least for me, even with all the tweaks in the > world) and I need to find a good way to kill a process and restart > since we are running in a memory-constrained environment. I'm curious, what tweaks did you try? What kind of workload are you running? (many disk writes at all?) Which version of Ruby are you using? Are you counting VMSize or RSS? Are you on 64-bit? Fwiw, virtual memory usage is very high on 64-bit Linux on newer versions of glibc, but mostly harmless since the memory isn't actually used (address space is nearly unlimited). You can try MALLOC_ARENA_MAX_=1 to limit the number of arenas if you want. That might reduce fragmentation since the GVL in MRI means it's unlikely to hit malloc lock contention (glibc uses multiple malloc arenas to avoid contention by default). > What are you using currently? Monit, OobGC? The good thing about the > gem above is that it will kill the Unicorn worker only after the last > requests has been performed and with easy adjustable thresholds. OobGC is absolutely not recommended for Rainbows! (or anything doing persistent connections or simultaneous clients within a process) However, you can safely send SIGQUIT to any Rainbows! worker (bypassing master) whenever you feel memory usage is high, master will restart it. You can just put a simple counter in middleware to do it, something like this: # nr is initialized to a number of your choice elsewhere nr -= 1 if nr < 0 Process.kill(:QUIT, $$) end > Can you point me into the right direction here? Thanks! The best solution is to fix your code/gems/Ruby :) I report and fix all the memory leaks I can find in gems+MRI. One thing to avoid is allocating too much memory in the first place (always use LIMIT in SQL SELECT statements, read files in smaller chunks, etc). It really takes only one poorly thought-out line of code to either OOM or cause a swap storm. I haven't hit one of these problems in a while, but check out commit f95113402b7239f225282806673e1b6424522b18 in git://github.com/rack/rack.git for an example of how IO#gets can ruin your app. _______________________________________________ Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org http://rubyforge.org/mailman/listinfo/rainbows-talk Do not quote signatures (like this one) or top post when replying