> On 6 Oct 2015, at 6:32 pm, 'Lukasz Szajkowski' via modwsgi
> <[email protected]> wrote:
>
> Deadlock shows that application hangs trying to load modules (from django or
> built-in etc.). Normally it should be done only once at start-up, but in our
> case it's after many requests (Why). So possible explanations:
> * python process/interpreter is killed/restarted from outside (e.g. by
> logrotate) and starts to import modules again
>
> * internal mod_wsgi monitor thread kills and restarts python
> (https://github.com/GrahamDumpleton/mod_wsgi/blob/3.4/mod_wsgi.c#L11157
> <https://github.com/GrahamDumpleton/mod_wsgi/blob/3.4/mod_wsgi.c#L11157>)
>
Both of the above would result in a completely new process being created. There
shouldn’t be any case where Python is reinitialised in the same process.
For a process restart wouldn’t be so concerned.
> * lazy load of application leads to late imports - added options to
> mod_wsgi to force early application load (default it lazy load)
>
This could definitely be an issue, especially if imports are done from within
functions rather than global scope.
Lets try another things just to make sure that everything Python is at least
happening in daemon processes as it should.
For this, ensure that you are setting:
WSGIRestrictedEmbedded On
This will ensure that Python isn’t being initialised inside any Apache child
worker processes. If for some reason configuration was getting applied wrongly
and request ran in child worker process rather than daemon processes, this
would come up as an error with that setting.
The other thing one can do to be absolutely certain things running in right sub
interpreter context, is that instead of doing:
WSGIDaemonProcess xxx
WSGIProcessGroup xxx
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /some/path/app.wsgi
use:
WSGIDaemonProcess xxx
WSGIScriptAlias / /some/path/app.wsgi process-group=xxx
application-group=%{GLOBAL}
This will ensure everything runs in main interpreter context of daemon process
‘xxx’ and not subject to Apache context matching rules to ensure that
WSGIProcessGroup/WSGIApplicationGroup are applied correctly.
Use of the process-group and application-group options together on
WSGIScriptAlias will also have the side effect of preloading the WSGI script
file on process start rather than lazily on first request.
This only applies to the WSGI script file itself and direct module imports.
Django itself will lazily load view handlers for URLs still and so code for
those can still be lazily loaded.
The only away around that is as a side effect of loading WSGI script, use
WebTest or something to fake requests into the Django application instance for
certain key URLs to force it to load code then.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
