On Mon, Feb 15, 2010 at 9:01 AM, Zdravko Spoljar <zdravko.spoljar@xxxxxxxxxxxx> wrote: > On Mon, 2010-02-15 at 07:29 -0500, Jeff Trawick wrote: > > <cut> > >> >> Anything that causes child processes to exit during steady state can >> lead to extra child processes *when some requests take a relatively >> long time to finish*. > > now, if i understand correctly "active child processes" != "child > processes which are terminating" so relative long lived request hold > additional childs alive, and apache spawns new one above ServerLimits to > server new requests. And there is no directive which will limit number > of apache processes in absolute sense? Absolute control Use this combination of directives: MaxSpareThreads =MaxClients MaxRequestsPerChild 0 Since graceful restart has the same effect -- telling a child process to terminate even though the requests it is handling won't finish for a long time -- you can't use graceful restart either. Not absolute control but still work-able with a relatively small number of extra child processes as long as individual requests don't hang: MaxSpareThreads not small enough that parent terminates child processes except in rare circumstances (e.g., after a period of abnormally high client connections) MaxRequestsPerChild enabled, but only after a large number of requests (e.g., 80000) When you don't use absolute control, you'll need to monitor behavior for a while to see if MaxSpareThreads or MaxRequestsPerChild needs to be increased. > so only solution would be to use > kernel mechanism for limiting number of processes for apache user. > of course that can lead to "worst case" situation in which i will have > up to 1 per child slow request finishing, and no "fast" traffic served > because there are no available threads. > right? :-) (Solution above) That's why worker allows these extra processes to be created. > >> Your very low value for MaxRequestsPerChild is the likely culprit. >> You might have to increase MaxSpareThreads as well since that will >> cause one or more child processes to begin termination when load >> decreases by a moderate amount. > > that was in because i wanted relative short time of recycling processes, > to avoid memleaks, but i get short of memory due long live requests :-( > (that is relatively new problem, as php application works for over year) > > to summ: > i should rise MaxRequestsPerChild to 5000 (or more), I'd guess higher, but check watching the number of extra processes > and have slower > rate of recycling processes? yes > and setup some way to kill off long live > requests (maybe killed by firewall setup or by some mod_qos options). investigate why they are long running; if because of client behavior (very slow upload of large data), then firewall setup could help; but often it is because some application logic is hung, and Apache will wait forever for mod_php to return control > also setup max number of processes in kernel this should only be plan B just in case tuning of MaxSpareThreads and MaxRequestsPerChild doesn't handle some rare condition > (and max process RSS size) one thread going over the limit will trash all other requests being served by that process, right? > to stabilize server (as apache cannot take care of itself). because of the combination of threaded MPM, the need for aggressive child process termination because of (presumably) an application problem, and long-running requests > > i would rather have locked/crashed apache (which can be detected&fixed > by cron job) than have unusable system due lack of memory (which i need > to fix myself :) > > any way, thanks for precise point to my lack of understanding of > implications of using MaxRequestsPerChild != 0. --------------------------------------------------------------------- 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@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|