2010/1/30 janedenone <[email protected]>: > > > On Jan 30, 3:14 am, Graham Dumpleton <[email protected]> > wrote: >> BTW, what operating system is this? Don't think you have said what it was. > > Sorry: CentOS 5.2 > >> Also might be an idea to say whether you are installing binary >> packages for Apache and mod_wsgi or whether compiling from source code >> and what versions of Apache, APR and mod_wsgi. > > Apache 2.2.3/APR 1.2.7, mod_wsgi 3.1.
Are though these being installed from binary RPM packages or all compiled from source code? If I had to guess, the problem may be that you are using a binary RPM package for mod_wsgi which is compiled against a newer version of Apache and APR libraries than what you are running. Although there is some measure of guaranteed compatibility if using an Apache module compiled against older Apache than what it is being used with, the reverse isn't necessarily true. If you are compiling everything from source code and even recompiled mod_wsgi from source code when you switched from prefork to worker MPM and still had the problem, then I would be worried. Although should point out that mod_wsgi module doesn't use anything which is MPM specific, so technically even if compiled against prefork MPM, same .so should work fine with worker MPM. This presumes though that a specific Linux distribution isn't using quite radically different compile time options for Apache for different MPMs such that modules not dependent on the MPM cant be used against either. >> > Can you send the complete messages from before and after that. That >> > message doesn't look like anything mod_wsgi produces which means you >> > likely have some combination of Apache and APR libraries which is >> > incompatible and is thus breaking things even for normal Apache static >> > file serving. You could check that by simply disabling mod_wsgi and >> > trying to restart Apache and see if problem still persists. > > I suspected a general memory issue first, so I changed the default > worker setup to (following http://blog.zakame.net/tips/apache2-worker-lowmem): > > <IfModule mpm_worker_module> > MaxClients 10 > MinSpareThreads 3 > MaxSpareThreads 7 > ThreadsPerChild 3 > MaxRequestsPerChild 200 > </IfModule> > > With mod_wsgi and LogLevel debug, I get: > > [Sat Jan 30 08:58:06 2010] [debug] proxy_util.c(1854): proxy: grabbed > scoreboard slot 0 in child 5674 for worker proxy:reverse > [Sat Jan 30 08:58:06 2010] [debug] proxy_util.c(1950): proxy: > initialized worker 0 in child 5674 for (*) min=0 max=25 smax=25 > [Sat Jan 30 08:58:06 2010] [notice] Apache/2.2.3 (CentOS) configured > -- resuming normal operations > [Sat Jan 30 08:58:06 2010] [info] Server built: Nov 12 2009 18:46:18 > [Sat Jan 30 08:58:06 2010] [debug] worker.c(1740): AcceptMutex: > sysvsem (default: sysvsem) > [Sat Jan 30 08:58:06 2010] [alert] (12)Cannot allocate memory: > apr_thread_create: unable to create worker thread > [Sat Jan 30 08:58:08 2010] [alert] No active workers found... Apache > is exiting! > > Without mod_wsgi: > > [Sat Jan 30 08:51:40 2010] [debug] proxy_util.c(1854): proxy: grabbed > scoreboard slot 0 in child 26443 for worker proxy:reverse > [Sat Jan 30 08:51:40 2010] [debug] proxy_util.c(1950): proxy: > initialized worker 0 in child 26443 for (*) min=0 max=25 smax=25 > [Sat Jan 30 08:51:40 2010] [notice] Apache/2.2.3 (CentOS) configured > -- resuming normal operations > [Sat Jan 30 08:51:40 2010] [info] Server built: Nov 12 2009 18:46:18 > [Sat Jan 30 08:51:40 2010] [debug] worker.c(1740): AcceptMutex: > sysvsem (default: sysvsem) > > I should add that my VPS only has 256 MB RAM guaranteed (1024 MB > dynamic). Maybe it's pointless to try to optimize with so little RAM? > On the other hand, the machine manages to serve all three sites (via > Django) with prefork MPM. For a freshly started Apache 256 MB is more than enough. Have seen people run Apache/mod_wsgi and Django on a 64MB VM on SliceHost. The trick there is using nginx proxy front end to handle static files, worker MPM in Apache and mod_wsgi daemon mode to get tight control on number of fat Python web processes and thread counts. Graham -- 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.
