You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Lynn Schaper <sc...@Colorado.EDU> on 2003/05/31 01:15:09 UTC
[users@httpd] MaxRequestsPerChild, memory, and ps allocation
We're seeing some interesting behavior with memory on apache and need to
tune the server around it. We run apache_1.3.26 with mod_ssl_2.8.10 on
Solaris 8, using PHP_4.3.2RC4. This is our webmail server and it runs
Horde/IMP as the webmail client.
We are seeing some httpd's get pretty big (output from top):
BIGGEST:
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
27936 nobody 3 58 0 377M 349M sleep 9:04 0.20% libhttpd.ep
27930 nobody 3 28 0 115M 98M sleep 7:43 0.60% libhttpd.ep
SMALLEST:
2438 nobody 3 54 0 16M 9888K sleep 0:00 0.00% libhttpd.ep
2444 nobody 3 34 0 16M 9904K sleep 0:00 0.00% libhttpd.ep
The majority run between 15Mb and 40Mb in size.
Our testing shows that these processes grow when users upload and send
attachments, and for some reason the memory is not released after that
connection is finished. We can accept that as a PHP feature/bug, and we
decided that we can control this with MaxRequestsPerChild, having the
children die after a given number of connections and forcing the memory
to be recovered. We've been watching "apachectl fullstatus" for a few
days and have these questions:
1) When we have "MaxRequestsPerChild 10000", we've seen the children
serve up to 700 more than 10,000 requests. Here are 2 lines (Request
eliminated) from fullstatus on one pid, the last one is where it died
at 10622 requests:
16-2 10077 0/10622/18191 _ 674.74 1 411 0.0 21.94 38.59 12.203.214.9
16-2 10077 0/10622/18191 W 674.74 4 0 0.0 21.94 38.59 127.0.0.1
QUESTION: How often does the apache parent check to see if a child has
reached its limit? How far over the MaxRequestsPerChild can we normally
expect to see the children run?
2) Apache seems to favor certain children when the server is not busy.
At some times of day, we have many children that are idle, and apache
does not seem to distribute requests to all children, rather it uses its
"favorites." When we look at children that were started at the same
time, some have taken 4000 requests, others only 2000 requests, and
corresponding amount of data transferred and CPU time also vary. It
makes sense that the "favorites" are the ones that suck up memory, since
they serve more requests and thus are more likely to do attachments.
Here are some lines from fullstatus (Request eliminated), sorted by
number of accesses this child:
7-0 21928 0/4003/4003 _ 272.62 28 0 0.0 24.90 24.90
17-0 21938 0/3969/3969 _ 268.34 5 0 0.0 22.02 22.02
snip
26-0 23713 0/2111/2111 _ 152.87 5 0 0.0 12.20 12.20
27-0 23739 0/2036/2036 _ 145.91 4 2386 0.0 12.74 12.74
QUESTION: Is there a method to this? What is the reasoning? We can
tune the server to not have as many idle servers around, but why doesn't
apache use the ones that are there and idle? It seems to use the same
5-10 (when we're not busy) over and over again.
TIA for any advice. We're hoping it helps us to tune RequestsPerChild
and spare servers so we don't use up all of our memory. We also don't
want to bog the machine down with killing and starting children.
Lynn
--
Lynn Schaper Schaper@colorado.edu
Information Technology Services Central and Unix Services
University of Colorado at Boulder 303-492-3872
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] MaxRequestsPerChild, memory, and ps allocation
Posted by Rasmus Lerdorf <ra...@apache.org>.
On Fri, 30 May 2003, Lynn Schaper wrote:
> Our testing shows that these processes grow when users upload and send
> attachments, and for some reason the memory is not released after that
> connection is finished. We can accept that as a PHP feature/bug
It used to be the case that PHP we buffer an entire upload in ram before
writing it out to disk. But that was fixed a while ago, and the fix is
most definitely in the version you are using. I would have a look at the
user-space code that manipulates the uploaded file. Perhaps it is reading
the entire thing into memory in order to copy the uploaded file out of the
tmp dir and into its final location. The code should be using the
move_uploaded_file() function to do this. That will simply do a rename()
(if possible) and if that fails it will try to copy it in 8k chunks.
If your code is already using move_uploaded_file(), then have a look at
what is being done with the file once it has been moved into the right
location. It sounds a lot like you have a basic application-level problem
where something is loading the entire file into memory at some point.
I realize your question was regarding workarounds and not the problem
itself, but I much prefer to try to solve the real problem.
-Rasmus
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org