• 検索結果がありません。

運用

ドキュメント内 トラブルシューティング集 (ページ 39-44)

第1章 障害調査資料の採取

1.5 CORBAサービスのスナップショットの採取

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

---

ドキュメント内 トラブルシューティング集 (ページ 39-44)