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/opsiconfd%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: https://forum.opsi.org/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.