Seite 1 von 3
opsiconfd CPU load
Verfasst: 25 Nov 2015, 10:10
von olio
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
Re: opsiconfd CPU load
Verfasst: 25 Nov 2015, 10:37
von Simon09
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
Verfasst: 25 Nov 2015, 12:35
von wolfbardo
Bitte mal infopage prüfen/posten
https://<opsiserver>:4447/info
Gruss
Bardo Wolf
Re: opsiconfd CPU load
Verfasst: 25 Nov 2015, 13:15
von olio
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
Verfasst: 25 Nov 2015, 13:21
von olio
wolfbardo hat geschrieben:Bitte mal infopage prüfen/posten
https://<opsiserver>:4447/info
Anbei mal die Infopage da sich mir mit den Werten noch nicht erschliesst wo das Problem ist.
http://www.zmml.uni-bremen.de/~olio/ops ... 20info.pdf
Oliver Oster
ZMML - Universität Bremen
Re: opsiconfd CPU load
Verfasst: 25 Nov 2015, 17:26
von n.wenselowski
Hallo Oliver,
Bin sehr überrascht vom RAM-Verbrauch!
Swappt euer Server zufällig?
Gruß
Niko
Re: opsiconfd CPU load
Verfasst: 26 Nov 2015, 09:39
von olio
n.wenselowski hat geschrieben:Hallo Oliver,
Bin sehr überrascht vom RAM-Verbrauch!
Swappt euer Server zufällig?
Hallo Niko,
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
Gruss,
Oliver
Re: opsiconfd CPU load
Verfasst: 26 Nov 2015, 18:13
von olio
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
Re: opsiconfd CPU load
Verfasst: 27 Nov 2015, 18:37
von trabs-ol
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
Re: opsiconfd CPU load
Verfasst: 30 Nov 2015, 10:46
von ueluekmen
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.