On Wednesday, August 25, 2010, Maria <[email protected]> wrote: > Thanks! > >> Are the right number of mod_wsgi daemon process still visible in 'ps' output? > > I'll check on this next time it locks up. > >> If you have only single Django instance per daemon process group, then >> force them to run in the main interpreter rather than a sub >> interpreter of the process. This will eliminate problems caused by >> third party extension modules for Python which don't handle threading >> in sub interpreters properly. You can force use of main interpreter by >> adding: >> >> WSGIApplicationGroup %{GLOBAL} > > Cool, we'll try this setting today and see how it goes. > >> I cant suggest anything else with knowing what Apache MPM you are >> using and what MPM settings are, what you have KeepAlive and Timeout >> set to in Apache. > > We are using prefork. Following are the relevant settings:
If nginx is handling static files, and in particular the only thing Apache is handling is mod_wsgi stuff, why are you using prefork MPM and not worker MPM. > Timeout 300 > KeepAlive Off > <IfModule mpm_prefork_module> > StartServers 3 > MinSpareServers 5 > MaxSpareServers 10 > MaxClients 30 That is maximum of 30 concurrent requests. If you are running multiple daemon process groups, what is the total number of threads across all daemon process groups? Is it less than 30 or more? > MaxRequestsPerChild 2500 Why are you using this? If Apache only handling mod_wsgi and everything running in daemon mode, this should not be needed and the combination of prefork and MaxRequestPerChild is known to be causing an issue in a handful of cases. In those other cases the daemon processes aren't being replaced when they restart, but you say the right number of processes are there. Finally, when you say it hangs, does it ever recover again, or is restart required. Can't remember what you said about that. FWIW, if daemon processes are still present and haven't vanished, one possibility is you are hitting an issue have seen a couple of times before. That appeared to be that operating system was somehow screwing up on UNIX sockets. The connect call was saying it was connecting, but on the server side, it was never seeing a connection. Thus daemon processes were sitting their idle not getting requests and all threads in Apache server child processes were blocked waiting for response from daemon process. If you upgrade to mod_wsgi 3.3, not sure if in 2.8, then will get a change which detects OS stuffing up like this and will time out and at least kill off connection and try and recover. Setting inactivity-timeout on daemon process to 300 seconds could act as a good failsafe as well to restart daemon process if that is the problem with why not being able to receive new connections. So long as you are getting steady stream of requests normally, process should't restart, but if seems to have become idle for no good reason, would restart itself to try and recover. Graham > </IfModule> > >> BTW, are you using same Apache to serve static media files? > > No, static files are being served by nginx before the requests get to > apache. > > -- > 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. > > -- 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.
