opsiconfd CPU load
opsiconfd CPU load
Hallo,
wir haben hier einen Prüfungsraum mit 120 Rechner und Testen dafür OPSI.
Noch vorhandenes Problem: Wenn viele Clients gleichzeitig starten (10-120)
steigt die CPU Last des opsiconfd. Damit dauert die erste Anfrage des Clients beim
OPSI Server sehr lange und der normale Timeout von 30 Sekunden reicht nicht aus.
Wir haben den Timeout nun auf 240 Sekunden gesetzt und ein Client benötigt
ca. 90 Sekunden in der Situation.
Der Opsi Server ist einen opsi-serverVM unter VMWare mit externem DHCP Server.
Ist das eine normales Verhalten bei parallelem Start der Rechner oder habe wir
etwas vergessen?
Mfg,
Oliver Oster
ZMML - Universität Bremen
wir haben hier einen Prüfungsraum mit 120 Rechner und Testen dafür OPSI.
Noch vorhandenes Problem: Wenn viele Clients gleichzeitig starten (10-120)
steigt die CPU Last des opsiconfd. Damit dauert die erste Anfrage des Clients beim
OPSI Server sehr lange und der normale Timeout von 30 Sekunden reicht nicht aus.
Wir haben den Timeout nun auf 240 Sekunden gesetzt und ein Client benötigt
ca. 90 Sekunden in der Situation.
Der Opsi Server ist einen opsi-serverVM unter VMWare mit externem DHCP Server.
Ist das eine normales Verhalten bei parallelem Start der Rechner oder habe wir
etwas vergessen?
Mfg,
Oliver Oster
ZMML - Universität Bremen
Re: opsiconfd CPU load
Ist die CPU Auslastung denn auf 100%? Ab wie vielen Clients gleichzeitig erreicht der CPU Load denn eine vollständige Auslastung?
Re: opsiconfd CPU load
Bitte mal infopage prüfen/posten
https://<opsiserver>:4447/info
Gruss
Bardo Wolf
https://<opsiserver>:4447/info
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
Re: opsiconfd CPU load
Simon09 hat geschrieben:Ist die CPU Auslastung denn auf 100%? Ab wie vielen Clients gleichzeitig erreicht der CPU Load denn eine vollständige Auslastung?
Bei einem Client laut top kurz 25% CPU ab 10 Clients dann 100% und bei 120 Clients mehrere Minuten >100%.
Mit freundlichen Grüßen,
Oliver Oster
Re: opsiconfd CPU load
Anbei mal die Infopage da sich mir mit den Werten noch nicht erschliesst wo das Problem ist.wolfbardo hat geschrieben:Bitte mal infopage prüfen/posten
https://<opsiserver>:4447/info
http://www.zmml.uni-bremen.de/~olio/ops ... 20info.pdf
Oliver Oster
ZMML - Universität Bremen
- n.wenselowski
- Ex-uib-Team
- Beiträge: 3194
- Registriert: 04 Apr 2013, 12:15
Re: opsiconfd CPU load
Hallo Oliver,
Bin sehr überrascht vom RAM-Verbrauch!
Swappt euer Server zufällig?
Gruß
Niko
Bin sehr überrascht vom RAM-Verbrauch!
Swappt euer Server zufällig?
Gruß
Niko
Code: Alles auswählen
import OPSI
Re: opsiconfd CPU load
Hallo Niko,n.wenselowski hat geschrieben:Hallo Oliver,
Bin sehr überrascht vom RAM-Verbrauch!
Swappt euer Server zufällig?
der RAM-Verbrauch war mir auch schon aufgefallen aber bislang scheint das noch kein Problem zu sein:
Code: Alles auswählen
top - 09:34:48 up 1 day, 19:08, 2 users, load average: 0,00, 0,01, 0,05
Aufgaben: 377 total, 1 running, 376 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 be, 0,0 sy, 0,0 ni,100,0 un, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 4044712 total, 2416568 used, 1628144 free, 202820 buffers
KiB Swap: 2047996 total, 0 used, 2047996 free. 714120 cached Mem
PID BENUTZER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1776 opsicon+ 20 0 16,697g 895172 8116 S 0,0 22,1 51:17.21 opsiconfd
1403 mysql 20 0 15,633g 67788 7076 S 0,0 1,7 2:01.97 mysqld
Oliver
Re: opsiconfd CPU load
Nochmaliges Suchen durch das Forum führt dann zu einem Thread der das Problem auch beschreibt aber leider
keine Lösungsmöglichkeit aufzeigt: viewtopic.php?f=7&t=5203
Wenn viele Clients gleichzeitig Anfragen an den opsiconfd stellen schein dieser sehr viel länger zu
benötigen um diese Anzunehmen (Connection Timeout) und dann zu bearbeiten...
Gruss,
Oliver
keine Lösungsmöglichkeit aufzeigt: viewtopic.php?f=7&t=5203
Wenn viele Clients gleichzeitig Anfragen an den opsiconfd stellen schein dieser sehr viel länger zu
benötigen um diese Anzunehmen (Connection Timeout) und dann zu bearbeiten...
Gruss,
Oliver
Re: opsiconfd CPU load
Hi,
kommt es denn nur zu einem Time-Out, wenn die Clients beim Bootvorgang etwas installieren sollen?
Nutzt Ihr das File-Backend?
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...
VG
Lars
kommt es denn nur zu einem Time-Out, wenn die Clients beim Bootvorgang etwas installieren sollen?
Nutzt Ihr das File-Backend?
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...
VG
Lars
Re: opsiconfd CPU load
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.
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 würde sich für euren Prüfungsraum das Modul local-image-backup bestimmt ganz gut machen. Auch wenn man hier die Serviceconnects nicht umgeht, ist das Verfahren mit dem Modul für PC-Räume immer besser geeignet.
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.
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 würde sich für euren Prüfungsraum das Modul local-image-backup bestimmt ganz gut machen. Auch wenn man hier die Serviceconnects nicht umgeht, ist das Verfahren mit dem Modul für PC-Räume immer besser geeignet.
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
For productive opsi installations we recommend support contracts.
http://www.uib.de