NEC Mark
WebOTX Manual V10.2 (第4版)

目次を表示

チューニング

1. APサーバ

1.1. チューニングのための事前確認

チューニングの方針を立てるためには現在使用中または使用予定のWebOTXのメモリ使用量や性能を正しく把握する必要があります。WebOTXやOSが提供する情報採取方法について説明します。

1.1.1. メモリ使用量の確認

WebOTXが必要とするメモリ使用量はマニュアルの以下を参照してください。

WebOTXのエージェントプロセスが使用するJVMヒープサイズの確認については [ドメイン > Javaプロセスの監視・管理] を、JVMヒープサイズのモニタリングに関しては [モニタリング]を参照してください。

アプリケーションプロセスのメモリ使用量の確認については[ TPシステム > 統計情報(統合運用管理ツールでの表示) ] を参照してください。その他のプロセスについてはタスクマネージャ(Windowsの場合)またはtopコマンド(unixの場合)で確認してください。また、OS全体でのメモリ残量はタスクマネージャ(Windowsの場合)またはswapinfoコマンド(unixの場合)で確認できます。
なお、Oracle製JDKをご使用の場合はjconsoleを、HP-UXの場合はHPJmeterなどでヒープ使用量を確認することもできます。

1.1.2. アプリケーション処理時間の確認

実行時間の上限の設定を適切に行うために、運用アシスタントの実行時間の上限の適正値算出機能を利用してください。 詳細は [ TPモニタ > TPモニタの障害に対する機能 > 運用アシスタント ] の実行時間の上限の適正値算出を参照してください。

また、プロセス数やスレッド数を適切に設定するためにはキュー滞留数がひとつの目安になります。統合運用管理ツールでのキュー滞留数の確認方法については [モニタリング > モニタリング情報の採取 > モニタリングの利用例 > キューイング数のモニタリング] を参照してください。さらにquewrtコマンドで確認することもできます。 [ TPシステム > キュー滞留情報 ] を参照してください。

1.1.3. 多重度の確認

クライアント多重度、スレッド多重度がどこまで使われているのかを確認する方法を説明します。

1.2. リソースチューニング

WebOTXのプロセスとして動作するJava仮想マシン(Java VM)に対してチューニングを行うことで、使用メモリ、ガーベッジコレクション(GC)の頻度などを考慮した設計を行うことができます。

ここで設計対象となるのは、ユーザドメインのエージェントプロセス、プロセスグループです。それらに対し個々にヒープ領域、非ヒープ領域を考慮した設計を行う必要があります。

なおチューニングする値については [モニタリング > モニタリング情報の採取] や [ ドメイン > Javaプロセスの監視・管理 > 統計レポート出力]、 [ ドメイン > Javaプロセスの監視・管理 > GCログ出力] や、下記の例のようにgenerate-jvm-reportコマンドなどから 高負荷時にも耐えられるサイズを見積もる必要があります。

otxadmin > generate-jvm-report --type=memory
**** Java 仮想マシン [アプリケーションサーバ インスタンス名: server] に対するメモリ (Perm Gen, Eden Space etc.) 情報 ****

[メモリ情報]
ヒープメモリ使用状況:     132,486 K /   192,256 K 全体(確定),  68 % 使用済み [   65,536 K 初期,   506,816 K 最大]
非ヒープメモリ使用状況:   114,302 K /   125,056 K 全体(確定),  91 % 使用済み [    2,496 K 初期,        -1 K 最大]

ファイナライズを待機しているオブジェクトの数(概算): 0

[メモリプール情報]
Java 仮想マシンの実行時間: 0 時間 45 分 17 秒
Survivor Space      2,983 K /     6,592 K 全体(確定),  45 % 使用済み [    2,176 K 初期,    17,472 K 最大]
Eden Space         17,260 K /    53,120 K 全体(確定),  32 % 使用済み [   17,472 K 初期,   139,776 K 最大]
Compressed Class Space      8,680 K /    11,008 K 全体(確定),  78 % 使用済み [        0 K 初期, 1,048,576 K 最大]
Metaspace          75,575 K /    83,712 K 全体(確定),  90 % 使用済み [        0 K 初期,        -1 K 最大]
Tenured Gen       112,472 K /   132,544 K 全体(確定),  84 % 使用済み [   43,712 K 初期,   349,568 K 最大]
Code Cache         30,098 K /    30,336 K 全体(確定),  99 % 使用済み [    2,496 K 初期,   245,760 K 最大]
                         :

また、設定を行った場合、ドメインの再起動、またはプロセスグループの再起動が必要となります。

1.2.1. ヒープ領域に対するチューニング

ヒープ領域の構成とJVMオプションの設定範囲

ヒープ領域は使用するガベージコレクションの種別により、ヒープ領域に対する扱いが変わる点について注意する必要があります。JDK8を使用した場合は、既定では世代別GCが使用されます。

世代別GCは、New領域、Old領域を分けて管理し、それぞれの領域に対してデータの特性に考慮したアルゴリズムでもってガベージコレクションを実施します。

一方、G1GC(ガベージファースト・ガベージ・コレクタ)は、世代別GCと異なりヒープ領域が多数の均等サイズのリージョンと呼ばれる単位に分割されます。その上で、GC時に発生する一時停止時間を考慮した上で設計を実施する必要があります。世代別GCと同じようにNew領域、Old領域を分けて管理しますが、アルゴリズムによりそれらの値は自動的に変動します。アルゴリズムにより調整されるため、New領域やOld領域に対しての割合などを設定することはできません。

ヒープサイズについて

使用するGCの種別に問わず、メモリに対しての見積もりを行う場合、New領域、Old領域をどの程度使用する可能性があるか、考慮した上でその2つを合計した値を最大ヒープサイズとして設定する必要があります。

New領域に対する設計

アプリケーションを実際に動作させ、期待通りのスループットを得られるか確認を行う必要があります。アプリケーションを動作させ、GCの発生頻度を確認してください。New領域が少ないとOld領域に登録されやすく、Old領域に格納されたオブジェクトは、FullGCでのみ解放されます。

このFullGCが頻発するとアプリケーションの処理性能が劣化します。この点を考慮し、アプリケーションが期待したスループットを得ているか確認することが重要です。

Old領域に対する設計

Old領域は、常駐する可能性があるオブジェクトとNew領域から割り当てられるオブジェクトの2種類を考慮する必要があります。New領域に見積もった値と常駐する可能性があるオブジェクトの値を加算したものを設定する必要があります。

HEAP_OLD

常駐する可能性があるオブジェクトのサイズを見積もるには、アプリケーションを配備した状態でGCログからFullGC発生直後のヒープサイズを確認する必要があります。何回かFullGCが発生したのを確認した後、安定して使用される値が最終的に常駐する可能性のあるオブジェクトのサイズとなります。

最大ヒープサイズ・最小ヒープサイズの設定

なお、これらの設定値が大きすぎると、${INSTANCE_ROOT}/logs/server.logや${INSTANCE_ROOT}/logs/tpsystem/<アプリケーショングループ名>/<プロセスグループ名>/<プロセスグループ名>.<プロセスID>.log などに次のようなエラーが発生してドメインが起動しなくなる場合がありますので注意して下さい。また、実際にこれらのエラーが発生した場合には、OS側でそれ以上のサイズを確保できない状況であることを示していますので、指定した値よりも小さな値を設定するようにしてください。

Error occurred during initialization of VM
Could not reserve enough space for object heap

世代別GCの場合に設定可能なJVMオプション

世代別GCの場合に設定可能なJVMオプションは下記の通りです。


G1GCの場合に設定可能なJVMオプション

G1GCの場合はシステム要件に従い、JVMオプションを設定する必要があります。設定可能なJVMオプションとその詳細は、ガベージファースト・ガベージ・コレクタのチューニングを参照してください。

1.2.2. 非ヒープ領域に対するチューニング

非ヒープ領域の構成とJVMオプションの設定範囲

非ヒープ領域の構成は、ヒープ領域に対するガベージコレクションの種別による影響を受けません。非ヒープ領域は大きくはMetaspaceと呼ばれるクラス情報を格納する領域とそれ以外の領域に分かれており、いくつかの領域が調整対象となります。

Metaspace

Metaspace領域はクラスの情報が格納される領域となりますが、内部的にはクラスの情報を格納する領域(Class Type)と、それ以外の情報を格納する領域(Non-Class Type)に分かれています。Non-Class Typeの一つとして圧縮オブジェクトポインタ機能向けの領域(Compressed Class Space)が用意されています。

何れの領域も動作するアプリケーションの実装により変動するものとなるため、一概に値を設定することはできません。このため、アプリケーションを実際に動作させ、Metaspace領域及びCompressed Class Spaceの使用状況がどこで安定するのか、GCログや、generate-jvm-reportコマンドより確認する必要があります。

Code Cache

アプリケーション実行時にJIT コンパイラ(Just-In-Time compiler)により生成されたネイティブコードは、Code Cacheというメモリ領域に配置されます。JDK8以降では、JITコンパイラの既定が階層型コンパイルとなっており、この階層型コンパイルは従来の手法よりCode Cache領域を使用する可能性があります。

Code Cacheサイズが枯渇した場合、JIT コンパイルが行われないため、性能が低下するおそれがあります。そのため、必要に応じてチューニングが必要です。Code Cacheサイズが不足した場合、${INSTANCE_ROOT}/logs/server.logや${INSTANCE_ROOT}/logs/tpsystem/<アプリケーショングループ名>/<プロセスグループ名>/<プロセスグループ名>.<プロセスID>.log などに以下のような警告が出力されます。

Java HotSpot(TM) Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=

Code Cacheサイズのチューニングは下記のような方法でのチューニングが必要です。

  1. JVMオプション(-XX:+PrintCompilation)を使用して、実際にコンパイルされているメソッドを出力。
  2. 出力が安定状態になるまで待つ
  3. JVMオプション(-XX:ReservedCodeCacheSize)を付与し、Code Cacheを2倍に増やし出力されるメソッド数を確認する。
  4. コンパイルされたメソッド数が増加した場合、変更前のCode Cache領域が小さかったものと判断できる。
  5. 全体的なパフォーマンスの再テストを行い、コード・キャッシュサイズの変更が他の側面に悪影響を及ぼしていないかどうかを確認する。
Thread Stack

JavaVM上でスレッドを生成した場合に、そのスレッド終了時まで一時的なデータを格納するために使用される領域です。既定値は使用するOSにより変わります。

通常は変更する必要がありませんが、あるメソッドを再帰的に延々と呼び出したり、非常に大きなサイズのローカル変数などを使用した場合に枯渇する恐れがあります。この場合java.lang.StackOverflowErrorがスローされます。このエラーがでる場合、スタックサイズの拡張を検討してください。

C Heap

調節はできません。この領域Java VMや、アプリケーションからJavaJava Native Interface(JNI)を使用し、CやC++などの他の言語を使用したときに使用される領域です。このためJNI等を使用しアプリケーションを実装している場合は、メモリの解放漏れなど発生しないよう注意してアプリケーションを実装する必要があります

1.2.3. 起動サービスの見直し

ドメイン作成時の既定値では、既定の状態に従い、サービスの起動設定が行われます。

この際、運用上必要のないサービスを起動させない設定にすることによりメモリを削減することができます。サービスを停止する場合、下記の表に記載されている停止条件を確認し、停止条件に全て合致しているか確認を行った後、設定を変更してください。

1.2.3.1. 設定方法

  統合運用管理ツールのドメイン毎に設定

ライフサイクル別停止設定
ライフサイクル名
(英語名)		 既定状態 停止への変更 停止条件 備考
データベースコントローラ
(DBControllerService)		 起動 可 データベースコントローラを使用してデータベースの起動を行わない場合
 テスト用サーバをインストールした場合、自動的にJavaDB(Derby)の自動起動設定を行います。
JavaEEUtilityLifecycle
(JavaEEUtilityLifecycle)		 起動 不可    
JMSプロバイダ
(JmsProvider)		 起動 可 業務アプリケーションでJMSを使用していな場合  
CORBAサービス
(CORBAService)		 起動 可 Webコンテナサービスを使用しない場合
EJBを使用しない場合
JNDIサービスを使用しない場合		  
TPモニタマネージャサービス
(TPMonitorManagerService)		 Editionにより異なる 不可   Expressインストール時には停止状態となっており、使用することができません。
Transactionサービス
(TransactionService)		 起動 不可    
Webコンテナサービス
(WebContainerService)		 起動 可 Webアプリケーションを使用していない場合
運用管理コンソールを使用しない場合

このサービスを停止する場合、以下のコマンドを実行して運用管理コンソールを無効化する必要があります。

otxadmin> set system-applications.application.manager.enabled=false
Webサーバサービス
(WebServerService)		 インストール時の選択によって異なる 可 WebOTX Webサーバを使用していない場合
インストール時にアドバンスドモードを選択している場合
(別マシンのWebサーバを利用しない限り、必要となります。)		  

1.2.4. プロセス数・スレッド数の見直し

サーバAPプロセスのプロセス数およびスレッド数を減らすことによりシステム全体のメモリを削減することが出来ます。 それ以上にメモリの節約を必要とする場合はコンポーネントの集約を行うことによりメモリを削減できます。ただし、障害の局所化か難しくなるなどのデメリットもあるので注意が必要です。

1.2.4.1. 設定方法

・ 統合運用管理ツールのプロセスグループの[プロセス制御]-[プロセス数]

・ 統合運用管理ツールのプロセスグループの[スレッド制御]-[スレッド数]

1.2.5. ディスクサイズの節約

ディスクサイズを節約するためにはアプリケーションログのファイルサイズを制限したり、プロセス終了により退避されたアプリケーションログを削除することが有効です。 例えば削除可能なアプリケーションログについては [ログ > WebOTXのログ > Standard上のアプリケーションのログ出力 > サーバアプリケーショントレース採取] に記述しているsaveディレクトリがあります。 但し、ログの削除は障害発生時のプロセスの異常終了の原因究明に支障が出る可能性があるため注意が必要です。

最終更新日から30日(既定値)経ったsaveディレクトリ配下のファイルは、WebOTXシステムの起動後12時間間隔(運用アシスタント機能を使用している場合)、およびWebOTXシステムの停止時に自動的に削除されます。

1.2.5.1. 設定方法

・ 統合運用管理ツールのTPシステムの[システムパラメータ]-[トレースファイルの保存期間]

・ 統合運用管理ツールのプロセスグループの[トレース設定]-[システムトレースファイルの最大サイズ]

1.2.6. エージェントプロセスのメモリ節約STD

Standardで動作するTP モニタは、オペレーション毎にトランザクション等の実行時情報を管理する機能を備えています。あるモジュールが配備されると、TP モニタでは個々のオペレーションを識別するために番号を付与して、内部管理テーブルと状態情報との関連付けを行います。EJB モジュールの場合には、オペレーションがリモートインタフェースのメソッドに該当します。

メソッド識別情報の割り当て範囲を限定することにより、配備処理中に行われる識別情報の生成数を削減し、エージェントプロセスでのメモリ消費量の削減が可能です。

詳しくは、 [統合運用管理ツール(WebOTX Administrator) > アプリケーションの配備]、 [ アプリケーション配備< > 配備チューニング > EJBのメソッド識別情報の割り当て抑止 STD ] を参照してください。

また、EJBのメソッド識別情報の割り当てを抑止する以外にもオペレーションの統計情報を採取しないようにすることでエージェントプロセスでのメモリ消費量を節約できます。 ただし、この場合、運用アシスタントの機能を停止する必要があります。

1.2.6.1. 設定方法

・ 統合運用管理ツールのTPシステムの[オペレーション制御]-[オペレーションの統計情報を採取しない]

・ 統合運用管理ツールのTPシステムの[運用アシスタント]-[運用アシスタント機能を使用する]

1.3. 性能チューニング

サーバAPの性能チューニングについて説明します。

1.3.1. 多重度のチューニング

プロセスグループの適正な多重度を算出するための方法について説明します。

1.3.1.1. 理論的に算出

待ち行列理論を用いた計算により理論値を算出する方法について説明します。まずは以下の値について要件を整理します。

これらを待ち行列理論で計算して必要な多重度Nを求めます。
N=RTs/(Ta(R-Ts))
例えば
Ta=0.1 (10件/秒)
Ts=0.2
R=0.5
とすると
N=0.5*0.2/(0.1*(0.5-0.2))=3.33...
となり要求を満たすには4多重必要ということになります。

1.3.1.2. プロトタイプを用いた算出

本番運用を想定したプロトタイプを動作させ多重度を求める方法について説明します。プロトタイプを用いた測定のほうがより実運用に即した値を求めることが出来ます。

単体評価で算出

平均サービス時間:Tsを1多重で1つのクライアントからアクセスして時間を求めます。その他の値は既存システムもしくはユーザ要件から算出した値を用いて多重度を求めることが出来ます。

負荷評価で確認

実際に平均到着間隔:Taだけの負荷をかけて多重度を変えながらレスポンス時間を確認します。

1.3.1.3. 運用アシスタントの利用

運用アシスタントにより多重度の適正を診断することができます。多重度が多すぎる/少なすぎる場合は統合運用管理ツールなどを通して通知されます。
また運用アシスタントの多重度自動変更機能を利用することにより、システムの稼働状況に合わせて多重度を自動的に変更させることができます。 詳しくは [ TPシステム > 運用アシスタント > 多重度の最適化支援 ] を参照してください。

1.3.2. CPU使用率の確認

応答時間が長い場合はその時のCPU使用率を確認してください。応答時間が長い場合はその時のCPU使用率を確認してください。 プロセスグループの「動作情報」タブの「プロセス情報」で確認できます。CPU情報はオペレーションジャーナルに記録され、統計的に解析することが可能です。
CPU使用率が高い場合はプロセス数やスレッド数を増やしても性能がよくなるとは限らないため、CPU使用率を減らすなどの対策が必要です。

1.3.3. 重要な処理を優先的に実行したい場合の設定

多重度を増やす等の対処をおこなっても、他のプロセスが動作中でCPU時間がなかなか割り当てられない場合などはレスポンス時間が大きくなってしまいます。 プロセスの優先度を指定することにより、高優先度の処理は他のプロセスより優先されるため、CPU負荷が高い状況でも処理投入後即開始することが可能となります。

例えば、以下のように業務特性に合わせた最適な優先度設定が可能です。(※)

処理優先度設定例

処理

優先度

緊急オンライン処理

高

通常オンライン処理

通常(未設定)

バッチ処理

低


さらに、呼び出し処理単位の優先度設定（オペレーション優先度）と組合せて、よりきめ細かな設定が可能です。

プロセス優先度の設定はプロセスグループ単位で行います。 また、オペレーション優先度の設定はオペレーション単位で行います。

(※)優先度を維持するためには優先度を固定化する必要があります。またLinux OSでは優先度を固定することが出来ません。優先度を高く設定しても、実行を続けると優先度が落ちる場合があります。

1.3.4. 性能ネック箇所の特定

性能測定を行なった結果、性能が想定していたより出ない場合、どの部分に問題があるのか特定する方法について説明します。

1.3.4.1. レスポンス時間の把握

実際にどれくらいの実行時間で運用しているかを確認する方法について説明します。レスポンス時間の把握により問題のあるオペレーションを特定することが出来ます。
オペレーションの性能情報は[統計情報]-[ドメイン名]-[アプリケーション]-[アプリケーション名]-[モジュール名]-[インタフェース名]-[オペレーション名]を参照して下さい。
また、レスポンス時間(キュー待ち時間を含む応答時間)の他に、実行時間（キュー待ち時間を含まない処理時間）とCPU時間を確認することで性能ネック箇所を切り分けることができます。性能ネック箇所として疑わしいのは以下の箇所となります。
　レスポンス時間 >> 実行時間 であれば多重度不足
　実行時間 >> CPU時間 であればDBやネットワークなどのバックエンド問題
　実行時間 ≒ CPU時間 であれば業務AP内でのループ

1.3.4.2. キュー滞留数の把握

キュー滞留が発生しているかを確認する方法について説明します。キュー滞留が発生している場合、多重度が不足しておりレスポンス悪化になっている可能性が考えられます。

キュー滞留数の確認方法については [ TPシステム > キュー滞留情報 ] を参照ください。

1.3.4.3. オペレーションジャーナルの活用

オペレーション単位でオペレーションの処理状況(平均時間、最大時間、最小時間、呼び出し回数、平均CPU使用時間(ユーザモード/カーネルモード)、最大CPU使用時間(ユーザモード/カーネルモード)、最小CPU使用時間(ユーザモード/カーネルモード))を確認することができます。これにより問題のあるオペレーションを特定することが出来ます。

オペレーションジャーナルの確認方法については [ TPシステム > 統計情報(オペレーションジャーナル) ] を参照ください。

1.3.4.4. イベントジャーナルの活用

イベントジャーナルを採取してオペレーションの処理の流れを詳細に調べることができます。

イベントジャーナルについては [ TPシステム > 通信情報(イベントジャーナル) ] を参照ください。

1.3.4.5. プロファイリング(Java APのみ)

Javaアプリケーションの場合プロファイリングを行なうことにより、より詳細に問題箇所を特定することが出来ます。

1.3.5. RMI-IIOPの通信で利用するクラスのキャッシュ

EJBアプリケーションやJNDIサーバとの通信で利用するクラスをキャッシュするように設定を変更することで、性能を向上させることができる場合があります。 Webアプリケーションのセッションレプリケーションでは、実装上、JNDIサーバとの通信が行われます。

1.3.5.1. 設定方法
統合運用管理ツールで設定する場合：

次のMOの「Javaプロパティ設定」操作で、PoolClassesプロパティの値にtrueを設定してください。
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[ORBコンフィグ]

運用管理コマンドで設定する場合：

otxadmin> set-orb-java-property PoolClasses true

クラスのキャッシュ機能を利用できる条件の詳細は、 [CORBA通信基盤(Object Broker) > 注意事項(Java) ] を参照してください。

1.4. その他チューニングに関する設定

高負荷になりレスポンスが悪化した場合などに考慮が必要なタイムアウト値や、プロセス起動・停止に必要なタイムアウト値などに関する設定、その他上限設定について説明します。



1.4.1. 起動・停止タイムアウト(メッセージ表示)

プロセスの起動操作、停止操作の完了を待ち合わせる時間を設定します。 タイムアウトした場合はエラーメッセージが表示されます。但し、プロセスの起動処理自体は実行され続けます。

起動・停止タイムアウト一覧(メッセージ表示)

設定項目

説明

既定値

設定値範囲

補足事項

１．システム起動タイムアウト

システムの起動処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

２．システム停止タイムアウト

システムの停止処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

３．アプリケーショングループ起動タイムアウト

アプリケーショングループの起動処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

４．アプリケーショングループ停止タイムアウト

アプリケーショングループの停止処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

５．プロセスグループ起動タイムアウト

プロセスグループの起動処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

６．プロセスグループ停止タイムアウト

プロセスグループの停止処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

設定方法

1. システム起動タイムアウト 
otxadmin> set tpsystem.startTimeOut=120
2. システム停止タイムアウト 
otxadmin> set tpsystem.stopTimeOut=120
3. アプリケーショングループ起動タイムアウト 
otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>.startTimeOut=120
4. アプリケーショングループ停止タイムアウト 
otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>.stopTimeOut=120
5. プロセスグループ起動タイムアウト 
otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.startTimeOut=120
6. プロセスグループ停止タイムアウト 
otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>processGroups.<プロセスグループ名>.stopTimeOut=120

1.4.2. 起動・停止タイムアウト(プロセス終了)

アプリケーションプロセスの起動または停止に長い時間がかかる場合はタイムアウトを検出して異常終了することがあります。この場合、処理時間が妥当か検証し、妥当でないなら処理を見直し、妥当ならタイマ値を見直す必要があります。

起動・停止タイムアウト一覧(プロセス終了)<

設定項目

説明

既定値

設定値範囲

1. スレッド初期化時間

スレッド初期化にかかる時間のタイムアウト値を設定します。

600秒

1-2147483647で秒単位

2. プロセスのストール監視間隔

スレッド初期化前及びスレッド終了後にかかる時間のタイムアウト値を設定します。

600秒

1以上の整数で秒単位

スレッド初期化時間のタイムアウト値は以下の場所で時間のかかる処理を行っている場合に考慮が必要です。

設定を反映させるためにはアプリケーショングループを再起動してください。

また、プロセスのストール監視間隔のタイムアウト値は以下の場所で時間のかかる処理を行っている場合に考慮が必要です。

設定を反映させるためにはTPシステムを再起動してください。

1.4.2.1. 設定方法

  1. スレッド初期化時間

    統合運用管理ツールのプロセスグループの[スレッド制御]-[スレッドの初期化時間の上限]

  2. プロセスのストール監視間隔

    統合運用管理ツールのTPシステムの[上限設定]-[プロセスのストール監視間隔]

1.4.3. 呼び出しタイムアウト

1.4.4. 実行時間タイムアウト

サーバ側のオペレーション実行開始から実行完了までのタイムアウト値を設定します(既定値：600秒)。この値はサーバでの実行時間のみ考慮して設定します(キュー待ち時間は含みません)。

オペレーションの実行をタイムアウトさせる場合は、オペレーションの[実行時間の上限超過時にプロセスを強制停止する]設定にチェックを入れてください。タイムアウト値はオペレーションの[実行時間の上限]で設定できます。いずれもTPシステムに設定した場合は全てのオペレーションに一括設定されます。

なお、実行時間タイムアウト値は運用アシスタントの実行時間の上限の適正値算出機能により推奨値が自動設定されている場合があります。[実行時間の上限超過時にプロセスを強制停止する]にチェックを入れる場合は、実行時間タイムアウト値の設定値が問題ないかを検討して下さい。

これらの設定を変更した場合、予期しない時間で強制停止されることを防ぐために、運用アシスタントの適正値算出機能を停止させます。運用アシスタントに実行時間の上限を自動設定させたい場合は、 再度設定を行ってください。実行時間の上限における適正値算出機能の詳細は [TPモニタ > TPモニタの障害に対する機能 > 運用アシスタント ] の実行時間の上限の適正値算出を参照してください。

なお、実行時間タイムアウト値を超過した場合、プロセスは終了します。プロセスを再起動させるためには再起動回数（統合運用管理ツールのTPシステムの[上限設定]-[プロセス障害時の再起動回数]）を2以上にする必要があります。推奨はデフォルトの5です。プロセス障害時の再起動回数が1でプロセスが終了した場合、プロセスは終了したままで再起動しませんので注意してください。

1.4.4.1. 設定方法

統合運用管理ツールの以下の設定を変更します。
オペレーションの[オペレーション制御]-[実行時間の上限]
オペレーションの[オペレーション制御]-[実行時間の上限超過時にプロセスを強制停止する]

1.4.5. クライアント無通信監視間隔

TPシステム利用時、サーバとクライアントの間、または、WebサーバとAPサーバの間の無通信状態を監視します(既定値：しない)。本タイマ値以上無通信状態(具体的には要求も応答も流れない状態)が続いた場合はコネクションを切断します。設定を反映させるためにはTPシステムの再起動が必要です。

1.4.5.1. 設定方法

統合運用管理ツールの[IIOPリスナ]-[クライアント制御]-[クライアントとの無通信監視を行う]及び[クライアントとの無通信監視間隔]
または
統合運用管理ツールの[AJPリスナ]-[クライアント制御]-[Webサーバとの無通信監視を行う]及び[Webサーバとの無通信監視間隔]

1.4.6. キューイング数上限

サーバアプリケーションすべてのスレッドがクライアントからのリクエスト処理を行なっている場合、新たな要求はキューイングされ実行待ちとなります。既定値ではメモリの許す限りキューイングされてしまい、クライアントから見るとキュー数が増えれば増えるほど無応答時間が長くなります。ある程度以上のキューイングを抑制することによりクライアントのレスポンスを保証することが出来ます。

(平均待ち時間)=(平均サービス時間)*{(キュー数)+1}

1.4.6.1. 設定方法

統合運用管理ツールでプロセスグループ毎に設定できます。

プロセスグループの[キューの最大数]-[リクエストキューのサイズ]

1.4.7. 接続クライアント数上限

IIOPリスナを使ってrichクライアントを動作させる場合、またはAJPリスナを使ってthinクライアントを動作させる場合、想定以上の接続を受けるとサーバ側資源(主にメモリとファイルディスクリプタ)を余分に使います。 接続数に上限を設けることにより設定以上のクライアントから要求を受け付けなくすることが出来ます。ただし接続クライアント数をぎりぎりに設定してしまうとゴーストセッションが残っている場合、 接続できなくなる可能性がありますので、ゴーストセッションの対策をとった上である程度の余裕を持たせてください。 ゴーストセッションの対策については [ 障害解析 > ログ情報から > イベントログ・syslog > クライアント接続数オーバへの対応] を参照してください。

1.4.7.1. 設定方法

統合運用管理ツールの[TPシステム]-[IIOPリスナ]-[上限設定]-[最大同時接続クライアント数]
統合運用管理ツールの[TPシステム]-[AJPリスナ]-[上限設定]-[最大同時リクエスト処理数]

1.4.8. セッションあたりの同時実行数

thinクライアント構成の場合、Webサーバから1つのセッションを通して多重にリクエスト要求が発行されます。 クライアント数やトランザクション処理件数に応じた1セッションあたりの同時実行数を設ける必要があります。 本設定は、IIOPリスナ利用時にのみ有効です。

1.4.8.1. 設定方法

統合運用管理ツールの[TPシステム]-[IIOPリスナ]-[クライアント制御]-[1セッションあたりのリクエスト多重度]

1.4.9. 電文長の長いメッセージの送受信

サーバ側の送受信の上限は設定の有無にかかわらず99,999,998バイト(約100M)となります。

また、クライアントがVBまたはC++の場合、電文の受信最大サイズは8,388,608バイト(8M)となります。クライアント側での受信電文長を10Mまで増やしたい場合はクライアントマシンのレジストリ変更が必要です。

1.4.9.1. 設定方法

レジストリの名前：HKEY_LOCAL_MACHINE\SOFTWARE\NEC\ObjectSpinner\1\MaxMessageSize
属性：文字列属性(REG_SZ)
値  ：0〜4294967295(単位:バイト)
意味：受信可能とする最大サイズを指定します。
補足：送信には関係ありません。

Memo
本バージョンでは、VB/C++のクライアントアプリケーションをサポートしていません。旧バージョン連携時に有効です。

1.4.10. 接続要求最大保留数

クライアントから瞬時に大量の接続要求が来た場合、WebOTX側での接続処理が間に合わずクライアントへエラーが返ってしまうことがあります。このような場合には本パラメータの値を大きくすることにより、接続要求をサーバ側で保留することができます。

1.4.10.1. 設定方法

統合運用管理ツールの[TPシステム]-[IIOPリスナ]-[クライアント制御]-[接続要求最大保留数]
統合運用管理ツールの[TPシステム]-[AJPリスナ]-[クライアント制御]-[接続要求最大保留数]

1.4.11. メモリプールサイズ

クライアントからのCORBAリクエストはメモリプールとして事前に確保した共有メモリ上に受信されます。また、サーバからのCORBA応答もメモリプールに展開された後に送信を行います。これらの領域は、クライアントへの送信が完了した時点で解放されます。
このような管理方式にすることで、外因によらず迅速で確実なバッファ取得ができることになりますが、一方で、このサイズを適当な値に設定する必要があります。
バッファ使用区間はCORBAリクエストの受信から送信までですので、サーバ側でのオペレーションの同時実行数が上がるほどバッファが必要になります(キューイングされているものも含む)。また、リクエストや応答のメッセージサイズが大きいほどバッファが必要になります。
なお、本用途に使用されるバッファ領域はメモリプールサイズ×0.9となります。

必要なメモリプールサイズの最大値は次のとおり計算できます。

(メモリプールサイズの最大値) = (メモリブロック数) * (ブロックサイズ)
(メモリブロック数) = {もっとも大きい電文のサイズ/(ブロックサイズ) + 1} *
　　　　　　　　　　　　　(WebOTXで同時に処理するオペレーション数)
(ブロックサイズ) = 4704 bytes

1.4.11.1. 設定方法

統合運用管理ツールの[TPシステム]-[システムパラメータ/動的情報]-[送受信用共有メモリサイズ]


1.4.12. プロセス障害時の再起動回数

プロセスグループのプロセスが異常終了したとき、自動再起動させる回数を1から55000の範囲の整数で設定します。 1を設定すると、プロセスは再起動しません。全てのプロセスグループに対してこの設定は有効となります。

プロセスグループ単位で、プロセスが自動で再起動する回数は次の計算式の通りです。
(プロセス再起動回数) = (プロセス多重度) × { (プロセス障害時の再起動回数) − 1 }

例えば、(プロセス多重度)が4で(プロセス障害時の再起動回数)を5に設定している場合、 プロセスグループ単位でプロセスは計16回再起動します。 4プロセスの内で特定のプロセスのみが異常終了している場合でも、16回まで自動で再起動します。

なお、[TPシステム]-[上限設定]-[プロセスを正常と仮定する間隔]で設定されている時間内にプロセスの異常終了が起こらなかった場合、プロセス再起動回数はクリアされ、初期値にリセットされます。

1.4.12.1. 設定方法

統合運用管理ツールの[TPシステム]-[上限設定]-[プロセス障害時の再起動回数]

1.4.13. TPシステム(システムパラメータ)

統合運用管理ツールのTPシステム(システムパラメータ)で設定可能なパラメータで、 設定値に対するメモリ使用量の計算式は次のとおりです。

  1. 最大プロセス数
    設定値 * 688byte

  2. 最大コンポーネント数
    最大コンポーネント数の設定値 * 最大プロセス数の設定値 * 8byte

  3. 最大インタフェース数
    最大インタフェース数の設定値 * 最大プロセス数の設定値 * 4byte

  4. 最大オペレーション数
    設定値 * 1016byte

1.4.13.1. 設定方法

統合運用管理ツールの以下の設定を変更します。
[TPシステム]-[システムパラメータ/静的情報]
[TPシステム]-[システムパラメータ/動的情報]

Copyright (C) 1998 - 2020 NEC Corporation. All rights reserved.