Semaphore Fehler nach dem Update

[Tannibal]

Hallo zusammen,

ich habe heute unseren Haupt Domino-Server auf 9.0.1 migriert.
Nach dem Update erhalte ich nach 30 Minuten die ersten Semaphore Meldungen. Nach einiger Zeit reagiert der Server dann garnicht mehr.
Ich denke, das Problem ist, dass aktuell Konsistenzprüfungen auf fast allen Datenbanken laufen. (alter Server lies sich nie sauber herunterfahren)

Ich habe dazu auch gerade ein Ticket bei IBM aufgemacht, aber vlt weiß hier auch jemand rat.

Vielen Dank.

Hier die Meldungen:

Code

[09B0:0076-0178] LkMgr Conv Timeout ------------------ [09B0:0076-0178] Nest=0
[09B0:0076-0178] Lock(Mode=IS   LockID(DB DB=F:\mail\xx.nsf)) countNonIntentLocks = 0 countIntentLocks = 5, queuLength = 1
[09B0:0076-0178]    Req(Status=Granted Mode=IS Class=Commit Nest=0 Cnt=1(Hold - count should be 1)
[09B0:0076-0178]        Tran=0 Func=N/A \rmtran.cpp:161 [0FFC:001F-02D0])
[09B0:0076-0178] rm_lkmgr_cpp:2121
[09B0:0076-0178] rm_lkmgr_cpp:1354
[09B0:0076-0178] rm_rmtran_cpp:1512
[09B0:0076-0178] dbbktbuf_c:143
[09B0:0076-0178] dbfixup_c:14135
[09B0:0076-0178] dbfixup_c:13960
[09B0:0076-0178] dbfixup_c:12124
[09B0:0076-0178] dbfixup_c:682
[09B0:0076-0178] dbload_c:1394
[09B0:0076-0178] dbload_c:97
[09B0:0076-0178] dbopen_c:862
[09B0:0076-0178]    Req(Status=Granted Mode=IS Class=Commit Nest=0 Cnt=1(Hold - count should be 1)
[09B0:0076-0178]        Tran=0 Func=N/A \rmtran.cpp:161 [0FFC:0023-087C])
[09B0:0076-0178] rm_lkmgr_cpp:2121
[09B0:0076-0178] rm_lkmgr_cpp:1354
[09B0:0076-0178] rm_rmtran_cpp:1512
[09B0:0076-0178] index_buf_c:3121
[09B0:0076-0178] index_dbbuf_c:3563
[09B0:0076-0178] dbfixup_c:9223
[09B0:0076-0178] dbfixup_c:7251
[09B0:0076-0178] dbfixup_c:6036
[09B0:0076-0178] dbfixup_c:12431
[09B0:0076-0178] dbfixup_c:14135
[09B0:0076-0178] dbfixup_c:13960
[09B0:0076-0178] dbfixup_c:12124
[09B0:0076-0178] dbfixup_c:682
[09B0:0076-0178] dbload_c:1394
[09B0:0076-0178] dbload_c:97

Code

ti="004A4115-C1257CA3" sq="00000619" THREAD [09B0:0089-0F68] WAITING FOR WRITE LOCK ON FRWSEM 0x4245 open database queue semaphore (@01A1B8B8)  (R=0,W=1,WRITER=09A8:05BC,1STREADER=0000:0000) FOR 30000 ms
ti="004A4118-C1257CA3" sq="0000061A" THREAD [09B0:0098-0F9C] WAITING FOR WRITE LOCK ON FRWSEM 0x4245 open database queue semaphore (@01A1B8B8)  (R=0,W=1,WRITER=09A8:05BC,1STREADER=0000:0000) FOR 30000 ms
ti="004A4122-C1257CA3" sq="0000061B" THREAD [09B0:00A2-0FE8] WAITING FOR WRITE LOCK ON FRWSEM 0x4245 open database queue semaphore (@01A1B8B8)  (R=0,W=1,WRITER=09A8:05BC,1STREADER=0000:0000) FOR 30000 ms
ti="004A41E5-C1257CA3" sq="0000061C" THREAD [09B0:009C-0F08] WAITING FOR WRITE LOCK ON FRWSEM 0x4245 open database queue semaphore (@01A1B8B8)  (R=0,W=1,WRITER=09A8:05BC,1STREADER=0000:0000) FOR 30000 ms
ti="004A4265-C1257CA3" sq="0000061D" THREAD [0C2C:0002-0C44] WAITING FOR WRITE LOCK ON FRWSEM 0x4245 open database queue semaphore (@01E6B8B8)  (R=0,W=1,WRITER=09A8:05BC,1STREADER=0000:0000) FOR 30000 ms
ti="004A43AD-C1257CA3" sq="0000061E" THREAD [0B40:0002-0B24] WAITING FOR WRITE LOCK ON FRWSEM 0x4245 open database queue semaphore (@019FB8B8)  (R=0,W=1,WRITER=09A8:05BC,1STREADER=0000:0000) FOR 30000 ms
ti="004A46BC-C1257CA3" sq="0000061F" THREAD [09B0:009D-0FB8] WAITING FOR READ LOCK ON FRWSEM 0x4245 open database queue semaphore (@01A1B8B8)  (R=0,W=1,WRITER=09A8:05BC,1STREADER=0000:0000) FOR 30000 ms
ti="004A478A-C1257CA3" sq="00000620" THREAD [09B0:00AA-0F4C] WAITING FOR WRITE LOCK ON FRWSEM 0x4245 open database queue semaphore (@01A1B8B8)  (R=0,W=1,WRITER=09A8:05BC,1STREADER=0000:0000) FOR 30000 ms
ti="004A4878-C1257CA3" sq="00000621" THREAD [09B0:00AE-0FC0] WAITING FOR READ LOCK ON FRWSEM 0x4245 open database queue semaphore (@01A1B8B8)  (R=0,W=1,WRITER=09A8:05BC,1STREADER=0000:0000) FOR 30000 ms

[m3]

Disk ist defragementiert?
Dreh mal den http, router, ... task ab, bis er mit den checks fertig ist.
Mach die fixups/compacts bei abgeschaltetem Server.

[Tannibal]

Die Disk ist eine ISCSI LUN auf einer Netapp. Die letzte Aussage, die ich dazu im Internet gefunden habe war, dass man dort nicht defragmentieren darf/soll.

Werde ich versuchen, ich berichte dann

[m3]

OK, das sollte man wirklich nicht

[Tannibal]

Wie so oft, "Abwarten und Tee trinken" hat geholfen
Server ist wieder zum Leben erwacht, als die Prüfung fertig war. Aktuell laufen noch einige DBs aber das Gröbste ist geschafft.

Danke und Schönes Wochenende!

[Tweeks]

Und ich dachte, wir wären die einzigen mit diesem Problem 
Bei uns verhält sich der eine Server nach jedem Update so. Sein komplett identischer Clusterpartner allerdings nicht.
Wie du schon sagst, einfach 30min warten und es tut wieder.
IBM hat auch keine Ahnung woran es liegt.

Aber mit der Zeit gewöhnt man sich dran^^

MfG
Matthias

[J Parlin]

... was hab ich mir auf dem SAN wegen der Semaphoren einen abgebrochen. Defragmentierung geht ( leider _ da scheiden sich aber noch die Geister auf dem SAN wegen der Defragmentierung ) wegen dem SnapCreator nicht. Bei uns liefen auf den Aggregaten zu viele Maschinen und Backups teilweise parallel, was die Domino-Machinen nicht mochten, die wurden ihre Daten nicht richtig los ....  IBM tat natürlich auch ahnungslos, bis wir das Problem eingrenzen konnten. Wir haben dann z.B. mit HD-Tune Performancemessungen auf den LUNs gemacht, dann war das dann klar, das das Datenwegschreiben nicht performant genug war. 

[Tode]

@J Parlin: Das ist genau auch meine Erfahrung. Wann immer ich bisher Probleme mit Long Held Locks, Performance- Probleme, seltsame Phänomene hatte, dann liess sich das fast immer auf fehlenden Datendurchsatz zurückführen. Einmal war der falsche Treiber in den virtuellen Maschinen eingebunden, dann waren es Parameter der SAN, dann wieder einfach zu viele gleichzeitige Operationen auf dem SAN, aber immer hatte der Domino darunter zu leiden... Alle anderen Systeme liefen einwandfrei, also muss es ja am Domino liegen und KANN gar nicht an SAN / Netzwerk liegen...

Ist oftmals ein Kampf gegen Windmühlen, bis man mit Hilfe von Performance- Messungen / Windows Logs / etc. bewiesen hat, dass die Schreib- Queues der Disks immer grösser werden und deshalb der Server beinahe steht...

[Tannibal]

Da ich letztens wieder eine Ausfall hatte, bin ich wieder auf das Problem gestoßen, dass der komplette Server hing.
Wieder ein Ticket eröffnet und endlich eine Antwort bekommen
-> fixed in 9.0.2 , 9.0.1 FP1 release
http://www-10.lotus.com/ldd/fixlist.nsf/Public/5EA65ACFED7442E785257C850005C4A9?OpenDocument