I was under the impresion that this is a bug in the way --idle is checking for
idleness. It should check if there are any requests running currently before
stopping all workers, right now it only checks if there was no new requests in
last --idle seconds.
Looking at the code I only see timestamp checks, so it seems that (if I'm
right) You should add check that iterates all workes and checks if any of them
is busy.

2012/9/6 Roberto De Ioris <[email protected]>:
>
> 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



-- 
Łukasz Mierzwa
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to