ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionトラブルシューティング・ガイド
11g リリース 1 (11.1.1.7.0)
B72443-01
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

4 Directory Proxy Serverのトラブルシューティング

この章では、Directory Proxy Serverで発生する問題をトラブルシューティングする方法について説明します。この章の内容は、次のとおりです。

4.1 一般的なDirectory Proxy Serverデータの収集

発生している問題の種類に関係なく、収集し、必要に応じてSunのサポートに提供しなければならない最小限のデータのセットがあります。

4.1.1 Directory Proxy Serverのバージョン情報の収集

この後の各項では、現在および以前のバージョンの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
    

4.1.2 冗長モードでのdpadmコマンドの実行

dpadmコマンドを冗長モードで実行すると、インスタンスの作成や削除、データのバックアップなどで発生する問題のトラブルシューティングに役立つ情報が提供されます。次のように、dpadmを冗長モードで実行します。

# dpadm -v

4.1.3 Directory Proxy Serverの構成情報の収集

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  - \

4.1.4 Directory Proxy Serverのログ情報の収集

Directory Proxy Serverのログを収集します。デフォルトでは、ログは次のディレクトリに格納されます。

instance-path/logs

Sunのサポートにこの情報を提供する場合は、関係する各種のDirectory Serverから入手可能な一般的なDirectory Serverデータも含める必要があります。この一般的なデータには、Directory ServerのバージョンおよびDirectory Serverのアクセス・ログ、エラー・ログおよび監査ログが含まれます。Directory Serverの一般情報の収集の詳細は、「汎用データの収集」を参照してください。

JDBCバックエンド、SQLデータベース、Oracle Databaseなど、その他のバックエンド・サーバーを使用している場合は、それらの一般情報も含めます。

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

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

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

SolarisおよびJavaに付属するツールに、プロセスに関する問題のトラブルシューティングに利用できるものがあります。次の各項では、最も効果的なツールの概要を説明します。

4.2.1.1 Directory Proxy Server 11gリリース1 (11.1.1.6.0)での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を使用します。

4.2.1.2 Directory Proxy ServerでのSolarisツールの使用方法

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

  • pmap — 仮想アドレスのリストを含むプロセス・マップを表示しますが、ここは、動的ライブラリのロード先であるとともに、変数が宣言される場所でもあります。

  • pstack — プロセス・スタックを表示します。プロセス内のスレッドごとに、プロセスの終了時またはpstackコマンドの実行時にスレッドが実行していた命令のスタックを示します。

  • pfiles— 各プロセスで開いているすべてのファイルに関する情報をレポートします。

  • pldd — 各プロセスにリンクされている動的ライブラリをリストします。

4.2.2 ハングしているか応答しないDirectory Proxy Serverプロセスのトラブルシューティング

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

4.2.2.1 Solaris上でハングしているDirectory Proxy Server 11gリリース1 (11.1.1.6.0)に関する情報の収集

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に対応します。

4.2.3 拒否された接続に対するDirectory Proxy Serverのトラブルシューティング

この項では、次の図を使用して、サーバーで操作が処理される方法およびそれらの処理に関連するリソースについて説明します。リソース使用率は、Directory Proxy ServerプロセスにUSR2シグナルを送信することで、エラー・ログ・ファイルにダンプできます。

working_threads.pngの説明が続きます
working_threads.pngの説明

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はアイドルです。WorkerThreadWorkQueueから操作を取得すると、すぐにビジーになります。リソース・ダンパーは、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=confignumWorkerThreads属性を設定します。

レスポンス時間は低下しますが、クライアントがこれ以降SERVER_ERRORステータス・コードを受け取ることはありません。

4.3 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の監視に関する説明を参照してください。