Hi,
da dürften die Optionen RandomizedDelaySec und eventuell FixedRandomDelay helfen. Damit wird der Timer um eine zufällige Zeit verschoben und die Hosts verteilen sich. Mit FixedRandomDelay bleibt dabei das Intervall trotzdem konstant.
RandomizedDelaySec=
Delay the timer by a randomly selected, evenly distributed amount of time between 0 and the specified time value. Defaults to 0, indicating that no randomized delay shall be applied. Each timer unit will determine this
delay randomly before each iteration, and the delay will simply be added on top of the next determined elapsing time, unless modified with FixedRandomDelay=, see below.
This setting is useful to stretch dispatching of similarly configured timer events over a certain time interval, to prevent them from firing all at the same time, possibly resulting in resource congestion.
Note the relation to AccuracySec= above: the latter allows the service manager to coalesce timer events within a specified time range in order to minimize wakeups, while this setting does the opposite: it stretches timer
events over an interval, to make it unlikely that they fire simultaneously. If RandomizedDelaySec= and AccuracySec= are used in conjunction, first the randomized delay is added, and then the result is possibly further
shifted to coalesce it with other timer events happening on the system. As mentioned above AccuracySec= defaults to 1 minute and RandomizedDelaySec= to 0, thus encouraging coalescing of timer events. In order to optimally
stretch timer events over a certain range of time, set AccuracySec=1us and RandomizedDelaySec= to some higher value.
