opsiconfd CPU load

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

Re: opsiconfd CPU load

Beitragvon olio » 30 Nov 2015, 15:48

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
uib-Team
Beiträge: 3195
Registriert: 04 Apr 2013, 12:15

Re: opsiconfd CPU load

Beitragvon n.wenselowski » 03 Dez 2015, 11:53

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

Beitragvon olio » 03 Dez 2015, 15:11

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: 1148
Registriert: 01 Jul 2008, 12:10

Re: opsiconfd CPU load

Beitragvon wolfbardo » 03 Dez 2015, 15:19

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


!!! ANMELDEN !!! opsi-Konferenz in Mainz am 02. / 03. März 2020 https://opsiconf.org

opsi workshops

https://uib.de/de/support-schulung/schulung/

Basis
9.-12.12.2019
3.-6.2.2020
23.-26.3.2020


opsi support by uib gmbh

http://www.uib.de

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

Re: opsiconfd CPU load

Beitragvon olio » 03 Dez 2015, 17:44

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

Beitragvon olio » 04 Dez 2015, 13:33

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: 1892
Registriert: 28 Mai 2008, 10:53

Re: opsiconfd CPU load

Beitragvon ueluekmen » 04 Dez 2015, 13:46

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

Beitragvon dkoch » 04 Dez 2015, 14:05

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

Beitragvon bademeister » 09 Okt 2018, 19:25

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: 1892
Registriert: 28 Mai 2008, 10:53

Re: opsiconfd CPU load

Beitragvon ueluekmen » 11 Okt 2018, 00:30

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