configed: Freie Anfrage in „Software-Inventarisierungseigenschaften“ funktioniert nicht

[poly]

Hallo zusammen,

Seit kurzer Zeit (nach Update auf configed Version 4.0.6.3.5.1 ???) kann ich keine Abfragen von „Software-Inventarisierungseigenschaften“ mehr durchführen. Der configed hängt sich auf bzw. kommt nach ca. 15 Minuten mit der Fehlermeldung: „Die Anwendung muss mit einer höheren Speicheranforderung konfiguriert werden.“ Der dazugehörige Abschnitt in der „configed.log“ sieht wie folgt aus:

Code: Alles auswählen

[2] (WARNING)  [Nov 04  10:51:15.001  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]      de.uib.configed.type.SWAuditClientEntry   swIdent not found in softwarelist
[3] (INFO)     [Nov 04  10:51:15.094  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]      de.uib.configed.type.SWAuditClientEntry   software with ident Chemikalien-Informations-System II version 2.872;2.872;;;x86 not yet indexed
[3] (INFO)     [Nov 04  10:51:15.095  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]      de.uib.utilities.WaitCursor   adding instance 1-- call location at (de.uib.opsicommand.JSONthroughHTTPS) on component de.uib.configed.configedApplet[panel0,0,0,1600x1089,invalid,layout=java.awt.BorderLayout,rootPane=javax.swing.JRootPane[,0,0,1600x1089,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
[3] (INFO)     [Nov 04  10:51:15.095  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://vmopsi.mpip-mainz.mpg.de:4447/rpc
[3] (INFO)     [Nov 04  10:51:15.095  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]      de.uib.opsicommand.JSONthroughHTTPS   retrieveJSONObjects request old or  new session 
[3] (INFO)     [Nov 04  10:51:21.974  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]      de.uib.opsicommand.JSONthroughHTTPS   retrieveJSONObject ready
[3] (INFO)     [Nov 04  10:51:21.974  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]      de.uib.utilities.WaitCursor    stop wait cursor 1, was located at (de.uib.opsicommand.JSONthroughHTTPS)
[3] (INFO)     [Nov 04  10:51:28.804  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]         Exception java.lang.OutOfMemoryError: Java heap space 
STACK:
     java.util.Arrays.copyOf(Unknown Source)
     java.lang.AbstractStringBuilder.expandCapacity(Unknown Source)
     java.lang.AbstractStringBuilder.ensureCapacityInternal(Unknown Source)
     java.lang.AbstractStringBuilder.append(Unknown Source)
     java.lang.StringBuilder.append(Unknown Source)
     java.lang.StringBuilder.append(Unknown Source)
     java.util.AbstractCollection.toString(Unknown Source)
     java.lang.String.valueOf(Unknown Source)
     java.lang.StringBuilder.append(Unknown Source)
     de.uib.opsidatamodel.OpsiserviceNOMPersistenceController.retrieveListOfMapsNOM(OpsiserviceNOMPersistenceController.java:3891)
     de.uib.opsidatamodel.DataStubNOM.retrieveInstalledSoftwareInformation(DataStubNOM.java:853)
     de.uib.opsidatamodel.DataStubNOM.getSoftwareList(DataStubNOM.java:791)
     de.uib.opsidatamodel.OpsiserviceNOMPersistenceController.getSoftwareList(OpsiserviceNOMPersistenceController.java:5978)
     de.uib.configed.type.SWAuditClientEntry.updateSoftware(SWAuditClientEntry.java:214)
     de.uib.configed.type.SWAuditClientEntry.produceSWid(SWAuditClientEntry.java:224)
     de.uib.configed.type.SWAuditClientEntry.<init>(SWAuditClientEntry.java:145)
     de.uib.opsidatamodel.DataStubRawData.retrieveSoftwareAuditOnClients(DataStubRawData.java:550)
     de.uib.opsidatamodel.DataStubNOM.fillClient2Software(DataStubNOM.java:942)
     de.uib.opsidatamodel.OpsiserviceNOMPersistenceController.fillClient2Software(OpsiserviceNOMPersistenceController.java:2514)
     de.uib.configed.clientselection.backends.opsidatamodel.OpsiDataBackend.getSwAuditOnClients(OpsiDataBackend.java:446)
     de.uib.configed.clientselection.backends.opsidatamodel.OpsiDataBackend.checkInitData(OpsiDataBackend.java:271)
     de.uib.configed.clientselection.backends.opsidatamodel.OpsiDataBackend.getClients(OpsiDataBackend.java:297)
     de.uib.configed.clientselection.Backend.checkClients(Backend.java:32)
     de.uib.configed.clientselection.SelectionManager.selectClients(SelectionManager.java:154)
     de.uib.configed.gui.ClientSelectionDialog.doAction1(ClientSelectionDialog.java:153)
     de.uib.configed.gui.FGeneralDialog.actionPerformed(FGeneralDialog.java:435)
     javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
     javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
     javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
     javax.swing.DefaultButtonModel.setPressed(Unknown Source)
     javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
     java.awt.Component.processMouseEvent(Unknown Source)

[3] (INFO)     [Nov 04  10:51:28.805  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]         Thread Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup] - RunTime Error -  java.lang.OutOfMemoryError: Java heap space
[1] (ERROR)    [Nov 04  10:51:28.805  2015]    [Thread[AWT-EventQueue-2,4,https://vmopsi.mpip-mainz.mpg.de:4447/configed/-threadGroup]]         Es gibt ein Problem mit einer Anfrage.
Die Anwendung muss mit einer höheren
Speicheranforderung konfiguriert werden.

Ich benutze gespeicherte Abfragen, die mit früheren Versionen einwandfrei funktioniert haben. Auch einfache Abfragen nach “(Software)Inventarisierung/ID“ oder „Inventarisierung/Version“ scheiterten wiederholt. Andere Abfragen nach „Host-Eigenschaften“ oder „opsi-Produkt-Eigenschaften“ funktionieren wie gewohnt einwandfrei.

Gibt es hier bekannte Probleme?

Gruß
Thomas

[r.roeder]

Die Fehlermeldung ist eindeutig. „Die Anwendung muss mit einer höheren Speicheranforderung konfiguriert werden", im Log stehtava.lang.OutOfMemoryError. Zur Reparatur am besten das Localboot-Produkt verwenden und neu installieren mit required_memory auf 1024 MB (oder mehr, aber ich habe noch nicht beobachtet, dass das erforderlich ist). Der configed cached mehr Daten lokal als früher, das bringt Zeitvorteile beim erneuten Zugriff, aber erfordert eine höhere Speicheranforderung (die heute ja kein Problem mehr sein dürfte).

Grüße
R. Röder

[poly]

Hallo Herr Röder,

zunächst einmal danke für die schnelle Antwort.
Ich habe nochmals ein wenig getestet, den lokalen configed benutzt und die Größe des Java-Heap-Memory nach ihrem Rat verändert. Der Standardwert von 'required_memory' ist ja schon bei 1024MB, also habe ich ihn auf 2048MB gesetzt. Danach läuft die Anfrage zwar ohne Fehler durch, liefert auch ein Ergebnis, benötigt aber etwa 10-15 Minuten dafür. Eine weitere Erhöhung des Speichers auf 4096MB bringt keine spürbare Verbesserung.
Wie bereits geschildert sind Abfragen anderer Eigenschaften (auch mit mehreren Kriterien) deutlich schneller. Aber auch hier gibt es erhebliche Unterschiede.
- Abfragen nach 'Host-Eigenschaften' brauchen Bruchteilen von Sekunden
- Abfragen nach 'opsi-Produkt-Eigenschaften' brauchen einige Sekunden
- Abfragen nach diversen 'Hardware-Eigenschaften' brauchen 1-2 Minuten
- Abfragen nach 'Software-Inventarisierungseigenschaften' brauchen 10-15 Minuten
Vor jedem Test wurden mit dem Reload-Button alle Daten neu geladen. Die drei ersten Tests funktionieren mit 1024MB Speicher übrigens ähnlich schnell.

Woher kommen diese unterschiedlichen Verarbeitungszeiten? Der configed kann ja offensichtlich sehr schnell die Datenbank abfragen und auch wenn die Datenstrukturen der Software-Inventarisierungseigenschaften sicherlich komplexer sind, erscheint mir ein Faktor >1000 für die Bearbeitung sehr ungewöhnlich.

Gruß
Thomas

[r.roeder]

Die SW-Inventarisierungsdaten können sehr umfangreich sein. Es ist dringend empfohlen, hierfür das mysql-Backend zu verwenden. Für die Audit-Daten kann es auch kostenfrei aktiviert werden. Ich vermute, dass das bei Ihnen nicht der Fall ist. Auch sonst ist bei dem Datenvolumen, das offenbar bei Ihnen anliegt, (wieviele Clients managen Sie?) ein mysql-Backend empfehlenswert.

Grüße
R. Röder

[poly]

Wir managen ca. 700 Clients und haben das mysql-Backend bereits im Einsatz.

Gruß
Thomas

[r.roeder]

Sehr eigenartig, ich habe schon weit größere Backends mit völlig unproblematischem Zeitverhalten gesehen. Bitte schauen Sie mal in das Logfile des configeds (der lokal per opsi-Paket installierte sollten in c:\opsi.org\log\configed.log die Logmeldungen schreiben). Ziemlich am Anfang der Logdatei sollte bei aktivem mysql-Backend stehen

... DataStubRawData test,
...
....DataStubRawData test result true

Findet sich das bei Ihnen?

[poly]

... DataStubRawData test,
...
....DataStubRawData test result true

Ja, das finde ich bei mir im Logfile.

Ich habe das Problem mittlerweile wie folgt gelöst:
Nach Ausführen von 'opsi-setup --cleanup-backend' laufen die gewünschten Abfragen in vertretbaren Zeiten (< 1 Min.) und ohne Speicherprobleme durch.

- Kann hier das Problem gelegen haben?
- Gibt es weitere Möglichkeiten oder Empfehlungen zum Thema 'database maintenance'?

Gruß
Thomas

[r.roeder]

ok, diese Zeiten entsprechen den Erwartungen, es muss jede Menge Einträge für nicht mehr referenzierte Software in der Datenbank gegeben haben. Anstelle cleanup-backend könnte man auch die SW-Audit-Tabellen löschen und durch das schnell ausführbare swaudit auf allen Rechnern neu erzeugen.