opsiconfd CPU load

[bademeister]

Ich probiere es trotzdem mal.
Beim Supportvertrag habe ich wie leider wie manch ein anderer das Problem der Freigabe beim Chef.
Wir sind aber stolzer Kunde von UEFI und OLI.

Hier mal ein Auszug den ich gerade erstellt habe und erneut mit 23 Clients gleichzeitig einen on_demand gemacht habe.
Einziges Product auf "setup" war der shutdownwanted.

Ich kann mit meinem ungeschulten Auge leider keinerlei Auffälligkeit sehen. Ich habe vor 2 Tagen den RAM vom opsi-Server auch auf min. 4 max 8GB gehoben.
https://nextcloud.isw.uni-stuttgart.de/ ... RC7syY5tdW

Besten Dank.
Viele Grüße,
Felix

EDIT: Mal aus Interesse: Das Kontingent bei einem Supportvertrag (bspw. 1h pro Monat) sammelt sich nicht an, oder? Also bei nicht benötigtem Support habe ich dann nach 2 Monaten 2h auf dem Konto?

[n.wenselowski]

Hi Felix,

EDIT: Mal aus Interesse: Das Kontingent bei einem Supportvertrag (bspw. 1h pro Monat) sammelt sich nicht an, oder? Also bei nicht benötigtem Support habe ich dann nach 2 Monaten 2h auf dem Konto?

Das Kontingent gilt für den gewählten Zeitraum und sammelt sich nicht an.
Bei 1h im Monat hast du für Monat 1 eine Stunde Zeit und für Monat 2 auch eine Stunde.
Braucht es in Monat 1 mehr als 1h im Monat, dann wird das entsprechend Vertrag abgerechnet. In Monat 2 gibt es wieder 1h.

Warum dieses Vorgehen? Alle Zeit die nicht für den Support aufgewendet wird, wird in die Weiterentwicklung von opsi gesteckt. Die persönlichen Stunden "verfallen", landen aber wiederum in opsi.


Gruß

Niko

[bademeister]

Ich habe jetzt nochmal ein wenig nachgeforscht.
Auch der Disk IO ist unauffällig (~50K/s), wenn sich 24 PCs gleichzeitig melden.

Ich habe auch mal ne 1GB Datei via wget geholt und bekomme die vollen 1GBit ausgenutzt.
Ich bin ziemlich ratlos, wo ich noch schauen könnte und 24 simultane Verbindungen sind meiner Meinung nach jetzt nicht gerade viel.

Die opsi VM läuft in der Zwischenzeit nicht mehr mit dynamischem RAM, sondern statischen 8GB bei 4 Cores. Die verfügbaren Ressourcen werden nicht voll ausgeschöpft.
Einzige Sache, um den IO jetzt wirklich noch auszuschließen wäre, mal SSDs in den Server zu stecken und /var/lib/opsi/config auf der SSD bereitzustellen.

Hat jemand andere Vorschläge/Ideen?

Viele Grüße,
Felix

UPDATE:
also iftop, iotop und top bringen kein brauchbares Ergebnis:
- iftop zeigt jede Menge Verbinungen zu den 24 Clients, die kommen
- iotop zeigt keine Auffälligkeit
- top zeigt die hohe CPU Last von opsiconfd

[bademeister]

So, ich habe jetzt mal ein paar Minuten Zeit gefunden, um in den VM-Host ein paar zusätzliche Platten zu stecken, welche ich dann ausschließlich für unsere opsi VM verfügbar gemacht habe.

Ich habe System-Platte sowie /var/lib/opsi komplett auf diesen neuen Platten laufen lassen und erneut versucht auf 23 Clients zeitgleich einen "on_deman" Event auszulösen.

Gleiches Ergebnis: Alle 23 Clients rennen zeitgleich los und lassen den connection_timeout von 20s ablaufen.

Der Disk IO wegen des Filebackends scheint es also wirklich nicht zu sein.
Viele Grüße,
Felix

EDIT:
Vermutlich löst die Scalability I Erweiterung das Problem, aber die wird erst ab 3000 Clients empfohlen. Wir haben gerade mal 240-270 im System.
Ich finde 23 zeitgleiche Connects für heutige Verhältnisse auch nicht besonders viel und mind. die Abfrage der auszuführenden Aktionen müsste laufen. Wenn dann was installiert wird, knickt selbstverständlich die Bandbreite ein, bzw. ist der Flaschenhals, aber soweit kommt es ja gar nicht.

[n.wenselowski]

Hi Felix,

Ich habe System-Platte sowie /var/lib/opsi komplett auf diesen neuen Platten laufen lassen und erneut versucht auf 23 Clients zeitgleich einen "on_deman" Event auszulösen.

Das erschlägt leider nicht alles, da benötigte Daten auch unter /etc/opsi liegen. Bei der geposteten Info-Page war bspw. das Lesen der Credentials extrem langsam und das File dazu liegt in /etc/opsi.

Gleiches Ergebnis: Alle 23 Clients rennen zeitgleich los und lassen den connection_timeout von 20s ablaufen.

Wenn die Clients mit Timeouts zu kämpfen haben, dann sind die 20 Sekunden vermutlich zu niedrig. Wieso nicht den Standard von 30 Sekunden probieren oder gleich noch etwas höher gehen? Hier muss vermutlich mal an der einen oder anderen Stelle gewackelt werden

Vermutlich löst die Scalability I Erweiterung das Problem, aber die wird erst ab 3000 Clients empfohlen. Wir haben gerade mal 240-270 im System.
Ich finde 23 zeitgleiche Connects für heutige Verhältnisse auch nicht besonders viel und mind. die Abfrage der auszuführenden Aktionen müsste laufen. Wenn dann was installiert wird, knickt selbstverständlich die Bandbreite ein, bzw. ist der Flaschenhals, aber soweit kommt es ja gar nicht.

Ja, vermutlich löst sie das. Ich sehe das aber bei der Client-Menge nicht unbedingt als zielführend, weil das Problem so vermutlich nur verdeckt wird.
23 zeitgleiche Verbindungen sind nicht viel und opsi kann definitiv mehr ab. Aber das File-Backend würde ich jetzt auch nicht als unbedingt die beste Möglichkeit ansehen, wenn es um viele zeitgleiche Zugriffe gibt.

Die große Frage ist was genau zu den langen Antwortzeiten führt. Wenn das bekannt ist, dann kann man zielgerichtet Anpassungen vornehmen.

Und, ich weiß es will niemand hören, aber wir bieten für solche Fälle Support an. Das genaue Problem ist nicht immer einfach zu finden und sowas wie Performance hängt maßgeblich von konkreten Setups an Server & Umgebung ab.
Die Alternative ist mal selbst hinter die Kulissen zu schauen und zu prüfen wo es hängt - opsi ist ja glücklicherweise open source und ermöglicht genau das.


Gruß

Niko

[bademeister]

Ich habe System-Platte sowie /var/lib/opsi komplett auf diesen neuen Platten laufen lassen und erneut versucht auf 23 Clients zeitgleich einen "on_deman" Event auszulösen.

Das erschlägt leider nicht alles, da benötigte Daten auch unter /etc/opsi liegen. Bei der geposteten Info-Page war bspw. das Lesen der Credentials extrem langsam und das File dazu liegt in /etc/opsi.

Wie gesagt, auch die System-Platte, also alles unter "/".
Nur /var/lib/opsi/images ist auf den langsamen Platten liegen geblieben.

Gleiches Ergebnis: Alle 23 Clients rennen zeitgleich los und lassen den connection_timeout von 20s ablaufen.

Wenn die Clients mit Timeouts zu kämpfen haben, dann sind die 20 Sekunden vermutlich zu niedrig. Wieso nicht den Standard von 30 Sekunden probieren oder gleich noch etwas höher gehen? Hier muss vermutlich mal an der einen oder anderen Stelle gewackelt werden

Habe ich gemacht. Bei 60s gibt es dann tatsächlich Erfolge. Nach 55s fangen alle 23 Clients erfolgreich an, eine Verbindung aufzubauen. Habs jetzt auf 90s eingestellt.
Ab dann dauert es Ewigkeiten, aber es wird alles Geladen. Ein "shutdownwanted" braucht dann ca. 10 Minuten bis alle Clients runtergefahren sind.

Irgendwo ist also ein weiterer Flaschenhals, aber ab jetzt wird wenigstens zuverlässig eine Verbindung hergestellt.

Besten Dank für die Hilfestellungen.
Viele Grüße,
Felix

[GEI]

Dann würde ich auf langsame Platten tippen. Dann mal top ausführen und die Kennzahlen vor "wa" anschauen. Steigen die an? Nach meinem Wissen sind das Disk-IO-Waits...

meines Erachtens ist atop da sehr aussagekräftig.