Il giorno 06/set/2012, alle ore 09:48, Marcin Deranek <[email protected]> ha scritto:
> Hi, > > Recently I've been playing with cheap mode and idle timeout (uwsgi > 1.2.3). The way I would expect it to work would be that idle workers > are cheaped after <idle> seconds of inactivity (if idle timeout was > specified). > This seems to be not the case ATM. Is this expected behaviour ? > It's even worse: if request takes more than <idle> seconds worker gets > cheaped before request gets completed (stats server indicates worker as > busy just before it gets cheaped) eg. > > uwsgi --http-socket :5000 --remap-modifier 5:0 -M --cheaper 1 --idle 20 > --stats /tmp/stats.sock -p 4 --psgi test.psgi > > PSGI app 0 (/tmp/test.psgi) loaded in 0 seconds at 0xb473db0 (interpreter > 0xb2ea7d0) > *** uWSGI is running in multiple interpreter mode *** > spawned uWSGI master process (pid: 4570) > spawned uWSGI worker 1 (pid: 4571, cores: 1) > *** Stats server enabled on /tmp/stats.sock fd: 15 *** > spawned uWSGI worker 2 (pid: 4951, cores: 1) > workers have been inactive for more than 20 seconds (1346916693-1346916672) > cheap mode enabled: waiting for socket connection... > > After issuing request worker 1 is "busy" and worker 2 is "idle". After 20s > all workers are cheaped. > This seems to be the problem with idle option as having this: > > uwsgi --http-socket :5000 --remap-modifier 5:0 -M --idle 20 > --stats /tmp/stats.sock -p 2 --psgi /tmp/test.psgi > > produces the very same result. Initially both workers get "idle" status. > Request comes and one of them becomes "busy". After 20s both get cheaped. > Regards, > --cheaper is different from --cheap, and the 'standard' way is combining --cheap and --idle, while --cheaper expect its algorithm to get rid of idle workers. (so --cheaper + --idle is a bit messy as they overlap) --idle <n> simply destroy ALL of the workers while the whole instance is inactive. This is normally higher than the harakiri value to avoid instances to be killed while a request is running (but that should be avoidable in the new infrastructure where teh master has access to the whole cores memory). If you want to kill single workers after inactivity, just use the --cheaper option and tune it for your specific needs (via --cheaper-step and --cheaper-overload) Interesting topics (even if mainly 1.3-related) about 'adaptive process spawning' http://projects.unbit.it/uwsgi/ticket/83 http://projects.unbit.it/uwsgi/ticket/150 -- Roberto De Ioris http://unbit.it JID: [email protected] _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
