> On 31 Dec 2016, at 3:07 PM, Cristiano Coelho <[email protected]> wrote:
>
> Hello,
>
> So the configuration might not be ideal, but these small config tweaks
> shoun't be really the source of the issue right? It's a bit odd since I
> haven't had issues with similar deploys. This project I guess uses more
> libraries C extensions (lxml and postgres) and the background threads/pools
> perform a lot of IO (email sending, message queue polling, and some others),
> although they are all under daemon threads and should finish under the 4
> seconds grace time.
If you are using lxml then you definitely need to use:
WSGIApplicationGroup %{GLOBAL}
as from memory it is one of the libraries which is known to have issues when
used in Python sub interpreters. The problem will be if a callback function is
registered which lxml calls when parsing XML. Because it doesn’t deal with
thread locking properly when using a sub interpreter, it can deadlock its own
thread. Other threads can still run, but if other request threads do the same,
you can eventually exhaust all the request threads and the process hangs.
Background threads you create separately could still run though. Although even
if this occurs, it shouldn’t stop an Apache restart from killing the process.
> Would setting WSGIApplication Group %{GLOBAL} still allow me to use more than
> 1 process on the daemon configuration? Although I don't think it will do any
> change at all since the web servers only listen on port 80 and are on the
> same domain so all requests should always be falling into the same
> application group if I interpreted the docs correctly.
Application group is the Python interpreter context within each respective
process. The value %{GLOBAL} just means the main or first interpreter context
of the process. This is the same as if you had run command line Python and
behaves the same. Any additional interpreter contexts created in a process are
what are referred to as sub interpreter contexts. By default mod_wsgi uses a
separate sub interpreter context in each process for each WSGI application
delegated to run in the same set of processes.
So there is no restriction on setting ‘processes’ option of WSGIDaemonProcess
to be more than one at the same time as setting WSGIApplicationGroup to
%{GLOBAL}.
> This issue is so random and since only happens on cloud deploys it gets
> really difficult to test if a change helped or not and it can take days to
> notice it. I guess I will keep playing around with settings and try to gather
> more info of the stuck processes when it happens.
Which sounds even more like issue with sub interpreters. If the bit of code
which triggers the deadlock is infrequent, then the loss of request threads
could be slow. This is where newer mod_wsgi versions at least have various
timeout options for causing daemon process restarts when requests timeout or
block.
At the least, add:
WSGIApplicationGroup %{GLOBAL}
and see how it goes.
Graham
> Thank you so much for all the help!
>
> --
> 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]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/modwsgi
> <https://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
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 https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
