Hi everyone, the problem now seems to be solved - it turned out that it was not a problem of apache, or php or mysql. The problem was that the hypervisor where I run the VM with apache started swapping to disk... I killed some unnecessary VMs and now I haven't seen this problem happen again.
Anyways, big thanks to everyone who replied! Regards, Peter On 17.05.2010 20:54, Peter Halicky wrote: > Hi Tom, > > PHP: > The RES size of the apache processes is around 25Mb, which totals to > about 2Gb with 80 processes. The VM is configured with 3Gb RAM, so > memory should be OK. > > Mysql: > This, I think, is the most likely explanation - mysql locks. To avoid > this, I tried to set max_execution_time in mysql to 10 seconds (i.e. if > it is locked for 10 seconds, it should terminate the script run and > hopefully also the mysql session). Maybe I'm too optimistic that it > would work... > > FastCGI: I am also thinking about this, but I don't have too much > experience with this. I know there's 'spawn-fcgi' for controlling the > fastcgi processes, but its capabilities seem quite limited to me - fixed > number of processes pre-spawned, I'm not sure how this will scale... > There is PHP-FPM coming, but it's not in the stock PHP yet and is also > not in the distribution I use (I prefer to use packaged versions of > everything, I like that I don't need to care about watching security > advisories and just run the security updates every now and then). > > Anyways, thanks for the suggestions, I'm still waiting for the 'storm' > to happen. Seems the storms have moved outdoors today, we got a lot of > rainfall, but no apache storm on my server ;-) > > Thanks again. > Peter > > On 17.05.2010 19:07, Tom Evans wrote: > >> Apache is unlikely to hang your whole machine - its normally the 'MP' >> part that has the problems. I don't know about Linux issues though. >> >> P: >> >> PHP uses a lot of memory. Run your server for a while, and look at the >> RSS/RES size of the httpd processes. A 'stock' apache process should >> be around 5-10Mb. A process with a nice PHP interpreter can be >> anything from 10Mb to 200Mb - check to see how much yours are. >> >> When your server gets busy, you're telling apache that it can spawn 80 >> children. Does 80 * <avg process size> fit in your RAM? >> >> M: >> >> mysql has locks. It is possible that your web application has locked >> up the DB server in some way - a long running update, or a DB dump, >> etc. If each request coming into the webserver requires a query that >> is blocked, then apache will have to start spawning more children, as >> the requests aren't being completed appropriately. >> This will very quickly turn into a 'perfect storm' : >> >> queries are blocked in mysql -> children dont finish requests -> >> apache spawns more children -> more queries submitted to mysql -> >> slower operating mysql -> more queries are blocked in mysql >> >> This can quickly lead to resource exhaustion. You wouldn't be able to >> connect to apache (no spare children) and there is so little RAM >> available that login cant spawn a tty. You may be just about able to >> ping the box. >> >> >> A solution is to not serve PHP in this manner. PHP as FastCGI works >> well, and clearly indicates where the memory is going (eg to PHP or >> Apache) and you can put tighter controls on FastCGI (which would lead >> to slower response times to your webapp, rather than overloading your >> server) than you would want to on apache. >> >> You could even then run apache with a more resource efficient and >> effective MPM, like worker or (my favourite) event. Apache with the >> event MPM serve all of $JOBs web apps static files and reverse proxies >> to all our app servers, and load never goes above 0.1, ram usage of >> apache never above 150Mb, serving between 2 and 4 million requests a >> day. >> >> Cheers >> >> Tom >> >> --------------------------------------------------------------------- >> 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-unsubscr...@httpd.apache.org >> " from the digest: users-digest-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org >> >> >> > --------------------------------------------------------------------- > 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-unsubscr...@httpd.apache.org > " from the digest: users-digest-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > --------------------------------------------------------------------- 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-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
