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-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > --------------------------------------------------------------------- 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
|