[Piuparts-devel] _throttle_if_overloaded stability

[Dave Steele]

On Sun, Feb 24, 2013 at 9:56 PM, Andreas Beckmann <anbe at debian.org> wrote:
> On 2013-02-25 02:45, Dave Steele wrote:
>> This has the potential to oscillate in the presence of multiple
>
> possible, but I see no solution without having the slaves communicate
> with each other (or have a single but multithreaded slave)
> and maybe I have seen such cases
> but usually for a longer high-load period one slave seems to go on a
> longer pause

It should be possible to have a fairly stable setup without having the
slaves communicate.

>
>> slaves. I'd recommend reducing the secs range to under the loadavg
>> time constant (say to 30-60 seconds, 15 to 45 would be better), and
>> skipping the delay accumulation.
>
> wouldn't that make the situation worse? as many more slaves will hit the
> short time slot where load is low enough for resume
>

So if the load is low because of all of the now-paused slaves, they
will start to kick back in earlier due to the higher checking rate,
before the avg slowly sinks even lower. That is a good thing.

All other things being equal, increasing the sampling rate will add
stability, up to the Nyquist rate (about 30 seconds here).

Also, the -1 in the load_resume calculation is adding to any
instability there is (i.e. it takes a thundering herd of slaves to
bring the average from the lower load_reserve back up to load_max).