Daemon processes not stopping after inactivity period

[Johan De Taeye]

Hi,

We use mod_wsgi to serve multiple apps in virtual hosts with separate daemon processes. All is working very well and very stable.

I notice however that the daemon process are not shut down after the inactivity-timeout. They simply run forever, which wastes resources on the machine as many of these apps are used only very infrequently.

Anything I misconfigured or misunderstood on the behavior of the inactivity timeout?

This is on ubuntu 18 with mod_wsgi 4.5.

My apache configuration file looks roughly like this:

<VirtualHost *:443>

ServerName ENV1.frepple.com

WSGIDaemonProcess ENV1 user=www-data processes=4 threads=4 inactivity-timeout=7200 request-timeout=3600 display-name=apache-env1

WSGIProcessGroup ENV1 

WSGIScriptAlias / "/home/ubuntu/config/env1/wsgi.py"

...

</VirtualHost>

<VirtualHost *:443>

ServerName ENV2.frepple.com

WSGIDaemonProcess ENV2 user=www-data processes=4 threads=4 inactivity-timeout=7200 request-timeout=3600 display-name=apache-env2

WSGIProcessGroup ENV2 

WSGIScriptAlias / "/home/ubuntu/config/env2/wsgi.py"

...

</VirtualHost>

Stay safe, 

Johan

[Graham Dumpleton]

From the documentation:

inactivity-timeout=sss

Defines the maximum number of seconds allowed to pass before the daemon process is shutdown and restarted when the daemon process has entered an idle state. For the purposes of this option, being idle means there are no currently active requests and no new requests are being received.

This option exists to allow infrequently used applications running in a daemon process to be restarted, thus allowing memory being used to be reclaimed, with process size dropping back to the initial startup size before any application had been loaded or requests processed.

Note that after any restart of the WSGI application process, the WSGI application will need to be reloaded. This can mean that the first request received by a process after the process was restarted can be slower. If you WSGI application has a very high startup cost on CPU and time, it may not be a good idea to use the option.

See also the request-timeout option for forcing a process restart when requests block for a specified period of time.

Note that similar functionality to that of the request-timeout option, for forcing a restart when requests blocked, was part of what was implemented by the inactivity-timeout option. The request timeout was broken out into a separate feature in version 4.1.0 of mod_wsgi.

In other words, it is not intended to shutdown the process and only restart it when a new request arrives.

It stops it so as to potentially reclaim memory if your process has a large memory footprint once it has been run a while, or it has a memory leak. The process will though be restarted again immediately.

That said, with the configuration you have, since you don't have pre-loading of the application set up, the new process size will be much smaller and should stay small until the next request arrives and then your application is loaded.

If you are wanting to reclaim some memory, and since you are using daemon mode, ensure you have the following directive set somewhere outside of all VirtualHost definition.:

    WSGIRestrictEmbedded On

There are possibly further settings you can tweak to reduce overall memory usage depending on which server MPM you are using and whether you are only using this Apache instance for running Python applications using mod_wsgi.

Also, if there are used infrequently, do you really need to have 4 processes for each daemon process group then. A capacity of 16 request threads can handle quite a lot of requests/sec depending on how long you requests take to run.

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 modwsgi+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/7eb5a7e2-a18a-4559-8f7b-f942a4c0fe66n%40googlegroups.com.

[Johan De Taeye]

Thanks for the quick and clear explanation. 

I misunderstood and should have read the documentation better.

Johan

Op zaterdag 24 oktober 2020 om 22:54:16 UTC+2 schreef Graham Dumpleton: