0

Server Version: Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/1.0.1e-fips DAV/2 mod_bwlimited/1.4 PHP/5.4.27 mod_perl/2.0.6 Perl/v5.8.8 CENTOS 6.6 PHP handler - DSO

The server is running with prefork module. Apache child processes start at about 10mb and gradually grows (to over 100mb). I'm beginning the process of searching for memory leaks - but in the interim I reduced MaxRequestsPerChild to 500 (from 10000), based on my understanding that this would kill the child earlier and start back at 10mb. However, in fact, the memory increases continue (it's grown to 23mb after a couple of days. This makes me think I'm not properly understanding something.

I'm assuming the childprocesses are dying because i see new PID being created and can see the # of accesses per child grow in the Apache Status page.

Is it possible that this is cache-related? I have eAccelerator for PHP enabled with a max memory allocation of 16mb (currently using about 3mb). I realize I don't know enough about how cache memory is managed (I presumed it was shared vs. replicated with each child process).

Addional thought... after the child process grows for a few days - the memory footprint falls back to smaller values without intervention. For instance, after it peaked at 100mb it fell to about 25mb one day (without an Apache restart). Is this perhaps just normal behaviour?

1
  • If you change the MaxRequestPerChild to 10 and nothing changes, you must take a look on what application you are running. Some CMS frameworks (PHP mostly) will eat a lot of memory.
    – ThoriumBR
    Dec 26, 2014 at 12:15

1 Answer 1

0

As soon as the new process starts, it's possible it will server couple of requests immediately and thus grow from 10 to 2x MBs and give you false sense of proportion.

Unfortunately just by looking at top or /proc data, you won't get complete picture. You are probably being misled by watching at live numbers. Gathering statistics via some monitoring tool would give you much better picture of what's exactly going on.

Regarding MaxRequestsPerChild setting - you did get it right, this setting tells apache after which number of served requests should process get recycled (eg: killed and replaced with fresh process). But, this won't guarantee you that processes will stay near 10MB limit, because even first request served will load shared stuff to memory, which will continue to be used until that specific PID dies. I would advise you to lower it even further - to 50. You are basically trading CPU for memory - eg lower the number, more CPU cycles will be used on killing existing and forking new apache processes. Servers tend to have excess CPU power today, so it's generally safe to swap CPU for RAM in cases like this.

Also, when you talk about memory usage, you didn't specify how did you calculate usage of each process? Did you calculate "proportional set size (PSS)", to exclude memory segments shared between all apache processes? Take a look at smem.

1
  • Thanks for the thoughtful answer. I'm not sure I'll ever get to the bottom of the original question - since I took advantage of the slow holiday period to rebuild apache and php (to 2.4 and 5.5 respectively). Since then, the processes are behaving exactly as I'd hoped... the child process comes in at about 9mb and usually builds to about 12mb or so before dying. And over a few days - the newly created PID is always the same. I am just looking at htop/RSS for the mem size... I will look into smem (on a learning curve...lol). (also using zend opcache vs eaccelerator now).
    – williamk
    Dec 30, 2014 at 19:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .