Nuclet einspielen dauert unterschiedlich lange

[Matthias KÖPER]

Hallo,

ich habe auf unserem Entwicklungssystem ein Nuclet erstellt und übertrage es auf zwei Nuclos-System. Beide hängen im selben Firmennetz auf zwei virtuellen Maschinen auf dem gleichen Server. Trotzdem dauert das Einspielen des gleichen Nuclets unterschiedlich lange. Auf dem einen System ist das Ganze in wenigen Minuten erledigt. Auf dem zweiten System dauert es ewig lange bis er das Nuclet analysiert hat und läuft teilweise auf einen Timeout (nach etwa einer halben Stunde). Der einzige Unterschied liegt darin, dass das zweite System mehr Daten enthält, das sollte aber meiner Meinung nach kein Problem sein.

Wie komme ich dem Problem auf die Spur?

Danke,
Skoeper

[Frank Pavlic]

Hallo,
doch ,es macht einen Unterschied, wieviele Daten das System bereits enthalten hat. Beispiel:
Du machst ein Attribut in einer Entität nach ca. 6 Monaten Laufzeit zum Pflichtfeld, für die Datenbank heisst es dann „NOT NULL“. Wenn diese Tabelle nun Daten enthält, müssen diese ja evaluiert werden, heisst, es muss überprüft werden, ob nicht ein Datensatz doch einen NULL-Wert in dem entsprechenden Attribut enthält.
Und so ähnlich verhält es sich mit anderen Operationen.
Wobei ich schon sagen muss, dass eine halbe Stunde Importzeit schon etwas ungewöhnlich ist.
Ich weiss jetzt nicht, ob dein nuclet das gesamte System beinhaltet oder nicht. Falls ja, dann könntest Du
ielleicht nur deine Änderungen in ein eigenes nuclet auslagern und nur dieses nuclet dann importieren?
Ansonsten würde ich mal die Datenbank ins Visier nehmen und schauen, was die so während des Imports treibt.
Dann kannst Du auch mit jvisualvm dein Tomcat unter die Lupe nehmen und schauen, wo er die meiste CPU-Zeit verbläst.

Gruß
Frank

[Matthias KÖPER]

Hallo Frank,

Datenbankänderungen, die die Daten betreffen habe ich so weit ich weiß nicht dabei. Das System hängt im ersten Teil des Imports fest, also dort, wo analysiert wird, welche Änderungen notwendig sind. Gestern habe ich mein aktuelles Nuclet gar nicht eingespielt bekommen. Nach zwei Timeouts habe ich aufgegeben. Datenbank- und Tomcatanalyse habe ich noch nicht gemacht. Gibt es dazu im Wiki Hinweise?

Viele Grüße
skoeper

[Frank Pavlic]

Hallo,
im Wiki habe ich nicht gesucht, daher weiss ich es nicht. Ich habe jvisualvm bereits vor nuclos benutzt, um Schwächen in Java-Programmen aufzudecken. In deinem Fall könntest Du nachschauen, in welcher Funktion der nuclet-Import hängt bzw. die Zeit bis zum Timeout verbringt. CPU-Sampling müsste dir relativ schnell zeigen, wo die meiste Zeit verbracht wird.

Gruß
Frank

[Matthias KÖPER]

Nach einigem Suchen hat sich folgender Grund gefunden:
Postgres war sehr beschäftigt und war der Flaschenhals. Nachdem wir einige Postgresparameter geändert hatten und die Datenbank mehr Luft hatte, ging es plötzlich wieder gut.

[Frank Pavlic]

Hallo,
es wäre super, wenn Du vielleicht die Postgres-Parameter posten könntest, die zu einer signifikanten Verbesserung führten. Davon könnten weitere Admins/User ebenfalls profitieren.

Gruß
Frank

[Matthias KÖPER]

Hallo zurück mit Verzögerung,

folgende Parameter haben wir in unsere postgresql.conf aufgenommen bzw. angepasst:


shared_buffers = 768MB # ggf. Kernel konfigurieren s. postgres-Doku
temp_buffers = 64MB
work_mem = 4MB
maintenance_work_mem = 256MB
effective_cache_size = 1024MB


Die Postgres-Doku bezüglich Kernel-Konfiguration z.B. hier (Version beachten):
http://www.postgresql.org/docs/9.1/static/kernel-resources.html

Ohne Anspruch auf perfektes Postgres-Tuning! Vor allem muss man darauf achten, dass sich der Speicherverbrauch bei manchen Parametern multipliziert (mit der Anzahl der User bzw. gleichzeitig ausgeführter Statements u.ä.).

Mit diesen Änderungen ließ sich jedenfalls das Nuclet wieder problemlos importieren.

Mfg
mkoeper

[Ramin Goettlich]

In der aktuellsten 4.3 Beta (noch nicht zum Download verfügbar) haben wir einige Optimierungen am Nucletimport vorgenommen, die die Performance desselben auf langsamen Datenbanken ca. verzehnfachen.

[Autor]

Beiträge