Seite 2 von 3

Re: opsiconfd CPU load

Verfasst: 30 Nov 2015, 15:48
von olio
ueluekmen hat geschrieben:Hi,

normalerweise würde ich auch sagen, dass diese Werte absolut nicht normal sind. Das er länger braucht ist normal, da der jetzige Webservice bekanntlich nicht gut skaliert. Dass er 10GB RAM frisst, ist aber nicht normal. Das sollte auch so nicht sein. Da man auch 120 Rechner nie gleichzeitig anbekommt ist ja eine Verzögerungen immer mit drin. Eine Erhöhung der Sessiontimeout ist auch mit Vorsicht zu genießen. Aber hier ist wahrscheinlich das Timeout bei den Clients gemeint.


Genau, es geht um dem Timeouts der Clients beim Starten der Rechner.
Da die Rechner eigentlich fast immer über WoL gestartet werden ist da doch fast gleichzeitig. Damit ist die Connect Zeit die ein
Opsi-Client zum confd benötigt hoch. Ausser den CPU-Prozenten beim confd war auch direkt nichts auffälliges zu sehen.
Kann das alles am File-Backend liegen?

ueluekmen hat geschrieben:Ich würde an der Stelle auch erst mal auf die Platte tippen. Wir haben schon bei diversen Installationen festgestellt, dass lahme Platten auch zu einem lahmen opsi-Systemen führen. Auch die Requests sind enorm Hoch für diese Clientanzahl. Was mich auch wundert ist, dass er für configStates_getObjects mehr als 2 Sekunden im Schnitt braucht, bei nur 35 Configs... da stimmt auch was nicht.


Ansonsten ist in der VM in einem VMWare-HA-Cluster nichts zu bemerken. Einzig der Client-Connect bei ca. >15 gleichzeitigen Connects zum Opis Server
dauern doch sehr lange. Die Installation von Software ist dann wieder kein Problem. Nur der Start der Rechner ist durch den Timeout halt deutlich
verzögert.

Gruss,
Oliver

Re: opsiconfd CPU load

Verfasst: 03 Dez 2015, 11:53
von n.wenselowski
Hi,

olio hat geschrieben:Da die Rechner eigentlich fast immer über WoL gestartet werden ist da doch fast gleichzeitig.

Alle gleichzeitig? Dann würde ich zwischen den einzelnen Rechnern mal ein bisschen Pufferzeit einbauen.

olio hat geschrieben:Ausser den CPU-Prozenten beim confd war auch direkt nichts auffälliges zu sehen. Kann das alles am File-Backend liegen?

Ja, das kann durchaus daran liegen. Aber es kann auch daran liegen was alles gemacht wird (bspw. ständige Inventur).
Einfache Möglichkeit wäre mit einer Test-Freischaltung des MySQL-Backends mal zu testen, wie stark sich das Verhalten hierbei ändert.


Gruß

Niko

Re: opsiconfd CPU load

Verfasst: 03 Dez 2015, 15:11
von olio
Hallo,

n.wenselowski hat geschrieben:Alle gleichzeitig? Dann würde ich zwischen den einzelnen Rechnern mal ein bisschen Pufferzeit einbauen.

Damit würden wir das Zeitproblem vom Connect nur auf die Pufferzeit verlagern. Die Rechner werden nur für
Prüfungen gestartet und in einigen Fällen zwischen zwei Prüfungen neu gestartet. Dies soll natürlich ohne Aktivität
von OPSI nicht zu lange benötigen. Aktuell sind es ca. 10 Minuten um einmal zum Server zu Verbinden (ohne Aktionen).

n.wenselowski hat geschrieben:Ja, das kann durchaus daran liegen. Aber es kann auch daran liegen was alles gemacht wird (bspw. ständige Inventur).
Einfache Möglichkeit wäre mit einer Test-Freischaltung des MySQL-Backends mal zu testen, wie stark sich das Verhalten hierbei ändert.

Aktionen sind da eigentlich keine (Inventur ist nicht aktiv). Bleibt also zunächst ein Test mit dem MySQL-Backend.

Gruss,
Oliver

Re: opsiconfd CPU load

Verfasst: 03 Dez 2015, 15:19
von wolfbardo
olio hat geschrieben:Genau, es geht um dem Timeouts der Clients beim Starten der Rechner.
Da die Rechner eigentlich fast immer über WoL gestartet werden ist da doch fast gleichzeitig.


Warum gleichzeitig?

Wie ist die aktuelle backend-Konfiguration ?

Code: Alles auswählen

cat /etc/opsi/backendManager/dispatch.conf


Gruss
Bardo Wolf

Re: opsiconfd CPU load

Verfasst: 03 Dez 2015, 17:44
von olio
wolfbardo hat geschrieben:Warum gleichzeitig?


Die Rechner werden vor der Prüfung gestartet (je nach notwendiger Anzahl und Platzierung via WoL)
das sind dann so 64-120 Rechner gleichzeitig. Die alle einmal kurz den OPSI Server befragen wollen.

Der Raum wird nur für Prüfungen genutzt.

wolfbardo hat geschrieben:Wie ist die aktuelle backend-Konfiguration ?

Code: Alles auswählen

cat /etc/opsi/backendManager/dispatch.conf


Code: Alles auswählen

backend_.*         :opsipxeconfd, mysql, file
host_.*            :file, opsipxeconfd
productOnClient_.* :file, opsipxeconfd
configState_.*     :file, opsipxeconfd
license.*          :mysql
softwareLicense.*  :mysql
audit.*            :mysql
.*                 :file


Gruss,
Oliver

Re: opsiconfd CPU load

Verfasst: 04 Dez 2015, 13:33
von olio
n.wenselowski hat geschrieben:Hi,
Einfache Möglichkeit wäre mit einer Test-Freischaltung des MySQL-Backends mal zu testen, wie stark sich das Verhalten hierbei ändert.

Der Test mit MySQL-Backends hat in dem Fall "Verbinde zu Config-Server" nichts verändert. Der Timeout zählt immer noch ca. 90 Sekunden
runter bis die Verbindung aufgebaut wird.

Gruss,
Oliver

Re: opsiconfd CPU load

Verfasst: 04 Dez 2015, 13:46
von ueluekmen
Hallo Oliver,

wenn der Umstieg auf mysql nichts bringt, dann ist bei euch was ganz anderes schief. Habt Ihr Netzwerkperformanceprobleme?

Andere Frage, die Rechner zu starten ist eine Sache, müssen diese Rechner nach dem aufwecken sich noch updaten? Wenn nicht, wäre es auch eine Möglichkeit, dass gui_startup von diesen Clients zu deaktivieren und zum Beispiel auf on_shutdown-Installation aus zu weichen.

Ansonsten sollten wir uns vielleicht mal direkt unterhalten, eventuell ist es auch etwas ganz anderes, wo es bei euch hängt.

Re: opsiconfd CPU load

Verfasst: 04 Dez 2015, 14:05
von dkoch
Auch bei uns sind nicht mehr als 700 rpcs/min zu schaffen. Das geht mit den von OP genannten Problemen und Phänomenen einher. Bis auf den RAM ist das kein abweichendes Verhalten zu unserer Installation. Mehr geht imho mit aktueller Hardware, OPSI as is und Installation nach Handbuch zur Zeit nicht. Du könntest einen Balancer und mehrere opsiconfd nutzen.

Re: opsiconfd CPU load

Verfasst: 09 Okt 2018, 19:25
von bademeister
Hat hier jemand weitere Erfahrungen gesammelt? Wir haben ähnliche Probleme bei nur 24 Rechnern. Wenn diese zeitgleich starten, reicht ein client_timeout von 20s nicht aus und der opsiconfd läuft mit >130%.

Wir haben bereits das OLI im Einsatz und möchten jetzt eben halbtäglich Images in einem Schulungsraum switchen. Das gestaltet sich so in "kurzer Zeit" natürlich schwierig.

Die opsi/info gibt mir bei 24 zeitgleichen Clients auch komischerweise durchschnittliche 88 rpcs/min zurück.
Hat jemand eine Idee wo ich noch schauen könnte?
Disks vom Server können es meines Erachtens nach nicht sein, denn dann würde ja immerhin eine Verbindung klappen und keine timeouts auftreten.

Viele Grüße,
Felix

Re: opsiconfd CPU load

Verfasst: 11 Okt 2018, 00:30
von ueluekmen
Hallo Felix,

die info-Page zeigt einiges mehr als nur die CPU-Last. Wenn die Last dauerhaft die 100% kratzt hilft manchmal ein Blick unten in die letzten 250 RPCs, dabei ist entscheidend wie lange diese laufen. Je länger, desto schlechter. ;)

EDIT: Über einen Supportvertrag kann man auch ein geschultes Auge drüber schauen lassen. (Bin etwas eingerostet :D)