5.2.1　J2EEサーバが使用するリソースの見積もり

(a)　基本のスレッド数

次の計算式で算出してください。

• J2EEサーバの場合

  最大スレッド数 = 76＋A＋B＋C＋D＋E＋F＋G＋H＋I＋J＋K＋L＋M＋N＋O＋P＋Q＋R＋S

• バッチサーバの場合

  最大スレッド数 = 73＋D＋E＋F＋G＋H＋I＋O＋P

（凡例）

• A：デプロイ済みのEntity Bean数の合計

• B：Message-driven Beanを使用する場合，Message-driven Beanの最大インスタンス数（複数のMessage-Driven Beanがある場合は合計）^※

  注※　Message-Driven Bean属性ファイルの<pooled-instance><maximum>の値

• C：リモート呼び出しを行う最大EJBクライアント数×2＋各EJBクライアントの最大同時リクエスト数の合計＋1

• D：CORBAネーミングサービスのスレッド数（=クライアントとCORBAネーミングサービス間のコネクション数×2＋同時受け付けリクエスト数＋初期化時に生成されるスレッド数（vbroker.agent.enableLocatorの値がtrueの場合は6，falseの場合は4）＋1）

  ただし，CORBAネーミングサービスをインプロセスで起動（usrconf.propertiesのejbserver.naming.startupModeキーにinprocessを指定）した場合だけ加算する。

• E：同時に使用する最大のデータベースコネクション数

  コネクションプーリング機能を使用している場合は，最大コネクションプール数（Connector属性ファイルで指定するMaxPoolSizeの値。複数のリソースアダプタがある場合は合計）となる。

  コネクションプーリング機能を使用していない場合は，最大同時リクエスト数や1リクエストで使用するコネクション数から求める（1リクエストで1コネクションを使用する場合，最大同時リクエスト数となる）。

• F：JTAトランザクションを使用する場合，最大同時実行トランザクション数（トランザクションタイムアウトが発生したトランザクション一つにつき，1スレッドを使用する。1リクエストが1トランザクションの場合，最大同時リクエスト数となる）

• G：最大コネクションプール数^※（複数のリソースアダプタがある場合は合計）×2

  注※　Connector属性ファイルで指定するMaxPoolSizeの値

• H：コネクションプーリング機能を使用しているリソースアダプタ数

• I：グローバルトランザクションの決着処理，リカバリ処理で使用するスレッド数（グローバルトランザクションを使用している場合，16を加算する）

• J：デプロイ済みのWebアプリケーションの数

• K：J2EEアプリケーションの自動リロード機能で使用するスレッド数

  次のどれかの値を指定する。

  • ejbserver.deploy.context.reload_scope=app，かつ，ejbserver.deploy.context.check_interval=1以上の場合

    展開ディレクトリ形式で開始状態のJ2EEアプリケーション数＋展開ディレクトリ形式で開始状態のJ2EEアプリケーションに含まれるWARの数×2

  • ejbserver.deploy.context.reload_scope=web，かつ，ejbserver.deploy.context.check_interval=1以上の場合

    展開ディレクトリ形式で開始状態のJ2EEアプリケーションに含まれるWARの数×2

  • ejbserver.deploy.context.reload_scope=jsp，かつ，ejbserver.deploy.context.check_interval=1以上の場合

    展開ディレクトリ形式で開始状態のJ2EEアプリケーションに含まれるWARの数

• L：TP1インバウンドアダプタのスレッド数（4＋TP1インバウンドアダプタのプロパティrpc_max_thread_countに指定したスレッド数＋TP1インバウンドアダプタのプロパティtrn_max_thread_countに指定したスレッド数＋TP1インバウンドアダプタと連携するデプロイ済みのMessage-driven Bean（サービス）の数の合計＋TP1インバウンドアダプタのプロパティMaxTPoolSizeに指定した数）

  TP1インバウンド連携機能を利用する場合だけ加算する。このスレッド数は，Connector属性ファイルによって制御できる。先頭で加算している4は，TP1インバウンド連携機能の内部で使用するスレッド数。

• M：非同期Session Bean呼び出し用のスレッドプールの最大数（cosminexus.xmlの<cosminexus-app><ejb-async-props><max-thread-pool-size>の値）の合計

• N：非同期Session Beanを含むJ2EEアプリケーション数の合計×2

• O：リプライ受信専用スレッドを管理するスレッドを起動する設定（vbroker.ce.iiop.ccm.htc.threadStarter=true）の場合，5を加算する。

• P：タイムアウト発生時のコネクションのクローズを抑止する設定（vbroker.ce.iiop.ccm.htc.readerPerConnection=true）の場合，次の値を加算する。

  （リモート呼び出し先のEJBがあるJ2EEサーバの数＋1）×2

  CTMを使用している場合は，さらに次の値を加算する。

  • J2EEアプリケーション単位のスケジューリングをしている場合

    開始しているJ2EEアプリケーション数＋1

  • Stateless Session Bean単位のスケジューリングをしている場合

    スケジューリング対象のStateless Session Beanの数＋1

• Q：NIO HTTPサーバの最大スレッド数（webserver.connector.nio_http.max_threadsの値）

• R：Java Batchで使用する最大スレッド数

  Java Batchを使用するアプリケーションがある場合だけ加算する。

  ejbserver.javaee.batch.executorService.<JNDI名>.maxThreadsの値を指定する。複数のJNDI名を定義している場合は，それらの合計値を指定する。

• S：Concurrency Utilities for Java EEで使用する最大スレッド数

  Concurrency Utilities for Java EEを使用するアプリケーションがある場合だけ加算する。

  次の値の合計値になる。複数のJNDI名を定義している場合は，それらの合計値を指定する。

  • ManagedExecutorServiceの最大スレッド数

    （ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>.maxPoolSizeの値）

  • ManagedScheduledExecutorServiceで同時に実行される最大タスク数

  • ManagedThreadFactoryで同時に生成される最大スレッド数

CORBAネーミングサービスをインプロセスで起動し，HTTP Serverを使用する場合の見積もり例を次の図に示します。

図5‒1　 HTTP Serverを使用する場合のスレッド数の見積もり例

図に示したHTTP Serverを使用する場合のスレッド数の見積もり例を次に示します。

CORBAネーミングサービスをインプロセスで起動しHTTP Serverを使用する場合の計算式

最大スレッド数 = 76＋A＋B＋C＋D＋E＋F＋G＋H＋I＋J＋K＋L＋M＋N＋O＋P＋Q＋R＋S

上記の計算式より算出した結果と設定内容について，次に示します。

最大スレッド数＝76＋0＋0＋1＋5＋72＋72＋144＋2＋0＋2＋0＋0＋0＋0＋0＋0＋100＋0＋0＝474

表5‒13　HTTP Serverを使用する場合のスレッド数の見積もり内容（例）

設定項目	設定する値	説明
A	0	Entity Beanを使用していないため，0を設定します。
B	0	Message-Driven Beanを使用していないため，0を設定します。
C	1	リモート呼び出しは行われていません。また，EJBがWebアプリケーションからのローカル呼び出しの場合，EJB実行でのスレッドは生成されません。
D	4+1	Cと同様にEJBクライアントに関する値は0になります。
E	48+24	−
F	72	1リクエストが1トランザクションとした場合，最大同時リクエスト数であるMaxClientの値を設定します。
G	(48+24)×2	−
H	2	−
I	0	グローバルトランザクションは使用していないため，0を設定します。
J	2	−
K	0	展開ディレクトリ形式ではないため，0を設定します。
L	0	TP1インバウンドアダプタを使用していないため，0を設定します。
M	0	非同期Session Beanを使用していないため，0を設定します。
N	0	非同期Session Beanを使用していないため，0を設定します。
O	0	専用スレッドによる応答電文受信を設定していないため，0を設定します。
P	0	コネクションのクローズの抑止を設定していないため，0を設定します。
Q	100	−
R	0	Java Batchを使用していないため，0を設定します。
S	0	Concurrency Utilities for Java EEを使用していないため，0を設定します。

(b)　JavaVMのオプション指定に応じて使用するスレッド数

JavaVMのオプション指定に応じて，次の計算式で算出してください。Aは，-XX:+UseG1GCオプションを指定している場合だけ加算します。Bは，-XX:+HitachiUseExplicitMemoryオプションを指定した場合だけ加算します。

最大スレッド数 = A＋B

（凡例）

• A：G1GCで使用するスレッド数（-XX:ParallelGCThreadsオプションに指定した値。このオプションの指定を省略した場合は，論理CPU数を基にした-XX:ParallelGCThreadsオプションのデフォルト値。なお，J2EEサーバ起動時の論理CPU数によって決定されるため，起動後に論理CPUの数を変更してもスレッド数は変化しない）

• B：明示管理ヒープ機能で使用するスレッド数（論理CPU数。ただし，論理プロセッサ数が8以上の場合は8。なお，J2EEサーバ起動時の論理CPU数によって決定されるため，起動後に論理CPUの数を変更してもスレッド数は変化しない）

JavaVMのオプションについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の次の個所を参照してください。

• 14.5　Application Serverで指定できるJava HotSpot VMのオプション

• -XX:[+|-]HitachiUseExplicitMemory（明示管理ヒープ機能オプション）

(a)　初期化時に生成されるスレッド数

初期化時に生成されるスレッド数は，usrconf.propertiesのvbroker.agent.enableLocatorキーの値がtrueの場合は6，falseの場合は4です。なお，vbroker.agent.enableLocatorキーは，CTM連携機能を有効（ejbserver.ctm.enabledキーにtrueを指定）にした場合，自動的にtrueが設定されます。

(b)　ワーカスレッド数

ワーカスレッド数は，「同時受け付けリクエスト数＋1」と「クライアントとCORBAネーミングサービス間のコネクション数×2」の合計になります。

ワーカスレッド数に関連するキーを次に示します。

• vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMax

• vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMin

• vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMaxIdle

これらのキーは，usrconf.propertiesのejbserver.naming.exec.argsキーの値として指定します。これらのキーの詳細については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」，およびマニュアル「Borland(R) Enterprise Server VisiBroker(R) プログラマーズリファレンス」を参照してください。

vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMaxキーで最大値を指定している場合のワーカスレッド数は，「このキーで指定した最大値」と「クライアントとCORBAネーミングサービス間のコネクション数」の合計になります。

ただし，vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMinキーでワーカスレッド数の最小値を指定している場合，ワーカスレッド合計数が最小値に満たないときは，最小値がワーカスレッド数となります。

最大値を指定していない場合は，多重度の増加に伴いワーカスレッド数も増加していきます。ただし，ワーカスレッドは，アイドルになってからvbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMaxIdleキー（デフォルト値は300秒）で指定した時間が経過したあとに消滅（30秒の誤差があります）しますので，負荷が下がるとスレッド数も減少します。

ワーカスレッド数の最大値を指定している場合に，スレッド数とワーカスレッドの最大値が同じになったときは，これ以降のリクエスト受け付けはエラー扱いにはしないで，次のように処理を継続します。

• 受信済みのリクエストについては処理を継続します。

• 新規のリクエストはソケットからread()されないで，TCPの受信バッファ，クライアント側の送信バッファで滞留します。TCPのバッファがいっぱいの場合は，クライアント側で送信待ちとなります。

処理中だったワーカスレッドが空きになった（応答を返した）時点で，次のリクエストの受信処理が行われます。