Cache für viel parallele IO optimieren

[nudgegoonies]

Hallo,
gibt es eine gute Anleitung wie man den Festplattencache für viel paralelle IO optimieren kann? Es handelt sich um einen CI Buildserver der hohe Last hat. RAM sieht gut aus. Dafür viel parallele IO. Bei der CPU sind alle Kerne am Anschlag.
Viele Grüße,
Andreas

[peschmae]

Ich habe derzeit gerade ein ähnliches Problem (auch mit einem CI-Server), der load geht schon mal gerne gegen 50...

Ich würde die Sache eher von der anderen Seite angehen: Versuchen nur so viele Prozesse aufs mal zu starten, dass die CPUs gerade gut ausgelastet sind, aber nicht so viele dass der Load ins unendliche steigt. Dann wird das Caching sicher effizienter, weil sich weniger Prozesse den Speicherplatz im Cache bzw. die Bandbreite streitig machen. Ich meine, bei hohem load hast du ja nur mehr Prozesse, die die Pages von den anderen Prozessen aus dem Cache rausmobben...

z.B. bietet ninja-build die Option neue parallele Prozesse nur zu starten wenn der load im System niedrig ist. Habe ich allerdings leider noch nicht ausprobieren können wie das insgesamt läuft, wegen eines cmake-bugs (0014553), verspreche mir aber recht viel davon.

MfG Peschmä

[nudgegoonies]

Danke Dir für Deine Antwort. Bezüglich IO sind für die Server schon SSDs geplant. Viele Entwickler haben ihre Workstation HD wegen der Buildzeiten schon getauscht.

Danke für den Tip mit der Load. Ich schaue bei unserer CI mal welche Optionen es alles gibt. Ich bin sowieso schon unzufrieden, wie die Jobs auf die Slaves verteilt werden wenn nicht alle Slots belegt sind. Da lässt sich sicher auch noch was machen. Aber häufig läuft halt alles auf Anschlag.

Viele Grüße!

[nudgegoonies]

Ich schreibe mal wie es aktuell aussieht. TMPFS sind für TMP und RUN aktiviert. NOATIME ist eh Standard. Die SSDs haben geholfen, Wenn nur ein Buildslot auf einem Slave aktiv ist dann ist ein Build 32 Minuten schnell, genauso schnell als wenn der Buildagent in einer Ramdisk läuft. Vorher waren es 49 Minuten. Wenn aber alle 3 Buildslots aktiv sind dann kommt man bestenfalls auf 43 Minuten, meistens dauerts aber ca. 50.

Bei Vollauslastung habe ich folgende Werte:
Die Load ist bei ca. 6 und IO-Wait bei 0.

Es werden logs rausgeschrieben aber generell zeigt IOTOP überhaupt kein Lesen an (ist wohl eh immer alles im Cache) und beim Schreiben sind es meistens 10 KB/s und alle 5 Sekunden ein kurzer Peak von 500 KB/s.

Die CPU Auslastung ist im Durchschnitt bei 70% auf allen 8 Cores (4 Cores Hyperthreading). Im Durchschnitt sind 2, maximal 4 auf Anschlag.

Von den 8 GB RAM werden ca. 5 GB benutzt, der Rest ist Buffers und Cache, geswappt wird überhaupt nicht.

Hat noch jemand Systemseitig Ideen oder muss ich mich jetzt um die JVM Parameter kümmern (CI-Agent, Maven-Build, alles nutzt Java und es laufen im Durchschnitt 8 JVMs gleichzeitig)?

Viele Grüße!

[peschmae]

Sprechen wir bei dir von Java oder von was anderem? Die 32 Minuten, was macht er da alles? Nur kompilieren, oder sind das vor allem die Tests?

Ich habe hier vor allem C++-Zeugs. Da ist die CPU-Auslastung beim Build auf jeden Fall praktisch 100% auf allen Cores (inkl. der Hyperthreading-Cores)... - und dann muss man halt viel Cachen (ccache) und überhaupt schon mal sich auf make verlassen.

MfG Peschmä

[nudgegoonies]

Ist alles Java und es laufen eine riesige Menge Tests. Ich hatte jetzt auch schon Network-Wait im Verdacht, aber weiß noch nicht, wie ich das überprüfen kann.

Viele Grüße!

[peschmae]

Java... - nicht gerade das womit ich mich derzeit befasse. Das einzige in Java hier ist der Jenkins, und der braucht für meinen Geschmack viel zu viel Arbeitsspeicher

Brauchst du denn wirklich 8 JVMs oder könnte es auch eine tun, die mehr multithreaded tests macht? Könnte mir vorstellen dass das jeweils einiges an Overhead mitbringt. Ausserdem gibts bei java ja die --server Option, wenn du ne JVM länger am laufen hast könnte das was bringen. Würde mal auf jeden Fall die Java-Seite etwas tunen

Netzwerk - eventuell hilft dir ntop oder iptraf weiter...

MfG Peschmä

[nudgegoonies]

Danke Dir für die Tips. iptraf habe ich mir schon angeschaut aber ntop kannte ich noch gar nicht.

Die vielen JVMs haben mit den CI Agents zu tun. Jeder CI Agent hat eine JVM und es laufen 3 pro Kiste. Dann baut jeder einen unterschiedlichen Branch oder den Master mit Maven also hat man grundsätzlich mindestens 6 die laufen bei Vollauslastung.

Ich habe schon diverse GC und LargePage Optionen für die JVM gefunden und auch -server werde ich mir anschauen.

Danke Dir und viele Grüße!

[Colttt]

hast du nen raidcontroller drunter?

evtl hilft es ein anderen scheduler zu nutzen:

Code: Alles auswählen

echo noop > /sys/block/hda/queue/scheduler
oder
echo deadline > /sys/block/hda/queue/scheduler

und wenn du eine USV hast oder du verschmerzen kannst es evtl Dateien beschädigt werden, hilft noch die mountoption barrier=0

[nudgegoonies]

Es liegt kein raidcontroller drunter und der scheduler ist schon deadline.

Eine USV kommt nicht zum Einsatz. Bei barrier=0 mache ich mir etwas Sorgen um die MySQL Datenbank. Die sollte schon konsistent bleiben. Wenn irgendewelche Dateien von einem Build beschädigt sind ist das kein Problem, den Build kann man ja wieder starten.

[Colttt]

hast du bei den tests denn noch ram übrig?
wenn ja könntest du dir ja ne RAM-Disk machen udn die dateien dort verschieben

[nudgegoonies]

Ob Du es glaubst oder nicht, dass habe ich schon probiert und bis auf ein paar Sekunden keinen Unterschied zwischen SSD und Ramdisk festgestellt. Außerdem würde es dann mit dem RAM doch knapp werden, weil ich für jedes CI Agent workdir mindestens 1,5 GB RAM brauche.

[peschmae]

Ist jetzt auch nicht weiter gross überraschend, dass eine Ramdisk nicht viel bringt. Wird ja eh auch sonst alles im Ram gecached...

MfG Peschmä

[Colttt]

zt auch nicht weiter gross überraschend, dass eine Ramdisk nicht viel bringt. Wird ja eh auch sonst alles im Ram gecached...

wenn das stimmt und es immer noch so lange dauert dann liegts aber nicht an der I/O-Performance sondern eher an der CPU, oder?

[nudgegoonies]

[...]dann liegts aber nicht an der I/O-Performance sondern eher an der CPU, oder?

Die ist aber zu 30% (aggregiert über alle Kerne) idle.

[Colttt]

Gut, dann dauerte eben einfach so lange.. Was sagt denn top wenn das ganze läuft?

[nudgegoonies]

Da sind bei Vollast 2 bis 4 Kerne auf 100 % und die anderen schwanken zwischen 50 % und 75 % wobei ich nicht so genau weiß, wie aussagekräftig dies bei Hyperthreading wirklich ist.

[Milbret]

Die Frage wäre auch was die Software eigentlich macht?
Es kann ja sein, dass selbst Multithreading hier an der ein oder anderen Stelle ausgebremst wird.
Wenn z.B. Threads auf Shared Resources zugreifen, werden die Threads durch locks ausgebremst.
Die CPU kann im schlimmsten Fall also nie zu 100% ausgelastet sein.

Da wir aber nichts über die Kompilierungs- und Testdauer wissen und auch nicht wissen was intern alles passiert, kann man hier nur vermuten, dass eben an einigen Stellen durch locks zu Wartezeiten kommt.
Dann kann es aber auch nicht schneller gehen.
Bzw. wurde mal geprüft was lange dauert?
Also Kompilierung, Tests etc.?

Wenn es z.B. beim Testen lange dauert, hat man den Falschenhals gefunden.
Gibt es hier z.B. Timer wie lange einzelne Tests laufen?

Nachtrag:
Gibt es vielleicht auch ein Log was Informationen über den gesamten Prozess der Kompilierung und Tests ausgibt?
Somit könnte man ebenfalls einen Weg finden, den Engpass zu finden.

Martin

[nudgegoonies]

Hi Martin!

Die Frage wäre auch was die Software eigentlich macht?

Da unsere Software keine OSS ist kann ich nichts an Details, Logs, etc. auf NoPaste packen.

In der Tat laufen tausende von Tests, auch Integrationstest, die auf externe Systeme zugreifen. Es ist aber unwahrscheinlich, dass die bei parallelen Zugriffen, die ja auch nicht völlig zeitgleich sind, einknicken. Die Netzwerklast ist auch nicht hoch.

Es kann ja sein, dass selbst Multithreading hier an der ein oder anderen Stelle ausgebremst wird.
Wenn z.B. Threads auf Shared Resources zugreifen, werden die Threads durch locks ausgebremst.
Die CPU kann im schlimmsten Fall also nie zu 100% ausgelastet sein.

Die tests selbst sind auch parallelisiert. Vielleicht ist es dann einfach zu viel mit der Parallelisierung, wenn drei Agents pro Rechner 3 Mavenbuilds gleichzeitig ausführen wovon jeder wieder parallelisierte Tests ausführt.

Deine weiteren Fragen bezüglich des Testlogs gehe ich gerade an indem ich das Log mal analysiere, ob ich zeitlich dort was finde im Vergleich zu einem alleine laufenden Build.
Vielen Dank für Deine Hilfe!

[Milbret]

Theoretisch ist es möglich, dass ihr zu viele Threads habt.
Den wenn ihr alle Tests parallel laufen lasst und jeden davon in einem Thread dann ist dies ein möglicher Flaschenhals.
Den dann muss die CPU die ganze Zeit zwischen den Threads hin und her springen und kann im schlimmsten Fall nie zu 100% ausgelastet werden.
Oder arbeitet ihr bei euren Tests z.B. mit dem ExecutorService von Java anstelle eigener Threads?

Dann wäre das weniger ein Problem, da dort dann alles über den Threadpool abgehandelt wird.
Hier bräuchte man aber mehr Details zu den Tests.
Auch was dort ungefähr gemacht wird.
Erst dann kann man ggf. prüfen ob es bei den externen Systemen hängt.

Oder konntest du durch angepassstes Logging was finden?

Martin

[nudgegoonies]

Hi Martin,
vielen Dank für Deine Antwort. Von der Umgebung her haben wir umgestellt und nun einen Rechner mehr. Es laufen nur noch 2 Agents pro Rechner statt 3, bei gleicher bis minimal höherer CPU Auslastung wie mit 3, aber um ca. 10 Minuten kürzeren Buildzeiten

Zu den Tests selber, wir setzen den ExecutorService für Tests ein.

Ich bleibe dran. Aber im Moment haben andere Sachen Priorität. Darum auch die späte Antwort.
Viele Grüße!

[Milbret]

Gibt es zu den Kisten eigentlich auch eine Spezifikation?
Also welche Hardware jeweils vorhanden ist.

Vielleicht würde es auch helfen anstelle von x Rechnern lieber einen richtig dicken zu nehmen.
Das würde die Build und Testzeiten auch nochmal enorm drücken.

Ansonsten könnte man ja mal ein Benchmark machen wie lange die einzelnen Tests dauern.
Vielleicht gibt es hier noch einige Flaschenhälse die man optimieren kann.

Kannst dich melden sobald das Thema wieder wichtig wird )
Vielleicht finde ich den Thread dann sogar noch.

Martin

[nudgegoonies]

Das mit der "dicken" Maschine wird schwierig zu testen, dafür müsste man erst mal eine bekommen was ein komplizierter Prozess ist.

Hoffen wir mal, dass es nicht zu lange dauert, bis ich wieder was zu melden habe

Viele Grüße!