Re: apache hanging whole system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-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
>
>   

---------------------------------------------------------------------
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


[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux