Performance Phänomen/Problem große DB, viele Dokumente, viele Updates

[Gandhi]

Ich habe ein Performance Problem, dass ich nicht restlos verstehe:
Ein LEI Job ändert Massen von Dokumenten (DB hat ca. 200k Dokumente, etwa die Hälfte wird in einem wöchentlichen Lauf durch den Job geändert).

Nun zeigt sich folgendes Verhalten:
In den ersten etwa 2 Stunden werden ca. 300 Dokumente pro Minute geändert.
Danach sackt die Performance ab. bis  irgendwan nur noch ca. 30 Dokumente geändert werden.

Was habe ich bislang getan:
1. Anzahl der Update Prozesse von 1 auf 3 erhöht (Server hat 4 CPUs). ==> kein erkennbarer Effekt
2. Job in mehrere Abschnitte aufgeteilt==> Die fangen jeweils (ca. 1h Unterbrechung) wieder bei 300 an und sacken aber auch wieder ab.

Meine erste Vermutung, dass es an den Indexern lag, hat sich als falsch erwiesen - offenbar hat der Server aber ein Problem mit der Dichte der Änderungen über einen längeren Zeitraum.

Hat hierzu jemand eine Idee?

Meine Ideen:
1. Alle 10.000 Dokumente einen Sleep einbauen (das wird mein nächster Versuch sein)
2. IO genauer Monitoren, ob da noch irgendeine SystemDB gefüllt wird (die temporären Dateien liegen schon getrennt von den DBs, andere Platte, anderer Controller).

Auf dem Server ist sonst nur noch Userverkehr, also keine speziellen aufwändigeren Tasks. Keine Agenten o.ä., der Replikator ist quasi ständig Idle

[Gandhi]

Hab das nochmal bei IBM geposted:
http://www-10.lotus.com/ldd/nd6forum.nsf/ShowMyTopicsAllFlatweb/ad61ac6083c9a4cf8525754000449b29?OpenDocument

[Thomas Schulte]

Ich denke das hängt davon ab wie LEI die Dokumente anspricht. Mach mal einen Agent der dieses Verhalten simuliert. Du wirst feststellen das der Agent bei der Verwendung von GetNextDocument dasselbe Verhalten zeigt. Was bei mir dann geholfen hat war den Refresh für die Ansicht aus der er die Dokumente geholt hat abzuschalten

Der Sleep wird nichts bringen, eher den Lauf auf maximal 20000 Dokumente zu begrenzen und dann halt 5 mal zu starten.

[Gandhi]

D.h. der LCConnection.fetch arbeitet genauso, wie ein getNthDocument???

Mittlerweile bin ich soweit ausdrücklich von der Verwendung von LEI in solchen Sachen abzuraten.
Das wäre dann wohl noch das finale Argument.
Ich teste es jetzt dennoch mal mit dem Sleep Befehl - auch wenn mir Deine Erklärung in gewisser Weise plausibel erscheint (von der Argumentation vollkommen - warum IBM so was dann so implementiert überhaupt nicht).

Die Resultate von der Sleep Geschichte erwarte ich dann am Montag - jetzt erst mal raus aus dem Büro aber

Vielen Dank für den Hinweis! Dann werde ich wohl das SQL Statement, dass die Daten auswählt verändern müssen, um das Resultset klein zu halten...

[Gandhi]

Also, beides leider Fehlschläge.
Zunächst habe ich mal alle 5000 Einträge einen Sleep 300 (5 Minuten eingebaut)
Dann habe ich die SQL Abfrage in Seiten mit je 5000 Einträgen unterteilt und separat verarbeitet (Je 5000 Einträge aus einer großen Tabelle rausgeholt.
Beides hat nichts geholfen - die Performance geht weiter herunter.

Jetzt bin ich aktuell auf der Suche nach einem Memory Leak - da zeichnet sich aber eigentlich nichts Signifikantes ab.

Ich weiß ja nicht, wie das Euch da draußen geht - aber bislang habe ich mit LEI, wann immer es auch nur um einen Hauch mehr ging als simpel Daten von A nach B zu schieben nichts als Ärger und Frust erlebt.  So, das musste jetzt mal raus...