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: > 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 > > On 24 Oct 2020, at 9:11 pm, Johan De Taeye <[email protected]> wrote: > > 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 > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/7eb5a7e2-a18a-4559-8f7b-f942a4c0fe66n%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/7eb5a7e2-a18a-4559-8f7b-f942a4c0fe66n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/4fa43032-eeab-437e-aded-652333961a21n%40googlegroups.com.
