Seltsamer Domino-"Absturz"

Wir haben seit längerem in unregelmäßigen Abständen immer wieder mal ein Problem, ausgerechnet mit unserem zentralen Haupt-Server.

Generelle Infos unten, hier erst mal wie's generell abläuft:
Ich (oder ein Kollege hier) bekomm einen Anruf, Domino ginge nicht mehr. Kurzer Check - Domino reagiert nicht mehr. Cluster Node findet ihn nicht mehr und zeigt massig Failover (funktioniert i.d.R. auch ganz gut). Also auf die Kiste mit "MSTSC /console" drauf. Domino Fensterchen steht da brav vor sich hin. Nun kannman einen(!) der folgenden Befehle noch eintippen "sh u", "sh ta", "sh serv". Dann kommt dazu die Ausgabe, danach geht nichts mehr. Bei allen anderen Befehlen (einshcließlich "q") passiert nichts. Garnichts. Die Ausgaben der drei Befehle die noch gehen sind - wie sollte es hier auch anders sein - unauffällig. An diesem Punkt hilft dann wirklich ncihts mehr außer Tasks abschießen oder "nsd -kill" und Dienst wieder neu starten.

Eckdaten:
Windows Server 2003 Standard Edition, SP2
Lotus Domino 6.5.6 FP2
Trend Micro 3, Build 3500 (SP3 + Hotfix)
läuft auf einem FuSi-Blade, 2 DualCore Opterons, 4 GB RAM

Hab hier vom letzten "Hänger" auch noch einen äußerst ausführlichen 30MB-NSD-Dump. Das einzige was auf ein Problem hindeutet - die Fehlermeldungssammlung am Ende des Dumps:

ERROR (0): Bad chunk desc 0
ERROR (0): Bad memchunk desc 0 (256)
ERROR (0): NSD thread 10f8 got system exception: ACCESS_VIOLATION (3221225477)
ERROR (0): exception(0): NSD thread 10f8 got system exception: ACCESS_VIOLATION (3221225477)
ERROR (0): Invalid task VTID=102

Wenn jemand noch Infos braucht zum helfen liefere ich gerne nach. Auf Grund der Fülle an Daten die da interessant sein könnten, verzichte ich jetzt aber mal darauf blind alles hier rein zu schießen.

So weit war ich auch schon. Hätte mich oben vielleicht nochmal deutlicher ausdrücken können: den NSD starten ich wenn dann manuell! Da ist kein Panic, kein Fatal, kein Error - NICHTS! Domino "steht" einfach vor sich hin. Im Taskmanager kann man noch beobachten wie sich der Speicherverbrauch mancher Domino-Prozesse im KByte-Bereich noch ein bisschen ändert (auch länger). CPU zieht aber kein Task mehr. Und wie schon gesagt: auf der Konsole tut sich nichts mehr. Er nimmt auch keine Befehle mehr an. Von außen ist der Task tot.
Witzigerweise lauschen aber noch alle Domino-Tasks laut "netstat -ano" auf ihre Ports, sprich, es werden auch keine Sockets geschlossen. Nur antworten tut auf den Ports auch keiner mehr...

Wenn es nur so einfach wäre... Gibt es bei uns natürlich nicht. Wir haben keinen Virenscanner im System - nur einen Domino-Integrierten, der auch nur die Mails scannt. Arbeitet aber nach wie vor einwandfrei - schon alles gecheckt.

DaSi läuft über TSM OnlineAgent. Sichert das ganze Ding im Online direkt über Notes-APIs weg. Äußerst sauber, äußerst elegant, äußerst Problemlos. Übrigens: auch das hatte ich heute Vormittag nochmal alles bis ins kleinste Winkelchen zerpflügt --> keinerlei Hinweise auf Probleme.
Das Tool werd ich mir gleich mal anschauen. Vielen Dank dafür schon mal!

So, hab nun nocheinmal ein paar Informationen zu meinem Problem eingeholt. Danke erst mal für die Tips mit den Semaphore-Debug-Parametern. Scheinen der richtige Weg zu sein.
Habe jetzt mal zwei Fälle verfolgen können...

1.

aus der SEMDEBUG:

ti="002B7702-C12574AF" sq="00273297" THREAD [1300:0034-1C98] WAITING FOR SEM 0x0931 Task sync semaphore (@4C79EAA2) (OWNER=1300:2278) FOR 30000 ms

PID "1300" gehört in diesem Fall der nserver.exe

2.

aus der SEMDEBUG:

ti="0041A6B8-C12574B7" sq="00098978" THREAD [0D14:0CC7-0EF4] WAITING FOR SEM 0x0931 Task sync semaphore (@4E62A7B2) (OWNER=0D14:1040) FOR 30000 ms

PID "0D14" gehört in diesem Fall ebenfalls der nserver.exe

Wenn ich mir in beiden Fällen die Timestamps entsprechend umrechne, kommt das mit dem zeitpunkt wo die ersten Beschwerden aufgetreten sind gut zusammen. Kann mir also durchaus vorstellen, dass das die Ursache ist.

Wo ich nun wieder eure Hilfe oder zumindest ein paar Denkanstöße bräuchte:
1.) Kann so ein Semaphore-Timeout/-Lock derartige Probleme verursachen
2.) Wofür genau ist der Semaphore 0931? Jaja, "Task sync". Kann mir auch einigermaßen an den Haaren herbeiziehen was das heißen könnte, aber was ist es genau?
3.) Was kann Ursache dafür sein und noch viel wichtiger, wie löse ich das ganze, sollte es die Ursache unserer Probleme sein?

Hoffe ein Freak von euch kann mir hier weiterhelfen! Wäre wirklich sehr dankbar. Sammle auch gerne noch weitere Daten, falls das hilfreicher sein könnte.

:cry: keiner ne Idee?

Also hier mal die Infos für den ersten beschriebenen Fall - da hatte die nserver.exe die PID 1300...

Der Owning Thread:

############################################################### thread 95/120: [ nSERVER:  1300:  2278] ### FP=1609fd90, PC=7c8285ec, SP=1609fd20### stkbase=160a0000, total stksize=262144, used stksize=736############################################################ [ 1] 0x7c8285ec ntdll.KiFastSystemCallRet+0 (6108,ffffffff,0,1609fdd4) [ 2] 0x77e61c8d kernel32.WaitForSingleObject+18 (6108,ffffffff,ed24a4,ed24a2)@[ 3] 0x600a75c7 nnotes.WaitOnNativeSemaphore@16+135 (6000023b,ed24a4,60c9594c,0)@[ 4] 0x600f0416 nnotes.WaitOnNativeSemaphoreCounted@12+22 (6000023b,ed24a4,0)@[ 5] 0x60008f3d nnotes.OSLockWriteFRWSemInt@12+333 (ed24a2,1,0)@[ 6] 0x60008de0 nnotes.OSLockWriteFRWSem@4+16 (ed24a2)@[ 7] 0x6019d69f nnotes.OSWaitFairEvent@8+15 (ed24a0,0)@[ 8] 0x1001a459 nserverl.DbServer@8+265 (cf3b0119,88140068)@[ 9] 0x1002f0e4 nserverl.WorkThreadUtilityTask@8+1076 (4c79e9d4,0)@[10] 0x100016cb nserverl.Scheduler@4+763 (0)@[11] 0x60114b24 nnotes.ThreadWrapper@4+212 (0) [12] 0x77e64829 kernel32.GetModuleHandleA+223 (60114a50,0,0,fffe0129)

Waiting Processes:

1300 - (1300):[E:\notes\prog\nSERVER.EXE =E:\notes\prog\notes.ini:  1300]

Aus dem Thread-zeugs werde ich aber noch nicht schlau :-/
Falls da jemandzufällig tiefergehende Informationen zu soetwas hat, bitte immer her damit! Würde mich da gerne tiefer einarbeiten und nicht nur etwas an der Oberfläche kratzen. Dann muss ich euch das nächste mal bei so einem Problem nicht mehr auf den Senkel gehen

Und leider mal wieder ein kompletter Freeze

Betroffenes Semaphore: 0x034C (NAMELookup Thread Queue)

Owning Threads:

Zitat

############################################################
### thread 48/57: [ nRouter: 1dc4: 1274]
### FP=581de00c, PC=7c8285ec, SP=581ddf9c
### stkbase=581e0000, total stksize=262144, used stksize=8292
############################################################
[ 1] 0x7c8285ec ntdll.KiFastSystemCallRet+0 (11e8,ffffffff,0,581de050)
[ 2] 0x77e61c8d kernel32.WaitForSingleObject+18 (11e8,ffffffff,0,10826aa)
@[ 3] 0x600a75c7 nnotes.WaitOnNativeSemaphore@16+135 (9,0,60c95084,0)
@[ 4] 0x600d4c31 nnotes.OSWaitEvent@8+97 (10826aa,0)
@[ 5] 0x60114ba9 nnotes.OSCreateThread@16+89 (6090cbd0,40000,50c74ce8,0)
@[ 6] 0x6090ca3b nnotes.NAMELookupAcquireThread@12+443 (581de0c4,0,cb4c05)
@[ 7] 0x609011f8 nnotes.ThreadedNAMELookup@48+24 (0,200,0,0,0,581de0c8,f10f10,ffffffff,0,0,0,0)
@[ 8] 0x600ab168 nnotes.NAMELookup2@36+264 (0,0,1,60a6926c,0,581de118,f10f10,ffffffff,0)
@[ 9] 0x60966190 nnotes.MailExpandNamesInternal@28+640 (0,0,0,57f53f94,0,581de5f8,f10f10)
@[10] 0x60965ce6 nnotes.MailExpandNamesExt@32+598 (0,0,0,4ac7,0,581de758,f10f10,ffffffff)
@[11] 0x6096942c nnotes.MailNameInAddress@32+1372 (8ee19ec,24,581df120,2f,0,581dee90,f10f10,ffffffff)
@[12] 0x609557ff nnotes.MailDeliverMessage@68+527 (14c5000,2ab,7,8ee19ec,0,581df32c,f10f10,ffffffff,0,0,0,0,0,0,0,0,0)
@[13] 0x00411a7b nRouter.AttemptMessageDelivery@48+1019 (14c5000,581dfdd8,0,0,0,581dfa90,f10f10,ffffffff,0,0,0,0)
@[14] 0x004113e2 nRouter.DeliverToDestination@32+1842 (448260,581dfdd8,0,8221fa0,0,581dfc4c,f10f10,ffffffff)
@[15] 0x0040e87c nRouter.Transfer@32+588 (448260,95c0001,1,581dfdd8,0,581dfca4,f10f10,ffffffff)
@[16] 0x00417562 nRouter.TransferThread@4+658 (1)
@[17] 0x60114b24 nnotes.ThreadWrapper@4+212 (0)
[18] 0x77e64829 kernel32.GetModuleHandleA+223 (60114a50,0,0,905a4d)

Alles anzeigen

Zitat

############################################################
### thread 41/122: [ nSERVER: 1ddc: 1f80]
### FP=1262fd54, PC=7c8285ec, SP=1262fd28
### stkbase=12630000, total stksize=262144, used stksize=728
############################################################
[ 1] 0x7c8285ec ntdll.KiFastSystemCallRet+0 (2d20,1262fd90,1262fe04,1262fd88)
@[ 2] 0x60994859 nnotes.iocp_ProcessNativeIOCP+89 (11bb450,5dc,1262fe4c,1262fe00)
@[ 3] 0x6098f26d nnotes.iocp_WaitForStatus@20+93 (13b80001,5dc,1262fe64,1262fe4c,0)
@[ 4] 0x6098dca8 nnotes.nti_GetQueuedCompletionStatus@20+40 (13b80001,5dc,1262fe64,1262fe4c,0)
@[ 5] 0x60987541 nnotes.PortDriver_IOCPWaitForAnyIO@16+81 (13b80001,5dc,1262ff20,1262ff1c)
@[ 6] 0x6073f5c7 nnotes.NetIOCPWaitForAnyIO@20+55 (86d80001,13b80001,5dc,1262ff20,0)
@[ 7] 0x1002e2ec nserverl.WorkThreadTask@8+348 (2893be4,0)
@[ 8] 0x100016cb nserverl.Scheduler@4+763 (0)
@[ 9] 0x60114b24 nnotes.ThreadWrapper@4+212 (0)
[10] 0x77e64829 kernel32.GetModuleHandleA+223 (0,0,0,0)

Alles anzeigen

Waiting Threads:

Zitat

1DC4 - (1DC4):[E:\notes\prog\nRouter.EXE : 1dc4]
1DDC - (1DDC):[E:\notes\prog\nSERVER.EXE =E:\notes\prog\notes.ini: 1ddc]

Nachdem ich heute endlich mal einen Ausführlicheren NSD mit Dump machenkonnte habe ich heute richtig viele Infos. Besonders erwähnenswert findet Sandbox bei dem einen Owning Thread vom Router:

Zitat

High number of handles (11165) for shared memory block 0x8405 - BLK_IDTABLE

Dieser Thread hatte zum zeitpunkt des Freeze laut Sandbox ein paar User-MailDBs im Zugriff, alle 4 mail.box und sämtliche über DirectoryAssistance eingebundene Names.

Vielelicht nützliche Infos zum Process Memory:
Virt. Size war auf 1.5G
Work set size 1.4G
Max. work set size 1.3G
Handle Count 2041

Hat nicht zufällig einer eine Idee?

Irgendwo ein Freak, der jede Zeile Code im Domino auswendig kennt? Oder jemand, der genau das Problem täglich behebt? Oder irgendwer, der von irgendwem gehört hat, wie das problem behoben werden kann?

Mir würde ja auch schon ein Schubser in die richtige Richtung helfen wie ich an die Ursache kommen könnte. Bin leider mit dem Problem hier etwas überfordert und IBM sagt nur: Update auf 8 und alles wird gut. Ja klar, weil wir mal eben unsere 500 Anwendungen auf Domino 8 testen und die 180 Server updaten können... Scherzkeckse!

Die einfachsten Dinge sind ja oft die, die übersehen werden - aber auch das hatten wir schon getan. Wir haben das Problem in der Tat schon das erste mal im Februar und dann zweimal im März. Wie es im Mai das vierte mal auftrat haben wir neu installiert.
Aber wie ihr seht, ist das problem noch immer vorhanden.

Wenn aber neu installieren nichts gebracht hat, können wir aber auch shcon wieder irgendwelche Fehlerhaften Domino-Dateien ausschließen. Entweder ist es dann ein problem unserer Konfig, ein Problem der Hardware/des OS darunter oder tatsächlich ein Bug der (mal wieder) nur bei uns auftritt...

ja klar.
Wir gehen bei Neuinstallationen sowieso immer os vor, dass wir die ini aus der Installation übernehmen und nur einen wohl ausgewählten Satz an Einstellungen dort rein kopieren, alles andere wichtige kommt über die Configdokumente mit rein.
Letztere hatten wir bei der Installation unsere Sorgenkindes nocheinmal einer kritischen Prüfung unterzogen und liegen mit jeder einzelnen Einstellung auf BestPratice-Level :-/

Wir haben in unserer Domäne auch noch 12 andere Server, die absolut identisch konfiguriert sind - als bestes Beispiel das Cluster-Mitglied zu unserem Sorgenkind. Der einzige Unterschied ist ide Anzahl der aktiv auf dem Server arbeitenden User.

Also scheint es ein problem zu sein, das vor allem unter Last-Situationen zu diesem Freeze führt...

Die Frage ist: was kann man dagegen machen? Die Hardware sollte das eigentlich abkönnen. HDD-Read/Write-Speed, CPU und Memory haben physikalisch noch Reserven, HDD-Queue ist zwischendurch auch immer mal wieder auf 0. Bin da echt am Verzweifeln!