|
Jim Gallacher
jg.lists at sympatico.ca
Mon Aug 15 17:55:10 EDT 2005
Huzaifa Tapal wrote: > I am not using mod_python Session management in my handler. > Huzaifa I don't think that your problems are related to init_mutexes then. The mutexes are used for 3 things: locking session objects, locking the dbm file used for storing session data (in the case of DbmSession), and locking the dbm file used as the psp cache. Oh, I guess I didn't ask you that: are you using psp? I may be wrong, but I don't see how just initializing the mutexes at mod_python startup could be exercising the bug in the 2.6.12 kernel. You could always try compiling with MAX_LOCKS=2 (defined in src/include/mod_python.h) and see what happens, but I would be suprised if it made a difference. Heck you could even try MAX_LOCKS=0, but I'm not sure what might happen there. I'm pretty sure if you do call _apache._global_lock() with MAX_LOCKS=0 you'll seg fault as I don't thing we check to see if glb->nlocks==0. Please note that in version 3.2 you will be able to specify MAX_LOCKS using configure --with-max-locks=<some integer>. Jim > Jim Gallacher wrote: > >> Huzaifa Tapal wrote: >> >>> No, no content was being served from ns, however, our sys dev team >>> here did some investigation and here is what the found: >>> >>> in mod_python.c for the apr_status_t init_mutexes() method which I >>> believe gets called for the Memory Session management, apache's >>> apr_global_mutex_create() locking mechanism is being used to lock a >>> file on the filesystem in cases of a mulit-process and multi-threaded >>> apache configuration to share the session between different child >>> processes. Apache's apr_status_t init_mutexes() method is covered >>> with flock() the handling of which in the debian kernel 2.6.12.4 has >>> a bug under severe cases. >>> >>> In our testing, under a very, very heavy load of over 800 concurrent >>> connections using a jython-based tool called grinder, a race >>> condiditon is happening at which point the kernel is panicking. The >>> solution to this problem as we see it is to either change apache's >>> apr_status_t init_mutexes() method ot use fnctl lock instead of >>> flocks, or run apache with only one process at all times. >>> >>> In the meantime, we are going to still moderately load test our >>> cluster through out the weekend and see if we can replicate the panic >>> under a moderate load but a long duration of time. >> >> >> >> Are you using sessions in your test handler? If so I've got some ideas >> I can share, but I don't want to confuse the issue if you are not >> actually using sessions. >> >> The short answer is that init_mutexes() does indeed allocate mutexes >> for session locking support. >> >> Jim >> >> > > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python >
|