test

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

Directory Proxy Server プロセスの問題のトラブルシューティング

この節では、次の手順について説明します。

プロセスのトラブルシューティングツールの概要

Solaris および Java に付属するツールに、プロセスに関する問題のトラブルシューティングに利用できるものがあります。以降の節で、もっとも有用性の高いツールの概要を説明します。

Directory Proxy Server 6.3 での Java ツールの使用

Directory Proxy Server 6.3 は Pure Java アプリケーションであるため、JDK 1.5 に付属の Java ツールを問題のトラブルシューティングに使用できます。次のツールが含まれます。

Solaris では、これらのツールは次の場所に存在します。


/usr/lang/JAVA/jdk1.5.0_03/solaris-sparc/bin

JVM には、JConsole (Java Monitoring and Management Console) ツールと呼ばれる、Java 仮想マシンを監視するためのグラフィカルツールも含まれます。このツールは、Java プラットフォーム上で JMX (Java Management Extension) テクノロジを使用して稼働しているアプリケーションのパフォーマンスおよびリソース消費に関する情報を、Java 仮想マシンを使用して提供します。JConsole を使用して、Java プラットフォームで稼働しているアプリケーションに関する情報を確認できます。JConsole は、メモリー使用状況、スレッド使用状況、クラスローディング、および JVM パラメータに関する情報およびチャートを提供します。

Unix プラットフォームでは、スレッドダンプの取得に kill -QUIT process-id コマンドを使用してもうまくいかない場合に、jstack が使用されます。

Directory Proxy Server 5.x での Solaris ツールの使用

Solaris に含まれるプロセスツールのコレクションを使用すると、ハングアップしたプロセス、クラッシュしたプロセス、メモリー使用量の問題など、プロセスに関する問題の詳細を収集するのに役立ちます。次のツールが含まれます。

ハングアップまたは応答しない Directory Proxy Server プロセスのトラブルシューティング

この節では、応答しないまたはハングアップした Directory Proxy Server プロセスのトラブルシューティングについて説明します。まったく応答しないプロセスを、ハングアップと呼びます。この節の以降の部分では、ハングアップに関するデータを収集および分析する方法について説明します。

Solaris での Directory Proxy Server 6.3 のハングアップに関するデータの収集

jstat ツールは、CPU の使用量をスレッドごとに示します。jstat ツールの実行と同時に jstack ユーティリティーを使用してスレッドスタックを収集する場合は、jstack の出力を使って問題発生時のスレッドの動作を確認できます。jstack および jstat ツールを同時に何度も実行していくと、問題が同じスレッドで発生していたのか、また同じ関数呼び出しで発生していたのかを確認できます。

実行中の Directory Proxy Server のプロセス ID を取得するには、jps コマンドを使用します。たとえば、Solaris では、次のようにこのコマンドを実行します。


# jps
8393 DistributionServerMain
2115 ContainerPrivate
21535 startup.jar
16672 Jps
13953 swupna.jar

次のように使用状況の情報を収集します。


# ./scp DPS-PID

DPS-PID フィールドには、応答しないプロセスの PID を指定します。

Solaris およびその他の UNIX プラットフォームでは、次のように truss コマンドを使用して、クラッシュ時に発生するシステムコールを表示します。


truss -o /tmp/trace.txt -ealf -rall -wall -vall -p 21362

値 21362 は、応答しないプロセスの PID に対応します。

Solaris での Directory Proxy Server 5.x のハングアップに関するデータの収集および分析

prstat ツールは、CPU の使用量をスレッドごとに示します。prstat ツールの実行と同時に pstack ユーティリティーを使用してプロセススタックを収集する場合は、pstack の出力を使って問題発生時のスレッドの動作を確認できます。prstat および pstack ツールを同時に何度も実行していくと、問題が同じスレッドで発生していたのか、また同じ関数呼び出しで発生していたのかを確認できます。

注 –

Linux では、Solaris の pstack ユーティリティーの代わりに lsstack または pstack コマンドを使用します。

次に示すのは、これらのツールの実行を自動化するスクリプトです。


cat scp
#!/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

[ "$i" -lt "10" ] 行の値 10 は、トラブルシューティング中の問題が発生する時間に合わせて増減できます。この調整により、完全なプロセスデータセットを収集して問題のトラブルシューティングに役立てることができます。このようにして、問題に関係する完全なプロセスデータセットの入手が可能になります。

次のように使用状況の情報を収集します。


# ./scp DPS-PID

DPS-PID フィールドには、応答しないプロセスの PID を指定します。

Solaris およびその他の UNIX プラットフォームでは、次のように truss コマンドを使用して、クラッシュ時に発生するシステムコールを表示します。


truss -o /tmp/trace.txt -ealf -rall -wall -vall -p 21362

値 21362 は、応答しない ldapfwd プロセスの PID に対応します。

ハングアップに関するデータの分析

Directory Proxy Server がクラッシュする際には、常にコアが生成されます。このコアファイルおよびそのプロセススタックを使って、問題を分析できます。コアファイルの分析については、「Solaris でのコアファイルの確認」を参照してください。ただし、ユーティリティーを ns-slapd バイナリディレクトリから実行するのではなく、から実行する必要があります。

たとえば、truss コマンドの出力がクラッシュ時にシステムコールが作成されていないことを示している場合は、パッシブハングアップであることがわかります。コアファイルおよび jstack または pstack の情報を確認することにより、処理を続行するためにロックが解除されるのを待っている複数のスレッドを特定できます。さまざまなツールの出力を比較することにより、問題の原因がデッドロックであることを推測できます。この情報を使用することで、Sun サポートは問題解決の支援を適時的確に行うことができます。

クラッシュした Directory Proxy Server プロセスのトラブルシューティング

コアファイルおよびクラッシュダンプは、プロセスまたはアプリケーションが異常終了したときに生成されます。これらのファイルを分析することが、問題の原因特定に役立ちます。

この節では、次の内容について説明します。

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

コアファイルを分析するため、Directory Proxy Server プロセスに関係付けられたすべてのライブラリおよびバイナリを取得します。サーバーがクラッシュしたときに Directory Proxy Server がコアファイルを生成できるように、システムを設定します。コアファイルの生成の詳細については、「コアファイルの生成」を参照してください。

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

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


# pkg_app pid core-file
注 –

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

Solaris での Directory Proxy Server 6.3 コアデータの分析

コアファイルを取得したあとで、このファイルに対して jstack および jpmap Java ツールを実行します。

次のように jstack ユーティリティーを実行します。


# jstack process-ID

次に、jstack ユーティリティーの出力例を示します。


# jstack 8393
Attaching to process ID 8393, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 1.5.0_03-b07
Thread t@1: (state = BLOCKED)

Thread t@42: (state = IN_NATIVE) 
 - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \
java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame)
 - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \
java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame)
 - sun.nio.ch.ServerSocketChannelImpl.accept() @bci=130, line=145 \
(Interpreted frame)
 - com.sun.directory.proxy.extensions.ExtendedTCPClientListener.run() \
@bci=267, line=190 (Interpreted frame)

Thread t@41: (state = IN_NATIVE)
 - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \
java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame)
 - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \
java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame)
 - sun.nio.ch.ServerSocketChannelImpl.accept() @bci=130, line=145 \
(Interpreted frame)
 - com.sun.directory.proxy.extensions.ExtendedTCPClientListener.run() \
@bci=267, line=190 (Interpreted frame)

Solaris での Directory Proxy Server 5.x コアデータの分析

コアファイルを取得したあとで、このファイルに対して pstack および pmap Solaris ユーティリティーを実行します。

次のように pstack ユーティリティーを実行します。


# pstack core-file > /tmp/pstack.txt

次に、pstack ユーティリティーの出力例を示します。


core '/var/core/core_dps-dr-zone1_ldapfwd_0_0_1156942096_3167' of 3167: ./ldapfwd 
-t /var/opt/mps/serverroot/dps-dps-dr-zone1/etc/tailor.txt
-----------------  lwp# 1 / thread# 1  --------------------
 fedc0b6c __pollsys (ffbff680, 2, ffbff610, 0, 0, 1770) + 8
 fed5cea8 poll     (ffbff680, 2, 1770, 10624c00, 0, 0) + 7c
 ff19c610 _pr_poll_with_poll (1770, ffbff680, 927c0, ffbff91c, 2, 1) + 42c
 00039504 __1cLCAI_LF_CmgrDrun6F_v_ (75, 115d74, 11202c, 2, 88c00, 116510) + 1a8
 00062070 ldapfwdMain (0, ffbffa84, c, 9952c, feb60740, feb60780) + 1c
 0002f968 _start   (0, 0, 0, 0, 0, 0) + 108
-----------------  lwp# 3 / thread# 3  --------------------
 fedc0b6c __pollsys (fea19b70, 3, fea19b00, 0, 0, 3e8) + 8
 fed5cea8 poll     (fea19b70, 3, 3e8, 10624c00, 0, 0) + 7c
 ff19c610 _pr_poll_with_poll (3e8, fea19b70, 186a0, fea19e8c, 3, 2) + 42c
 0005de38 __1cIidarPollEwait6MI_i_ (fea19e6c, 186a0, 16e360, 1, 0, 1) + 20
 000639ec __1cJHeartbeatJheartbeat6Fpv_1_ (158f40, 1, 14da70, faa36, 16e360, faa5d) + 114
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 136734 / thread# 136734  --------------------
 fedbfe40 __lwp_park (0, 0, 116710, 0, 0, 1) + 14
 00076548 __1cMCAI_LF_MutexHacquire6M_v_ (116708, fd2bc, 0, 46, fea24800, 1000) + 34
 00076158 __1cPCAI_LF_RefCountGAddRef6M_v_ (116708, 156510, 2400, 26dc, 11667c, 800) + 24
 0006ddb0 __1cVCAI_LF_ReferralServer2t5B6MpnPCAI_LF_ConnPair_pnVCAI_LF_RequestMessage_pnNCAI_LF_Server
_ipcibbi_v_ (197198, fe7790d8, 1541c0, 156510, 185, 1565b8) + 50
 00046324 __1cPCAI_LF_ConnPairYstart_referral_operation6MipCpnNCAI_LF_Server_i_i_ (fe7790d8, 1, 1565b8
, 156510, 1, 197198) + 26c
 0004f2a0 __1cPCAI_LF_ConnPairLsend_result6MrnOCAI_LF_Message_rnVCAI_LF_RequestMessage__v_ (fe7790d8, 
156eb8, 1541c0, 2400, 0, 0) + 354
 00044758 __1cPCAI_LF_ConnPairOinner_activity6MpnOCAI_LF_Message__v_ (fe7790d8, 156eb8, 11202c, f4f27,
 fe7790f8, 1) + 114c
 00045c24 __1cPCAI_LF_ConnPairDrun6M_v_ (fe7797c8, 198383, 170c78, fe7790d8, fe779e54, fe779740) + 6cc
 00046cd0 CAI_LF_StartFunction (157500, 11202c, 1, 0, 46ab4, 1) + 21c
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 136735 / thread# 136735  --------------------
 fedc0b6c __pollsys (fe9e8d98, 3, fe9e8d28, 0, 0, 1d4c0) + 8
 fed5cea8 poll     (fe9e8d98, 3, 1d4c0, 10624c00, 0, 0) + 7c
 ff19c610 _pr_poll_with_poll (1d4c0, fe9e8d98, b71b00, fe9e9e74, 3, 2) + 42c
 0005de38 __1cIidarPollEwait6MI_i_ (fe9e9e54, b71b00, 1, f4f27, fe9e90f8, 12d8d0) + 20
 00045cbc __1cPCAI_LF_ConnPairDrun6M_v_ (fe9e97c8, 17bb43, 130ff8, fe9e90d8, fe9e9e54, fe9e9740) + 764
 00046cd0 CAI_LF_StartFunction (157500, 11202c, 1, 0, 46ab4, 1) + 21c
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 136738 / thread# 136738  --------------------
 fedc0b6c __pollsys (fe9a8d98, 3, fe9a8d28, 0, 0, 1d4c0) + 8
 fed5cea8 poll     (fe9a8d98, 3, 1d4c0, 10624c00, 0, 0) + 7c
 ff19c610 _pr_poll_with_poll (1d4c0, fe9a8d98, b71b00, fe9a9e74, 3, 2) + 42c
 0005de38 __1cIidarPollEwait6MI_i_ (fe9a9e54, b71b00, 1, f4f27, fe9a90f8, 0) + 20
 00045cbc __1cPCAI_LF_ConnPairDrun6M_v_ (fe9a97c8, 198123, 130fd8, fe9a90d8, fe9a9e54, fe9a9740) + 764
 00046cd0 CAI_LF_StartFunction (157500, 11202c, 1, 0, 46ab4, 1) + 21c
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 136788 / thread# 136788  --------------------
 00197d68 ???????? (116708, 1, 156510, 0, 0, 1000)
 0006dee4 __1cVCAI_LF_ReferralServer2T6M_v_ (155780, 1000, fedecbc0, fea25c00, fe779780, 0) + 34
 000707c4 __SLIP.DELETER__A (155780, 1, 4, a6c, 1, 2400) + 4
 00046a94 CAI_LF_ReferralStartFunction (155780, fe6da000, 0, 0, 46a64, 1) + 30
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)

pstack コマンドの代わりに mdb または adb コマンドを使用してもコアのスタックを表示できます。mdb コマンドはモジュラーデバッガであり、adb コマンドは Solaris に含まれる汎用デバッガです。次のように 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 を含まないスレッドを検索して、スタックを分析します。

Solaris では、Solaris dbx シンボリックデバッガも使用できます。これは、http://sun.com/ から無料で入手可能な開発者用のツールです。dbx ツールを使用すると、シンボリックデバッグを実行できます。このツールには操作可能な変数が含まれます。次に、dbx デバッガの出力例を示します。


current thread: t@2482121
=>[1] 0x0(0x156138, 0x0, 0xff000000, 0xfedefad4, 0x2, 0x2), at 0xffffffffffffffff
  [2] CAI_LF_RefCount::Release(0x116708, 0x1, 0x156138, 0x0, 0x0, 0x1000), at 0x7629c
  [3] CAI_LF_ReferralServer::~CAI_LF_ReferralServer(0x241270, 0x1000, 0xfedecbc0, 0xfe097c00, 
0xfe8d9780, 0x0), at 0x6dee4
  [4] __SLIP.DELETER__A(0x241270, 0x1, 0x4, 0xa6c, 0x1, 0x2400), at 0x707c4
  [5] CAI_LF_ReferralStartFunction(0x241270, 0xfe81a000, 0x0, 0x0, 0x46a64, 0x1), at 0x46a94

Linux での Directory Proxy Server 5.x コアデータの分析

Linux では、Solaris の pstack ユーティリティーの代わりに lsstack または pstack コマンドを使用します。次のように lsstack コマンドを実行します。


# lsstack /tmp/core-file

GNU プロジェクトデバッガ gdb を使用して、クラッシュ時に何が起きたかを確認することもできます。次のようにデバッガを実行します。


# gdb ./ldapfwd /tmp/core-file

gdb ツールで使用可能な有用なコマンドの詳細については、gdb のマニュアルページを参照してください。

HP-UX での Directory Proxy Server 5.x コアデータの分析

HP-UX では、Linux の場合と同様、GNU プロジェクトデバッガを使用してクラッシュ時に何が起きたかを確認することもできます。次のようにデバッガを実行します。


# gdb ./ldapfwd /tmp/core-file

gdb ツールで使用可能な有用なコマンドの詳細については、gdb のマニュアルページを参照してください。

Windows での Directory Proxy Server 5.x コアデータの分析

Windows では、カーネルおよび NT デバッグ用の UI を提供する WinDbg デバッガを使用できます。このデバッガは、カーネルモードとユーザーモードの両方で動作可能です。Windows のクラッシュダンプファイルに対して、このデバッガを実行します。