On 30-11-2008, Graham Dumpleton wrote:
>
> 2008/11/30 William Dode <[EMAIL PROTECTED]>:
>>> Anyway, it doesn't matter how many processes/threads you configure for
>>> main Apache child worker processes, any dynamic requests will stall if
>>> a dynamic request before them takes a long time. In other words, you
>>> have created a potential bottleneck in the way you have configured the
>>> daemon process group.
>>
>> Does this bottleneck can make the load so high to freeze the system ?
>
> It in itself will not cause load to increase.
>
>> Because most of the time every think is fine i just would like that when
>> there is an overload apache answer a 503 service unavailable.
>
> It will not return 503 unless situation gets extreme. More below about this.
>
>>> If you
>>> have numerous scripts, you need to be aware that each will be run in
>>> the context of its own sub interpreter within the daemon process.
>>
>> Is it possible that even if i have one script it will run differents sub
>> interpreters ?
>
> If it only appears in one virtual host under one URL, should only be
> one sub interpreter. Log value of mod_wsgi.application_group from WSGI
> environ dictionary to be sure.
>
>> My problem is here, i cannot identify clearly what is going on.
>> I'm admin of two servers since years, and never seen this : completly
>> nothing is visible in the differents logs or ps.
>> The *only things* make me looking at apache is that when there is the
>> high load netstat show me a lot (25) of line with wsgi socket.
>> unix  4      [ ]         STREAM     CONNECTING    0        
>> /var/run/apache2/wsgi.1911.1.1.sock
>> unix  4      [ ]         STREAM     CONNECTED     886488
>> unix  4      [ ]         STREAM     CONNECTING    0        
>> /var/run/apache2/wsgi.1911.1.1.sock
>> unix  4      [ ]         STREAM     CONNECTED     886487
>> ps aux doesn't show me any cpu or memory problem. I could also see that
>> the app was not restarted before or during the load (same pid).
>
> This indicates that whatever request the daemon process is handling
> has stalled and because it is single threaded, any subsequent requests
> have been queued up waiting for that first one to finish. The reason
> you will not see a 503 message straight away is that the socket
> listener queue length means they queue up. Even when that is full,
> mod_wsgi in client side will retry some number of times just in case
> it is because of daemon processes are restarting. Only then would a
> 503 error be returned. It is likely you aren't seeing 503 errors as
> pending requests never exceeds listener socket queue length.

Ok, it's what i thought.

>
> So, what this tells you is that the issue is likely in your
> application code and/or connections to or operations being done on any
> associated database.

The question now is to know if it's my application wich make the load 
high or if it's because of the load high (because an other reason) my 
application cannot answer...

>
> If you are seeing high load, check whether CPU usage is in user or
> system space. Then also perhaps look at output of 'vmstat' and see if
> the problem is due to your machine swaping because of running out of
> physical memory and there needing to page. This could account for high
> load. Inefficient queries could cause this. Check memory usage of
> mod_wsgi daemon process and database processes to see if they spike.

Nothing like that even if there is only 256mo on this server... I must 
investigate more and i'll came back.

Thanks

-- 
William Dodé - http://flibuste.net
Informaticien Indépendant


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to