opsiconfd CPU load

olio
Beiträge: 9
Registriert: 25 Nov 2015, 09:49

Re: opsiconfd CPU load

Beitrag 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
Benutzeravatar
n.wenselowski
Ex-uib-Team
Beiträge: 3194
Registriert: 04 Apr 2013, 12:15

Re: opsiconfd CPU load

Beitrag 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

Code: Alles auswählen

import OPSI
olio
Beiträge: 9
Registriert: 25 Nov 2015, 09:49

Re: opsiconfd CPU load

Beitrag 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
Benutzeravatar
wolfbardo
uib-Team
Beiträge: 1354
Registriert: 01 Jul 2008, 12:10

Re: opsiconfd CPU load

Beitrag 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


OPSICONF 2024
https://opsi.org/en/opsiconf/

opsi-Basisworkshops:

22. - 25. 04. 2024


opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.

http://www.uib.de
olio
Beiträge: 9
Registriert: 25 Nov 2015, 09:49

Re: opsiconfd CPU load

Beitrag 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
olio
Beiträge: 9
Registriert: 25 Nov 2015, 09:49

Re: opsiconfd CPU load

Beitrag 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
Benutzeravatar
ueluekmen
uib-Team
Beiträge: 1939
Registriert: 28 Mai 2008, 10:53

Re: opsiconfd CPU load

Beitrag 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.
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
dkoch
Beiträge: 309
Registriert: 25 Nov 2011, 14:03

Re: opsiconfd CPU load

Beitrag 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.
bademeister
Beiträge: 141
Registriert: 28 Feb 2014, 10:21

Re: opsiconfd CPU load

Beitrag 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
Benutzeravatar
ueluekmen
uib-Team
Beiträge: 1939
Registriert: 28 Mai 2008, 10:53

Re: opsiconfd CPU load

Beitrag 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)
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
Antworten