この節では、パフォーマンス低下のトラブルシューティングを開始する方法について説明します。パフォーマンス低下の考えられる原因、およびパフォーマンスが低下したときに参照する必要のある情報、およびこの情報の分析方法について説明します。
アクティブハングアップによるパフォーマンス低下と、パッシブハングアップによるパフォーマンス低下を混同しないようにしてください。パフォーマンスが低下している場合、次のいずれかの原因が考えられます。
CPU またはディスクアクセスがほかのプロセスから受ける影響
ネットワークの問題
高い入出力速度
メモリーのスワッピング
インデックスを使用しない検索 (インデックスが欠落しているか、「!」フィルタが使用されている)
複合検索 (静的グループ、サービスのクラス、およびロールに対する検索など)
複合更新 (静的グループ、サービスのクラス、およびロールに対する更新など)
準最適ハードウェア
fds や keepalive などの準最適システム設定
不正に調整された Directory Server
パフォーマンス低下時のディスク、CPU、メモリー、およびプロセススタックの使用率に関する情報を収集します。
CPU の使用率が非常に低い (10% 前後) 場合は、次のように netstat コマンドを使用して、ネットワーク関連の問題かどうかを確認します。
# netstat -an | grep port |
アクセスログには結果がただちに送信されたことが示されているにもかかわらず、クライアントが情報を受信しない場合は、ネットワークにパフォーマンス低下の原因がある可能性があります。ping および traceroute コマンドを実行すると、ネットワークレイテンシが問題の原因であるかどうかを判別するのに役立ちます。
スワップ情報を収集して、メモリーが不足しているかどうかを確認します。swap コマンドの出力が小さい場合は、メモリーが問題の原因である可能性があります。
Solaris |
swap -l |
HP-UX |
swapinfo |
Linux |
free |
Windows |
C:\report.txt に提供済み |
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" prstate -L -p $1 0 1 > /tmp/prstate.$date pstack $1 > /tmp/pstack.$date i=`expr $i + 1` sleep 1 done |
idsktune コマンドは、システムパラメータ、パッチレベル、チューニングの推奨事項に関する情報を提供します。このコマンドの出力を使用して、スレッドライブラリの問題や不足しているパッチを検出できます。idsktune コマンドの詳細については、idsktune(1M) のマニュアルページを参照してください。
一般に、データを通して発生したエラーのパターンや共通点を見つけます。たとえば、操作の問題がすべて静的グループの検索、静的グループの変更、およびロール上の検索に関連している場合、これら負荷の大きい操作を処理できるよう、Directory Server が適切に調整されていないことを意味します。たとえば、nsslapd-search-tune 属性が静的グループ関連の検索に合わせて正しく設定されていないか、グループ関連の更新が部分文字列内のインデックス生成属性 uniqueMember の影響を受けている可能性があります。問題と操作の間に関連性がないが、すべてが特定の時間に発生している場合は、メモリーアクセスまたはディスクアクセスの問題である可能性があります。
pstacks で集められた情報は、 SunSolve で unresponsive events という語句とともに検索すると、類似の問題が以前に発生して解決されていないかどうかを確認できます。SunSolve は http://sunsolve.sun.com/pub-cgi/show.pl?target=tous で参照できます。
この節の残りの部分では、前の手順で収集したデータを分析するのに役立つ補足的なヒントを提供します。
logconv コマンドを使用して、Directory Server アクセスログを分析できます。このコマンドは、使用状況に関する統計を抽出して、有意なイベントの数をカウントします。このツールの詳細については、logconv(1) のマニュアルページを参照してください。
たとえば、次のように logconv コマンドを実行します。
# logconv -s 50 -efcibaltnxgju access > analysis.access |
出力されたファイルで、次の情報を確認します。
インデックスを使用しない検索 (notes=U)
インデックスを使用しない検索が存在する場合は、dsconf list-indexes コマンドを使用して関連するインデックスを検索します。インデックスが存在する場合は、all-ids-threshold プロパティーの制限に近づいている可能性があります。このプロパティーは、インデックスリスト内の各インデックスキーの値の最大数を定義しています。all-ids-threshold の値を大きくして、インデックスを再生成します。
インデックスが存在しない場合は、インデックスを作成して再生成します。インデックスの作成については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「インデックスを作成する」を参照してください。
ファイル記述子の大量消費
ファイル記述子の消費の問題を管理するには、システムレベルで使用可能なファイル記述子を増やすことが必要な場合があります。持続検索の数 (notes=persistent) を減らすか、切断されていないクライアントアプリケーションを変更するか、nsslapd-idletimeout プロパティーで設定されたアイドルタイムアウト値を減らすことができます。
長い etime を使用した検索または多数のエントリを返す検索
以下に例を示します。etime が 344 の場合、アクセスログで grep を実行して etime 344 を検索します。アクセスログから接続および操作の情報が得られます。この情報を使って、パフォーマンスが低下したときの操作、接続が開かれた時刻、およびバインドしたユーザーを確認できます。同一の操作がすべて長い 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、sy=system、および id=idle を参照すると、CPU の 50% 以上がアイドル状態にあり、パフォーマンスの問題に使用可能であることがわかります。メモリーの問題を検出する方法の 1 つは、vmstat の出力の sr (スキャンレート) 列を参照することです。ページスキャナが実行を開始しているか、スキャンレートが 0 より大きくなる場合、メモリーシステムをより詳細に確認する必要があります。この表示の奇妙な点は、左側に表示されるブロックされたキュー に 18 または 19 個のプロセスが含まれるのに、実行キューにはプロセスが存在していないことです。これは、Solaris 内のどこかで、プロセスが、使用可能な CPU をすべて使用せず、ブロックされていることを示しています。
次に入出力サブシステムを確認します。Solaris 8 では、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 はすべて、ディスクドライブからの応答を待機していました。