test

Sun Java System Directory Server Enterprise Edition 6.3 トラブルシューティングガイド

第 5 章 Directory Server の問題のトラブルシューティング

この章では、Directory Server で発生する一般的な問題のトラブルシューティング方法について説明します。次のトピックに関する情報が含まれます。

クラッシュのトラブルシューティング

この節では、クラッシュした Directory Server プロセスのトラブルシューティングを開始する方法について説明します。クラッシュの考えられる原因、問題を特定するために収集する必要のある情報、収集した情報の分析方法について説明します。

クラッシュの考えられる原因

クラッシュの原因には、次に示す要素の 1 つまたは複数が考えられます。

Directory Server プロセスがクラッシュする場合、Sun サポートセンターを使用してサービスリクエストを開始する必要があります。

クラッシュに関するデータの収集

この節では、サーバーがクラッシュしたときに収集する必要のあるデータについて説明します。収集すべきもっとも重要なデータは、コアファイルです。

注 –

クラッシュした Directory Server プロセスについて Sun サポートセンターに連絡する場合、コアファイルとログを提出する必要があります。

コアファイルの生成

コアファイルおよびクラッシュダンプは、プロセスまたはアプリケーションが異常終了したときに生成されます。サーバーがクラッシュしたときに Directory Server がコアファイルを生成できるように、システムを設定します。コアファイルには、クラッシュ時の Directory Server プロセスのスナップショットが含まれます。これは、クラッシュの原因を特定するために不可欠な場合があります。コアファイルは errors ログと同じディレクトリに書き込まれます。デフォルトでは、このディレクトリは instance-path /logs/ です。コアファイルにはエントリキャッシュが含まれるため、サイズが非常に大きくなる場合があります。

コアファイルが自動的に生成されない場合は、次の表に示すコマンドを使用してコアダンプを許可するようにオペレーティングシステムを設定してから、次のクラッシュを待ってデータを取得します。

Solaris 

coreadm

または、 


ulimit -c unlimited
ulimit -H -c unlimited

Linux 

 

ulimit -c unlimited
ulimit -H -c unlimited

HPUX/AIX 

ulimit -c

Windows 

Windows crashdump

たとえば 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 でのコアファイル生成の設定については、『Sun Gathering Debug Data for Sun Java System Directory Server 5』の「Configuring the Operating System to Generate Core Files」を参照してください。

次に、kill -11 process-id コマンドを使用して、アプリケーションがコアファイルを生成可能であることを確認します。コアの生成先は、指定したディレクトリ内またはデフォルトの instance-name/logs ディレクトリ内になります。


# cd /var/cores
# sleep 100000 &
[1] process-id
# kill -11 process-id
# ls

コアライブラリと共用ライブラリの取得

コアファイルを分析するため、slapd プロセスに関連付けられたすべてのライブラリおよびバイナリを取得します。pkg_app スクリプトを使用してライブラリを収集します。pkg_app スクリプトは、実行可能ファイルとそのすべての共用ライブラリを、圧縮された 1 つの tar ファイルにパッケージ化します。アプリケーションのプロセス ID、および開くコアファイルの名前 (必要な場合) を指定します。pkg_app スクリプトの詳細については、「Solaris での pkg_app スクリプトの使用」を参照してください。

superuser として、pkg_app スクリプトを次のように実行します。


# pkg_app server-pid core-file
注 –

コアファイルを指定せずに pkg_app スクリプトを実行することもできます。これにより、スクリプトの出力サイズが小さくなります。あとで、変数をコアファイルの正しい場所に設定する必要があります。

補足情報

問題発生時に作成されたログファイルを表示するには、次のファイルを確認します。


# install-path/instance-name/logs/errors*
# install-path/instance-name/logs/access*

クラッシュが、オペレーティングシステムのディスクまたはメモリー容量の不足に関連するものである場合は、システムログを取得します。たとえば、Solaris OS では、 /var/adm/messages ファイルおよび /var/log/syslogs ファイルを参照して、ハードウェアまたはメモリーの障害を確認します。

完全な出力を取得するには、次のコマンドを使用します。


# cd install-path/bin/slapd/server
# ./ns-slapd -D install-path/instance-name -V

クラッシュデータの分析

Directory Server がクラッシュする際には、常にコアが生成されます。このコアファイルおよび ns-slapd バイナリディレクトリから取得したコアファイルのプロセススタックを使用して、問題を分析できます。

この節では、Solaris OS でコアファイルクラッシュデータを分析する方法について説明します。

Solaris でのコアファイルの確認

コアファイルを取得したあとで、このファイルに対して pstack および pmap Solaris ユーティリティーを実行します。pmap ユーティリティーは、仮想アドレスのリストを含むプロセスマップを表示します。仮想アドレスは、動的ライブラリの読み込み先であるとともに、変数が宣言される場所でもあります。pstack ユーティリティーにより、プロセススタックが表示されます。これは、プロセス内のスレッドごとに、プロセスの終了時または pstack コマンドの実行時にスレッドが実行していた命令のスタックを示します。

これらのユーティリティーは、ns-slapd バイナリ root-dir/bin/slapd/server を含むディレクトリから実行する必要があります。次に示すようにユーティリティーを実行します。


# pstack core-file


# pmap core-file

pstack ユーティリティーの結果がほぼ空である場合は、すべての出力行が次のようになります。


0002c3cc ???????? (1354ea0, f3400, 1354ea0, 868, 2fc, 1353ff8)

pstack の出力がこのような場合は、ns-slapd バイナリディレクトリからこのユーティリティーを実行していることを確認してください。ns-slapd バイナリディレクトリからこのユーティリティーを実行していなかった場合は、このディレクトリに移動してユーティリティーを再度実行します。

pstack コマンドの代わりに mdb コマンドを使用してもコアのスタックを確認できます。次のように mdb コマンドを実行します。


# mdb $path-to-executable $path-to-core
$C to show the core stack
$q to quit

mdb および pstack コマンドの出力から、クラッシュ時のプロセススタックに関する有用な情報を入手できます。mdb $C コマンドの出力から、クラッシュを引き起こしたスレッドを特定できます。

Solaris 8 および 9 では、多くの場合、pstack 出力の最初のスレッドにクラッシュの原因となったスレッドが含まれます。Solaris 10 では、mdb を使用してクラッシュの原因となったスレッドを特定します。pstack コマンドを使用する場合は、lwp-park、poll、および pollsys を含まないスレッドを検索して、スタックを分析します。

たとえば、プラグイン関数の呼び出し時に、次のコアプロセススタックが発生します。


core '../../../slapd-psvmrr3-27/logs/core' of 18301:    ./ns-slapd \
-D /opt/iplanet/servers/slapd-psvmrr3-27 -i /opt/iplanet/se
-----------------  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 のバージョンに適用されるか確認します。バージョンの情報を取得するには、次のコマンドを使用します。


# ns-slapd -V

コアファイルの基本的な分析を行っても問題を特定できない場合は、pkg_app スクリプトを使ってバイナリおよびライブラリを収集し、Sun サポートセンターに連絡してください。

応答しないプロセスのトラブルシューティング

次の表に示すように、発生するパフォーマンスの問題のタイプは使用可能な CPU のレベルにより異なります。稼働しているがクライアントアプリケーションの要求に応答しなくなった Directory Server のトラブルシューティングの第 1 段階は、パフォーマンスに関する 3 タイプの問題のどれに該当するかを特定することです。

表 5–1 CPU レベルおよび関係するパフォーマンスの問題

CPU レベル 

問題 

CPU = 0% 

パッシブハングアップ、サーバーはまったく応答しない 

CPU > 10% 

CPU < 90% 

パフォーマンスが低下、サーバーは動作するが期待する速度は得られない 

CPU = 100% 

アクティブハングアップ、サーバーはまったく応答しない 

この節のこのあとの部分では、次に示すトラブルシューティング手順について説明します。

応答しないプロセスの徴候

通常、エラーログにファイル記述子を開けないというエラーが含まれる場合、これは応答しないプロセスの徴候です。たとえば、次のようなメッセージがエラーログに含まれることがあります。


[17/Jan/2007: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 ツールは、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
/u1/SUNWdsee/user1/52/slapd-server1 -i /u1/SUNWdsee/user1/52/slapd-s

次に、検索を再実行し、検索中に 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、メモリー、およびプロセススタックの使用率に関する情報を収集します。

ディスク、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 コマンドを使用します。

Solaris での連続したプロセススタックの収集

「応答しないプロセスに関するデータの分析: 例」に記載の手順に従って、パフォーマンス低下時の 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 コマンドの詳細については、idsktune(1M) のマニュアルページを参照してください。

パフォーマンスの問題に関する収集データの分析

一般に、データを通して発生したエラーのパターンや共通点を見つけます。たとえば、操作の問題がすべて静的グループの検索、静的グループの変更、およびロール上の検索に関連している場合、これら負荷の大きい操作を処理できるよう、Directory Server が適切に調整されていないことを意味します。たとえば、nsslapd-search-tune 属性が静的グループ関連の検索に合わせて正しく設定されていないか、グループ関連の更新が部分文字列内のインデックス生成属性 uniqueMember の影響を受けている可能性があります。問題と操作の間に関連性がないが、すべてが特定の時間に発生している場合は、メモリーアクセスまたはディスクアクセスの問題である可能性があります。

pstacks で集められた情報は、 SunSolve で unresponsive events という語句とともに検索すると、類似の問題が以前に発生して解決されていないかどうかを確認できます。SunSolve は http://sunsolve.sun.com/pub-cgi/show.pl?target=tous で参照できます。

この節の残りの部分では、前の手順で収集したデータを分析するのに役立つ補足的なヒントを提供します。

logconv コマンドを使用したアクセスログの分析

logconv コマンドを使用して、Directory Server アクセスログを分析できます。このコマンドは、使用状況に関する統計を抽出して、有意なイベントの数をカウントします。このツールの詳細については、logconv(1) のマニュアルページを参照してください。

たとえば、次のように logconv コマンドを実行します。


# logconv -s 50 -efcibaltnxgju access > analysis.access

出力されたファイルで、次の情報を確認します。

キャパシティーの限界の識別: 演習

キャパシティーの限界自体が、パフォーマンスの問題の原因になることがよくあります。パフォーマンスとキャパシティーを区別するため、パフォーマンスは「システムの処理速度」と定義し、キャパシティーは「システムまたは個別のコンポーネントの最大パフォーマンス」と定義します。

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 はすべて、ディスクドライブからの応答を待機していました。

プロセスのハングアップのトラブルシューティング

この節では、まったく応答しない Directory Server プロセスのトラブルシューティングについて説明します。まったく応答しないプロセスはハングアップと呼ばれます。発生する可能性のあるハングアップには、次の 2 種類があります。

この節の残りの部分では、各タイプのプロセスハングアップのトラブルシューティング方法について説明します。

アクティブハングアップのトラブルシューティング

top または vmstat 1 の出力に 95% を超える CPU レベルが表示される場合は、アクティブハングアップです。

この節では、アクティブハングアップの原因、アクティブハングアップの情報の収集方法、およびこのデータの分析方法について説明します。

アクティブハングアップの考えられる原因

アクティブハングアップの原因としては、次のことが考えられます。

アクティブハングアップのデータの収集と分析

Solaris システムでは、Solaris pstack ユーティリティーを使用して、ハングアップしている Directory Server プロセススタックの複数のトレースを収集します。このコマンドは、root-dir/bin/slapd/server ディレクトリから実行します。また、Solaris prstat ユーティリティーを使って、アクティブなプロセスに関する統計情報も収集してください。サーバーがハングアップしている間に、この情報を収集する必要があります。

連続している pstack および prstat データを毎秒収集してください。

パッシブハングアップのトラブルシューティング

top または vmstat 1 の出力に低い CPU レベルが表示される場合は、パッシブハングアップです。

パッシブハングアップの考えられる原因

パッシブハングアップの原因としては、次のことが考えられます。

パッシブハングアップのデータの収集と分析

Solaris システムでは、Solaris pstack ユーティリティーを使用して、ハングアップしている Directory Server プロセススタックの複数のトレースを収集します。このコマンドは、root-dir/bin/slapd/server ディレクトリから実行します。サーバーがハングアップしている間に、この情報を収集する必要があります。連続した pstack データを 3 秒ごとに収集してください。

サーバーがハングアップしている間に、サーバースレッドの状態が示された複数のコアファイルを収集します。これには、gcore コマンドを使用してコアファイルを生成し、コアファイルの名前を変更して、30 秒待ってから別のコアファイルを生成します。この手順をあと 1 回以上繰り返して、コアファイルと関連するデータのセットを 3 つ以上取得します。

コアファイルの生成の詳細については、「コアファイルの生成」を参照してください。

データベースの問題のトラブルシューティング

この節では、アクセス不能なデータベースのトラブルシューティング方法について説明します。

データベースの問題の考えられる原因

Directory Server データベースがアクセス不能になる理由として、次のことが考えられます。

Procedureデータベースの問題のトラブルシューティング

  1. サーバーが起動しない場合は、サーバーがオフラインである間にガーディアンファイルおよびすべての共用メモリーファイルを削除して、もう一度起動を試みます。


    # install-path/instance-name/db/guardian
# install-path/instance-name/db/_db.00*

    起動に成功してもデータベースを読み込めない場合は、次の手順を続けて実行します。

  2. db/ ディレクトリに格納されているすべてのデータベースファイルをバックアップします。

  3. データベースがアクセス不能であった期間のエラーログおよびアクセスログファイルを収集します。


    # install-path/instance-name/logs/errors*
# install-path/instance-name/access*

メモリーリークのトラブルシューティング

この節では、メモリーリークのトラブルシューティング方法について説明します。

メモリーリークの考えられる原因

メモリーリークは、Directory Server 自体またはカスタムプラグインにメモリー割り当ての問題があるために発生します。これらの問題のトラブルシューティングは、特にカスタムプラグインの場合、非常に難しいことがあります。

メモリーリークに関するデータの収集

メモリーリークに関するデータを収集する前に、次の作業を行っておくことが重要です。

上記の作業を実行したら、メモリーリークについて検証するテストを実行します。テストの実行中に、次のようにして pmonitor ユーティリティーの出力を収集します。








pmonitor ユーティリティーはプロセスモニターです。



「汎用データの収集」の説明に従って、一般的な Directory Server データを収集します。このデータには、実行中の Directory Server のバージョン、テスト実行のログ (特に監査ログ)、および Directory Server 設定ファイルが含まれます。


データを収集したら、Sun サポートセンターに連絡して問題解決の支援を求めることができます。



libumem ライブラリを使用したメモリーリークの分析


Solaris システムでは、libumem ライブラリは、プロセスメモリーフットプリントに割り当てられるすべてのアドレスを追跡するメモリーエージェントライブラリです。これは非常に低速なため、通常、本稼働環境では使用されません。ただし、メモリーリークの原因を分析するのに役立ちます。libumem ライブラリの詳細については、次の場所にある技術記事を参照してください。"http://access1.sun.com/techarticles/libumem.html"


次のコマンドを使用して、Directory Server を再起動します。









# SUN_SUPPORT_SLAPD_NOSH=true LD_PRELOAD=libumem.so \
UMEM_DEBUG=contents,audit=40,guards UMEM_LOGGING=transaction ./start-slapd





これで、Directory Server の起動前に、SmartHeap を使用せずに libumem ライブラリが読み込まれます。


次に、gcore コマンドを複数回実行します。メモリー使用量が増え始める前に 1 回、増え始めたあとで 1 回実行するようにしてください。gcore コマンドにより、アドレスとポインタのリストが出力されます。出力結果を使って、libumem ライブラリを読み取ります。









# cd install-root/bin/slapd/server
gcore -o /tmp/directory-core process-id






最後に、mdb および splitrec ツールを使用して結果を分析します。splitrec ツールは、結果を比較してリークの完全なスタックを確認します。









# cd install-root/bin/slapd/server
echo "::umausers -e" | mdb ./ns-slapd path_gcore1 > res.1
eacho "::umausers -e" | mdb ./ns-slapd path_gcore2 > res.2
splitrec -1 res.1 res.2






splitrec ツールは、Sun サポートから入手できます。このツールは、割り当てスタックのリーク原因として特定されたスタックの概要を示します。Sun サポートでは、これらのスタックの内容を使って、SunSolve データベース内で既知のメモリーリークを特定します。splitrec ツールのデフォルト設定では、リークが 100 回を超えていることが確認されたスタックだけがリークとして報告されるため、出力が生成されないことがあります。splitrec  -l オプションを使って、制限値を引き下げてください。