How to manage growing memory with Rainbows!

Claudio Poli claudio at
Thu Feb 14 08:49:16 UTC 2013

Il giorno 14/feb/2013, alle ore 08:15, Eric Wong <normalperson at> ha scritto:
> Last I checked, tcmalloc never releases memory to the OS, so that
> could be a problem.  (Giving memory back to the kernel and then
> getting it back soon afterwards is slow because the kernel must
> clear that memory, first, so most malloc implementations (including
> glibc) will try to keep memory for the process)
> You might also want to try MALLOC_MMAP_THRESHOLD_=131072 to disable the
> sliding sbrk/mmap window (you can try larger/smaller values).  The
> latest Linux man-pages releases have better mallopt(3) documentation
> (but the arenas stuff was only documented on Dreppers blog, AFAIK (and
> glibc.git/malloc/*.[ch] comments)

Thanks for the advices Eric, will try.

I have few more questions before definitely make the switch if you don't mind.

This is the configuration I'm trying out in staging:

Is there something special that should I know about AR connection pool and Rainbows! + Threadpool? My pool in database.yml is 30.
After a small load test currently I'm sitting around 60/80 connections, which is kinda expected given that also Sidekiq is in action.

I don't like the global $redis connection. Can you, or anyone else, offer any advice how to improve that, if you use it in your projects?
The goal was to keep a connection alive in a single process due to the sheer number of commands that can be put in redis as consequence of actions, but now that I'm using threads it probably needs to be changed.
The cost however for opening a new connection seems high, I was reading this:!topic/redis-db/xcz5MXykXdk

Thanks for the help,

More information about the rainbows-talk mailing list