Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionトラブルシューティング・ガイド 11g リリース 1 (11.1.1.7.0) B72443-01 |
|
前 |
次 |
この章では、Directory Proxy Serverで発生する問題をトラブルシューティングする方法について説明します。この章の内容は、次のとおりです。
発生している問題の種類に関係なく、収集し、必要に応じてSunのサポートに提供しなければならない最小限のデータのセットがあります。
この後の各項では、現在および以前のバージョンのDirectory Proxy Serverの構成情報を収集する方法について説明します。
Directory Proxy Serverのバージョン情報は、次のいずれかの方法を使用して収集できます。
Directory Proxy Serverバージョンに関する詳細情報を取得するには、$dpadm -V
コマンドを使用します。これは次のような出力を表示します。
[dpadm] dpadm : 7.0 B2009.0219.2158 NAT Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. [DPS] Sun Microsystems, Inc. Sun-Java(tm)-System-Directory-Proxy-Server/7.0 B2009.0219.2146
バージョン情報は、instance-dir
/logs/error
ファイルにあります。たとえば、エラー・ログにはバージョン情報が次のように表示されます。
[31/Mar/2009:18:45:34 +0530] - STARTUP - INFO - \ Sun-Directory-Proxy-Server/7.0 B2009.0219.2146 started \ on host server1 in directory /local/dps.3333
dpadm
コマンドの実行dpadm
コマンドを冗長モードで実行すると、インスタンスの作成や削除、データのバックアップなどで発生する問題のトラブルシューティングに役立つ情報が提供されます。次のように、dpadm
を冗長モードで実行します。
# dpadm -v
Directory Proxy Serverの構成情報を収集します。この情報は、instance-dir
/logs/errors
ファイルにあります。たとえば、エラー・ログには構成情報が次のように表示されます。
user@server1 local]$ more dps.3333/logs/errors [31/Mar/2009:18:45:33 +0530] - STARTUP - INFO - \ Global log level INFO (from config) [31/Mar/2009:18:45:33 +0530] - STARTUP - INFO - \ Logging Service configured [31/Mar/2009:18:45:33 +0530] - STARTUP - INFO - \ Java Version: 1.5.0_12 (Java Home: /usr/jdk/instances/jdk1.5.0/jre) [31/Mar/2009:18:45:33 +0530] - STARTUP - INFO - \ Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) [31/Mar/2009:18:45:33 +0530] - STARTUP - INFO - \ Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_12-b04, mixed mode) [31/Mar/2009:18:45:33 +0530] - STARTUP - INFO - \ Java Heap Space: Total Memory (-Xms) = 241MB, Max Memory (-Xmx) = 241MB [31/Mar/2009:18:45:33 +0530] - STARTUP - INFO - \ Operating System: SunOS/sparcv9 5.9 [31/Mar/2009:18:45:33 +0530] - STARTUP - INFO - \ SSL initialization succeeded. [31/Mar/2009:18:45:33 +0530] - CONFIG - WARN - \ Attribute certMappingDataViewPolicy in entry \ cn=LDAPS Listener,cn=Client Listeners,cn=config missing. Using ALL_DATA_VIEW [31/Mar/2009:18:45:33 +0530] - STARTUP - INFO - \ Creating 50 worker threads. [31/Mar/2009:18:45:34 +0530] - BACKEND - WARN - \ Can't retrieve LDAP schema (LDAP error code: 32) \ No data view were found to process the search request. [31/Mar/2009:18:45:34 +0530] - STARTUP - INFO - \
Directory Proxy Serverのログを収集します。デフォルトでは、ログは次のディレクトリに格納されます。
instance-path/logs
Sunのサポートにこの情報を提供する場合は、関係する各種のDirectory Serverから入手可能な一般的なDirectory Serverデータも含める必要があります。この一般的なデータには、Directory ServerのバージョンおよびDirectory Serverのアクセス・ログ、エラー・ログおよび監査ログが含まれます。Directory Serverの一般情報の収集の詳細は、「汎用データの収集」を参照してください。
JDBCバックエンド、SQLデータベース、Oracle Databaseなど、その他のバックエンド・サーバーを使用している場合は、それらの一般情報も含めます。
この項では、次の手順について説明します。
SolarisおよびJavaに付属するツールに、プロセスに関する問題のトラブルシューティングに利用できるものがあります。次の各項では、最も効果的なツールの概要を説明します。
Directory Proxy Server 11gリリース1 (11.1.1.6.0)Pure Javaアプリケーションであるため、JDK 1.5に付属のJavaツールを問題のトラブルシューティングに使用できます。このツールの例を次に示します。
jstack
。このツールは、Directory Proxy Serverスレッド・スタックに関する情報を提供します。
jmap
。このツールは、メモリーに関する情報を提供します。たとえば、jmap —histo
PID
を実行すると、ヒープのヒストグラムが出力されます。
jinfo
。このツールは、JVM環境に関する情報を提供します。
jstat
。このツールは、JVMのパフォーマンス統計を表示します。
JVMには、Java Monitoring and Management Console (JConsole)ツールと呼ばれる、Java仮想マシンを監視するためのグラフィカル・ツールも含まれます。このツールは、Javaプラットフォーム上でJava Management Extension (JMX)テクノロジを使用して実行しているアプリケーションのパフォーマンスおよびリソース使用量に関する情報を、Java仮想マシンを使用して提供します。JConsoleを使用して、Javaプラットフォームで実行中のアプリケーションに関する情報を確認できます。JConsoleは、メモリー使用量、スレッド使用状況、クラスのロードおよびJVMパラメータに関する情報およびチャートを提供します。
Unixプラットフォームでは、スレッド・ダンプの取得にkill -QUIT process-id
コマンドがうまく機能しない場合に、jstack
を使用します。
Solarisに含まれるプロセスツールのコレクションは、ハングしたプロセス、クラッシュしたプロセス、メモリー使用量の問題など、プロセスに関する問題の詳細を収集するのに役立ちます。このツールの例を次に示します。
pmap
— 仮想アドレスのリストを含むプロセス・マップを表示しますが、ここは、動的ライブラリのロード先であるとともに、変数が宣言される場所でもあります。
pstack
— プロセス・スタックを表示します。プロセス内のスレッドごとに、プロセスの終了時またはpstack
コマンドの実行時にスレッドが実行していた命令のスタックを示します。
pfiles
— 各プロセスで開いているすべてのファイルに関する情報をレポートします。
pldd
— 各プロセスにリンクされている動的ライブラリをリストします。
この項では、応答しないまたはハングしているDirectory Proxy Serverプロセスのトラブルシューティング方法について説明します。まったく応答しないプロセスを、ハングと呼びます。この項の残りの部分では、ハングに関するデータを収集および分析する方法について説明します。
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
次のスクリプトでは、これらのツールの実行プロセスを自動化します。
cat scpTools #!/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
は、トラブルシューティングしている問題が発生する時間に合わせて増減できます。この調整により、完全なプロセス・データ・セットを収集して問題のトラブルシューティングに役立てることができます。したがって、問題に関係する完全なプロセス・データ・セットの入手が可能になります。
次のように使用状況の情報を収集します。
# ./scpTools DPS-PID
DPS-PIDフィールドには、応答しないプロセスのPIDを指定します。Directory Proxy ServerのPIDには、行DistributionServerMain
が含まれています。
Solarisおよびその他のUNIXプラットフォームでは、次のようにtruss
コマンドを使用して、クラッシュ時に発生するシステム・コールを表示します。
truss -o /tmp/trace.txt -ealf -rall -wall -vall -p 21362
値21362
は、応答しないプロセスのPIDに対応します。
この項では、次の図を使用して、サーバーで操作が処理される方法およびそれらの処理に関連するリソースについて説明します。リソース使用率は、Directory Proxy ServerプロセスにUSR2
シグナルを送信することで、エラー・ログ・ファイルにダンプできます。
Clientlistener
は、クライアントからの新しい受信接続を検出し、それらを保留接続のバッファに格納します。ConnectionHandler
は、随時、保留接続のすべてをフェッチして、処理する接続(Java Selector)のリストに入れます。次のリソース・ダンプの抜粋は、受信接続の数を示します。
0.0.0.0:2389 useSSL:false Thread[Connection Handler 0 for Listener Thread 0.0.0.0:2389,5,main] ConnectionHandler pending connections = 0 ConnectionHandler pending connections 2 = 0 ConnectionHandler connections in selector = 1 Thread[Connection Handler 1 for Listener Thread 0.0.0.0:2389,5,main] ConnectionHandler pending connections = 0 ConnectionHandler pending connections 2 = 0 ConnectionHandler connections in selector = 0
デフォルトでは、Directory Proxy Serverには、通常接続用とセキュアな接続用の2つのリスナーがあり、各クライアント・リスナーには、2つの接続ハンドラがあります。
ConnectionHandler
は、ファイル記述子内のバイト数を読み取り、完全なLDAP操作の取得後に、それらをWorkQueue
に入れます。キュー内の操作は、処理のためにWorkerThreads
によって取得されます。常にWorkQueue
は、リソース・ダンパーに対して次の情報を使用可能な状態にします。
WorkQueue Norm inQ = 0 number of operations in the Q WorkQueue Norm peak = 1 the peak of operations in the Q WorkQueue Norm totalIn = 1875 the total # of operations put by the connection handlers WorkQueue Norm totalOut = 1875 the total # of operations get by the workers WorkQueue High inQ = 0 -- same but foe the "high priority" Q WorkQueue High peak = 0 -- same but foe the "high priority" Q WorkQueue High totalIn = 0 -- same but foe the "high priority" Q WorkQueue High totalOut = 0 -- same but foe the "high priority" Q WorkQueue abandonRequests = 0 the number of abandon requests WorkQueue abandonSuccess = 0 the number of succeeded abandons
WorkQueue
が空の場合、WorkerThreads
はアイドルです。WorkerThread
がWorkQueue
から操作を取得すると、すぐにビジーになります。リソース・ダンパーは、WorkerThreads
の状態を提供します。
WorkerThread: idle = 49 -> all the WorkerThreads are idle but 1 WorkerThread: busy = 1
処理の最初の段階で、WorkerThread
操作をルーティング可能なデータ・ビューのリストを取得します。この手順はここには記載されていません。次に、選択されたそれぞれのデータ・ビューは、データ・ソース・プールを通って、LDAPサーバーに到達します。LDAPサーバーは、ロード・バランシング・アルゴリズムによって選択されます。たとえば、Proportionalロード・バランシングが使用されている場合、統計は次のようになります。
Data Source Pool pool1 pool1 - ProportionalLB - total connections - Bind (provided=0 refused=0) pool1 - ProportionalLB - total connections - Add (provided=0 refused=0) pool1 - ProportionalLB - total connections - Search (provided=0 refused=0) pool1 - ProportionalLB - total connections - Compare (provided=0 refused=0) pool1 - ProportionalLB - total connections - Delete (provided=0 refused=0) pool1 - ProportionalLB - total connections - Modify (provided=0 refused=0) pool1 - ProportionalLB - total connections - ModifyDN (provided=0 refused=0) pool1 - ProportionalLB - Connections per server for Bind pool1 - ProportionalLB - ds1 (provided=0 refused=0) pool1 - ProportionalLB - Connections per server for Add pool1 - ProportionalLB - ds1 (provided=0 refused=0) pool1 - ProportionalLB - Connections per server for Search pool1 - ProportionalLB - ds1 (provided=0 refused=0) pool1 - ProportionalLB - Connections per server for Compare pool1 - ProportionalLB - ds1 (provided=0 refused=0) pool1 - ProportionalLB - Connections per server for Delete pool1 - ProportionalLB - ds1 (provided=0 refused=0) pool1 - ProportionalLB - Connections per server for Modify pool1 - ProportionalLB - ds1 (provided=0 refused=0) pool1 - ProportionalLB - Connections per server for ModifyDN pool1 - ProportionalLB - ds1 (provided=0 refused=0)
選択されたLDAPサーバーは、リモート・バックエンドに接続を提供するように要求されます。リモート・バックエンドへの接続は、接続の2つのプール(ConnectionPool
)を使用して管理されます。たとえば、1つのプールは通常接続用で、もう一方のプールはセキュアな接続用です。Directory Proxy Serverでリモート・バックエンドに対してセキュアな接続のみが構成されている場合は、2つ目のプールは使用されず、最初のプールにセキュアな接続が含まれます。各プールには、BIND
操作、READ
操作およびWRITE
操作に専用の接続が含まれています。これらのそれぞれのセットに対して、リソース・ダンパーはプール内の現在の接続数および使用可能な接続数を報告します。接続数は必要に応じて増やすことができますが、接続の最大数(デフォルトで1024)を超えることはできません。
BackendConnectionPool [woz:8389/:pool1-DS1] BIND (max=1024 cur=10 avail=10) BackendConnectionPool [woz:8389/:pool1-DS1] READ (max=1024 cur=10 avail=10) BackendConnectionPool [woz:8389/:pool1-DS1] WRITE (max=1024 cur=10 avail=10) BackendConnectionPool [woz:8389/:pool1-DS1] Bound connections = 0 BackendConnectionPool [woz:8389/:pool2-DS1] BIND (max=1024 cur=0 avail=0) BackendConnectionPool [woz:8389/:pool2-DS1] READ (max=1024 cur=0 avail=0) BackendConnectionPool [woz:8389/:pool2-DS1] WRITE (max=1024 cur=0 avail=0) BackendConnectionPool [woz:8389/:pool2-DS1] Bound connections = 0
LDAPサーバーは、プールの使用率に関する統計をとります。
bindConnectionsRequested = 0 bindConnectionsProvided = 0 bindConnectionsRefused = 0 bindConnectionWaitsRequired = 0 bindConnectionsReturnedValid = 0 bindConnectionsReturnedInvalid = 0 readConnectionsRequested = 0 readConnectionsProvided = 0 readConnectionsRefused = 0 readConnectionWaitsRequired = 0 readConnectionsReturnedValid = 0 readConnectionsReturnedInvalid = 0 writeConnectionsRequested = 0 writeConnectionsProvided = 0 writeConnectionsRefused = 0 writeConnectionWaitsRequired = 0 writeConnectionsReturnedValid = 0 writeConnectionsReturnedInvalid = 0
常に、requested = provided + refused
で要求した数の接続があります。WorkerThread
は、接続が使用可能になるまで少し待機する必要があることがあります。ジョブの完了後、WorkerThread
は接続をプールに返します。接続が有効でなくなった場合は、接続は無効として返され、再使用することはできません。
これらのバックエンドに対する接続に関する数値は、サーバー・リソースのチューニングに役立てることができます。次に例を示します。
totalReadConnections: 1024 availableReadConnections: 0 readConnectionsRequested: 2121 readConnectionsProvided: 1612 readConnectionsRefused: 509 readConnectionWaitsRequired: 1019 readConnectionsReturnedValid: 1612 readConnectionsReturnedInvalid: 0
提供されたデータの分析後に、次のことが完了します。
プールには使用可能な接続がなく、プールは最大サイズ(1024接続)に達します。
リクエストは2121個があり、接続は1612のみ提供されていますが、これはスケーラビリティの面でよくありません。
ワーカー・スレッドは接続が使用可能になるまでに1019回待機する必要があり、これはパフォーマンスの面でよくありません。
すべての拒否された接続は、クライアントにSERVER_ERROR
を返して終了します。
拒否された接続を防ぐには、プールで許可される接続の最大数を増やし、使用可能な接続が不足するのを防ぎます。たとえば、サーバーに十分なファイル記述子がないなどでこれが実行できない場合は、次のコマンドを使用して、WorkerThreads
の数を減らします。
$ dpconf set-server-prop -e -h host -p port number-of-worker-threads:number
このコマンドは、conf.ldif
ファイルのcn=config
のnumWorkerThreads
属性を設定します。
レスポンス時間は低下しますが、クライアントがこれ以降SERVER_ERROR
ステータス・コードを受け取ることはありません。
cn=monitor
下のデータを使用したDirectory Proxy Serverのトラブルシューティングcn=monitor
のDIT下にあるデータは、様々な根本的な問題の特定および修復に役立ちます。cn=monitor
は、パフォーマンスと使用状況、Directory Proxy Serverインスタンスに対するLDAP操作またはサービス、リモート・サービス、接続、ロード・バランシング、JVM、接続ハンドラ・スレッド、ワーク・キュー、その他の様々なスレッドなどの各種の問題を発見するための情報を提供します。
cn=monitor
のレイアウトおよびその下の各エントリの説明を理解するには、『Oracle Directory Server Enterprise Editionリファレンス』のDirectory Proxy Serverの監視に関する説明を参照してください。