You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
processes=1: I can't see any reason to use multiple processes when we have threads enabled. Using two processes eats twice as much memory and ensures that some state is not shared between processes (e.g. cached Site objects) which requires a manual restart of Apache.
maximum-requests=400 ensures that the WSGI daemon process is recycled regularly, freeing up any memory that it may have leaked.
display-name='%{GROUP}' allows us to identify the WSGI process(es) in the process list, differentiating them from normal Apache processes. They will appear as (wsgi:<project_name>) instead of /usr/sbin/httpd.
deadlock-timeout=30 enables the detection and breaking of deadlocks caused by extensions starting a long-running operation in native C code without releasing the Python GIL lock. Otherwise these will hang the whole WSGI process for a long time, perhaps forever.
WSGIApplicationGroup %{GLOBAL} causes all Python code to run in the first Python interpreter instead of a sub-interpreter, avoiding a deadlock with native extensions.
We are currently using this mod_wsgi configuration as the default for new projects:
I think we should be using this instead:
Rationale for the changes:
processes=1
: I can't see any reason to use multiple processes when we have threads enabled. Using two processes eats twice as much memory and ensures that some state is not shared between processes (e.g. cached Site objects) which requires a manual restart of Apache.maximum-requests=400
ensures that the WSGI daemon process is recycled regularly, freeing up any memory that it may have leaked.display-name='%{GROUP}'
allows us to identify the WSGI process(es) in the process list, differentiating them from normal Apache processes. They will appear as(wsgi:<project_name>)
instead of/usr/sbin/httpd
.deadlock-timeout=30
enables the detection and breaking of deadlocks caused by extensions starting a long-running operation in native C code without releasing the Python GIL lock. Otherwise these will hang the whole WSGI process for a long time, perhaps forever.WSGIApplicationGroup %{GLOBAL}
causes all Python code to run in the first Python interpreter instead of a sub-interpreter, avoiding a deadlock with native extensions.References for these recommendations:
The text was updated successfully, but these errors were encountered: