The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,769 other followers

Scheduled jobs and jitter…

Posted by jpluimers on 2019/05/23

Too bad G+ doesn’t allow the WayBack machine or Archive.is to archive the whole thread at [WayBack] [Archive.isDas es inzwischen fast überall Standard ist die Uhren mit einem guten Zeitsignal zu synchronisiseren (NTP, DCF-77, GPS etc) ist eigentlich eine gute Sache… – Kristian Köhntopp – Google+ so here are a few quotes below.

The generatel conclusions seem to be that:

This was the start:
Nils Ketelsen originally shared:

Guckt man live sieht es schon anders aus: Während die RunQueue meist so bei 4-5 liegt (bei 21vCPUs kein Problem) springt sie jede volle Minute einige Sekunden lang auf 20. Bei durch 2 Teilbaren Minuten auf ca. 40. Bei durch 10 Teilbaren Minuten auf 70, bei durch 15 teilbaren Minuten auf 150…. Ich habe eben durch einen schlecht getimten Toilettenbesuch die volle Stunde verpasst, das muss ich gleich mal anders hinbekommen, aber ich gehe davon aus, daß es da noch schlimmer ist.

And these some of the comments:

Lars Marowsky-Brée:

That is why good schedulers do implement jitter.

Harald Wagener (oliof):

+Daniel Kerkow mit 35k Hosts, die alle einmal die Stunde anklopfen, aber bei Installation einmal einen zufälligrn Offset von 0 bis zu 59 Minuten setzen, war eine Gleichverteilung erzielbar.

Lars Marowsky-Brée:

+Daniel Kerkow Monte Carlo Methoden sind jetzt mathematisch und statistisch nichts neues. Macht nur keiner. Müsste man ja was zu lesen.

Kristian Köhntopp:

Den Jitter sollst Du im Cron machen, nicht in der Systemzeit

Elias Probst:

systemd timer units supporten RandomizedDelaySec=

Roland Tapken:

Meine Saltstack-Clients lösen sowas, indem die CRC der Node-ID Mod 60 für die Minute verwendet wird. Das verteilt sich ganz gut…

+Kristian Köhntopp Sinnvoller wäre die Ergänzung der Cron-Syntax um einen parametrisierbaren Jitter a la “*/15(2)”.

+Roland Tapken SaltStack hat da fürs Job-Scheduling builtin den splay Parameter https://docs.saltstack.com/en/latest/ref/states/all/salt.states.schedule.html

Sascha Schneider:

Bei manchen Anwendungen gibt es entsprechende cron-scripts oder Parameter die den jitter selbst hinzufügen, wie portsnap:-

“Commands:
fetch — Fetch a compressed snapshot of the ports tree,
or update an existing snapshot.
cron — Sleep rand(3600) seconds, and then fetch updates.”

Aber ja, ich stimme +Martin Seeger zu, das sinnvollste wäre dem cron das jittern beizubringen, bevor sich jeder selbst die Arbeit macht das zu implementieren

Kristian Köhntopp:

+Martin Seeger Der Jitter muß Default sein. */15 ist viermal die Stunde, irgendwann. */15! oder 0,15,30,45 für glatte Viertel

Sebastian Nohn:

https://www.freebsd.org/cgi/man.cgi?cron(8)

+Sascha Schneider den Abstand konstant halten heißt bei verteilten Systemen idealerweise die Wiederholfrequenz durch Anzahl Knoten teilen. Das müsste bei hinzufügen oder wegnehmen der Knoten immer wieder synchronisiert werden, und irgendwann landen wir bei consistent hashing oder ähnlichem Kram.

Da ist zufällig einfacher und wird es auch tun.

Wahrscheinlich ist die beste Implementierung aber etwas anders als +Kristian Köhntopp sagt gar nicht daß */15 gleichbedeutend mit 4x die Stunde ist, sondern der Abstand zwischen zwei Läufen 15 – 1/2 max jitter + random jitter, also daß nur im Durchschnitt etwa 4x die Stunde eingehalten wird,und manchmal etwas früher, manchmal etwas später getriggert wird.

Hat auch Nachteile, ist aber sowohl einfach wie auch statistisch das gleiche wie fest zur Viertelstunde.

Michael Grandjean:

Also UCS (das aus Bremen, nicht das von Cisco) hat das hier an Bord:

/usr/sbin/jitter

jitter <seconds> <command> [<command-options>]

sleeps for random time between 0 and <seconds> before exec of <command> with given <command-options>

Das wird bei so ziemlich allen Cronjobs, die das System von Haus aus mitbringt und die andere UCS Kisten was fragen, vor den eigentlichen Command gesetzt – genau aus dem oben genannten Grund.

Ich Find die Implementierungsidee von +Kristian Köhntopp super.
wenn ich */15 Minuten schreibe, ist mein MaxJitter 15min – wenn ich * Tage schreibe, dann ist mein Jitter 24h. Das Wiederholungsintervall bestimmt den Spread.
Und wenn ich den genauen Zeitpunkt unbedingt brauche, dann schreib ich ein ! dahinter.

Rainer Sokoll:

FreeBSD:

SYNOPSIS
cron [-j jitter] [-J rootjitter] [-m mailto] [-s] [-o] [-x debugflag[,...]]

Michael Dix (Eisberg):

Und mich belächeln die Kollegen immer, weil meine Tasks um 09:01Uhr laufen…

Also unsere Poller für das Message-Handling bekommen einen random initial delay und ein fixed delay als sleep time. Da der Lauf grundsätzlich eine zufällige Dauer hat, bekommt man kaum oszilierende Systeme. Ich mag keine crontab gesteuerten Systeme, so lange man nicht an natürliche Zeitpunkte takten will (Mitternacht, Wochenende, neues Jahr usw).

+Stefan Fendt den Zwang zu sehen, feste Zeitpunkte für Jobs zu haben, deren Aufrufe periodisch sind, zeigen häufig eine fehlende Robustheit auf.

Ich führe ständig die Diskussion, dass es a) den Entwicklern oder b) dem Support angeblich helfen würde, wenn die Ausführungszeit determistisch sei. Das ist ein Trugschluss. Denn vom Support wird fast Voodoo betrieben, um beste Perioden zu ermitteln, die dann über den Haufen geworfen werden, wenn eine Komponente hinzugefügt wird. Der Entwickler denkt in den Constraints der Takte und nicht in der Businesslösung und schiebt Timingprobleme auf falsche Konfigurationen, anstatt die Aufgabe robust gegen asynchrone Ausführung zu machen. Eigentlich das Grundwerkzeug bei der Entwicklung von Services.

Ingo Oeser:

Hatte mir für solche Fälle mal einen wrapper für meine cron jobs geschrieben: github.com

–jeroen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: