excessive RAM consumption - memory leak

Kiril Angov kupokomapa at gmail.com
Thu Feb 21 22:36:21 MSK 2008

I do not know how you restart nginx but you can send the control process
"kill -HUP" and it will do exactly what you want, which is gracefully
restart each worker process. You can have a script check for the memory
usage and do that when you see it is getting high, or simply do that every
24 hours.


On Thu, Feb 21, 2008 at 2:17 PM, Todd HG <lists at ruby-forum.com> wrote:

> >> Igor Sysoev wrote:
> >> > On Wed, Feb 20, 2008 at 11:47:29PM +0100,
> >>
> >> Is there anywhere I could read more about how Nginx uses
> >> connection_pool_size, stores connections, if it is in a cache in RAM or
> >> hard drive, and what else might be stored in RAM by Nginx?
> >
> > All that you need is to disable gzipping images. It's enough.
> > Other default settings do not allow workers to grow up.
> Of course disabling gzip defeats the purpose of having gzip decrease
> bandwidth and increase site speed for readers. Right now I only have
> gzip handling a few million js and css files a day, in addition to tens
> of millions of images which are not gzipped, but the RAM usage just
> grows until it is completely consumed. By setting the gzip compression
> level to 1 the RAM consumption grows more slowly, but eventually eats
> all the RAM.
> It appears what might be needed is a setting to allow the total number
> of connections for gzip to be set before Nginx automatically kills and
> restarts a worker. This would be similar to the Apache
> MaxRequestsPerChild limit setting. There should be a way to set Nginx to
> kill and restart the worker process to free the RAM, and start again at
> zero for situations like mine.
> Without a solution I need to restart my server about every 24 hours, and
> this is a very robust server.
> --
> Posted via http://www.ruby-forum.com/.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080221/f6d3c872/attachment.html>

More information about the nginx mailing list