After reading your message, I disabled quite a lot of modules. The following modules remained active:
LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule auth_digest_module modules/mod_auth_digest.so LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_alias_module modules/mod_authn_alias.so LoadModule authn_anon_module modules/mod_authn_anon.so LoadModule authn_dbm_module modules/mod_authn_dbm.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_owner_module modules/mod_authz_owner.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_dbm_module modules/mod_authz_dbm.so LoadModule authz_default_module modules/mod_authz_default.so LoadModule include_module modules/mod_include.so LoadModule log_config_module modules/mod_log_config.so LoadModule logio_module modules/mod_logio.so LoadModule env_module modules/mod_env.so LoadModule ext_filter_module modules/mod_ext_filter.so LoadModule mime_magic_module modules/mod_mime_magic.so LoadModule expires_module modules/mod_expires.so LoadModule deflate_module modules/mod_deflate.so LoadModule headers_module modules/mod_headers.so LoadModule usertrack_module modules/mod_usertrack.so LoadModule setenvif_module modules/mod_setenvif.so LoadModule mime_module modules/mod_mime.so LoadModule status_module modules/mod_status.so LoadModule info_module modules/mod_info.so LoadModule vhost_alias_module modules/mod_vhost_alias.so LoadModule dir_module modules/mod_dir.so LoadModule actions_module modules/mod_actions.so LoadModule alias_module modules/mod_alias.so LoadModule rewrite_module modules/mod_rewrite.so LoadModule wsgi_module modules/mod_wsgi.so With this configuration, Apache is able to create threads for two of my Django applications, but not for the third: [Wed Feb 03 11:23:32 2010] [alert] (12)Cannot allocate memory: mod_wsgi (pid=13314): Couldn't create reaper thread in daemon process 'djangoanke'. [Wed Feb 03 11:23:33 2010] [alert] (12)Cannot allocate memory: mod_wsgi (pid=13401): Couldn't create worker thread 5 in daemon process 'djangoanke'. [Wed Feb 03 11:23:39 2010] [alert] (12)Cannot allocate memory: mod_wsgi (pid=13429): Couldn't create worker thread 5 in daemon process 'djangoanke'. [Wed Feb 03 11:23:44 2010] [alert] (12)Cannot allocate memory: mod_wsgi (pid=13429): Couldn't create worker thread 7 in daemon process 'djangoanke'. [Wed Feb 03 11:23:49 2010] [alert] (12)Cannot allocate memory: mod_wsgi (pid=13429): Couldn't create worker thread 9 in daemon process 'djangoanke'. [Wed Feb 03 11:23:55 2010] [alert] (12)Cannot allocate memory: mod_wsgi (pid=13469): Couldn't create worker thread 5 in daemon process 'djangoanke'. [Wed Feb 03 11:24:01 2010] [alert] (12)Cannot allocate memory: mod_wsgi (pid=13517): Couldn't create worker thread 5 in daemon process 'djangoanke'. So it does look like a memory issue which affects the worker MPM more than the prefork MPM (with which I can run all three apps, although with frequent QoS alerts). Kind regards, Jan On Feb 2, 2:59 am, Graham Dumpleton <[email protected]> wrote: > On 31 January 2010 00:07, janedenone <[email protected]> wrote: > > > > > > > On Jan 30, 12:57 pm, Graham Dumpleton <[email protected]> > > wrote: > >> 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? > > > Apache/APR were provided with CentOS, mod_wsgi was compiled from > > source. > > >> 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. > > > Just did that: Switched to worker MPM and recompiled/installed > > mod_wsgi – same result. > > Can you provide output for: > > egrep -h '^ *LoadModule' /etc/httpd/conf/httpd.conf /etc/httpd/conf.d/*.conf > > I had no issue with switching to use worker MPM for precompiled mod_wsgi rpm. > > I wish to compare what other Apache modules you have loaded to basic > set as well as to what other person with CentOS issues is using. > > My CentOS installation is virgin install from 5.4 DVD with only > addition being mod_wsgi. > > 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.
