ページの先頭行へ戻る
Interstage Application Server/Interstage Web Server トラブルシューティング集
Interstage

1.5.3 運用

  スナップショットの運用について説明します。

ポイント

  スナップショットを採取するためには、アプリケーションにサーバ用ライブラリ(“CORBAサービス”パッケージに含まれる)をリンクする必要があります。以下に必要となるサーバ用ライブラリを示します。

開発言語

ライブラリ名

C・C++

ODSV.LIB

Java

ODjava4.jar

COBOL (スレッドモード)

ODCOBCBLMTSV.LIB または ODCOBCBLSVUC.LIB

COBOL (プロセスモード)

ODCOBCBLSV.LIB または ODCOBCBLSVUC.LIB

OOCOBOL

ODOOCOBSV.LIB または ODOOCOBSVUC.LIB

開発言語

ライブラリ名

C・C++

libOM.so

Java

ODjava4.jar

COBOL (スレッドモード)

libOMcblMT.so

COBOL (プロセスモード)

libOMcbl.so

OOCOBOL

libOMoocob.so

開発言語

ライブラリ名

C・C++

libOM.so

Java

ODjava4.jar

注意

  サーバ用ライブラリは、本製品の“CORBAサービス”(サーバ機能)に含まれています。インストール時には、必ず、“CORBAサービス”パッケージを選択してください。“CORBAサービスクライアント”(クライアント機能)をインストールしても、ログ採取機能は有効になりませんので注意してください。


1.5.3.1 スナップ情報の採取


■手順

  スナップ情報を採取する手順を以下に示します。

  1. スナップ情報の採取開始
    サーバアプリケーションが動作していることを確認後、odstartsnapコマンドを使用してスナップ情報の採取を開始します。
      

  2. スナップ情報採取終了
    目的のスナップ情報を採取した後、odstopsnapコマンドを使用してスナップ情報の採取を終了します。スナップ情報の採取を終了する必要がない場合は、そのまま3.に進んでください。
      

  3. スナップショットのフォーマット出力
    odformsnapコマンドを使用して、採取したスナップ情報をファイルに出力します。このスナップ情報により、アプリケーションの送受信情報を取得することができます。

  必要に応じて、odfreesnapコマンドを使用してメモリ上のスナップ情報をクリアしてください。


■コマンド

  スナップ情報の採取は、以下に示す4つのコマンドで操作を行います。

  odstartsnapコマンド

  スナップ情報の採取を開始します。このコマンドを使用する場合、スナップ情報を採取するプロセスが起動されている必要があります。

  odstopsnapコマンド

  スナップ情報の採取を終了します。

  odformsnapコマンド

  メモリ上に採取されたスナップ情報をファイルへ出力します。作成されるディレクトリは、コマンド使用時のカレントディレクトリです。

  odfreesnapコマンド

  メモリ上に採取したスナップ情報をクリアします。


1.5.3.2 スナップ情報の出力形式

  odformsnapコマンドが出力するスナップ情報の出力形式を以下に示します。

  Time        ProcessID Action     Type   requestID  QueueID  implID                    operation  host
  ----------------------------------------------------------------------------------------------------------
  22:33:39.180  359 request send     client  1      -------  IDL:CosNaming/NamingContext:1.0  resolve  hostABC
  22:33:39.191  202 request queue-in manager 1      1b3f664  IDL:CosNaming/NamingContext:1.0  ----     ---
  22:33:39.191  248 request recv     server  1      1b3f664  IDL:CosNaming/NamingContext:1.0  resolve  ---
  22:33:39.831  248 reply send       server  1      1b3f664  IDL:CosNaming/NamingContext:1.0  resolve  ---
  22:33:39.831  359 reply recv       client  1      -------  IDL:CosNaming/NamingContext:1.0  ----     hostABC
  Time

  スナップ情報が採取された時間。「時:分:秒.ミリ秒」で表示されます。これはスナップ情報が記録された時間であるため、実際に送受信された時刻と完全には一致しません。

  ProcessID

  送受信を行ったプロセスのプロセスID。

  Action

  送受信の動作種別を示します。動作種別は以下の5つです。

  • request send

      リクエストが送信されたことを示します。

  • request queue-in

      リクエストがOD_startサービスによって受け付けられ、キューイングされたことを示します。

  • request recv

      リクエストがサーバアプリケーションに受け付けられたことを示します。

  • reply send

      リクエストからの返信がサーバアプリケーションから送り出されたことを示します。

  • reply recv

      クライアントアプリケーションがサーバアプリケーションからの返信を受け取ったことを示します。

  Type

  送受信を行ったプロセス種別を示します。プロセス種別は以下の3つです。

  • client

      プロセスがクライアントアプリケーションとして動作していることを示します。

  • server

      プロセスがサーバアプリケーションとして動作していることを示します。

  • manager

      プロセスがOD_startサービスであることを示します。

  requestID

  送受信を行っているリクエストのIDを示します。

  QueueID

  送受信を行っているリクエストがキューイングされたキューのIDを示します。これは動作種別が“request queue-in”、“request recv”、“reply send”の3つの場合に表示されます。

  implID

  相手先サーバアプリケーションのインプリメンテーションリポジトリIDを示します。これは動作種別によって意味が異なります。

  • request send

      相手先サーバアプリケーションのインプリメンテーションリポジトリIDを示します。

  • request queue-in

      OD_startサービスが受け付けたリクエストのキューイング先のサーバアプリケーションのインプリメンテーションリポジトリIDを示します。

  • request recv

      リクエストを受け付けたサーバアプリケーションのインプリメンテーションリポジトリIDを示します。

  • reply send

      “request recv”と同じ意味です。

  • reply recv

      “request send”と同じ意味です。

  operation

  相手先サーバメソッドのオペレーション名を示します。これは動作種別が“request send”、“request recv”、“reply send”の3つの場合に表示されます。

  host

  相手先サーバマシンのホスト名を示します。これは、動作種別が“request send”、“reply recv”の場合に表示されます。


1.5.3.3 スナップ情報の分析

  以下の4つの例をもとにスナップ情報を分析する方法について説明します。


1:サーバアプリケーションとクライアントアプリケーションが同一マシン上で動作している場合

  ここではクライアントアプリケーション、サーバアプリケーション(ネーミングサービス)、OD_startサービスがすべて同一マシン“hostABC”にある場合のスナップ情報について説明します。

  Time      ProcessID Action            Type   requestID  QueueID  implID                         operation  host
  -----------------------------------------------------------------------------------------------------------------
  22:33:39.180    359 request send      client         1  -------  IDL:CosNaming/NamingContext:1.0  resolve  hostABC
  22:33:39.191    202 request queue-in  manager        1  1b3f664  IDL:CosNaming/NamingContext:1.0  ---      ---  
  22:33:39.191    248 request recv      server         1  1b3f664  IDL:CosNaming/NamingContext:1.0  resolve  ---  
  22:33:39.831    248 reply send        server         1  1b3f664  IDL:CosNaming/NamingContext:1.0  resolve  ---  
  22:33:39.831    359 reply recv        client         1  -------  IDL:CosNaming/NamingContext:1.0  ---      hostABC
  1. まず、時刻「22:33:39.180」にクライアントアプリケーションはリクエストID1のリクエストを送信しています。相手先サーバアプリケーションのインプリメンテーションリポジトリIDは“IDL:CosNaming/NamingContextExt:1.0”で、相手先サーバアプリケーションはネーミングサービスです。メソッド名は“resolve”であり、相手先のホストは“hostABC”であることがわかります。

  2. 時刻「22:33:39.191」にOD_startサービスはクライアントアプリケーションからのリクエスト(リクエストIDは1)を受け付けてキューイングしています。キューイングしたキューIDは、“1b3f664”です。

  3. 時刻「22:33:39.191」にサーバアプリケーションはキューID“1b3f664”のキューを取り出し、リクエストID1のリクエストを受け付けています。メソッド“resolve”が呼び出されています。

  4. 時刻「22:33:39.831」にサーバアプリケーションはリクエストID1のリクエストに対する返信をクライアントアプリケーションに返しています。このリクエストに対応していたキューIDは“1b3f664”であり、メソッド名は“resolve”であることを示します。

  5. 時刻「22:33:39.831」にクライアントアプリケーションはリクエストID1のリクエストに対する返信をサーバアプリケーションから受け取っています。

注意

  送受信のタイミングとスナップ情報の書き込みのタイミングは完全に一致しないため、“reply send”と“reply recv”の時刻が逆転する場合があります。


2:サーバアプリケーションとクライアントアプリケーションが別マシン上で動作している場合

  ここではサーバアプリケーション(ネーミングサービス)とOD_startサービスが“hostXYZ”にあり、クライアントアプリケーションは別マシンで動作している場合のスナップ情報について説明します。


  [クライアントマシンでの出力例]

  Time        ProcessID Action            Type   requestID  QueueID  implID                         operation  host
  -----------------------------------------------------------------------------------------------------------------
  22:35:39.150    407 request send      client         3  -------  IDL:CosNaming/NamingContext:1.0  resolve  hostXYZ
  22:35:40.534    407 reply recv        client         3  -------  IDL:CosNaming/NamingContext:1.0  ---      hostXYZ

  [サーバマシンでの出力例]

  Time        ProcessID Action            Type   requestID  QueueID  implID                         operation  host
  -----------------------------------------------------------------------------------------------------------------
  22:35:39.182      328 request queue-in  manager        3  2b3f656  IDL:CosNaming/NamingContext:1.0  ---      ---
  22:35:40.012      258 request recv      server         3  2b3f656  IDL:CosNaming/NamingContext:1.0  resolve  ---
  22:35:40.442      258 reply send        server         3  2b3f656  IDL:CosNaming/NamingContext:1.0  resolve  ---

  クライアントアプリケーション側で採取されるスナップ情報は、動作種別が“request send”のものと“reply recv”のものです。クライアントアプリケーション側のスナップ情報を見ると、リクエストID3のリクエストを時刻「22:35:39.150」に送信し、時刻「22:35:40.534」に返信を受け取っていることがわかります。

  サーバアプリケーション側で採取されるスナップ情報は、動作種別が“request queue-in”、“request recv”、“reply send”のものです。サーバアプリケーション側のスナップ情報を見ると時刻「22:35:39.182」にOD_startサービスがリクエストID3のリクエストをキューイングし、サーバアプリケーションが時刻「22:35:40.442」に返信をクライアントアプリケーションに送っていることがわかります。


3:サーバアプリケーションが異常状態にある場合

  ここではサーバアプリケーション(ネーミングサービス)が異常状態にある場合のスナップ情報について説明します。

  Time        ProcessID Action            Type   requestID  QueueID  implID                         operation  host
  -----------------------------------------------------------------------------------------------------------------
  22:41:59.730      237 request send     client        10  -------  IDL:CosNaming/NamingContext:1.0  resolve  hostABC
  22:41:59.730      202 request recv     manager       10  3bff4b8  IDL:CosNaming/NamingContext:1.0  resolve  ---
  22:41:59.730      202 reply send       manager       10  3bff4b8  IDL:CosNaming/NamingContext:1.0  resolve  ---
  22:41:59.730      237 reply recv       client        10  -------  IDL:CosNaming/NamingContext:1.0  ---      hostABC

  リクエストの送信先サーバプロセスが起動されていない等の異常状態にある場合は、OD_startサービスがサーバアプリケーションの代わりにリクエストを受け取り、例外情報をクライアントアプリケーションに返すことがあります。
  例外情報は、スナップ情報の出力からはわかりません。また、OD_startサービスがリクエストを処理している場合はリクエストがキューイングされません。そのため、動作種別が“request queue-in”であるスナップ情報はなく、キューID“3bff4b8”は意味を持ちません。


4:OD_startサービスに対してリクエストが発行された場合

  ここではOD_startサービスに対してリクエストが発行された場合のスナップ情報について説明します。

  Time        ProcessID Action            Type   requestID  QueueID  implID                         operation  host
  -----------------------------------------------------------------------------------------------------------------
  22:35:51.541      359 request send     client         6  -------  IDL:OM_ORB/admin:1.0       synch  hostABC
  22:35:51.551      202 request recv     manager        6        0  IDL:OM_ORB/admin:1.0       synch  ---
  22:35:51.581      202 reply send       manager        6        0  IDL:OM_ORB/admin:1.0       synch  ---
  22:35:51.581      359 reply recv       client         6  -------  IDL:OM_ORB/admin:1.0       ---    hostABC

  管理用コマンドの中には、OD_startサービスに対してリクエストを送るものがあります(例:OD_impl_inst)。OD_startサービスに送られたリクエストは、キューイングされずにOD_startサービスによって直接処理されます。“request recv”に対応するプロセス種別が“server”ではなく“manager”である場合、OD_startサービスがリクエストを処理していることを示します。その場合、リクエストがキューイングされないため、動作種別が“request queue-in”であるスナップ情報はありません。キューIDは“0”になっていますが、OD_startサービスによって直接処理されるリクエストに対応するキューIDは意味を持ちません。


1.5.3.4 スナップ情報採取状況の確認

  スナップ情報の採取状況を確認するには、odlistsnapコマンドを使用します。

  odlistsnapコマンドは、インプリメンテーションリポジトリIDごとのスナップ情報の採取状況を以下のように出力します。

  odlistsnapコマンドの実行例を以下に示します。

> odlistsnap
PID    ImplementationRepositoryID               status
1085   IDL:OM_ORB/admin:1.0                   non getting
1121   IDL:CosNaming/NamingContext:1.0        non getting