本文へジャンプ

ソフトウェア > Lotus > Lotus Developer Domain > 

Iris Today Archives

セマフォー パート1


 Lotus Software
by Carol Zimmet and Laura Rutherford (with Michelle Pflaum)
レベル：上級者
対象：Domino 5.0
原文の掲載：1999年11月1日

Iris Today Archivesの原文

インデックス
セマフォーとは
なぜセマフォーのタイムアウトが発生するのか？
セマフォー・タイムアウトのメッセージを読み取る
メモ
トラブルシューティング - 情報の収集
NOTES.INI の設定を変更する
トラブルシューティング ‐ 情報を読み取る
メモ
まとめ

非常に交通量が多く、渋滞が発生する交差点に信号が無いとしたら、そのありさまは想像を絶する混沌とした世界となるでしょう。しかし、交差点に信号機があれば交通の流れがきちんと制御され問題がなくなります。これと同じように、これから紹介するセマフォーは、信号機と同じ役割をドミノの中で果たして、サーバーがスムースに動作させる役割を担っており、ドミノ サーバーのタスクを制御します。ドミノ サーバーの管理者は、ドミノ・システムを効率よく動作させ信頼性を高く保たせるために、このセマフォーをサーバー・アーキテクチャーの一部として理解しておく必要があります。

セマフォーに関しては、パート1、パート2および補足資料で解説を行っていきます。パート1では、セマフォーがなぜタイムアウト・メッセージを発するのかというメカニズムの説明と、そのメッセージの読み取り方とトラブルシューティングを行うにあたってのヒントを紹介します。パート2では、実際に発生するシナリオを基にセマフォー・タイムアウト・メッセージのトラブルシューティングについて解説していきます。また併せて、セマフォーに関する問題を最小限にするためのヒントについても触れていきます。

セマフォーとは
セマフォーとは、サーバーが別のタスクを開始する前に、あるタスクを確実に終了させるためのフラグです。マルチタスクのシステムでは、効率よくかつ確実に処理を行う上で、このセマフォーはキーとなる要素といえます。

ノーツ/ドミノでは、あるタスクが行われている間はセマフォーをセットしてリソースやオブジェクトに対してロックをかけ、タスクが終了するとロックを解除する仕組みになっています。例えば、Indexerタスクがインデックスを再構築している間は、セマフォーをセットして他のタスクがビューを使えないようにします。他のタスクからビューを開く要求が来た場合には、インデックス再構築後、セマフォーが解除されるまで待つことになります。

では、セマフォーが解除されるまでタスクはずっと待ち続けるのでしょうか？いつまで待たなければならないのか、という点はシステムをスムースに動かす上で当然気になるところです。ドミノ サーバーの内部では、タスクがどれくらい待たされているかを記録しており、notes.ini に DEBUG_SHOW_TIMEOUT がセットされている場合には、待ち時間が30秒を越えるとタイムアウトの(内部的な)通知が発生します。これを受けて、セマフォーのハンドリング・ロジックに従ってメッセージをサーバー・コンソールに表示、ログに記録します。ユーザー・タスクはセマフォーが解除されるまで ("semaphore holder"と呼ばれるセマフォーを保持するタスクが終了するまでの間) ずっと待ち続け、30秒おきにタイムアウトの通知を発生する仕組みになっています。複雑な処理が行われている場合は、何度ものタイムアウトに見舞われながらセマフォーの解除を待つことになります。場合によってはシステム・パフォーマンスが低下する、あるいはサーバーが停止してしまうこともあり、そのような場合にはタイムアウトを起こしていることすら表示されなくなってしまいます。
 
上に戻る
 
なぜセマフォーのタイムアウトが発生するのか？
セマフォーのタイムアウトが発生する理由は様々です。例えば、あるタスクがセマフォーのフラグを設定して、そのまま解除しないままでいることがあります。（詳細は、後述の発生理由の一覧を参照してください。 ）この場合、そのセマフォー解除を待っているタスクはずっと待ったままになってしまいます。必ずしも、セマフォーのタイムアウト・メッセージの全てが重大な問題が発生していることを意味しているわけではありません。セマフォーのタイムアウト・メッセージは、サーバーに負荷が過度にかかっている場合にも起こり得るものだからです。したがって、問題となるものと、一時的に発生し問題にならないものを見分けることが重要になってきます。それについては、これから説明します。
セマフォーのタイムアウトが発生する理由には以下のものがあります。
  • サーバーに過度の負荷がかかっていて、セマフォー解除の処理が遅れている場合。
  • セマフォーのデッドロック　-　2つのプロセスがそれぞれ一つずつリソースをロックしている状態において、各プロセスがお互いのリソースの解放を待っている状態などを指します。それぞれのタスクが「待ち」をかけたままループに入ってしまい、そこから脱することが不可能になります。
  • タスクの実行時にセマフォーの解除をし損じたプロセスがあると、セマフォーで待ちに入っているプロセスはそのセマフォーによりずっとブロックされたまま「待ち」の状態となります。
  • スクリプトあるいはプログラムの出来が悪く、同時に同じデータベースに対して操作を行なおうとした場合。比較的小規模エンド・ユーザー環境で動作確認ができたものでも、実際に大規模な実稼働環境で動作させると問題がでる場合があります。

セマフォーのタイムアウトが発生しているか否かは、以下の何れかの方法で確認できます。
  • ドミノ サーバー・コンソールで、Show Stat Sem.Timeouts とコマンドを打ちます。タイムアウトが発生している場合は、以下のようなメッセージが表示されます。
    Sem.Timeouts= 430D:58 0A12:42 030B:28 0116:26 0A12:21
  • ドミノ サーバー・コンソールを確認して、以下のメッセージが出ていないかどうかを確認します。
    Session semaphore held for [n] seconds
    notes.ini の DEBUG_SHOW_TIMEOUT の設定がされているかを確認してください。尚、このメッセージやエラーは、ドミノ・ログ・ファイルには記録されません。

 
上に戻る
 
セマフォー・タイムアウトのメッセージを読み取る
メッセージを読むためには、まずシステムからメッセージを取り出す必要があります。それには、いくつかの方法があります。ドミノでは、セマフォーのタイムアウトのタイプと回数を内部的に保持しており、その内容はサーバー・コンソールから、Show Stat Sem.Timeouts とコマンドを打つと表示されます。このようにタイムアウト・メッセージは、サーバー・コンソールに表示できる以外に、テキスト・ファイルとして (SEMDEBUG.TXT) 出力できます。テキスト出力をするには notes.ini を編集する必要があります。詳細は、後述の「トラブルシューティング -情報の収集-」のセクションをご覧ください。ここでは取り出したデータの読み取り方について説明していきます。

セマフォーのタイムアウト・メッセージの解読方法を習得できると、問題のエリアを絞り込むことが可能なため、問題解決が容易になります。ここでは、サンプルのセマフォー・タイムアウト・メッセージを使って解読方法を説明します。このメッセージは一例であり、内容はメッセージ毎にそれぞれ異なります。

THREAD [009F:00BE-0012] WAITING FOR RWSEM 0x4245 open database queue semaphore (@01070246) (R=0,W=1,WRITER=009F:00AF-0025,1STREADER=009F:00AF-0025) FOR 5000 ms

太字で示した内容は、ドミノ R5 で新たに加わった情報が表示されたものです。
 
上に戻る
 
メモ
この文章の中で用いられる用語は、プロセスやスレッドのアーキテクチャーを持ったプラットフォーム（Windows NT、UNIX、OS/2 ）にのみ適用されます。プロセス ID はドミノのアドイン・タスク、あるいはドミノのサーバー・タスクと対応しています。タスクの殆どがマルチスレッドで動作しているため、複数のスレッドが一つのプロセスと結びついています。プロセスをサポートしていても、スレッドをサポートしていないプラットフォーム ( Netware や Windows 95/98の場合）は、セマフォーの扱いは若干異なります。

例の中にある、0x4245 が問題となるセマフォーです。この 0x4245 に続くテキスト(この場合には、open database queue semaphore)は、要求されているセマフォーの種類を簡潔に示しています。特定のセマフォーと関連しているアクティビティーの情報については、パート2 で説明する予定です。

以下の表は、例に示したセマフォー・メッセージの中の識別子から分析する方法をまとめたものです。特定のタスクに対応したスレッド識別子については、「トラブルシューティング - 情報を読み取る -」をご覧ください。

表1
識別子 意味
[009F:00BE-0012] 009F は、セマフォーを要求したプロセスを示しています。009Fは抜粋した形であり、それに対応するレコードが実際のプロセス ID となります。この ID は、他のプロセスがセマフォーを設定している可能性がある状況下で、さらにセマフォーをロックしようとしているプロセス名を示しています。
[009F:00BE-0012] 00BE は仮想スレッド ID を示しています。00BE は抜粋した形であり、それに対応するレコードが実際の仮想スレッド ID となります。この値はドミノ内部で使われているもので、実行中のスレッドを示すものです。
[009F:00BE-0012] 0012 は OS が理解できるスレッド ID を示しています。この情報は今後のデバッグの作業を行う上で重要となるもので、カスタマー・サポートでトラブルシューティングをする上で必要となってくるものです。物理的なスレッド情報表示は、R5 で取り入れられたスレッド・プール・アーキテクチャーの改良により可能になりました。
009F:00AF 009F は、セマフォーを最後にロックしたプロセスを示しています。AF は、仮想スレッド ID を示しています。

上記の例では、同じプロセス (009F) があるセマフォーにアクセスしようしているものの、ロジック (コード) 中において異なるポイントで実行されている別のスレッドがあることを示しています。一つのスレッドがセマフォーを設定しており、他のスレッドをブロックしている状況を示しています。実際に発生するセマフォーのタイムアウトがこのように複雑なわけではありません。しかし、この例では読み取りが難しいものの一つとして紹介しました。

セマフォー・タイムアウト・メッセージを読み取る上での詳細な情報については、セマフォー (Sem.Timeouts)分析をご覧ください。また、Lotus Customer Support Techote #112710 Semaphores and Semaphore Timeoutsをご覧ください。

 
上に戻る
 
トラブルシューティング - 情報の収集
セマフォーのタイムアウト・メッセージを分析してその重要度を測るには、さらに情報を収集する必要があります。一般的に、自分のシステムにおいてそれぞれのアクティビティーが異なるレベルでどのように動作しているかを知っている必要があります。このセクションでは、関連する情報の収集と分析方法についてのアドバイスをまとめています。

パート2 では、トラブルシューティングについての追加情報も提供します。日々お客様のところで発生するトラブルなどを観察中に得られた、実際に起こるセマフォー・タイムアウトのシナリオ情報を中心に説明します。

セマフォー・メッセージは、ドミノ・ログ・ファイルに書きこまれません。そのため、その情報をまず収集することがトラブルシューティングを行う上で重要なステップとなります。以下に示した情報収集の進め方が手助けになると思います。

「アクティブでない」動作時と「アクティブな」動作時、それぞれのシステムの挙動を調べる
「アクティブでない」動作時とは、早朝などユーザー・アクセスが少なく、サーバーにあまり負荷がかからない状態を指しています。「アクティブ」な状態とは、ユーザーが同時にログオンしている状態で、午前中や午後の業務が集中する時間帯を意味しています。

そういった「アクティブでない」時間帯を見計らって、ドミノ サーバーの挙動調査を行っておくと、「アクティブ」な状態でのドミノ サーバーの挙動の違いを把握しやすくなります。また、このようにして調べておくと、短時間の観察では気がつきにくい、じわりじわりとした変化でも、あるいは急激に変化が発生した場合にでも、「アクティブではない」時や「アクティブな時」それぞれに対するパフォーマンスのインパクトを見定めることができます。また、その変化が通常時の正常範囲の物か否か、また時間の経過と共に増えるデータベースの利用頻度によるものか否か、あるいは新規のアプリケーション追加に伴なうものかなどについて見極めが行えるようになります。

調査を行う際には、ドミノ サーバーのコンソールに以下のコマンドを打込んで、その出力から情報を集めます。
  • Show Stat Sem.Timeouts
    ドミノ サーバーが起動してから発生した、Sem.Timeouts の回数とタイプを表示します。
  • Show Stat Server.Users
    現時点でのアクティブなユーザー数を表示します。
  • Show Stat Database.DbCache.AverageDbOpenTime
    ユーザーからの要求、あるいはサーバー自身からの要求に対して、データベースを開くのに要した平均時間を秒単位で表示します。
  • Show Tasks
    サーバーの状態と現在起動しているタスクの状況と動作内容について表示します。
  • Show Perf
    日時とトランザクションの数、現在アクティブなユーザー数を1分間隔で継続的に表示します。
  • Show Dbs
    データベースのパフォーマンスに関する情報が表示されます。例えば、データベースがオープンされた回数、データベースへの書き込み回数、データベースがロックされていたためにユーザーが待った回数などが表示されます。ちなみに、このコマンドは R5 で新たに加わったものです。
  • 様々なツールを利用する
    以下に示すツールを使ってアクティブなプロセスやアクティビティー・レベル、スレッド ID の値を取得できます。先ほど示したセマフォー・メッセージで示されたプロセス情報を手掛りにして、以下に示すツールのアウトプットから問題のプロセスを特定できます。
  • Perfmon
    Windows NT プラットフォームでは Perfmon を使用すると、OS 乃びドミノのコンポーネントのパフォーマンスに関する情報を収集できます。特に、プロセスの統計情報を介して各アドイン・タスクについてアクティビティーの動作レベルを確認できます。
  • Windows NT のタスク・マネージャー
    このツールを使用すると、各タスクのプロセス ID を識別できます。ID を確認するには、プロセスのタブをクリックしてイメージ名の列に表示されるプロセス名 (イメージ名の列に表示) とプロセスID (PIDの列に表示) から読み取ります。セマフォー・タイムアウト・メッセージの中で記されたプロセス ID をタスク・マネージャーで表示される ID と照合すると、タスク名を確認できます。詳細に関しては、Lotus Customer Support Techote #175384 How To Utilize SEMDEBUG.TXT and Task Managerをご覧ください。
  • Qslice
    Windows NT のプラットフォームの場合は、このツールを使って、その時点でのアクティブなタスクを表示さできます。ここでは、プロセス ID とそのプロセスの中で動作している物理スレッド ID を表示します。
  • NSD
    ドミノのエンジニアが開発したもので、現在のところ UNIX プラットフォーム上でのみ動作するツールです。( UNIX 版のパッケージに同梱されています。) このツールでは、疑わしいスレッドのスタックを表示します。詳細については、Troubleshooting recommendations for UNIX（US） をご覧ください。
 
上に戻る
 
NOTES.INI の設定を変更する
notes.ini の様々な設定を変更すると、問題の解決につながるものが見えることがあります。必要に応じて、以下のものを「有効」に設定してみてください。

表2
NOTES.INI の設定内容 意味
DEBUG_SHOW_TIMEOUT=1 サーバー・コンソールにタイムアウト・メッセージを表示します。
DEBUG_CAPTURE_TIMEOUT=1 ドミノ サーバーがセマフォー・タイムアウト・メッセージをコンソールにレポートする間隔を指定します。デフォルトは 30 で、基本的に変更しないでください。ロータス・カスタマー・サポートとのやりとりの中で必要な場合にのみ変更します。
DEBUG_SEM_TIMEOUT=n ドミノ サーバーがセマフォー・タイムアウト・メッセージをコンソールにレポートする間隔を指定します。デフォルトは 30 で、基本的に変更しないでください。ロータス・カスタマー・サポートとのやりとりの中で必要な場合にのみ変更します。
DEBUG_THREADID=1 DEBUG_OUTFILE から得られるメッセージ中においてプロセスやスレッド ID との関連づけを行います。
LOG_UPDATE =2
LOG_VIEW_EVENTS=1		 データベースおよびインデクサーに関連したより深い詳細な情報を探る場合に使用します。
NSF_BUFFER_POOL_SIZE=value この設定は、1サーバーあたりのパーディションが一つの場合に使用し、複数のパーディションがある場合には使用しません。その場合は、デフォルト値を使用してください。(現状では空きメモリーとオーバーヘッド値(固定) に基づいて計算する仕組みになっています。
この値の算出方法の詳細については、Optimizing server performance: Port encryption and Buffer Pool settings（US）、あるいは、Deploying Domino R5 for performance and scalability(US)をご覧ください。
SERVER_MAX_CONCURRENT_TRANS=n ドミノからより高い性能を引き出して、多数のユーザーが同時にサーバーにアクセスした場合でもある一定のレベルの動作を保証するために使用するものです。デフォルトは 20 です。これを増やすと、使用できるセマフォーを増加できます。また、非常に負荷の高い動作時にサーバーがより効率的な動作をするようにできます。この設定は最新のスレッド・プール・アーキテクチャーの改良をされているドミノ R5 には適用されません。
SERVER_SHOW_PERFORMANCE=1 過去1分のトランザクションと現在のサーバー・ユーザー数を1分おきにサーバー・コンソールに出力します。
DEBUG_OUTFILE=path file name サーバー・コンソールへのアウトプットをキャプチャーしてファイルへ出力します。この際、DEBUG_THREADID と併せて使用します。この内容から、メッセージとプロセスやスレッド ID を特定できます。この機能は、ディスク・スペースと CPU パワーを消費しますので、必要のない時には「無効」にしてください。さらに詳細な情報に関しては次をご覧ください。Lotus Customer Support Technote #162400、 How Should the DEBUG_OUTFILE Parameter Be Implemented?（US）

ドミノ サーバー・コマンドと notes.ini の設定に関する詳細については、ドミノ R5 システム管理者ヘルプをご覧ください。
 
上に戻る
 
トラブルシューティング ‐ 情報を読み取る
多くの場合、原因として考えられるものをひとつずつ取り除くことで、問題の原因を特定する手順を踏むことになります。ここでは、セマフォー・タイムアウトのトラブルシューティングを行うにあたっての手順を示します。

ドミノ・ログ・ファイルから読取る
セマフォーの挙動について調査を行なうにあたって、最初にあたるべきものはドミノのログ・ファイルです。ログ・ファイルにはドミノ サーバー・コンソールに出力された内容が記録されています。特に、Show Stat Server.Users や Show Stat Sem.Timeouts を打ち込むと一定時間内に起きたアクティビティーも記録されますので手掛りとなります。

サーバーのトレンド・パターンを見分けるには、ドミノ サーバーのログ・ファイルを1日ベースや1週ベースで分析する必要があります。さらに詳しいモニターが必要な場合には、1時間から４時間単位でサーバー・コンソールの表示内容をキャプチャーする事が必要になることもあります。トレンド・パターンを把握した上で、ログ・ファイルの出力された Server.Users と Sem.Timeouts を観察すると、両者の関係を見つけやすくなり因果関係の特定に役にたちます。また、ドミノ サーバーに接続しているユーザーが増えるにしたがってどのように Sem.Timeouts が発生するかを確認しやすくなります。ログを見て Sem.Timeouts のメッセージが見当らないからと言って、Sem.Timeouts のメッセージが出ていないわけではありません。ログには記録されないものの、コンソールには出ています。またその合計は内部的に積算されています。

LOG_UPDATE と LOG_VIEW_EVENTS で得られる内容を確認する
セマフォーの問題がデータベースあるいはインデクサーに関連したものであると思われる場合は、LOG_UPDATE と LOG_VIEW_EVENTS を notes.ini に設定して、出力される内容をドミノのログで確認します。

LOG_UPDATE の設定では、インデックス (Update タスク) のアクティビティーに関する情報（具体的には、データベースの名称、更新されたビューの名称、その他状態を表す内容）を設定できます。LOG_UPDATE が設定されると、ビューの更新が行われる度に即座にドミノ サーバー・コンソールにメッセージが表示され、ビューのインデックスが最新のものになります。（各ビューをチェックする毎にドミノ サーバー・コンソールにメッセージが表示されます。）

LOG_VIEW_EVENTS コマンドで出力される内容からは、アクティビティーのが行われている理由、すなわちそのアクティビティーが何を行っているかが分かります。例えば、あるビューの再構築が行われている際には、同時に Update タスクはビューの再構築を行っている状態を示します。また、いつ、どのビューが再構築されたかを確認できます。そして、この情報から原因追求の手掛りを引き出すこともできます。例えば、あるビューのインデックスが繰り返し短い間隔で再構築されている場合、ディスクの空きスペースを確認するとよいでしょう。空きスペースが十分にないとビューの再構築ができずに何度でも繰り返すことになるからです。通常システム管理者から普通に見ている範囲では、単にビューの更新を繰り返しているだけにしか見えません。

DEBUG_THREADID で得られる内容を確認する
ドミノのログ・ファイルでは、DEBUG_THREADID から得られる出力を見て、DEBUG_OUTFILE ファイルのメッセージとプロセスIDやスレッドIDを関連づけを行えます。それにはDEBUG_THREADID から OS のプロセスとその ID を特定する必要があります。プロセス ID の詳細については、「トラブルシューティング - 情報の収集」のセクションをご覧ください。

Database.DbCache.AverageDbOpenTime で得られる内容を確認する
この統計内容では、ドミノ サーバーのデータベースをユーザーから、あるいはサーバー内で開いた時の平均所要時間を秒単位で記録しています。この統計内容を継続的に監視することで、データベース・オープンにかかる時間のトレンドを把握できます。(これはシステムの負荷が総じて安定していることが条件となります。あまりばらつきがあるとトレンドを見い出しにくくなります。) この値はシステムの過負荷を含めてシステムの問題の警告として利用できますが、一つのデータだけで、サーバー全体の状態を把握することはできませんので、他の統計情報も検討して全体を把握するように心がけてください。

ドミノ・アドイン・タスクのアクティビティーを確認する
ドミノ サーバーのログの内容とセマフォー・タイムアウトの変化を時間軸から観察する場合は、ドミノのアドイン・タスクの状況についても確認します。アドイン・タスクはドミノのコア・タスクから呼び出される場合などは、関連しながら動作しているため、アドイン・タスクが原因を作っている場合があります。

Show Tasks コマンドを実行するとアドイン・タスク名の横にステータスを示すコメントが出てきます。これから、そのタスクが現在どのような状態にあるか、どのような動作をしているかを確認できます。タスクが止まったと思われる時に、一定の時間ごとにこのコマンドを発行した際に、ステータスの変化がないものは、本当にタスクが止まってしまったと判断できます。但し、非常に大きなビューを再構築する場合などでは該当しないことがあります。そのため、それぞれのシステムの構成や動作の傾向を知っておくと原因の誤認を防げます。

ドミノ サーバーのユーザー数を確認する
ドミノ サーバー・コンソールからのメッセージ、あるいはドミノ・ログを確認する際には、ドミノ サーバーのユーザー数を、トランザクション数と共に見てください。ユーザー数の表示を行なうには、notes.ini の設定に、SERVER_SHOW_PERFORMANCE をセットします。あるいは、ドミノ サーバー・コンソールで Show Perf コマンドを実行してください。これ以降は、ドミノ サーバーのユーザー数が自動的にサーバー・コンソールに表示され、ログにも記録されます。この表示は1分おきに行われるようになっています。表示される内容は、日時、過去1分間のトランザクション数、現在のアクティブ・ユーザー数です。

Sem.Timeouts の内容を分析する
Sem.Timeouts で出力される内容には、セマフォー・タイムアウトのタイプと回数が含まれています。この出力では、複数のセマフォー・タイムアウト・タイプが一覧できます。モニターを行っている間にタイムアウト数が急激に増えた場合は、その時間帯に発生したアクティビティーが怪しいと思われますので、さらに調査を行います。一般的には1時間に 5 から 10 程度で増えている場合には詳細な調査が必要です。

SEMDEBUG.TXT や STATREP.NSF (統計情報が記録されています) に記録された詳しい出力とドミノ・ログ・ファイルから、特定のセマフォーのタイムアウトの発生頻度が高い時間帯を特定できます。また、どの製品群からセマフォー・タイムアウトが発生しているのかを判断できます。(例えば、どのドミノ サーバー上のタスクが何かの作業を実行しようとしているものの、それがブロックされているかなど。)Sem.Timeouts の内容詳細について、特にどれくらいの頻度でどのタイムアウトが発生しているかをトラックする場合は、 セマフォー (Sem.Timeouts)分析 やLotus Customer Support Techote #112710 Semaphores and Semaphore Timeoutsをご覧ください。
 
上に戻る
 
メモ
Sem.Timeouts の統計情報は任意のタイミングで初期化できません。最初に値が取得した以降の統計値が表示される仕組みになっていますので、読み取るときには注意してください。

セマフォー・タイムアウト・メッセージの分析
notes.ini に DEBUG_CAPTURE_TIMEOUT=1 を設定するとセマフォー・タイムアウト・メッセージが SEMDEBUG.TXT に書き込まれます。各プラットフォームのツール (Windows NT の場合は、NT タスク・マネージャー) を使って、書き込まれた内容を解釈していきます。そうすると、どのタスクがセマフォー・タイムアウトと関係しているのかが分かってきます。メッセージの解読方法については、前述の「セマフォー・タイムアウトのメッセージを読み取る」をご覧ください。

不必要なアドイン・タスクを外す
可能な範囲で不必要なドミノ サーバーのアドイン・タスクを外します。ここでのアドイン・タスクとは、ドミノをインストールした時に入っているタスクやユーザー側で開発、購入して追加でインストールしたものを指します。これらのタスクのいくつかを外すことで、サーバーの負荷を下げリソースの競合を下げられます。特に、サーバーの過負荷が原因でセマフォー・メッセージが出ている場合には有効です。外す順番については、ドミノに付属しているタスクよりも、外部で開発したアドイン・タスクを先に外すことを推奨します。ドミノ付属のアドイン・タスクはロータスで開発していることから、外部で開発したアドイン・タスクと比べて競合や動作の低下の原因を作っている可能性が比較的低いためです。一時的にアドイン・タスクを外してみて、動きに変化がないかを見てみます。セマフォー・メッセージがでなくなった場合、あるいはその間隔に変化があった場合、異なるメッセージを出し始めた場合には、それを手がかりにその因果関係をさらに詳細に調べていくことになります。

NSF_BUFFER_POOL_SIZE を見直す
基本的に notes.ini のデフォルト値を引き続き使うことを推奨します。もし、他の値に変更した場合には、システム設定の変更を行った場合や新しいドミノ・リリースにアップグレードした場合に、その度に設定値を見直す必要があります。以上に示した、「デフォルト値を使う」ガイドラインは、シングル・パーディション・サーバーにのみ適用され、複数のパーディション・サーバーの場合は当てはまりません。

SERVER_MAX_CONCURRENT_TRANS を確認する
notes.ini の設定値が高くなっていないか確認してみます。デフォルト値は 20 ですが、増やす場合には 20 きざみで行なうことを勧めます。ノーツ・クライアントがタイムアウトを起こす場合には、この値が高いことが考えられます。この設定に関する詳細については、パート2で説明を行う予定です。

DEBUG_SEM_TIMEOUT のデフォルト値を変更する
ロータスのサポートとのやりとりの中で必要な場合にのみ変更してください。
DEBUG_SEM_TIMEOUT は、セマフォーがブロックされていることを管理者に通知する間隔、つまりどのくらいの間セマフォーのブロックが発生すると問題とみなして通知を行うかを制御しています。基本的に、デフォルトの 30 から変更する必要性は特にないと思われます。

30 以外の推奨値は 60 です。しかしながら、これを行なうにあたってはサーバーの挙動に対する理解や何を行なおうとしているかについて理解した上で判断することが必要となります。例えば、サーバーの負荷が高いほどセマフォーのタイムアウト・メッセージが出やすいため、このようなサーバーでは意図的に値を変える場合があります。サーバーの負荷に起因するセマフォーのタイムアウト・メッセージであることが予め分かっている場合ならば、この値を増やしてメッセージの表示を減らすことが可能です。
 
上に戻る
 
まとめ
りません。正常に動作しているシステムでもセマフォー・タイムアウト・メッセージは出るのです。ここで大切なのは、セマフォー・タイムアウト・メッセージの意味するところを理解して対処することで、如何にサーバー・システムを効率的に運用し、信頼性の高いものにしていくかということです。

今回の文章では、「セマフォーとは何か」、「なぜ発生するのか」、「発生したときの確認方法」などが理解できたかと思います。また、タイムアウト・メッセージが意味するところと、その原因を探る方法についても把握できたことと思います。パート2では、ここで示したもの以外のトラブルシューティング方法を、実際に発生するシナリオを例にとって説明していく予定です。さらに、セマフォー関連の問題発生を最小限にとどめるヒントについても触れていく予定です。
 
上に戻る