On Tuesday 11 October 2011, Jim Jagielski wrote: > On Oct 11, 2011, at 3:01 PM, Jim Jagielski wrote: > > On Oct 11, 2011, at 2:09 PM, Daniel Shahaf wrote: > >> Paul Querna wrote on Sun, Sep 11, 2011 at 12:10:53 -0700: > >>> Infra has upgraded eos, aka the main webserver for *.apache.org > >>> to 2.3.15-dev-r1167603 > >> > >> We observe processes whose memory, in trend, grows over time up > >> to 2.8GB and more, for example: > >> > >> http://www.apache.org/eos/mem.txt > > > > which mom? > > mpm even :)
mpm event: http://www.apache.org/server-status At least I assume that's eos. Is this a new problem since you upgraded? I think the problem may be the combination of - by default, httpd never gives memory back to the OS - mpm event creates transaction pool with a separate allocator for every connection - by default, it never destroys transaction pools This means that every allocator keeps the memory that was allocated for that connection (including the request pool). So the process will slowly approach the size (max number of simultaneous connections) * (max memory used for one connection) Max number of simultaneous connections == 3 * 128 == 384 for your configuration. While this limit is probably never reached, I have seen 300 conns for one process in the server-status. If you divide 2.8GB / 300, that's 9MB. That's not totally off as "max memory used for one connection" (depends on the modules/configuration you use). Can you try setting MaxMemFree, maybe to 4000? This will limit the maximum free memory kept in each allocator to 4000K. It will also cause mpm event to destroy transaction pools if more than 128 * 0.75 == 96 are unused, but I am not sure that will make a difference if the load is more or less constant. Cheers, Stefan
