the disease: on an SMP system, multiple CPUs could try to update requests_this_child simultaneously, and only one of the updates will take effect. this is a rare timing situation. the SMP issue is not important because the variable will still be updated and continue to do its job.
requests_this_child is the variable used to implement MaxRequestsPerChild. this is used to periodically quiesce worker processes which are replaced by new workers and keep the server going if there are slow memory or resource leaks due to bugs. the hope is a worker process that is using more and more memory or file descriptors over time will be shut down before the situation gets serious. it counts the number of connections served by a worker process, contrary to its name. the admin picks a big number out of the air, let's say 10000, and sets MaxRequestsPerChild to that value. if he observes that that workers are now being shut down before the leak gets too bad and there isn't a lot of unneccessary process forking/exiting, great! he's done until he has time to address the software bug which is the root cause of the problem. if the workers are still getting too big before quiescing, he lowers MRPC. if there is no more worker growth problem but the CPU is high and he can see workers getting forked very rapidly, he raises MRPC. so if internally the httpd actually processes 10002 connections instead of 10000 before quescing some worker process, it isn't important enough to justify slowing down the mainline path. if you have a hung server, I would do some more diagnosis and not get sidetracked by MRPC. have you looked for unusual messages in the error log, especially messages that mention MaxClients? have you gotten samples of the server-status page with ExtendedStatus on? do you see a pattern with certain URLs that hang and others that do not? are small local static files always served quickly? Greg ----- Original Message ---- From: Darryl Miles <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, July 20, 2007 1:46:53 PM Subject: Re: one word syncronize once more Greg Ames wrote: > please see rev. 558039. requests_this_child does not need to be 100% > accurate. the cure below is worse than the disease. > > Greg > > - requests_this_child--; /* FIXME: should be synchronized - aaron */ > + apr_atomic_dec32(&requests_this_child); /* much slower than > important */ Maybe someone could reconfirm to the list what exactly the disease is ? ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
