Schräg viele Volltext-Schreibvorgänge des Update-Tasks

[SD]

Guten Tag allerseits,

hat hier zufällig jemand Erfahrung mit Performance-Tuning von Volltextindizierung auf dem Server? Ich habe einige Best Practice Guides gewälzt, finde aber nichts, was sich wirklich um mein spezielles Problem dreht.

Konkret geht es um folgende Situation:

2 Domino-Server im Cluster (10.0.1 FP3), jeweils ca. 350 User haben den einen und nochmal so viele den anderen als Homeserver. Jede Maildatenbank hat einen Volltextindex (ohne Anhangsindizierung, Update immediate) auf dem Homeserver, die Cluster-Replik hat keinen. Also jeder Server hat ca. 700 Maildatenbanken, wovon jeweils die Hälfte indiziert ist.

Die Server sind virtuell und wir haben die Volltextindexe auf beiden Servern auf eine separate Festplatte ausgelagert, weg vom Data. Außerdem laufen zwei Update-Tasks und Fulltext läuft in separaten Tasks. Also folgende INI-Settings:
FTBASEPATH=F:\
FT_FLY_INDEX_OFF=1
UPDATERS=2
UPDATE_FULLTEXT_THREAD=1

Unsere Infrastruktur-Admins melden nun, dass die Server extrem viel Schreiblast erzeugen würden. Im Monitoring-Tool sieht man auch, dass eben diese Festplatte F:\ wirklich sehr viel beschrieben wird den lieben langen Tag. Im Prinzip ist das auch verständlich, da der Server ja den ganzen Tag die Volltextindexe aktuell hält, aber das Ausmaß macht mich doch stutzig.

Pro Server sind alle Volltextindexe zusammen ca. 200 GB groß. Also alles, was auf F:\ liegt, zusammen. Über das Process-Monitor-Tool kann ich mir anzeigen lassen, wieviel jeder Task seit dem letzten Reboot geschrieben hat. Dieser Reboot ist jetzt ziemlich genau 24h her und beide Update-Tasks haben jeweils jetzt schon über 200 GB geschrieben, siehe Anhang.

Da frage ich mich, wie das denn sein kann?! Soweit ich das sehen kann, arbeitet der Task viel mit temporären Files und sortiert dann nochmal um, usw., aber innerhalb von 24h die gesamte Größe aller Volltextindexe zusammen zwei mal komplett neu schreiben? Das erscheint mir irrwitzig viel. Das ist auch ein vielfaches der gesamten Datenmenge, die der Server in diesen 24h gewachsen ist. Kann das normal sein, oder ist da irgendwo der Wurm drin? Kann die Config sowas verursachen, oder muss da ein Defekt vorliegen? Ich kann mir schon vorstellen, das ~350 Indexe mit immediate Update viel Last erzeugen, aber am Ende müsste es doch irgendwie im Verhältnis zum Datenwachstum + Overhead stehen. Und nur die Hälfte der Datenbanken auf dem Server hat einen Volltextindex, also geht es um die Hälfte des Datenwachstums des Servers + Overhead.

Viewupdates müsste der Task auch machen, aber nicht auf F:\, sondern auf anderen Festplatten, die allerdings sehr viel weniger (Schreib-)Last haben.

[SD]

Moin,

falls irgendjemand mal das selbe Problem hat und auf diesen Thread hier stößt:

Die Volltextindexe von Immediate auf Hourly umstellen macht tatsächlich einen enormen Unterschied bei der Schreibmenge. Dank On-The-Fly-Indizierung mit Domino 10, wenn nicht zu viele Dokumente unindiziert sind, stört es die User auch (offenbar) nicht wirklich. Die Datenbank muss aber mindestens ODS 53 haben dafür.

Außerdem sollte man seinen Message Tracking Task im Blick behalten. Mutmaßlich irgendwie defekte Volltextindexe können dazu führen, dass der Updater schreibt und schreibt und gar nicht mehr wirklich aufhört mit schreiben. Das betrifft wohl auch gerne mal den Volltextindex der mtstore.nsf (aber auch andere). Ein gelegentlicher Reindex schafft Abhilfe. Generell sollte man wahrscheinlich monitoren, ob irgendwelche Volltextindex plötzlich deutlich größer sind, als die Datenbank, die sie indizieren. Das ist dann eher kein gutes Zeichen.