Genau, es geht um dem Timeouts der Clients beim Starten der Rechner.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.
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?
Ansonsten ist in der VM in einem VMWare-HA-Cluster nichts zu bemerken. Einzig der Client-Connect bei ca. >15 gleichzeitigen Connects zum Opis Serverueluekmen 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.
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