| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionトラブルシューティング・ガイド 11g リリース 1 (11.1.1.7.0) B72443-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionトラブルシューティング・ガイド 11g リリース 1 (11.1.1.7.0) B72443-01 |
|
前 |
次 |
この章では、Directory Serverで発生する一般的な問題をトラブルシューティングする方法について説明します。内容は次のとおりです。
この項では、クラッシュしたDirectory Serverプロセスのトラブルシューティングを開始する方法について説明します。クラッシュの考えられる原因、問題を特定するために収集する必要のある情報および収集した情報の分析方法について説明します。
クラッシュは、次の1つ以上が原因で発生する可能性があります。
バッファのオーバーフロー
リソース(メモリー、ディスク、ファイル記述子など)の不足
メモリー割当ての問題(ダブル・フリー、未割当ての空きメモリーなど)
NULL参照解除
その他のプログラム・エラー
Directory Serverのプロセスがクラッシュした場合、Sunのサポート・センターを使用して、サービス・リクエストを開始する必要があります。
この項では、サーバーがクラッシュしたときに収集する必要のあるデータについて説明します。収集する最も重要なデータは、コア・ファイルです。
|
注意: クラッシュしたDirectory ServerプロセスについてSunのサポート・センターに連絡する場合、コア・ファイルとログを提供する必要があります。 |
コア・ファイルおよびクラッシュ・ダンプは、プロセスまたはアプリケーションが異常終了したときに生成されます。サーバーがクラッシュしたときにDirectory Serverがコア・ファイルを生成できるように、システムを構成する必要があります。コア・ファイルには、クラッシュ時のDirectory Serverプロセスのスナップショットが含まれるため、クラッシュの原因を特定するために不可欠な場合があります。コア・ファイルはerrorsログと同じディレクトリに書き込まれ、デフォルトではinstance-path/logs/です。コア・ファイルにはエントリ・キャッシュが含まれるため、サイズが非常に大きくなる場合があります。
コア・ファイルが自動的に生成されない場合は、次の表に示すコマンドを使用して、コア・ダンプを許可するようにオペレーティング・システムを構成してから、次のクラッシュを待ってデータを取得します。
| プラットフォーム | コマンド |
|---|---|
|
Solaris |
および ulimit -c unlimited ulimit -H -c unlimited |
|
Linux |
ulimit -c unlimited ulimit -H -c unlimited |
|
HPUX/AIX |
|
|
Windows |
|
たとえばSolaris OSでは、次のコマンドを使用して、アプリケーションでコア・ファイルを生成できるようにします。
# coreadm -g /path-to-file/%f.%n.%p.core -e global -e process \
-e global-setid -e proc-setid -e log
path-to-fileには、生成するコア・ファイルのフルパスを指定します。ファイルの名前には、実行可能ファイル名(%f)、システム・ノード名(%n)およびプロセスID (%p)が使用されます。
コア・ファイル生成を有効にしてもシステムがコア・ファイルを生成しない場合は、オペレーティング・システムで設定されているファイルサイズ書込み制限の変更が必要な可能性があります。ulimitコマンドを使用して、次のように、コア・ファイルおよびスタック・セグメントの最大サイズを変更します。
# ulimit -c unlimited # ulimit -s unlimited
次のように-aオプションを使用して、制限が正しく設定されていることを確認します。
# ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) unlimited coredump(blocks) unlimited nofiles(descriptors) 256 vmemory(kbytes) unlimited
Red Hat LinuxおよびWindowsでのコア・ファイル生成の構成の詳細は、それぞれのオペレーティング・システムのドキュメントを参照してください。
次に、kill -11 process-idコマンドを使用して、アプリケーションでコア・ファイルが生成できることを確認します。コアは、指定したディレクトリまたはデフォルトのinstance-name/logsディレクトリに生成されます。
# cd /var/cores # sleep 100000 & [1] process-id # kill -11 process-id # ls
コア・ファイルを分析するために、slapdプロセスに関連付けられたすべてのライブラリおよびバイナリを取得します。pkgappスクリプトを使用して、ライブラリを収集します。pkgappスクリプトは、実行可能ファイルおよびそのすべての共有ライブラリを１つの圧縮されたtarファイルにパッケージ化します。アプリケーションのプロセスID、および(必要な場合は)開くコア・ファイルの名前を指定します。pkgappスクリプトの詳細は、「Solarisでのpkgappスクリプトの使用方法」を参照してください。
superuserとして、pkgappスクリプトを次のように実行します。
# pkgapp server-pid core-file
|
注意: コア・ファイルを指定せずに、 |
問題発生時に作成されたログ・ファイルを表示するには、次のファイルを確認します。
# instance-name/logs/errors* # instance-name/logs/access*
クラッシュが、オペレーティング・システムのディスクまたはメモリー不足に関連する場合は、システム・ログを取得します。たとえば、Solaris OSでは、/var/adm/messagesファイルおよび/var/log/syslogsファイルを参照して、ハードウェアまたはメモリーの障害を確認します。
完全な出力を取得するには、次のコマンドを使用します。
# dsadm -V
Directory Serverがクラッシュした場合、常にコアが生成されます。このコア・ファイルおよびns-slapdバイナリ・ディレクトリから取得したコア・ファイルのプロセス・スタックを使用して、問題を分析できます。
この項では、Solaris OSでコア・ファイルのクラッシュ・データを分析する方法について説明します。
コア・ファイルを取得したら、このファイルに対してpstackおよびpmap Solarisユーティリティを実行します。pmapユーティリティは、仮想アドレスのリストを含むプロセス・マップを表示しますが、ここは、動的ライブラリのロード先であるとともに、変数が宣言される場所でもあります。pstackユーティリティは、プロセス・スタックを表示します。プロセス内のスレッドごとに、プロセスの終了時またはpstackコマンドの実行時にスレッドが実行していた命令のスタックを示します。
# pstack core-file # pmap core-file
pstackユーティリティの結果がほぼ空の場合、出力のすべての行が次のようになります。
0002c3cc ???????? (1354ea0, f3400, 1354ea0, 868, 2fc, 1353ff8)
この場合、コア・ファイルが生成されたマシンでpstackを実行していることを確認してください。
pstackコマンドのかわりにmdbコマンドを使用してもコアのスタックを確認できます。mdbコマンドを次のように実行します。
# mdb $path-to-executable $path-to-core $C to show the core stack $q to quit
mdbおよびpstackコマンドの出力では、クラッシュ時のプロセス・スタックに関する有用な情報が提供されます。mdb $Cコマンドの出力では、クラッシュを引き起こしたスレッドを特定できます。
Solaris 9では、多くの場合、pstack出力の最初のスレッドに、クラッシュの原因となったスレッドが含まれます。Solaris 10では、mdbを使用してクラッシュの原因となったスレッドを特定するか、pstackコマンドを使用する場合は、lwp-park、pollおよびpollsysを含まないスレッドを検索して、スタックを分析します。
たとえば、プラグイン関数の呼出し時に、次のコア・プロセス・スタックが発生します。
core '/local/dsInst/logs/core' of 18301: ./ns-slapd \ -D /local/dsInst -i /local/dsInst ----------------- lwp# 13 / thread# 25 -------------------- ff2b3148 strlen (0, fde599fb, 0, fbed1, 706d2d75, fde488a8) + 1c ff307ef8 sprintf (7fffffff, fde488a0, fde599d8, fde599ec, 706d2d75, fde599fc) \ + 3c fde47cf8 ???????? (1354ea0, 850338, fde59260, e50243, 923098, 302e3800) + f8 fde429cc ???????? (1354ea0, 3, 440298, 154290, 345c10, 154290) + 614 ff164018 plugin_call_exop_plugins (1354ea0, 8462a0, d0c, ff1e7c70, ff202a94, \ 1353ff8) + d0 0002c3cc ???????? (1354ea0, f3400, 1354ea0, 868, 2fc, 1353ff8) 00025e08 ???????? (0, 1353ff8, fdd02a68, f3400, f3000, fbc00) fef47d18 _pt_root (362298, fe003d10, 0, 5, 1, fe401000) + a4 fed5b728 _thread_start (362298, 0, 0, 0, 0, 0) + 40
コアから取得したプロセス・スタックを分析する際は、スレッド中央の操作に注目します。下部のプロセスは一般的すぎ、上部のプロセスは限定的すぎます。スレッド中央のコマンドはDirectory Serverに固有のものであるため、処理のどの時点で操作が失敗したかを識別するのに役立ちます。上の例では、plugin_call_exop_pluginsプロセス・コールで、カスタム・プラグイン内の外部操作の呼出し時に問題が発生したことを示しています。
問題がDirectory Serverに関連している場合は、問題の原因である可能性が最も高い関数呼出しを使用して、この関数呼出しに関連する問題をSunSolveで検索できます。SunSolveはhttp://sunsolve.sun.com/にあります。
発生している問題に関連する問題が見つかった場合、それが実行中のDirectory Serverのバージョンに適用されるかどうかを確認します。実行中のバージョンの情報を取得するには、次のコマンドを使用します。
# dsadm -V
コア・ファイルの基本的な分析を行っても問題を特定できない場合は、pkgappスクリプトを使用してバイナリおよびライブラリを収集し、Sunのサポート・センターに連絡してください。
次の表に示すとおり、発生するパフォーマンスの問題のタイプは使用可能なCPUのレベルによって異なります。実行中でクライアント・アプリケーションのリクエストに応答しなくなったDirectory Serverのトラブルシューティングの最初のステップは、パフォーマンスに関する3つのタイプの問題のどれに該当するかを特定することです。
表5-1 パフォーマンスの問題に関連付けられているCPUレベル
| CPUレベル | 問題の説明 |
|---|---|
|
CPU = 0% |
パッシブ・ハング、サーバーはまったく応答しない |
|
CPU> 10% CPU < 90% |
パフォーマンスが低下、サーバーは動作しているが期待された速度ではない |
|
CPU = 100% |
アクティブ・ハング、サーバーはまったく応答しない |
この項の残りの部分では、次のトラブルシューティング手順について説明します。
エラー・ログにファイル記述子を開けないというエラーが含まれる場合、これは通常、応答しないプロセスの症状です。たとえば、次のようなメッセージがエラー・ログに含まれることがあります。
[17/APR/2009:01:41:13 +0000] - ERROR<12293> - Connection - conn=-1 op=-1 msgId=-1 - fd limit exceeded Too many open file descriptors - not listening on new connection
その他の応答しないプロセスの症状には、LDAP接続が応答しないかハングする、エラー・ログまたはアクセス・ログにメッセージが存在しない、アクセス・ログが更新されないなどがあります。
prstat -Lツールは、CPUの使用量をスレッドごとに示します。prstatツールの実行と同時にpstackユーティリティを使用してプロセス・スタックを収集する場合は、pstackの出力を使用して問題発生時のスレッドの動作を確認できます。prstatおよびpstackツールを同時に複数回実行すると、問題が同じスレッドで発生していたのか、同じ関数呼出しで問題が発生していたのかを確認できます。パフォーマンスが低下している場合は、コマンドを2秒ごとに同時に実行します。パッシブ・ハングまたはアクティブ・ハングが発生している場合は、コマンドを多少遅らせて(たとえば10秒ごとに)実行します。
たとえば、次のようにDirectory Server上でldapsearchの実行を試みます。
# ldapsearch -p 5389 -D "cn=Directory Manager" -w secret -b "o=test" description=*
このコマンドは40秒間実行されますが、結果は得られないとします。プロセスが応答しない原因を分析するには、最初に次のコマンドを実行してプロセスIDを取得します。
# ps -aef | grep slapd | grep slapd-server1 mares 15013 24159 0 13:06:20 pts/32 0:00 grep slapd-server1 mares 14993 1 1 13:05:36 ? 0:04 ./ns-slapd -D /local/dsInst -i /local/dsInst
次に、検索を再実行し、検索中にDirectory Serverプロセスに対してprstatおよびpstackコマンドを同時に実行しますが、前述の出力では、プロセスIDは14993です。
prstat -L -p 14993 0 1> prstat.output ; pstack 14993> pstack.output
2秒の間隔をおいて、コマンドを3回連続して再実行します。
最初のprstatコマンドの出力は、次のようになります。
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID 14993 mares 128M 110M cpu0 59 0 0:00.02 3.0% ns-slapd/51 14993 mares 128M 110M sleep 59 0 0:00.49 1.3% ns-slapd/32 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/16 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/15 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/14 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/13 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/12 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/11 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/10 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/9 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/8 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/6 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/5 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/4 14993 mares 128M 110M sleep 59 0 0:00.00 0.0% ns-slapd/3 Total: 1 processes, 51 lwps, load averages: 0.36, 0.29, 0.17
問題はスレッド51で発生しているようです。次に、最初のpstackコマンドの出力でスレッド51を検索すると、次のようになっています。
----------------- lwp# 51 / thread# 51 -------------------- ffffffff7eb55a78 ???????? (1, 102183a10, ffffffff70c1d340, 1001c5390, 0, ffffffff7ecea248) ffffffff77925fe0 id2entry (1002b7610, 1a09, 0, ffffffff70c1e7f4, 0, ffffffff77a6faa8) + 3e8 ffffffff7795ed20 ldbm_back_next_search_entry_ext (101cfcb90, 10190fd60, 0, 101b877b0, 1a08, 45b4aa34) + 300 ffffffff7ebaf6f8 ???????? (101cfcb90, 1002b7610, 1, ffffffff70c1eaf4, 0, 0) ffffffff7ebafbc4 ???????? (101cfcb90, 1, ffffffff70c1eaf4, 0, 10190fd60, ffffffff70c1e980) ffffffff7ebaf170 op_shared_search (101cfcb90, 0, 1015ad240, 0, ffffffffffffffff, ffffffff7ecea248) + 8c0 ffffffff7e92efcc search_core_pb (101cfcb90, 2, 1000, 4000, ffffffff7ea4c810, ffffffff7ea56088) + 6c4 ffffffff7e93a710 dispatch_operation_core_pb (101cfcb90, 101cfcb90, c00, ffffffff7ea4c810, 0, d10) + cc ffffffff7e926420 ???????? (101f3fe80, 102fd3250, 2, 63, 2, 200000) ffffffff7e92672c ldap_frontend_main_using_core_api (101f3fe80, 102fd3250, 2, 101da1218, 10133db10, 0) + fc ffffffff7e927764 ???????? (220, 101c97310, ffffffffffffffff, 800, 958, 101f3fe80) ffffffff7d036a7c _pt_root (101c97310, ffffffff70b00000, 0, 0, 20000, ffffffff70c1ff48) + d4 ffffffff7c1173bc _lwp_start (0, 0, 0, 0, 0, 0)
|
注意: この例では、各行をページに納めるために行末で改行しています。 |
2番目および3番目のpstackコマンドの出力では、スレッド51が同じタイプの操作を実行し、同じ結果が表示されます。
2秒間隔で実行した3つのpstackの出力はすべて、スレッド51が同じ検索操作を実行していることを示しています。op_shared_search関数の最初のパラメータには、実行された操作のアドレス(101cfcb90)が含まれます。3つのスタックのそれぞれで同じ操作が実行されていますが、これは、最初と最後のpstackの実行間隔である4秒間に同じ検索が実行されていることを示します。さらに、prstatの出力は、スレッド51がCPU使用量の最も高いスレッドであることを常に示しています。
アクセス・ログでハングが検出されたときの検索操作の結果を確認すると、これが索引付けされていない説明エントリでの検索の結果であることがわかります。説明索引を作成することで、このハングを回避できます。
この項では、パフォーマンスの低下のトラブルシューティングを開始する方法について説明します。パフォーマンス低下の考えられる原因、パフォーマンスが低下したときに参照する必要のある情報およびこの情報の分析方法について説明します。
パフォーマンス低下に関して、アクティブ・ハングとパッシブ・ハングを間違えないでください。パフォーマンスが低下している場合、次のいずれかの原因が考えられます。
他のプロセスがCPUまたはディスク・アクセスに影響している
ネットワークの問題
高い入力/出力率
メモリーのスワッピング
索引が指定されていない検索(索引が欠落しているか、「!」フィルタが使用されている)
複雑な検索(静的グループ、サービスのクラスおよびロールに対する検索など)
複雑な更新(静的グループ、サービスのクラスおよびロールに対する更新など)
準最適ハードウェア
fdsやkeepaliveなどの準最適システム設定
Directory Serverが正しくチューニングされていない
パフォーマンスの低下時に、ディスク、CPU、メモリーおよびプロセス・スタックの使用に関する情報を収集します。
CPUが非常に低い(10%前後)場合は、次のようにnetstatコマンドを使用して、ネットワーク関連の問題かどうかを確認します。
# netstat -an | grep port
アクセス・ログには結果がただちに送信されたことが示されているにもかかわらず、クライアントが情報を受信しない場合は、ネットワークがパフォーマンス低下の原因である可能性があります。pingおよびtracerouteコマンドを実行すると、ネットワーク待機時間が問題の原因であるかどうかを判別するのに役立ちます。
スワップ情報を収集して、メモリーが不足しているかどうかを確認します。スワップ・コマンドの出力が小さい場合は、メモリーが問題の可能性があります。
| プラットフォーム | メモリー損失のインジケータ |
|---|---|
|
Solaris |
|
|
HP-UX |
|
|
Linux |
|
|
Windows |
|
Solarisでは、prstatコマンドの出力を使用して、他のプロセスがシステムのパフォーマンスに影響を与えているかどうかを確認します。LinuxおよびHP-UXでは、topコマンドを使用します。
「応答しないプロセスに関するデータの分析: 例」の説明に従って、パフォーマンスの低下時にDirectory Serverの連続したpstackおよびprstatの出力を収集します。たとえば、Solarisで次のスクリプトを使用して、pstackおよびprstatの情報を収集します。
#!/bin/sh
i=0
while [ "$i" -lt "10" ]
do
echo "$i/n"
date= `date"+%y%m%d:%H%M%S"
prstat -L -p $1 0 1> /tmp/prstat.$date
pstack $1> /tmp/pstack.$date
i=`expr $i + 1`
sleep 1
done
一般に、データを確認して発生したエラーのパターンや共通点を見つけます。たとえば、操作の問題がすべて静的グループの検索、静的グループの変更およびロール上の検索に関連している場合、負荷の高いこれらの操作を処理できるようにDirectory Serverが適切にチューニングされていないことを意味します。たとえば、nsslapd-search-tune属性が静的グループ関連の検索に合わせて正しく構成されていないか、グループ関連の更新が部分文字列内で索引付けされたuniqueMember属性の影響を受けている可能性があります。問題が関連性のない操作に関連しているが、すべてが特定の時間に発生している場合は、メモリー・アクセスまたはディスク・アクセスの問題である可能性があります。
pstacksで収集した情報をSunSolveで「応答しないイベント」というフレーズとともに検索すると、類似の問題が以前に発生して解決されていないかどうかを確認できます。SunSolveはhttp://sunsolve.sun.com/pub-cgi/show.pl?target=tousにあります。
この項の残りの部分では、前述の手順で収集したデータを分析するのに役立つ補足的なヒントを提供します。
logconvコマンドを使用したアクセス・ログの分析logconvコマンドを使用してDirectory Serverのアクセス・ログを分析できます。このコマンドは、使用状況統計を抽出して、重要なイベントの発生数をカウントします。このツールの詳細は、「logconv」を参照してください。
たとえば、次のようにlogconvコマンドを実行します。
# logconv -s 50 -efcibaltnxgju access> analysis.access
出力ファイルで、次を確認します。
索引が指定されていない検索(notes=U)
索引が指定されていない検索が存在する場合は、dsconf list-indexesコマンドを使用して関連する索引を検索します。索引が存在する場合は、all-ids-thresholdプロパティの制限に達している可能性があります。このプロパティは、索引リストの各索引キーの最大数を定義します。all-ids-thresholdを増やして索引を再作成します。
索引が存在しない場合は、索引を作成し、その後、索引を再作成する必要があります。索引の作成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の索引の作成に関する説明を参照してください。
ファイル記述子の大量消費
ファイル記述子の消費に関する問題を管理するには、システム・レベルで使用可能なファイル記述子を増やす必要がある場合があります。永続検索(notes=persistent)の数を減らすか、切断しないクライアント・アプリケーションを変更するか、nsslapd-idletimeoutプロパティで設定したアイドル・タイムアウトの値を減らす必要がある場合があります。
長いetimeを使用する検索または多数のエントリを返す検索
たとえば、etimeが344の場合、アクセス・ログでetime 344をgrepします。アクセス・ログには、接続および操作が表示されます。この情報を使用して、パフォーマンスが低下したときに実行していた操作、接続が開かれた時刻およびバインドしたユーザーを確認できます。同一の操作がすべて長いetimeを保持する場合は、特定の操作の問題であることを示しています。同一のバインドしたユーザーが長いetimeに常に関連付けられている場合は、ACIの問題である可能性があります。
ACIとバインドしたユーザーの問題が疑われる場合は、ACIの対象でないDirectory Managerユーザーで同じ操作を実行することで確認できます。
uniquemember属性または不正なフィルタに対する検索。
SunSolveを参照して、静的グループ・パフォーマンスのホット・パッチを検索します。nsslapd-search-tune属性を指定して、検索を実行します。
長いADDおよびMOD操作
容量の制限が、パフォーマンスの問題の原因となっていることがよくあります。パフォーマンスと容量を区別するために、パフォーマンスは「システムの処理速度」と定義でき、容量は「システムまたは個別のコンポーネントの最大パフォーマンス」と定義できます。
CPUが非常に低い(10%前後)場合は、ディスク・コントローラが完全にロードされているか、入出力が原因かどうかを確認します。ディスク関連の問題かどうかを判別するには、次のようにiostatツールを使用します。
# iostat -xnMCz -T d 10
たとえば、ディレクトリはインターネット上で使用できます。顧客は複数のサイトから検索を送信し、サービス・レベル合意(SLA)は、レスポンス時間が3秒を超えるリクエストのわずか5%でした。現在、リクエストの15%が3秒よりかかりますが、これはビジネスにとっては不利益な状態です。システムは、900MHzのCPUを12個使用する6800です。
vmstatの出力は、次のようになります。
procs memory page disk faults cpu r b w swap free re mf pi po fr de sr m0 m1 m1 m1 in sy cs us sy id 0 2 0 8948920 5015176 374 642 10 12 13 0 2 1 2 1 2 132 2694 1315 14 3 83 0 19 0 4089432 188224 466 474 50 276 278 0 55 5 5 4 3 7033 6191 2198 19 4 77 0 19 0 4089232 188304 430 529 91 211 211 0 34 8 6 5 4 6956 9611 2377 16 5 79 0 18 0 4085680 188168 556 758 96 218 217 0 40 12 4 6 4 6979 7659 2354 18 6 77 0 18 0 4077656 188128 520 501 75 217 216 0 46 9 3 5 2 7044 8044 2188 17 5 78
右の3つの列us=user、us=userおよびus=userを確認すると、CPUの50%以上がアイドルで、パフォーマンスの問題に使用可能であることを示しています。メモリーの問題を検出する方法の1つは、vmstatの出力のsr (スキャン・レート)列を確認することです。ページ・スキャナが実行を開始しているか、スキャン・レートが0より大きくなる場合、メモリー・システムをより詳細に確認する必要があります。この表示の奇妙な点は、左側に表示されているブロックされたキューには18または19個のプロセスが含まれているが、実行キューにはプロセスが存在していないことです。これは、Solaris内のどこかで、使用可能なCPUをすべて使用せずに、プロセスがブロックされていることを示しています。
次に、入出力サブシステムを確認します。iostatコマンドにはスイッチ(-C)があり、これによりコントローラ・レベルでの入出力が集計されます。次のように、iostatコマンドを実行します。
# iostat -xnMCz -T d
extended device statistics
r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
396.4 10.7 6.6 0.1 0.0 20.3 0.0 49.9 0 199 c1
400.2 8.8 6.7 0.0 0.0 20.2 0.0 49.4 0 199 c3
199.3 6.0 3.3 0.0 0.0 10.1 0.0 49.4 0 99 c1t0d0
197.1 4.7 3.3 0.0 0.0 10.2 0.0 50.4 0 100 c1t1d0
198.2 3.7 3.4 0.0 0.0 9.4 0.0 46.3 0 99 c3t0d0
202.0 5.1 3.3 0.0 0.0 10.8 0.0 52.4 0 100 c3t1d0
コントローラ1では毎秒396回の読取りを実行し、コントローラ3では毎秒400回の読取りを実行しています。データの右側には、コントローラがほぼ200%のビジー状態であることを出力が示しています。このため、個々のディスクが毎秒ほぼ200回の読取りを実行しており、これらのディスクが100%のビジー状態であることが出力からわかります。これは大まかに言えば、個々のディスクが毎秒約150回の入出力を実行していることになります。これは、大規模なディスク・アレイのLUNやLDEVには当てはまりません。これらの数値の調査に基づいて、各コントローラに2台のディスクを追加し、データを中継するという提案につながります。
この演習では、すべての数値を確認し、問題の特性を正確に把握することを試みました。CPUとメモリーを追加することで、パフォーマンスの問題がすべて解決されるとはかぎりません。この場合は、検索プログラムがディスク・ドライブの容量を超過しており、それがトランザクションで非常に長いレスポンス時間がかかるというパフォーマンスの問題となっていることがわかりました。これらのCPUはすべて、ディスク・ドライブを待機していました。
この項では、まったく応答しないDirectory Serverプロセスのトラブルシューティング方法について説明します。まったく応答しないプロセスはハングと呼ばれ、発生する可能性のあるハングには、次の2つのタイプがあります。
アクティブ・ハング(CPUレベルが100%の場合)。たとえば、プロセスで無限ループが発生すると、リクエストを永久に待機したり、リクエストにサービスを永久に提供することを意味します。
パッシブ・ハング(CPUレベルが0%の場合)。たとえば、プロセスでデッドロックが発生すると、そこではプロセスの複数のスレッドが他のスレッドの完了を待機するために、何も実行されません。
この項の残りの部分では、これらのプロセス・ハングのそれぞれのタイプについてのトラブルシューティング方法を説明します。
topまたはvmstat 1の出力で95%を超えるCPUレベルが表示される場合、ハングはアクティブです。
この項では、アクティブ・ハングの原因、アクティブ・ハングに関する情報の収集方法およびこのデータの分析方法について説明します。
topまたはvmstat 1の出力で低いCPUレベルが表示される場合、ハングはパッシブです。
Solarisシステムでは、Solaris pstackユーティリティを使用して、ハングしているDirectory Serverプロセス・スタックの複数のトレースを収集します。この情報は、サーバーがハングしている間に収集する必要があります。連続したpstackデータを3秒ごとに収集する必要があります。
サーバーがハングしている間に、サーバー・スレッドの状態を示す複数のコア・ファイルを収集します。これを行うには、gcoreコマンドを使用してコア・ファイルを生成し、コア・ファイルの名前を変更して30秒待機し、別のコア・ファイルを生成します。この手順を1回以上繰り返して、コア・ファイルと関連するデータのセットを3つ以上取得します。
コア・ファイルの生成の詳細は、「コア・ファイルの生成」を参照してください。
この項では、アクセス不能なデータベースのトラブルシューティング方法について説明します。
次のいずれかが理由で、Directory Serverデータベースがアクセス不能になる可能性があります。
データベース破損
索引の破損
共有のリージョン・ファイルの破損
変更ログの欠落
変更ログの破損
データベースのオフライン(再インポート中など)
トランザクション・ログの欠落
エラー・ログを分析して、必要な情報を検索します。
# instance-name/logs/errors*
この項では、メモリー・リークのトラブルシューティング方法について説明します。
メモリー・リークは、Directory Server自体またはカスタム・プラグインのメモリー割当ての問題によって発生します。これらの問題のトラブルシューティングは、特にカスタム・プラグインの場合は、非常に難しい場合があります。
メモリー・リークに関するデータを収集する前に、次を行うことが重要です。
すべてのカスタム・プラグインを無効にする
キャッシュ設定を非常に低い値に下げる
監査ログを有効にする
前述の作業を実行したら、prstat -Lユーティリティを実行して、VSZ列が増えているかどうかを確認します。
「汎用データの収集」の説明に従って、一般的なDirectory Serverデータを収集します。このデータには、実行中のDirectory Serverのバージョン、テスト実行のログ(特に監査ログ)およびDirectory Serverの構成ファイルが含まれます。
データを収集したら、Sunのサポート・センターに連絡して問題解決の支援を求めることができます。
libumemライブラリを使用したメモリー・リークの分析Solarisシステムでは、libumemライブラリは、メモリー・リークの原因の分析に役立つメモリー・エージェント・ライブラリです。libumemライブラリの詳細は、http://developers.sun.com/solaris/articles/libumem_library.htmlにある技術記事を参照してください。
次のコマンドを使用して、Directory Serverを再起動します。
# SUN_SUPPORT_SLAPD_NOSH=true LD_PRELOAD=libumem.so \ UMEM_DEBUG=contents,audit=40,guards UMEM_LOGGING=transaction ./dsadm start
これで、libumemライブラリは、Directory Serverが起動する前に、Directory Serverのメモリー割当てを使用せずにロードされます。
次に、gcoreコマンドを複数回(メモリー使用が増え始める前に1回、増え始めた後に1回)実行します。gcoreコマンドは、現在のディレクトリにメモリー・イメージをダンプします。
# gcore core.process-id
最後に、mdbツールを使用して、結果を分析します。
