On Oct 24, 1:15 pm, Graham Dumpleton <[email protected]> wrote: > On 22 October 2010 07:10, Patrick Michael Kane <[email protected]> wrote: > > > Hey Graham: > > > Just had another freeze, this time with flock -- backtraces from two > > of the WSGI processes below. > > > The Apaches are in the same state as with the SysV mutex, blocking on > > this connect: > > > connect(69, {sa_family=AF_FILE, path="/home/actionkit/releases/ > > stable/apache/logs/.2028.61.7.sock"}, 110 > > > Let me know if you need more info! > > If possible, next time can you capture it across all process in the > daemon process group. > > Want to validate that whether they are all stuck on flock() or sysvsem > lock in Thread 2. > > This will tell me whether issue is that no process is getting past > lock, or whether one is getting to do apr_poll() on listener socket, > but not seeing a notification.
Sorry to jump in on an older thread but we've been seeing exactly this behaviour, but with earlier software version (ostensibly standard RHEL5 fare) mod_wsgi-2.6-1.el5 httpd-2.2.3-31.el5_4.2 python-2.4.3-27.el5 There seems to be no regular pattern to it, though it's more common during high load periods. Poor mans forensics have indicated it seems to occur when all the daemon processes restart close together. On the system that was exhibiting the problem, I moved the daemon count from 4 to 8, and threads from 5 to 8, and bumped up the max requests. This appears to have mitigated the problem, but as it appears for now to be a bug either within mod_wsgi or apache I'm happy to help any way I can in tracking it down. Matt -- 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.
