Semaphore

[ebse]

Hallo Zusammen,

habe den Parameter

Code

DEBUG_SHOW_TIMEOUT=1

in unsere "Notes.ini" aufgenommen um die "Semdebug.txt" zu bekommen und aufgetrettene Timeouts zu analysieren.

Nun das Problem: Das einzigste was in der SEMDEBUG.txt steht ist

Code

SEMDEBUG_NOTES-PROD01_2006_05_10@06_00_02.TXT

Kann ich damit irgendwas anfangen?? der Parameter steht seit vorgestern drin, wir hatten gestern Timeouts!
Nach recherchen müsste dort aber viel mehr drinstehen... anbei auch noch ein Screenshot der Konsole zum Zeit des Timeout (dieser ist von heute, gestern sahs genau gleich aus)!

Wo könnte der Fehler liegen, dass das SEMDEBUG File nicht richtig geschrieben wird?

!!Bin für jeden Hinweis echt DANKBAR!!

[Ralf_M_Petter]

Hallo!

Du bekommst die Informationen nur auf der Console angezeigt. Um Sie in die Datei zu kriegen musst du noch DEBUG_CAPTURE_TIMEOUT=10 angeben. Siehe auch http://eknori.dyndns.org/knowledge/kbnv11.nsf/0/0437a986b2564578852565f4007c9103?OpenDocument

Grüße

Ralf

[ebse]

Vielen Dank erstmal dazu.

Wohin schreibt er dann das File??

Und kann es sein das er jetzt schon was in die LOG.nsf geschrieben hat?? hat irgendwas auf der Konsole angezeigt von "logged to D:\Notes\Date\log.nsf" (oder so ähnlich). In der Log.nsf find ich aber nichts.

Außerdem hab ich noch diesen Wert über "sh stat sem.timeouts" bekommen, was sagt dieser aus?

Code

Sem.Timeouts	0244:549 012E:94 0A12:21 041A:13 012D:3 0147:2 0A0B:2 0931:1 0921:1 

Kann man mit dem zuvor geposteten screenshot schon was anfangen??

DANKE IM VORRAUS!

[Ralf_M_Petter]

Sollte unter IBM_TECHNICAL_SUPPORT sein.

Nein rein aus dem Screensho kann man wenig erkennen, da er nicht vollständig ist. Was du auf jeden Fall auch noch brauchst, ist ein Tool mit dem man schauen kann, welche Threadid was ist. Eventuell wäre auch noch ein Tool gut mit dem man den Stacktrace des Threads anschauen kann. Wir verwenden, Domino auf der Iseries, da ist das alle im Betriebssystem integriert und kann bequem über wrkactjob eingesehen werden.

Zu den Semdebug Meldungen.

Darin findest du die Meldung welcher Thread auf welchen Semaphore wartet und von welchem Thread der momentan belegt wird. Du musst nun sozusagen, die Threads von hinten nach vorne verfolgen um den Thread zu finden, der den ersten Semaphore blockiert und nicht mehr freigibt.

Prinzipiell sind Semaphore eine Technologie mit der Domino verhindert, dass verschiedene Threads gleichzeitig eine Aktion durchführen, die nicht gleichzeitig gemacht werden darf. Ein Beispiel Thread A sagt, ich möchte die view xy updaten. Dann darf das kein andere Thread machen. Deshalb setzt Thread A einen Semapore lock für diese view. Wenn nun Thread A aus irgendeinem Grund nie mehr fertig wird mit seinem update. Dann kommt es irgendwann dazu, dass auch andere Threads auf diese Semaphore zugreifen wollen und hängen bleiben. Diese Thread blockieren aber bereits andere Semaphofes und über kurz oder lange, hängt dein ganzer Server. Hoffe ich habe es verständlich erklärt.

Grüße

Ralf

[ebse]

Super Klasse! Danke für die Erklärung!

Was muss ich unter "Thread" vestehen??

Unter Windows2003 Server seh ich die sogenannte "PID (Process ID) im Task Manager. Reicht mir die??

[Ralf_M_Petter]

Jein, soweit ich Windows verstehe sollte die ersten Stellen der ThreadId vor dem Dopelpunkt der PID entsprechen. Insofern solltest du zumindest den Prozess herauskriegen, der dein Problem verursacht. Ein Thread ist eine Unterteilung eines Prozesses. Lies sonst mal in der Wikipedia nach. Eventuell helfen auch die Tools von Sysinternals.

Grüße

Ralf

P.S. Meiner Meinung nach ohne einen Flamewar starten zu wollen, ein gravierender Nachteil von Windows, dass es keine vernünftigen Boardmittel gibt um die laufenden Prozesse zu überwachen.

[ebse]

Ok ich werd mir dann morgen nachdem der Server neu gestartet wurde das SEMDEBUG File anschauen und mich dann evtl. nochmal melden!!

DANKE NOCHMAL!!

[smoki]

Threads laufen parallel auf dem Rechner, ähnlich wie Prozesse.

Im Prinzip besteht jeder Prozess aus mindestens einem Thread. Der Vorteil von Threads ist, dass diese sich innerhalb eines Prozesses den Speicherbereich und die Umgebung (Umgebungsvariable, Userkennung usw.) teilen und verschiedene Teilaufgaben parallel verarbeiten können.

Durch Threads, kann ein Prozess mehrere Aktionen gleichzeitig durchführen, ohne diese Sequenziell abarbeiten zu müssen. Zum Beispiel wartet ein Thread auf die Ergebnisse von der Festplatte, während der andere schon die nächste Usereingabe abfragen kann und ähnliches.

Da sich die Threads einen Speicherbereich teilen, muss unbedingt verhindert werden, dass diese Parallel den gleichen Speicherbereich beschreiben. Die Kommunikation der Threads läuft meistens über Speicherbereiche, die sich die Threads teilen. Diese Bereiche kann sich ein Thread mit einem Mutex oder einer Semaphore kurzzeitig(hoffentlich...) für sich beanspruchen und die anderen Threads warten (bleiben stehen...Suspend), wenn diese nun auch diesen Bereich auch lesen oder bearbeiten wollen.

Problematisch wird es beispielsweise, wenn ein Prozess zwei Threads mit zwei Speicherbereichen hat und nun gliechzeitig folgendes passiert:

Thread 1 nimmt sich nun den Speicherbereich 1
Thread 2 nimmt sich nun den Speicherbereich 2

anschließend wollen beide (praktisch gleichzeig) folgendes tun:

Thread 1 will nun auch Speicherbereich 2 haben
Thread 2 will nun Speicherbereich 1 haben

Jetzt warten die beiden Threads endlos aufeinander (Suspended) und es entsteht ein Dead-Lock!

Um solche Probleme zu verhindern, gibt es verschiedene Ansätze. Der einfachste Ansatz ist, dass es eine festgelegte Reihenfolge gibt, nachdem Gelocked wird. D. h. wenn ein Thread mehrere Speicherbereiche haben möchte, reserviert er diese immer Aufsteigend (oder Absteigend... egal... hauptsächlich einheitlich) . Leider ist dieser Ansatz in der Praxis schwer durchzuhalten oder einer der Programmierer kannte diese Vorgabe nicht und tut es eben falsch.

Ich hoffe, das erklärt es (vereinfacht) in Grundzügen.

Gruss
Chris

[Ralf_M_Petter]

Sehr gute Beschreibung eines Deadlocks. Nur tritt hier offensichtlich nicht ein Deadlock auf, da soweit ich es verstanden habe nach einiger Zeit die Timeouts wieder aufhören. Eventuell kann das der Ursprungposter nocheinmal präzissieren.

Grüße

Ralf

[smoki]

OK.... ergänzend. Der Timeout entsteht, wenn der Thread zu lange wartet (bsp. 30 Sekunden), dadurch wird ein Endlos langer Dead-Lock verhindert. Und ja es kann auch entstehen, wenn ein Thread eine Ressource zu lange bearbeitet. z. B. View-Index neu aufbaut. (Wurde weiter oben ja schon mal erwähnt...)

[ebse]

Vielen Dank mal für die super Erklärung!

Anbei noch ein Auszug aus dem Semdebug File von heute morgen:

Code

ti="00248848-C125716B" sq="00007A67" THREAD [0DF0:0273-0914] WAITING FOR FRWSEM 0x0244 database semaphore (@01E242D1) (D:\Notes\Data\log.nsf) (R=0,W=2,WRITER=0F48:0A08,1STREADER=0000:0000) FOR 30000 ms
ti="00248848-C125716B" sq="00007A68" 456789:;=>?@ABCDEFGH
JKLMNOPQRSTUVXYZ[\]^_`abcdeghijklmnopqrstu·xyz{|}Ú€?‚ƒ„…†‡ˆ‰Š‹Œ?Ž??‘’“”•–—˜™š›œ?žŸ ¡¢£í¥¦§¨©ª«¬­®¯°±²³´µ¶ý`e!00000000: FACE 6600 0244 0000 0000 0000 0000 FFFF   'Nz.fD...........'
00000010: 

ti="002488F5-C125716B" sq="00007A69" THREAD [0DF0:027E-00B8] WAITING FOR FRWSEM 0x0244 database semaphore (@01E242D1) (D:\Notes\Data\log.nsf) (R=0,W=2,WRITER=0F48:0A08,1STREADER=0000:0000) FOR 30000 ms
ti="002488F5-C125716B" sq="00007A6A" 456789:;=>?@ABCDEFGH
JKLMNOPQRSTUVXYZ[\]^_`abcdeghijklmnopqrstu·xyz{|}Ú€?‚ƒ„…†‡ˆ‰Š‹Œ?Ž??‘’“”•–—˜™š›œ?žŸ ¡¢£í¥¦§¨©ª«¬­®¯°±²³´µ¶ý@“E00000000: FACE 6600 0244 0000 0000 0000 0000 FFFF   'Nz.fD...........'
00000010: 

ti="00248945-C125716B" sq="00007A6B" THREAD [0DF0:027D-01AC] WAITING FOR FRWSEM 0x0244 database semaphore (@01E242D1) (D:\Notes\Data\log.nsf) (R=0,W=2,WRITER=0F48:0A08,1STREADER=0000:0000) FOR 30000 ms
ti="00248945-C125716B" sq="00007A6C" 456789:;=>?@ABCDEFGH
JKLMNOPQRSTUVXYZ[\]^_`abcdeghijklmnopqrstu·xyz{|}Ú€?‚ƒ„…†‡ˆ‰Š‹Œ?Ž??‘’“”•–—˜™š›œ?žŸ ¡¢£í¥¦§¨©ª«¬­®¯°±²³´µ¶ýžE00000000: FACE 6600 0244 0000 0000 0000 0000 FFFF   'Nz.fD...........'
00000010: 


Was kann ich jetzt hierraus lesen?? Was hat das

Code

(D:\Notes\Data\log.nsf) 

zu bedeuten??

[Ralf_M_Petter]

Meiner Meinung nach, musst du schauen, was der Thread 0F48:0A08 macht. Das ist der Thread der den Semaphore momentan hat. Dazu nimmst du das Tool von Sysinternals Process Explorer. Dann kannst du den Stacktrace dieses Threads anschauen während er den Semaphore locked. Eventuell sagt uns die Funktion die er ausführt etwas. Sonst kannst du diese Daten an den IBM Support weitergeben. Die finden dann meistens relativ schnell raus, was es hat.

Grüße

Ralf

[m3]

P.S. Meiner Meinung nach ohne einen Flamewar starten zu wollen, ein gravierender Nachteil von Windows, dass es keine vernünftigen Boardmittel gibt um die laufenden Prozesse zu überwachen.

Dafür gibt es ja PSList.

[ebse]

ok..

also so wie ich es verstanden hab ist doch bei "0F48:0A08" der Wert vor dem Doppelpunkt die ProcessID unter Windows in HEX also "3912" in Dezimal... diese ProcessID hat bei uns der Task "ncompact.exe"! Sagt das schon was aus?

Was bedeutet die Zahl hinter dem Doppelpunkt?

[Ralf_M_Petter]

Nun es ist sicher problematisch wenn du Ncompact unter tags laufen lasst, warum macht Ihr das.
Der Wert hinter dem Doppelpunkt ist die Thread ID. Hast du dir schon den Process Explorer von Sysinternals angeschaut. Ist wirklich ein tolles Tool.


Grüße

Ralf

[ebse]

Also könnte es am "ncompact" liegen??

Tool hab ich mir angeschaut. Ist das komplett Freeware auch für den geschäftlichen Gebrauch? Läuft es stabil und verursacht auch keine Fehler auf dem Server?! Erfahrungen allgemein??

EDIT: was hat der Pfad (D:\Notes\Data\log.nsf) in dem SEMDEBUG File zu bedeuten?? kann es sein das er beim komprimieren dieser Datenbank einen Timeout entsteht??

[Ralf_M_Petter]

Soweit ich es beurteilen kann, ist es Freeware. Wir haben keinen Windows Server aber auf dem Client hatte ich noch keine Probleme damit. Laufen lassen würde ich das Tool sowieso zu Zeiten wo es Probleme gibt. Zu Ncompact, je nachdem mit welchen Parametern er läuft, könnte ich mir schon vorstellen, dass der ein Problem macht. Meiner Meinung nach sollte Ncompact nur in der Nacht oder besser noch zum Wochenende laufen.

Grüße

Ralf

[ebse]

Zu Ncompact, je nachdem mit welchen Parametern er läuft, könnte ich mir schon vorstellen, dass der ein Problem macht. Meiner Meinung nach sollte Ncompact nur in der Nacht oder besser noch zum Wochenende laufen.

der compact läuft mit dem Parameter "-B"!

und nochmal die Frage falls es einer oben übersehen hat: was hat der Pfad (D:\Notes\Data\log.nsf) in dem SEMDEBUG File zu bedeuten?? kann es sein das er beim komprimieren dieser Datenbank einen Timeout entsteht??

[Ralf_M_Petter]

Zu deiner Frage möglich, aber kann ich nicht sicher beantworten. Eines ist aber sicher, sehr viele Prozesse und Thread schreiben in die Notes.log Beim komprimieren muß er den zugriff darauf aber sicher immer wieder sperren. Wenn jetzt das Compact länger dauert dann kann das schon ein Problem verursachen. Was ich mich aber noch immer frage, warum machst du ein Compact während der normalen Zeit?

Grüße

Ralf

[Lossa]

Hi,

die compact regelmässig laufen zu lassen ist sehr lobenswert, abär...

Bitte NIE Tagsüber immer nur Nachts.

Auf die Log.nsf, greift der Server permanent zu und wenn diese gleichzeitig compacted wird gibt das definitiv Probleme, nachts ist das weniger los und dann geht es besser.