WebOTX Manual V10.3 (第4版) 目次を表示

---

4. TPシステム

TPシステムに関する運用操作法について説明します。 WebOTX V6.3以降の統合運用管理ツールでは、WebOTX V5の運用管理ツールと比べてショートカットキーが一部以下のように変更されています。

4.1. 操作・状態確認(TPシステム)

4.1.1. 設定の変更

4.1.1.1. 統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりWebOTXシステム[TPシステム]を選択します。
3. リストビューより変更したい項目を選択し、変更します。

図7.1.1.1-1

4.1.1.2. コマンドから設定

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get tpsystem.*
   

3. 変更したい属性を変更します。属性の名前がわからない場合は、[ リファレンス > MBean > MBean定義 > 統合運用管理ツールの表示から検索 > TPシステム > WebOTXSystem ]を参照して確認してください。

   otxadmin> set tpsystem.serverName=host1
   

4.1.1.3. 注意事項

システムパラメータ、イベントジャーナル、ジャーナルに関する設定はTPシステムが停止している必要があります。

4.1.2. 設定値の説明

4.1.3. 起動・停止

4.1.3.1. 統合運用管理ツールから起動・停止

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりWebOTXシステム[TPシステム]を選択します。
3. 右クリックメニューより「システムの起動」あるいは「システムの停止」を実行します。

図7.1.1.3-1

4.1.3.2. コマンドから起動・停止

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 起動・停止を実行します。
   
   起動

   otxadmin> start-system
   

   停止

   otxadmin> stop-system
   

4.1.4. 状態

WebOTXシステム(TPシステム)の状態について説明します。

4.1.4.1. 注意事項

ドメイン起動中（TPモニタ・マネージャライフサイクル起動処理中）にTPシステムの状態チェックコマンドを実行すると、TPモニタ・マネージャライフサイクルの起動に失敗することがあります。 ドメインが起動状態になってから状態チェックを行ってください。

IIOPリスナの状態は、個別に起動停止することはできません。 TPシステムの起動停止に合わせて動作します。 状態に関しては、TPシステムの状態と同じです。 アライブチェックを行うために、TPモニタ・マネージャからIIOPリスナに対してセッションを1本張ります。 このアライブチェックに失敗した場合、起動停止処理失敗となります。

4.2. 操作・状態確認(アプリケーショングループ)

4.2.1. 作成・削除

4.2.1.1. 統合運用管理ツールから新規作成

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりTPシステム配下のアプリケーショングループを選択します。
3. 右クリックメニューより「アプリケーショングループの新規作成」を実行します。
4. 新規作成するアプリケーショングループ名を入力し、作成します。

図7.1.2.1-1

4.2.1.2. 統合運用管理ツールから削除

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりTPシステム配下のアプリケーショングループを選択します。
3. 右クリックメニューより「アプリケーショングループの削除」を実行します。
4. 削除するアプリケーショングループ名を選択し、削除します。

なお、直接該当アプリケーショングループ名のノードを選択して右クリックメニューより「アプリケーショングループの削除」を実行することもできます。

4.2.1.3. コマンドから新規作成・削除

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. アプリケーショングループ名を指定して新規作成・削除を実行します。
   
   新規作成

   otxadmin> create-apg apg
   

   削除

   otxadmin> delete-apg apg
   

4.2.1.4. 注意事項

アプリケーショングループ作成後にドメインのパスを変更することはできません。

4.2.2. 設定の変更

4.2.2.1. 統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を変更するアプリケーショングループを選択します。
3. リストビューより変更したい項目を選択し、変更します。

図7.1.2.2-1

4.2.2.2. コマンドから設定

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get tpsystem.applicationGroups.apg.*
   

3. 変更したい属性を変更します。属性の名前がわからない場合は、[ リファレンス > MBean > MBean定義 > 統合運用管理ツールの表示から検索 > TPシステム > WebOTXApplicationGroup ]を参照して確認してください。

   otxadmin> set tpsystem.applicationGroups.apg.applicationGroupAutoStart=true
   

4.2.2.3. 注意事項

アプリケーショングループの各プロパティについては、アプリケーショングループ起動中でも設定は可能ですが、設定内容を反映させるにはアプリケーショングループの再起動が必要です。

4.2.3. 設定値の説明

4.2.4. 起動・停止

4.2.4.1. 統合運用管理ツールから起動・停止

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより起動・停止するアプリケーショングループを選択します。
3. 右クリックメニューより「アプリケーショングループの起動」あるいは「アプリケーショングループの停止」を実行します。 強制停止を行う場合は「アプリケーショングループの強制停止」を実行します。

図7.1.2.4-1

4.2.4.2. コマンドから起動・停止

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 起動・停止を実行します。
   
   起動

   otxadmin> start-apg apg
   

   停止

   otxadmin> stop-apg apg
   

   強制停止

   otxadmin> stop-apg --force=true apg
   

4.2.4.3. 強制停止について

停止しようとしているプロセスグループがクライアントからのオペレーション実行中の場合、通常停止処理が失敗(タイムアウト)する場合があります。 通常停止を行なっても停止できない場合は強制停止を行なって停止させてください。 なお、強制停止を行なった場合実行中の処理は強制的に終了させますので、処理の保証は行なえません。 したがって強制停止は通常停止が行なえない場合に限り利用ください。

4.2.5. 状態

アプリケーショングループの状態について説明します。

4.3. 操作・状態確認(プロセスグループ)

4.3.1. 作成・削除

4.3.1.1. 統合運用管理ツールから新規作成

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりアプリケーショングループ配下のプロセスグループを選択します。
3. 右クリックメニューより「プロセスグループの新規作成」を実行します。
4. 新規作成するプロセスグループ名を入力し、作成します。

図7.1.3.1-1

4.3.1.2. 統合運用管理ツールから削除

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりアプリケーショングループ配下のプロセスグループを選択します。
3. 右クリックメニューより「プロセスグループの削除」を実行します。
4. 削除するプロセスグループ名を選択し、削除します。

なお、直接該当プロセスグループ名のノードを選択して右クリックメニューより「プロセスグループの削除」を実行することもできます。

4.3.1.3. コマンドから新規作成・削除

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. プロセスグループ名を指定して新規作成・削除を実行します。
   
   新規作成

   otxadmin> create-pg --apgroup apg pg
   

   削除

   otxadmin> delete-pg --apgroup apg pg
   

4.3.1.4. 注意事項

プロセスグループの作成、削除は、アプリケーショングループ起動中の場合は実行できません。 アプリケーショングループを停止して実行してください。

4.3.2. 設定の変更

4.3.2.1. 統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を変更するプロセスグループを選択します。
3. リストビューより変更したい項目を選択し、変更します。

図7.1.3.2-1

4.3.2.2. コマンドから設定

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get tpsystem.applicationGroups.apg.processGroups.pg.*
   

3. 変更したい属性を変更します。属性の名前がわからない場合は、[ リファレンス > MBean > MBean定義 > 統合運用管理ツールの表示から検索 > TPシステム > WebOTXJ2EEProcessGroup ]を参照して確認してください。

   otxadmin> set tpsystem.applicationGroups.apg.processGroups.pg.processCount=1
   

4. リストのように配列指定する場合は、{{変数1,値1},{変数2,値2},...}として指定します。

   otxadmin> set tpsystem.applicationGroups.apg.processGroups.pg.javaSystemPropertyList={{var1,value1},{var2,value2}}
   

4.3.2.3. 注意事項

プロセスグループの各プロパティについては、アプリケーショングループ起動中でも設定は可能ですが、設定内容を反映させるにはアプリケーショングループの再起動が必要です。

4.3.3. 設定値の説明

4.3.4. 起動・停止

4.3.4.1. 統合運用管理ツールから起動・停止

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより起動・停止するプロセスグループを選択します。
3. 右クリックメニューより「起動」あるいは「停止」を実行します。 強制停止を行う場合は「プロセスグループの強制停止」を実行します。

図7.1.3.4-1

4.3.4.2. コマンドから起動・停止

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 起動・停止を実行します。
   
   起動

   otxadmin> start-pg --apgroup apg pg
   

   停止

   otxadmin> stop-pg --apgroup apg pg
   

   強制停止

   otxadmin> stop-pg --apgroup apg --force=true pg
   

4.3.4.3. 強制停止について

停止しようとしているプロセスグループがクライアントからのオペレーションが実行中の場合、通常停止処理が失敗(タイムアウト)する場合があります。 通常停止を行なっても停止できない場合は強制停止を行なって停止させてください。 なお、強制停止を行なった場合実行中の処理は強制的終了させますので、処理の保証は行なえません。 したがって強制停止は通常停止が行なえない場合に限り利用ください。

4.3.5. 状態

プロセスグループの状態について説明します。

4.4. 操作・状態確認(モジュール)

4.4.1. 設定の確認

4.4.1.1. 統合運用管理ツールから設定確認

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を確認するモジュールを選択します。
3. リストビューより確認したい項目を確認します。

図7.1.4.1-1

4.4.1.2. コマンドから設定確認

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get applications.j2ee-applications.CartApp.CartApp\\.ear.*
   

4.4.2. 設定値の説明

4.4.3. 活性化・閉塞

4.4.3.1. 統合運用管理ツールから活性化・閉塞

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより活性化・閉塞するモジュールを選択します。
3. 右クリックメニューより「活性化」あるいは「閉塞」を実行します。

図7.1.4.3-1

4.4.3.2. コマンドから活性化・閉塞

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 活性化・閉塞を実行します。
   
   活性化

   otxadmin> invoke applications.j2ee-applications.CartApp.CartApp\\.ear.enable
   

   閉塞

   otxadmin> invoke applications.j2ee-applications.CartApp.CartApp\\.ear.disable
   

4.4.4. 状態

モジュールの状態について説明します。

4.5. 操作・状態確認(インタフェース)

4.5.1. 設定の変更

4.5.1.1. 統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を変更するオブジェクトを選択します。
3. リストビューより変更したい項目選択し、変更します。

図7.1.5.1-1

4.5.1.2. コマンドから設定確認

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get applications.j2ee-applications.CartApp.CartApp\\.ear.CartEJB.cart\\.CartHome.*
   

3. 変更したい属性を変更します。属性の名前がわからない場合は、[ リファレンス > MBean > MBean定義 > 統合運用管理ツールの表示から検索 > TPシステム > WebOTXMessageDrivenBeanClass, WebOTXEntityBeanHome, WebOTXEntityBeanRemote, WebOTXSingletonSessionBeanHome, WebOTXSingletonSessionBeanRemote, WebOTXStatefulSessionBeanHome, WebOTXStatefulSessionBeanRemote, WebOTXStatelessSessionBeanHome, WebOTXStatelessSessionBeanRemote, WebOTXWebContext ]を参照して確認してください。

   otxadmin> set applications.j2ee-applications.CartApp.CartApp\\.ear.CartEJB.cart\\.CartHome.connectCtrlPolicy=1
   

4.5.2. 設定値の説明

4.6. 操作・状態確認(オペレーション)

4.6.1. 設定の変更

4.6.1.1. 統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を変更するオペレーションを選択します。
3. リストビューより変更したい項目選択し、変更します。

図7.1.6.1-1

4.6.1.2. コマンドから設定確認

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get applications.j2ee-applications.CartApp.CartApp\\.ear.CartEJB.cart\\.CartHome.create().*
   

3. 変更したい属性を変更します。属性の名前がわからない場合は、[ リファレンス > MBean > MBean定義 > 統合運用管理ツールの表示から検索 > TPシステム > WebOTXMessageDrivenBeanOperation, WebOTXEntityBeanHomeOperation, WebOTXEntityBeanRemoteOperation, WebOTXSingletonSessionBeanHomeOperation, WebOTXSingletonSessionBeanRemoteOperation, WebOTXStatefulSessionBeanHomeOperation, WebOTXStatefulSessionBeanRemoteOperation, WebOTXStatelessSessionBeanHomeOperation, WebOTXStatelessSessionBeanRemoteOperation, WebOTXWebMethod ]を参照して確認してください。

   otxadmin> set applications.j2ee-applications.CartApp.CartApp\\.ear.CartEJB.cart\\.CartHome.create().exetimeMax=-1
   

4.6.2. 設定値の説明

4.6.3. 起動・停止

4.6.3.1. 統合運用管理ツールから起動・停止

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより活性化するオペレーションを選択します。
3. 右クリックメニューより「起動」あるいは「停止」を実行します。

図7.1.6.3-1

4.6.3.2. コマンドから設定確認

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 起動・停止を実行します。
   
   起動

   otxadmin> invoke applications.j2ee-applications.CartApp.CartApp\\.ear.CartEJB.cart\\.CartHome.create().start
   

   停止

   otxadmin> invoke applications.j2ee-applications.CartApp.CartApp\\.ear.CartEJB.cart\\.CartHome.create().stop
   

4.6.4. 状態

オペレーションの状態について説明します。

4.7. 設定詳細

4.7.1. クライアント制御

接続しているクライアント制御の設定について以下に示します。

4.7.1.1. クライアント情報の表示

統合運用管理ツールで[クライアントセッション]を選択することにより現在接続しているクライアントに関する情報を表示します。 ただし thinクライアントから利用している場合は、実際にTPシステムにアクセスを行っているのはWebコンテナであるため、Webコンテナの情報が表示され、実際のブラウザの情報は表示されません。

V6.5より、IIOPリスナのアライブチェックを行うため、TPモニタ・マネージャよりIIOPリスナに対してセッションを1本張っています。 このときのIPアドレスは127.0.0.1です（127.0.0.1であるセッションすべてがアライブチェック用のセッションとは限りません）。 このセッションは切断しないように注意してください。 切断した場合、IIOPリスナが起動停止失敗(failed)状態になります。 ただし、つぎのアライブチェック時にセッションを張りなおします。

4.7.1.2. クライアントの強制切断

接続しているクライアントを統合運用管理ツール上で切断することができます。

1. 統合運用管理ツールで[クライアントセッション]を選択します。
2. [操作]-[クライアント切断]メニューを実行します。
3. 切断したいクライアントを設定し、切断を実行します。

4.7.1.3. クライアント無通信監視

接続しているクライアントより、一定時間が経過してもオペレーション呼び出しがない場合、強制的にクライアントからの接続を切断させることができます。

1. 統合運用管理ツールで[IIOPリスナ]を選択します。
2. [クライアント制御]を選択し、[クライアントとの無通信監視を行う]をチェックします。
3. [クライアントとの無通信監視間隔]に監視時間を秒単位(60〜2147483)で指定します。
4. 設定を反映させるためにTPシステムを再起動します。

4.7.1.4. 接続クライアント情報のホスト名表示

統合運用管理ツールの[クライアントセッション]では接続しているクライアントのホスト名の表示を行っています。 ただ、クライアントのIPアドレスからホスト名への変換ができない場合に、ホスト名変換ができずにWebOTX全体のレスポンスを悪化させてしまいます。 そのような環境の場合は接続クライアント情報のホスト名表示を行わない指定をする必要があります。

1. 統合運用管理ツールで[クライアントセッション]を選択します。
2. [クライアント制御]を選択し、[クライアント情報表示時にホスト名の逆引き処理を行う]からチェックを外します。

4.7.1.5. TCPレベルでのアライブチェック

クライアント及び回線の有効性を確認するため、OSの機能を使用してアライブチェックを行うことができます。 アライブチェックで応答がないクライアントは強制的に切断されます。 WebOTXの機能を使ったCORBAのクライアントアプリケーションのアライブチェックと違って本機能は全てのクライアントに有効です。 但し、アライブチェック間隔はOS側の設定となります。 OS側の設定については [ 構築・運用 > チューニング > 通信 > TCP/IPに関する設定 ] を参照してください。

TPシステムに関しては以下の手順で設定してください。

1. 統合運用管理ツールで[TPシステム]を選択します。
2. [クライアント制御]を選択し、[TCPレイヤーのアライブチェックを行う]をチェックします。
3. 設定を反映させるためにTPシステムを再起動します。

4.7.2. 名前サーバへの登録

4.7.2.1. 名前サーバへの登録

CORBAコンポーネントでは名前サーバへのInteroperable Object Reference(IOR)登録URLをcorbaname形式で任意に指定することができます。EJBコンポーネントの場合URLはcorbaname://*となります。

また、その登録を永続化するか一時的に扱うかを選択し、どのタイミングで名前サーバに登録するかを選択することができます。 名前サーバへのIOR登録方法は名前サーバへの負荷を軽減するため"永続的に扱う"が既定値です。 つまり、プロセス起動時に自動で登録されないため、運用管理ツールから手動で登録を行う必要があります。 プロセス起動時に自動で登録する場合は運用管理ツールから名前サーバの登録で"一時的に扱う"設定にしてください。 システムの名前サーバの登録でも"一時的に扱う"設定にすることができます。

1. 統合運用管理ツールを起動し、ドメインと接続します。
2. インタフェースの[オブジェクトリファレンスのポリシ]を選択し[名前サーバへの登録名]を選択します。 [任意に設定する」を選択した場合、名前サーバへの登録URL等の設定が可能になります。 [登録は行わない]を選択した場合は、名前サーバへの登録は行いません。
3. [任意に設定する]を選択した場合、[登録するURL]に登録用URLをcorbaname形式で任意に指定します。 既定値はV4.2までの登録URLです。 IDLファイルのモジュール名、インタフェース名から構築されます。
   旧バージョンでCORBAコンポーネントを登録した場合は名前サーバのルートに直接登録されるURLも既定値として存在します。
4. [オブジェクトリファレンスのポリシ]にて永続的に扱うか一時的に扱うかを選択してください。 永続的に扱う場合、任意のタイミングで登録できます。 また、プロセスが停止してもその情報は登録されたままになります。 プロセス起動時の名前サーバアクセス負荷を軽減することができます。
   一時的に扱う場合、プロセス起動時にWebOTX内部で登録を行います。 プロセス停止時に削除されます。 ユーザが明示的に名前サーバへの登録を行う必要はありません。
   [システムの設定を参照する]にチェックを入れている場合はTPシステムの[オブジェクトリファレンスのポリシ]で設定されている値が引き継がれます。
5. 複数サーバに関する設定を行う場合、[マルチサーバのシステムグループ名]を設定してください。 名前サーバへの登録時、システムグループに設定されている全TPシステムの情報を登録します。
   [マルチサーバのシステムグループ名]はツリービューから[マルチサーバ]を選択して設定することができます。
   詳細は [ マルチサーバラウンドロビン負荷分散運用 ] をご覧ください。
6. ラウンドロビン機能を利用する場合は、[オブジェクトリファレンスのラウンドロビンを行う]にチェックを入れてください。 同一のサーバアプリケーションが登録されたTPシステム間で負荷分散を行います。(既定値:行う)

4.7.2.2. 名前サーバに登録したオブジェクトリファレンスの確認

サーバアプリケーションのオブジェクトは、WebOTXが名前サーバに登録するほかに、ユーザが任意に登録することができます。 その登録内容をWindows版のOrbManagerを使用して確認することができます。 以下にその確認方法について示します。

1. WebOTXインストールディレクトリにObject Brokerがインストールされます。 そのbinディレクトリ配下にあるorbmanag.exeを起動します。
2. 該当名前サーバに登録されているオブジェクト一覧が確認できます。 設定したcorbaname形式の“/”を区切りとしたツリーとして表示されます。

なお、orbmanag.exeは指定したホストで名前サーバが起動していないとエラーになります。 かならず名前サーバが起動しているホスト名を指定して下さい。

orbmanag.exe起動中にオブジェクトが登録された時、ツリービューが構築されない時はツリーを一度閉じてください。

4.7.2.3. インタフェース削除後のIOR削除

IORを永続的に扱う設定をしている場合、IORの削除をしないうちにコンポーネント削除や置換によるインタフェース名の変更・削除があると、登録されたIORは無効となります。 運用管理ツールからは情報が消えるため削除できなくなりますのでコンポーネント削除やインタフェース名変更前に名前サーバからIORを削除してください。 IORを一時的に扱う設定にしている場合はプロセス停止時にWebOTXが削除します。

IOR削除前にインタフェース名を変更・削除してしまった場合は、実行環境のIOR削除コマンドwoiorunbindで手動削除してください。 この時指定するURLは、名前サーバホスト名の省略はできません。

コマンドは以下の位置にインストールされています。

• ${AS_INSTALL}/Trnsv/command/woiorunbind

URLを指定できずコマンドも使用できないという場合はOrbManagerを起動し、手動で削除してください。 起動の方法に関しては名前サービスに登録したオブジェクトリファレンスの確認を参照してください。

ただし、このツールで表示されるURLはユーザが手動登録したIOR以外も含まれます。 WebOTXが自動登録したIORやWebOTX製品自身が動作するのに必要なIORを削除した場合、動作が不定になります。 IOR削除は極力運用管理ツールでインタフェース変更・削除前に行うかIOR削除コマンドで行ってください。どうしてもOrbManagerを使用しなければならない場合は誤って他のIORを削除することのないよう取り扱いには十分注意してください。

1. URLを登録したホストにアクセスし、左側の"Root Context"をダブルクリックしてください。
   ホスト名の変更はメニューの[参照先]-[ホスト名指定]で行うことができます。
2. 登録したURLがツリー構造になっていますので、該当URLを探してください。
   最後まで探してクリックすると右側に"Object Name"が表示されます。
3. 削除する名前を選択し、メニューの[オブジェクト]-[アンバインド]を実行してください。

4.7.3. マルチサーバラウンドロビン負荷分散運用

マルチサーバラウンドロビン負荷分散はEJBのホームインタフェース、ステートレスセッションBeanのリモートインタフェース、CORBAアプリケーションのオブジェクトリファレンスに複数の接続先の情報を含める(IOR 多重化)ことにより、クライアントからのオペレーション呼び出し毎にラウンドロビン方式で接続先を決定することにより、複数ドメイン間の負荷分散運用を行うことができます。

オブジェクトのIORにマルチサーバの定義を行うためのサーバ、クライアントの設定について説明します。

4.7.3.1. サーバ実行環境の設定

サーバ実行環境においては、統合運用管理ツールを使って以下の設定を行います。 全てのサーバで同一の設定を行ってください。

1. [オブジェクトリファレンスのポリシ]の設定
   TPシステムのプロパティで[オブジェクトリファレンスのポリシ]を[永続的に扱う]に設定します。
2. 複数サーバの設定
   [マルチサーバ]を選択し、[操作]-[システムグループの設定]でシステムグループを作成します。 配下にシステムグループが作成されるので、[操作]-[サーバセットの設定]を実行して自システムを含め負荷分散を行うTPシステム全てを登録します。 いくつかの負荷分散パターンがある場合は複数のシステムグループを作成してください。
3. インタフェースの設定
   インタフェースの属性で負荷分散を行う全てのインタフェースについて、[オブジェクトリファレンスのポリシ]を[永続的に扱う]に設定し、[マルチサーバのシステムグループ名]に[マルチサーバ]で作成したシステムグループ名を指定します。
4. IORの登録
   インタフェースを選択して、[操作]-[名前サーバへ登録]を実行し、IORを名前サーバに登録します。 この作業は全てのシステムで実行してください。 登録を行うときに、各TPシステムに対してポート番号やSSLの設定などの情報取得を行いますので、全てのサーバのWebOTXシステムを起動させた状態で実行してください。

4.7.3.2. クライアント実行環境の設定

マルチサーバ負荷分散を行うためのクライアント実行環境の設定について説明します。

4.7.3.3. Java

クライアントの実行環境においては、システムプロパティまたはAPIで以下の設定を行います。

1. システムプロパティで設定する場合
   UseMultiConnection=true,UseConnectionRoundRobin=true に設定されているかをご確認下さい。既定値はtrueです。
   設定方法に関する詳細は[ リファレンス > 設定 > CORBA通信基盤(Object Broker) > Object Broker JavaにおけるORBのプロパティ定義 ]をご覧ください。
2. APIで設定する場合
   setUseMultiConnection及びsetUseConnectionRoundRobinの設定を行ってください。
   設定に関する詳細は[ リファレンス > API > jp.co.nec.orb.Config ] をご覧ください。

4.7.3.4. 注意事項

ステートレスセッションBeanをステートレスで動作させる場合、クライアントでオペレーション呼び出し毎、もしくは頻繁にEJBホームインターフェースのcreate() を呼び出だすと負荷が偏るのでご注意下さい。これはcreate() で取得したリファレンスに対する呼び出しは複数の接続先の中から同じ順番で振り分けられるためです。

4.7.4. プロセスグループの設定の動的変更

動的変更の設定について以下に示します。

4.7.4.1. 動的変更方法

• 運用管理ツールより設定する場合
  動的設定変更に対応している項目を変更し、更新する。
  [TPシステム]-[アプリケーショングループ名]-[プロセスグループ名]を右クリックし、表示されたメニューより[動的に設定値を変更する]を選択します。
• 運用管理コマンドより設定する場合
  動的設定変更に対応している項目のMOの属性を変更後、以下のコマンドで実行することができます。
  (各設定に対応するMOの属性名は、 [ リファレンス > MBean一覧 > MBean定義 ] を参照してください。)

  otxadmin> invoke tpsystem.aplicationGroups.<アプリケーショングループ名>.proecssGroups.<プロセスグループ名>.dynamicUpdateProperty

図7.1.7.10-1

以下の動作の場合は、再起動回数による起動リトライは行われず、旧設定のプロセスで動作継続します。

• 新設定のプロセス起動時にOutOfMemoryError等により、起動が失敗した場合
• 初期化完了通知のタイムアウトが発生した場合

旧設定のプロセスの終了でタイムアウトが発生した場合、タイムアウトの旨をプロセスIDとともにsyslog(またはイベントログ)に出力しますが、 再起動処理自体は正常終了となり、業務は新プロセスで継続します。

動的設定変更に対応している項目は以下となります。

• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[トレース設定]
  • トレースファイルに標準出力も出力する
  • トレースファイルに標準エラー出力も出力する
• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[JavaVMオプション]
  • 最大ヒープサイズ
  • 最大ヒープサイズの単位
  • 初期ヒープサイズ
  • 初期ヒープサイズの単位
  • スタックトレース採取時にJavaヒープの情報を採取する
  • Javaヒープの情報採取時に何位の情報まで出力するか
  • その他の引数
  • プロセスごとに指定する
  • プロセスごとの引数
• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[Javaシステムプロパティ]
  • Javaシステムプロパティ

4.7.4.2. 動的設定変更に関する設定及び状態

動的設定変更に関する以下の設定及び状態が追加になります。

• 動的設定変更時初期化待ち時間
  TPモニタがAPの初期化完了通知を待ち合わせる時間。(既定値:600sec)
• 動的設定変更時終了待ち時間
  TPモニタからの終了要求の完了待ち時間。(既定値:600sec)
  プロセスがストールしている場合、正常終了できないため、再起動処理が継続できなくなることを防止します。
• 動的設定変更状態
  動的設定変更の状態を示します。以下の状態があります。
  • 反映中 : 動的設定変更を反映のため、プロセスグループを再起動しています。
  • 反映失敗 : 動的設定変更に失敗しました。プロセスグループは変更反映前の状態で起動しています。
  • 変更無し : 変更を行っていません。

上記設定は、運用管理ツールの以下の箇所で設定・参照することができます。

• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[プロセス制御]
  • 動的設定変更時初期化待ち時間
  • 動的設定変更時終了待ち時間
• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[状態]
  • 動的設定変更状態

MOの属性名は以下となります。

• 動的設定変更時初期化待ち時間
  tpsystem.aplicationGroups.<アプリケーショングループ名>.proecssGroups.<プロセスグループ名>.dynamicUpdateInitWaitTime
• 動的設定変更時終了待ち時間
  tpsystem.aplicationGroups.<アプリケーショングループ名>.proecssGroups.<プロセスグループ名>.dynamicUpdateInitStopTime
• 動的設定変更状態
  tpsystem.aplicationGroups.<アプリケーショングループ名>.proecssGroups.<プロセスグループ名>.updateStatus

4.7.4.3. ログ出力

動的設定変更で出力するTPSメッセージは、 [ リファレンス > メッセージ一覧 > TPSから始まるメッセージ > TPS15:tpmMainが出力するメッセージ ] を参照してください。

4.7.5. 予備スレッドの事前生成と活性化

予備スレッドの事前生成と活性化の設定を以下に示します。
予備スレッドはプロセス起動時には閉塞状態となっており、オペレーションの実行を行うことができません。
予備スレッドの閉塞・閉塞解除は、[TPシステム]-[アプリケーショングループ名]-[プロセスグループ名]を右クリックし、表示されたメニューより[動的多重度変更]の"スレッドの多重度"を設定することにより閉塞解除できます。このとき、"プロセス多重度"の設定は必須です。
スレッドの多重度は "スレッド数"+"予備スレッド数"の範囲で設定してください。

図7.1.7.11-1

図7.1.7.11-2

予備スレッド数は運用管理ツールから設定する場合、

• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[スレッド制御]
  • 予備スレッド数(既定値:0)

で設定することができます。
また、運用管理コマンドからは以下のMOの属性に設定します。

• tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.reserveThreads

4.7.6. アプリケーショングループ停止処理時間の短縮

プロセスグループの強制停止処理に即時強制停止する設定を以下に示します。
運用管理ツール上の設定項目は以下の通りとなります。

• [TPシステム]-[起動／停止]
  • プロセス停止時の終了処理を行う

上記に対応するMOの属性は、

• tpsystem.immediateStopProcess

となります。

4.7.7. IIOPリスナ

RMI-IIOPのリクエストを処理するリスナです。統合運用管理ツールで設定できる項目は次の通りです。

SSL通信を行うための設定手順は次の通りです。

1. TPシステムを停止します。
2. [SSL]-[SSLを使用する]にチェックを入れます。
3. クライアント認証を行わない場合、[SSL]-[クライアント認証なしのSSLを利用する]にチェックを入れ、ポート番号を指定します。クライアント認証を行う場合、[SSL]-[クライアント認証ありのSSLを利用する]にチェックを入れ、ポート番号を指定します。必ずどちらかのポート番号を指定する必要があります。
4. OpenSSLを使用する場合、[SSLOpenSSL]-[秘密鍵ファイル名], [証明書ファイル名], [信頼するCAの証明書ファイル名]を全て指定します。フルパス指定不可ですのでファイル名のみ指定してください。セキュリティパックを使用する場合、[SSLSecureWare]-[鍵識別子]を指定します。
5. 設定完了後、更新ボタンを押します。
6. ${INSTANCE_ROOT}\config\tpsystem 配下に秘密鍵ファイル、証明書ファイル、信頼するCAの証明書ファイルを置きます。
7. オブジェクトリファレンスのポリシが「永続的に扱う」設定である場合、名前サーバにIORを登録します。
8. TPシステムを起動します。

4.7.8. AJPリスナ

AJPのリクエストを処理するリスナです。統合運用管理ツールで設定できる項目は次の通りです。

4.8. 統計情報(統合運用管理ツールでの表示)

統合運用管理ツールから確認できるスレッド情報、CPU情報、キュー情報、接続クライアント情報に関して説明します。

4.8.1. スレッド情報

起動しているプロセスグループのスレッド情報を見ることができます。

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりプロセスグループを選択します。
3. リストビューより動作情報を選択します。

4.8.2. プロセス情報

起動しているプロセスグループのプロセス情報を見ることができます。

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりプロセスグループを選択します。
3. リストビューより動作情報を選択します。

4.8.3. キュー情報

起動しているTPシステム全体のキュー情報を見ることができます。

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより[キュー]を選択します。
3. リストビューよりキュー情報を選択します。

4.8.4. クライアントセッション情報

TPシステムと接続しているクライアント情報を見ることができます。

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより[クライアントセッション]を選択します。
3. リストビューよりクライアント情報を選択します。

4.9. 統計情報(ジャーナル)

ジャーナルはWebOTXの稼働状況を評価するための性能及び統計情報を各種レポートとして提供します。 レポートの種類は以下の通りです。

• アクティビティレポート（レポートNo.01）
  指定された時間間隔におけるWebOTX全体の動作状況を表示します。 表示項目はCPU使用量(秒)、CPU使用率(%)、トランザクション数(件数、%)、スループット、レスポンス時間※(最大、最小、合計)、キュー滞留数(最大、最小、平均)です。
  
  
• トランザクションサマリレポート（レポートNo.02/03）
  アプリケーショングループ、プロセスグループ単位に発生したトランザクション処理状況を表示します。 表示項目はCPU時間の合計(秒、使用率)、トランザクション件数の合計(件数、%)、レスポンス時間※(最大、最小、合計)、キュー滞留数(最大、最小、平均)です。
  
  
• CPU時間タイムチャート（レポートNo.05/06/07）
  全体、アプリケーショングループ、プロセスグループ単位に、一定時間間隔におけるトランザクション処理とCPU時間の推移を表示します。 表示項目は単位時間あたりのCPU時間の合計とそのグラフ化です。
  
  
• トランザクション件数タイムチャート（レポートNo.09/10/11）
  全体、アプリケーショングループ、プロセスグループ単位に、一定時間間隔におけるトランザクション処理数の推移を表示します。 表示項目は単位時間あたりのトランザクション件数の合計とそのグラフ化です。
  
  
• トランザクション件数レスポンス時間グラフ（レポートNo.13/14/15）
  全体、アプリケーショングループ、プロセスグループ単位に、一定レスポンス時間内で処理されたトランザクションの数の一覧表示です。 表示項目はトランザクション件数とそのグラフ化です。
  ※レスポンス時間に対する補足事項
  本ジャーナルにおけるレスポンス時間とは、サーバAPにおいてユーザの実装を呼び出してからその結果が返るまでの時間を測定したものです。 通信リスナとの間のキューに滞留している時間は含まないことに注意して下さい。 なお、統合運用管理ツールにおいてオペレーションの情報として表示される最小/最大/平均レスポンス時間は、通信リスナとの間のキューに滞留している時間を含んでいます。

ジャーナル採取の手順は以下のようになります。

0. 準備
   下記で説明する各コマンドは${AS_INSTALL}/Trnsv/commandにあります。 UNIX版のWebOTXをご使用で、且つ、WebOTX運用ユーザを設定している場合は、WebOTX運用ユーザでコマンドを実行して下さい。
   
   
1. ジャーナル採取の設定
   ジャーナルの採取は統合運用管理ツールで指定できます。 なお、ここで指定するファイルサイズは以下を目安として下さい。

   SIZE(MB) = 0.084nt + 0.028mt + 0.009gt
   

   • n：サーバアプリケーションのプロセス数
   • m：サーバアプリケーションのオペレーション数
   • g：起動しているプロセスグループ数
   • t：採取時間(単位:時間)
   
   
2. ジャーナル採取
   WebOTXを再起動するとジャーナルの採取を始めます。 ジャーナル情報を格納したファイル（ジャーナルファイル）はカタログディレクトリ下のjnlディレクトリにjnl000x.logという名前で作られます(xは1〜3)。 ファイルはサイクリックに使用されます。 次のファイルに移る契機は指定された容量に達した時、もしくは、WebOTXを再起動した時です。
   
   
3. ジャーナルの状態表示
   現在のジャーナルの採取状況はjnldispコマンドで確認できます。 コマンドの書式は以下の通りです。

   jnldisp [-C journaldir]
     ・-C：jnlディレクトリを指定します。 省略時はカレントディレクトリとなります
   

   
   出力例を以下に示します。

   ********** Control File Infomation **********
     Status      : Active
     Groupnum    : 1
     Filenum     : 3
     Filesize    : 10
   ****** Group 0 Journal File Infomation *****
   
    ***** Current Journal File *****
     number       : 2
     PathName     : C:\WebOTX\domains\domain1\config\tpsystem\jnl\jnl0002.log
     record count : 1
     Save Flag    : 0 : (Not Save)
     FirstDate    : 2017.09.30    FirstTime    : 10:10:36
     LastDate     : 2017.09.30    LastTime     : 10:10:36
   
     number       : 1
     PathName     : C:\WebOTX\domains\domain1\config\tpsystem\jnl\jnl0001.log
     record count : 67
     Save Flag    : 0 : (Not Save)
     FirstDate    : 2017.09.29    FirstTime    : 15:37:16
     LastDate     : 2017.09.29    LastTime     : 21:02:16
   
     number       : 3
     PathName     : C:\WebOTX\domains\domain1\config\tpsystem\jnl\jnl0003.log
     record count : 99
     Save Flag    : 1 : (Saved)
     FirstDate    : 2017.09.29    FirstTime    : 15:22:16
     LastDate     : 2017.09.29    LastTime     : 15:34:51
   
   

   Filenum：ファイル数
   FileSize：ファイルサイズ（単位Ｍbyte）
   

   *** Current Journal File ***
   

   ジャーナルファイルが新しい順に表示されます。 最初に表示されるジャーナルファイルをカレントジャーナルファイルと言います（例ではjnl0002.logのファイル）。
   
   
4. ジャーナルファイルの退避
   ジャーナルファイルはそのままではサイクリックに使用されてしまうため、定期的に退避する必要があります。 退避は単にコピーコマンドを使用するかもしくはjnlsaveコマンドを使用します。 コマンドは${AS_INSTALL}/Trnsv/commandにあります。 jnlsaveコマンドを使うと複数のジャーナルファイルを１つにまとめることができます。 また、使用中のカレントジャーナルファイル（ジャーナルが動作中の時のカレントジャーナルファイル）は、jnlsaveコマンドで一旦退避しないと編集できません。
   ジャーナル退避のコマンドの書式は以下の通りです。

   jnlsave -n domainName [-C journaldir] [-d savefilename] [file_num]
   
     ・-n：WebOTXが起動中の場合はドメイン名（例：domain1）を指定します。
     
     ・-C：jnlディレクトリを指定します。 省略時はカレントディレクトリとなります。
     
     ・-d：退避するファイル名を指定します。 省略時はjnlsv.logとなります。
     
     ・file_num：無指定（1〜3の全てのジャーナルファイルが対象）を推奨します。
       特定のジャーナルファイルだけを編集する必要がある場合は番号を指定します（1〜3）。
       複数のファイルを指定する場合、番号は1つ以上のスペースで区切り、時刻の古いファイル順に指定する必要があります。
       時刻はjnldispコマンドで確認してください。
   

   
   
5. ジャーナルファイルの編集
   各種レポートを編集するために、ジャーナル編集コマンド(wojnledt)を実行します。 コマンドは${AS_INSTALL}/Trnsv/commandにあります。 ジャーナル編集コマンドの書式は以下の通りです。

   wojnledt [-I InputFile] [-a ApplicationGroup] [-p ProcessGroup] [-t OutputType] [-x SuppressionType] [-l TimeLength] [-r ResponseTime] [-L LinesPerPage] [-O Output] [-D TargetTime]
   
     ・-I：入力ファイルのパス名を255文字以内で指定します。 省略時はカレントディレクトリのjnlsv.logとなります。
       ジャーナルファイルとその退避ファイルを入力ファイルとして指定できますが、使用中のカレントジャーナルファイルは指定できません。
       
     ・-a：編集対象とするアプリケーショングループ名を指定します。
       最大は32文字までで","（カンマ）をデリミタとして複数指定が可能です。
       省略時は全アプリケーショングループが編集対象となります。
       
     ・-p：編集対象とするプロセスグループ名を指定します。 最大は32文字までで","（カンマ）をデリミタとして複数指定が可能です。
       省略時は全プロセスグループが編集対象となります。
   
     ・-t：編集出力するレポートの種別を数値（01〜15）で指定します。
       ","（カンマ）をデリミタとした複数指定や、"_"（アンダーバー）でつないだ範囲指定が可能です。 -xとの同時指定はできません。
       省略時は全レポートを出力します。
   
   
         指定例：
         01,02,03
         05_10
         _05 (01から05まで）
         11_（11から15まで）
   
     ・-x：編集出力を抑止するレポートの種別を数値（01〜15）で指定します。 指定方法は-tと同じです。
       また-tとの同時指定はできません。
   
     ・-l：時系列レポートの時間間隔（単位：分、1から999まで）を指定します。 省略時は30分間隔となります。
     
     ・-r：トランザクション件数レスポンス時間グラフにおける、レスポンス時間間隔（単位：秒）、編集開始レスポンス時間（単位：秒）、レスポンス時間間隔数をそれぞれss.ss1,ss.ss2,limit_cntとして指定します。
       指定可能な範囲はss.ss1が0.01〜100.00まで、ss.ss2が0.00から100.00まで、limit_cntは1〜99983です。
       省略時はss.ss1は0.01秒、ss.ss2は0.00秒、limit_cntは1ページに収まる行数となります。
   
     ・-L：レポートの1ページあたりの行数を指定します。 指定可能な範囲は30〜100000です。
       省略された場合は60行となります。
   
     ・-O：レポートの出力先ファイル名を指定します。 省略時は標準出力に出力します。
     
     ・-D：編集対象日時をdate1/time1_date2/time2で指定します。
       date1（開始日）、date2（終了日）はyyyy.mm.ddの形式で指定します。
       time1（開始時）、time2（終了時）はhh:mmの形式で指定します。 省略時は全レコードを編集します。
   

ジャーナルのファイル数またはファイルサイズの変更手順は次の通りです。

1. TPシステムを停止します。
2. ファイル数を変更する場合、${INSTANCE_ROOT}/config/tpsystem/jnlwrt.ped ファイルを開き、-F オプションの引数を書き換えます。既定値は3で、2 から 100 の範囲で指定可能です。
3. ファイルサイズを変更する場合、統合運用管理ツールでTPシステムをクリックし、右ページの[ジャーナルの設定]タブの[ファイルサイズ]で設定します。
4. ${INSTANCE_ROOT}/config/tpsystem/jnl/journal.ctl ファイルを削除します。削除すると、それまで採取していたジャーナル情報は削除されます。設定変更前のジャーナルが必要な場合、事前にジャーナルを採取してください。
5. TPシステムを起動します。

4.10. 統計情報(オペレーションジャーナル)

オペレーションジャーナルは、システムの稼働状況・統計をオペレーション単位でレポート出力します。 オペレーションごとの実行時間情報（平均値・最大値・最小値）、オペレーションの実行回数、プロセスグループごとの稼動スレッド数(起動中のスレッドのうち実際にオペレーションを実行しているスレッド数)を知ることができます。 それぞれの情報について、全体の統計と単位時間ごとの推移がレポート出力されます。

V6.3からはこれに加えて、オペレーションのCPU使用時間（ユーザモード、カーネルモード）の平均・最大・最小、プロセスグループのCPU使用率・CPU使用時間(ユーザモード、カーネルモード)をレポート出力します。

またオペレーション情報のサマリに「実行時間の上限の推奨値」が追加されました。 実行時間の上限を設定する際の参考にしてください。

ジャーナルに蓄積された各オペレーションの実行時間データは、CVS形式のファイルで出力されます。 データはデータ種別（平均時間、最大時間、最小時間、呼び出し回数、最大同時稼動スレッド数、平均同時稼動スレッド数）ごとに編集可能です。 編集時刻、情報採取時間帯や、全体の情報がファイルの先頭に表示されます。 一度も実行されていないオペレーションについては表示されません。

コマンドは${AS_INSTALL}/Trnsv/commandにあります。 UNIX版のWebOTXで、且つWebOTX運用ユーザを設定している場合は、WebOTX運用ユーザでコマンドを実行して下さい。

4.10.1. オペレーションジャーナル編集コマンド

オペレーションジャーナル編集コマンドの使用方法は以下のとおりです。

woopjnledt  [-I InputFile] [-O Output] [-type EditType] [-intvl TimeLength] [-time TargetTime] [-line LinesPerPage] [-ag ApplicationGroup][-pg ProcessGroup] [-cmp Component] [-rep RepositoryID] [-op Operation] [-txid TXID] [-txn TxIDNumber]  [-c CatalogDir]

  使用例：
  
  1.まずジャーナルを待避します。
jnlsave -n domain1 -C ${INSTANCE_ROOT}\config\tpsystem\jnl -d jnlsv.log

  2.待避したジャーナルをオペレーションジャーナル編集コマンドにより編集します。
woopjnledt -I jnlsv.log -c ${INSTANCE_ROOT}\config\tpsystem -O domain1jnl.csv


  以下のオプションは必ず指定するようにしてください。
    ・-c
      カタログディレクトリ(${INSTANCE_ROOT}/config/tpsystem)を絶対パスで指定します。
      省略時はプロセスグループ名、オペレーション名、起動時設定スレッド数、スレッド使用率などの一部情報が出力されなくなります。
      スレッド数などの設定の変更を行っていない場合はカタログディレクトリを指定することを推奨します。

  以下のオプションで編集間隔を指定することができます。
    ・-intvl
      時系列レポートの時間間隔（単位：分、1から999まで）を指定します。 省略時は30分となります。
     「TPシステム」-「稼働情報の採取と設定更新の間隔」で設定された時間間隔より短い値を設定すると、編集結果が不正確になるのでご注意ください。
     
  ファイル入出力に関するオプションには以下があります。
    ・-I
      入力ファイルのパス名を255文字以内で指定します。
      省略時はカレントディレクトリのjnlsv.log(jnlsaveコマンドで生成)となります。
      ジャーナルファイルとその退避ファイルを入力ファイルとして指定できますが、使用中のカレントジャーナルファイルは指定できません。
      
    ・-O
      レポートの出力先ファイル名を指定します。 省略時は標準出力に出力します。

  以下のオプションはデータ量が多いときに使用してください。
  
  情報のフィルタリングを行うオプションには以下があります。
    ・-type
      編集出力するレポートの種別を数値（01〜08）で指定します。 ","（カンマ）をデリミタとした複数指定できます。
      指定した数値にかかわらず、20以降のレポートは出力します。省略時は全レポートを出力します。
      レポートナンバー01がオペレーション情報サマリ、02がプロセス情報サマリ、03が平均値、04が最大値、05が最小値、06がオペレーション実行回数、07が平均同時稼動スレッド数、08が最大同時稼動スレッド数、20がCPU使用率、
      21がプロセスCPU使用時間(ユーザモード)、22がプロセスCPU使用時間(カーネルモード)、30がオペレーションCPU使用時間平均(ユーザモード)、31がオペレーションCPU使用時間最大(ユーザモード)、
      32がオペレーションCPU使用時間最小(ユーザモード)、33がオペレーションCPU使用時間平均(カーネルモード)、34がオペレーションCPU使用時間最大(カーネルモード)、35がオペレーションCPU使用時間最小(カーネルモード)の
      それぞれ集計です。

       指定例：
       01,02,03
       
    ・-time
      編集対象日時をdate1/time1_date2/time2で指定します。
      date1（開始日）、date2（終了日）はyyyy.mm.ddの形式で指定します。
      time1（開始時）、time2（終了時）はhh:mmの形式で指定します。 省略時は全レコードを編集します。
      
    ・-ag
      編集するアプリケーショングループを指定します。
      指定されたアプリケーショングループに含まれるオペレーション、またはプロセスのみを編集します。
      アプリケーショングループは複数指定できます。 その場合はカンマで区切ってください。
      省略時は全てのオペレーション、またはプロセスについて編集します。
      -pg,-txid,-rep,-cmp,-opオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。
      本オプションを使用するには、-cオプションによりカタログディレクトリを指定する必要があります。
      
    ・-pg
      編集するプロセスグループを指定します。 指定されたプロセスグループに含まれるオペレーション、またはプロセスのみを編集します。
      プロセスグループは複数指定できます。 その場合はカンマで区切ってください。
      省略時は全てのオペレーション、またはプロセスについて編集します。
      -ag,-txid,-rep,-cmp,-opオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。
      -cによりカタログディレクトリが指定されていない場合、プロセスについては指定プロセスのみの編集となりますが、オペレーションについては全てのオペレーション情報を編集します。
      
    ・-txid
      編集するオペレーションをTxIDで指定します。 TxIDは複数指定することができます。 その場合はカンマで区切ってください。
      省略時は全てのオペレーションを編集します。
      -ag,-pg,-cmp,-rep,-opオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。

    ・-rep
      編集するオペレーションをリポジトリIDで指定します。 指定されたリポジトリIDを持つ全てのオペレーションを編集します。
      リポジトリIDは複数指定することができます。 その場合は、カンマで区切ってください。 省略時は全てのオペレーションを編集します。
      このオプションを利用するためには、-cオプションによりカタログディレクトリが指定されている必要があります。
      -ag,-pg,-cmp,-op,-txidオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。
      
    ・-cmp
      編集するオペレーションをコンポーネント名で指定します。 指定されたコンポーネント名を持つ全てのオペレーションを編集します。
      コンポーネント名は複数指定することができます。 その場合は、カンマで区切ってください。 省略時は全てのオペレーションを編集します。
      このオプションを利用するためには、-cオプションによりカタログディレクトリが指定されている必要があります。
      -ag,-pg,-rep,-op,-txidオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。
      
    ・-op
      編集するオペレーションをオペレーション名で指定します。 指定されたオペレーション名を持つ全てのオペレーションを編集します。
      オペレーション名は複数指定することができます。 その場合は、カンマで区切ってください。 省略時は全てのオペレーションを編集します。
      このオプションを利用するためには、-cオプションによりカタログディレクトリが指定されている必要があります。
      -ag,-pg,-cmp,-rep,-txidオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。
      
  テーブルの整形をするオプションです。
    ・-line
      レポートの1ページあたりの行数を指定します。 指定可能な範囲は30〜100000です。
      省略された場合は、txt形式で60行、CSV形式で100000行となります。
      
    ・-txn
      1つの表に表示するオペレーションの数を指定します。 指定可能な範囲は1〜10000です。
      指定された数を越えるオペレーションが存在する場合は、別の表に表示します。
      省略された場合は、全てのオペレーションが1つの表に表示されます。
      
    ・-txt
      テキスト形式で編集します。 プロセスグループ名は先頭の14文字までしか表示されません。
      省略した場合はCSV形式で出力します。

4.10.2. オペレーションジャーナルの読み方

オペレーションジャーナル編集コマンドでは、以下の17種類のテーブルを出力します。

• オペレーション情報統計サマリ
• プロセスグループ情報統計サマリ
• オペレーション平均実行時間推移
• オペレーション最大実行時間推移
• オペレーション最小実行時間推移
• オペレーション実行回数推移
• 最大稼動スレッド数推移
• 平均稼動スレッド数推移
• CPU使用率平均推移（プロセスグループ）
• ユーザモードCPU使用時間推移（プロセスグループ）
• カーネルモードCPU使用時間推移（プロセスグループ）
• ユーザモードCPU使用時間平均推移（オペレーション）
• ユーザモードCPU使用時間最大推移（オペレーション）
• ユーザモードCPU使用時間最小推移（オペレーション）
• カーネルモードCPU使用時間平均推移（オペレーション）
• カーネルモードCPU使用時間最大推移（オペレーション）
• カーネルモードCPU使用時間最小推移（オペレーション）

テーブルの読み方は以下のようになります。 ここではオペレーション情報統計サマリとプロセスグループ情報統計サマリを例にしています。 以下に示すテーブルはCSV形式で編集されたものです。

オペレーション実行時間統計サマリのレポートは以下のように出力されます。

図7.1.10.2-1

各値はそれぞれ秒単位です。

実行時間とCPU使用時間に差がある場合は、データベース処理やネットワーク関連など何らかの「待ち」が生じていると推測されます。 オペレーションジャーナルからCPUを多く使用しているオペレーションを特定することもできます。

プロセスグループ情報統計サマリのレポートは以下のように出力されます。

図7.1.10.2-2

どのプロセスグループでCPUを消費しているかがオペレーションジャーナルよりわかります。 障害解析や、システムの稼働状況把握に役立ててください。

ここでいうスレッド稼働率は、[稼動スレッド数/(稼動可能なプロセス数×稼動可能なスレッド数)]となります。 これは多重度設定が適切かどうかの指標になります。

4.10.3. オペレーションジャーナル採取間隔時間の設定

オペレーションジャーナルの稼働情報の採取と設定更新の間隔は１分から１４４０分(24時間)の間で指定可能です。 デフォルトは５分となっています。 この稼働情報の採取と設定更新の間隔がオペレーションジャーナルの最小編集単位となります。 稼働情報の採取と設定更新の間隔を変更したい場合は以下の設定を変更してください。

「TPシステム」-「運用アシスタント」タブ-「稼働情報の採取と設定更新の間隔」

この設定は運用アシスタント機能でも使用されます。

4.10.4. 補足事項

• オペレーションジャーナルにおける実行時間とは、サーバAPにおいてユーザの実装を呼び出してからその結果が返るまでの時間を測定したものです。 通信リスナとの間のキューに滞留している時間は含まないことに注意して下さい。 なお、統合運用管理ツールにおいてオペレーションの情報として表示される最小/最大/平均レスポンス時間は、通信リスナとの間のキューに滞留している時間を含んでいます。
• ジャーナルに蓄積されるデータのサイズは「TPシステム」の「ジャーナルの設定」-「ファイルサイズ」で設定することができます。
• コマンドによる編集以前に設定が変更されると、以下の項目が正しく表示されない場合があります。
  オペレーション名
  指定されたプロセスグループに属するオペレーション情報
  各プロセスグループに設定された起動スレッド数、プロセス数、スレッド稼働率 (動的多重度変更が成された場合は設定の変更がなくても正確に表示されません)
• 実行時間の上限の推奨値は運用アシスタント機能での算出機能と同様の算出方法を用いていますが、オペレーションジャーナル編集コマンドの場合はジャーナルとして待避された情報のみが、解析の対象となります。 そのため統合運用管理ツールで表示される値と異なる場合があります。 オペレーションジャーナルで推奨値算出に用いている推奨基準は「ノーマル」です。
• 情報採取間隔時間経過前のデータはTPシステム停止時に破棄されます。 情報採取間隔を大きく設定している場合はご注意ください。
• 複数スレッド構成で何らかの問題によりいくつかのスレッドが閉塞した場合、その閉塞したスレッドは稼動状態としてオペレーションジャーナルにカウントされます。 つまり、オペレーション呼び出しをしていなくても、1スレッドが閉塞状態であれば稼動スレッド数は1として表示されます。 オペレーション呼び出しをしていないにもかかわらず、スレッド使用率が高い場合はスレッドが閉塞していると考えられるので、必要に応じてアプリケーションログなどからスレッド閉塞の原因を特定してください。
• 平均同時稼動スレッド数の計算式は以下の通りです。
  平均同時稼動スレッド数= 情報採取時の稼動スレッド数の総和 / 情報採取回数
  情報採取回数=(採取終了時間 - 採取開始時間)　/　情報採取間隔
• (V6.31以降)V6.3以降のWebOTXでは、オペレーションのCPU情報取得機能が新規に追加されたことにより、Solaris版とHP-UX版でV6.2と比べてオペレーションの実行性能が遅くなっています。 V6.2と比較して、HP-UX版で約4%、Solaris版で約16%遅くなっています。 Windows版とLinux版ではV6.2との性能差はありません。 V6.31以降では、このオペレーションのCPU情報取得機能を抑制し、オペレーション呼び出しの実行性能をV6.2と同等にすることができます。
  CPU情報取得を抑制するには、プロセスグループの設定の「環境変数」に以下の値を設定し、アプリケーショングループを再起動します。 この環境変数を指定すると、オペレーションジャーナルに記録されるオペレーションのCPU使用時間が全て0になります。 オペレーションのCPU情報採取機能を利用しない場合は、本環境変数を設定してください。
  名前：WO_NO_SAMPLING_CPUINFO
  値：ON

4.11. 通信情報(イベントジャーナル)

オペレーションの実行の過程で起きる障害については、イベントジャーナルを追っていくことで、どこで障害が発生しているか調べることができます。 また、イベントジャーナルではクライアントからの受信開始から応答の送信終了までを確認できるため、障害箇所がサーバ側なのかそうではないのか（ネットワークやクライアント側なのか）を切り分けることができます。

イベントジャーナルの編集は統合運用管理ツールから実行できます。 編集の対象となる期間は前回TPシステム起動時から編集実行時までを1世代分として、3世代分まで遡って編集することが出来ます。 TPシステムを終了した状態で編集を実行しても前回の運用中の情報が採取できます。 ログは次の箇所に出力されます。

[世代数を指定しない、現在稼動しているシステムを選択した場合]
${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\{ドメイン名}_woejout{数字}.log

[世代数を指定した場合]
${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\{ドメイン名}_woejout_{世代数}_{数字}.log

以下に主な採取ポイントを示します。 空欄は採取項目がないか、もしくは開発向けの内部情報です。 また、採取ポイントは他にもありますが、それらも開発向けの内部情報です。

• ※1：OBJMNGはオブジェクトマネージャのこと
• ※2：統合運用管理ツールを使ってオペレーション終了時に自動的にCommit/Rollbackする設定にした場合のみ
• ※3：TPSSetTxStatus()で設定した値

TX処理における上記コンポーネント(通信リスナ、サーバAP)の位置づけを以下に示します。 図中の数字は上表での種別の数字に対応しています。

図7.1.11-1

次に編集形式を以下に示します。

Event Journal Ver6.2                        2017/09/30
(イベントジャーナルのバージョン)              (編集日)

System name : domain1
Last Output Time = 2017/09/30:11:16:42 (情報の最終出力時刻)

DATE        TIME             PID    THREAD  RECNO  BLOCKNO  COMP   TYPE  ITEM1                ITEM2  ...
2017/09/30  10:05:26.622000  02728  65535   13832  000      TPLIB  01    Lower(IDL:Loop:1.0)  sample
2017/09/30  10:05:26.782000  02728  65535   13837  000      TPLIB  02    2                    1
(日付)      (時刻)           (プロセスID)   (レコード通番)  (コンポーネント名)                (項2)
                                    (スレッドID)   (ブロック#)     (種別)(項1)

コマンドによるイベントジャーナルの編集

イベントジャーナルの編集はコマンドでも実行可能です。 但しWebOTXが動作しているマシン上で直接コマンドを実行する必要があります。 コマンドは${AS_INSTALL}/Trnsv/commandにあります。 UNIXでWebOTXの運用ユーザを設定している場合は必ず運用ユーザでコマンドを実行する必要があります。 また、運用管理コマンドからの実行も可能です。

コマンドは下記の通りです。

  [コマンドからの実行]
> woejedit catalogpath maxline outpath domainName

  [運用管理コマンドからの実行]
otxadmin> invoke tpsystem.editEventJournal maxline

  ・catalogpath：カタログディレクトリをフルパスで指定します。
  
  ・maxline：編集後の1ファイルの行数(目安)を指定します。
    ここで指定した行数を越えないように分割してファイルを作成します。
    
  ・outpath：編集後の出力ファイル名をフルパスで指定します。
  
  ・domainName：ドメイン名を指定します。
  
  実行例
  
  [コマンドからの実行]
> woejedit /opt/WebOTX/domains/domain1/config/tpsystem 30000 /opt/WebOTX/domains/domain1/logs/tpsystem/ejout.log domain1

  [運用管理コマンドからの実行]
otxadmin> invoke tpsystem.editEventJournal 30000

  この場合、実際の出力ファイルはejout1.log, ejout2.log, ejout3.log … となります。

コマンドによる前世代のイベントジャーナルの編集

イベントジャーナルの編集は基本的に1世代分(前回TPシステム起動時からコマンド実行時まで)の情報を編集します。 統合運用管理ツールによる編集と同じく、コマンドによる編集でも3世代前までの情報を編集することが可能です。 また、運用管理コマンドからの実行も可能です。

コマンドは下記の通りです。

  [コマンドからの実行]
> woejedit catalogpath maxline outpath domainName savedfile

  [運用管理コマンドからの実行]
otxadmin> invoke tpsystem.editEventJournal maxline generation

  ・savedfile：1世代前は#0msj、2世代前は#1msj、3世代前は#2msjを指定します。
  
  ・generation：1世代前は1、2世代前は2、3世代前は3を指定します。

  実行例

  [コマンドからの実行]
> woejedit /opt/WebOTX/domains/domain1/config/tpsystem 30000 /opt/WebOTX/domains/domain1/logs/tpsystem/ejout.log domain1 #0msj

  [運用管理コマンドからの実行]
otxadmin> invoke tpsystem.editEventJournal 30000 1

  この場合、1世代前のイベントジャーナルを編集します。
  なお、3世代分のイベントジャーナルの編集前ファイルは

  ${INSTANCE_ROOT}/config/tpsystem/tmp/saveディレクトリ

  に退避しています。

ファイルサイズ

イベントジャーナル採取データはTPモニタにより定期的に${INSTANCE_ROOT}/config/tpsystem/tmpディレクトリ下のファイルmsjに出力されます。

msjファイルのファイルサイズは設定変更可能(既定値10MB)であり、そのサイズまでアペンド出力します。 ファイルサイズ上限に達した場合はサイクリックに出力されます。 設定は統合運用管理ツールの[TPシステム]をクリックし、右ページの[イベントジャーナル]-[ファイルサイズ]で行ってください。

4.12. キュー滞留情報

クライアントからのリクエストは通信リスナが受付を行い、アプリケーション側のキューに一旦格納されます。 キューはプロセスグループ単位のキューとプロセス単位のキューが作成されますが、ステートレスの場合はプロセスグループ単位のキューが、ステートフルの場合はプロセス単位のキューが使用されます。 アプリケーション側では処理スレッドに空きがあればすぐにリクエストをキューから取りだして処理しますが、スレッドが塞がっている場合にはしばらくキューに滞留した状態が続くことになります。 以下では、このキュー滞留数を確認する方法を説明します。

otxadminコマンドによるキュー滞留数の確認

otxadminコマンドを用いてキューの状態を確認できます。

 ・システムレベルでの最大キュー滞留数の参照

    キューはプロセスグループ単位で作成されていますが、その中で現在最も多いキュー滞留数を確認することができます。
   これを参照することにより、システム全体の滞留状況が確認できます。
otxadmin> get --monitor tpsystem.Queue.MaxStayMsgNum-Current

 ・プロセスグループレベルでの最大キュー滞留数の参照

    該当プロセスグループのキュー滞留数を確認します。 これを参照することにより、問題のプロセスグループが特定できます。
otxadmin> get --monitor tpsystem.applicationGroups.apg_name.processGroups.pg_name.queueingCount-Current

 ・オペレーションレベルでの最大キュー滞留数の参照

    実際にキュー滞留している要求がどのオペレーションであるかを確認することが出来ます。

    Webメソッドの場合
otxadmin> get --monitor server.applications.ap_name.module_name.interface_name.operation_name.queue-Current

    Java EEオペレーションの場合
otxadmin> get --monitor server.applications.ap_name.module_name.ejb_name.interface_name.operation_name.queue-Current

quewrtコマンドによるキュー滞留数の確認

このコマンドで確認できるのはプロセスグループ単位での滞留リクエスト数(ステートレスの場合)、プロセス単位での滞留リクエスト数(ステートフルの場合)です。

コマンドは${AS_INSTALL}/Trnsv/commandにあります。 UNIX版のWebOTX使用の場合は、WebOTX運用ユーザでコマンドを実行して下さい。

> quewrt -n ドメイン名 -M 収集間隔 -C 収集回数 [-f ファイル名]

  ・ドメイン名：ドメイン名を指定
  
  ・収集間隔：情報の収集間隔を秒単位で指定（1〜2^31-1。10以上を推奨）
  
  ・収集回数：情報の収集回数を指定（1〜2^31-1）
  
  ・ファイル名：データ収集結果を格納するファイル名を64バイト以内で指定

結果表示例：

MODE QUE-NAME                          MSG-NUM  POOL-NAME  CONECT DEQUE
  Q  STPCTLQUE28752                          0       ea60     ON    ON
  Q  QUE_TIMER                               0   746d6d70     ON    ON
  Q  TPproc029983                            0       ea60     ON    ON
  Q  java                                    0       ea60     ON    ON
  Q  _OTSLink                                0       ea60     ON    ON
  Q  JOURNALQUE0                             0      13880     ON    ON
  Q  SENDTPPQUE                              0       ea60     ON    ON
  Q  STPRCVQUE                               0       ea60     ON    ON
  Q  TPproc028754                            0       ea60     ON    ON
  Q  IIOPLISTENER                            0       ea60     ON    ON
  Q  AJPLISTENER                             0       ea60     ON    ON
  Q  TPproc028758                            0       ea60     ON    ON

• QUE-NAME
  キュー名称です(WebOTX内部で使用するキューも含まれます)。 プロセスのキューはTPproc(プロセスID) となっています。 プロセスIDとプロセスグループの対応は、カタログディレクトリに作成されるhistory.actファイルを参照して下さい。
• MSG-NUM
  キューに滞留しているリクエストの数が表示されます。

contpsコマンドによるキュー滞留数の確認

このコマンドで確認できるのはオペレーション単位での滞留リクエスト数です。

このコマンドはWebOTX運用ユーザで実行してください。 コマンドは${AS_INSTALL}/Trnsv/commandにあります。

> contps -n ドメイン名 DI N TR

結果表示例：

********** TPBASE TR STATUS ****************************************************
TxID    :処理状態:Tx滞留数  :総Tx数    :最小応答:最大応答:平均応答:応答合計
LOX000  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
UKN000  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
APR000  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABAAAB  :START   :         0:   1022991:       3:     503:       4:   4727079
ABAAAA  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa00  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa01  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa20  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa21  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
********** END OF TR STATUS ****************************************************

• Tx滞留数
  TxIDに対応するオペレーションで処理待ちとなっているリクエストの数です。 ここに表示される6桁のTxIDとCORBAオペレーションの対応付けには、イベントジャーナルを実行した時にカタログディレクトリ/tmpにできるotx.t2oファイルを参照して下さい。

4.13. 運用アシスタント

V6.3 から、オペレータの運用を支援する自律運用機能「運用アシスタント」を実現しました。 運用アシスタントに関する各種設定について以下に説明します。

4.13.1. 運用アシスタント機能全体に関する設定

運用アシスタント機能全体に関する設定について説明します。

なお、本節では統合運用管理ツールからの操作をメインに説明します。

4.13.1.1. 設定箇所について

統合運用管理ツールから設定する場合の設定箇所は、 「TPシステム」、「アプリケーショングループ」、「プロセスグループ」、「モジュール」、「オペレーション」ノードにある「運用アシスタント」タブになります。

ただしV9.2より既定設定ではオペレーションの監視は診断サービスが行うため、多くの設定項目は既定では表示されていません。 統合運用管理ツールの左上のメニュー「システム」-「システム設定」をクリックし、画面表示の「属性の表示レベル」と「操作の表示レベル」を「詳細レベルの情報を表示」に変更してください。 すると各ノードに「運用アシスタント」タブが表示されます。

以下の項目をまず確認してください。

• スローダウン監視機能
  スローダウン監視機能とは、TPシステムで動作するアプリケーションの動作を監視する機能です。既定では診断サービスのフェイルセーフが有効となっていますが、 V8以前の運用アシスタントを使った監視を行うには運用アシスタント機能を使用するを選択し、TPシステムを再起動して反映させて下さい。また、スローダウン監視を行わない場合はスローダウンを監視しないを、フェイルセーフによるスローダウン監視の設定に戻す場合はフェイルセーフ機能を使用するを選択してTPシステムを再起動してください。
  ただし、アプリケーションのスローダウン監視を行わない場合、システムの状態を監視しませんので障害発生時の解析が困難になる場合があります。 また、この設定を変更すると運用アシスタントの統計情報はクリアされます。
• 学習期間
  学習期間とは、システムの稼働状況を採取し始めてから、実際に自動設定などのアクションをとるまでの期間を示します。 学習期間内は、情報を採取・蓄積するのみで、以下の操作を行いません。
  • 多重度の適正チェック
  • 実行時間の上限の一括設定・自動設定（推奨値の提示は行います）
  • スローダウン障害検出
  例えば学習期間を1日(1440分)に設定すると、少なくとも1日分以上の情報をもとに上記のアクションがなされます。 週末になると負荷が高くなるといったシステムであれば、学習期間には1週間以上を設定してください。 現在までの学習時間は、プロセスグループまたはオペレーションのノードに表示されます。 学習期間を終えても情報の採取･蓄積は続けられます。 システムの稼動情報採取はプロセスグループ作成時、アプリケーション配備時に開始されます。 プロセスグループ未起動の状態であっても学習時間の経過時間に含みます。

以下の項目は必要であれば見直してください。

• 稼働情報の採取と設定更新の間隔
  稼働情報の採取と設定更新の間隔では、システムの稼動情報の採取と、運用アシスタントの各種設定を反映する間隔を設定します。この間隔ごとに運用アシスタント機能による解析と、その結果に基づいた反映処理が行われます。 また、ここで設定された時間は、オペレーションジャーナルの最小編集間隔でもあります。

以下の操作により、内部的に蓄積された情報を一旦クリアすることができます。

• 運用アシスタント統計情報のクリア
  通常、運用アシスタント機能では学習開始から現在までの全てのデータをもとに稼働状況を解析します。 しかし、明示的な環境の変化があった場合など、それ以前の情報を勘案することがふさわしくない場合もあります。 この操作を行うと今までの情報は一旦破棄され、新しく採取された情報より多重度最適化支援・実行時間の上限の適正値算出・スローダウン検出を行います。 システムの稼動状況を決定的に変えるような変更があった場合に、この操作を実行してください。 この操作を行うことにより、運用アシスタントの解析動作が素早く新しい環境に適合されます。
  この操作は通常「TPシステム」のノードを右クリックして実行します。細かい単位でクリアしたい場合は、統合運用管理ツールの左上のメニュー「システム」−「システム設定」をクリックし、画面表示の「操作の表示レベル」を「詳細レベルの情報を表示」に変更してください。

4.13.2. 多重度の最適化支援

多重度最適化支援機能の設定について以下に説明します。

多重度最適化支援機能ではシステムの稼働状況を解析し、多重度の増減を推奨、または自動変更します。 多重度の増減が推奨される場合は、以下のメッセージが統合運用管理ツールに通知され、イベントログ/syslog, agent.log(webotx_tpmmgr.log)に出力されます。 また、多重度不足時にはキューへのリクエスト滞留数とイベントジャーナルを採取します。

"OTX20220100 プロセスグループxxxの多重度が不足しています。プロセス数/スレッド数の増加を検討してください。"
"OTX20220001 プロセスグループxxxは多重度を減らしても同じ処理能力を維持できます。プロセス数/スレッド数の削減を検討してください。もしくは予備プロセス数を変更してください。"
"OTX20220100 The multiplicity of process group xxx is insufficient. Please increase the number of process or threads."
"OTX20220001 Even if the multiplicity is decreased, process group xxx can maintain the same processing performance. Please decrease the number of process or threads, or modify backup process count."

[注] イベントIDがV6.3から変更になりました(OTX20220000 → OTX20220100
[注] OTX20220001のトレースレベルがV9.2から変更になりました(INFO → DEBUG)

多重度の自動変更機能を利用している場合は、以下のメッセージとなります。

"OTX20220010 プロセスグループxxxの多重度が不足しています。プロセス数をaに変更しました。"
"OTX20220011 プロセスグループxxxは多重度を減らしても同じ処理能力を維持できます。プロセス数をaに変更しました。"
"OTX20220010 The multiplicity of process group xxx is insufficient. So the count of process is changed to a."
"OTX20220011 Even if the multiplicity is decreased, process group xxx can maintain the same processing performance. So the count of process is changed to a."

多重度最適化支援機能の設定としては、以下の設定をまず確認してください。

• 多重度最適化支援:目標応答時間
  最低限確保したいキュー待ち時間を含む応答時間を設定してください。 現在キューの最後尾で待機しているリクエストが応答期限を越える可能性があると予測される場合、運用アシスタント機能は多重度が不足していると判断し、オペレータへの通知、またはプロセス多重度増加を行います。 リクエストの応答時間の予測は、オペレーションの優先度が同一である場合が想定されています。
  以下のメッセージが表示された場合は応答期限設定を長めに設定することを検討してください。

  "OTX20220020 プロセスグループxxxの応答期限設定が小さすぎます。応答期限設定を変更するか、オペレーションzzzの処理を見直してください。"
  "OTX20220020 The response time limit of process group xxx is insufficient. So modify the configration or review the processing of operation zzz."
  

  このメッセージはオペレーションzzzのキュー待ち時間を含まない処理時間が応答期限設定を超えているため、多重度を増やしても応答期限を満たせないことを意味します。 運用アシスタントでは、このメッセージを出力した後もそれまでと同様に多重度最適化支援を続けます。

必要に応じて以下の設定も見直してください。 多重度を増加させるべきかの判断基準を示す設定には、上記の応答期限に加えて以下のものがあります。

• 多重度最適化支援:アイドルCPU使用率
  最低限確保しておきたいマシンのアイドルCPU使用率を設定してください。 運用アシスタント機能では、キューの最後尾で待機しているリクエストが応答期限を越える可能性があると予測される場合であっても、プロセス多重度を増加させた結果、マシンのアイドルCPU使用率がこの設定を下回ると予測されるならば、多重度を増加すべきとは判断しません。 マシンのアイドルCPU使用率が0に近い状態で多重度を上げても、処理能力の向上はのぞめません。
  * Linux版では多重度を増加させた場合のCPU使用率を予測しません。 アイドルCPU使用率設定と現在のマシンのアイドルCPU使用率を比較します。
• 多重度最適化支援機能で動的変更するプロセス数の最大値
  プロセスグループあたりのプロセス数の上限を設定することができます。 本設定は「TPシステム」ノードの「運用アシスタント」タブにあります。

  表7.1.13.2-1

  設定名	パラメータ
  	既定値	最大値
  多重度最適化支援機能で動的変更するプロセス数の最大値	5	1000

  多重度最適化支援機能で動的変更するプロセス数の最大値の制限により多重度を増やせない場合は、以下のメッセージが出力されます。

  "OTX20220012 プロセスグループxxxの多重度が不足していますが、多重度最適化支援機能で動的変更するプロセス数の最大値を超えるため、プロセス数をaに変更できません。"
  "OTX20220012 The multiplicity of process group xxx is insufficient. But the count of process cannot be changed to a , because over MaxMultiProcess."
  

多重度を減少させるかの判断基準を示す設定には、以下のものがあります。

• 多重度最適化支援:多重度過剰と見なす間隔
  プロセス数を減らしてもオペレーション実行に影響を与えない期間がこの時間を超えた場合、多重度を減少させるべきと判断されます。 必要なくなったと思われるプロセスをどのくらいの期間残しておくかをここで設定してください。
• 多重度最適化支援:予備プロセス数
  障害回避の観点で余分に確保しておきたいプロセス数を設定してください。 ここで設定された予備プロセス数分はプロセス数が過剰であっても、多重度を減少させるべきとは判断されません。

以下の設定を変更することにより、そのときのシステム稼働状況に応じて動的に多重度を変更することができます。

• 多重度最適化支援
  「自動変更」を選択した場合、情報採取間隔が経過するごとに多重度の適正をチェックし、必要に応じてプロセス数を動的に変更します。 上に挙げた各種の設定が妥当かどうか十分に検証した上で、「自動変更」機能をご利用ください。

[注] 多重度最適化支援機能は、各プロセスグループで学習が完了後(プロセスグループ配下の全アプリケーションに属する全オペレーションで、稼働時間が学習期間を超過)に動作する点ご注意ください。

4.13.3. 実行時間の上限の適正値算出

実行時間の上限の適正値算出機能に関する設定について以下に説明します。 実行時間の上限とは、実行時間の上限を超えるオペレーションが検出し異常状態とみなされたプロセスを再起動させる、ストール障害自律復旧のための設定です。

運用アシスタントが算出した実行時間の上限の推奨値は、以下に表示されます。

• 実行時間の上限の推奨値
  オペレーションのノードの「オペレーション制御」タブ内の「実行時間の上限の推奨値」に、運用アシスタントが算出した実行時間の上限の推奨値が表示されます。 すぐ上に表示される「実行時間の上限」が現在実際に設定されている値です。 実行時間の上限の推奨値は、該当オペレーションの実行回数が30回以上になるまでは算出されません。 この場合、「実行時間の上限の推奨値」には-1（設定なし）が表示されます。 また、TPシステムのスローダウン監視機能がフェイルセーフ機能を使用する、またはスローダウンを監視しないになっている場合もこの値が-1になっています。

運用アシスタントが算出した実行時間の上限の推奨値を実際に設定するには、以下の操作を実行します。

• 実行時間の上限に推奨値を設定
  運用アシスタントが算出した実行時間の上限の推奨値を実際に設定します。 この操作は通常「TPシステム」のノードを右クリックして実行します。 この場合、全オペレーションに対して一括設定されます。 細かい単位で設定したい場合は、統合運用管理ツールの左上のメニュー「システム」−「システム設定」をクリックし、画面表示の「操作の表示レベル」を「詳細レベルの情報を表示」に変更してください。 設定負荷低減のため、推奨値が設定値の90%〜100%であるような微小な減少では値は設定されません。 実行時間の上限の推奨値の一覧はotxadminコマンドで確認することができます。

  get *.rcmdExeMax
  

必要に応じて以下の設定も確認してください。

• 実行時間の上限の推奨値を更新する
  実行時間の上限の推奨値の更新有無を設定します。 「更新する」を設定すると稼働情報の採取と設定更新の間隔(「TPシステム」-「運用アシスタント」-「稼働情報の採取と設定更新の間隔」）ごとに推奨値が更新されます。 推奨値の妥当性を検証したい場合など、推奨値の更新を止めることもできます。
• 実行時間の上限の推奨値を提示する
  実行時間の上限の推奨値の提示有無を設定します。 推奨値を提示しない場合は実行時間の上限の自動設定機能も働きません。
• 実行時間の上限値の推奨基準
  実行時間の上限値を推奨する基準を設定します。 早期復旧優先を設定した場合は短めの値が、オペレーション継続優先を設定した場合は長めの値が実行時間の上限値として推奨されます。 以下のメッセージが統合運用管理ツールに通知、またはイベントログ/syslog,agent.logに出力された場合は、推奨基準が適切でないことを意味します。 長めの値を設定するように推奨基準を見直してください。 例えば、「ノーマル」状態で以下のメッセージを検出した場合は、推奨基準を「オペレーション継続優先」に変更してください。

  "OTX20310100オペレーションｚｚｚの実行時間が実行時間の上限の推奨値を超えました。推奨値算定モードを見直してください。 実行時間=aaaa。 ObjectName=yyy"
  "OTX20310100 The execution time of zzz get over the recommended timeout value. Review rcmdExeMaxbase. Excecution Time is xxx. The ObjectName is yyy."
  

  [注] イベントIDがV6.3から変更になりました(OTX20310000 → OTX20310100)
• 実行時間の上限の推奨値の最小値
  実行時間の上限の推奨値の最小値を設定します。 この値より小さな値が推奨されても、自動設定・一括設定されません。 実行時間の上限の推奨値として表示はされます。
• 実行時間の上限に推奨値を自動設定する
  実行時間の上限の自動設定を設定します。 「自動設定する」をチェックすると稼働情報の採取と設定更新の間隔(「TPシステム」-「運用アシスタント」-「稼働情報の採取と設定更新の間隔」）ごとに実行時間の上限が自動的に更新されます。 設定負荷低減のため、推奨値が設定値の90%〜100%であるような微小な減少では値は設定されません。
  自動設定機能を使用すると、頻繁に設定値が変更されるためプロジェクト側で現在の設定値を把握しづらいというデメリットがあります。 稼働状況の即時反映を最優先する場合をのぞいて、実行時間の上限の推奨値を確認後に実行時間の上限に一括設定する方法を推奨します。
  実行時間の上限はこれを超えるオペレーションを検出した場合にプロセスを再起動させるための設定です。 自動設定機能を利用される際は、上に挙げた各種の設定が妥当かどうか十分に検証した上でご利用ください。

4.13.4. スローダウン障害の検出

スローダウン障害検出機能のための設定について以下に説明します。

ここでスローダウン障害とは、「従来に比べて総体として遅くなった」状態を指します。 何回かのオペレーション実行がたまたま長いだけではスローダウン障害とは見なしません。

V9.2からV8までの統計情報によるスローダウン判定時間の自動設定に加えて、オペレーションごとにスローダウン判定時間を手動設定する機能を追加しました。スローダウン判定時間を切り替えるには、オペレーションのスローダウンの判定時間を自動計算するの設定を変更して下さい。

スローダウン判定時間の自動設定では、前回の情報取得までの統計情報と、最新の情報採取分（「稼働情報の採取と設定更新の間隔」分）のデータを比較します。 最新の情報取得で得た各オペレーションの実行回数が30回に満たない場合は、スローダウン検出を行わず、次回の情報取得分にマージさせます。 スローダウン障害の疑いがあっても、正常動作の可能性が多く残る場合は、スローダウン障害として検出しません。また、V8.2からは1秒以下でのスローダウンは検出しません。

スローダウン判定時間の手動設定では、稼働情報の採取と設定更新の間隔ごとにオペレーションの実行時間の平均を算出し、その時間が手動設定された値より大きい場合にスローダウンと判定します。
スローダウン障害を検出すると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,agent.log(tpmmgr.log)に出力します。 このとき、スタックトレースを5秒間隔3回でアプリケーションログに出力し、イベントジャーナルとキュー情報を ${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\配下に出力します。 これらの情報を確認することで障害解析に役立ちます。また、スタックトレースの採取回数はチューニング可能です。

• スローダウン判定時間を自動設定する場合
  

  "OTX20110100 オペレーションzzzのスローダウンを検出しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。プロセスグループ=vvv。 ObjectName=yyy"
  "OTX20110100 The Operation zzz get late. Average of current time is xxx s. Average of normal time is www s. The Process Group is vvv. The ObjectName is yyy"
  

  [注] イベントIDがV6.3から変更になりました(OTX20110000 → OTX20110100)

• スローダウン判定時間を手動設定する場合
  

  "OTX20110101 オペレーションzzzのスローダウンを検出しました。current:平均実行時間=xxx秒。スローダウンとみなす応答時間=www秒。プロセスグループ=vvv。 ObjectName=yyy"
  "OTX20110101 The Operation zzz get late. Average of current time is xxx s. Response time border as slowdown is www s. The Process Group is vvv. The ObjectName is yyy"
  

スローダウン障害からの回復を検出すると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,agent.log(webotx_tpmmgr.log)に出力します。 遅くなったまま長期間状態が落ち着いた場合も以下のメッセージとなります。

• スローダウン判定時間を自動設定する場合
  

  "OTX20120100 オペレーションzzzがスローダウン状態からノーマル状態に遷移しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。プロセスグループ=vvv, ObjectName=yyy"
  "OTX20120100 The Operation zzz transit from slowdown to normal. Average of current time is xxx s. Average of normal time is www s. The Process Group is vvv. The ObjectName is yyy"
  

  [注] イベントIDがV6.3から変更になりました(OTX20120000 → OTX20120100)

• スローダウン判定時間を手動設定する場合
  

  "OTX20120101 オペレーションzzzがスローダウン状態からノーマル状態に遷移しました。current:平均実行時間=xxx秒。スローダウンとみなす応答時間=www秒。プロセスグループ=vvv, ObjectName=yyy"
  "OTX20120101 The Operation zzz transit from slowdown to normal. Average of current time is xxx s. Response time border as slowdown is www s. The Process Group is vvv. The ObjectName is yyy"
  

スローダウンが検出された場合は、システム運用上重要な問題となっていないか、オペレーションジャーナルや統合運用管理ツールを使用し稼動状態を調査してください。 スローダウン検出機能は、遅くなり始めた状態を検出するものであり、致命的な遅延となる前に自然復旧される場合もあります。 この場合は特に復旧処置は必要ありません。

スローダウン障害が、自然復旧される一時的なものか、オペレータによる対処が必要な恒久的なものかの判断を支援する機能として「長期スローダウン検出機能」があります。 オペレーションのスローダウンを検出してから「スローダウンの継続を監視する間隔」を超えてなお、スローダウン状態が継続していると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,agent.log(webotx_tpmmgr.log)に出力します。

• スローダウン判定時間を自動設定する場合
  

  "OTX20110200 オペレーションzzzの長期にわたるスローダウン状態を検出しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。スローダウン継続時間=uuu分。プロセスグループ名=vvv, ObjectName=yyy"
  "OTX20110200 The Operation zzz is slow for a long time. Average of current time is xxx s. Average of normal time is www s. Duration of slow is uuu m. The Process Group is vvv. The ObjectName is yyy"
  

• スローダウン判定時間を手動設定する場合
  

  "OTX20110201 オペレーションzzzの長期にわたるスローダウン状態を検出しました。current:平均実行時間=xxx秒。スローダウンとみなす応答時間=www秒。スローダウン継続時間=uuu分。プロセスグループ名=vvv, ObjectName=yyy"
  "OTX20110201 The Operation zzz is slow for a long time. Average of current time is xxx s. Response time border as slowdown is www s. Duration of slow is uuu m. The Process Group is vvv. The ObjectName is yyy"
  

「長期にわたるスローダウン状態」を検出すると、メッセージ出力とともに、該当プロセスグループのスタックトレースを採取します。 このAPログに出力されるスタックトレースを参照することで、スローダウンの原因を調査することができます。

「長期にわたるスローダウン状態」が通知される場合、スローダウンが長期化しており、一時的なスローダウンでなく恒久的なスローダウンに陥っている可能性があります。 オペレーションジャーナルやスタックトレース、イベントジャーナルによりスローダウンの原因を調査してください。 必要に応じてプロセスグループの再起動などの復旧に向けた対処を検討してください。 運用管理製品などによりスローダウン障害を監視する場合は、本メッセージを監視することをお奨めします。

スローダウン状態が継続しているか否かは、「稼働情報の採取と設定更新の間隔」ごとに監視されます。 「スローダウンの継続を監視する間隔」を超えてスローダウン状態が継続していても、次の情報採取までは「長期にわたるスローダウン状態」が検出されません。 前回スローダウン状態か否かを解析してからの該当オペレーションに対する呼び出し回数が30に満たない場合は、スローダウン状態か否かの判断ができないため、「長期にわたるスローダウン」は検出されません（復旧したとも見なされません）。 スローダウン継続時間は、最初にスローダウンを検出した時間を0としてカウントされます。 「長期にわたるスローダウン状態」は同一オペレーションに対して連続して通知されません。

スローダウン障害検出機能のための設定には以下があります。 必要に応じて見直してください。

• スローダウン障害検出基準
  スローダウン障害を検出する基準を設定します。 スローダウン障害を早期に検出したい場合は「早期検出優先」を設定してください。 正常動作とみなせるオペレーションまでスローダウン障害として検出されてしまう場合は「長め」を設定してください。
• スローダウンの判定時間を自動計算する
  スローダウンの判定時間を統計情報に基づいて自動計算するV8の動作にするにはこの設定を有効にしてください。判定時間を手動で設定する場合は無効にしてください。
• スローダウンとみなす応答時間
  スローダウンと判定する時間を手動設定します。オペレーションごとにオペレーションの動作に合わせて値を設定してください。スローダウンの判定時間を自動計算するを無効にすると、この設定値が使用されます。
• スローダウン継続時間
  スローダウンを検出してからの経過時間を分単位で監視します。 この時間を過ぎてもスローダウン状態が解消されない場合は「長期にわたるスローダウン」として警告メッセージを出力します。 スローダウンを検出してからの経過時間は、稼働情報の採取と設定更新の間隔ごとにチェックされます。 -1を設定した場合は、スローダウンを検出してからの経過時間を監視しません。
• スローダウン時に自動スタックトレースを採取する
  「長期にわたるスローダウン状態」を検出時に、自動でスタックトレースを採取するかを設定します

スローダウン状態がどのくらい長く継続しているかは、以下で参照できます。

• スローダウン継続時間
  スローダウンを検出してからの経過時間を分単位で表示します。 ノーマル状態の場合は-1が表示されます。 スローダウン継続時間は稼働情報の採取と設定更新の間隔ごとに計算されます。

4.14. 同時受付オペレーション数

TPシステムの同時受付オペレーション数

TPシステムで同時に受け付けるオペレーション数を制限することができます。変更するには、同時受付オペレーション数を変更します。実行中のオペレーションとキューに滞留中のオペレーションの両方を含みます。WebOTX内部で生成され、IIOPリスナを経由して起動されるオペレーションも含まれます。非同期トランザクションは含まれません。

統合運用管理ツールからの設定は以下の通りとなります。

• [TPシステム]-[IIOPリスナ]-[上限設定]-[同時受付オペレーション数]

TPシステムで現在受け付けているオペレーション数は、統合運用管理ツールから参照できます。

• [統計情報]-[ドメイン名]-[TPシステム]-[IIOPリスナ]-[同時受付オペレーション数]

TPシステムで現在受け付けているオペレーション数は、otxadminコマンドからでも参照できます。

otxadmin> get --monitor tpsystem.IIOPListener.simultaneousRequestsCount-Current

プロセスグループの同時受付オペレーション数

IIOPリスナは各プロセスグループにオペレーションを振り分けますが、その際にプロセスグループが同時に受け付けるオペレーション数を指定できます。実行中のオペレーションとキューに滞留中のオペレーションの両方を含みます。WebOTX内部で生成され、IIOPリスナを経由して起動されるオペレーションも含まれます。非同期トランザクションは含まれません。

統合運用管理ツールからの設定は以下の通りとなります。

• プロセスグループの[上限設定]-[同時受付オペレーション数]

プロセスグループで現在受け付けているオペレーション数は、統合運用管理ツールの統計情報から参照できます。

• [統計情報]-[TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[同時受付オペレーション数]

プロセスグループで現在受け付けているオペレーション数は、otxadminコマンドからでも参照できます。

otxadmin> get --monitor tpsystem.applicationGroups.apg_name.processGroups.pg_name.simultaneousRequestsCount-Current

4.15. ログ・バックアップファイルの削除

TPシステムのログ・バックアップファイルの削除

TPシステムではログファイルやバックアップファイルによるディスク容量圧迫を防ぐために削除する機能を提供しています。

タイミングについて

ログファイルやバックアップファイルの削除は以下のタイミングで実行されます。

• TPシステム起動時
• TPシステム停止時
• TPシステム起動後の12時間毎
• TPシステムの運用操作[トレースファイルの削除]実行時

TPシステムの運用操作[トレースファイルの削除]は以下のように実行します。

• 統合運用管理ツール：
  

  [TPシステム]を右クリックし、表示されたメニューより[トレースファイルの削除]を実行

• 運用管理コマンド：
  

  otxadmin> invoke tpsystem.deleteOldTraceFile
  

設定について

ログファイルやバックアップファイルの削除は以下で設定した期間より古いファイルを削除対象とします。

• 統合運用管理ツール：
  

  [TPシステム]-[システムパラメータ]-[トレースファイルの保存期間]

• 運用管理コマンド：
  

  otxadmin> set tpsystem.traceFilePreservationPeriod=<日数>
  

対象ファイルについて

ログファイルやバックアップファイルの削除は以下のファイル、ディレクトリを対象に実行されます。

※1 削除したプロセスグループのログファイルは対象外となります。
※2 削除したアプリケーショングループのログファイルは対象外となります。
※3 「保存期間」は[TPシステム]-[システムパラメータ]-[トレースファイルの保存期間]の設定値を指しています。

削除実行時のログについて

ログファイルやバックアップファイルの削除実行時は以下のログがINFOレベルでagent.log(webotx_tpmmgr.log)へ出力されます。

"OTX07000027: 古いトレースファイルの削除を実行しました。(チェック数：xx、削除数：xx、保存期間：xx日)"