Server hängt sich auf mit korrupten MTStore-Index

RockWilder · 6. Januar 2006

Moijns allerseits!

Wir haben seit ein paar Tagen das Problem, dass sich einer unserer Mailserver sich hin und wieder aufhängt. Und zwar mit korrupten Volltextindex in der mtstore.nsf

Zitat

06.01.2006 06:52:17 Full Text message: Unexpected error. errcode = 3312
06.01.2006 06:52:17 GTR search error for "[data-directory]\mtdata\mtstore.ft\ftgi": Unexpected error. errcode = 3312: Full text index Corrupt, Try to Delete and Re-add Index
06.01.2006 06:52:17 Full Text message: Unexpected error. errcode = 3271
06.01.2006 06:52:17 GTR search error for "[data-directory]\mtdata\mtstore.ft\ftgi": Unexpected error. errcode = 3271: Full text index Corrupt, Try to Delete and Re-add Index

Dann hält der Server noch ein paar Minuten durch (heute: 07:37:04) und verabschiedet sich dann. Die Fault Recovery bringt dann auch nichts mehr, da er sich dann irgendwann keine Lust mehr zu hat: Too many crashes, restart disabled (max. 3 faults in 5 Minuten)

Woran das liegt, dass er crasht, ist die erste gute Frage (Plattenplatz, Sicherung etc. können wir ausschließen). Die viel wichtigere Frage ist aber im Moment: wie können wir unterbinden, dass immer wieder ein Index auf den Mail Tracker Store gelegt wird? Wenn das unterbleiben würde, hätten wir erstmal etwas Zeit gewonnen.

Wer eine gute Idee dazu hat, darf sie gern kundtun

erzengel · 6. Januar 2006

Auch wenn ich nicht viel Ahnung habe, aber du kannst doch einen Volltextindex über die DB Eigenschaften entfernen und neuanlegen(wenn benötigt). DB Eigenschaften >>> Volltext >>> Index Löschen. Dann sollte die DB auch nicht Volltext indiziert werden.

In der Adminhilfe unter: "Volltextindizes für einzelne Datenbanken" findest da mehr

Zitat

Full text index Corrupt, Try to Delete and Re-add Index

tomthecat · 6. Januar 2006

ich vermute mal folgendes hast du schon probiert:
Index löschen und neu anlegen
Datenbank neu anlegen

Wenn mich net alles täuscht sollte der rebuild vom index auch über MTC erfolgen. Z. B. über ein Programmdokument

Program Name: server
Command Line: -c "tell mtc reindex"

Zeitintervall ist natürlich von deinem message volumen abhängig.

RockWilder · 6. Januar 2006

erzengel: Nun, einen Index zu löschen, das schaff ich grad noch Dank dir trotzdem.

tom: Soweit ich die Hilfe verstanden habe, tut das tatsächlich der MTC. Soweit hast du recht. Nur leider haben wir kein Programmdokument, was den Index neu anlegt. Der Witz an der Sache ist: sobald ich den Index lösche, ist er ein paar Minuten später wieder da. Die DB hab ich noch nicht wieder neu anlegen lassen. Einen Versuch ist es allemal wert.

Die Frage ist also: wie bekomm ich den Index ein für alle Mal weg? Oder wenigstens solange, bis ich ihn manuell anlege.

/edit:
die erwähnten "ein paar Minuten" scheinen wohl mit dem collection interval zusammenzuhängen.- Sobald der collectet, baut der auch den Index wieder hin...

tomthecat · 6. Januar 2006

Ist ewig her....
ich glaub du mußt den FT interval auf scheduled (nach plan) stellen, dies verhindet den index prozess den index zu erneuern... dann greift das MTC über das programmdokument zu und erstellt den index.
glaub ich

Edit:
ich glaube mit scheduled ist "nach plan" auf deutsch gemeint... hab halt nen englischen

RockWilder · 6. Januar 2006

Genau so ist es bei uns eingestellt. Trotzdem kommt der immer wieder.
Hab es grad nochmal beobachtet: pünktlich zum neuen collection intervall wird der Index neu erstellt. Und wie man dem das untersagt, das ist nun die spannende Frage

TorstenM · 6. Januar 2006

Ist dies zufällig ein 6.5.3 unter Linux?

Dann hilft ein Update auf mind. 6.5.4.

Ansonsten fällt mir nur noch ein MTC zu deaktivieren - wenn DB neu anlegen nicht hilft.

tomthecat · 6. Januar 2006

Hm...
also DB neu wäre dann auch meine letzte alternative...

ein paar spinnerein :
Wenn du dem server nur Editor rechte auf die DB gibst... und die index löscht... dürfte er den index net neu anlegen (?) noch nie getestet, weiß nur das es so bei AW geht.

Dann gibt es da ja noch ein paar ini-parameter

Server_Name_Lookup_NoUpdate=1
FT_LIBNAME=ftgtr40.dll

hat aber mehr mit nen speicherfehler zu tun... aber vielleicht hilft es ja auch....

aber alles ohne garantie!!!!

RockWilder · 6. Januar 2006

Nope, ist ein 6.5.4FP1 auf Windows 2003 Server

Was mich auch stutzig macht: der Domino crasht im Allgemeinen morgens. Ausgerechnet dann, wenn am wenigsten los ist. Wir schießen täglich zwischen 500MB und einem Gig über den Server und zwischen halb4 und 6-halb7 ist passiert am wenigsten. Ausgerechnet dann verraucht die Kiste. Um 2 läuft ein updall, um 5 ein statlog. Sonst nichts. Sehr strange das alles...

tom: mit dem Editorzugriff probiere ich es mal. Und wenn die Kiste das nächste mal verreckt, lösche ich die DB. Was die ini-Parameter bedeuten, muss ich mir mal ansehen. Dann schau ich mal, ob es das bringt.

erzengel · 6. Januar 2006

hm, also ich habe Volltext indizierte DBs und einige nicht, wenn der Index startet, sowie Abends ein Programm dass den Volltextindex mit aktualisiert, werden nur die DBs Volltext indziert die auch vorher indiziert waren.

RockWilder · 6. Januar 2006

Jupp, normal ist das auch so.

Zur Info: das ist ein reiner Durchlauferhitzer. Der Server macht den ganzen Tag nichts anderes, außer Mails von A nach B zu verschieben. Keine Replikation, keine Agenten, kein Schnickschnack. Ergo: auch keine Volltextindizes.

Aber es ist halt so, dass der MTC den Index immer neu anlegt. Auch und obwohl ich den Server gemäß toms Tip auf Editor runtergestuft hab. Spätestens das ist mir unbegreiflich...

tomthecat · 6. Januar 2006

Ich würd jetzt vorschlagen: wirf den server aus den fenster und setz ihn neu auf

ne da bin ich am ende mit meinen latein... wie gesagt... last hope neue DB erstellen.... bin dann mal gespannt ob das funkt....

admin · 6. Januar 2006

Moin Ralf,

hattest du die Tecnote dazu schon entdeckt ?

Zitat

Error: "MT Collector: Error Indexing the Message Tracking Store..." and Crash on Message Tracking Collector (nMTC)

Product:
Lotus Domino > Lotus Domino Server > Versions 6.5, 6.0

Platform(s):
Windows 2000

Doc Number:
1109707
Published: 11.08.2005
Technote

Problem

Customers running releases of Domino 6.0.1 and later have experienced a problem with the message tracking store and the nMTC task, which results in the following error being produced on the server:

"MT Collector: Error indexing the message tracking store: Full Text Error - failure to init KV filter"

If this condition is allowed to continue without recycling the server, the following crash may occur:

############################################################
### FATAL THREAD 1/3 [ nmtc:07b0:07ac]
### FP=001265bc, PC=60196953, SP=00125c44, stksize=2424
Exception code: c0000005 (ACCESS_VIOLATION)
############################################################
@[ 1] 0x60196953 nnotes._Panic@4+483 (609a0016,1b1,1265e0,6011c310)
@[ 2] 0x6019671c nnotes._Halt@4+28 (1b1,1052cfc,0,1265e8)
@[ 3] 0x6011c310 nnotes._AccessAllProtected@0+96 (126708,6004f405,1,1)
@[ 4] 0x6004e50f nnotes._AccessAll@8+47 (1,1,0,1052cfc)
@[ 5] 0x6004f405 nnotes._ProcessGlobalEvent@4+21 (1052cfc,1052cfc,0,0)
@[ 6] 0x601a2797 nnotes._OSPerformGlobalEvent@12+167 (1,0,708,6e09750)
@[ 7] 0x6019760f nnotes._DEBUGDumpHandleTable@8+175 (0,0,1052cfc,0)
@[ 8] 0x6011c30a nnotes._AccessAllProtected@0+90 (126a90,6004f405,1,1)
@[ 9] 0x6004e50f nnotes._AccessAll@8+47 (1,1,0,1052cfc)
@[10] 0x6004f405 nnotes._ProcessGlobalEvent@4+21 (1052cfc,126f04,6e095e0,606d9ab5)
@[11] 0x6004f311 nnotes._OSProcessShouldQuit@0+49 (126f04,126f04,0,428)
@[12] 0x06c06e5d gtr40nts.CGtrExtentMgr::Pin+45 (99,12882c,1,6e09804)
@[13] 0x06c0604c gtr40nts.CGtrSharedBlockMgr::ReadSlot+364 (6e0d8c4,6d9c208,6e0388c,6e00f28)
@[14] 0x06c038c0 gtr40nts.CGtrPosLow::Internalize+64 (6e00f38,0,6e01f70,6e00f28)
@[15] 0x06c01edd gtr40nts.CGtrPosBrokerMulti::Internalize+157 (6e0388c,0,12e104,2)
@[16] 0x06bff215 gtr40nts._gtrMergeMerge+277 (6e00f28,6e063e0,12d17c,0)
@[17] 0x06bccc35 gtr40nts._gtr_MergePatt+3685 (73e62a4,73ebb74,56000029,12e098)
@[18] 0x06bcb463 gtr40nts._GTR__mergeIndex+2419 (6e00020,297286,0,6c1e690)
@[19] 0x06be5939 gtr40nts._GTR_mergeIndex+1241 (10933c8,12e658,12e758,12e858)
@[20] 0x06b8cc5f nFTGTR40.cGTRio::Merge+223 (1170000,723ffdc,1ea0,68)
@[21] 0x06b89f70 nFTGTR40.FTGMergeGTRIndexes+80 (723ffdc,0,724001a,12f874)
@[22] 0x06b82860 nFTGTR40._FTGIndex@16+4688 (1098bec,0,188,0)
@[23] 0x601d7506 nnotes._FTCallIndex@20+38 (12f874,1098bec,723ffdc,188)
@[24] 0x601d8158 nnotes._FTIndexExt@20+3128 (a3,188,0,12f964)
@[25] 0x601d83ba nnotes._FTIndex@16+26 (a3,100,0,12f964)
@[26] 0x0040ea3f nmtc.MTIndex::Index+79 (a3,5,3e8,0)
@[27] 0x0040ce2e nmtc.MTStore::Index+78 (1068c78,108d038,402090,0)
@[28] 0x004037d0 nmtc.IndexStore+64 (12fdbc,0,384,256d09)
@[29] 0x0040291b nmtc.processLogs+1883 (1,bf3b94,7ffdf000,7d3)
@[30] 0x004012ee nmtc._AddInMain@12+718 (400000,1,bf3b94,20a)
@[31] 0x0040598f nmtc._NotesMain@8+47 (1,400000,20a,21a)
@[32] 0x00405a96 nmtc._main+246 (0,0,0,1)
@[33] 0x004059b6 nmtc._main+22 (1,c026e0,c02708,20a)
@[34] 0x00405e23 nmtc._mainCRTStartup+197 (20a,21a,7ffdf000,0)
Called from 77ea847e (0001:0002747E in c:\notes\KERNEL32.dll) Base=0x77e80000 RVA=0x00001000

Solution

This issue was reported to Quality Engineering and has been addressed in Domino 6.0.4 and 6.5.2.

Excerpt from the Lotus Notes and Domino Release 6.0.4 and 6.5.2. MR fix list (available at http://www.ibm.com/developerworks/lotus/):

MTC
SPR# BRIS5MLK8N - Fixed a problem where MTC (Message Tracking Collection) crashes when out of virtual address space about once a week on Windows, when running Domino as a service. This regression was introduced in 6.0.

Temporary workaround:

Deleting the MTDATA directory usually resolves the problem temporarily [refer to the document "MT Collector: Error Indexing the Message Tracking Store: Full Text Error - Failure to Init KV Filter" (#1138702Lotus Software Knowledge Base) for more information], but customers generally report a recurrence after about two weeks.

More permanent workaround:

The following workaround resolved the issue for at least one customer who was crashing multiple times per week. After implementing this workaround, no crash recurred during the 3 months it was monitored:

Set a Program document to purge the MTSTORE more frequently. Currently, the default is every 30 days. You can increase this by running a Program document to issue the following command:
tell mtc purge value
...where value is the maximum number of days. Set this to 7 (you may want to start with 14 if 7 seems too aggressive), and then run this command via a Program document once a week during off hours.

Another workaround if still an issue:

If the problem persists after adding the purge, the following may help:

Setup a Program document to run Updall -x once a week against the MTSTORE.NSF (this will rebuild the full text index and keep it compact.)

Additionally, add the following NOTES.INI parameters:
PRIVATE_DPOOLSIZE_THRESHOLD=65536
PercentAvailSysResources=70
The first will force Domino to make requests directly to the O.S. for any private memory allocations greater than 64K, helping to reduce fragmentation (memory dumps seem to indicate this may be playing a part in the problem) and improve utilization. The second parameter will reduce the initial size of the buffer pool, allowing more memory to be available for individual tasks. The second value can be set lower if necessary, but care should be taken as overall performance may be affected.

Note that the default value for PRIVATE_DPOOLSIZE_THRESHOLD is 512K.

Related Document Links

MT Collector: Error Indexing the Message Tracking Store - Document 1138702

Related Attachments

Alles anzeigen

boemitsu · 6. Januar 2006

----EDIT----
hmm...irgendwie hatte ich übersehen, dass schon etliche Beiträge existieren...
----EDIT----

Hello,

Irgendwie sollte das doch gehen, dass man einen existierenden FTI löschen kann und auf dieser einzelnen DB verhindern, dass erneut einer erstellt wird...Aber leider habe ich nichts passendes gefunden.

Einzig ein kleiner Workaround _könnte_ evtl. funktionieren....

Den FTI auf der DB löschen und das Update Intervall auf Scheduled setzten.

Auszug aus Admin Help
As scheduled by a Program document for the Updall server task in the Domino Directory.
Note If you select the Scheduled option, you must specify a schedule for Updall in a Program document; otherwise, ! scheduled updates will not occur. !

...dann setzen wir halt keinen Schedule... :lol:

Ansonsten wär noch das notes.ini

Update_No_Fulltext=value

...aber glaub nicht, dass ihr den FTI auf allen DB's disablen wollt.

HTH,
Michael

RockWilder · 6. Januar 2006

Dank dir Detlef. Ich hab mal das Programmdokument erstellt. Schau 'mer mal, ob das ausreicht.

Jedenfalls allen ein schönes WE

tomthecat · 6. Januar 2006

Hm... das mit den purge kannte ich jetzt noch net... bin ja mal gespannt!
Dir auch ein schönes WE!

RockWilder · 12. Januar 2006

Was auch immer das Problem war, es tritt nicht mehr auf. Ob es das compact war, oder nicht, das kann ich nicht mit Gewissheit sagen. Aber immerhin...

Server hängt sich auf mit korrupten MTStore-Index

Teilen

Benutzer online in diesem Thema