[Mongrel] Memory leaks in my site

Kyle Kochis kylekochis at gmail.com
Wed Mar 7 21:17:26 EST 2007

Ah. Thank you Alex, this is very handy information for me as I am in
charge of quite a few small VPS's. I have not had mem leaking issues
yet but this could could come in really handy for a much larger scale
rails project I am working on.
Kyle Kochis

On 3/7/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> OK, I probably know what is happening. So...
> 1. Mongrel with a Hello, World application has virtual segment size (VSS) of
> ~32 Mb. As long as it is not overloaded, it stays at that level.
> 2. Once you overload it, Mongrel starts spawning new threads, up to the
> default limit of 1024, or {max # of file descriptors per process - 2},
> whichever is smaller.
> 3. Creating a new thread takes quite a bit of RAM (I guess, most of it is
> simply allocated to the stack). 1024 new threads take over 60 Mb.
> 4. Killing the thread does not cause Ruby interpreter to release the memory
> back to OS.
> So, in a nutshell, in overload situation you end up with all 1024 threads
> parked at the Rails mutex.
> Solution is to set --num-procs much lower than 1024. Say, to 64. Or even to
> 10.
> In my tests, Hello'world application did not exceed 48 Mb even with
> --num-procs=256. Due to the Rails mutex, having more threads doesn't really
> help in the situation where all of your static content, uploads and
> downloads are served by an upstream web server.
> A more "industrial" solution would be to redesign Mongrel's internal
> architecture a bit. Requests routed to Rails can be placed in a queue, and
> the thread released, instead of being parked at the mutex. It would help
> people hosting their apps in those 64 Mb slices to work without an upstream
> web server, but it would also add complexity to the code. One of those
> tradeoffs.
> I also think that --num-procs=1024 is not the best possible default. For the
> benefit of all the people running Rails in cheap VPSes, it should be set to
> a level not exceeding the limits of a 64 Mb slice.
> I have a pretty lengthy record of configuration under test and what I did to
> figure all this out. If anyone is interested in reading it, let me know.
> Alex
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

More information about the Mongrel-users mailing list