Grenzwerte für neue cmsearch Aufgaben gesucht

[ChristianB]

Hallo,

es steht ein neuer Schwung Aufgaben für cmsearch in den Startlöchern. Diese Batch besteht zum Großteil aus Kurzläufern mit ein paar Ausreißern im 6-8 Stunden Bereich und nur 3 mit einer geschätzten Laufzeit über 12h. Wir haben jetzt die Erzeugung von Aufgaben umstrukturiert und können jetzt anhand der Vorhersage die Aufgaben an die jeweilige App (S, XXL, VM) verteilen. Die Frage ist nur nach welchen Grenzwerten machen wir das. Hier mal mein Vorschlag den ich zur Diskussion stellen möchte:

• cmsearch S: Gesamtlaufzeit bis zu 12 Stunden aber Einzellaufzeit unter 4 Stunden (damit hätten wir ein simples Checkpointing für S)
• cmsearch XXL: mehr als 4 und weniger als 48 Stunden Gesamtlaufzeit und nur ein cmsearch Aufruf
• cmsearch VM: alles über 48 Stunden Laufzeit (nur ein Aufruf)

Die Besonderheit bei S ist das mehrere cmsearch Aufrufe gebündelt werden bis entweder 1000 erreicht sind oder die 12h erreicht sind.

Die Verluste bei einem Absturz oder Reset der Workunit sind somit für S und XXL überschaubar. Diese Grenzwerte sind anpassbar und stehen hiermit zur Diskussion. Wollt Ihr also kürzere S, XXL oder längere XXL oder ...?

[Stiwi]

• cmsearch S: Gesamtlaufzeit bis zu 12 Stunden aber Einzellaufzeit unter 4 Stunden (damit hätten wir ein simples Checkpointing für S)
• cmsearch XXL: mehr als 4 und weniger als 48 Stunden Gesamtlaufzeit und nur ein cmsearch Aufruf
• cmsearch VM: alles über 48 Stunden Laufzeit (nur ein Aufruf)

Die Besonderheit bei S ist das mehrere cmsearch Aufrufe gebündelt werden bis entweder 1000 erreicht sind oder die 12h erreicht sind.

Die Verluste bei einem Absturz oder Reset der Workunit sind somit für S und XXL überschaubar. Diese Grenzwerte sind anpassbar und stehen hiermit zur Diskussion. Wollt Ihr also kürzere S, XXL oder längere XXL oder ...?

klingt gut^^

[Norman]

+1

[Dunuin]

Finde ich auch ok, aber die Namen passend dann nicht mehr so. Das XXL ist dann eigentlich nur noch ein L, weil die VM zum XXL wurde.

[Norman]

oder ein M für medium gebraten

[nico]

Könnte man die Einzelnen S unter 2h bringen oder wird es dann zuviel in XXL?

[ChristianB]

Könnte man die Einzelnen S unter 2h bringen oder wird es dann zuviel in XXL?

Für die jetzige Batch ist das egal weil sowieso sehr viele S erzeugt werden. Verringert man die Laufzeit pro Job werden halt nur mehrere Jobs erzeugt. Ich werde morgen mal eine genauere Analyse (Häufigkeitsverteilung) der Batch anfertigen und ein paar Grafiken hochladen. Was man aber auch beachten muss ist das wenn die S zu klein werden steigt die Last für den Server. Auch ist der Pool an Rechnern die XXL erlauben recht klein.

[Michael H.W. Weber]

Hinweis: In den S stecken oft auch WUs von nur wenigen Minuten Laufzeit drin (es gibt sogar welche unter 1 Min.). Diese einzeln auszugeben, zwingt bei unseren Mengen jeden Server früher oder später in die Knie. Wir haben das ausprobiert und diese Erkenntnis war der Grund für das Verpacken vieler kleiner WUs in Pakten mit dem Namen S. Die im Manager angegebene Gesamtlaufzeit ist also NICHT notwendigerweise identisch mit der Laufzeit einer WU. Wenn man bei S WUs den Rechner einfach abstellt, dann wird das Paket erneut mit der zuletzt in Berechnung befindlichen WU gestartet - das bezeichnen wir als "pseudo-Checkpointing".

Christian hat es oben schon angedeutet - dies nur nochmal zur etwas detaillierteren Erklärung.

Wir müssen also mmer den Kompomiss suchen zwischen möglichst kurzen WUs, möglichst viel Checkpointing und der Sicherstellung, dass der Server nicht einbricht.
Die VM WUs sollte man nach meiner Meinung eigentlich für alle längeren WUs ausgeben. Dort ist dann aber das Problem zu beachten, dass die VM WUs ziemlich viel Material senden und ohne Ende Platz auf der Platte einnehmen. Es ist dann also die Frage, für welche Laufzeit man sich das generell geben möchte.

Das der VM-Ansatz auch etwas Performance kostet ist bekannt. Allerdings laufen unsere Clients in der VM immer unter Linux, während auf Windowsrechnern die Windows Kompilate verwendet werden, die weniger performant sind. Ich wage jetzt nicht zu behaupten, dass sich das also ausgleichen würde, dazu müßten wir das im Detail vermessen. Trotzdem bitte mal im Kopf behalten...

Ich würde unterm Strich Christians Vorschlag übernehmen mit der Änderung, dass XXL namentlich durch L ersetzt wird.

Michael.

[Tom_unoduetre]

Moin,

mein persönlicher Wunsch

cmsearch S: Gesamtlaufzeit bis zu 12 Stunden aber Einzellaufzeit unter 1 Stunden
cmsearch VM: alles über 12 Stunden Laufzeit (nur ein Aufruf)

Aus persönlicher Sicht wäre es schön die Einzellaufzeiten der S WUs auf 1 Stunde zu verringern, oder wäre das zu stressig für den Server? (Ich bin ein Checkpoint Freak, jede verschwendete Minute an Rechenzeit tut mir immer weh... ich bin da aber auch sehr empflindlich glaube ich)

Gibt es Überlegungen die XXL (oder dann L) komplett durch die VM WUs zu ersetzen, so daß am Ende nur S und VM übrig bleiben? Oder wollt Ihr XXL behalten für Leute die kein checkpointing brauchen und sich aber auch keine VM installieren wollen bzw. wegen des von Michael angedeuteten Overhead Problems bei VM?

[Michael H.W. Weber]

Ja, die XXL werden demnächst in den VMs abgearbeitet bzw. als L bezeichnet - die genauen Laufzeitgrenzen probieren wir gerade sinnvoll neu festzulegen.

Ich bin der Ansicht, dass wir generell eher auf etwas Performance zu Gunsten eines Checkpointings verzichten können, denn unsere Tasks liegen jenseits von allem, was die anderen Projekte so an Anforderungen haben. Abstürze wirken sich nämlich auch auf die Gesamtperformance aus.

Michael.

[ChristianB]

Im englischen Thread kam gerade folgender Vorschlag:

S: Gesamtlaufzeit bis zu 4 Stunden, Einzellaufzeit unter 4 Stunden
L: Einzellaufzeit über 4 aber unter 48 Stunden
VM: alles über 48 Stunden

[Michael H.W. Weber]

Ich habe den "thread" gelesen und stimme darin überein, das der Endbenutzer gerne so kurze Tasks haben will, wie möglich. Das Bündeln der WUs hatten wir aus der Not heraus installiert, dass der Server bei WUs von oft nur wenigen Sekunden (Viren mit unkomplizierten RNA Molekülen) in die Knie ging. Die Frage ist: Ab welcher minimalen Laufzeit würde dieses "in die Knie gehen" weiter kritisch sein. 20 Min? Mehr?
Es wäre zu überlegen, ob man einen Sonderstatus "packed" einführt, der klar WUs ausweist, die als Paket mehrere Einzelaufgaben extrem kurzer Laufzeit beinhalten.
Man würde dann als S zukünftig etwas anderes ausgeben, nämlich welche verpacken, die nur eine Aufgabe enthalten - also nicht pseudo-checkpointen - aber eben dennoch kurz laufen.
Dagegen spräche, dass man dafür wieder eine neue App definieren muss. Daher möchte ich euch als Admis überlassen, ob dieser Mehraufwand gerechtfertigt sein könnte. Der Vorteil wäre, dass man den Nutzern mehr Entscheidnungsspielraum darüber gibt, was sie an Arbeit bekommen und wie hoch das Verlustrisiko ist.

Also:

P(acked: pseudo-checkpointed): 0-4 Std.
S(hort: non-checkpointed): Serverminimallaufzeitanforderung (30 Min.?)-8 Std.
L(ong: non-checkpointed): 8-48 Std.
VM (virtual machine: checkpointed): >48 Std.

Ich denke momentan auch etwas über die Zukunft nach in der wir sehr kleine WUs an Smartphones ausgeben könnten. Die Viren wären dafür ideal. Auf dem Cortex-A8 Monocore des BeagleBoard xM hatte ich einen Faktor von ca. 20 bezügl. Laufzeitverlängerung ermittelt (nicht statistisch signifikant - weitere Benchmarks würde ich aber noch nachholen). Also würde eine einminütige Viren-WU dort 20 Min laufen. Das nur schon mal so als Vorgeschmack...
Die "packed" könnten auch dann weiterhin als Option für die x32/x64 Maschinen existieren.

Also zukünftig zusätzlich noch:

M(obile: non-checkpointed): <1 Std.

Michael.