Configed ist sehr zäh

[RMuenz]

Hallo,
wir haben den Opsi nun seit knapp 4 Jahren am laufen, er tut was er soll, ohne Probleme.
Nur der Configed hat inzwischen eine sehr schlechte Reaktionszeit. Bereist das Anmelden dauert mehr als 1 Minute, bis zu 2, manchmal gibt es einen Timeout, es wird ein lokaler User, zB opsiadmin, benutzt.
Auch jede Aktualisierung dauert so lange. Jede weitere Aktualisierung inkurzen abständen läuft flott, aber wehe der Configedsteht eine länger Zeit im Hintergrund! Dann dauert es wieder bis 2 Minuten ehe die Aktualisierung durch ist. Zu zum Beispiel wenn man einen Client aus der clientliste anklickt um dann die Einzelheiten zu bekommen wie Produktkonfiguration, Soft- /Hardware Inventur, Logdateien ...
CPU und RAM sind kein Problem. Platz ist auch genug da.
Etwas Besserung für sehr kurze zeit bringt ein "Cleanup-Backend", aber eben nur leicht und ndur für 2, 3 Tage.
Es sind 52 Clients. Standardkonfig der dispatch mit mysql für sw und HW Audits, sonst file.
Gibt es noch eine Stelle, wo man ansetzen kann? Wo liegen eigentlich die Dateien für file als Backend z. B. instlog? Wie kann man das mal aufräumen?
Danke vorab für Tips und Hinweise!
Beste Grüße, Ralf

[Jan.Schmidt]

Salve,

"wenn" dein Sponsor/Cheffe dir was gutes tun will und du das lahme Ding endgültig loswerden willst.....

Besorg Euch das mysql Backend und der configed ist so schnell, das du wieder auf sekunden statt minuten kommst.

Alles andere hast du ja selber schon probiert.

[RMuenz]

Na ja - die UIB Empfehlung dafür lautet ab 300 Clients, Das ist nachvollziehbar. Aber wegen 50?
Und wo kommt das SQL Backend bei der Anmeldung ins Spiel bei "Verbinden und authentifizieren"? Das ging früher auch flotter. Im SSH (putty) erfolgt die Anmeldung ohne jede Verzögerung, selbst bei Domänenkonten.
Ich denke daher eher, hier hat der auf dem Windows 10 Notebook installierte Configed ein Problem, nicht das Backend....

[SisterOfMercy]

Have you updated configed recently?

[RMuenz]

Sure, it is the current Version available from UIB.

[Jan.Schmidt]

Hi,

sorry bei 50+ Clients muß es was anderes sein, das läuft eigentlich schon mit dem filebackend.

Habt Ihr viele "Freie Anfragen im Configed" gespeichert?
Ich starte den configed immer ohne ssh, außer ich mach was ganz besonderes.

[RMuenz]

Hallo,
es sind 4 gespeicherte Anfragen drin.
Wie gesagt - ich denke auch es liegt irgendwo im Client selber. An der Shell mit SSH ist man in Millisekunden angemeldet, egal ob mit Kerberos gegen die Domäne oder lokal. Der Configed braucht dazu in beiden Fällen gleich lange.
Wenn er einmal verbunden ist, sind die Zeiten für Aktualisierungen recht kurz,, heißt er läuft flott. Erst wenn der Configed eine Weile steht, dauert es wieder bis er geruht sich die Daten abzuholen. Das hat den Anschein, als würde JAVA sich hier komisch anstellen?

[r.roeder]

Hi,

auch wenn ich mich über jede Empfehlung des mysql-Backends freue, da es aus Entwicklersicht 100mal besser ist als das File-Backend: Daran allein kann ein Geschwindigkeitsproblem nicht liegen, denn die paar Dateien eines Backends mit 50 Clients liegen ja faktisch im Hauptspeicher.

Es hat aber auch im configed die letzten jahre keine Änderung gegeben, die das Programm selbst ausbremsen würde. Man müsste sich das System insgesamt anschauen, wo Engpässe oder Probleme auftreten. Ein erster Ansatzpunkt ist immer die Infopage https:/ /OPSISERVER:4447/info, die einerseits anzeigt, wenn der Server Probleme hat und andererseits die letzten Service-Methodenaufrufe mit der Antwortdauer auflistet.

Ein weitere Ansatzpunkt sind natürlich die Logdateien des Service sowie des configed (diese Logdatei ist findbar mit Hilfe des Menüpunkts Hilfe/Aktueller Logfile

Wenn man, ebenfalls im Hilfe-Menü, das Loglevel auf "check" setzt, wird auch direkt die Dauer jedes Serviceaufrufs geloggt. Vielleicht wird dabei deutlich, wo Probleme liegen.

Ein Test wäre auch, einfach auf einem Notebook einen neuen opsi-Server aufzusetzen (s. , die Daten zu backuppen und das Backup in den Zweitserver einzuspielen. Vielleicht ist dann alles performant.

Es handelt sich offenbar um ein Problem, das nicht einfach ein Standardverhalten der opsi-Komponenten ist, sondern an spezifischen Bedingungen liegt - insofern eigentlich ein typischer Supportfall

Ich drücke die Daumen

[RMuenz]

Der Tip mit dem Logfile war schon mal gut - das hatte ich noch gar nicht gesehen

Da fällt dieser Teil auf mit knapp 1 Minute Stillstand:

[3] (INFO) [Juni 26 15:02:12.053 2020] [Thread[HandshakeCompletedNotify-Thread,6,main]] de.uib.opsicommand.JSONthroughHTTPS$MyHandshakeCompletedListener protocol TLSv1.2 peerName 1.2.840.113549.1.9.1=#161d6365727461646d696e4066656c647363686c6f6573736368656e2e6465,CN=ddopsi1.fsdd.local,OU=IT,O=Feldschloesschen AG,L=Dresden,ST=Sachsen,C=DE
[3] (INFO) [Juni 26 15:02:12.053 2020] [Thread[HandshakeCompletedNotify-Thread,6,main]] de.uib.opsicommand.JSONthroughHTTPS$MyHandshakeCompletedListener cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256
[3] (INFO) [Juni 26 15:03:05.262 2020] [Thread[Thread-2,6,main]] de.uib.opsicommand.JSONthroughHTTPS retrieveJSONObjects got new session

Das sieht sehr danach aus, dass dem Configed etwas mit dem SSL-Zertifikat bzw. den geforderten tls-cipher nicht wirklich schmeckt.

Der Aufruf des Configed ist so:
"C:\Program Files (x86)\opsi.org\configed\sapmachine-jre-11.0.5\bin\javaw.exe" -Xmx1024m -jar "C:\Program Files (x86)\opsi.org\configed\configed.jar" -h ddopsi1.fsdd.local -r 0 --ssh-immediate-connect y --use_tls_cipher TLS_RSA_WITH_AES_128_GCM_SHA256 -l D

Kann damit jemand was anfangen?

[r.roeder]

Etwas Herumstochern:

man könnte die Option --use_tls_cipher TLS_RSA_WITH_AES_128_GCM_SHA256 einfach mal weglassen und Server-Lib und Java-Lib das aushandeln lassen;

Hinweise über Probleme kriegt man auch, wenn man den ganz Aufruf in die Konsole kopiert und dann javaw.exe durch java.exe ersetzt, dann wird zusätzlich in die Konsole geloggt. Mit --loglevel 4 wird das Loglevel direkt hochgesetzt.