Rainbows! Rack HTTP server user/dev discussion
 help / Atom feed
From: Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>
To: Rainbows! list <rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org>
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> (raw)
In-Reply-To: <E326380F-0B96-4B17-B721-DB814415E03E-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Claudio Poli <claudio-3HQ/CcOImoi171pxa8y+qA@public.gmane.org> 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


  parent reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12  4:19 Claudio Poli
     [not found] ` <E326380F-0B96-4B17-B721-DB814415E03E-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-02-12  5:00   ` Eric Wong [this message]
     [not found]     ` <20130212050021.GA18443-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2013-02-14  6:58       ` Claudio Poli
     [not found]         ` <B3ED3231-62E8-4FF5-A65A-859AFD790C2B-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-02-14  7:15           ` Eric Wong
     [not found]             ` <20130214071512.GA10890-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2013-02-14  8:49               ` Claudio Poli
     [not found]                 ` <F6728D3D-3E35-488B-8165-EB80E25FFF1B-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-02-14 20:28                   ` Eric Wong

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://bogomips.org/rainbows/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130212050021.GA18443@dcvr.yhbt.net \
    --to=normalperson-rmlxzr9ms24@public.gmane.org \
    --cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Rainbows! Rack HTTP server user/dev discussion

Archives are clonable:
	git clone --mirror https://bogomips.org/rainbows-public
	git clone --mirror http://ou63pmih66umazou.onion/rainbows-public

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.rainbows
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.rainbows

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox