Interstage Web Server Express Interstage Application...

B1WS-1019-01Z0(00)2012年8月

Windows/Solaris/Linux

Interstage Application Server/Interstage Web Server Express

チューニングガイド

まえがき

本書の目的

本書は、運用形態を変更したり、システム規模を変更する場合などに必要な環境設定のチューニングについて説明し

ています。

本書は、Interstage Application Serverの運用を行う方を対象に記述されています。

前提知識

本書を読む場合、以下の知識が必要です。

・ C言語に関する基本的な知識

・ C++言語に関する基本的な知識

・ COBOLに関する基本的な知識

・ Java言語に関する基本的な知識

・インターネットに関する基本的な知識

・オブジェクト指向技術に関する基本的な知識

・分散オブジェクト技術(CORBA)に関する基本的な知識

・リレーショナルデータベースに関する基本的な知識

・使用するOSに関する基本的な知識

本書の構成

本書は以下の構成になっています。

第1章必要資源

Interstageの運用時に必要な資源について説明します。

第2章 Interstageのチューニング

Interstageのモデルケースから、より詳細なシステム構築を行う場合に必要となるチューニングについて説明します。

第3章システムのチューニング

システムのチューニングについて説明しています。

第4章ワークユニットのチューニング

ワークユニットのチューニングについて説明しています。

第5章 Java EE機能のチューニング

Java EE機能を運用する際のチューニングについて説明しています。

第6章 J2EEのチューニング

J2EEアプリケーションの動作に必要なチューニングについて説明します。

第7章業務構成管理機能のチューニング

業務構成管理機能が管理するリポジトリのチューニングについて説明します。

第8章 JDK/JREのチューニング

JDK/JREのチューニングに関して、基本的な知識、Java VM、異常発生時の原因振り分け方法およびチューニング方

法について説明します。

第9章データベース連携サービスのチューニング

データベース連携サービスのiniファイルについて説明します。

付録A CORBAサービスの動作環境ファイル

CORBAサービスの環境定義について説明しています。

付録B コンポーネントトランザクションサービスの環境定義

コンポーネントトランザクションサービスの環境定義について説明しています。

- i -

付録C データベース連携サービスの環境定義

データベース連携サービスの環境定義について説明しています。

付録D イベントサービスの環境定義

イベントサービスの環境定義について説明しています。

付録E Interstage HTTP Serverの環境定義

Interstage HTTP Serverの環境定義について説明します。

付録F Interstage シングル・サインオンの環境定義

Interstage シングル・サインオンを運用するための、環境定義のチューニングについて説明します。

付録G マルチサーバ管理の環境定義

マルチサーバ管理の環境定義について説明します。

付録H Portable-ORBの環境設定

Portable-ORBの環境設定について説明します。

付録I Webサーバ(Sun Java System Web Server)の環境定義

Webサーバ(Sun Java System Web Server)を使用する場合の環境定義について説明します。

製品名称の略称について

本マニュアルでは、以下の製品名称を略称で表記している箇所があります。

略称製品名称

EE Interstage Application Server Enterprise Edition

SJE Interstage Application Server Standard-J Edition

WS Interstage Web Server Express

輸出許可

本ドキュメントを非居住者に提供する場合には、経済産業大臣の許可が必要となる場合がありますので、ご注意くださ

い。

著作権

Copyright 2012 FUJITSU LIMITED

2012年8月初版

- ii -

目　次

第1章必要資源.........................................................................................................................................................................11.1 運用時に必要なディスク容量.............................................................................................................................................................1

1.1.1 サーバ機能を使用する場合........................................................................................................................................................11.1.2 マルチサーバ管理を使用する場合...........................................................................................................................................211.1.3 MQ連携サービスを使用する場合.............................................................................................................................................221.1.4 クライアント機能を使用する場合...............................................................................................................................................22

1.2 メモリ容量...........................................................................................................................................................................................231.2.1 サーバ機能を使用する場合......................................................................................................................................................231.2.2 マルチサーバ管理を使用する場合...........................................................................................................................................351.2.3 クライアント機能を使用する場合...............................................................................................................................................35

第2章 Interstageのチューニング..............................................................................................................................................362.1 想定するシステム形態(Java EE).......................................................................................................................................................362.2 想定するシステム形態（マルチ言語サービス）................................................................................................................................372.3 定義ファイルの設定値......................................................................................................................................................................382.4 チューニング方法(Java EE)..............................................................................................................................................................412.5 チューニング方法(マルチ言語サービス).........................................................................................................................................42

2.5.1 アプリケーション追加によるチューニング..................................................................................................................................422.5.1.1 クライアントアプリケーションを追加した場合......................................................................................................................422.5.1.2 サーバアプリケーションを追加した場合.............................................................................................................................422.5.1.3 クライアント、サーバ兼用アプリケーションを追加した場合................................................................................................43

2.5.2 Interstage機能を使用するためのチューニング.........................................................................................................................442.5.2.1 データベース連携サービス.................................................................................................................................................442.5.2.2 ロードバランス......................................................................................................................................................................452.5.2.3 イベントサービス..................................................................................................................................................................452.5.2.4 サーバマシン状態監視.......................................................................................................................................................47

2.6 環境変数について............................................................................................................................................................................482.7 IPv6環境での運用について.............................................................................................................................................................492.8 ホスト情報(IPアドレス/ホスト名)の変更方法について......................................................................................................................53

第3章システムのチューニング.................................................................................................................................................543.1 サーバ機能運用時に必要なシステム資源......................................................................................................................................54

3.1.1 CORBAサービスのシステム資源の設定...................................................................................................................................573.1.2 コンポーネントトランザクションサービスのシステム資源の設定...............................................................................................653.1.3 データベース連携サービスのシステム資源の設定..................................................................................................................693.1.4 イベントサービスのシステム資源の設定...................................................................................................................................733.1.5 J2EE互換のシステム資源の設定..............................................................................................................................................783.1.6 Interstage HTTP Serverのシステム資源の設定.........................................................................................................................783.1.7 MessageQueueDirectorのシステム資源の設定.........................................................................................................................803.1.8 Interstage シングル・サインオンのシステム資源の設定............................................................................................................823.1.9 Interstage ディレクトリサービスのシステム資源の設定..............................................................................................................853.1.10 Interstage管理コンソールのシステム資源の設定....................................................................................................................923.1.11 Interstage統合コマンドのシステム資源の設定........................................................................................................................923.1.12 Webサーバコネクタのシステム資源の設定.............................................................................................................................94

3.2 マルチサーバ管理機能を使用する時に必要なシステム資源........................................................................................................973.3 性能監視ツール使用時に必要なシステム資源...............................................................................................................................97

3.3.1 システム構成情報の見積もり方法 (Solarisの場合) ..................................................................................................................973.3.2 システム構成情報の見積もり方法 (Linuxの場合) ...................................................................................................................983.3.3 共有メモリ量の見積もり方法......................................................................................................................................................99

3.4 TCP/IPパラメタのチューニング.........................................................................................................................................................993.5 IPC資源のカスタマイズ...................................................................................................................................................................101

第4章ワークユニットのチューニング.......................................................................................................................................1034.1 ワークユニット数、オブジェクト数、プロセス数のチューニング......................................................................................................1034.2 プロセス強制停止時間のチューニング..........................................................................................................................................104

- iii -

4.3 CORBAワークユニットのチューニング...........................................................................................................................................1054.4 IJServerワークユニットのチューニング............................................................................................................................................1054.5 トランザクションアプリケーションのチューニング............................................................................................................................1054.6 ラッパーワークユニットのチューニング...........................................................................................................................................1054.7 ユーティリティワークユニットのチューニング..................................................................................................................................106

第5章 Java EE機能のチューニング........................................................................................................................................1075.1 Interstage Java EE DASサービスのチューニング...........................................................................................................................1075.2 Interstage Java EE Node Agentサービスのチューニング...............................................................................................................1105.3 IJServerクラスタのチューニング......................................................................................................................................................111

5.3.1 複数プロセス運用.....................................................................................................................................................................1115.3.2 Java VMのヒープ領域サイズ/Perm領域サイズ.......................................................................................................................1115.3.3 ガーベジコレクション発生回数................................................................................................................................................1125.3.4 アプリケーション大処理時間................................................................................................................................................1125.3.5 グループ管理サービスの設定.................................................................................................................................................112

5.4 Interstage Java EE管理コンソールのチューニング.........................................................................................................................1135.4.1 セッションタイムアウト................................................................................................................................................................1135.4.2 アップロードファイルの大サイズのチューニング.................................................................................................................1145.4.3 ポート番号................................................................................................................................................................................1155.4.4 SSL通信の利用........................................................................................................................................................................115

5.5 配備時のチューニング....................................................................................................................................................................1165.6 Webコンテナのチューニング..........................................................................................................................................................1165.7 セッションリカバリ機能のチューニング............................................................................................................................................1205.8 EJBコンテナのチューニング...........................................................................................................................................................122

5.8.1 スレッドプーリング.....................................................................................................................................................................1225.8.2 Enterprise Beanインスタンスのキャッシング.............................................................................................................................1255.8.3 Enterprise Beanインスタンスのプーリング................................................................................................................................1275.8.4 同一Java VM内のリモートアクセスでデータコピーを防ぐ機能..............................................................................................128

5.9 JPAのチューニング.........................................................................................................................................................................1285.9.1 永続性コンテキストキャッシュ...................................................................................................................................................1285.9.2 永続性ユニットの共有キャッシュ..............................................................................................................................................130

5.10 Webサービスのチューニング........................................................................................................................................................1335.11 データベース連携環境のチューニング........................................................................................................................................133

5.11.1 プール内の接続数.................................................................................................................................................................1335.11.2 接続検証................................................................................................................................................................................1355.11.3 トランザクション管理...............................................................................................................................................................1375.11.4 詳細属性................................................................................................................................................................................137

5.12 コネクタのチューニング.................................................................................................................................................................1385.12.1 プール内の接続数.................................................................................................................................................................1395.12.2 接続検証................................................................................................................................................................................1405.12.3 トランザクション管理...............................................................................................................................................................1425.12.4 シャットダウンタイムアウト.......................................................................................................................................................142

5.13 トランザクションサービスのチューニング......................................................................................................................................1425.14 ORBのチューニング......................................................................................................................................................................143

5.14.1 ORB........................................................................................................................................................................................1435.14.2 通信データサイズに関する注意事項....................................................................................................................................146

5.15 予兆監視機能から警告が通知された場合の対処......................................................................................................................1475.15.1 予兆監視警告メッセージ(Javaヒープ)...................................................................................................................................1485.15.2 予兆監視警告メッセージ(ガーベジコレクション)...................................................................................................................149

5.16 Interstage Java EE DASサービスのヒープ領域サイズとアドレス空間..........................................................................................1525.17 時間監視機能の相関関係............................................................................................................................................................1555.18 モニタリング情報の監視................................................................................................................................................................159

5.18.1 注意事項................................................................................................................................................................................1605.19 モニタロギング...............................................................................................................................................................................160

5.19.1 モニタロギングの操作手順....................................................................................................................................................1615.19.2 モニタロギングのログファイル................................................................................................................................................1635.19.3 性能情報の分析.....................................................................................................................................................................165

- iv -

5.20 プロファイラ設定............................................................................................................................................................................1755.20.1 プロファイラ設定の運用方法.................................................................................................................................................175

第6章 J2EEのチューニング....................................................................................................................................................178

第7章業務構成管理機能のチューニング................................................................................................................................1797.1 リポジトリのチューニング.................................................................................................................................................................179

第8章 JDK/JREのチューニング..............................................................................................................................................1808.1 基礎知識.........................................................................................................................................................................................180

8.1.1 JDK関連のドキュメント.............................................................................................................................................................1808.1.2 Java VM....................................................................................................................................................................................1818.1.3 FJVM........................................................................................................................................................................................1828.1.4 仮想メモリと仮想アドレス空間..................................................................................................................................................1828.1.5 スタック......................................................................................................................................................................................1848.1.6 Javaヒープとガーベジコレクション............................................................................................................................................1858.1.7 FJVMに対して指定可能なチューニング用オプション...........................................................................................................1878.1.8 Java Native Interface(JNI)........................................................................................................................................................188

8.2 ガーベジコレクション(GC)...............................................................................................................................................................1898.2.1 FJVMでサポートされるガーベジコレクション処理..................................................................................................................1898.2.2 標準GC（シリアルGC）..............................................................................................................................................................1928.2.3 New世代領域用制御処理並列化機能付きGC（パラレルGC）..............................................................................................1928.2.4 コンカレント・マーク・スイープGC付きパラレルGC（CMS付きパラレルGC）..........................................................................1958.2.5 オブジェクト参照の圧縮機能...................................................................................................................................................1988.2.6 ガーベジコレクションのログ出力..............................................................................................................................................199

8.2.6.1 ガーベジコレクション処理の結果ログ出力機能の強化...................................................................................................2018.3 動的コンパイル................................................................................................................................................................................206

8.3.1 コンパイラ異常発生時の自動リカバリ機能..............................................................................................................................2078.3.2 長時間コンパイル処理の検出機能.........................................................................................................................................2088.3.3 動的コンパイル発生状況のログ出力機能..............................................................................................................................210

8.4 チューニング方法............................................................................................................................................................................2128.4.1 Javaヒープのチューニング.......................................................................................................................................................2128.4.2 スタックのチューニング.............................................................................................................................................................2178.4.3 暖機運転..................................................................................................................................................................................218

8.5 チューニング/デバッグ技法............................................................................................................................................................2218.5.1 スタックトレース.........................................................................................................................................................................221

8.5.1.1 スタックトレースの解析方法(その1)..................................................................................................................................2228.5.1.2 スタックトレースの解析方法(その2)..................................................................................................................................2238.5.1.3 スタックトレースの解析方法(その3)..................................................................................................................................224

8.5.2 例外発生時のスタックトレース出力.........................................................................................................................................2258.5.3 スレッドダンプ...........................................................................................................................................................................2268.5.4 クラスのインスタンス情報出力機能..........................................................................................................................................2348.5.5 java.lang.System.gc()実行時におけるスタックトレース出力機能............................................................................................2358.5.6 Java VM終了時における状態情報のメッセージ出力機能.....................................................................................................2368.5.7 ログ出力における時間情報のフォーマット指定機能..............................................................................................................2378.5.8 FJVMログ..................................................................................................................................................................................237

8.5.8.1 異常終了箇所の情報........................................................................................................................................................2388.5.8.2 異常終了時のシグナルハンドラ情報 ..............................................................................................................................2398.5.8.3 異常終了時のJavaヒープに関する情報...........................................................................................................................2408.5.8.4 出力例と調査例.................................................................................................................................................................240

8.5.9 クラッシュダンプ・コアダンプ....................................................................................................................................................2438.5.9.1 クラッシュダンプ.................................................................................................................................................................2438.5.9.2 コアダンプ（Solaris）...........................................................................................................................................................2448.5.9.3 コアダンプ（Linux）............................................................................................................................................................244

8.5.10 JNI処理異常時のメッセージ出力..........................................................................................................................................2458.6 異常発生時の原因振り分け...........................................................................................................................................................248

8.6.1 java.lang.OutOfMemoryErrorがスローされた場合..................................................................................................................2488.6.1.1 メモリ領域不足事象発生時のメッセージ出力機能の強化..............................................................................................250

- v -

8.6.2 EXTP4435メッセージまたはISJEE_OM1018メッセージが出力された場合...........................................................................2518.6.3 java.lang.StackOverflowErrorがスローされた場合.................................................................................................................254

8.6.3.1 スタックオーバーフロー検出時のメッセージ出力機能....................................................................................................2548.6.4 SIGBUS発生により異常終了した場合....................................................................................................................................2558.6.5 プロセスが消滅(異常終了)した場合.......................................................................................................................................2568.6.6 ハングアップ(フリーズ)した場合..............................................................................................................................................2578.6.7 スローダウンが発生した場合...................................................................................................................................................258

8.7 Javaツール機能...............................................................................................................................................................................258

第9章データベース連携サービスのチューニング....................................................................................................................2609.1 データベース連携サービスのiniファイル設定情報.......................................................................................................................2609.2 iniファイルの設定例........................................................................................................................................................................2619.3 セマフォ資源...................................................................................................................................................................................2629.4 Windows(R)固有パラメタ................................................................................................................................................................262

付録A CORBAサービスの動作環境ファイル...........................................................................................................................263A.1 config..............................................................................................................................................................................................264A.2 gwconfig.........................................................................................................................................................................................282A.3 inithost/initial_hosts........................................................................................................................................................................284A.4 queue_policy...................................................................................................................................................................................286A.5 nsconfig...........................................................................................................................................................................................287A.6 irconfig............................................................................................................................................................................................289

付録B コンポーネントトランザクションサービスの環境定義......................................................................................................293B.1 記述形式.........................................................................................................................................................................................293

B.1.1 ステートメント............................................................................................................................................................................293B.1.2 セクション..................................................................................................................................................................................295B.1.3 コメント行..................................................................................................................................................................................296B.1.4 空行..........................................................................................................................................................................................296

B.2 環境定義ファイルの制御文............................................................................................................................................................296B.2.1 [SYSTEM ENVIRONMENT]セクション.................................................................................................................................296B.2.2 [WRAPPER]セクション ...........................................................................................................................................................298

付録C データベース連携サービスの環境定義........................................................................................................................300C.1 configファイル.................................................................................................................................................................................300C.2 セットアップ情報ファイル................................................................................................................................................................305

C.2.1 MODE: セットアップ種別.........................................................................................................................................................305C.2.2 LOGFILE: システムログファイルのパス..................................................................................................................................306C.2.3 TRANMAX: 大トランザクション多重度..............................................................................................................................307C.2.4 PARTICIPATE: 1トランザクションに参加するリソース数.......................................................................................................308C.2.5 OTS_FACT_THR_CONC: OTSシステムのスレッド多重度...................................................................................................308C.2.6 OTS_RECV_THR_CONC: リカバリプロセスのスレッド多重度..............................................................................................308C.2.7 JTS_RMP_PROC_CONC: JTS用のリソース管理プログラムのプロセス多重度....................................................................308C.2.8 JTS_RMP_THR_CONC: JTS用のリソース管理プログラムのスレッド多重度........................................................................309C.2.9 HOST: OTSシステムが動作するホスト名................................................................................................................................309C.2.10 PORT: OTSシステムが動作するホストのCORBAサービスのポート番号............................................................................309

C.3 RMPプロパティ...............................................................................................................................................................................310C.4 リソース定義ファイル.......................................................................................................................................................................311C.5 OTSシステム用業務システム情報定義ファイル............................................................................................................................316C.6 アプリケーション用業務システム情報定義ファイル.......................................................................................................................316

付録D イベントサービスの環境定義........................................................................................................................................318D.1 traceconfig.......................................................................................................................................................................................318D.2 サプライヤ・コンシューマ総数の見積もり方法...............................................................................................................................321

付録E Interstage HTTP Serverの環境定義...........................................................................................................................322E.1 タイムアウト時間..............................................................................................................................................................................322E.2 クライアントの同時接続数...............................................................................................................................................................324

- vi -

付録F Interstage シングル・サインオンの環境定義.................................................................................................................326F.1 1台のサーバにリポジトリサーバを構築する場合のチューニング..................................................................................................326F.2 1台のサーバに認証サーバを構築する場合のチューニング........................................................................................................327F.3 1台のサーバにリポジトリサーバと認証サーバを構築する場合のチューニング...........................................................................328F.4 業務サーバを構築する場合のチューニング.................................................................................................................................329

付録G マルチサーバ管理の環境定義.....................................................................................................................................331G.1 マルチサーバ管理定義ファイル....................................................................................................................................................331

付録H Portable-ORBの環境設定..........................................................................................................................................332

付録I Webサーバ(Sun Java System Web Server)の環境定義..............................................................................................333

索引......................................................................................................................................................................................334

- vii -

第1章必要資源

1.1 運用時に必要なディスク容量

運用時に必要なディスク容量は次のとおりです。

1.1.1 サーバ機能を使用する場合

Interstageの各機能の運用時に必要となるディスク容量について説明します。

以下の表を参照し、使用する製品に応じて、各機能のディスク容量を見積もってください。表内で使用している略称につ

いては、「製品名称の略称について」を参照してください。

EE SJE WS

Interstage動作環境 ○ ○ ×

Interstage管理コンソール ○ ○ ○

業務構成管理 ○ ○ ○

Interstage HTTP Server ○ ○ ○

Interstage JMXサービス ○ ○ ○

Interstage シングル・サインオン ○ ○ ○

(注)

Interstage ディレクトリサービス ○ ○ ×

J2EE ○ ○ ×

IJServerワークユニット ○ ○ ×

Interstage JMS ○ ○ ×

Servletサービス(OperationManagement) ○ ○ ○

ワークユニット ○ ○ ×

CORBAサービス ○ ○ ○

イベントサービス ○ ○ ×

Portable-ORB ○ ○ ×

コンポーネントトランザクションサービス ○ ○ ○

データベース連携サービス ○ ○ ×

ロードバランス ○ × ×

性能監視ツール ○ ○ ×

MessageQueueDirector ○ × ×

フレームワーク ○ ○ ×

Java EE ○ ○ ○

○:該当製品で提供される機能です。

×:該当製品で提供されない機能です。

注) Interstage シングル・サインオンの業務サーバだけでディスク容量を見積もります。

機能: Interstage動作環境

- 1 -

ディレクトリディスク容量

(単位:Mバイト)備考(用途)

コンポーネントトランザクションサービ

スのインストールディレクトリ\var\td001(Interstage動作環境定義ファイルの

“TD path for system”で指定)

60 以上 Interstage動作環境作

成時

機能: Interstage管理コンソール



Interstage管理コンソールのインストー

ルディレクトリ\isAdmin\var\download

/var/opt/FJSVisgui/tmp/download

(注) ログ情報

注) Interstage管理コンソールの以下の画面において、ログファイルをダウンロードする場合、同時にダウンロードするロ

グファイルのサイズ分のディスク容量が一時的に必要となります。

機能画面(スタンドアロン)

Interstage HTTP Server [システム] > [サービス] > [Webサーバ] > [Webサーバ

名] > [ログ参照]タブ

[システム] > [サービス] > [Webサーバ] > [Webサーバ

名] > [バーチャルホスト] > [バーチャルホスト名] > [ログ

参照]タブ

Webサーバコネクタ [システム] > [サービス] > [Webサーバ] > [Webサーバ

名] > [Webサーバコネクタ] > [ログ参照]タブ

IJServerワークユニット

[システム] > [ワークユニット] > [ワークユニット名] > [ログ

参照]タブ

ログファイルのサイズについては、各機能のログ情報のディスク容量を参照し、運用の内容により必要とするサイズ

を検討してください。

なお、ログファイルのサイズが大きいため、ディスク容量の不足によりログファイルのダウンロードに失敗する場合は、

FTPなどを使用してダウンロードしてください。

機能: 業務構成管理



業務構成管理のリポジトリ

Interstage JMXサービスのインストー

ルディレクトリ\var\repository

/var/opt/FJSVisas/repository

運用の内容により、必

要とするサイズを検討

してください。 (注)

デフォルトから変更した

場合は、変更先

注) 業務構成管理のリポジトリの格納先のサイズは、“Interstage Application Server 運用ガイド(基本編)”の“業務構成管

理機能”を参照してください。

機能: Interstage HTTP Server

- 2 -



アクセスログ、エラーログ、トレースログ

格納ディレクトリ



してください。

アクセスログ、エラーロ

グ、トレースログ

Interstage HTTP Serverのインストール

ディレクトリ\var\opelog

/var/opt/FJSVihs/var/opelog

2 オペレーションログ

Interstage HTTP Serverのインストール

ディレクトリ\var\.ihsapi

/var/opt/FJSVihs/var/.ihsapi

10 保守ログ

コンテンツ格納するディレクトリ運用の内容により、必



コンテンツ(HTML文書

など)

機能: Interstage JMXサービス



Interstage JMXサービスのインストー

ルディレクトリ

14以上 (注)



/var/opt 14 以上 (注)

/var/opt 32 以上 (注)

/etc/opt 0.1 以上

注) Interstage JMXサービスのカスタマイズでログインログのファイルサイズの上限値を変更している場合、以下のディス

ク所要量が必要となります。

－ログインログ

ログインログのファイルサイズの上限値 × 2 (Mバイト)

上限値を変更していない場合、ログインログのファイルサイズの上限値は1に設定されています。

機能: Interstage シングル・サインオン

Interstage シングル・サインオンの業務サーバ機能



Interstage シングル・サインオンのイ

ンストールディレクトリ\ssoatzag\log

/var/opt/FJSVssoaz/log



してください。 (注1)

アクセスログなどのログ

情報

(アクセスログファイルの

出力先ディレクトリ)

- 3 -




ンストールディレクトリ\ssocm\etc

/var/opt/FJSVssocm/etc

2


ンストールディレクトリ

/etc/opt




アクセス制御情報

Interstage シングル・サインオンの認証サーバ機能




ンストールディレクトリ\ssoatcag\log

/var/opt/FJSVssoac/log





情報

(アクセスログファイルの

出力先ディレクトリ)


ンストールディレクトリ\ssofsv\log

/var/opt/FJSVssofs/log



してください。 (注1)(注2)




2 (注3)(注4)

Interstage シングル・サインオンのリポジトリサーバ機能




ンストールディレクトリ\ssoatcsv\log

/var/opt/FJSVssosv/log



してください。 (注1)(注5)


情報

(アクセスログファイル、

およびセション管理ロ

グファイルの出力先

ディレクトリ)




2

注1) デフォルト設定のままでは使用ディスクサイズの上限なしにログが採取されます。ディスク不足発生を防止するため

に、定期的に不要になったログファイルを削除するか、ログの採取方法を変更してください。

注2) 認証サーバ間連携を行わない場合は、0Mバイトです。

- 4 -

注3) 統合Windows認証を行う場合には、2Mバイトを加算してください。

注4) 認証サーバ間連携を行う場合には、2Mバイトを加算してください。

注5) セション管理を行うリポジトリサーバをクラスタシステム上で運用する場合には、52Mバイトを加算してください。

機能: Interstage ディレクトリサービス



Interstage ディレクトリサービスのイン

ストールディレクトリ\var

/var/opt

20 × リポジトリ作成数

＋ 20ログ情報

Interstage ディレクトリサービスのイン

ストールディレクトリ\etc

/etc/opt

0.5 × リポジトリ作成数環境定義

Interstage ディレクトリサービスのアク

セスログ作成ディレクトリ

Interstage管理コンソー

ルのアクセスログの設

定値に依存

サイズ × 世代管理数

アクセスログ

Interstage ディレクトリサービスのデー

タベース格納先ディレクトリ

(注1) データベース格納先

(リポジトリのデータベー

スとして標準データ

ベースを使用する場

合)

Interstage ディレクトリサービス SDKの

インストールディレクトリ\var

/var/opt/FJSVirepc

プロセス数 × 8

同時接続数 × 8 (注2)

Interstage ディレクトリ

サービス SDKのログ情

報

注1) 1つのリポジトリあたりで、以下のディスク所要量が必要です。

－レプリケーション環境のマスタのリポジトリ

0.2 × n × s ÷ 500 ＋ 200

－上記以外

0.1 × n × s ÷ 500 ＋ 200

n: エントリ数

s: 1エントリをLDIFで記述したときのサイズ(単位:バイト)

計算式は目安です。ディスク容量は十分に余裕を持たせてください。

データベース格納先に指定したディスク領域が不足すると、メッセージirep30023を表示し、リポジトリを強制終了しま

す。メッセージirep30023の対処は、“メッセージ集”の“メッセージ番号がirepで始まるメッセージ”を参照してください。

注2) 同時接続数には、以下の必要数の総和を指定して見積もってください。

－スレッド多重のアプリケーションを使用してリポジトリにアクセスする場合の、アプリケーションのプロセス数

－プロセス多重のアプリケーションを使用してリポジトリにアクセスする場合の、アプリケーションのプロセス多重度

- 5 -

－ Interstage シングル・サインオン機能を使用する場合の、Interstage シングル・サインオンのリポジトリサーバ機能を

組み込んだWebサーバのクライアント同時接続数

機能: J2EE



J2EE共通ディレクトリ

/var/opt/FJSVj2ee/deployment




J2EEアプリケーション

の資産一式

機能: IJServerワークユニット



J2EE共通ディレクトリ\ijserver\IJServer名\logディレクトリ

J2EE共通ディレクトリ/ijserver/IJServer名/logディレクトリ

24 以上 (注1)

Interstageのインストールディレクトリ

\F3FMjs5\logs\jk2

/var/opt/FJSVjs5/logs/jk2

2 以上 (注2)

J2EE共通ディレクトリ\ijserver\Session Registry Server(IJServer)名\apps\srs.ear\srs.war\serializedata\sessionrecovery

J2EE共通ディレクトリ/ijserver/SessionRegistry Server(IJServer)名/apps /srs.ear/srs.war/serializedata/sessionrecovery

(注3) Servletサービスのセ

ションリカバリ機能使用

時

セションの永続化有効

時、Session RegistryServerを運用する環境

で必要です。

注1) IJServerワークユニット1つにつき以下を加算してください。

プロセス多重度 ×4(コンテナログとコンテナ情報ログのデフォルトディスク使用量) ×6(世代分のバックアップ) 以上

アプリケーションのタイムアウトが多発する場合、アプリケーションで短時間に大量のメッセージを出力する場合、お

よびデバッグ情報出力を行う場合は、“J2EE共通ディレクトリ/ijserver/IJServer名/log”配下のコンテナ情報ログのディ

スク使用量が大きくなります。このような操作が想定される場合は、十分なディスク容量をご用意ください。

注2) Webサーバ1つにつきデフォルトで2Mバイトです。アプリケーションで短時間に大量のメッセージを出力する場合、

デバッグ情報出力を行う場合は、ディスク使用量が大きくなります。このような操作が想定される場合は、十分なディ

スク容量をご用意ください。

注3) セションリカバリ機能を使用して、セションの永続化を有効にした場合は、Session Registry Server環境定義ファイル

で指定したセションの永続化ファイルの保存先にセションの永続化ファイルが生成されます。配備するWebアプリケー

ション1つについて、次のディスク容量が必要です。(単位:Mバイト)

- 6 -

(0.005 ＋ (0.005 ＋セションの保持するデータ容量) × セション数) × 2



“セションの保持するデータ容量”は、Webアプリケーションでセションの属性(Attribute)にセットするオブジェクトおよ

びキーのサイズの合計値です。

上記の値は、利用しているファイルシステムによっては値が増減する場合があります。

なお、Session Registry Serverは、Interstage Application Server Enterprise Editionで運用可能です。

機能: Interstage JMS



Interstage JMSのインストールディレク

トリ\etc

/etc/opt

0.01 ＋(durable Subscriber数× 0.002)

定義情報

Interstage JMSのインストールディレク

トリ\var

/var/opt

10 以上コンソールファイル

機能: Servletサービス(OperationManagement)



Servletサービス

(OperationManagement)インストール

ディレクトリ\log

/var/opt/FJSVjs2su/log

12 ログ情報

機能: ワークユニット



Interstage動作環境定義の定義項目

“TD path for system”で指定

1つのワークユニット定

義サイズ × ワークユ

ニット定義数 (注)

ワークユニット定義登録

時

1つのワークユニット定

義サイズ × ワークユ

ニット起動数 (注)

ワークユニット運用時

注) 1つのワークユニット定義サイズ＝

1000 ＋(500 × “[Application Program]セクション定義数”) ＋(500 × “[Resource Manager]セクション定義数”) ＋(500 × “[Nonresident Application Process]セクション定義数”) ＋(500 × “[Multiresident Application Process]セクション定義数”) ＋ユーザ任意指定文字列データ長

- 7 -

機能: CORBAサービス

Interstage Application Server Standard-J Editionの場合

Interstage Application Server Enterprise Editionの場合



CORBAサービスのインストールディ

レクトリ\etcフォルダ

/etc/opt

0.1 以上インプリメンテーション

情報、ネーミングサー

ビス、インタフェースリ

ポジトリのデータサイズ

に依存します。

4.1 以上 (注1) ネーミングサービス情

報


レクトリ\varフォルダ

/var/opt

8 以上

42.0

24.0(デフォルト時の大サ

イズ) (注2)

ログ情報

2.0 以上 (注3) 内部ログ採取時(プレイ

ンストール型Javaライブ

ラリ以外の場合)

4.0 以下 (注1) ネーミングサービスの

ユーザ例外ログ情報

4.0 以下 (注1) ネーミングサービスの

実行トレース情報(サー

ビス動作時のみ)

32.3 以下インタフェースリポジトリ

サービスのログ情報

(サービス動作時のみ)


レクトリ\var\traceフォルダ

/var/opt/FSUNod/trace

/var/opt/FJSVod/trace

10.4 (注4) トレース情報


スインストールディレクトリ\var\IRDB


スインストールディレクトリ/var/IRDB(Interstage統合コマンド使用時のデ

フォルト)

10.3 以上 (注5) インタフェースリポジトリ

サービス情報

/tmp

1.0 以上

IDL定義の量に依存

C/C++コンパイラ動作

時には、別途作業用の

ディスク容量が必要

IDLコンパイラ動作時

- 8 -



Java VMのシステムプロパティの

user.dirで指定

(注6) 内部ログ採取時(プレイ


ラリの場合)

環境変数OD_HTTPGW_HOMEまた

はOD_HOMEで指定されたvarディレ

クトリ

2.0 以上 (注7) HTTP-IIOPゲートウェ

イの内部ログ採取時

Interstage Web Server Expressの場合




レクトリ\varフォルダ

/var/opt

8.0 以上

42.0

24.0(デフォルト時の大サ

イズ) (注2)

ログ情報

2.0 以上 (注3) 内部ログ採取時(プレイ


ラリ以外の場合)


レクトリ\var\traceフォルダ

/var/opt/trace

10.4 (注4) トレース情報


user.dirで指定

(注6) 内部ログ採取時(プレイ


ラリの場合)

注1) CORBAサービスのサーバマシンにネーミングサービスを構築する場合に、必要となるディスク容量について以下に

示します。

－ディスク容量

用途容量

ネーミング

サービス情

報

オブジェクトリポジト

リ

(固定)16Kバイト

制御ファイル (固定)2056Kバイト

データファイル (可変)2048(Kバイト) × コンテキスト数＋(オブジェクトリファレンス長 × オブジェク

ト数 × 2)

実行トレース情報 ( 大)4096Kバイト

ユーザ例外ログ情報 ( 大)4096Kバイト

- 9 -

注2) CORBAサービスのログ採取機能を使用している場合、大で以下のディスク容量を使用します。(各パラメタはconfigファイルで定義)

access_log_size × 2 ＋ error_log_size × 2 ＋ process_log_size × 2 ＋ info_log_size × 2

Windowsでは、上記に加えてさらに以下のディスク容量を使用します。

error_log_size × 2 ＋ process_log_size × 2 ＋ info_log_size × 2

ログ採取機能については“トラブルシューティング集”の“CORBAサービスのログ情報の採取”を、上記パラメタにつ

いては“A.1 config”(CORBAサービス)を参照してください。

注3) 以下のディスク所要量(単位:バイト)が必要です。

(max_processes(*) ＋ 2) × log_file_size(*) × 2 *: CORBAサービスのインストールフォルダ\etc\configファイルのパラメタ

log_file_size(*)×2 *: configファイルで定義

なお、ログファイルは、不要になった時点で、削除してください。

採取されるログファイルはlog、log.old以外にサーバアプリケーションごとに“appNNNN.log”、“appNNNN.old”(NNNNは英数字)の名前で採取されます。

自ホストでネーミングサービス、インタフェースリポジトリを動作させる場合には、それぞれ、4Mバイト、32Mバイトの

領域が必要です。

注4) CORBAサービスのトレース情報の採取機能を使用している場合、大で以下のディスク容量を使用します。(各パ

ラメタはconfigファイルで定義)

trace_size_per_process× max_processes × 2 ＋ trace_size_of_daemon × 2

トレース情報の採取機能については“トラブルシューティング集”の“CORBAサービスのトレース情報の採取”を、上

記パラメタについては“A.1 config”(CORBAサービス)を参照してください。

注5) インタフェースリポジトリを使用する場合のディスク容量について以下に示します。インタフェースリポジトリのデータ

ベースのサイズは、以下の計算式に従って見積もり、ディスクを確保してください。

なお、インタフェースリポジトリのデータベースは、初期値(10240Kバイト)から自動拡張します。

－ディスク容量

用途容量

インタフェー

スリポジトリ

サービス情

報

管理域 (固定)220Kバイト

利用者定義領域 (初期値:可変)10240Kバイト

実行トレース情報 ( 大)33000Kバイト

－見積り式

利用者定義領域(オブジェクトに要するディスク容量)の見積り式を以下に示します。

項

番

IDL定義計算式(単位:バイト)

1 モジュール宣言 1708 ＋ ((a－1)÷32＋1)×176

2 インタフェース宣言 1712 ＋ ((a－1)÷32＋1)×176 ＋ ((b－1)÷32＋1)×176 ＋ 512×b

- 10 -

項

番

IDL定義計算式(単位:バイト)

3 オペレーション宣言 2304 ＋ ((e－1)/32＋1)×176 ＋ ((f－1)÷32＋1)×176 ＋ ((g－1)÷32＋1)×176

4 属性宣言 2224

5 定数宣言 2160 ＋ c

6 例外宣言 1712 ＋ ((d－1)÷32＋1)×176 ＋ 836×d

7 データ型宣言 2220

8 文字列型宣言(ワイ

ド文字列を含む)1716

9 列挙型宣言 1824 ＋ ((j－1)÷32＋1)×176 ＋ 64×j

10

シーケンス型宣言 2228

11

構造体宣言 1712 ＋ ((h－1)÷32＋1)×176 ＋ 836×h

12

共用体宣言 2436 ＋ ((i－1)÷32＋1)×176 ＋ 972×i

13

固定小数点型宣言 1716

14

配列宣言 2228

記

号

項目意味

a 包含数包含する型宣言数

b 継承数インタフェース宣言が継承するインタフェース数

c 定数値長定数宣言の値の長さ

d 例外構造体メンバ

数

例外宣言の構造体のメンバ数

e パラメタ数オペレーション宣言でのパラメタ数

f コンテキスト数オペレーション宣言でのコンテキスト数

g 例外数オペレーション宣言での例外数

h 構造体メンバ数構造体宣言でのメンバ数

i 共用体メンバ数共用体宣言でのメンバ数

j 列挙型メンバ数列挙型宣言でのメンバ数

注6) ログファイルのサイズの上限値は、CORBAサービスのconfigファイルのlog_file_sizeで設定することができます。ア

プリケーションごとにJVxxxxxxxxxx.log/JVxxxxxxxxxx.old(xxxxxxxxxxは一意の数字)の名前で採取されます。な

お、ログファイルは、不要になった時点で、削除してください。

注7) ログファイルのサイズの上限値は、HTTPトンネリングの“gwconfigファイル”の“max_log_file_size”で設定することが

できます。ディスク容量は、バックアップファイルを1つ残すため“max_log_file_sizeで指定した値×2”となります。ま

た、SolarisまたはLinuxで、WebサーバにInterstage HTTP Serverを使用している場合は、Interstage HTTP Serverの通

信プロセスごとにログファイルが作成されます。なお、ログファイルは、不要になった時点で、削除してください。

機能: イベントサービス

- 11 -



イベントサービスのインストールディレ

クトリ\etc

/etc/opt

0.1 以上

1.0 以上

チャネル情報

イベントサービスのインストールディレ

クトリ\var

/var/opt

61(Mバイト) ＋essetcnfコマンドの-s -logsizeオプションの指

定値×2(Kバイト)以上

ログ情報

traceconfigファイルの

trace_size × トレース

ファイルの世代数

トレースの採取方法に

よって異なります。 (注1)

トレース情報

Interstage管理コンソールで保存先(新規作成)の格納ディレクトリで指定、ま

たはイベントサービスのユニット定義

ファイルの“trandir”、“sysdir”、

“userdir”で指定

38 × イベントサービス

で作成したユニット数

以上 (注2)




不揮発チャネル運用時

注1)

－プロセス単位で内部トレースを採取する

(traceconfigファイルのtrace_buffer = process)場合

traceconfigファイルのtrace_size × イベントチャネルのプロセス数 ×トレースファイルの世代数

イベントチャネルのプロセス数＝静的イベントチャネルグループ数＋動的イベントチャネルのプロセス数

動的イベントチャネルのプロセス数: isinitコマンドでInterstage初期化時に設定したInterstage動作環境定義の定義“Event maximum Process”の指定

値。

ノーティフィケーションサービスを使用している場合は、“動的イベントチャネルのプロセス数×2”としてください。

－イベントサービス単位で内部トレースを採取する

(traceconfigファイルのtrace_buffer = system)場合

traceconfigファイルのtrace_size × トレースファイルの世代数

注2) Interstage管理コンソールで設定した場合は、保存先(新規作成)の格納ディレクトリには、以下の容量が必要となりま

す。

－イベントデータ用ファイル容量

－システム用ファイル容量

- 12 -

－トランザクション用ファイル容量:((トランザクション多重度 × 4) ＋ 256 ＋(1トランザクション内大メッセージサイズ × 2)) × 16 (KB)

ユニット定義ファイルで設定した場合は、各ユニット定義ファイルで指定した以下の容量が必要となります。

－ “sysdir”で指定したディレクトリには、“syssize”で指定したサイズ

－ “userdir”で指定したディレクトリには、“usersize”で指定したサイズ

－ “trandir”で指定したディレクトリには、

((tranmax×4) ＋ 256 ＋ (tranunitmax × 2)) × 16 (Kバイト)

機能: Portable-ORB



Portable-ORBインストールディレクトリ

(注1)

/var/opt (注1)

(注2) ログ情報

注1) アプレットとして動作する場合は、アプレットが動作するクライアントマシン上のローカルディスクに、porbeditenvコマ

ンドで“ログ格納ディレクトリ”として指定したディレクトリとなります。

注2) porbeditenvコマンドで“ログ情報を採取”を指定した場合、

設定した“ログファイルサイズ” × 2 × 動作するアプリケーション/アプレット数

機能: コンポーネントトランザクションサービス




スのインストールディレクトリ\var

/var/opt/FSUNtd/

25以上ログトレースファイル

/opt/FSUNtd/etc/isreg(Interstageの

動作環境ディレクトリ)

/opt/FJSVtd/etc/isreg(Interstageの動

作環境ディレクトリ)

15.0 以上動作環境

/var



してください。 (注)

異常終了した場合に採

取されるcoreファイル

注) ディスク所要量の算出方法は、以下のとおりです。

CORBAサービス関連の共有メモリサイズ(*1) × 3 ＋コンポーネントトランザクションサービスの共有メモリサイズ(*2) ＋ワークユニット数 × 0.26 ＋

- 13 -

ワークユニットに含まれるIDL定義のパラメタ数(*3) × 0.00005 ＋基本サイズ(*4)

CORBAサービス関連の共有メモリサイズ(*1) × 3 ＋ワークユニット数 × 0.26 ＋基本サイズ(*4)

－ *1:CORBAサービス関連の共有メモリサイズ

CORBAサービスのconfigファイル(/opt/FJSVod/config)中の各パラメタから以下の式で算出します。

limit_of_max_IIOP_resp_con × 0.016 ＋limit_of_max_IIOP_resp_requests × 0.016 ＋max_impl_rep_entries × 0.006 ＋ 0.01

－ *2: コンポーネントトランザクションサービスの共有メモリサイズ

クライアント数 × 0.1 ＋ 100

クライアント数とは、環境定義ファイル(/var/opt/FJSVtd/etc/sysdef)のSystem Scale: ステートメントに指定した値に

応じて、以下のように見積もってください。

small : 50moderate : 100large : 500super : 1000

－ *3: ワークユニットに含まれるIDL定義のパラメタ数

ワークユニット数やIDL定義内のパラメタ数が多い場合に加算してください。

各オペレーションのパラメタに構造体がある場合、パラメタごとに構造体のメンバ数を加算してください。

－ *4: 基本サイズ

環境定義ファイル(/var/opt/FJSVtd/etc/sysdef)のSystem Scale: ステートメントに指定した値に応じて、以下のよう

に見積もってください。



機能: データベース連携サービス



－

(注) システムログファイル

ログファイル格納ディレクトリ

トランザクション数 ×0.008 ＋ 0.001

データベース連携サー

ビス運用時

トレースログファイル格納ディレクトリ運用環境の

OTS_TRACE_SIZE× 0.001

- 14 -



リソース管理トレースログファイル格納

ディレクトリ

運用環境の

RESOUCE_TRACE_SIZE × 0.001

リカバリトレースログファイル格納ディ

レクトリ

運用環境の

RECOVERY_TRACE_SIZE × 0.001

監視プロセストレースログファイル格納

ディレクトリ

運用環境の

OBSERVE_TRACE_SIZE × 0.001

リソース定義ファイル格納ディレクトリ

登録したリソース定義

ファイル数 × 0.001

/opt/FSUNots/var(otsgetdumpコマンドによるダンプファ

イル格納ディレクトリ)

5.0 以上

注) データベース連携サービスのシステムログファイルは、isgendefコマンドで指定したシステム規模により異なりますの

で、以下のとおり見積もってください。

small : 1Mバイト以上

moderate : 2Mバイト以上

large : 8Mバイト以上

super : 16Mバイト以上

機能: ロードバランス



CORBAサービスのインストールディレ

クトリ\etcフォルダ

/etc/opt

(注) データファイル

注) 以下のディスク所要量が必要です。

ロードバランスグループ数 × ((1ロードバランスグループあたりのオブジェクトリファレンス数 × オブジェクトリファレン

ス長) ＋ 0.0005)

初期量として、8256Kバイトを、初回起動時に獲得します。

これを超過した場合、1024Kバイト単位で拡張します。

機能: 性能監視ツール



格納ディレクトリ 1.0以上 (注1) 性能ログファイル

/var

6.4 × 性能監視ツール

の共有メモリサイズ(注2) × 6

異常終了した場合に採

取されるcoreファイル

注1) 所要量＝ ispmakeenvで指定する共用メモリサイズ × (測定時間 ÷ インターバル時間)

- 15 -

注2) ispmakeenvコマンドの-mオプションで指定する共有メモリサイズです。

機能: MessageQueueDirector



－運用の内容により、必


してください

詳細は

“MessageQueueDirector 説明書”の“ファイル

容量の見積り”を参照

してください

機能: フレームワーク




java.io.tmpdirで指定クライアント(Webブラ

ウザ)からアップロードさ

れるファイルサイズ




ファイルアップロード機

能の使用時 (注)

フレームワークのログ機能で指定した

ファイルが格納されるディレクトリ




フレームワークのログ機

能の使用時

注) このディレクトリには、WebブラウザからアップロードされたファイルのサイズがWebアプリケーションの指定したファイ

ル転送用メモリサイズを超えた場合に、アップロードされたファイルが格納されます。

機能: Java EE



[Java EE共通ディレクトリ]\work

[Java EE共通ディレクトリ]/work

配備ファイルのサイズ × 2 配備時に使用する一

時領域

[Java EE共通ディレクトリ] 配備ファイルを展開した資産の

サイズ × 2Java EEアプリケー

ションの資産一式

[Java EE共通ディレクトリ]\domains\interstage\logs\verifier-results

[Java EE共通ディレクトリ]/domains/interstage/logs/verifier-results

配備モジュールの誤りに依存配備モジュールの検

証結果を格納する領

域

サーバーログ (注1)

・ IJServerクラスタの場合

[Java EE共通ディレクトリ]\nodeagents\ijna\サーバーインスタンス名\logs

・サイズによるローテーション

を指定した場合

ログサイズ × (保存するロ

グファイルの世代数＋ 1)

- 16 -



・ Interstage Java EE DASサービスの場合

[Java EE共通ディレクトリ]\domains\interstage\logs

・ Interstage Java EE Node Agentサービスの場

合

[Java EE共通ディレクトリ]\nodeagents\ijna\agent\logs


[Java EE共通ディレクトリ]/nodeagents/ijna/サーバーインスタンス名/logs


[Java EE共通ディレクトリ]/domains/interstage/logs

・ Interstage Java EE Node Agentサービスの場

合

[Java EE共通ディレクトリ]/nodeagents/ijna/agent/logs

・時刻によるローテーション


1日あたりの出力サイズ×

(保存するログファイルの世

代数＋ 1)

※1日あたりの出力サイズは、

アプリケーションが出力するロ

グの内容や業務の負荷によっ

て、出力サイズや採取回数が

異なることを考慮してください。

サーバーインスタンスの起動お

よび終了処理だけで約0.016Mバイトのログが出力されます。

※ログサイズ、保存するログファ

イルの世代数は、ロガーの定義

項目で指定した値です。

Java VMログ(注1)

[Java EE共通ディレクトリ]\nodeagents\ijna\サー

バーインスタンス名\logs

[Java EE共通ディレクトリ]/nodeagents/ijna/サー

バーインスタンス名/logs







1日あたりの出力サイズ×


代数＋ 1)

※1日あたりの出力サイズは、

アプリケーションが出力するロ

グの内容や業務の負荷によっ

て、出力サイズや採取回数が

異なることを考慮してください。

サーバーインスタンスの起動お

よび終了処理だけで約0.003Mバイトのログが出力されます。




HTTPトレースログ(注1)


[Java EE共通ディレクトリ]\nodeagents\ijna\サーバーインスタンス名\logs\http


[Java EE共通ディレクトリ]\domains\interstage\logs\http

HTTPトレースログのログサイ

ズ × (保存するログファイルの

世代数＋ 1)


イルの世代数は、HTTPサービ

スの定義項目で指定した値で

す。

- 17 -




[Java EE共通ディレクトリ]/nodeagents/ijna/サーバーインスタンス名/logs/http


[Java EE共通ディレクトリ]/domains/interstage/logs/http

HTTPアクセスログ(注1)


[Java EE共通ディレクトリ]\nodeagents\ijna\サーバーインスタンス名\logs\http


[Java EE共通ディレクトリ]\domains\interstage\logs\http


[Java EE共通ディレクトリ]/nodeagents/ijna/サーバーインスタンス名/logs/http


[Java EE共通ディレクトリ]/domains/interstage/logs/http







1日あたりの出力サイズ ×(保存するログファイルの世

代数＋ 1)


イルの世代数、形式は、HTTPサービスの定義項目で指定し

た値です。

IIOPアクセスログ(注1)


[Java EE共通ディレクトリ]\nodeagents\ijna\サーバーインスタンス名\logs\iiop


[Java EE共通ディレクトリ]\domains\interstage\logs\iiop


[Java EE共通ディレクトリ]/nodeagents/ijna/サーバーインスタンス名/logs/iiop


[Java EE共通ディレクトリ]/domains/interstage/logs/iiop

IIOPアクセスログのログサイズ

× (保存するログファイルの世

代数＋ 1) (注3)

IIOPアクセスログ

モニタロギングのログ(注1)(注2)


バーインスタンス名\logs


バーインスタンス名/logs



1回あたりの出力サイズ ×1日あたりの採取回数 ×


代数＋ 1)



ログファイルのサイズ × (保存するログファイルの世代

数＋ 1)

- 18 -



※1回あたりの出力サイズは、

監視する情報の数や監視レベ

ルによって異なりますが、ログ

ファイル1つにつき約0.0001Mバイト～0.0005Mバイトです。

※1日あたりの採取回数は、監

視サービスの定義項目で設定

した採取間隔により決まります。

採取間隔の指定単位は1分の

ため、「1440÷採取間隔」で1日

あたりの採取回数を求めること

ができます。




[Java EE共通ディレクトリ]\domains\interstage\applications\j2ee-apps

[Java EE共通ディレクトリ]/domains/interstage/applications/j2ee-apps

配備するエンタープライズアプ

リケーション(.ear)を展開した資

産のサイズ

[Java EE共通ディレクトリ]\domains\interstage\applications\j2ee-modules

[Java EE共通ディレクトリ]/domains/interstage/applications/j2ee-modules

配備する下記アプリケーション

を展開した資産のサイズ

・ Webアプリケーション(.war)

・ EJBモジュール(.jar)

・コネクタモジュール(.rar)

・アプリケーションクライアン

ト(.jar)

[Java EE共通ディレクトリ]\domains\interstage\generated

[Java EE共通ディレクトリ]/domains/interstage/generated

配備するアプリケーションの構

成に依存します。

なお、大容量、および多数の配

備モジュールを配備する場合、

開発環境でアプリケーションの

配備を行い、生成物の容量を

事前に確認することを推奨しま

す。

[Java EE共通ディレクトリ]\commands

[Java EE共通ディレクトリ]/commands

大6Mバイト

[Java EE共通ディレクトリ]\domains\interstage\imq\instances\ブローカインスタンス名

[Java EE共通ディレクトリ/domains/interstage/imq/instances/ブローカインスタンス名

初期値1MBに以下の算出値を

加算してください。

・物理格納先ごとに以下の

値を算出し、合計してくだ

さい。

大蓄積件数×(メッセー

ジボディに設定する大サ

イズ＋メッセージプロパティ

メッセージブローカを

複数起動する場合に

は、メッセージブロー

カごとに左記の値を

算出し、各値を合計

してディスク容量を算

出してください。

- 19 -



に設定する大サイズ＋

0.0003)×2

・ imq.log.file.rolloverbytesプロパティに設定したサイ

ズ×10

トランザクションを使用する場合

・トランザクションの合計数×

0.002

・トランザクション中に受信す

るメッセージの大数をnと

して、n×(512＋32×n)×ト

ランザクションの合計数×

0.000001

Durable Subscription機能を

使用する場合

・ durable Subscriberの大

数×0.003

セッションの永続化ファイル


バーインスタンス名\dat


バーインスタンス名/dat

(注4) セッションリカバリ機

能使用時

セッションの永続化有

効時、SessionRegistry Serverを運

用する環境で必要で

す。

[トランザクションログの位置] キーポイント間隔の設定値 ×0.0005Mバイト＋ 0.15Mバイト

トランザクションログ

ファイルの格納先

[セッション格納位置] passivateされたBeanインスタン

スのファイルサイズ × passivateされたBeanインスタンス数

Beanインスタンスのファイルサ

イズやpassivateされる数量は、

配備するアプリケーションやア

プリケーションの運用方法に依

存します。

「5.8.2 EnterpriseBeanインスタンスの

キャッシング」を参照

しEJBコンテナ定義の

チューニングを実施

したり、負荷試験や運

用リハーサルを実施

したりしてどの程度の

ディスク容量が必要

になるかどうか事前に

想定し、見積もること

を推奨します。

注1) このディレクトリは、ロガーの定義項目で変更可能です。

注2) デフォルトでは、モニタロギングは無効になっているため、ログは出力されません。

注3) ログサイズおよび保存するログファイルの世代数は、IIOPサービスの定義項目の値です。IIOPサービスの定義項目

については、「Java EE運用ガイド」の「定義項目一覧」－「動作環境に関する定義項目」を参照してください。

注4) セッションリカバリ機能を使用して、セッションの永続化を有効にした場合は、Session Registry Serverの環境設定で

- 20 -

指定したセッションの永続化ファイルの保存先にセッションの永続化ファイルが生成されます。配備するWebアプリ

ケーション1つについて、次のディスク容量が必要です。(単位:Mバイト)

(0.004 + (セッションの保持するデータ容量 + X + 0.004) × セッション数) × 2



“セッションの保持するデータ容量”は、Webアプリケーションでセションの属性(Attribute)にセットするオブジェクトお

よびキーのサイズの合計値です。

“X”は、0.001 + セッションの保持するデータ容量 × 0.05です。

上記の値は、利用しているファイルシステムによっては値が増減する場合があります。


1.1.2 マルチサーバ管理を使用する場合

マルチサーバ管理を使用する場合、以下に示すディスク容量が追加で必要です。

■管理サーバ機能を使用する場合

管理サーバ機能を使用する場合は以下にあげる項目に関するディスク容量が必要です。ディレクトリおよび容量につ

いては“1.1.1 サーバ機能を使用する場合”の同一項目名の記述を参照してください。

・ Interstage管理コンソール

・ Interstage HTTP Server

・ Interstage ディレクトリサービス

・ Interstage JMXサービス

・業務構成管理

また、以下のディスク容量も必要です。

ディレクトリ

(デフォルト)ディスク容量


Interstage JMXサービスのインストール

ディレクトリ\var\ssv_ijs

/var/opt/FJSVisjmx/ssv_ijs

配備するアプリケーションの

サイズ × 2Interstage管理コン

ソールからのアプリ

ケーションの配備

Interstage管理コンソールのインストー

ルディレクトリ\isAdmin\var\download

/var/opt/FJSVisgui/tmp/download

(注) Interstage管理コン

ソールからのログ

参照

注) Interstage管理コンソールの以下の統合管理画面において、ログファイルをダウンロードする場合、同時にダウンロード

するログファイルのサイズ分のディスク容量が一時的に必要となります。


Interstage HTTP Server [統合管理] > [Interstage管理コンソール] > [InterstageApplication Server] > [サーバグループ名] > [サーバ名] > [シス

テム] > [サービス] > [Webサーバ] > [FJapache] > [ログ参照]タブ

- 21 -


[統合管理] > [Interstage管理コンソール] > [InterstageApplication Server] > [サーバグループ名] > [サーバ名] > [シス

テム] > [サービス] > [Webサーバ] > [FJapache] > [バーチャル

ホスト] > [バーチャルホスト名] > [ログ参照]タブ

Webサーバコネクタ [統合管理] > [Interstage管理コンソール] > [InterstageApplication Server] > [サーバグループ名] > [サーバ名] > [シス

テム] > [サービス] > [Webサーバ] > [FJapache] > [Webサーバ

コネクタ] > [ログ参照]タブ

IJServerワークユニット [統合管理] > [Interstage管理コンソール] > [InterstageApplication Server] > [サーバグループ名] > [サーバ名] > [シス

テム] > [ワークユニット] > [ワークユニット名] > [ログ参照]タブ

ログファイルのサイズについては、各機能のログ情報のディスク容量を参照し、運用の内容により必要とするサイズを検

討してください。

なお、ログファイルのサイズが大きいため、ディスク容量の不足によりログファイルのダウンロードに失敗する場合は、FTPなどを使用してダウンロードしてください。

■管理対象サーバとして運用する場合

管理対象サーバとして運用する場合は、使用する機能に関するディスク容量が必要です。ディレクトリおよび容量につ

いては“1.1.1 サーバ機能を使用する場合”の同一項目名の記述を参照してください。

また、以下のディスク容量も必要です。

ディレクトリ

(デフォルト)ディスク容量


Interstage JMXサービスのインストール

ディレクトリ\etc

/etc/opt/FJSVisjmx

1 サイトへ追加される

場合

■共存サーバとして運用する場合

共存サーバでは管理サーバ機能とInterstageのサーバ機能(管理対象サーバ)が同一マシン上で動作しています。上記

の記事を参照して、管理サーバ機能とInterstageのサーバ機能で使用するサービスを列挙してください。各サービスが必

要とするディスク容量は“1.1.1 サーバ機能を使用する場合”の同一項目名の記述を参照してください。

注意

管理サーバ機能とInterstageのサーバ機能で同一サービスを使用する場合、そのサービスの必要資源量を2倍する必

要はありません。

1.1.3 MQ連携サービスを使用する場合

本ソフトウェアの動作時に必須となる動的ディスク所要量の詳細は、“MQ連携サービス説明書”の“MQDBRIDGEシス

テム向けInterstage環境の作成”を参照してください。

1.1.4 クライアント機能を使用する場合

本ソフトウェアを以下の運用で動作させるとき、各ディレクトリにはインストールに必要な“静的ディスク資源”に加えて以

下のディスク容量が必要です。空き容量が足りない場合は、該当するファイルシステムのサイズを拡張してください。


- 22 -



/var/opt (注1) ログ情報(プレインストール

型Javaライブラリ以外の場

合)

任意(Java VMのシステムプ

ロパティのuser.dirで指定)(注2) ログ情報(プレインストール

型Javaライブラリの場合)

/tmp 1.0 以上

IDL定義の量に依存

IDLコンパイラ動作時

注1) ログファイルのサイズの上限値は、CORBAサービスのconfigファイルのlog_file_sizeで設定することができます。ディ

スク容量は、バックアップファイルを1つ残すため“ログファイルサイズの上限値×2”となります。configファイルの詳細

については、“CORBAサービスの動作環境ファイル”－“A.1 config”を参照してください。なお、ログファイルは、不要

になった時点で、削除してください。

注2) ログファイルのサイズの上限値は、CORBAサービスのconfigファイルのlog_file_sizeで設定することができます。ア

プリケーションごとにJVxxxxxxxxxx.log/JVxxxxxxxxxx.old(xxxxxxxxxxは一意の数字)の名前で採取されます。な

お、ログファイルは、不要になった時点で、削除してください。




/var/opt (注) “ログファイルサイズ”×2×

動作するアプリケーション/アプレット数

porbeditenvコマンドで“ログ

情報を採取”を指定した場

合のログ情報

注) アプレットとして動作する場合は、アプレットが動作するクライアントマシン上のローカルディスクに、porbeditenvコマ

ンドで“ログ格納ディレクトリ”として指定したディレクトリとなります。

1.2 メモリ容量

本ソフトウェアを動作させるために必要なメモリ容量は次のとおりです。

注意

動作させるために必要なメモリ容量が確保されていない場合、動作に不具合が生じる場合があります。

1.2.1 サーバ機能を使用する場合

Interstageの各機能を使用する場合のメモリ所要量について説明します。

以下の表を参照し、使用する製品に応じて、各機能のメモリ所要量を見積もってください。表内で使用している略称につ

いては、「製品名称の略称について」を参照してください。

EE SJE WS

Interstage管理コンソール ○ ○ ○


Interstage JMXサービス ○ ○ ○


(注)

- 23 -

EE SJE WS

Interstage ディレクトリサービス ○ ○ ×

IJServerワークユニット ○ ○ ×

Session Registry Server ○ × ×

CORBAサービス ○ ○ ○

イベントサービス／ノーティフィケーションサービス ○ ○ ×

Portable-ORB ○ ○ ×

コンポーネントトランザクションサービス ○ ○ ○


ロードバランス ○ × ×

セション情報管理機能 ○ × ×

MessageQueueDirector ○ × ×

フレームワーク ○ ○ ×

Java EE ○ ○ ○

○:該当製品で提供される機能です。

×:該当製品で提供されない機能です。

注) Interstage シングル・サインオンの業務サーバだけでメモリ容量を見積もります。

機能: Interstage管理コンソール

メモリ所要量(単位:Mバイト) 備考

121.0 以上

機能: Interstage HTTP Server


22.7 ＋ (0.05 × m) ＋ (0.06 × n) 以上

25.2 ＋ (0.04 × m) ＋ (0.12 × n) 以上

17.0 ＋ (3.5 × n) 以上

8.0 ＋ (3.0 × n) 以上

m: 環境定義ファイルで指定した大リクエスト同時処理数

(httpd.confファイルのThreadsPerChildディレクティブの設定値)n: クライアントからのHTMLファイル同時アクセス数

HTMLファイルを複数

クライアント同時アクセ

ス時

機能: Interstage JMXサービス


(注)

90.0 以上

81.3 以上

270.0 以上 130.0 以上

200.0 以上

- 24 -

注) 下段はWindows Server(R) 2003 x64 Editionsを使用した場合の所要量です。

機能: Interstage シングル・サインオン


10.0 以上 (注1) 業務サーバ機能

10.0 以上 (注2) 認証サーバ機能

10.0 以上 (注3) リポジトリサーバ機能

注1) 運用に応じて以下の式で見積もった値を加算してください。(単位:バイト)

－ (2,400 ＋ (ロール数＋ロールセット数＋ (ロールセット数 × ロール数)) × 2,048以上) × パス定義数 + 業務

サーバ数 × (2,000,000 ＋キャッシュサイズ × キャッシュ数) ロール数 : SSOリポジトリに定義した保護リソースの、チューニングを行う業務サーバのパス定義に設定した

ロールの総数

ロールセット数 : SSOリポジトリに定義した保護リソースの、チューニングを行う業務サーバのパス定義に設定した

ロールセットの総数

パス定義数 : SSOリポジトリに定義した保護リソースの、チューニングを行う業務サーバのパス定義の総数

キャッシュサイズ: “F.4 業務サーバを構築する場合のチューニング”を参照してください。

キャッシュ数 : “F.4 業務サーバを構築する場合のチューニング”を参照してください。

注2) セション管理を行わない場合は、運用に応じて以下の式で見積もった値を加算してください。(単位:バイト)

－ ((サイト定義数 × 1,024) ＋ (パス定義数 × 1,024)) × 2 サイト定義数: SSOリポジトリに定義したサイト定義の総数

パス定義数 : SSOリポジトリのすべてのサイト定義に定義したパス定義の総数

統合Windows認証を行う場合は、256Mバイトを加算してください。

認証サーバ間連携を行う場合は、256Mバイトを加算してください。

注3) 運用に応じて以下の式で見積もった値を加算してください。(単位:バイト)

－ ((ロール数＋ロールセット数＋ロールセット数 × ロール数) × 2,048以上) × 2 ロール数 : SSOリポジトリに定義したロールの総数

ロールセット数: SSOリポジトリに定義したロールセットの総数

セション管理を行う場合は、上記の算出値に、以下の式から算出される値を加算してください。

－ 23,500,000 ＋ ((同時にシングル・サインオンシステムを使用する利用者数 × (2,560 ＋ α)) × 2)

【α：拡張ユーザ情報】

通知する拡張ユーザ情報の数に応じて、以下の値を加算する。

通知する拡張ユーザ情報のサイズ × 2

ユーザ情報を登録するディレクトリサービスにActive Directoryを使用し、シングル・サインオンの拡張スキーマを使

用しない場合は、上記の算出値に、以下の式から算出される値を加算してください。

－ Active Directoryのロール/ロールセットに使用する属性の総数 × 524 × 2



340.0 以上 (注1) 150.0 以上 (注1) 217.0以上 (注1) スタンドアロン、データ

ベース共用、またはス

- 25 -


レーブで運用する場

合 (注2)

50.0 以上

(前項のスタンドアロンで運用する場合に加えて必要となる値)マスタで運用する場

合 (注2)

2.0 以上エントリ管理コマンドを

使用する場合

22.0 以上 60.0 以上 60.0 以上エントリ管理ツールを使

用する場合

m × n × 3m: 1エントリの登録に使用したLDIFファイルのサイズ

n: 検索により通知されるエントリ数

Interstage ディレクトリ

サービス SDK検索時

注1) リポジトリを複数作成して運用する場合は、リポジトリ数を乗算してください。

注2) 表中の“マスタ”、および“スレーブ”は、リポジトリのデータベースに標準データベースを使用したレプリケーション形

態で運用する場合の、マスタ、およびスレーブサーバについて説明しています。

リポジトリのデータベースにRDBを使用したレプリケーション形態で運用する場合の、マスタ、およびスレーブサーバ

のメモリ所要量は、スタンドアロンで運用する場合と同じです。

機能: IJServerワークユニット

“WebアプリケーションとEJBアプリケーションを同一JavaVMで運用”時 (注1)(注2)

メモリ所要量(単位:Mバイト) 備考(以下のサンプルアプリケーショ

ンを運用した場合)

(*)

59.6 以上

56.5 以上

107.4 以上 90.2 以上

114.3 以上

EjbBmp(Web,Session,BMP)

62.1 以上

56.6 以上

108.7 以上 65.8 以上

115.1 以上

EjbCmp11(Web,Session,CMP1.1)

65.8 以上

61.2 以上

114.7 以上 89.9 以上

118.8 以上

EjbCmp20(Web,Session,CMP2.0)

71.6 以上

66.2 以上

119.2 以上 99.6 以上

125.3 以上

EjbMessageDriven(Web,Session,MDB)

*) 下段はWindows Server(R) 2003 x64 Editionsを使用した場合の所要量です。

“Webアプリケーションのみ運用”時 (注1)

- 26 -



(*)

51.6 以上

53.1 以上

97.7以上 81.4 以上

94.4 以上

HelloServlet(Web)


“EJBアプリケーションのみ運用”時 (注2)



(*)

54.3 以上

55.8 以上

98.2 以上 87.7 以上

106.3 以上

EjbBmp(Session,BMP)

55.8 以上

55.9 以上

100.9 以上 86.4 以上

107.6 以上

EjbCmp11(Session,CMP1.1)

57.9 以上

58.6 以上

107.9 以上 86.4 以上

111.8 以上

EjbCmp20(Session,CMP2.0)

59.8 以上

60.2 以上

109.9 以上 96.9 以上

118.3 以上

EjbMessageDriven(Session,MDB)


注1) 詳細は以下の式で見積もってください。(単位:Mバイト)

・ Webサーバコネクタ

0.2 × k ＋ 2.0

1.9 × k ＋ 30.0

1.0 × k ＋ 30.0

k: Servletサービスへの同時アクセス数

・ IJServerワークユニット:(プロセス多重度1当り)

－ “WebアプリケーションとEJBアプリケーションを運用”の場合

48.0 ＋ (1.4 × k) ＋ (0.7 × w) ＋ (P1＋P2＋P3＋..＋Pn)

121.0 ＋ (2.1 × k) ＋ (0.7 × w) ＋ (P1＋P2＋P3＋..＋Pn)

- 27 -

28.0 ＋ (1.5 × k) ＋ (0.7 × w) ＋ (P1＋P2＋P3＋..＋Pn)

－ “Webアプリケーションのみ運用”の場合

47.0 ＋ (1.3 × k) ＋ (0.7 × w) ＋ (P1＋P2＋P3＋..＋Pn)

84.0 ＋ (2.5 × k) ＋ (0.7 × w) ＋ (P1＋P2＋P3＋..＋Pn)

27.0 ＋ (1.3 × k) ＋ (0.7 × w) ＋ (P1＋P2＋P3＋..＋Pn)

k: Servletコンテナへの同時アクセス数

w: Webアプリケーションの数

Pn: 各ServletまたはJSPの実行サイズ。上記表では1Mバイトとして計算

セションリカバリ機能(Session Registry Client)を使用する場合は、以下の値を加算してください。

－ (0.002 ＋セションの保持するデータ容量(※)) × 想定されるセション数

※: Webアプリケーションでセションの属性(Attribute)にセットするオブジェクトおよびキーのサイズの合計値

なお、セションリカバリ機能(Session Registry Client)は、Interstage Application Server Enterprise Edition、InterstageApplication Server Standard-J Editionで運用可能です。

ServletはJava VM上で動作するため、実際のメモリ使用量(ヒープ領域を含む)は、以下に示す要因により異なりま

す。

－ newするクラス型

－ newするインスタンスの個数

－インスタンスのライフサイクル

－ GCの動作状況

－ IJServerワークユニットの各種定義

－使用するJava VM

そのため正確なメモリ使用量(ヒープ領域、Perm領域)は次のようにして実測することにより見積もることを推奨しま

す。

－本番運用のピーク時と同一条件で動作させます。Java VMが使用するメモリが不足すると、イベントログにメッセー

ジが出力されますので、ヒープ領域やPerm領域の大値を増やして、適な値としてください。求めたヒープ領

域やPerm領域の大値をそのまま本番運用時の値として利用します。

注2) 以下を参考に、EJBサービス運用時のメモリ所要量を見積もってください。

EJBアプリケーション運用時、Java VMが使用するメモリ量(初期値、大値)および1プロセスで必要な全メモリ量

は、以下に示す要因により異なります。

－ newするクラス型

－ newするインスタンスの個数

－インスタンスのライフサイクル

－ GCの動作状況

－ EJBアプリケーションの各種定義

いずれのメモリ量も簡単には算出できないので、次のようにして実測することにより見積もってください。

1. Java VMが使用するメモリ量の初期値(javaコマンドの-Xmsオプションで指定する値)EJBアプリケーションを、本番運用の通常時(ピーク時ではない)と同一条件で動作させます。Java VMが使用

するメモリ量( 大値)が不足すると、IJServer21033またはEJB1033メッセージが出力されますので、試行錯誤

によりメモリ量( 大値)を適な値としてください。このようにして求めたメモリ量( 大値)を本番運用時のメモリ

量(初期値)として利用します。メモリ量(初期値)の省略値は2Mバイトです。

- 28 -

2. Java VMが使用するメモリ量の大値(javaコマンドの-Xmxオプションで指定する値)EJBアプリケーションを、本番運用のピーク時と同一条件で動作させます。Java VMが使用するメモリ量( 大

値)が不足すると、IJServer21033またはEJB1033メッセージが出力されますので、試行錯誤によりメモリ量( 大

値)を適な値としてください。このようにして求めたメモリ量( 大値)をそのまま本番運用時のメモリ量( 大

値)として利用します。メモリ量( 大値)の省略値は64Mバイトです。

3. 1プロセスで必要な全メモリ量

1)と2)でJava VMが使用するメモリ量を見積り時、同時に1プロセスで必要な全メモリ量も実測して見積もってく

ださい。

機能: Session Registry Server (J2EE)


(例)254 (注) (例)120 (注)

注) 詳細は以下の式で見積もってください。(単位:Mバイト)

85.7 ＋ (2.5 × k) ＋ (0.01 × a) ＋ ((0.002 ＋ d) × s) × 2

28.7 ＋ (1.3 × k) ＋ (0.01 × a) ＋ ((0.002 ＋ d) × s) × 2

k: Session Registry Serverの同時処理数

a: (IJServerに配備している)Webアプリケーションの数

d: セションの保持するデータ容量＝ Webアプリケーションでセションの属性(Attribute)にセットするオブジェクトおよびキーのサイズの合計値。

s: セション数

例: 対象とするIJServerは同時処理数64、アプリケーション1つ、セションに格納するデータ量が2KB、セション数が

1000の場合。

85.7 ＋ (2.5 × 64) ＋ (0.01 × 1) ＋ ((0.002 ＋ 0.002) × 1000) × 2＝ 85.7 ＋ 160 ＋ 0.01 ＋ 8≒ 254

28.7 ＋ (1.3 × 64) ＋ (0.01 × 1) ＋ ((0.002 ＋ 0.002) × 1000) × 2＝ 28.7 ＋ 83.2 ＋ 0.01 ＋ 8≒ 120

Session Registry ServerはJava VM上で動作するため、実際のメモリ使用量(ヒープ領域を含む)は、負荷やGCの動

作状況により異なります。

そのため正確なメモリ使用量は次のようにして実測することにより見積もることを推奨します。

－本番運用のピーク時と同一条件で動作させます。Java VMが使用するメモリが不足すると、イベントログ/システム

ログにメッセージが出力されますので、ヒープ領域の大値を増やして、適な値としてください。求めたヒープ

領域の大値をそのまま本番運用時の値として利用します。




Interstage Application Server Enterprise Editionの場合

- 29 -


16.0 以上 (注1)

8.0 以上ネーミングサービス運

用時

45.6 以上 (注2) インタフェースリポジトリ

運用時

2.4 COBOL Webサブルー

チン使用時

注1) CORBAサービスの動作環境定義(configファイル)の設定により、16Mバイト＋加算値(下表)が必要です。

運用形態必要数(加算値)(単位:Kバイト)

CORBAサービス運

用時

100.0 ＋ limit_of_max_IIOP_resp_con × 16.0 ＋limit_of_max_IIOP_resp_requests × 16.0 ＋max_impl_rep_entries × 6.0 (以上)

トレース機能を使用

する場合

(CORBAサービス運用時) ＋ 20.0 ＋max_processes × trace_size_per_process (以上)

スナップショット機能

を使用する場合

(CORBAサービス運用時) ＋ 10.0 ＋ snap_size (以上)

なお、上記のlimit_of_[パラメタ名]のデフォルト値は以下となります。0が指定された場合も、以下と同様になります。

[パラメタ名] × 1.3 (小数部分切り捨て)

isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場

合は、[パラメタ名]となります。

また、CORBAアプリケーションを動作させる場合、1プロセスあたり1.5 Mバイト以上のメモリが必要となります。

注2) インタフェースリポジトリは、起動時にデータベースに格納されているオブジェクトをメモリ上に展開します。インタ

フェースリポジトリを使用する場合のメモリ容量について説明します。

－固定使用領域

45.6 Mバイト

－可変使用領域

インタフェースリポジトリでは、オブジェクトごとにメモリが使用されます。

以下の計算式より、オブジェクトごとの使用メモリを算出することができます。

項番 IDL定義計算式(単位:バイト)

1 モジュール宣言 3902＋a×(2×b＋2)

2 インタフェース宣言 3902＋a×(2×b＋2)＋a×b×c

3 オペレーション宣言 3934＋a×(3×b＋2＋f)＋a×b×g＋h×(12＋a＋

a×b)

4 属性宣言 3910＋a×(3×b＋2)

5 定数宣言 7704＋a×(3×b＋3)＋d

6 例外宣言 3836＋a×(2×b＋e＋1)＋e×(78＋a＋a×b)

7 文字列型宣言(ワイ

ド文字列を含む)3882＋a×(b＋1)

8 列挙型宣言 3918＋a×(2×b＋k＋2)

9 シーケンス型宣言 3882＋a×(2×b＋1)

- 30 -

項番 IDL定義計算式(単位:バイト)

10 構造体宣言 3766＋a×(2×b＋i＋1)＋i×(78＋a＋a×b)

11 共用体宣言 3840＋a×(3×b＋j＋1)＋j×(3880＋2×a＋a×b)

12 固定小数点型宣言 3882＋a×(b＋1)

13 配列宣言 3886＋a×(2×b＋1)

記号項目意味

a 識別子長対象オブジェクトの識別子の長さ

b 階層数対象オブジェクトの存在する階層

c 継承数インタフェース宣言が継承するインタフェース数

d 定数値長定数宣言の値の長さ

e 例外構造体メンバ

数

例外宣言の構造体のメンバ数

f コンテキスト数オペレーション宣言でのコンテキスト数

g 例外数オペレーション宣言での例外数

h パラメタ数オペレーション宣言でのパラメタ数

i 構造体メンバ数構造体宣言でのメンバ数

j 共用体メンバ数共用体宣言でのメンバ数

k 列挙型メンバ数列挙型宣言でのメンバ数



32.0 以上

機能: イベントサービス／ノーティフィケーションサービス


16.0 以上 8.0 以上 8.0 以上

ユニット数 × 100 ＋イベントサービスのユニット定義ファイルのshmmaxの合計

不揮発チャネル運用時

(a＋b)×c (Kバイト) (注1) essetcnfコマンド実行時に静

的生成のイベントチャネル

のコンシューマ数・サプライ

ヤ数を拡張する場合

(a＋b)×d (Kバイト) (注1) essetcnfコマンド実行時に動

的生成のイベントチャネル

のコンシューマ数・サプライ

ヤ数を拡張する場合

(a＋b)×(c－e)＋(f＋g)×e (Kバイト) (注1) essetcnfおよびessetcnfchnlコマンドを併用して静的生

成のイベントチャネルのコン

シューマ数・サプライヤ数を

拡張する場合

メッセージ本文のサイズ×蓄積メッセージ数イベントチャネルに蓄積する

イベントデータの形式に、

any型を使用する場合 (注2)

- 31 -


(メッセージ本文のサイズ＋(QoSプロパティ項目数×4Kバ

イト))×蓄積メッセージ数

イベントチャネルに蓄積する

イベントデータの形式に、

StructuredEvent型を使用す

る場合 (注2)

注1) a：essetcnfコマンドの-coninitオプションで指定するコンシューマ数の初期値の拡張数（初期設定値からの差分）

b：essetcnfコマンドの-supinitオプションで指定するサプライヤ数の初期値の拡張数（初期設定値からの差分）

c：イベントチャネルのグループ数

d：essetcnfコマンドの-dchmaxオプションで指定するイベントチャネルの大起動数

e：essetcnfchnlコマンドで設定するイベントチャネルのグループの数

f：essetcnfchnlコマンドの-coninitオプションで指定するコンシューマ数の初期値の拡張数（初期設定値からの差分）

g：essetcnfchnlコマンドの-supinitオプションで指定するサプライヤ数の初期値の拡張数（初期設定値からの差分）

essetcnfコマンドおよびessetcnfchnlコマンドの詳細については、“リファレンスマニュアル（コマンド編）”を参照してく

ださい。

注2) イベントサービスの形式については、“アプリケーション作成ガイド（イベントサービス編）”の“イベントデータの形式”

を参照してください。



1.5 以上

3.0 以上

機能: コンポーネントトランザクションサービス


48.0 以上 (注1) 50.0 以上 (注2) サービスの起動

－ 4.0 以上 (注3)

注1) この値はCORBAサービスのメモリ容量を含んでいませんので、加算してください。

注2) ユーザ認証機能を使用する場合は、0.9Mバイト加算してください。

アクセス制御を使用する場合は、0.6Mバイト加算してください。

注3) 1つのワークユニットでプロセス多重度を1とした場合の値です。

詳細は以下の式で見積もってください。

－ 4.0 × ワークユニット配下のプロセス数の総和

機能: データベース連携サービス


54.0 ＋ 0.010 × m ＋ 43.0 × n 以上

64.0 ＋ 0.011 × m ＋ 32.0 × n 以上

30.0 ＋ 0.010 × m ＋ 75.0 × n 以上

サービスの起動

(データベース連携

サービス動作マシン)

- 32 -


34.0 ＋ 0.009 × m ＋ 23.0 × n 以上

36.0 ＋ 0.010 × m ＋ 23.0 × n 以上

m: 大トランザクション数

n: リソース管理ごとの多重度＋1の総数

22.0 ＋ 27.0 × n 以上

27.0 ＋ 27.0 × n 以上

27.0 ＋ 75.0 × n 以上

14.0 ＋ 20.0 × n 以上

n: リソース管理ごとの多重度＋1の総数

サービスの起動

(リソース管理プログラ

ムだけを起動するマシ

ン)

機能: ロードバランス


2.0

機能: セション情報管理機能


7.0 以上

機能: MessageQueueDirector

注) MQDシステムが複数ある場合には、それぞれのMQDシステムについて見積もった値の合計が所要量になりま

す。


100.0 ＋ m ＋ s ÷ 1000 以上

100.0 ＋ mm: MQD環境定義のMQDConfigurationセクションの

MessageBufferMaxSizes: MQD環境定義のMemoryQueueセクションのsize

基本機能使用時

39.0 ＋ sc × 0.3 ＋ rc × 0.3 以上

sc: イベントチャネル連携サービスのCHANNELセクション定義数

rc: イベントチャネル連携サービスのRCHANNELセクション定

義全部の総集信数

イベントチャネル連携

サービス使用時

10.0 以上

同報配信サービス使用

時

305 ＋ sq × 0.2 ＋ rq × 0.1 ＋メッセージ長以上

sq: SMTP連携サービス定義中の送信メッセージキュー数

rq: SMTP連携サービス定義中の受信メッセージキュー数

SMTP連携サービス使

用時

- 33 -

機能: フレームワーク


Application Serverが使用するメモリ使用量＋ 32.0


2.9 [参考値] (注) サンプル“model”を実

行した場合

注) フレームワークを使用して作成したWebアプリケーションを運用する場合、必要となるメモリ容量は、Servletサービス

の運用に必要となるメモリ容量に含めて見積もってください。IJServerワークユニットの注1)の計算式のPn(各サーブ

レットまたはJSPの実行サイズ)の値として、Webアプリケーションのメモリ使用量を適用してください。この値は、フレー

ムワークのサンプル“model”の場合、2.9Mバイトです。なお、Servletサービスの運用に必要となるメモリ容量は、IJServerワークユニットの注1)に記載した方法で実測によって見積もることができます。

フレームワークを使用して作成したEJBアプリケーションを運用する場合、必要となるメモリ容量は、EJBサービスの

運用に必要となるメモリ容量に含めて、IJServerワークユニットの注2)に記載した方法で見積もってください。

機能: Java EE

Javaヒープ領域/Permanent世代領域

Interstage Java EE DASサービスのJavaヒープ領域/Permanent世代領域のデフォルト値は、以下のとおりです。

種別デフォルト値

Javaヒープ 512m

Permanent世代領域 192m

Javaヒープ領域/ Permanent世代領域のサイズは、Interstage Java EE管理コンソール、またはasadminコマンドで参

照・変更できます。

値の参照・変更方法の詳細は、以下を参照してください。

- 「リファレンスマニュアル(コマンド編)」－「create-jvm-optionsサブコマンド」

- 「リファレンスマニュアル(コマンド編)」－「delete-jvm-optionsサブコマンド」

物理メモリ使用量

Interstage Java EE DASサービスの物理メモリ使用量は、以下の見積もり式で算出してください。

[Javaヒープ領域サイズ]＋[Permanent世代領域サイズ]＋[数値1]＋( [IJServerクラスタ数] × 22 ＋ [サーバーイン

スタンス数] × 10 ＋ 82 ) × [数値2]

数値1、数値2:

使用するプラットフォームにより異なります。数値1、数値2は下記表を参照してください。

項番プラットフォーム数値1 数値2

1 Windows(R) 300 Mバイト 0.25 Mバイト

2 Solaris 500 Mバイト 1.0 Mバイト

3 Linux 500 Mバイト 0.5 Mバイト

IJServerクラスタ数および配下のサーバーインスタンス数を元に算出した値が、プロセスのアドレス空間の上限値

を下回ることを確認してください。もし上限値を超える場合は、上限値を超えない範囲にまでIJServerクラスタ数お

- 34 -

よびサーバーインスタンス数の削減を検討してください。

上限を超え、Interstage Java EE DASサービスが起動できない場合は、IJServerクラスタを削除してください。削除

手順は「トラブルシューティング集」－「運用環境に関する異常」を参照してください。

1.2.2 マルチサーバ管理を使用する場合

マルチサーバ管理を使用する場合、以下に示すメモリ容量が追加で必要です。


管理サーバ機能を使用する場合は以下にあげる項目に関するメモリ容量が必要です。容量については“1.2.1 サーバ

機能を使用する場合”の同一項目名の記述を参照してください。

・ Interstage管理コンソール

・ Interstage HTTP Server

・ Interstage ディレクトリサービス

・ Interstage JMXサービス


管理対象サーバとして運用する場合は、使用する機能に関するメモリ容量が必要です。容量については“1.2.1 サーバ

機能を使用する場合”の同一項目名の記述を参照してください。


共存サーバでは管理サーバ機能とInterstageのサーバ機能(管理対象サーバ)が同一マシン上で動作しています。上記

の記事を参照して、管理サーバ機能とInterstageのサーバ機能で使用するサービスを列挙してください。各サービスが必

要とするメモリ容量は“1.2.1 サーバ機能を使用する場合”の同一項目名の記述を参照してください。

注意



1.2.3 クライアント機能を使用する場合

本ソフトウェアを以下の運用で動作させるときに使用するメモリ容量を示します。



22.0 以上エントリ管理ツールを使用する場合

- 35 -

第2章 Interstageのチューニング

Interstageはシステム規模の指定だけで、システム運用が可能となるようなモデルケースを設定して各サービスの定義を

登録しています。しかし、システムによっては、より詳細なシステム構築が必要となります。

Interstageをチューニングする場合は、isregistdefコマンドで各サービスの定義を登録した後で実施してください。チュー

ニングした内容はInterstageの初期化機能で有効となり、Interstageの起動で反映されます。

Interstageのチューニングは、以下の定義ファイルに対して行います。

・ Interstage動作環境定義

・ CORBAサービスの動作環境ファイル

・コンポーネントトランザクションサービスの環境定義

・データベース連携サービスのシステム環境定義

2.1 想定するシステム形態(Java EE)ここではJava EEアプリケーションの標準的なシステム形態について説明します。Java EE機能を使用してシステムを構築

する場合は、次のようなシステム形態を意識して設計します。

Java EEのシステム形態

Java EEでは、以下のようなシステム形態を推奨しています。

・クライアント層

システムに接続するユーザインタフェースを提供します。Webブラウザを基本としていますが、Javaアプリケーションも

クライアントとして想定されています。

・プレゼンテーション層

プレゼンテーションのロジックをカプセル化したもので、システムを利用するクライアントからのリクエストを受け付け、

ビジネスロジック層のサービスへの橋渡しなどを行ってレスポンスをクライアントに返送するサービスを提供します。こ

の層では主として、ServletやJSPなどのコンポーネントが使用されます。

・ビジネスロジック層

プレゼンテーション層などからの要求に応じて業務処理やデータ提供などのビジネスサービスを供給します。一般的

にこの層で業務に関する処理が行われますが、既存システムなどの資産がある場合はEIS層のリソースを利用する

場合もあります。この層では主として、Enterprise JavaBeans やWebサービスを使用してビジネスロジックが実装されま

す。

EIS層にあるサービス(処理やデータ)を利用する場合には、EIS層にある外部リソースや他システムなどと連携するた

めの通信機能を提供するためにインテグレーション層を想定する場合があります。この層では、JDBCやconnectorなどのコンポーネントが使用されます。

・ EIS(Enterprise Information System)層データベース、メインフレーム上で動作するレガシーシステムやパッケージソフトなどのリソースを提供します。

システムを構築する場合、システム設計者はInterstageが提供するJava EEのコンポーネントを組み合わせて自由にシス

テムを構築する事ができます。以下は代表的な4層モデルです。

- 36 -

上記のモデルを使用する場合のチューニングポイントとしては、以下があります。

・ IJServerクラスタ（サーバーインスタンス）のチューニング

アプリケーションを運用するプレゼンテーション層とビジネスロジック層はIJServerクラスタ（サーバーインスタンス）で

運用します。このため、アプリケーションの規模やアプリケーションが受け付けるリクエスト量などによりチューニングを

行います。

・ WebコンテナやEJBコンテナのチューニング

JSP/ServletやEnterprise JavaBeansといったアプリケーションに対する要求は、WebコンテナやEJBコンテナが受け付

けて、必要な前処理・後処理を行ってアプリケーションを呼び出します。コンテナに対して要求の同時処理数などを

チューニングすることで流用制限を行ったり、プールやキャッシュの定義値を変更することで利用する資源量を調整

することができます。

・ EIS層に対する接続のチューニング

データベースなど各種リソースにアクセスする場合には、リソースに対する接続をチューニングする接続プールを使

用できます。リソースに対する要求の同時処理数などをチューニングすることでリソースに対する流用制限を行った

り、使用されていない接続プールに保持された接続をタイムアウトにより破棄するなどにより使用する資源量を削減

することができます。

また、データベースへの接続には、各ベンダが提供するJDBCドライバを使用して接続します。このため、JDBCドライ

バ側のチューニングポイントも合わせて確認する必要があります。

上記のようにシステムを構築する場合、システム設計者は使用するモデルで使用する各コンポーネントのチューニング

項目を確認し、システム規模に合わせてチューニングを行ってください。

また、Java EE機能の各種運用操作を行うInterstage Java EE DASサービスや、IJServerクラスタ（サーバーインスタンス）

の起動状態を監視するInterstage Java EE Node Agentサービスについてもシステム規模に合わせてチューニングする項

目があります。

2.2 想定するシステム形態（マルチ言語サービス）

Interstageの初期化時に、トランザクションアプリケーションを使用した連携をモデルケースとして設定しています。

トランザクションアプリケーションを利用した連携は、以下のとおりです。

・ローカルトランザクション連携

・グローバルトランザクション連携

・セション管理を利用した連携

・既存システム(グローバルサーバ)との連携

トランザクションアプリケーションは、以下の条件で設計しています。

- 37 -

・すべてのトランザクションアプリケーションは、他サーバ(自システム内の連携も含みます)と連携することを想定してい

ます。

・トランザクションアプリケーションのオブジェクトのプロセス数は、大接続クライアント数の10分の1です。

・トランザクションアプリケーションのオブジェクトから接続するサーバマシンは、1台です。

・リソースはサーバマシンに1つ、リソース管理プログラムの多重度は5です。

・データベース連携サービスの多重度は5、リカバリプログラムの多重度は2です。

CORBAアプリケーションの運用、ロードバランス、サーバマシン状態監視を使用する場合は、Interstageのチューニング

が必要です。

2.3 定義ファイルの設定値

各定義ファイルには、Interstageシステム定義のSystem Scaleステートメントに設定されているシステム規模に応じた値が

設定されます。

システム規模には、以下の4種類があり、isgendefコマンドでInterstageシステム定義を生成する際に指定します。isgendefコマンドの詳細については、「リファレンスマニュアル(コマンド編)」の「isgendef」を参照してください。

・ small（小規模システム）

・ moderate（中規模システム）

・ large（大規模システム）

・ super（超大規模システム）

なお、インストール直後のセットアップ環境では、以下のシステム規模が設定されています。

・large（大規模システム）

・small（小規模システム）

各定義ファイルに設定される値を以下に示します。

■システム規模ごとの設定値

定義名ステートメント値(System Scaleごとの)

small moderate large super

Interstage動作環

境定義

Corba Host Name ありません。

Corba Port Number ありません。

IR path for DB file

TD_HOME\var\IRDB (注1)

TD_HOME/var/IRDB (注2)

IR USE ありません。 (注3)

IR Host Name ありません。

(注3)

IR Port Number 8002

NS USE ありません。 (注3)

NS Host Name ありません。

(注3)

NS Port Number 8002

NS JP no

- 38 -



NS Locale

SJIS

EUC

LBO USE no

TD path for systemTD_HOME\var (注1)

/var/opt/FJSVisas/system/default/FSUNextp

/var/opt/FJSVisas/system/default/FJSVextp

OTS Multiple degree 5

OTS Recovery 2

OTS path for system log ありません。 (注4)

OTS maximum Transaction

5

50

10

100

50

500

100

1000

OTS Setup mode sys

OTS JTS's RMP Multiple degree ofProcess

5

OTS JTS's RMP Multiple degree ofThread

16

OTS Participate 4

OTS Host ありません。

OTS Port ありません。

OTS Locale ありません。

Event Service no

Event maximum Process 2

Event maximum Connection

5

50

10

100

50

500

100

1000

Event Locale

SJIS

EUC

Event Auto Disconnect no

Event SSL no

SSL USE no

SSL Port Number 4433

- 39 -



IS Monitor Mode mode2

FJapache no

CORBAサービス

の動作環境ファイ

ル (注5)

max_IIOP_resp_con

33

80

40

135

100

575

175 (注6)

1024

max_IIOP_resp_requests

772

1920

896

2944

1920

10112

3968

20352

max_processes

29

31

31

36

51

76

76

126

max_exec_instance 448 448

448

1046

448

2046

コンポーネントトラ

ンザクションサービ

スの環境定義

[SYSTEM ENVIRONMENT]System Scale


データベース連携

サービスの環境定

義

ありません。ありません。

注1)

TD_HOME:Interstageのインストールフォルダ\td

注2)

TD_HOME:コンポーネントトランザクションサービスのインストールディレクトリ

注3)

運用形態が「TYPE3」の場合は、必ず指定してください。

注4)

運用形態が「TYPE2」の場合は、必ず指定してください。

注5)

CORBAサービスの動作環境ファイル内の値に表中の値がisregistdefコマンド実行時に加算されます。また、isregistdefコマンドの投入が初回でない場合は、前回のコマンド投入時に加算した値を、現在設定されている値から減算し、新

たに指定したSystem Scaleの値が加算されます。詳細については、“■CORBAサービスの動作環境ファイルの設定

について”を参照してください。

注6)

1024以上の値は、設定できません。

- 40 -

■CORBAサービスの動作環境ファイルの設定について

CORBAサービスの動作環境定義ファイルの定義値は、isregistdefコマンドによるセットアップの実行時に、以下のように

設定されます。

・セットアップ実行時に、CORBAサービスの動作環境ファイルの定義値に対し、必要な値が加算されます。

・すでにセットアップ済みの環境に対し、スケールを変更した場合には、加算値の差分の値が反映されます。スケール

を大きくした場合には、加算値の差分の値が加算され、スケールを小さくした場合には、加算値の差分の値が減算

されます。

・加算値は、スケールに対して一定です。

以下に定義値max_IIOP_resp_conに対する設定例を示します。

・ Interstageがセットアップされていない環境に対し、isregistdefコマンドを実行した場合(システム規模:small)。

－ max_IIOP_resp_conの値8に対して、33を加算した値41が設定される。

－ max_IIOP_resp_requestsの値128に対して、772を加算した値900が設定される。

－ max_processの値20に対して、29を加算した値49が設定される。

－ max_exec_instanceの値512に対して、448を加算した値960が設定される。

・システム規模がsmallの環境に対し、システム規模をlargeに変更した場合

－ max_IIOP_resp_conの値41に対して、スケール間の加算値の差分+67(100-33)が反映された値108が設定され

る。

－ max_IIOP_resp_requestsの値900に対して、スケール間の加算値の差分+1148(1920-772)が反映された値2048が設定される。

－ max_processの値49に対して、スケール間の加算値の差分+22(51-29)が反映された値71が設定される。

－ max_exec_instanceの値960に対して、スケール間の加算値の差分+0(448-448)が反映された値960が設定され

る。

・システム規模がlargeの環境に対し、システム規模をsmallに変更した場合

－ max_IIOP_resp_conの値108に対して、スケール間の加算値の差分-67(33-100)が反映された値41が設定され

る。

－ max_IIOP_resp_requestsの値2048に対して、スケール間の加算値の差分-1148(772-1920)が反映された値900が

設定される。

－ max_processの値71に対して、スケール間の加算値の差分-22(29-51)が反映された値49が設定される。

－ max_exec_instanceの値960に対して、スケール間の加算値の差分-0(448-448)が反映された値960が設定され

る。

なお、isregistdefコマンドを使用せずに、CORBAサービスの動作環境定義ファイルの値を変更した場合、それ以降に本

セットアップを行っても、その変更時の差分の値は有効です。

注意

システムスケールを小さくする場合には、CORBAサービスの動作環境ファイルの定義値が減算されます。CORBAサー

ビスの動作環境ファイルの定義値が、必要量を下回らないように注意してください(セットアップ後、CORBAサービスの動

作環境定義ファイルの値を小さくカストマイズしなおしている場合に注意が必要です)。

2.4 チューニング方法(Java EE)特にシステムとしてチューニングする項目はありません。業務運用するサーバーインスタンスの各種チューニングを実施


- 41 -

2.5 チューニング方法(マルチ言語サービス)

2.5.1 アプリケーション追加によるチューニング

クライアントアプリケーション、サーバアプリケーションを追加する場合に修正する各サービスの定義のステートメントと加

算する値を説明します。

なお、追加するアプリケーションがCORBAアプリケーションかトランザクションアプリケーションにより加算する値は異なり

ます。

以下に示すアプリケーションを追加した場合のチューニング方法について説明します。

・クライアントアプリケーションを追加した場合

・サーバアプリケーションを追加した場合

・クライアント、サーバ兼用アプリケーションを追加した場合

2.5.1.1 クライアントアプリケーションを追加した場合

CORBAアプリケーション

定義名ステートメント加算値

CORBAサービス


ル

max_processes (注1) プロセス数の合計

max_IIOP_resp_con (注1)(注2)

注1)

max_processes、max_IIOP_resp_conを変更した場合は、システムパラメタの設定が必要です。

注2)

SSL接続のコネクションとSSL接続でないコネクションは別コネクションとして数える必要があります。そのため、SSL連

携機能を使用する場合、加算値は“プロセス数の合計 × 2”となります。

EJBクライアントアプリケーション


CORBAサービス


ル

max_processes (注) 追加するクライアントアプリケーションの

プロセス数

注)

max_processesを変更した場合は、システムパラメタの設定が必要です。

2.5.1.2 サーバアプリケーションを追加した場合



CORBAサービス


ル

max_processes (注) プロセス数の合計

max_exec_instance リクエスト実行用スレッドの合計

注)


EJBアプリケーション

- 42 -


CORBAサービス


ル

max_processes (注) 追加するEJBアプリケーションのプロセ

ス数

max_exec_instance

・ EJBアプリケーション作成の際に、

スレッド動作可としている場合

追加するEJBアプリケーションの

プロセス数 × 16

・ EJBアプリケーション作成の際に、

スレッド動作不可としている場合

追加するEJBアプリケーションの

プロセス数

追加するEJBアプリケーションのプロ

セス数 × 16

注)


トランザクションアプリケーション

考慮の必要はありません。

2.5.1.3 クライアント、サーバ兼用アプリケーションを追加した場合

サーバアプリケーションから他のオブジェクトを呼び出したり、オブジェクトリファレンスを獲得したり、セション管理機能、

XA連携などを使用する場合など、CORBAクライアントとしても動作するアプリケーションを示します。



CORBAサービス


ル



max_exec_instance リクエスト実行用スレッドの合計

注1)


注2)



トランザクションアプリケーション


CORBAサービス


ル



注1)


注2)



- 43 -

2.5.2 Interstage機能を使用するためのチューニング

Interstageの機能を使用する場合のチューニング方法について説明します。

以下の表を参照し、使用する製品に応じて、以降に示すサービスのチューニングを行ってください。表内で使用している

略称については、「製品名称の略称について」を参照してください。

EE SJE WS


ロードバランス

○ × ×

イベントサービス (注) ○ ○ ×

サーバマシン状態監視

○ × ×

○：チューニングを行う必要があります。

×：チューニングを行う必要はありません(該当製品では、サービスが使用できないため)。

注) Interstage JMSを使用する場合、イベントサービスのチューニングを行う必要があります。

2.5.2.1 データベース連携サービス

データベース連携サービスの多重度

データベース連携サービスの多重度を変更する場合は、以下の値を設定または加算します。

定義名ステートメント加算、設定値

Interstage動作環

境定義

OTS Multiple degree (注1) データベース連携サービスの多重度

CORBAサービス


ル

max_IIOP_resp_requests (注2)(注3)

max_exec_instance (注2)

注1)

値を設定します。

注2)

値を加算します。

注3)

データベース連携サービスの多重度がmax_IIOP_resp_requestsより大きい場合は、データベース連携サービスの多

重度の値を設定します。

リカバリプログラムの多重度のチューニング

リカバリプログラムの多重度をチューニングする場合は、以下の値を設定または加算します。


Interstage動作環

境定義

OTS Recovery (注1) リカバリプログラムの多重度

CORBAサービス


ル

max_IIOP_resp_requests (注2)


注1)

値を設定します。

- 44 -

注2)

値を加算します。

リソース管理プログラムのチューニング

リソース管理プログラムを複数起動する場合または、リソース管理プログラムの多重度を変更する場合は以下の値を

加算します。


CORBAサービス


ル

max_processes (注) (リソース管理プログラムの多重度＋ 1)の合計max_IIOP_resp_con (注)

max_exec_instance

注)


2.5.2.2 ロードバランス

ロードバランス機能を使用する場合は、以下の値を加算します。


CORBAサービス


ル

max_processes (注) 定数: 1

max_IIOP_resp_con (注)

max_exec_instance odsetlboコマンドの-mオプションに指定

した値

注)


2.5.2.3 イベントサービス

イベントサービスを使用する場合は、以下の値を設定または加算します。


CORBAサービス


ル


max_IIOP_local_init_con 以下のいずれかの大値

・ max_IIOP_local_init_con

・起動するコンシューマ／サプライヤ

のプロセス数の大値＋ 3 (注3)

max_IIOP_local_init_requests 以下のいずれかの大値

・ max_IIOP_local_init_requests


のプロセス数の大値＋ 3 (注3)× mixモデルのコンシューマ／サプ

ライヤが1コネクションで同時に接続

(送信)できるリクエスト数


のプロセス数の大値＋ 3 (注3)× pushモデルのコンシューマ／pullモデルのサプライヤが1コネクション

- 45 -


で同時に接続(受信)できるリクエスト

数

max_IIOP_resp_con (注1) すべてのイベントチャネルに接続するコ

ンシューマ・サプライヤの合計値＋ 1 (注4)

max_IIOP_resp_requests 以下のいずれかの大値

・ max_IIOP_resp_conの加算値 ×

(mixモデルのコンシューマ／サプラ

イヤが1コネクションで同時に接続(送信)できるリクエスト数＋ 1)

・ max_IIOP_resp_conの加算値 ×

(pushモデルのコンシューマ／pullモデルのサプライヤが1コネクションで

同時に接続(受信)できるリクエスト

数＋ 1)

max_processes (注1) 起動するイベントチャネル・コンシュー

マ・サプライヤのプロセス数の合計値＋ 2(注4)

max_impl_rep_entries (作成する静的生成イベントチャネルの

プロセス数・動的生成イベントチャネル

のプロセス数 × 2)の合計 (注5)

period_receive_timeout 異常が発生した場合にコネクションを回

収するまでのタイムアウト時間 (注6)

注1)

max_IIOP_resp_con、およびmax_processesを変更した場合は、システムパラメタを設定してください。

注2)

イベントチャネル側のシステムと、コンシューマ・サプライヤ側のシステムで加算値が異なります。システムにより以下

の値を加算してください。

－イベントチャネル側(イベントチャネルを静的起動した場合)「イベントチャネルグループの接続数(esmkchnlコマンドの-mオプションの設定値) (*1)」の総和

*1）“「イベントチャネルグループの接続数」 × 2”の値が“256”よりも小さい場合は、“256”として計算してくださ

い。

－イベントチャネル側(イベントファクトリを使用する場合)「イベントチャネルの大プロセス数(isinitコマンドでInterstage初期化時に設定したInterstage動作環境定義の定

義“Event maximum Process”の指定値)」 × 「イベントチャネルの大接続数(isinitコマンドでInterstage初期化時

に設定したInterstage動作環境定義の定義“Event maximum Connection”の指定値) (*2)」＋ 17*2）“「接続数」 × 2”の値が“256”よりも小さい場合は、“256”として計算してください。

－コンシューマおよびサプライヤ側

「サーバアプリケーション数(Pushモデルのコンシューマ数、Pullモデルのサプライヤ数)」 × 「スレッド大多重度

(OD_impl_instコマンドの-axオプションで指定するthr_conc_maximumの設定値)」

－イベントチャネル側(イベントチャネルを静的起動した場合)「イベントチャネルグループの接続数(esmkchnlコマンドの-mオプションの設定値) (*3)」の総和

*3）“「イベントチャネルグループの接続数」＋ 16”の値が“256”よりも小さい場合は、“256”として計算してくださ

い。

- 46 -

－イベントチャネル側(イベントファクトリを使用する場合)「イベントチャネルの大プロセス数(isinitコマンドでInterstage初期化時に設定したInterstage動作環境定義の定

義“Event maximum Process”の指定値)」 × 「イベントチャネルの大接続数(isinitコマンドでInterstage初期化時

に設定したInterstage動作環境定義の定義“Event maximum Connection”の指定値) (*4)」＋ 17*4）“「接続数」＋ 16”の値が“256”よりも小さい場合は、“256”として計算してください。

－コンシューマおよびサプライヤ側

「サーバアプリケーション数(Pushモデルのコンシューマ数、Pullモデルのサプライヤ数)」 × 「スレッド初期多重度

(OD_impl_instコマンドの-axオプションで指定するthr_conc_initの設定値)」

注3)

イベントチャネルを動作させる場合は、さらに“3”を加算してください。

注4)

イベントチャネル通信中にイベントサービス運用コマンドを実行する場合は、1を加算してください。

注5)

静的生成イベントチャネルのプロセス数は、esmkchnlコマンドまたはInterstage管理コンソールで作成した静的生成イ

ベントチャネルグループ数です。

動的生成イベントチャネル(イベントファクトリを使用する場合)のプロセス数は、isinitコマンドでInterstage初期化時に

設定したInterstage動作環境定義の定義“Event maximum Process”の指定値です。

注6)

以下の見積もり式を参考にして見積もった値を加算してください。

period_receive_timeout × 5 ＞イベントデータの待ち合わせ時間(essetcnf／essetcnfchnlコマンドの“-wtime”

の設定値) ＋ 20

イベントデータの待ち合わせ時間より先にperiod_receive_timeoutによるタイムアウトが発生した場合は、以下の現象

が発生する可能性があります。

－イベントデータがロストします。

－エラーメッセージ“od10605”が出力されて、応答の送信が失敗します。

－エラーメッセージ“es10033”（CODE=138）が出力されて、イベントチャネルが異常終了します。

なお、イベントデータの待ち合わせ時間には、“0”を指定しないでください。“0”を指定すると、イベントデータの待ち

合わせ時間は無限となり、period_receive_timeoutによるタイムアウトが発生します。

2.5.2.4 サーバマシン状態監視

サーバマシン状態監視機能を使用する場合は、以下の値を加算します。

監視サーバのチューニング


CORBAサービスの動作環境

ファイル



max_exec_instance 定数: 4

注) max_processes、max_IIOP_resp_conを変更した場合は、システムパラメタの設定が必要です。

被監視サーバのチューニング


CORBAサービスの動作環境

ファイル



max_exec_instance

- 47 -

注) max_processes、max_IIOP_resp_conを変更した場合は、システムパラメタの設定が必要です。

2.6 環境変数について

以下にInterstageで使用する環境変数を示します。

環境変数名用途

OD_HOME CORBAサービスのインストールパスを指定します。

例)

OD_HOME=Interstageのインストールフォルダ\ODWIN

OD_HOME=/opt/FSUNod

OD_HOME=/opt/FJSVod

OD_CODE_SET コード変換を行う際のクライアントコード系を指定します。

サポートコードは以下のとおりです。

・ SJIS(ShiftJIS)

・ EUC

・ UNICODE

・ SJISMS(ShiftJIS MS)

・ U90

・ JEF_LOWER(JEF英小文字)

・ JEF_KANA(JEFカナ文字)

・ JEF_ASCII(JEFASCII)

・ UTF8

例) OD_CODE_SET=EUC

TD_HOME コンポーネントトランザクションサービスのインストールパスを指定しま

す。

例)

TD_HOME=Interstageのインストールフォルダ\td

TD_HOME=/opt/FSUNtd

TD_HOME=/opt/FJSVtd

OTS_HOME データベース連携サービスのインストールパスを指定します。

OTSが動作するためにOTS_HOMEの設定は必須ではありません。

例)

OTS_HOME=Interstageのインストールフォルダ\ots

OTS_HOME=/opt/FSUNots

OTS_HOME=/opt/FJSVots

OTS_SCROLL_SIZE otstranlist、otspendlistコマンドを使用して、1画面でトランザクションリス

トを表示する行数を指定します。

- 48 -

環境変数名用途

例) OTS_SCROLL_SIZE=30

デフォルト:20

OTS_INVOKE_MODE 旧バージョンレベルのINTERSTAGE上のOTSシステム、あるいはリ

ソース管理プログラムと分散トランザクション連携する場合に、OTSシ

ステム、あるいはリソース管理プログラムが動作するマシン上で指定し

ます。値として2以外指定できません。

例) OTS_INVOKE_MODE=2

ES_HOME イベントサービスのインストールパスを指定します。

例) ES_HOME=/opt/FJSVes

PORB_HOME Portable-ORBのインストールパスを指定します。

(Portable-ORBの動作環境ファイル検索時にも使用)

例)

PORB_HOME=Portable-ORBのインストールフォルダ

PORB_HOME=/opt/FJSVporb

IS_ISSTOP_MONITOR_TIMER

Interstage 停止やワークユニット停止が無応答になる現象が発生した

場合、自動的にトラブル調査資料を採取する内部機構において、調

査資料を採取するまでの監視時間を変更する場合に秒単位で設定

します。環境変数を指定しない場合はデフォルト5分の監視時間とな

ります。Interstage 停止やワークユニット停止をコマンドで行う場合に

は、監視時間はisstopおよびisstopwuコマンドの-t オプションで指定可

能です。環境変数の指定より、コマンドのオプション指定が優先されま

す。本環境変数は必須ではありません。無応答になるトラブルが発生

して資料の採取が必要な際に、デフォルトの監視時間を変更したい

場合のみ設定してください。

本環境変数はブート時に取得可能なシステム環境変数として設定し

てください。つまり、本環境変数を有効とするには、システム環境変数

として設定した後にOSの再起動が必要です。

isstartコマンドでInterstageを起動する場合には、コマンドを入力する前

に環境変数を設定してください。rcプロシジャからInterstageを起動す

る場合には、rcプロシジャ内で設定してください。管理コンソールから

Interstageを起動する場合には、システムの環境変数として設定してく

ださい。

2.7 IPv6環境での運用について

本項では、IPv6環境での運用について説明します。

注意

・ IPv6/IPv4デュアルスタック環境での運用のみをサポートします。IPv4を無効にした場合の運用はサポートしません。

・グローバルアドレスおよびユニークローカルアドレスを使用した運用が可能です。リンクローカルアドレスについては、

機能ごとにサポート有無が異なります。詳細は、以降の各機能の説明を参照してください。

・ホスト名指定によりIPv6運用を行う場合、そのホスト名をIPv6アドレスで名前解決できる必要があります。pingコマンド

などを使用して、対象ホスト名に対して正しくIPv6通信できることを事前に確認してください。

- 49 -

・一時アドレス対応（プライバシ拡張）を有効にした環境での動作はサポートしません。一時アドレス対応（プライバシ

拡張）の詳細については、各OSのマニュアルを参照してください。

・ IPv6アドレスをログ・メッセージに出力する場合、設定ファイルなどに指定した値（入力値）の形式と異なる形式で出

力される場合があります。

・ IPv6環境において運用可能な機能は、Interstage管理コンソールを使用してIPv6通信を設定することもできます。設

定方法の詳細については、Interstage管理コンソールのヘルプを参照してください。

■運用可能な機能

IPv6環境において、以下の機能が使用できます。表内で使用している略称については、「製品名称の略称について」を

参照してください。

機能名 WS SJE EE

JDK/JRE ○ ○ ○

Java EE 6 － ○ ○

J2EE EJB － ○ ○

JTS/JTA － ○ ○

マルチ言語サービ

ス

CORBAサービス－－ ○

イベントサービス－－ ○

データベース連携サービス－－ ○

コンポーネントトランザクションサービス－－ ○


MessageQueueDirector －－ ○


Interstage ディレクトリサービス ○ ○ ○

SMEEコマンドによる証明書/鍵管理環境 ○ ○ ○

○：使用可－：使用不可

JDK/JRE

JDK/JREを使用してIPv6通信を行うことが可能です。

注意

java.nioパッケージを使用する場合は、Windows Vista(R)/Microsoft(R) Windows Server(R) 2008以降のOSを使用する

必要があります。

Java EE 6

IPv6環境でJava EE 6を使用することが可能です。

注意

・Windows Vista(R)/Microsoft(R) Windows Server(R) 2008以降のOSを使用する必要があります。

- 50 -

・リンクローカルアドレスは使用できません。

J2EE

以下の機能において、IPv6通信を行うことが可能です。ただし、SSL連携機能を使用した場合はIPv6通信を行えません。

・ EJB

・ JTS/JTA

ポイント

CORBAサービスの環境設定が必要です。

CORBAサービスの動作環境ファイル（config）において、“IP-version”に“v4-dual”または“v6”を設定し、Interstageを再

起動してください。デフォルトは“v4-dual”です。詳細は、A.1 configを参照してください。

注意


・入力値としてIPv4射影アドレスを使用することはできません。

マルチ言語サービス

以下の機能において、IPv6通信を行うことが可能です。ただし、SSL連携機能を使用した場合はIPv6通信を行えません。

・ CORBAサービス

・イベントサービス

・データベース連携サービス

・コンポーネントトランザクションサービス（サーバマシン状態監視機構、IPCOM連携を利用した負荷分散を除く）

ポイント

・ CORBAサービスの環境設定が必要です。

CORBAサービスの動作環境ファイル（config）において、“IP-version”に“v4-dual”または“v6”を設定し、Interstageを再起動してください。デフォルトは“v4-dual”です。詳細は、A.1 configを参照してください。

・コンポーネントトランザクションサービスを使用する場合、コンポーネントトランザクションサービスの環境設定が必要です。

コンポーネントトランザクションサービス環境定義ファイルにおいて、“IP version”に“v6”を設定し、Interstageを再起

動してください。デフォルトは“v4”です。詳細は、付録B コンポーネントトランザクションサービスの環境定義を参照し

てください。

注意



- 51 -

Interstage HTTP Server

IPv6環境でのHTTP/HTTPS通信を行うことが可能です。

注意



MessageQueueDirector

SMTP連携サービスにおいて、IPv6通信を行うことが可能です。

ポイント

サービス環境定義(MXHost)にIPv6形式のIPアドレス(またはホスト名)を記述する必要があります。

詳細は“MessageQueueDirector 説明書”を参照してください。

注意

入力値としてIPv4射影アドレスを使用することはできません。

Interstage シングル・サインオン

IPv6環境でInterstage シングル・サインオンを使用することが可能です。

注意



・ IPv6アドレスを直接指定することはできません。ホスト名、またはFQDNを指定してください。

Interstage ディレクトリサービス

IPv6環境でInterstage ディレクトリサービスを使用することが可能です。

注意



・ IPv6アドレスを直接指定することはできません。ホスト名を指定してください。

SMEEコマンドによる証明書/鍵管理環境

cmgetcrlコマンド（CRLの取得）において、IPv6通信を行うことが可能です。

- 52 -

注意



2.8 ホスト情報(IPアドレス/ホスト名)の変更方法について

Interstageを運用しているサーバのホスト情報(IPアドレスやホスト名)を変更する場合には、1台のサーバで、Interstageの

資源移出と資源移入を行うことで実施できます。資源移入時に、変更したいホスト情報を指定して資源移入の操作を行っ

てください。詳細については、“運用ガイド(基本編)”の“メンテナンス(資源のバックアップ/他サーバへの資源移行/ホスト

情報の変更)”を参照してください。

- 53 -

第3章システムのチューニング

この章では、システムチューニングについて説明します。

3.1 サーバ機能運用時に必要なシステム資源

Interstageの各サービスの運用に必要となるシステム資源について説明します。

以下の表を参照し、使用する製品に応じて、以降に示すサービスのチューニングを行ってください。各機能の説明を参

照する前に“■システムパラメタについて”を参照してください。表内で使用している略称については、「製品名称の略称

について」を参照してください。

なお、システムパラメタを算出するためのExcelファイルがマニュアルパッケージの“ApplicationServer\tuning”配下のサ

ブフォルダに“ISAS-IPCtuning.xlsx”として格納されています。Microsoft(R) Excel 2007もしくは以降のバージョンの

Microsoft(R) Excelをお持ちの場合は“ISAS-IPCtuning.xlsx”を使用してシステムパラメタを算出することが可能です。使

用方法などの詳細については、当該Excelファイル内の説明記事を参照してください。

EE SJE WS

CORBAサービスのシステム資源の設定 ○ ○ ○

コンポーネントトランザクションサービスのシステム資源の設定 ○ ○ ○

データベース連携サービスのシステム資源の設定 ○ ○ ×

イベントサービスのシステム資源の設定 (注1) ○ ○ ×

J2EE互換のシステム資源の設定 ○ ○ ×

Interstage HTTP Serverのシステム資源の設定 ○ ○ ○

MessageQueueDirectorのシステム資源の設定 ○ × ×

Interstage シングル・サインオンのシステム資源の設定 ○ ○ ○(注2)

Interstage ディレクトリサービスのシステム資源の設定 ○ ○ ×

Interstage管理コンソールのシステム資源の設定 ○ ○ ○

Interstage統合コマンドのシステム資源の設定 ○ ○ ○

Webサーバコネクタのシステム資源の設定 ○ ○ ○(注3)

○:チューニングを行う必要があります。

×:チューニングを行う必要はありません(該当製品ではサービスが使用できないため)。

注1) Interstage JMSを使用する場合、イベントサービスのシステム環境を設定する必要があります。

注2) Interstage シングル・サインオンの業務サーバのシステム資源だけ設定します。

注3) Webサーバコネクタの故障監視機能のシステム資源を設定する必要はありません。

■システムパラメタについて

◆システムパラメタの変更方法

IPC資源のパラメタに値を設定するために、以下のいずれかの方法を選択してください。

・ /etc/systemファイルの修正

/etc/systemファイルを編集し、必要なパラメタ値を変更します。変更後は、変更した値を反映するためにシステムをリ

ブートしてください。なお、変更方法の詳細については、Solarisのドキュメントを参照してください。

注) Solaris 10以降において、この方法でシステムチューニングする場合、shmmaxおよびshmmniは以下の関係が成

り立つような値を設定してください。

project.max-shm-memory ＝ shmmax × shmmni

- 54 -

・資源制御(Solaris 10以降)

以下の手順で、パラメタ値を変更してください。

1. Interstageの停止

Interstageを停止してください。もしInterstage管理コンソールを使用するためのサービスを起動している場合は

それらのサービスも停止してください。

2. user.rootプロジェクトとsystemプロジェクトのパラメタの変更

projmodコマンドでuser.rootプロジェクトとsystemプロジェクトのパラメタの値を変更してください。以下に例を示

します。

projmod -s -K 'project.max-sem-ids=(privileged,155,deny)' user.root

projmod -s -K 'project.max-sem-ids=(privileged,155,deny)' system

変更の特権レベルをprivileged、設定したしきい値を超える要求があった場合のアクションをdenyとします。

3. 値の反映

newtaskコマンドで変更した値をシステム反映します。

newtask -p user.root -c $$

4. Interstageの起動

Interstageを起動してください。必要に応じて、Interstage管理コンソールを使用するためのサービスを起動して

ください。

資源制御の詳細については、Solarisのドキュメントを参照してください。

「種類」の意味

システムパラメタの表中の「種類」の意味は、以下のとおりです。

・設定値

必要数の条件に応じた値に変更してください。

・加算値

すでに設定されている値に、必要数を加算してください。

各パラメタの意味

システムパラメタの各パラメタ名と意味は、以下のとおりです。

なお、資源制御によるIPC資源のパラメタ設定は、Solaris 10以降で利用できます。

共用メモリ

パラメタ資源制御意味

－ project.max-shm-memory 共用メモリの大サイズ

shmmax

－共用メモリの大セグメントサイズ

shmmni project.max-shm-ids 共用メモリIDの大数

セマフォ


semmni project.max-sem-ids セマフォIDの大数

semmns －システム全体のセマフォの大数

semvmx

－セマフォに設定できる大数

semmsl process.max-sem-nsems セマフォIDあたりのセマフォの大数

- 55 -


semopm

process.max-sem-ops セマフォコールあたりのセマフォ操作の大数

semmnu

－システム全体のセマフォ操作の取消記録グループ

数

semume －プロセスあたりのセマフォ操作の取消記録の大

数

メッセージキュー


msgmax

メッセージの大サイズ

msgmnb

process.max-msg-qbytes メッセージキュー上のメッセージの大バイト数

msgmni project.max-msg-ids メッセージキューIDの大数

msgtql process.max-msg-messages

メッセージキューにあるメッセージの大数

ファイルディスクリプタ


rlim_fd_max

process.max-file-descriptor ファイルディスクリプタの大数

◆システムパラメタの変更方法

/etc/sysctl.confを編集し、パラメタ値を変更します。変更後は“sysctl -p /etc/sysctl.conf”を実行するか、システムをリブー

トしてください。

変更方法の詳細については、OSのドキュメントを参照してください。


システムパラメタの表中の「種類」の意味は、以下のとおりです。

・設定値

必要数の条件に応じた値に変更してください。

・加算値

すでに設定されている値に、必要数を加算してください。


システムパラメタの各パラメタ名と意味は、以下のとおりです。

共用メモリ

パラメタ意味

kernel.shmall システム全体の共用メモリの大サイズ

kernel.shmmax 共用メモリの大サイズ

kernel.shmmni 共用メモリセグメントの大数

- 56 -

セマフォ

セマフォの設定値は、各パラメタ値を以下の形式で指定します。

－ kernel.sem = para1 para2 para3 para4

パラメタ意味

para1 セマフォIDあたりのセマフォの大数

para2 システム全体のセマフォの大数

para3 セマフォコールあたりのセマフォ操作の大数

para4 セマフォIDの大数


パラメタ意味

kernel.msgmax メッセージの大サイズ

kernel.msgmnb メッセージキュー上のメッセージの大バイト数

kernel.msgmni メッセージキューIDの大数


パラメタ意味

fs.file-max システム全体のファイルディスクリプタの大数

◆リソース制限

システムのリソースを制限するには、/etc/security/limits.confファイルを編集し、必要なパラメタ値を変更します。変更後

は、変更した値を反映するためにシステムをリブートしてください。

変更方法の詳細については、OSのドキュメントを参照してください。


リソース制限の表中の「種類」の意味は、以下のとおりです。

・ softソフトウェアリミット値を変更してください。

・ hardハードウェアリミット値を変更してください。


リソース制限のパラメタ名と意味は、以下のとおりです。


パラメタ意味

nofile ユーザにおいてオープン可能なファイルディスクリプタの大

数

3.1.1 CORBAサービスのシステム資源の設定

CORBAサービスを用いたシステムの運用時には、接続するクライアント/サーバ数、オブジェクト数などによりシステム資

源を拡張する必要があります。ここでは、以下について説明します。

- 57 -

・システムパラメタ

－ CORBAサービス

－インタフェースリポジトリ

－ネーミングサービス

・プロセス・スレッド

・ファイルディスクリプタ

■システムパラメタ

一般的な CORBAサービスが使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニングにつ

いて説明します。

CORBAサービスの他に共用メモリ、セマフォ、メッセージキューを使用するアプリケーションが存在する場合、そのアプ

リケーションが使用する資源にCORBAサービスの資源量を加算してください。

システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。

CORBAサービス

CORBAサービスで必要となるシステム資源について、以下に示します。

注意

各表に記述されているパラメタ名(max_IIOP_resp_conなど)は、CORBAサービスのconfigファイルで指定します。詳細

については、“A.1 config”を参照してください。

共用メモリ

パラメタ資源制御種類必要数

shmmax －設定値 Solarisのドキュメントおよび“■システムパラメタについて”を

参照して値を決定してください。

－ project.max-shm-memory

加算値 max_IIOP_resp_con × 0.4K ＋ limit_of_max_IIOP_resp_con(注1) × 0.5K ＋ max_IIOP_resp_con_extend_number(注2) × 0.1K ＋ max_IIOP_resp_requests × 8K ＋ limit_of_max_IIOP_resp_requests(注1) × 3K ＋ max_IIOP_resp_requests_extend_number(注2) × 0.1K ＋ limit_of_number_of_common_buffer(注8) × 5K ＋ number_of_common_buffer_extend_number(注2) × 0.1K＋ max_processes × 0.6K ＋ max_exec_instance × 0.2K ＋ max_impl_rep_entries × 12K ＋ (max_IIOP_resp_con ＋ limit_of_max_IIOP_resp_con(注1)× 2) × max_impl_rep_entries × 0.004K ＋ max_bind_instances(注7) × 0.1K ＋ 3,200K 以上

[SSL連携機能を使用する場合]上記値＋ limit_of_max_IIOP_resp_con × 5K 以上

[トレース機能を使用する場合]上記値＋ max_processes × trace_size_per_process ＋ trace_size_of_daemon(注3) ＋ 20K 以上

- 58 -


[スナップショット機能を使用する場合]上記値＋ snap_size ＋ (max_impl_rep_entries ＋ max_processes) × 0.1K 以上

[CORBAワークユニットを使用する場合]上記値＋ (Buffer Size ＋ 0.2KB) × Buffer Number × “Buffer Size、Buffer Number(ワークユニット定義)を指定し

たアプリケーション数” (注5)

shmmni project.max-shm-ids 加算値 max_IIOP_resp_con_extend_number(注2) ＋ max_IIOP_resp_requests_extend_number(注2) ＋ number_of_common_buffer_extend_number(注2) ＋ “Buffer Size、Buffer Number(ワークユニット定義)を指定し

たアプリケーション数” ＋ 13 (注6)

注1)

limit_of_[パラメタ名]のデフォルト値は以下となります。0が指定された場合も、以下と同様になります。

[パラメタ名] × 1.3 (小数部分切り捨て)isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場


注2)

[パラメタ名]_extend_numberのデフォルト値は以下となります。0が指定された場合も、以下と同様になります。

(limit_of_[パラメタ名] － [パラメタ名]) ÷ [パラメタ名] (小数部分切り上げ)isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場

合は、0となります。

注3)

デフォルトは以下です。0が指定された場合も、以下と同様になります。

trace_size_per_process × 32

注4)


max_IIOP_resp_requests × 0.2

注5)

Buffer Size、Buffer Numberを指定したCORBAワークユニット定義の中で、“(Buffer Size ＋ 0.2KB) × BufferNumber”の大値に、“Buffer Size、Buffer Number(ワークユニット定義)を指定したアプリケーション数”を積算した

値が該当します。

なお、“(Buffer Size ＋ 0.2KB) × Buffer Number”の大値が 2,147,483,647より小さい値になるようにBuffer Size、

Buffer Numberの値を設定してください。

注6)

マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。

マルチシステム機能はInterstage Application Server Enterprise Editionで使用できます。

注7)


max_processes × 1024 (計算結果が65,535を超えた場合は65,535)

注8)


limit_of_max_IIOP_resp_requests

共用メモリ

- 59 -

パラメタ種類必要数

kernel.shmmax 設定値以下の値のうち、大値を指定します。

・ max_IIOP_resp_con × 16K ＋ (max_IIOP_resp_con_extend_number(注1) ＋ 1) ×

0.2K ＋ max_IIOP_resp_requests × 16K ＋ (max_IIOP_resp_requests_extend_number(注1) ＋ 1)× 0.2K ＋ max_impl_rep_entries × 6K ＋ max_bind_instances(注5) × 0.1K ＋ 100K 以上

－ [trace_use=yesの場合]上記値＋ max_processes × trace_size_per_process ＋ trace_size_of_daemon(注2) ＋ 20K 以上

－ [snap_use=yesの場合]上記値＋ snap_size ＋ 10K 以上

・ number_of_common_buffer(注3) × 4K 以上＋ (number_of_common_buffer_extend_number(注1) ＋

1) × 0.2K

・ max_exec_instance × 0.15KB 以上

・ [Buffer Size、Buffer Number(ワークユニット定義)を指定

したCORBAワークユニット、IJServer起動時](Buffer Size ＋ 0.2K) × Buffer Number 以上 (注4)

kernel.shmmni 加算値 max_IIOP_resp_con_extend_number(注1) ＋ max_IIOP_resp_requests_extend_number(注1) ＋ number_of_common_buffer_extend_number(注1) ＋ “Buffer Size、Buffer Number(ワークユニット定義)を指定し

たアプリケーション数” ＋ 14

注1)


limit_of_[パラメタ名]は、0が指定された場合は自動計算されます。計算式の詳細については、“config”を参照してく

ださい。



注2)


trace_size_per_process × 32

注3)


max_IIOP_resp_requests × 0.2

注4)

Buffer Size、Buffer Numberを指定したワークユニット定義の中で、“(Buffer Size ＋ 0.2KB) × Buffer Number”の

大値が該当します。

なお、“(Buffer Size ＋ 0.2KB) × Buffer Number”の大値が 2,147,483,647より小さい値になるようにBuffer Size、

Buffer Numberの値を設定してください。

- 60 -

注5)


max_processes × 1024 (計算結果が65,535を超えた場合は65,535)

セマフォ


semmni project.max-sem-ids 加算

値

以下の値のうち、大値を指定します。

・ 512

・ max_IIOP_resp_con_extend_number(注1) × 5 ＋ max_IIOP_resp_requests_extend_number(注1) ＋ max_impl_rep_entries ＋プロセスモードのCORBAサーバアプリケーションの起

動プロセス数(注2) ＋“Buffer Size、Buffer Number(ワークユニット定義)を指

定したアプリケーション数” × 2 ＋ 100 以上

semmsl process.max-sem-nsems

設定

値

以下の値のうちの大値以上の値を指定します。

・ max_IIOP_resp_con

・ max_processes

semopm process.max-sem-ops 設定

値

50 以上

注1)




注2)

起動プロセス数が分からない場合はmax_processesを指定してください。

セマフォ


para1 設定値以下の値のうちの大値以上の値を指定します。

・ max_IIOP_resp_con

・ max_processes

para2 加算値 limit_of_max_IIOP_resp_con(注1) × 4 ＋ max_IIOP_resp_con_extend_number(注2) ＋ max_IIOP_resp_requests_extend_number(注2) ＋ max_impl_rep_entries ＋ max_processes × 4 ＋プロセスモードのCORBAサーバアプリケーションの起動プ

ロセス数(注3) ＋“Buffer Size、Buffer Number(ワークユニット定義)を指定し

たアプリケーション数” × 2 ＋ 14 以上

[トレース機能を使用する場合]上記値＋ 1 以上

[スナップショット機能を使用する場合]上記値＋ 1 以上

- 61 -


[SSL連携機能を使用する場合]上記値＋ limit_of_max_IIOP_resp_con(注1) 以上

para3 設定値 50 以上

para4 加算値以下の値のうち、大値を指定します。

・ 512

・ max_IIOP_resp_con_extend_number(注2) × 5 ＋ max_IIOP_resp_requests_extend_number(注2) ＋ max_impl_rep_entries ＋プロセスモードのCORBAサーバアプリケーションの起

動プロセス数(注3) ＋“Buffer Size、Buffer Number(ワークユニット定義)を指

定したアプリケーション数” × 2 ＋ 100 以上

注1)

limit_of_[パラメタ名]のデフォルト値は以下となります。0が指定された場合も、以下と同様になります。

[パラメタ名] × 1.3 (小数部分切り捨て)isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場


注2)




注3)

起動プロセス数が分からない場合はmax_processesを指定してください。



msgmnb process.max-msg-qbytes 設定値 32,768 以上

msgmni project.max-msg-ids 加算値 512 以上



kernel.msgmax 設定値 16,384 以上

kernel.msgmnb 設定値 32,768 以上

kernel.msgmni 加算値 512 以上

インタフェースリポジトリ

インタフェースリポジトリを使用する場合に必要となるシステム資源を以下に示します。

共用メモリ




- 62 -



加算値 [ログ採取時(EJBサービス未使用)](logging memory size ＋ 16K) × 3 (注)

[ログ採取時(EJBサービス使用)]

(logging memory size ＋ 16K) × 4 (注)

shmmni project.max-shm-ids 加算値 [EJBサービスを使用しない場合]3

[EJBサービスを使用する場合]

4

注)

“logging memory size”は、CORBAサービスのirconfigファイルで指定します。詳細については、“A.6 irconfig”を参

照してください。

共用メモリ


kernel.shmmax 設定値 [ログ採取時]logging memory size ＋ 16K (注)

注)

“logging memory size”は、CORBAサービスのirconfigファイルで指定します。詳細については、“A.6 irconfig”を参


ネーミングサービス

ネーミングサービスにネーミングコンテキストを多数作成する場合に必要となるシステム資源を、以下に示します。


(注) 加算値ネーミングコンテキスト数＋ 16 以上

注)

プロセス数あたりのオープン可能なファイル数です。該当するパラメタはありません。

bash(Linux)または、ボーンシェルの場合はulimitコマンドを、Cシェルの場合はlimitコマンドを使用して、ネーミング

サービスのプロセスが必要とするファイルをオープンできるだけの値を設定してください。コマンドの詳細については、

OSのドキュメントを参照してください。

■アプリケーションで使用するスレッド数・プロセス数

CORBAサービスでアプリケーションを実行する場合、アプリケーションから生成されるプロセス数・スレッド数が多くなる

場合には、システムパラメタを変更する必要があります。

アプリケーションをマルチスレッドで作成している場合に、生成されるスレッド数の目安を以下に示します。

分類スレッド数

CORBAサービス 25個＋クライアントアプリケーションとの接続数

＋ CORBAアプリケーションプロセス数

サーバアプリケーション 1プロセスにつき (6個＋スレッド多重度数)

クライアントアプリケーション 1プロセスにつき8個

システムパラメタで、変更が必要となるものを以下に示します。

- 63 -

パラメタ内容

max_nprocs システム全体で生成できるプロセス数

kernel.threads-max システム全体で生成できるプロセス数とスレッド数の合計

システムパラメタ以外で、考慮するパラメタを以下に示します。

パラメタ内容

(注1) プロセスの大スタックサイズ

(注2) 1人のユーザが使用できる大のプロセス数

注1)

該当するパラメタはありません。

bashまたはボーンシェルの場合はulimitコマンドを、Cシェルの場合はlimitコマンドを使用して設定してください。この

値にスレッド数を掛けた値が、プロセスのスタック領域として使用されます。1つのプロセスで使用可能なメモリを超過

してスレッドは生成できないため、1つのプロセスが生成できるスレッド数は限界があります。

CORBAサーバアプリケーションおよびEJBアプリケーションのリクエスト処理多重度は“スレッド多重度 × プロセス多

重度”で計算されます。1つのプロセスで使用可能なメモリサイズによってスレッド多重度を上げることができない場合

は、プロセス多重度を上げることを検討してください。CORBAサーバアプリケーションのスレッド多重度・プロセス多重

度については“リファレンスマニュアル(コマンド編)”の“OD_impl_inst”に記載されているproc_conc_max、thr_conc_init、thr_conc_maximumを参照してください。

EJBアプリケーションのスレッド多重度については、“J2EE ユーザーズガイド(旧版互換)”－“EJBコンテナのチューニ

ング”に記載されている“同時処理数”を参照してください。

注2)

該当するパラメタはありません。

bashまたはボーンシェルの場合はulimitコマンドを、Cシェルの場合はlimitコマンドを使用して設定してください。ユー

ザが生成するプロセス数とスレッド数の合計値以上の値に設定してください。

■ファイルディスクリプタ数

CORBAサービスで多数のアプリケーションを動作させ(多端末接続時など)、使用するファイルディスクリプタ数がシステ

ムのデフォルト値を超える場合は、システムパラメタにその値を設定してください。

パラメタ内容

rlim_fd_cur(システムパラメタ)

使用するファイルディスクリプタ数がデフォルト値を超える場

合に設定。

システムパラメタで、変更が必要となるものを以下に示します。

パラメタ内容

fs.file-max システム全体のファイルディスクリプタの上限値。

システムパラメタ以外で、考慮するパラメタを以下に示します。

- 64 -

パラメタ内容

nofile (注1) 各ユーザのオープン可能なファイルディスクリプタの上限値

注1)

/etc/security/limits.conf ファイルを編集します。limits.conf ファイルの詳細については、オペレーティングシステムのド

キュメントを参照してください。

3.1.2 コンポーネントトランザクションサービスのシステム資源の設定

コンポーネントトランザクションサービスの動作時には、使用する機能によりシステム資源を拡張する必要があります。ここ

では、以下について説明します。


－コンポーネントトランザクションサービスの基本機能

－セション情報管理機能

－性能監視ツール

注意

以降に示す値は、CORBAサービスの値を含んでいません。“3.1.1 CORBAサービスのシステム資源の設定”を参照し、

必要な値を加算してください。


コンポーネントトランザクションサービスが使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニ

ングについて説明します。

コンポーネントトランザクションサービスの基本機能のほかに各機能を使用する場合は、コンポーネントトランザクション

サービスの基本機能の資源に各機能で使用する資源量を加算してください。


コンポーネントトランザクションサービスの基本機能

コンポーネントトランザクションサービスの基本機能を使用する場合に必要となるシステム資源について、以下に示しま

す。

共用メモリ



加算値 Interstage Application Server Enterprise Editionの場合

・ラッパーワークユニット未使用時

－システム規模がsmallの場合

36096468以上

－システム規模がmoderateの場合

48500404以上

－システム規模がlargeの場合

61728660以上

－システム規模がsuperの場合

83718036以上

- 65 -


・ラッパーワークユニット使用時

－システム規模がsmallの場合

36222932以上

－システム規模がmoderateの場合

48744628以上

－システム規模がlargeの場合

62914964以上

－システム規模がsuperの場合

86081940以上


・システム規模がsmallの場合

35971540以上

・システム規模がmoderateの場合

48257716以上

・システム規模がlargeの場合

60543892以上

・システム規模がsuperの場合

81355668以上


・ 35971540以上

shmmax －設定値 Interstage Application Server Enterprise Edition/ InterstageApplication Server Standard-J Editionの場合

・システム規模がsmallの場合

12498508以上

・システム規模がmoderateの場合

23736108以上

・システム規模がlargeの場合

34973708以上

・システム規模がsuperの場合

54736908以上


・ 12498508以上

shmmni project.max-shm-ids 加算値 22 (注)

注)



共用メモリ


kernel.shmmax 設定値

[システム規模がsmallの場合]12498508以上

- 66 -


[システム規模がmoderateの場合]23736108以上

[システム規模がlargeの場合]34973708以上

[システム規模がsuperの場合]54736908以上

18,219,144 以上

kernel.shmmni 加算値 22

セマフォ



値

29 (注)


設定

値

12 以上 (注)


値

3 以上

注)



セマフォ



para2 加算値 21


para4 加算値 29



msgmnb process.max-msg-qbytes 設定値 4,572 ＋ (528 × 同時実行コマンド数) (注1)

msgmni project.max-msg-ids 加算値 11 (注2)


設定値 15 ＋同時実行コマンド数以上(注1)(注2)(注3)

注1)

同時実行コマンド数とは、以下のコマンドを同時に実行した数のことです。

－ Interstage Application Server Enterprise Editionの場合

isstartwu、isstopwu、tdstartwu、tdstopwu、tdinhibitobj、tdpermitobj、tdmodifyprocnum、tdmodifywu

- 67 -

－ Interstage Application Server Standard-J Editionの場合

isstartwu、isstopwu

また、Systemwalker Operation Manager、Interstage運用APIを使用してワークユニットの起動/停止、オブジェクト閉

塞/閉塞解除、ラッパーワークユニットのオブジェクト情報の獲得を行う場合は、同時に操作する回数が同時実行コマ

ンド数となります。

オブジェクト閉塞/閉塞解除、ラッパーワークユニットのオブジェクト情報の獲得はInterstage Application Server EnterpriseEditionで使用できます。

注2)



注3)

AIM連携機能を使用する場合は、2,040を加算してください。

AIM連携機能は、Interstage Application Server Enterprise Editionで使用できます。



kernel.msgmax 設定値 528 以上

kernel.msgmnb 設定値 4,572 ＋ (528 × 同時実行コマンド数) (注)

kernel.msgmni 加算値 11

注)

同時実行コマンド数とは、以下のコマンドを同時に実行した数のことです。

－ Interstage Application Server Enterprise Editionの場合

isstartwu、isstopwu、tdstartwu、tdstopwu、tdinhibitobj、tdpermitobj、tdmodifyprocnum、tdmodifywu

－ Interstage Application Server Standard-J Editionの場合

isstartwu、isstopwu

－ isstartwu 、 isstopwu 、 tdstartwu 、 tdstopwu 、 tdinhibitobj 、 tdpermitobj 、 tdmodifyprocnum 、 tdmodifywu

また、以下を使用してワークユニットの起動/停止、オブジェクト閉塞/閉塞解除を行う場合は、同時に操作する回数が

同時実行コマンド数となります。

－ Systemwalker Operation Manager

－ Interstage運用API

オブジェクト閉塞/閉塞解除はInterstage Application Server Enterprise Editionで使用できます。

セション情報管理機能

セション情報管理機能を使用する場合に追加となるシステム資源について、以下に示します。

共用メモリ


shmmni project.max-shm-ids 加算

値

1 (注)

- 68 -

注)



共用メモリ



セマフォ



値

1 (注)

注)



セマフォ


para2 加算値 1

para4 加算値 1

性能監視ツール

性能監視ツールを使用する場合に追加となるシステム資源については、“3.3 性能監視ツール使用時に必要なシステ

ム資源”を参照してください。

3.1.3 データベース連携サービスのシステム資源の設定

データベース連携サービスの動作時には、利用するシステム形態によりシステム資源を拡張する必要があります。ここで

は、以下について、利用するシステム形態ごとに説明します。


－ OTSシステムのみが動作する場合

－リソース管理プログラムのみが動作する場合

－ OTSシステムとリソース管理プログラムの両方が動作する場合


データベース連携サービスが使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニングについ

て、システム形態ごとに説明します。


- 69 -

OTSシステムのみが動作する場合

OTSシステムのみが動作する場合に必要となるシステム資源について、以下に示します。

共用メモリ



加算値 17,830,204 (注)

shmmax －設定値 17,830,204以上 (注)

shmmni project.max-shm-ids 加算値 12

共用メモリ


kernel.shmmax 設定値 17,830,204 (注)


注)

以下のファイルのデフォルト値で算出した値です。

－データベース連携サービスの環境定義のconfigファイル

OTS_TRACE_SIZE = 4096RECOVERY_TRACE_SIZE = 4096OBSERVE_TRACE_SIZE = 4096

－データベース連携サービスの環境定義のセットアップ情報ファイル

TRANMAX = 100PARTICIPATE = 4

定義値を変更した場合は、以下の計算式で算出してください。

必要数＝(OTS_TRACE_SIZE ＋ RECOVERY_TRACE_SIZE ＋ OBSERVE_TRACE_SIZE) ×1,024 ＋ PARTICIPATE × TRANMAX × 2,048 ＋ TRANMAX × 284 ＋ 4,399,692

必要数＝(OTS_TRACE_SIZE ＋ RECOVERY_TRACE_SIZE ＋ OBSERVE_TRACE_SIZE) ×1,024 ＋ PARTICIPATE × TRANMAX × 2,560 ＋ TRANMAX × 284 ＋ 4,399,692

セマフォ



値

8


設定

値

12 以上


値

3 以上

セマフォ

- 70 -



para2 加算値 24


para4 加算値 8




msgmni project.max-msg-ids 加算値 3


設定値 2,040以上






リソース管理プログラムのみが動作する場合

リソース管理プログラムのみが動作する場合に必要となるシステム資源について、以下に示します。

共用メモリ



加算値 12,840,416 (注)


shmmni project.max-shm-ids 加算値リソース管理プログラムの種類 × 11

共用メモリ



kernel.shmmni 加算値リソース管理プログラムの種類 × 11

注)

リソース管理プログラムの種類が1つの場合で、かつ以下のファイルのデフォルト値で算出した値です。

－データベース連携サービスの環境定義のconfigファイル

RESOURCE_TRANMAX = 10

- 71 -

RESOURCE_TRACE_SIZE = 4096OBSERVE_TRACE_SIZE = 4096

－リソース定義ファイル

OTS_RMP_PROC_CONC = 5

－データベース連携サービスの環境定義のセットアップ情報ファイル

TRANMAX = 100


必要数＝(RESOURCE_TRACE_SIZE ＋ OBSERVE_TRACE_SIZE) × 1,024 ＋ (TRANMAX ＋ 1) × 332 ＋ ((リソース管理プログラムの種類 × RESOURCE_TRANMAX × OTS_RMP_PROC_CONC) × (144 ＋ 332)) ＋ 4,394,476

セマフォ



値

リソース管理プログラムの種類 × 7

セマフォ


para4 加算値リソース管理プログラムの種類 × 7

OTSシステムとリソース管理プログラムの両方が動作する場合

OTSシステムとリソース管理プログラムの両方が動作する場合に必要となるシステム資源について、以下に示します。

共用メモリ



加算値 17,830,204(注)


shmmni project.max-shm-ids 加算値 12 ＋リソース管理プログラムの種類 × 11

共用メモリ



kernel.shmmni 加算値 12 ＋リソース管理プログラムの種類 × 11

注)

リソース管理プログラムの種類が1つの場合で、かつデフォルト値で算出した値です。


必要数＝

- 72 -

OTSシステムのみが動作する場合の必要数＋リソース管理プログラムのみが動作する場合の必要数－ 4,915,600

セマフォ



値

8 ＋リソース管理プログラムの種類 × 7


設定

値

12 以上


値

3 以上

セマフォ



para2 加算値 24


para4 加算値 8 ＋リソース管理プログラムの種類 × 7






設定値 2,040以上






3.1.4 イベントサービスのシステム資源の設定

イベントサービスを用いたシステムの運用時には、チャネル数、接続するコンシューマ/サプライヤ数などによりシステム資

源を拡張する必要があります。ここでは、以下について説明します。


- 73 -

注意

以降に示す値は、CORBAサービスの値を含んでいません。“3.1.1 CORBAサービスのシステム資源の設定”を参照し、

必要な値を加算してください。


一般的なイベントサービスが使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニングについ

て説明します。

イベントサービスの他に共用メモリ、セマフォ、メッセージキューを使用するアプリケーションが存在する場合、そのアプリ

ケーションが使用する資源にイベントサービスの資源量を加算してください。


注意

揮発チャネル運用と不揮発チャネル運用を併用している場合は、不揮発チャネル運用の必要数を使用してください。

共用メモリ



加算値 [揮発チャネル運用の場合]以下の値を加算します。

・ 1,040 × イベントチャネル大作成数(注1) ＋ 600K

・ traceconfigファイルのtrace_sizeパラメタに指定したバイ

ト数

[不揮発チャネル運用の場合]以下の値を加算します。

・ 1,040 × イベントチャネル大作成数(注1) ＋ 184 × 同時実行可能なグローバルトランザクション数

(注2) ＋ 600K

・ 17 × 1,024 × 1,024 ＋ 576 × トランザクションの多重度＋ 88 × (システム用データ格納域の数＋イベントデータ用データ格納域の数) ＋ユニットで使用する共用メモリサイズ × 1,024 × 1,024(注3)


ト数

・ [MessageQueueDirectorのイベントチャネル連携サービ

スのパッキング転送機能を使用する場合]イベントデータの平均サイズ(注4) × packmsg_cntキーワード値(注5) × 23 － 42 × 1,024 × 1,024

shmmax －設定値 [揮発チャネル運用の場合]以下の値のうち、大値を指定します。

・ 1,040 × イベントチャネル大作成数(注1) ＋ 600K


ト数

- 74 -


[不揮発チャネル運用の場合]以下の値のうち、大値を指定します。

・ 1,040 × イベントチャネル大作成数(注1) ＋ 184 × 同時実行可能なグローバルトランザクション数

(注2) ＋ 600K

・ 17 × 1,024 × 1,024 ＋ 576 × トランザクションの多重度＋ 88 × (システム用データ格納域の数＋イベントデータ用データ格納域の数) ＋ユニットで使用する共用メモリサイズ × 1,024 × 1,024(注3)


ト数

・ [MessageQueueDirectorのイベントチャネル連携サービ

スのパッキング転送機能を使用する場合]イベントデータの平均サイズ(注4) × packmsg_cntキーワード値(注5) × 23 － 42 × 1,024 × 1,024

shmmni project.max-shm-ids 加算値 [揮発チャネル運用の場合]4

[不揮発チャネル運用の場合]ユニット数 × 100 以上

注1)

イベントチャネル大作成数＝静的生成イベントチャネル大作成数＋動的生成イベントチャネル大作成数

注2)

同時実行可能なグローバルトランザクション数は、essetcnfコマンドでイベントサービスの構成情報を設定した際、-gtrnmaxオプションに指定した値です。

注3)

各値は、ユニット作成コマンド(esmkunitでユニットを作成した際、ユニット定義の以下の項目に指定した値です。

なお、複数のユニットを使用する場合は、それぞれのユニットに対して、算出してください。

ユニット定義の項目

トランザクションの多重度 tranmaxの設定値

システム用データ格納域の数 sysqnumの設定値

イベントデータ用データ格納域の数 userqnumの設定値

ユニットで使用する共用メモリサイズ shmmaxの設定値(42より小さい場合、42)

注4)

イベントデータの平均サイズは、以下の計算式で算出してください(小数点以下、切り上げ)。Ev_size: アプリケーション内で送受信するイベントデータの平均サイズ

－ [Ev_sizeが2Kバイト以内の場合]イベントデータの平均サイズ＝ ((Ev_size ＋ 1) ÷ 512) × 512

－ [Ev_sizeが2Kバイトを超える場合]イベントデータの平均サイズ＝ 2K ＋ ((Ev_size － 2K) ÷ 16K) × 16K

- 75 -

注5)

packmsg_cntキーワード値は、MessageQueueDirectorのイベントチャネル連携サービスのサービス定義に指定した

CHANNELセクションのpackmsg_cntキーワード値です。

共用メモリ


kernel.shmmax 設定値 [揮発チャネル運用の場合]2,064 × イベントチャネル大作成数(注1) ＋ 600K ＋traceconfigファイルのtrace_sizeパラメタに指定した

バイト数＋ 3,328

[不揮発チャネル運用の場合]以下の値のうち、大値を指定します。

・ 2,064 × イベントチャネル大作成数(注1) ＋ 184 × 同時実行可能なグローバルトランザクション数(注2) ＋ 600K ＋traceconfigファイルのtrace_sizeパラメタに指定

したバイト数＋ 3,328

・ 134,217,728 以上

・ユニットで使用する共用メモリサイズ(複数ユニットがある

場合、大値)(注3)

kernel.shmmni 加算値 [揮発チャネル運用の場合]

・プロセス単位で内部トレースを採取する(traceconfigファ

イルのtrace_buffer=process)場合

4 ＋イベントチャネルのプロセス数(注4)

・イベントサービス単位で内部トレースを採取する

(traceconfigファイルのtrace_buffer=system)場合

4

[不揮発チャネル運用の場合]

・プロセス単位で内部トレースを採取する(traceconfigファ

イルのtrace_buffer=process)場合

100 以上の値 (ユニット単位に加算) ＋イベントチャネ

ルのプロセス数(注4)

・イベントサービス単位で内部トレースを採取する

(traceconfigファイルのtrace_buffer=system)場合

100 以上の値 (ユニット単位に加算)

注1)

イベントチャネル大作成数＝静的生成イベントチャネル大作成数＋動的生成イベントチャネル大作成数

注2)

同時実行可能なグローバルトランザクション数は、essetcnfコマンドでイベントサービスの構成情報を設定した際、-gtrnmaxオプションに指定した値です。

注3)

ユニットで使用する共用メモリサイズは、esmkunitコマンドでユニットを作成した際、ユニット定義ファイルの項目「shmmax」

に指定した値です。

- 76 -

注4)

イベントチャネルのプロセス数＝静的イベントチャネルグループ数＋動的イベントチャネルのプロセス数

動的イベントチャネルのプロセス数:essetupコマンドでイベントサービスをセットアップした際、-pオプションに指定した値です。

ノーティフィケーションサービスを使用している場合は、「動的イベントチャネルのプロセス数 × 2」としてください。

セマフォ



値

3

セマフォ


para1 設定値 29

para2 加算値 [揮発チャネル運用の場合]6 以上

[不揮発チャネル運用の場合]ユニット数 × 29 ＋ 13 以上

para3 設定値 29

para4 加算値ユニット数 × 256



msgmnb process.max-msg-qbytes 設定値 [不揮発チャネル運用の場合]4,096 以上

msgmni project.max-msg-ids 加算値 [揮発チャネル運用の場合]2

[不揮発チャネル運用の場合]ユニット数 × 3 ＋ 2


設定値 [不揮発チャネル運用の場合]以下をユニットごとに求めた合計値

6 ＋ (ユニット定義ファイルのtranmax値 × 4 × 1.3)



kernel.msgmax 設定値 [不揮発チャネル運用の場合]2,048 以上

kernel.msgmnb 設定値 [不揮発チャネル運用の場合]4,096 以上

kernel.msgmni 加算値 [不揮発チャネル運用の場合]ユニット数 × 9

- 77 -

3.1.5 J2EE互換のシステム資源の設定

IJServerまたはEJBサービスでは以下の機能を使用する場合に、システム資源を拡張する必要があります。ここでは、以

下について説明します。



IJServerまたはEJBサービスを使用する際には、以下のシステムパラメタのチューニングを行ってください。

ワークユニット定義の通信バッファ数(Buffer Number)、通信バッファ長(BufferSize)を指定する場合は、“3.1.1 CORBAサービスのシステム資源の設定”についても参照してください。





msgmni project.max-msg-ids 加算値 2 以上


設定値 1,024 以上





kernel.msgmni 加算値 2 以上

3.1.6 Interstage HTTP Serverのシステム資源の設定

Interstage HTTP Serverを用いたシステムの運用時には、システム資源を拡張する必要があります。ここでは、以下につ



・ファイルディスクリプタ


Interstage HTTP Serverを運用するためのサービスが使用するセマフォのシステムパラメタのチューニングについて説明

します。

システムパラメタの変更方法や、パラメタの意味については、“■システムパラメタについて”を参照してください。

セマフォ


para1 設定値 1以上

para2 加算値 Webサーバ数×2

- 78 -



para4 加算値 Webサーバ数×2


Interstage HTTP Serverを運用するために必要なファイルディスクリプタ数は、Webサーバで使用している機能、および環

境定義ファイル(httpd.conf)の定義内容に応じて異なります。

以下の表を参照して必要なファイルディスクリプタ数を算出してください。本値がシステムのデフォルト値を超える場合

は、システムパラメタに本値を設定してください。システムパラメタの変更方法や、パラメタの意味については、“■システ

ムパラメタについて”を参照してください。


rlim_fd_cur 設定値 130 以上

[以下の機能を使用する場合]上記に以下の値を加算してください。

・基本認証機能：1

・オンライン照合機能：1

・ SSL運用：21

・プロキシ機能：1

・ CGI機能（注）：5

[環境定義ファイル(httpd.conf)で以下のディレクティブを追

加した場合]上記に以下の値を加算してください。

・ CustomLog(ihsrlogコマンド実行文の指定時)：10×ディ

レクティブ数

・ CustomLog(ihsrlogコマンド実行文の未指定時)：1×ディ

レクティブ数

・ ErrorLog：1×ディレクティブ数

・ Listen：1×ディレクティブ数

注）

動作するCGIプログラム内で必要となるファイルディスクリプタの数は、別途加算してください。

以下の表を参照して必要なファイルディスクリプタ数を算出してください。

リソース制限については、本値がシステムのデフォルト値を超える場合、/etc/security/limits.confファイルに本値を設定し

てください。リソース制限の変更方法や、パラメタの意味については、“◆リソース制限 ”を参照してください。

システムパラメタについては、ファイルディスクリプタ数が不足する現象が発生した場合、システムパラメタに本値を加算

設定してください。複数のWebサーバを作成している場合は、Webサーバごとに必要数を加算してください。システムパ

ラメタの変更方法や、パラメタの意味については、“■システムパラメタについて”を参照してください。

- 79 -


[リソース制限]nofile

設定値 20 以上

[以下の機能を使用する場合]上記に以下の値を加算してください。

・基本認証機能：1

・オンライン照合機能：1

・ SSL運用：21

・プロキシ機能：1

・ CGI機能（注）：5

[環境定義ファイル(httpd.conf)で以下のディレクティブを追

加した場合]上記に以下の値を加算してください。

・ CustomLog(ihsrlogコマンド実行文の指定時)：2×ディレ

クティブ数

・ CustomLog(ihsrlogコマンド実行文の未指定時)：1×ディ

レクティブ数

・ ErrorLog：1×ディレクティブ数

・ Listen：1×ディレクティブ数

[システムパラメタ]fs.file-max

加算値上記と同じ値

注）

動作するCGIプログラム内で必要となるファイルディスクリプタの数は、別途加算してください。

3.1.7 MessageQueueDirectorのシステム資源の設定

MessageQueueDirectorを用いたシステムの運用時には、MQDのシステム数およびMQDの上位サービスの種類などに

よりシステム資源を拡張する必要があります。ここでは、以下について説明します。


・ファイルディスクリプタ数


MessageQueueDirectorが使用するシステムパラメタのチューニングについて説明します。


共用メモリ


shmmax －設定値 MessageBufferMaxSize × 1,000,000 以上


加算値 MessageBufferMaxSize × 1,000,000 × MQDシステム数

shmmni project.max-shm-ids 加算値 100 × MQDシステム数

共用メモリ

- 80 -


kernel.shmmax 設定値 134,217,728 以上

kernel.shmmni 加算値 100 × MQDシステム数

セマフォ


para1 設定値 29

para2 加算値 MQDシステム数 × 29

para3 設定値 29

para4 加算値 MQDシステム数 × 256



msgmnb process.max-msg-qbytes 設定値 44 × 1,024 × 4 × 1.3 (注1)

msgmni project.max-msg-ids 加算値 3 × MQDのシステム数

msgtql －加算値 [MQDのアプリケーションインタフェースを使用する場合]MQDシステム数 × (6 ＋ (1,024 × 4 × 1.3)) (注1)

[MQDのアプリケーションインタフェースを使用しない場合]MQDシステム数 × (6 ＋ (n × 4 × 1.3)) (注1)(注2)

－ process.max-msg-messages

設定値 [MQDのアプリケーションインタフェースを使用する場合]MQDシステム数 × (6 ＋ (1,024 × 4 × 1.3)) 以上 (注1)

[MQDのアプリケーションインタフェースを使用しない場合]MQDシステム数 × (6 ＋ (n × 4 × 1.3)) 以上 (注1)(注2)

注1)

1.3は余裕値です。

注2)

MQDの拡張機能を使用する場合、nには以下の式に従った値をいれてください。また、nには3以上の数値をいれて

ください。

拡張機能 nの値

イベントチャネル連携サービス(非同期メッセー

ジ基盤にMQDを使用する場合)3 ＋送信キュー数＋受信キュー数を加算

イベントチャネル連携サービス(非同期メッセー

ジ基盤にMQDを使用しない場合)3 を加算

同報配信サービス同報配信グループ数＋ 1 を加算

SMTP連携サービス 3 ＋送信キュー数 × 2 ＋受信キュー数＋100 を加算





kernel.msgmni 加算値 9 × MQDシステム数

- 81 -


MessageQueueDirectorでSMTP連携サービスを使用する場合には、MQDを起動するshellに対してulimitコマンドで設

定するパラメタを変更する必要があります。

パラメタ内容

descriptors 20 ＋ (送信キュー数定義数 × 2)

3.1.8 Interstage シングル・サインオンのシステム資源の設定

Interstage シングル・サインオンを用いたシステムの運用時には、システム資源を拡張する必要があります。ここでは、以

下について説明します。


－ Interstage シングル・サインオンのリポジトリサーバ機能を使用する際のシステムパラメタのチューニング

－ Interstage シングル・サインオンの認証サーバ機能を使用する際のシステムパラメタのチューニング

－ Interstage シングル・サインオンの業務サーバ機能を使用する際のシステムパラメタのチューニング


Interstage シングル・サインオンが使用するシステムパラメタのチューニングについて説明します。


なお、以降に示す値は、Interstage HTTP Serverで必要な値を含んでいません。“Interstage HTTP Serverのシステム資

源の設定”を参照し、必要な値を加算してください。

Interstage シングル・サインオンのリポジトリサーバ機能を使用する際のシステムパラメタのチューニング

リポジトリサーバでは、“Interstage ディレクトリサービス”を使用しています。“Interstage ディレクトリサービス”で必要とし

ているチューニングについては、“3.1.9 Interstage ディレクトリサービスのシステム資源の設定”を参照してください。

共用メモリ





加算値 26,000,000 ＋ (164 × サイト定義数(注1)) ＋ (ロール数(注2) ＋ロールセット数(注3) ＋ロールセット数(注3) × ロール数(注2)) × 1,024 × 3 (注4)


注1)

SSOリポジトリの保護リソースに登録したサイト定義の総数

注2)

SSOリポジトリに定義したロールの総数

注3)

SSOリポジトリに定義したロールセットの総数

- 82 -

注4)

ユーザ情報を登録するディレクトリサービスにActive Directoryを使用し、シングル・サインオンの拡張スキーマを使用

しない場合は、運用に応じて以下の式で見積もった値を加算してください。

Active Directoryのロール/ロールセットに使用する属性の総数 × 524 × 3

共用メモリ


kernel.shmmax 設定値 12,800,000 ＋ (164 × サイト定義数(注1)) ＋ (ロール数(注2) ＋ロールセット数(注3) ＋ロールセット数(注3) × ロール数(注2)) × 1,024 以上(注4)


注1)

SSOリポジトリの保護リソースに登録したサイト定義の総数

注2)


注3)

SSOリポジトリに定義したロールセットの総数

注4)

ユーザ情報を登録するディレクトリサービスにActive Directoryを使用し、シングル・サインオンの拡張スキーマを使用

しない場合は、運用に応じて以下の式で見積もった値を加算してください。

Active Directoryのロール/ロールセットに使用する属性の総数 × 524

セマフォ



値

9

セマフォ


para2 加算値 9

para4 加算値 9

Interstage シングル・サインオンの認証サーバ機能を使用する際のシステムパラメタのチューニング

共用メモリ





加算値 27,000,000 ＋パス定義の総数(注1) × 2,048


注1)

SSOリポジトリの保護リソースに登録した各サイト定義に定義したパス定義の総数

共用メモリ

- 83 -


kernel.shmmax 設定値 14,000,000 ＋パス定義の総数(注) × 2,048 以上


注)

SSOリポジトリの保護リソースに登録した各サイト定義に定義したパス定義の総数

セマフォ



値

10

セマフォ


para2 加算値 10

para4 加算値 10

Interstage シングル・サインオンの業務サーバ機能を使用する際のシステムパラメタのチューニング

共用メモリ





加算値 (13,000,000 ＋ (1 + キャッシュサイズ(注1)) × 1024 × キャッシュ数(注2) + (ロール数(注3) ＋拡張ユーザ情報数(注4)＋ 1) × パス定

義の大数(注5) × 1,200 × 2) × 業務サーバ数

shmmni project.max-shm-ids 加算値 10 × 業務サーバ数

注1)

セションの管理を行う運用の場合、業務サーバでキャッシュする利用者の認証情報サイズ(Kバイト)を設定します。セ

ションの管理を行わない運用の場合は、0で計算してください。

キャッシュサイズについては、“F.4 業務サーバを構築する場合のチューニング”を参照してください。

注2)

セションの管理を行う運用の場合、システムの同時アクセス大数以上を設定します。セションの管理を行わない運

用の場合は、0で計算してください。

キャッシュ数については、“F.4 業務サーバを構築する場合のチューニング”を参照してください。

注3)


注4)

業務アプリケーションに対して通知するユーザ情報の数

セションの管理を行う運用の場合、リポジトリサーバのInterstage管理コンソールの以下に設定されている属性名の数

を設定します。セションの管理を行わない運用の場合は、0で計算してください。

[システム] > [セキュリティ] > [シングル・サインオン] > [認証基盤] > [リポジトリサーバ] > [環境設定] > [リポジトリサー

バ詳細設定[表示]] > [業務システムに通知する情報] > [拡張ユーザ情報]

- 84 -

注5)

SSOリポジトリの保護リソースに登録した各サイト定義の保護パスに設定されているパス定義の大数

共用メモリ


kernel.shmmax 設定値 13,000,000 ＋(1 + キャッシュサイズ(注1)) × 1024 × キャッシュ数(注2) +(ロール数(注3) ＋拡張ユーザ情報数(注4)＋ 1) × パス定

義の大数(注5) × 1,200

kernel.shmmni 加算値 10 × 業務サーバ数

注1)

セションの管理を行う運用の場合、業務サーバでキャッシュする利用者の認証情報サイズ(Kバイト)を設定します。セ

ションの管理を行わない運用の場合は、0で計算してください。

キャッシュサイズについては、“F.4 業務サーバを構築する場合のチューニング”を参照してください。

注2)

セションの管理を行う運用の場合、システムの同時アクセス大数以上を設定します。セションの管理を行わない運

用の場合は、0で計算してください。

キャッシュ数については、“F.4 業務サーバを構築する場合のチューニング”を参照してください。

注3)


注4)

業務アプリケーションに対して通知するユーザ情報の数

セションの管理を行う運用の場合、リポジトリサーバのInterstage管理コンソールの以下に設定されている属性名の数

を設定します。セションの管理を行わない運用の場合は、0で計算してください。

[システム] > [セキュリティ] > [シングル・サインオン] > [認証基盤] > [リポジトリサーバ] > [環境設定] > [リポジトリサー

バ詳細設定[表示]] > [業務システムに通知する情報] > [拡張ユーザ情報]

注5)

SSOリポジトリの保護リソースに登録した各サイト定義の保護パスに設定されているパス定義の大数

セマフォ



値

7 × 業務サーバ数

セマフォ


para2 加算値 7 × 業務サーバ数

para4 加算値 7 × 業務サーバ数

3.1.9 Interstage ディレクトリサービスのシステム資源の設定

Interstage ディレクトリサービスを用いたシステムの運用時には、システム資源を拡張する必要があります。ここでは、以下

について説明します。

・システムパラメタ(Interstage ディレクトリサービスの運用に必要なシステム資源)

・システムパラメタ(標準データベースの運用に必要なシステム資源)

- 85 -

・システムパラメタ(Symfoware Serverの運用に必要なシステム資源)

・システムパラメタ(Oracleデータベースの運用に必要なシステム資源)

■システムパラメタ(Interstage ディレクトリサービスの運用に必要なシステム資源)

Interstage ディレクトリサービスが使用するシステムパラメタのチューニングについて説明します。


共用メモリ



加算値 (リポジトリ数 × 1,572,864 ＋ (5 × (リポジトリ数 × 1,843,200))(注1)) × (4 × リポジトリ数)

shmmax －設定値リポジトリ数 × 1,572,864 ＋ (5 × (リポジトリ数 × 1,843,200)) 以上 (注1)

shmmni project.max-shm-ids 加算値 4 × リポジトリ数(注2)

注1)

リポジトリのデータベースに標準データベースを使用してレプリケーション運用を行う場合は、さらに1,048,576を加算


注2)

リポジトリのデータベースに標準データベースを使用してレプリケーション運用を行う場合は、5 × リポジトリ数です。

共用メモリ


kernel.shmmax 設定値 5 × (リポジトリ数 × 1,843,200) 以上

kernel.shmmni 加算値 4 × リポジトリ数(注)

注)

リポジトリのデータベースに標準データベースを使用してレプリケーション運用を行う場合は、5 × リポジトリ数です。

リポジトリのデータベース運用に必要なシステム資源のチューニング

リポジトリのデータベースに標準データベースを使用する場合には、さらにシステム資源のチューニングが必要です。“シ

ステムパラメタ(標準データベースの運用に必要なシステム資源)”を参照して、システムパラメタを変更してください。

リポジトリのデータベースとしてRDBを使用する場合には、さらに、RDBの運用に必要なシステム資源をチューニングし

てください。以下の項目を参照して、システムパラメタを変更してください。

・ “システムパラメタ(Symfoware Serverの運用に必要なシステム資源)”

・ “システムパラメタ(Oracleデータベースの運用に必要なシステム資源)”

■システムパラメタ(標準データベースの運用に必要なシステム資源)

標準データベースを運用するには、omsアカウント環境の大ファイルディスクリプタ数のハードリミットが、256以上65,536以下となるように設定してください。

大ファイルディスクリプタ数のハードリミットを変更するには、以下を変更してください。

- 86 -

・システムパラメタを変更してください。システムパラメタの変更方法については、“■システムパラメタについて”を参照


・リソース制限を変更してください。システムパラメタの変更方法については、“◆リソース制限 ”を参照してください。



rlim_fd_max

process.max-file-descriptor 設定

値

256以上、65,536以下

資源制御で大ファイルディスクリプタ数のソフトリミットの設定を行った場合、ハードリミットが「無制限」に拡張されます。

ソフトリミットを設定した場合は、合わせてハードリミットも設定してください。

例

projmod -s -K 'process.max-file-descriptor=(basic,1024,deny),(priv,65536,deny)' default

なお、システム全体の大ファイルディスクリプタ数のハードリミットを、65,536より大きな値に設定したい場合、資源制御

を使用してください。「oms」プロジェクトを個別に設定してください。

例

projmod -s -K 'process.max-file-descriptor=(basic,1024,deny),(priv,524288,deny)' default

projmod -s -K 'process.max-file-descriptor=(basic,1024,deny),(priv,65536,deny)' oms

システムパラメタの場合は、システム全体に影響するため、設定値は、256以上65,5536以下で設定してください。



nofile hard 256以上、65,536以下

システム全体の大ファイルディスクリプタ数のハードリミットを、65,536より大きな値に設定したい場合、omsユーザを個

別に設定してください。

例

* hard nofile 524288

oms hard nofile 65536

■システムパラメタ(Symfoware Serverの運用に必要なシステム資源)

Symfoware Serverの運用に必要なシステムパラメタの設定は、Symfoware Serverをインストールしたマシンで変更してく

ださい。ただし、Symfoware Server Lite Editionを使用している環境では、本設定は不要です。

・ Symfoware ServerをSolarisにインストールした場合

・ Symfoware ServerをLinuxにインストールした場合

- 87 -

ここで示す各システムパラメタの必要数の値は、Symfoware Serverのシステム用動作環境ファイル、またはRDB構成パラ

メタファイルのパラメタに以下の値が設定されていることを前提としています。これらのパラメタの設定値を変更する場合

は、Symfoware Serverのマニュアルを参照して各システムパラメタの必要数を算出し直してください。

パラメタ設定値

ローカル接続で使用するメモリ量

(COMMUNICATION_BUFFER)32Kバイト

ローカル接続数

(MAX_CONNECT_SYS) (注1)256

デーモン多重度(RDBCNTNUM) 712

共有メモリ量(RDBEXTMEM) 13,208Kバイト

注1)

ローカル接続数は、Interstage ディレクトリサービスの使用時に必要となる、リポジトリからRDBへの大コネクション数

の合計に、他のアプリケーション等が使用するコネクション数を加えた値を算出してください。求めた値が、この設定

値(256)を超える場合には、各システムパラメタの必要数を算出し直してください。

リポジトリの大コネクション数の詳細は、“ディレクトリサービス運用ガイド”の“データベース共用”-“ 大コネクション

数の設定”を参照してください。

レプリケーション運用をするときは、Linkexpressの運用に必要なシステム資源の設定をしてください。設定内容は、

Linkexpressのインストールガイドを参照してください。

Solarisの場合は、「Linkexpressへの同時転送依頼数」を「1」、「Linkexpress同時ファイル転送多重度」を「4」として計算し

てください。また、システムパラメタ「shmmin」(共用メモリセグメントの小サイズ)は設定しないでください。

Symfoware ServerをSolarisにインストールした場合

共用メモリ

パラメタ

(注)資源制御種類必要数

shmmax project.max-shm-memory

設定値 13,524,992 以上


注)

パラメタ欄には、“shmsys:shminfo_xxxxxx”の“xxxxxx”を記載しています。

セマフォ



値

300


設定

値

48 以上

セマフォ

- 88 -

パラメタ



値

300


設定

値

48 以上

注)

パラメタ欄には、“semsys:seminfo_xxxxxx”の“xxxxxx”を記載しています。






設定値 64以上


パラメタ





加算値 64

注)

パラメタ欄には、“msgsys:msginfo_xxxxxx”の“xxxxxx”を記載しています。

Symfoware ServerをLinuxにインストールした場合

共用メモリ




セマフォ



para2 加算値 1,112

para3 すでに設定されている値

para4 加算値 300

- 89 -






■システムパラメタ(Oracleデータベースの運用に必要なシステム資源)

Oracleデータベースの運用に必要なシステムパラメタの設定は、Oracleデータベースをインストールしたマシンで変更し

てください。

・ OracleデータベースをSolarisにインストールした場合

・ OracleデータベースをLinuxにインストールした場合

レプリケーション運用をするときは、レプリケーションの運用に必要なシステム資源の設定をしてください。設定内容は、

Oracleデータベースのマニュアルを参照してください。

OracleデータベースをSolarisにインストールした場合

共用メモリ

パラメタ


shmmax project.max-shm-memory

設定値 4,294,967,295 以上

shmmni project.max-shm-ids 設定値 100 以上

注)

パラメタ欄には、“shmsys:shminfo_xxxxxx”の“xxxxxx”を記載しています。

セマフォ


semmni project.max-sem-ids 設定

値

100 以上

semmsl project.max-sem-nsems 設定

値

256 以上

セマフォ

パラメタ


semmni project.max-sem-ids 設定

値

100 以上

- 90 -

パラメタ


semmsl project.max-sem-nsems 設定

値

256 以上

注)

パラメタ欄には、“semsys:seminfo_xxxxxx”の“xxxxxx”を記載しています。

OracleデータベースをLinuxにインストールした場合

共用メモリ


kernel.shmall 設定値 2,097,152 以上

kernel.shmmax 設定値物理メモリのサイズ(バイト)の1/2 以上

kernel.shmmni 設定値 4,096 以上

セマフォ



para2 設定値 32,000 以上



ファイルシステム


fs.file-max( 大ファイル・ハンドル

数)

設定値 65,536 以上

ネットワーク


net.ipv4.ip_local_port_range(ポート番号の範囲)

設定値小：1,024大：65,000

net.core.rmem_default(受信用ウィンドウ・サイズのデ

フォルト値)

設定値 1,048,576 以上

net.core.rmem_max(受信用ウィンドウ・サイズの

大値)

設定値 1,048,576 以上

net.core.wmem_default(送信用ウィンドウ・サイズのデ

フォルト値)

設定値 262,144 以上

- 91 -


net.core.wmem_max(送信用ウィンドウ・サイズの

大値)

設定値 262,144 以上

3.1.10 Interstage管理コンソールのシステム資源の設定

Interstage管理コンソールを用いたシステムの運用時には、システム資源を拡張する必要があります。ここでは、以下につ



注意

Interstage管理コンソールを使用する場合は、Interstage統合コマンドのシステム資源も拡張する必要があります。“3.1.11Interstage統合コマンドのシステム資源の設定”を参照し、必要な値を加算してください。


Interstage管理コンソールを運用するためのサービスが使用するセマフォのシステムパラメタのチューニングについて説

明します。


セマフォ



para2 加算値 1


para4 加算値 1

3.1.11 Interstage統合コマンドのシステム資源の設定

以下のどれかを利用する場合は、各機能で追加したシステム資源に加えて、Interstage統合コマンドで使用するシステム

資源を拡張する必要があります。

ここでは、システムパラメタについて説明します。

・ Java EE

・マルチ言語サービス

・ J2EE互換機能


Interstage統合コマンドで使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニングについて説

明します。


共用メモリ

- 92 -



加算値 2015552 以上

shmmax －設定値 1106440 以上

shmmni project.max-shm-ids 加算値 22 (注)

注)


マルチシステム機能は、Interstage Application Server Enterprise Editionで使用できます。

共用メモリ


kernel.shmmax 設定値

12503496 以上

13208308 以上


セマフォ



値

2 (注)


設定

値

12 以上 (注)


値

3 以上

注)



セマフォ



para2 加算値 2


para4 加算値 2



msgmnb process.max-msg-qbytes 設定値 4572 ＋ (528 × 同時実行コマンド数) (注1)

- 93 -


msgmni project.max-msg-ids 加算値 12 (注2)


設定値 15 ＋同時実行コマンド数以上(注1)(注2)

注1)

同時実行コマンド数とは、Interstage統合コマンドを同時に実行した数のことです。

また、Systemwalker Operation Manager、Interstage運用APIを使用してワークユニットの起動／停止、オブジェクト閉

塞／閉塞解除を行う場合は、同時に操作する回数が同時実行コマンド数となります。

注2)






kernel.msgmnb 設定値 4572 ＋ (528 × 同時実行コマンド数) (注)


注)

同時実行コマンド数とは、Interstage統合コマンドを同時に実行した数のことです。

また、Systemwalker Operation Manager、Interstage運用APIを使用してワークユニットの起動／停止、オブジェクト閉

塞／閉塞解除を行う場合は、同時に操作する回数が同時実行コマンド数となります。

3.1.12 Webサーバコネクタのシステム資源の設定

Webサーバコネクタを使用する場合には、システム資源を拡張する必要があります。ここでは、以下について説明しま

す。

なお、J2EEをお使いの場合は、「IJServerクラスタ」を「IJServeワークユニット」に読み替えて設定してください。


－ Webサーバコネクタを使用する場合

－ Webサーバコネクタの故障監視機能を使用する場合


Webサーバコネクタを使用する際には、以下のシステムパラメタのチューニングを行ってください。

Webサーバコネクタの故障監視機能を使用する場合は、Webサーバコネクタで使用する資源にWebサーバコネクタの

故障監視機能で使用する資源量を加算してください。


Webサーバコネクタ

Webサーバコネクタを使用する場合に必要となるシステム資源について、以下に示します。

セマフォ

- 94 -



値

以下をWebサーバごとに求めた合算値 (注)

・ ((IJServerクラスタ数の合計値＋各IJServerクラスタのプロセス多重度の合計値＋ 2)×2) ＋ 4


設定

値

1 以上


値

2 以上

注)

チューニングの例を以下に示します。

条件

IJServerクラスタ WU001 プロセス多重度:3

WU002 プロセス多重度:3


Webサーバ web001 接続先:WU001、WU002

web002 接続先:WU003

－ semmni

web001の必要数＝ ((2(IJServerクラスタ数の合計値) ＋ 6(各IJServerクラスタのプロセス多重度の合計値) ＋ 2)×2) ＋ 4 ＝ 24web002の必要数＝ ((1(IJServerクラスタ数の合計値) ＋ 3(各IJServerクラスタのプロセス多重度の合計値) ＋ 2)×2) ＋ 4 ＝ 16semmni ＝ 24(web001の必要数) ＋ 16(web002の必要数) ＝ 40

セマフォ



para2 加算値以下をWebサーバごとに求めた合算値 (注)



para4 加算値以下をWebサーバごとに求めた合算値 (注)


注)

チューニングの例を以下に示します。

条件

- 95 -

IJServerクラスタ WU001 プロセス多重度:3



Webサーバ web001 接続先:WU001、WU002

web002 接続先:WU003

－ para2

web001の必要数＝ ((2(IJServerクラスタ数の合計値) ＋ 6(各IJServerクラスタのプロセス多重度の合計値) ＋ 2)×2) ＋ 4 ＝ 24web002の必要数＝ ((1(IJServerクラスタ数の合計値) ＋ 3(各IJServerクラスタのプロセス多重度の合計値) ＋ 2)×2) ＋ 4 ＝ 16para2 ＝ 24(web001の必要数) ＋ 16(web002の必要数) ＝ 40

－ para4

para2と同様に計算してください。

Webサーバコネクタの故障監視機能

Webサーバコネクタの故障監視機能を使用する場合に追加となるシステム資源について、以下に示します。

共用メモリ


shmmax －設定値 6,720,012 以上


加算値 6,720,012 × (Webサーバ数 + 1)

shmmni project.max-shm-ids 加算値 Webサーバ数 + 1

共用メモリ



kernel.shmmni 加算値 Webサーバ数 + 1

セマフォ



値

3

セマフォ



para2 加算値 3


- 96 -


para4 加算値 3

3.2 マルチサーバ管理機能を使用する時に必要なシステム資源

Interstageのマルチサーバ管理機能を使用する時に必要となるシステム資源について説明します。

なお、システムパラメタを算出するためのExcelファイルがマニュアルパッケージの“ApplicationServer\tuning”配下のサ

ブフォルダに“ISAS-IPCtuning.xlsx”として格納されています。Microsoft(R) Excel、または以降のバージョンのMicrosoft(R)Excelをお持ちの場合は“ISAS-IPCtuning.xlsx”を使用してシステムパラメタを算出することが可能です。使用方法などの

詳細については、当該Excelファイル内の説明記事を参照してください。


管理サーバ機能を使用する場合は、“Interstage ディレクトリサービス”のシステム資源が必要です。

管理サーバ機能を使用する場合に必要なシステム資源量は、“3.1 サーバ機能運用時に必要なシステム資源”の同一

サービスの説明を参照してください。


管理対象サーバとして運用する場合は、使用する機能に関するシステム資源が必要です。必要量については、“3.1サーバ機能運用時に必要なシステム資源”の同一サービスの説明を参照してください。


共存サーバでは管理サーバ機能とInterstageのサーバ機能(管理対象サーバ)が同一マシン上で動作しています。共存

サーバ運用時に必要なシステム資源については、“■管理サーバ機能を使用する場合”と“■管理対象サーバとして運

用する場合”を参照して使用するサービスを列挙してください。各サービスが必要とするシステム資源は、“3.1 サーバ機

能運用時に必要なシステム資源”の同一サービスの説明を参照してください。

注意



3.3 性能監視ツール使用時に必要なシステム資源

性能監視ツールで性能監視環境として使用する資源の見積もり方法を説明します。

3.3.1 システム構成情報の見積もり方法 (Solarisの場合) システム構成情報は、以下の見積もり式を参考に見積もり、見積もり値以上の値を設定してください。

セマフォ

- 97 -

システム構成情報資源制御種類見積もり

semsys:seminfo_semmnu (注1)

－加算値セマフォ数 (*)

semsys:seminfo_semmni

project.max-sem-ids 加算値 1

semsys:seminfo_semmns (注1)

－加算値セマフォ数 (*)

semsys:seminfo_semmsl

process.max-sem-nsems

設定値セマフォ数 (*) 以上の値

*)

セマフォ数＝性能監視ツール起動時に指定する共有メモリ量(MB) × 10 ＋ 2ただし、大52

注1)

Solaris 10以降の場合、指定する必要はありません。

共有メモリ

システム構成情報資源制御種類見積もり

shmsys:shminfo_shmmax

project.max-shm-memory

設定値 “3.3.3 共有メモリ量の見積もり方法”

を参照

shmsys:shminfo_shmmni

project.max-shm-ids 加算値 1

3.3.2 システム構成情報の見積もり方法 (Linuxの場合) システム構成情報は、以下の見積もり式を参考に見積もり、見積もり値以上の値を設定してください。

セマフォ

kernel.sem = para1 para2 para3 para4

システム構成情報種類見積もり

para1 設定値セマフォ数 (*) 以上の値

para2 加算値セマフォ数 (*)

para3 設定値セマフォ数 (*) 以上の値

para4 加算値 1

*)

セマフォ数＝性能監視ツール起動時に指定する共有メモリ量(MB) × 10 ＋ 2ただし、大52

共有メモリ


kernel.shmmax 設定値 “3.3.3 共有メモリ量の見積もり方法”を参照

- 98 -



3.3.3 共有メモリ量の見積もり方法

共有メモリ量は、以下の見積もり式を参考に必要な共有メモリ量を求め、その共有メモリ量をメガバイト単位に切り上げ

た値で見積もってください。

変更方法の詳細については、“■システムパラメタについて”を参照してください。

共有メモリ量の見積もり(単位:バイト)

1. 性能監視ツールの性能監視対象とする全オブジェクト（アプリケーション）に対して、オブジェクト（アプリケーショ

ン）ごとに必要な共有メモリ量を、以下の方法で求めてください。

a. 各オブジェクト（アプリケーション）に定義されているプロセス多重度を確認してください。

b. 各オブジェクト（アプリケーション）に定義されているスレッド多重度を確認してください。

c. 各オブジェクト（アプリケーション）に登録されているオペレーション数を確認してください。

オペレーション数はCORBAアプリケーションおよびトランザクションアプリケーションの場合、IDL定義ファイ

ルから求めてください。EJBアプリケーションの場合、remoteインターフェースとHomeインターフェースのソー

スを確認し、pubｌicであるメソッドの数を数えて、これに、継承されるインターフェースを加算して求めてくださ

い。

d. 以下の計算で、オブジェクト（アプリケーション）ごとに必要な共有メモリ量を求めてください。

- オペレーション数の平均が3以下の場合

(プロセス多重度 × スレッド多重度 × 1536) ＋ 400

4600 × プロセス多重度 × スレッド多重度＋ 276288

- オペレーション数の平均が3よりも多い場合

(オペレーション数 × プロセス多重度 × スレッド多重度 × 546) ＋ 400

(4600 × プロセス多重度 × スレッド多重度 × オペレーション数 ÷ 3) ＋ 276288

2. 以下の計算で、必要な共有メモリ量を求めてください。

オブジェクトごとに必要な共有メモリ量の合計＋ 261188

3. 共有メモリ量を、以下の計算で求めてください。

必要な共有メモリ量 ÷ 1048576

なお、上記の計算で端数(小数点以下)が発生した場合は、切り上げてください。

注意

インターバル時間内に性能監視対象のオブジェクトを再起動する場合には、a.～d.で求めた「オブジェクトごとに必要な

共有メモリ量の合計」について、再起動回数分、あらかじめ積算してください。

3.4 TCP/IPパラメタのチューニング

TCP/IPパラメタのチューニング方法を説明します。

- 99 -

■チューニング方法

レジストリエディタを使用して以下のレジストリ情報を追加した後、システムを再起動してください。

・レジストリキー:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

－名前:TcpTimedWaitDelay

－種類:REG_DWORD

－推奨値:1E(30秒)

・レジストリキー:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

－名前:MaxUserPort

－種類:REG_DWORD

－推奨値:65534(10進数)

短時間に数多くのクライアントが接続する場合、TCP/IPのソケット不足になりWebブラウザに「Internal Server Error」が表

示される場合があります。

上記情報を追加することで、使用可能なソケット数を増やし、また、使用済みのソケットを早く開放するようになります。

注意

・レジストリ情報がない場合は、新しく作成してください。

・ TCP/IPパラメタをチューニングする際は、上記の2つのレジストリキーの値を変更してください。

・レジストリの編集操作を誤ると、システムが不安定になる可能性がありますので、操作の際には、指定されたキー以

外は一切変更を加えないよう注意してください。また、操作前には必ずレジストリのバックアップを行ってください。

・ TCP/IPパラメタのチューニングは、すべてのTCPに対して影響を与えるため、システム管理者に相談してから実施し

てください。


nddコマンドを使用してtcp_time_wait_intervalを60秒にしてください。OSのデフォルト値は60秒のため、値を変更してい

なければ設定する必要はありません。

永続的に設定を有効する場合には、RCプロシジャ(/etc/rc2.d)に登録が必要です。

RCプロシジャの例を以下に示します。

#!/bin/sh

ndd -set /dev/tcp tcp_time_wait_interval 60000

短時間に数多くのクライアントが接続する場合、TCP/IPのソケット不足になりWebブラウザに「Internal Server Error」が表

示される場合があります。

上記情報を追加することで、使用可能なソケット数を増やし、また、使用済みのソケットを早く開放するようになります。

注意

TCP/IPパラメタのチューニングは、すべてのTCPに対して影響を与えるため、システム管理者に相談してから実施してく

ださい。

- 100 -

3.5 IPC資源のカスタマイズ

ここでは、その他に必要となるカスタマイズ項目について説明します。

■System V IPC資源のIPCキー値のカスタマイズについて

Interstageでは、Interstageを構成するプロセス間通信のために、OSが提供するSystem V IPC資源(メッセージキュー、セ

マフォ、共有メモリ)を使用しています。このIPC資源は、作成時に指定する値(IPCキー値)により、システムで一意に識別

されます。

IPCキー値は、システムで一意でなければなりませんが、任意の値を使用することが可能なため、ほかのIPC資源を使

用する製品およびアプリケーションプログラムと重複することがあります。

IPCキー値の重複が発生した場合、Interstageでは、以下のようなメッセージを出力して、IPCキー値の重複を通知しま

す。

例

IPCキー値の重複を検出したときにコンポーネントトランザクションサービスが出力するメッセージの例

・ TD: エラー: td11038:必要なIPC資源が使用中のため獲得できませんでした(key=%x path=%s)

この場合、IPCキー値に対応したIPC資源を使用しているInterstageのサービスの各機能は使用できません。

このような状態に対処するため、Interstageでは以下に示す方法で、Interstageが使用するIPCキー値をカスタマイズする

ことが可能です。IPCキー値の重複発生を通知するメッセージが出力された場合は、この対処により運用することができ

ます。

■概要

IPCキー値は4バイト(32ビット)で構成されますが、そのうちの下位12ビット(16進3桁)に任意の値を定義することで、ほか

の製品が使用するIPCキー値と重複しないようにします。なお、上位残りの20ビットは、Interstageが決定します。

■IPCキー値の定義方法

以下のIPCキー値定義ファイルを新規に作成し、16進3桁でIPCキー値の下位12ビットを指定します。

MessageQueueDirectorを除くサービスは、共通定義ファイルの指定が有効です。MessageQueueDirectorは固有の定義

ファイルの指定が有効です。

共通定義ファイル:

/var/opt/FJSVisas/system/システム名/FJSVisas/etc/ipc_key

/var/opt/FJSVisas/system/default/FJSVisas/etc/ipc_key

MQDシステムの定義ファイル:

/opt/FJSVmqd/mqd/MQDシステム名/ipc_key

注意

・定義ファイルの内容が16進3桁以外の場合は、IPCキー値の指定がない場合と同様に動作します。

・ “MQDシステム名”については、“MessageQueueDirector 説明書”を参照してください。

・“システム名”は、マルチシステム機能のシステム名です。マルチシステム機能を使用していない場合は、“default”と

なります。

- 101 -

・クラスタシステムを使用する場合、MQDシステム用の定義ファイルは、mqd環境定義ファイル中の以下で指定した

ディレクトリの中に定義ファイル(ipc_key)を作成してください。

－ [Cluster]SystemDirectory = MQDのクラスタサービスが使用するディレクトリの名前

例

FFF

この定義例の場合、Interstageが使用する上位20ビットを0x01280とすると、IPCキー値は、16進表示で、以下のようにな

ります。

0x01280FFF

注意

・ IPCキー値の定義は、Interstageを全強制停止モードで停止し、さらにInterstage JMXサービスを停止してから行って

ください。Interstageの運用中に本定義を変更しないでください。

・IPCキー値の定義は、システム間で重複することのないように定義してください。

- 102 -

第4章ワークユニットのチューニング

ワークユニットには、様々な機能があり、これらをチューニングすることで、適な状態での運用を行うことが可能となりま

す。ここでは、ワークユニットのチューニングについて説明します。

4.1 ワークユニット数、オブジェクト数、プロセス数のチューニング

起動できるワークユニット数、オブジェクト数およびプロセス数は以下の条件式を満たす必要があります。

(ワークユニット数×２)＋(オブジェクト総数×ｍ)＋(プロセス総数×ｎ)＋１ ≦ 2010

この条件式を超えてワークユニットを起動する場合は、大規模システム用環境定義ファイルをコピーする必要がありま

す。なお、Linux for Intel64版では、標準で大規模システム用環境定義ファイルが使用されています。

大規模システム用環境定義ファイルを使用した場合、以下の条件式まで起動できるワークユニット数、オブジェクト数お

よびプロセス数が拡張されます。

(ワークユニット数×２)＋(オブジェクト総数×ｍ)＋(プロセス総数×ｎ)＋１ ≦ 6030

条件式のオブジェクト総数とは、ワークユニット定義の[Application Program]セクションの総数です。

IJServerの場合、各ワークユニットのオブジェクト数は以下となります。

IJServerタイプオブジェクト数

WebアプリケーションとEJBアプリケーションを同一JavaVMで運用

Webアプリケーションのみ運用

EJBアプリケーションのみ運用

1

WebアプリケーションとEJBアプリケーションを別JavaVMで運用 2

条件式のｍ、ｎについては、ｍ＝１、ｎ＝２を基準値とし、以下に該当する場合は、変更してください。

・ islistwuおよびislistobjコマンドを使用する場合

ｍ＝２

・ islistaplprocコマンドを使用する場合

ｎ＝３

・ Interstage管理コンソールを使用する場合

ｍ＝２、ｎ＝３

大規模システム用環境定義ファイル

コピー元コピー先

Interstageインストール先フォルダ

\extp\etc\sys\td\extp.ini.largeInterstageインストール先フォルダ\td\var\td001\sys\etc\extp.ini

/opt/FSUNextp/etc/sys/td/extp.ini.large

デフォルトシステムの場合

/var/opt/FJSVisas/system/default/FSUNextp/td001/sys/etc/extp.ini

拡張システムの場合

/var/opt/FJSVisas/system/[sysname]/FSUNextp/[sysname]/sys/etc/extp.ini([sysname]は、拡張システム名)

/opt/FJSVextp/etc/sys/td/extp.ini.large

/var/opt/FJSVisas/system/default/FJSVextp/td001/sys/etc/extp.ini

通常システム用環境定義ファイル

通常のシステム定義に復元する場合は、以下の通常システム用環境定義ファイルをコピーしてください。

- 103 -

コピー元コピー先

Interstageインストール先フォルダ

\extp\etc\sys\td\extp.iniInterstageインストール先フォルダ\td\var\td001\sys\etc\extp.ini

/opt/FSUNextp/etc/sys/td/extp.ini デフォルトシステムの場合

/var/opt/FJSVisas/system/default/FSUNextp/td001/sys/etc/extp.ini

拡張システムの場合

/var/opt/FJSVisas/system/[sysname]/FSUNextp/[sysname]/sys/etc/extp.ini([sysname]は、拡張システム名)

/opt/FJSVextp/etc/sys/td/extp.ini /var/opt/FJSVisas/system/default/FJSVextp/td001/sys/etc/extp.ini

・大規模システム用環境定義ファイルを使用した場合、共有メモリ使用量が14メガバイト増加します。

・環境定義ファイルをコピーする場合は、Interstageを停止してください。

・コピー先の環境定義ファイルを誤って削除した場合、システム規模に応じて環境定義ファイルを再度コピーしてくだ

さい。

4.2 プロセス強制停止時間のチューニング

プロセス強制停止時間は、ワークユニット停止においてアプリケーションプロセスの停止処理がハングアップしていると

判断する時間です。

プロセス強制停止時間をチューニングする場合は、アプリケーションプロセス停止処理に必要な時間を考慮してくださ

い。以下の条件式を参考にしてください。

■条件式

プロセス強制停止時間(秒) ＞アプリケーションプロセス停止処理時間(秒)

アプリケーションプロセス停止処理時間：

以下の場合において、アプリケーションプロセス停止処理時間を考慮してください。その他の場合は、デフォルト値で問

題ありません。

・ CORBAワークユニットの場合

サーバアプリケーションの活性化後の動作モードに“SYNC_END(サーバアプリケーションを活性化しても、活性化メ

ソッドは復帰しません。)”を設定し、かつ、活性化メソッドの後に後処理を記述している場合、後処理の実行に必要な時間

サーバアプリケーションの活性化後の動作モードについては、“リファレンスマニュアル ( コマンド編 )OD_impl_inst(「CORBAアプリケーション情報定義ファイルでの登録」の「mode」)”を参照してください。

・ IJServerワークユニットの場合

停止時実行クラスを登録している場合、停止時実行クラスの実行に必要な時間

停止時実行クラスについては、“J2EE ユーザーズガイド(旧版互換)(「J2EEアプリケーションの設計」「J2EEアプリケー

ションが運用される環境(IJServer) 」の「起動/停止の実行クラス」)”を参照してください。

ワークユニットを停止する時は、お客様の業務が終了していることを想定しています。そのため、デフォルト値には、ハン

グアップしていると判断して差し支えのない値として、180秒を設定しています。

業務運用中にワークユニットを停止することがある場合は、アプリケーション処理時間を考慮する必要があります。以下の

条件式を参考にしてください。

プロセス強制停止時間はアプリケーションの処理時間とプロセスの停止処理時間の合計を上回るように設定してくださ

い。

- 104 -

プロセス強制停止時間(秒) ＞アプリケーション処理時間(秒) ＋アプリケーションプロセス停止処理時間(秒)

アプリケーション処理時間：

アプリケーション処理中にワークユニットを停止するような運用を実施する場合、そのアプリケーションの処理が正常に完

了するために必要な、も長い時間を設定してください。

ワークユニット同期停止は、アプリケーション処理中に実行すると、処理中の要求が完了するのを待ってからプロセスを

停止します。

アプリケーション処理時間の考慮がされていないと、ワークユニット同期停止において、処理中の要求が途中で強制終

了されます。

注)IJServerワークユニットの通常停止は同期停止と同じ動きとなります。

アプリケーションプロセス停止処理時間：

■条件式のアプリケーションプロセス停止処理時間を参照してください。

アプリケーション処理時間が120秒で、アプリケーションプロセス停止処理時間が5秒の場合、プロセス強制停止時間は、

126秒以上を設定してください。

4.3 CORBAワークユニットのチューニング

CORBAワークユニットは、以下の製品で使用可能です。

・ Interstage Application Server Enterprise Edition

ワークユニットのチューニングについては、以下のマニュアルを参照してください。

・ “OLTPサーバ運用ガイド”の“ワークユニットの作成”

・ “OLTPサーバ運用ガイド”の“CORBAワークユニット”

4.4 IJServerワークユニットのチューニング

IJServerワークユニットについては、以下を参照してください。

・ “J2EE ユーザーズガイド(旧版互換)”－“IJServerのチューニング”

4.5 トランザクションアプリケーションのチューニング

トランザクションワークユニットは、以下の製品で使用可能です。


トランザクションワークユニットについては、以下のマニュアルを参照してください。


・ “OLTPサーバ運用ガイド”の“トランザクションアプリケーションのワークユニット”

4.6 ラッパーワークユニットのチューニング

ラッパーワークユニットは、以下の製品で使用可能です。


ラッパーオブジェクトワークユニットについては、以下のマニュアルを参照してください。


・ “OLTPサーバ運用ガイド”の“ラッパーオブジェクトのワークユニット”

- 105 -

4.7 ユーティリティワークユニットのチューニング

ユーティリティワークユニットは、以下の製品が使用可能です。


ユーティリティワークユニットについては、以下のマニュアルを参照してください。


・ “OLTPサーバ運用ガイド”の“ユーティリティのワークユニット”

- 106 -

第5章 Java EE機能のチューニング

ここでは、Java EE機能のチューニングについて説明します。

ポイント

・ Java EE機能を機能的・効率的に運用するには本章のほか、「第3章システムのチューニング」の関連記事も参照し

てください。

・とくに「3.1.11 Interstage統合コマンドのシステム資源の設定」の内容を設定しない場合、Interstageの自動起動が失

敗する場合があります。

5.1 Interstage Java EE DASサービスのチューニング

下記の運用を行う場合は、Interstage Java EE DASサービスのチューニングが必要です。

ここでは、それぞれの運用に必要な設定内容、および設定方法について説明します。

・プロキシを使用する場合

・運用管理用HTTPリスナーのポート番号を変更する場合

・運用管理用HTTPリスナーのポート番号を変更する場合(Interstage Java EE DASサービスを起動できない場合)

・運用管理用HTTPリスナーのSSL通信利用設定を変更する場合

・監視サービスの定義項目を有効にする場合

プロキシを使用する場合

Webサービスアプリケーションの配備などで、プロキシを経由して外部リソースを取得する場合、Interstage Java EE DASサービスが使用するjavaプロセスのシステムプロパティに以下を設定する必要があります。

キー設定値備考

http.proxyHost ホスト名値が設定されない場合は、プロキシを経由せずに

接続します。http.proxyPort ポート番号

http.nonProxyHosts プロキシを経由せず

に接続するホスト名

「|」区切りで複数のホストを指定できます。

http.proxyUser ユーザ名プロキシがベーシック認証を行っている場合に設定

してください。http.proxyPassword パスワード

Interstage Java EE管理コンソールを使用して、下記の項目を変更してください。

・ [設定] > [server-config] > [JVM 設定] > [JVM オプション]

また、asadminコマンドのcreate-jvm-optionsサブコマンドで設定することも可能です。詳細は、「リファレンスマニュアル(コマンド編)」－「asadmin」の「create-jvm-optionsサブコマンド」を参照してください。

注意

・ asadminコマンドのcreate-jvm-optionsサブコマンドで設定を行う場合、targetオプションには「server」を指定してくださ

い。

・変更を有効にするためには、Interstage Java EE DASサービスの再起動が必要です。

・システムプロパティは、必ずキー値の前に-Dを付加して、下記のように設定してください。

-D"キー値"="設定する値"

- 107 -

運用管理用HTTPリスナーのポート番号を変更する場合

以下の手順で変更します。

1. Interstage Java EE DASサービスの起動

以下のサービスを起動します。

- Interstage Java EE DASサービス

ijdasstartコマンドを実行してサービスを起動します。

※他のプロセスとのポート番号の重複によりInterstage Java EE DASサービスを起動できない場合は、「運用管理

用HTTPリスナーのポート番号を変更する場合(Interstage Java EE DASサービスを起動できない場合)」の手順で

ポート番号を変更してください。

2. HTTPリスナーポート番号の変更

asadminコマンドのsetサブコマンドでserver.http-service.http-listener.admin-listener.portの定義項目を更新します。

例

ポート番号を8929に変更する場合

> asadmin set server.http-service.http-listener.admin-listener.port=8929

server.http-service.http-listener.admin-listener.port=8929

3. asadminenv.confファイルの修正

運用管理用HTTPリスナーのポートに合わせて、asadminenv.confファイルを修正します。

修正方法の詳細は、「リファレンスマニュアル(コマンド編)」の「Java EE運用コマンド」－「asadmin」の「asadminenv.confファイル」を参照してください。

例


AS_ADMIN_PORT=8929

AS_ADMIN_PROFILE=cluster

AS_ADMIN_SECURE=true

AS_ADMIN_REALM=os

4. Interstage Java EE DASサービスの再起動

以下のサービスを再起動します。


ijdasstopコマンドを実行後、ijdasstartコマンドを実行してサービスを再起動します。

運用管理用HTTPリスナーのポート番号を変更する場合(Interstage Java EE DASサービスを起動できない場合)

運用管理用HTTPリスナーのポートが他のアプリケーションで使用されているなど、Interstage Java EE DASサービスを起

動できない場合は、domain.xmlを修正します。

domain.xmlの修正方法

- 108 -

以下のファイルをテキストエディタなどで開いて、name属性に「server-config」が設定されているconfigタグ配下のhttp-listenerタグのport属性を編集します。

ファイルの格納先

[Java EE共通ディレクトリ]\domains\interstage\config\domain.xml

[Java EE共通ディレクトリ]/domains/interstage/config/domain.xml

例


<config dynamic-reconfiguration-enabled="true" name="server-config">

<http-service>

<access-log ・・・

<http-listener ・・・



<http-listener acceptor-threads="1" address="0.0.0.0"

blocking-enabled="false" default-virtual-server="__asadmin"

enabled="true" family="inet" id="admin-listener" port="8929"

security-enabled="false" server-name="" xpowered-by="false"/>

注意

domain.xmlを編集する際はポート番号以外の設定を変更しないでください。変更するとInterstage Java EE DASサービス

を使用できなくなる場合があります。編集前にdomain.xmlを退避することをお奨めします。

運用管理用HTTPリスナーのSSL通信利用設定を変更する場合

以下の手順で変更します。

1. Interstage Java EE DASサービスの起動

以下のサービスを起動します。


ijdasstartコマンドを実行してサービスを起動します。

2. SSL通信利用設定の変更

asadminコマンドのsetサブコマンドでserver.http-service.http-listener.admin-listener.security-enabledの定義項目を

更新します。

例

SSL通信を利用する設定に変更する場合

> asadmin set server.http-service.http-listener.admin-listener.security-enabled=true

server.http-service.http-listener.admin-listener.security-enabled=true

3. asadminenv.confファイルの修正

運用管理用HTTPリスナーのSSL通信利用設定に合わせて、asadminenv.confファイルを修正します。

- 109 -

修正方法の詳細は、「リファレンスマニュアル(コマンド編)」の「Java EE運用コマンド」－「asadmin」の「asadminenv.confファイル」を参照してください。

例

SSL通信を利用する設定に変更する場合

AS_ADMIN_PORT=12001

AS_ADMIN_PROFILE=cluster

AS_ADMIN_SECURE=true

AS_ADMIN_REALM=os

4. Interstage Java EE DASサービスの再起動

以下のサービスを再起動します。


ijdasstopコマンドを実行後、ijdasstartコマンドを実行してサービスを再起動します。

監視サービスの定義項目を有効にする場合

IJServerクラスタや、Interstage Java EE DASサービスの監視サービスの定義項目を有効にすると、サーバーインスタンス

数、配備済みのアプリケーション数に応じてInterstage Java EE DASサービスのメモリが使用されます。

監視サービスを有効に設定した場合は、Interstage Java EE DASサービスでメモリ不足が発生していないことを確認して

ください。メモリ不足が発生した場合は、「5.16 Interstage Java EE DASサービスのヒープ領域サイズとアドレス空間」を参

照して対処を行ってください。

5.2 Interstage Java EE Node Agentサービスのチューニング

複数のサーバーインスタンスを同時起動させる場合

デフォルトでは、Interstage Java EE Node Agentサービスのメモリ割り当てプールの大値を128MBに設定しています。

デフォルトのチューニング値で90個のインスタンス同時起動が可能です。

90個より多くのインスタンスを同時起動させる場合にはメモリ割り当てプールの大値をチューニングする必要がありま

す。

見積もり式

(90個より追加起動するインスタンス数) ＋ 128

チューニングファイル名

C:\Interstage\F3FMisjee\lib\processLauncher.xml (C:\Interstageにインストールした場合)

/opt/FJSVisjee/lib/processLauncher.xml

チューニング手順

1. Interstage Java EE Node Agentサービスを停止します。

2. Interstage Java EE DASサービスを停止します。

3. チューニングファイルをエディタで開いて、以下を探します。

<process name="s1as8-nodeagent"></process>タグで囲まれている<sysproperty key="-Xmx128m"/>タグ

4. <sysproperty key="-Xmx128m"/>タグの数値を、見積もり式で計算した値に修正します。

- 110 -

5. Interstage Java EE DASサービスを起動します。

6. Interstage Java EE Node Agentサービスを起動します。

注意

・その他の設定値は修正しないでください。

・サーバーインスタンスを増やすと、システム全体のメモリ使用量が増加する場合があるため注意してください。

5.3 IJServerクラスタのチューニング

IJServerクラスタのチューニングについて、以下に説明します。

ここで説明するチューニング項目は、IJServerクラスタで動作するすべてのアプリケーションに有効です。

5.3.1 複数プロセス運用

IJServerクラスタの配下に複数のサーバーインスタンスを作成することで、同一の業務アプリケーションを複数のプロセス

で運用できます。

サーバーインスタンスの数は、以下を考慮して設計します。

信頼性要件

複数のサーバーインスタンスを作成することにより、業務アプリケーションを運用するJava VMプロセスがダウンした場

合でも、他のプロセスでシステムの運用を継続できます。

Java VMのメモリ使用量

メモリを多く使用する業務アプリケーションの場合、サーバーインスタンスを増やすことで1プロセスあたりのメモリ使用

量を削減できる可能性があります。

なお、サーバーインスタンスを増やすと、システム全体のメモリ使用量が増加する場合があるため注意してください。

負荷状況

業務アプリケーションへの負荷に応じて適切なサーバーインスタンスを作成します。

高負荷状況では、サーバーインスタンスの数を増やすことでスループットが向上する場合があります。

注意

複数プロセス運用における注意事項

・設定値の妥当性は、必ず負荷試験を実施して確認してください。

・サーバーインスタンスを追加する場合は、物理メモリなどのシステム資源が十分かどうか確認してください。

・アプリケーションによっては、複数のサーバーインスタンスで動作させた場合に動作が変わることがあります。IJServerクラスタ配下にサーバーインスタンスを複数作成する場合は、アプリケーションへの影響を事前に確認してください。

Interstage Java EE管理コンソール、およびasadminコマンドを使用することで、サーバーインスタンスの追加/削除を行うこ

とができます。詳細については、以下のマニュアルを参照してください。

・ Interstage Java EE管理コンソールヘルプ

・「リファレンスマニュアル(コマンド編)」－「IJServerクラスタ運用」

また、複数のサーバーインスタンスによる運用については、「Java EE運用ガイド」－「IJServerクラスタの複数プロセス構

成」を参照してください。

5.3.2 Java VMのヒープ領域サイズ/Perm領域サイズ

以下のJava VMオプションの値を変更することで、Java VMのヒープ領域サイズ、およびPerm領域サイズを変更できま

す。

- 111 -

項目 Java VMオプションデフォルト値

Java VMの大ヒープ領域サイズ -Xmx -Xmx256m

Java VMのPerm領域サイズ -XX:MaxPermSize -XX:MaxPermSize=192m

Java VMオプションの値は、Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更できます。詳細に

ついては、以下のマニュアルを参照してください。


・「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」

・「リファレンスマニュアル(コマンド編)」－「configs.config.java-configの定義項目」

アプリケーションの運用中にjava.lang.OutOfMemoryErrorが多発する場合、Java VMの大ヒープ領域サイズ、または

Perm領域サイズが不足している可能性があります。「チューニングガイド」の「JDK/JREのチューニング」を参照し、適切な

値にチューニングしてください。

5.3.3 ガーベジコレクション発生回数

IJServerクラスタでは、JavaのRMI機能による自動ガーベジコレクションが1時間隔(デフォルトの場合)で動作します。

RMI機能による自動ガーベジコレクションの発生間隔を変更するには、以下のJava VMオプションの値を変更してくださ

い。

・ -Dsun.rmi.dgc.client.gcInterval=発生間隔

・ -Dsun.rmi.dgc.server.gcInterval=発生間隔

発生間隔: ミリ秒単位で数値を指定します。デフォルト値は、3600000です。

Java VMオプションの値は、Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更できます。詳細に

ついては、以下のマニュアルを参照してください。



・「リファレンスマニュアル(コマンド編)」－「configs.config.java-configの定義項目」

なお、RMI機能による自動ガーベジコレクションの発生間隔をチューニングしても、ガーベジコレクション発生回数が削

減されない場合、Java VMのヒープ領域サイズが不足している可能性があります。この場合、Java VMのヒープ領域サイ

ズのチューニングを行うことで削減される場合があります。「5.3.2 Java VMのヒープ領域サイズ/Perm領域サイズ」を参照


5.3.4 アプリケーション最大処理時間

想定される業務アプリケーションの大処理時間を指定します。

アプリケーション大処理時間の値は、Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更でき

ます。詳細については、以下のマニュアルを参照してください。



・「リファレンスマニュアル(コマンド編)」－「configs.config.ijserver-controlの定義項目」

5.3.5 グループ管理サービスの設定

IJServerクラスタはサーバーインスタンスが互いに起動状態を監視するためにグループ管理サービスを使用します。この

サービスを利用する機能については「Java EE運用ガイド」－「グループ管理サービス」を参照してください。

このサービスを使用すると、クラスタに設定されているハートビートアドレスとハートビートポートに各サーバーインスタンス

が定期的にハートビートの信号を送信し、その信号を別のサーバーインスタンスが受信することでサーバーインスタンス

- 112 -

が正常に運用されていることを認識します。ハートビート信号が送信されなかったサーバーインスタンスについては、停

止しているか異常が発生していると判断して、グループから除外されます。

定期的に信号が送受信されるため、以下のような場合には各種定義をチューニングすることができます。また、このグルー

プ管理サービスを使用する必要がない場合にはハートビートを無効にすることで、信号の送受信を行わないように変更

できます。

・ネットワーク負荷が高いため、定期的な信号の送受信間隔を大きくしてサーバ負荷を軽減したい。

・頻繁にアクセスがなく、システムでリアルタイムに異常を検知する必要がないため、異常を検知するまでの時間は若

干遅くても良いので、サーバの負荷を軽減したい。

以下に各種定義項目のチューニング観点を説明します。各信号を送信する時にはマルチキャストポートに対して約3300バイトのデータを送信します。プロトコル大試行/検証済みタイムアウト/pingタイムアウトは、値を小さくすると異常を検知

するまでの時間を短くすることができますが、一時的な高負荷状態をサーバーインスタンスが停止しているか異常が発生

していると判断する場合がありますので、特に理由がなければデフォルト値を使用することをお勧めします。

定義項目チューニング観点

プロトコルタイムアウト指定した間隔で約3300バイトのデータが定期的に送信されます。

この値を大きく設定することでネットワーク負荷を軽減することがで

きますが、サーバーインスタンスの停止や異常を検知するタイミン

グが遅延します。

プロトコル大試行 [プロトコルタイムアウト]×[プロトコル大試行]の時間にグループ

に属する他のサーバーインスタンスからハートビート信号が送信さ

れなかった場合に、信号が送信されないサーバーインスタンスに

異常(または停止)が発生している可能性があると判断します。

検証済みタイムアウト [プロトコルタイムアウト]×[プロトコル大試行]の時間にハートビー

ト信号が送信されなかった場合、更に検証済みタイムアウトの時間

超過してもハートビート信号が送信されなければ、ping要求を送信

します。

pingタイムアウト終的にサーバーインスタンスに異常(または停止)が発生してい

るかを確認するping要求を送信して、サーバーインスタンスからの

応答を待機する時間です。

上記より、サーバーインスタンスが異常もしくは停止した場合に、そのサーバーインスタンスを除外するまでの時間の目

安は以下となりますので、異常を検知する時間のシステム要件と、ネットワーク負荷を照らし合わせてチューニングを行っ

てください。

サーバーインスタンスをグループから除外するまでの時間の目安

[プロトコルタイムアウト]×[プロトコル大試行]＋[検証済みタイムアウト]＋[pingタイムアウト]

5.4 Interstage Java EE管理コンソールのチューニング

ここでは、Interstage Java EE管理コンソールのチューニングについて説明します。

Interstage Java EE管理コンソールはInterstage Java EE DASサービス上で動作するため、「5.1 Interstage Java EE DASサービスのチューニング」も参照してください。

5.4.1 セッションタイムアウト

セッションタイムアウトの初期値は、60分です。

セッションタイムアウト値を変更する場合の手順を以下に示します。

1. セッションタイムアウト値の変更

Interstage Java EE管理コンソールまたはasadminコマンドを利用してセッションタイムアウト値を変更します。

- 113 -

－ Interstage Java EE管理コンソールを利用する場合

以下の画面からセッションタイムアウトの値を変更します。

[スタンドアロンインスタンス] > [server (Admin Server)] > [詳細]

－ asadminコマンドを利用する場合

asadminコマンドのsetサブコマンドによりセッションタイムアウトの値を変更します。

定義項目名などの詳細は、「リファレンスマニュアル(コマンド編)」の「Java EE運用コマンド」－「asadminコマン

ドで操作できる定義項目」の「configs.config.admin-serviceの定義項目」を参照してください。

2. サービスの再起動

Interstage Java EE DASサービスを再起動します。

ijdasstopおよびijdasstartコマンドを実行して、Interstage Java EE DASサービスを再起動します。

5.4.2 アップロードファイルの最大サイズのチューニング

Interstage Java EE管理コンソールによる配備(再配備)時において、アップロード可能なアプリケーションのデフォルトの

大ファイルサイズは100000000byteです。

アップロードファイルの大サイズを変更する場合、以下の手順を実行します。

1. Interstage Java EE DASサービスを停止します。

2. 以下のファイルをバックアップした後、編集します。

C:\Interstage\F3FMisjee\lib\install\applications\admingui\adminGUI_war\WEB-INF\web.xml

/opt/FJSVisjee/lib/install/applications/admingui/adminGUI_war/WEB-INF/web.xml

編集内容

UploadFilterの初期化パラメータ「maxSize」に、変更したいアップロードファイルの大サイズを設定します。無

制限とする場合は、「-1」を設定します。

例

上限値を200000000byteに変更する場合

<filter-name>UploadFilter</filter-name>

<filter-class>com.sun.webui.jsf.util.UploadFilter</filter-class>

<init-param>

<param-name>maxSize</param-name>

<param-value>200000000</param-value>

</init-param>

例

無制限とする場合

<filter-name>UploadFilter</filter-name>

<filter-class>com.sun.webui.jsf.util.UploadFilter</filter-class>

<init-param>

<param-name>maxSize</param-name>

- 114 -

<param-value>-1</param-value>

</init-param>

3. Interstage Java EE DASサービスを起動します。

注意

アップロードファイルの大サイズを増やす場合や無制限にする場合、以下に注意してください。

・ファイルサイズの大きいアプリケーションの配備(再配備)は時間がかかります。

配備(再配備)処理中にInterstage Java EE DASサービスの停止やマシンの再起動を行わないでください。

・ 2Gバイトを超えるファイルは配備(再配備)できません。2Gバイト未満のファイルを指定して配備(再配備)を行ってくだ

さい。

5.4.3 ポート番号

Interstage Java EE管理コンソールで使用するHTTPリスナーポートは、Interstage Java EE DASサービスの運用管理用

HTTPリスナーポートと同一です。

HTTPリスナーポートのポート番号を変更する場合の手順を以下に示します。

1. ポート番号の変更

Interstage Java EE管理コンソールまたはasadminコマンドを利用してポート番号を変更します。


以下の画面から「リスナーポート」の値を変更します。

[設定] > [server-config] > [HTTPサービス] > [HTTPリスナー] > [admin-listener]


asadminコマンドのsetサブコマンドによりポート番号を変更します。

変更方法については、「5.1 Interstage Java EE DASサービスのチューニング」の「運用管理用HTTPリスナーの

ポート番号を変更する場合」を参照してください。




5.4.4 SSL通信の利用

Interstage Java EE管理コンソールでSSL通信を行うための設定は、Interstage Java EE DASサービスの運用管理用HTTPリスナーのSSL通信利用設定と同じです。

SSL通信を行うための設定を変更する場合の手順を以下に示します。

1. SSL通信利用設定の変更

Interstage Java EE管理コンソールまたはasadminコマンドを利用してSSL通信利用設定を変更します。


以下の画面から「セキュリティー」の設定を変更します。

[設定] > [server-config] > [HTTPサービス] > [HTTPリスナー] > [admin-listener]

- SSL通信を行う場合

「セキュリティー」の「有効」のチェックボックスを選択します。

- SSL通信を行わない場合

「セキュリティー」の「有効」のチェックボックスの選択を解除します。

- 115 -


asadminコマンドのsetサブコマンドによりSSL通信利用設定を変更します。

変更方法については、「5.1 Interstage Java EE DASサービスのチューニング」の「運用管理用HTTPリスナーの

SSL通信利用設定を変更する場合」を参照してください。




5.5 配備時のチューニング

IJServerクラスタへアプリケーションの配備を行った後のIJServerクラスタ起動時に、Interstage Java EE Node Agentサービ

スはIJServerクラスタの起動に必要な資産を展開するプロセスを起動します。

このプロセスの大ヒープ領域サイズが不足した場合、展開後のIJServerクラスタの起動に必要な資産に不整合が発生

する可能性があります。

以下のJava VMオプションを指定すると、IJServerクラスタの起動に必要な資産を展開するプロセスの大ヒープ領域サ

イズをチューニングできます。

項目 Java VMオプション

Java VMの大ヒープ領域サイズ -Xmx

アプリケーションを展開するプロセスのJava VMオプションは、Interstage Java EE管理コンソール、およびasadminコマン

ドを使用して変更できます。詳細については、以下を参照してください。


・「Java EE運用ガイド」－「Interstage Java EE Node Agentサービスの定義項目」の「Node Agentの追加プロパティ」

手順

1. 以下のプロパティを設定し、アプリケーション展開処理を実行するプロセスのヒープ領域サイズを設定します。

「Node Agentの追加プロパティ」のINSTANCE-SYNC-JVM-OPTIONS例) asadmin set node-agent.ijna.property.INSTANCE-SYNC-JVM-OPTIONS=-Xmx256m

2. Interstage Java EE Node Agentサービスを再起動します。

5.6 Webコンテナのチューニング

Webコンテナの処理の流れ

Webコンテナは以下の流れでクライアントからリクエストを受け付けて処理します。

1. Webサーバがクライアントからリクエストを受け付け、Webサーバコネクタ経由でWebコンテナへ送信する。

2. WebコンテナがWebサーバコネクタからリクエストを受け付ける。

3. 受け付けたリクエストを一時的にHTTP接続キューに格納する。

4. 要求処理スレッドは一定間隔でHTTP接続キュー内を監視する。

5. HTTP接続キューにリクエストがあった場合、要求処理スレッドはリクエストを処理する。

上記はWebコンテナのチューニングポイントとして以下の2つに分類できます。

・同時処理数(初期スレッド数、スレッド数、スレッドの増分)

- 116 -

・接続数(WebサーバコネクタのWebコンテナへの大接続数、大保留カウント、キューサイズ)

Webコンテナの処理の流れの5.は同時処理数に関係しています。

5.は「初期スレッド数」、「スレッド数」、「スレッドの増分」で設定することが可能です。

Webコンテナの処理の流れの1.、2.、3.は接続数に関係しています。

1.は「WebサーバコネクタのWebコンテナへの大接続数」で設定することが可能です。

2.は「大保留カウント」で設定することが可能です。

3.は「キューサイズ」で設定することが可能です。

以下に、リクエストの流れを基に各設定項目の関係を示します。

同時処理数

同時処理数およびサーバーインスタンスを追加すると、Webアプリケーションの同時実行多重度を増やせます。

同時処理数を増やすと、1プロセスあたりの実行多重度を増やせますが、同時処理数が増えることによる負荷や資源の

増加により効果はみられない可能性があります。通常はデフォルト値以下で運用することを推奨しています。

アプリケーションから呼び出すEJBの「5.8.3 Enterprise Beanインスタンスのプーリング」と「5.8.2 Enterprise Beanインスタン

スのキャッシング」、JDBCのコネクション数にあわせてチューニングしてください。

同時処理数については、以下が設定できます。

・初期スレッド数

・スレッド数

・スレッドの増分

同時処理数は、Interstage Java EE管理コンソールの[設定] > [クラスタ名-config] または [server-config] > [HTTP サービ

ス] > [要求処理]タブ、およびasadminコマンドを使用して変更できます。詳細については、以下のマニュアルを参照して

ください。

- 117 -



・「リファレンスマニュアル(コマンド編)」－「configs.config.http-serviceの定義項目」の

request-processing.thread-count(スレッド数)request-processing.initial-thread-count(初期スレッド数)request-processing.thread-increment(スレッドの増分)

接続数

接続数は、運用するシステムの要求の違いによって以下のように設定します。

・ Webコンテナの負荷が高く処理できないリクエストは、時間がかかってもかまわないので、正常に処理させたい場合

項目設定値

WebサーバコネクタのWebコンテナ

への大接続数

なし(無制限)

Webコンテナの大保留カウントリクエストを受け付けることができるだけの十分に大きな

値を設定

Webコンテナのキューサイズ処理待ちのリクエストを保持することができるだけの十分

に大きな値を設定

・ Webコンテナの負荷が高く処理できないリクエストは、長時間待たせるのではなく、エラーとしてクライアントに通知し

たい場合

項目設定値

WebサーバコネクタのWebコンテナ

への大接続数

Webコンテナが処理可能な数を設定

Webコンテナの大保留カウントリクエストを受け付けることができるだけの十分に大きな

値を設定

Webコンテナのキューサイズ Webコンテナの大接続数と同じ値を設定

接続数に関する設定項目について、以下に説明します。

WebサーバコネクタのWebコンテナへの最大接続数

－ WebサーバとWebコンテナを同一マシン内で運用する場合

Interstage Java EE管理コンソールの[クラスタ] または[スタンドアロンインスタンス] > [クラスタ名] または[サーバー

インスタンス名] > [Webサーバコネクタ]タブ、およびasadminコマンドを使用して変更できます。詳細については、

以下のマニュアルを参照してください。

- Interstage Java EE管理コンソールヘルプ

- 「リファレンスマニュアル(コマンド編)」－「update-web-server-connector-configサブコマンド」の--maxprocessorsオプション

－ WebサーバとWebコンテナをそれぞれ別のマシンで運用する場合

Webサーバを運用するマシン側で設定します。

Interstage管理コンソールからWebサーバコネクタの大接続数で設定します。また、isj2eeadminコマンドでも設

定できます。詳細については、以下のマニュアルを参照してください。

- Interstage管理コンソールのヘルプ

- 「リファレンスマニュアル(コマンド編)」の「isj2eeadmin」

Webコンテナの最大保留カウント

本項目の値を増やすと、Webコンテナが同時に受け付けることができるリクエスト数を増やせます。運用中に高負荷

な状態となった場合に想定される、クライアントからの同時リクエスト数を指定しておくことを推奨します。

- 118 -

大保留カウントは、Interstage Java EE管理コンソールの[設定] > [クラスタ名-config] または [server-config] > [HTTPサービス] > [接続プール]タブ、およびasadminコマンドを使用して変更できます。詳細については、以下のマニュア

ルを参照してください。

－ Interstage Java EE管理コンソールヘルプ

－「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」

－「リファレンスマニュアル(コマンド編)」－「configs.config.http-serviceの定義項目」の

connection-pool.max-pending-count

注意

大保留カウントに設定された値はWebコンテナが使用するSocketのbacklogに設定されます。Socketのbacklogに設

定した値はOSによって有効となる範囲が決まっていますので、大保留カウントに設定した値がすべて有効となるわ

けではありません。

Socketのbacklogの有効範囲については各OSのドキュメントを参照してください。

なお、Windows (R)の場合、200より大きな値を設定しても有効になりません。

Webコンテナのキューサイズ

本項目の値を増やすと、Webコンテナが受け付けたクライアントからのリクエストを、Webコンテナが処理できるように

なるまでの間保持する数を増やせます。

運用時に一時的に負荷が高くなり、Webコンテナの同時処理数を超えるリクエストを受け付けることが想定される場合

は、Webコンテナの同時処理数を抑えて、Webコンテナのキューサイズに大きな値を設定することで、サーバ全体の

レスポンスの悪化を防ぐことができます。

－設定ポイント1:運用時に一時的に負荷が高くなり、クライアントからのリクエスト処理に失敗しかつ、サーバーログにWEB1505が

出力されている場合は、キューサイズを大きくしてください。

－設定ポイント2:キューサイズを増やしてリクエストを処理することができるだけの十分に大きなキューを用意した場合、クライアン

トからのリクエストに対するレスポンスに遅れが生じる可能性があります。Webサーバコネクタの送受信タイムアウ

ト値を増やしてください。

キューサイズは、Interstage Java EE管理コンソールの[設定] > [クラスタ名-config] または [server-config] > [HTTPサー

ビス] > [接続プール]タブ、およびasadminコマンドを使用して変更できます。詳細については、以下のマニュアルを




－「リファレンスマニュアル(コマンド編)」－「configs.config.http-serviceの定義項目」の

connection-pool.queue-size-in-bytes

Webサーバコネクタの送受信タイムアウト

－ WebサーバとWebコンテナを同一マシン内で運用する場合

Interstage Java EE管理コンソールの[クラスタ] または[スタンドアロンインスタンス] > [クラスタ名] または[サーバー

インスタンス名] > [Webサーバコネクタ]タブ、およびasadminコマンドを使用して変更できます。詳細については、



- 「リファレンスマニュアル ( コマンド編 ) 」－「 update-web-server-connector-config サブコマンド」の --sendreceivetimeoutオプション

－ WebサーバとWebコンテナをそれぞれ別のマシンで運用する場合

Webサーバを運用するマシン側で設定します。

- 119 -

Interstage管理コンソールからWebサーバコネクタの送受信タイムアウトで設定します。また、isj2eeadminコマンド

でも設定できます。詳細については、以下のマニュアルを参照してください。

- Interstage管理コンソールのヘルプ

- 「リファレンスマニュアル(コマンド編)」の「isj2eeadmin」

キープアライブ

キープアライブに関する設定項目について、以下に説明します。

キープアライブの有効/無効および、1回のコネクションで処理可能なリクエスト数

本項目では、HTTPのキープアライブの有効/無効および、1回のコネクションで処理可能なリクエスト数を設定します。

"無効"を指定した場合は、1つのリクエストが完了するたびに接続を閉じて、次のリクエストに対して新しく接続を行います。

"有効"を指定した場合は、Webコンテナがレスポンスを返した後、次のリクエストが来るまでの間、HTTP接続を確立

し、リクエストの転送効率を向上させることができます。

初期値は、"無効"です。

IPCOMなどの負荷分散装置と連携する場合は、負荷分散装置のキープアライブ機能の設定と合わせる必要があり

ます。詳細については、負荷分散装置のマニュアルを参照してください。

キープアライブの有効/無効および、1回のコネクションで処理可能なリクエスト数は、Interstage Java EE管理コンソー

ルの[設定] > [クラスタ名-config]または[server-config] > [HTTPサービス]の[追加プロパティ]およびasadminコマンド

を使用して、"maxKeepAliveRequests"プロパティで変更することができます。詳細については、以下のマニュアルを




－「リファレンスマニュアル ( コマンド編 ) 」－「 configs.config.http-service の定義項目」の

「property.maxKeepAliveRequests(１回のコネクションで処理可能なリクエスト数)」

キープアライブのタイムアウト

本項目の値は、Webコンテナがレスポンスを返した後、次のリクエストが来るまでの間、キープアライブ接続を維持す

る時間を表します。クライアントのキープアライブのタイムアウト仕様に合わせて、タイムアウトを設定してください。

例えば、クライアントがサーバにつながっていることが前提でリクエストを投げてくる場合は、クライアント側のタイムア

ウトより大きい値を設定してください。

ただし、この項目には10秒以下の値を設定できません。

キープアライブのタイムアウトは、asadminコマンドを使用して変更できます。詳細については、以下のマニュアルを参



－「リファレンスマニュアル(コマンド編)」－「configs.config.http-serviceの定義項目」の「keep-alive.timeout-in-seconds（キープアライブのタイムアウト）」

注意

キープアライブが"無効"な場合、リクエスト毎に接続が切断されるため、クライアント側(Webサーバ/Webサーバコネクタを

使用する運用の場合、Webサーバを運用するマシンを含む)にて、TCP/IP資源(エフェメラルポート)をより多く消費します。

短時間に多くのリクエストが行われる場合に、TCP/IP資源が枯渇する場合があります。

必要に応じて、キープアライブを"有効"にするか、または「3.4 TCP/IPパラメタのチューニング」を参照し、TCP/IPパラメタ

をチューニングしてください。

5.7 セッションリカバリ機能のチューニング

セッションリカバリ機能を使用する場合のJavaヒープサイズは、以下のように見積もります。

- 120 -

セッションリカバリ機能(Session Registry Server)を使用する場合

以下の式で見積もって、「5.3.2 Java VMのヒープ領域サイズ/Perm領域サイズ」で見積もったIJServerクラスタのJavaヒープサイズに加算してください。(単位:Mバイト)

35 ＋ (0.4 × k) ＋ (0.05 × a) ＋ ((0.001 ＋ 0.05 × d ＋ d) × s) × 2

90 ＋ (0.4 × k) ＋ (0.05 × a) ＋ ((0.001 ＋ 0.05 × d ＋ d) × s) × 2

80 ＋ (0.4 × k) ＋ (0.05 × a) ＋ ((0.001 ＋ 0.05 × d ＋ d) × s) × 2

70 ＋ (0.4 × k) ＋ (0.05 × a) ＋ ((0.001 ＋ 0.05 × d ＋ d) × s) × 2

k: Session Registry Serverの同時処理数

a: (IJServerクラスタに配備している)Webアプリケーションの数

d: セッションの保持するデータ容量＝ Webアプリケーションでセッションの属性(Attribute)にセットするオブジェクトおよびキーのサイズの合計値

s: セッション数

例: 対象とするIJServerクラスタは同時処理数64、Webアプリケーション1つ、セッションに格納するデータ量が2KB、

セッション数が1000の場合

35 ＋ (0.4 × 64) ＋ (0.05 × 1) ＋ ((0.001 ＋ 0.05 × 0.002 ＋ 0.002) × 1000) × 2＝66.85

90 ＋ (0.4 × 64) ＋ (0.05 × 1) ＋ ((0.001 ＋ 0.05 × 0.002 ＋ 0.002) × 1000) × 2＝ 121.85

80 ＋ (0.4 × 64) ＋ (0.05 × 1) ＋ ((0.001 ＋ 0.05 × 0.002 ＋ 0.002) × 1000) × 2＝ 111.85

70 ＋ (0.4 × 64) ＋ (0.05 × 1) ＋ ((0.001 ＋ 0.05 × 0.002 ＋ 0.002) × 1000) × 2＝ 101.85

Session Registry ServerはJava VM上で動作するため、実際のJavaヒープサイズは、負荷やGCの動作状況により異な

ります。

そのため正確なメモリ使用量は次のようにして実測することにより見積もることを推奨します。

－本番運用のピーク時と同一条件で動作させます。Java VMが使用するメモリが不足すると、イベントログ/システム

ログにメッセージが出力されますので、Javaヒープサイズの大値を増やして、適な値としてください。求めた

Javaヒープサイズの大値をそのまま本番運用時の値として利用します。

なお、セッションリカバリ機能(Session Registry Server)は、Interstage Application Server Enterprise Editionで運用可能

です。

セッションリカバリ機能(Session Registry Client)を使用する場合

以下の式で見積もって、「5.3.2 Java VMのヒープ領域サイズ/Perm領域サイズ」で見積もったIJServerクラスタのJavaヒープサイズに加算してください。(単位:Mバイト)

- 121 -

(0.001 ＋ 0.05 × d ＋ d) × s

d: セッションの保持するデータ容量＝ Webアプリケーションでセッションの属性(Attribute)にセットするオブジェクトおよびキーのサイズの合計値

s: セッション数

なお、セッションリカバリ機能(Session Registry Client)は、Interstage Application Server Enterprise Edition、InterstageApplication Server Standard-J Editionで運用可能です。

5.8 EJBコンテナのチューニング

EJBコンテナをチューニングする時に、考慮するポイントについて説明します。

5.8.1 スレッドプーリング

クライアントからEnterprise JavaBeanに対して同時に要求が発行された場合、EJBコンテナは要求を別スレッドで実行して

並列処理します。

スレッドの作成処理はレスポンス時間に影響するため、スレッドプールを活用してスレッドを再利用しています。

スレッドプーリングは以下のチューニングを行うことができます。

・ EJBアプリケーションの同時処理数制御

・リクエストの優先順位付け

スレッドはEnterprise JavaBeanのアクセスパターンにより、制御が異なります。以下にEnterprise JavaBeanのアクセスパター

ンとスレッド制御の関係を説明します。

Enterprise JavaBeanのアクセスパターンとスレッド制御の関係

以下にEnterprise JavaBeanのアクセスパターンを示します。

EJBコンテナがスレッド制御を行うアクセスパターン

以下の場合はEJBコンテナがスレッドプールを使用してスレッド制御します。

－ RMI-IIOPによるリモートアクセスによりEnterprise JavaBeanに対して要求が発行される場合

- 122 -

－ JMSメッセージが受信され、Message-driven Beanが実行される場合

－リソースアダプタのメッセージが受信され、Message-driven Beanが実行される場合

呼出し元のスレッドで動作するアクセスパターン

以下のJava VM内の呼出しの場合は呼出し元のスレッドで動作します。

－ EJB間の呼出し

－ Servlet/JSPからのEJB呼出し

－ WebサービスからのEJB呼出し

－ JPA Entityに対する操作

HTTP通信によるアクセスの場合はスレッドのチューニングについては、「5.6 Webコンテナのチューニング」と「5.10Webサービスのチューニング」を参照してください。

リソースアダプタのスレッドで動作するアクセスパターン

リソースアダプタのメッセージを受信するMessage-driven Beanの場合、メッセージリスナーメソッドはリソースアダプタ

が作成したスレッドで動作します。

EJBアプリケーションの同時処理数制御

IJServerクラスタプロセス起動時にスレッドプールの小プールサイズのスレッドを作成しプールに格納します。

要求の処理開始前にプールを検索し、プールにスレッドがない場合、スレッドを作成して要求を実行します。

処理完了後、作成したスレッドは削除されることなくプールに返却されます。現在のスレッド数がスレッドプールの大

プールサイズとなり、プールにスレッドがない状態で要求が配信された場合、スレッドがプールに戻るまで要求をキュー

に入れて待機します。

リクエストの優先順位付け

RMI-IIOPによるリモートアクセスが行われるEJBアプリケーションでは、EJBアプリケーションごとにスレッドプールを作成

し大プール数を指定することにより、EJBアプリケーションごとに同時処理数を制御できます。

EJBアプリケーションに個別にスレッドプールを割り当てることによって、他のリモートアクセス対象のEJBアプリケーション

よりも高い優先度で実行できます。個別のスレッドプールに割り当てられたEJBアプリケーションは、他のEJBアプリケー

ションに対する要求がスレッドプールでキューイングされていても独立したスレッドプールで実行できるため、優先的に実

行できます。

スレッドプールの設定

以下にスレッドプールのチューニング項目について説明します。

チューニング項目意味効果

小プールサイズスレッドプールの初期数および小数です。

IJServerクラスタ起動時に作成するスレッド数で

す。

想定している同時に発

行される要求数を指定

するとレスポンスタイムを

削減できます。

大プールサイズスレッドプールの大値です。

大値のスレッドが動作した場合、要求が発行さ

れてもスレッドを作成せず、スレッドが空くまで、

要求はキューに置かれます。

スレッドプールの大値

によりスレッドプールが使

用するメモリやリソースを

制御できます。

アイドルタイムアウトプール内のスレッドがアイドル状態のままでいら

れる長時間(秒単位)です。

この期間を過ぎるとスレッドを破棄します。ただ

し、小値のスレッド数分はプーリングされ続け

ますので破棄対象外となります。また、IJServerクラスタプロセスが停止するとスレッドも削除されま

す。

不要になった過度のス

レッドを破棄することによ

りメモリやリソースの適

化ができます。

- 123 -

EJBアプリケーションでは、RMI-IIOPによるリモートアクセスにおいて、個別のスレッドプールが定義されている場合はそ

のスレッドプールが使用され、個別のスレッドプールが定義されていない場合は、用意されているデフォルトスレッドプー

ルが使用されます。

デフォルトスレッドプールは、以下の機能でも使用されるため、EJBアプリケーションへの要求が多くなるとスレッドの空き

待ちが発生し、遅延が発生する場合や応答がなくなる場合があります。

・ EJBタイマーサービスによるコールバックメソッドの実行

・ Enterprise Beanインスタンスのキャッシングによるpassivate処理の実行

・ Enterprise Beanインスタンスのプーリングによるプールの縮小や拡張処理の実行

・スレッドプールIDを定義していないリソースアダプタのWorkの実行

・別プロセスのEJBアプリケーションを呼び出した場合のリクエスト受信処理

RMI-IIOPによるリモートアクセスが行われるEJBアプリケーションについては、必ずデフォルトスレッドプールとは別のス

レッドプールを作成し、「Enterprise Beanごとのスレッドプール設定」を行ってください。

デフォルトスレッドプールは、初期値が「thread-pool-1」になっています。このスレッドプールは削除しないでください。

Enterprise Beanごとのスレッドプールの大プールサイズは、以下の見積もりを行ってください。

最大プールサイズ＝想定される最大クライアント多重度(注1)

注1) 想定されるスレッド多重度の合計。

デフォルトスレッドプール(thread-pool-1)の大プールサイズは、以下の見積もりを行ってください。200より小さい値に

なった場合は、200(デフォルト)にしてください。

最大プールサイズ＝ EJBタイマーサービスのタイマーの数

＋ Enterprise Beanの数

＋リソースアダプタのWork数 (注1)

＋想定される同時接続クライアントのプロセス数

＋想定される最大クライアント多重度 (注2)

＋呼出し先IJServerクラスタのプロセス数 (注3)

注1) スレッドプールIDを定義していないリソースアダプタだけ。

注2) 想定されるスレッド多重度の合計。

注3) 他IJServerクラスタのEJBアプリケーションなどを呼び出した場合の、呼出し先IJServerクラスタのプロセス数。

スレッドプールの作成

スレッドプールは、Interstage Java EE管理コンソール、およびasadminコマンドを使用して作成できます。詳細は、以

下のマニュアルを参照してください。


－「リファレンスマニュアル（コマンド編）」の「create-threadpoolサブコマンド」

スレッドプールの設定値は、Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更できます。詳

細は、以下のマニュアルを参照してください。


－「リファレンスマニュアル（コマンド編）」の「configs.config.thread-poolsの定義項目」

Enterprise Beanごとのスレッドプール設定

作成したスレッドプールを、使用するEJBアプリケーションのInterstage deployment descriptorで指定します。詳細は、


－「Java EE運用ガイド」－「Interstage EJB application deployment descriptor (sun-ejb-jar.xml)」の<use-thread-pool-id>タグ

- 124 -

5.8.2 Enterprise Beanインスタンスのキャッシング

Stateful Session Beanの場合、クライアントの初期アクセスからRemove要求まで同一インスタンスを使用し、クライアントと

の対話状態を保持するため、他Enterprise Beanに比べてメモリ使用量が多くなります。メモリ使用量を制御するため、要

求実行中ではないBeanインスタンスをキャッシュする時間や数を調整することができます。

Stateful Session BeanインスタンスのライフサイクルはEJBの規約に説明されています。EJBコンテナはメソッド実行可状態

のBeanインスタンスをキャッシュに格納します。クライアントからBeanのビジネスメソッドに対して再度要求がくると、Beanイ

ンスタンスをキャッシュから取得し、メソッドを実行して、実行完了後にインスタンスをキャッシュに戻します。同じBeanに対

して再度要求がくると、該当のBeanインスタンスをキャッシュから取得し、メソッド実行完了後にキャッシュに戻します。

クライアントからBeanに対してRemove要求が発行されるとBeanインスタンスがキャッシュから削除され、インスタンスが破

棄されます。

Stateful Session Beanでは以下のチューニング項目でBeanインスタンスのキャッシングを変更できます。

チューニング項目効果

SFSB持続性のタイプ「none」に設定することでBeanインスタンスをファイルシス

テムに格納することを抑止するため、ユーザーは不要と

なったファイルの削除を意識する必要がありません。

「file」に設定することでキャッシュに格納されたBeanイン

スタンスから長時間使用されていないものをファイルシス

テムにpassivateするため、不要なメモリの増加を防ぐこと

ができます。ただし、passivateしたファイルは、ユーザー

が削除する必要があります。

「SFSB持続性のタイプ」で「file」を設定する場合は「SFSB持続性のタイプ「file」で運用する場合の注意事項」を確認して

ください。

「SFSB持続性のタイプ」はIJServerクラスタごとに設定できます。この設定は、Interstage Java EE管理コンソール、および

asadminコマンドを使用して変更できます。詳細は、「Java EE運用ガイド」－「EJBコンテナの定義項目」を参照してくださ

い。

キャッシュの設定

チューニング項目「SFSB持続性のタイプ」によって、キャッシングのチューニング項目の動作が変わります。

以下の表にキャッシング機能を制御するチューニング項目を説明します。


大キャッシュサイズ同時にアクセスするクライアント数に設定することにより、

メモリの使用量を削減できます。

キャッシュのサイズ変更量要求のピークが終わって不要になったインスタンスを素

早く破棄することによりメモリ消費を低減できます。

本設定はSFSB持続性のタイプがfileのときのみ有効で

す。

キャッシュアイドルタイムアウトクライアントがBeanに対してRemove要求を発行し忘れて

いる場合に、不要なBeanインスタンスが自動的に消去さ

れるため、不要なメモリの増加を防ぐことができます。

削除タイムアウト長時間使用されていない不要なBeanインスタンスが消去

されるため、資源の適化ができます。


す。

選択内容の削除ポリシー削除ポリシーをBeanの使用パターンに合わせることで

SFSB持続性のタイプがnoneのとき、使用頻度の低い

Beanインスタンスをキャッシュから削除できます。また、

SFSB持続性のタイプがfileのとき頻繁に使用されるBean

- 125 -


インスタンスのpassivateとactivate処理による性能劣化を

縮小できます。

EJBコンテナがpassivateするインスタンスの保存場所は以下のチューニング項目で変更できます。


セッション格納位置例えば容量にゆとりがある任意のディスクドライブを指定

して資源配置の適化を図ったり、ファイルI/Oが速い任

意のディスクドライブを指定することによりファイル化した

Beanインスタンスの操作速度を向上させることができます。


す。

デフォルトの格納場所とそのディレクトリ配下の構成については、「Java EE運用ガイド」－「IJServerクラスタのファイル構

成」を参照してください。ファイルはpassivateしたBeanインスタンスごとに作成され、Beanのactivate、削除タイムアウト、ま

たはIJServerクラスタの削除時に削除されます。セッション格納位置のディスク容量の見積もり方法については、「機能:Java EE」を参照してください。

キャッシュのチューニング設定はEnterprise Beanごとに指定できます。定義詳細については、以下のマニュアルを参照し

てください。

・「Java EE運用ガイド」－「Interstage EJB application deployment descriptor (sun-ejb-jar.xml)」の<ejb><bean-cache>タ

グ

Enterprise Beanのキャッシュ設定を指定しない場合はIJServerクラスタの値が使用されます。この値は、Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更できます。詳細については、以下のマニュアルを参照してくださ

い。


・「リファレンスマニュアル(コマンド編)」－「setサブコマンド」の「configs.config.ejb-containerの定義項目」

注意

Interstage Java EE DASサービスではSFSB持続性のタイプは「none」固定となります。

SFSB持続性のタイプ「none」で運用する場合の注意事項

・ EJBコンテナはIJServerクラスタの停止時にキャッシュしている全Beanインスタンスを削除します。

SFSB持続性のタイプ「file」で運用する場合の注意事項

・ IJServerクラスタ停止状態でStateful Session Beanを配備解除した場合、「セッション格納位置」配下の資産は削除さ

れません。このときはアプリケーション配備解除後にユーザーが資産を削除してください。

・ IJServerクラスタ起動状態でStateful Session Beanを配備解除した場合、「セッション格納位置」配下の資産は削除さ

れます。IJServerクラスタ起動状態では「セッション格納位置」配下の資産の削除をユーザーは行わないでください。

・ passivateする時には Beanインスタンスを直列化してファイルシステムに格納します。このため、Beanインスタンスから

参照するオブジェクトが直列化できる (java.io.Serializableインタフェースを実装するなど)必要があります。Beanインス

タンスが直列化できない場合には java.io.NotSerializableException例外が発生してpassivateに失敗し、そのBeanイ

ンスタンスは削除されます

・ EJBコンテナはIJServerクラスタの停止時にキャッシュしている全Beanインスタンスをpassivateします。ただしIJServerクラスタを強制停止した場合は、EJBコンテナはpassivateせずに終了します。

- 126 -

5.8.3 Enterprise Beanインスタンスのプーリング

クライアントから要求がある前にBeanのインスタンスを生成しておくことでアクセス時のインスタンス生成処理時間が省略

され、処理性能が向上します。Enterprise Beanインスタンスのプーリング機能は以下のEnterprise Beanで利用されます。

・ Stateless Session Bean

・ Message-driven Bean

以下にStateless Session BeanとMessage-driven Beanインスタンスのライフサイクルとプールについて説明します。

Stateless Session Beanの場合、クライアントからBeanに対して要求があると、EJBコンテナはプールからBeanインスタンス

を1つ取得し、そのインスタンスに対してビジネスメソッドを実行します。Message-driven Beanの場合、メッセージが届くと、

同様にプールからBeanインスタンスを取得しそのインスタンスに対してメッセージリスナーメソッドを実行します。実行完了

時にインスタンスをプールに戻します。

EJBタイマーによるコールバック処理の場合にも同様に、プールからインスタンスを取得しタイマーコールバックメソッドを

実行し、実行完了時にインスタンスをプールに戻します。

以下の表にプーリング機能を制御するチューニング項目を説明します。


初期および小プールサイズインスタンスをあらかじめ生成しておくことにより、プールされ

ているインスタンスを利用してすぐに実行できるため処理性

能が向上します。

大プールサイズプールの大値によりメモリ使用量を制御できます。

プールサイズ変更量クライアントからの要求数の急増によってメソッド実行可状態

のインスタンスが足りなくなった場合でも、プールサイズの即

時拡張により、インスタンス生成処理によるレスポンス遅延が

軽減されます。

プールアイドルタイムアウト不要になった過度のインスタンスを破棄することによりメモリ

の適化ができます。

注) プールの監視は指定値の間隔で実施しますが、起動後に1回行った後はEJBアプリケーションの使用状況を確認し、

使用されていないBeanインスタンスはプールサイズを調整しません。

注意

Message-driven Beanはインスタンスごとにセッションを使用してメッセージを受信します。そのため、プールの大値を2以上に設定するとメッセージ順序性が保証されません。

- 127 -

プール設定はEnterprise Beanごとに指定できます。定義詳細については、以下のマニュアルを参照してください。

・「Java EE運用ガイド」－「Interstage EJB application deployment descriptor (sun-ejb-jar.xml)」の<ejb><bean-pool>タグ

Enterprise Beanのキャッシュ設定を指定しない場合はIJServerクラスタの値が使用されます。この値は、Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更できます。詳細については、以下のマニュアルを参照してくださ

い。


・「リファレンスマニュアル(コマンド編)」－「setサブコマンド」の「configs.config.ejb-containerの定義項目」、または

「configs.config.mdb-containerの定義項目」

5.8.4 同一Java VM内のリモートアクセスでデータコピーを防ぐ機能

Enterprise Beanのリモートビジネスインタフェースにアクセスすると、同一Java VM内のアクセスであっても、ビジネスメソッ

ドの引数と返却値は値のコピーを転送します。このため、引数の値を呼出し先で変更したり、返却された値を呼出し元で

変更しても、呼出し先と呼出し元のコピーされた値には影響を与えません。

これは、IIOP経由でJava VM外からEnterprise Beanにアクセスした場合には、必ずビジネスメソッドの引数と返却値は値

のコピーを転送するため、同一Java VMで呼び出した場合とIIOP経由でJava VM外から呼び出した場合の仕様を統一

するためです。仕様が統一されるためアプリケーションの汎用性が向上します。

しかし、値のコピーを作成することは、オーバーヘッドが大きく、性能に影響を与えます。転送する値を変更しなければ値

の参照を転送しても動作上の差異はありません。

以上より、同一Java VM内でEnterprise Beanのリモートビジネスインタフェースにアクセスした場合、引数と返却値のコピー

ではなく参照を転送するように変更してメソッドのアクセス性能を改善できます。

参照

本機能の定義詳細については、以下のマニュアルを参照してください。

・「Java EE運用ガイド」－「Interstage EJB application deployment descriptor (sun-ejb-jar.xml)」の<ejb><pass-by-reference>タグ

5.9 JPAのチューニング

JPAはOLTP系(データの検索が多く、更新が少ない)のJava EEアプリケーションによく使用されます。Interstage永続性プ

ロバイダはデータベースで検索したデータをキャッシングすることにより性能を向上させることができます。

Interstage永続性プロバイダのチューニングオプションにはデータベースを検索したデータから作成するEntityインスタン

スをキャッシュするオプションが用意されています。これに合わせてJDBCの接続プールまたはデータベースのチューニ

ングも実施してください。

キャッシュは以下の2つが使用できます。

・永続性コンテキストキャッシュ

・永続性ユニットの共有キャッシュ

以下に各キャッシュについて説明します。

5.9.1 永続性コンテキストキャッシュ

エンティティマネージャを使用してEntityをデータベースから取得する場合、または作成したEntityを永続性コンテキスト

にマージする場合、Entityインスタンスが永続性コンテキストキャッシュに格納されます。このキャッシュのライフサイクルは

永続性コンテキストと同じです。

以下に永続性コンテキストキャッシュの特徴を説明します。

findメソッド

エンティティマネージャのfindメソッドでEntityを検索すると、まずは永続性コンテキストキャッシュから探します。

キャッシュにある場合は、データベースに問い合わせずにキャッシュされたインスタンスを返却します。キャッシュにない

- 128 -

場合は、「5.9.2 永続性ユニットの共有キャッシュ」を探します。共有キャッシュにもない場合、SQL文を発行しデータベー

スに問い合わせします。検索が成功した場合、Entityインスタンスを永続性コンテキストキャッシュに格納し、アプリケー

ションに返却します。

クエリメソッド

エンティティマネージャを使用してJPQLクエリメソッドを実行すると、SQL文を発行しデータベースから検索します。ただ、

レコードを見つけた場合、レコードと同じプライマリキーのEntityがすでに永続性コンテキストキャッシュに存在しているか

どうか確認します。

存在している場合は、現在の永続性コンテキストで行った更新やEntity間のリレーション関係の整合性を保つため、キャッ

シュしたインスタンスを返却します。

存在していない場合は、永続性ユニットの共有キャッシュを探します。共有キャッシュにもない場合、SQL文を発行しデー

タベースに問い合わせします。検索が成功した場合、Entityインスタンスを永続性コンテキストキャッシュに格納し、アプリ

ケーションに返却します。

Entityインスタンスの更新、マージ、削除

管理されているEntityインスタンスの更新、削除、または非管理状態のEntityインスタンスの永続性コンテキストへのマー

ジは永続性コンテキストキャッシュに反映されます。

データベースのレコードとの不整合について

エンティティマネージャを使用し各操作を実行する際、同一トランザクションや別トランザクションにおいて、そのエンティ

ティマネージャ以外のアクセス方法でデータベースの同一レコードを更新すると、永続性コンテキスト内で管理された

Entityインスタンスとデータベースのレコード間で不整合が発生する可能性があります。

これを回避するためには、エンティティマネージャの各操作に対するフラッシュやEntityデータの新化を必要に応じて

明示的に実行してください。また、Entityデータを新化する方法については以下に説明します。

Entityデータの最新化

Entityインスタンスの永続化フィールドの新データをデータベースから取得するため、以下の方法があります。

エンティティマネージャのrefreshメソッドを実行

Entityインスタンスをエンティティマネージャのrefreshメソッドに指定し本メソッドを実行すると、SQL文が発行され、レ

コードの新データが取得されます。新データがEntityインスタンスに反映され永続性コンテキストキャッシュも更

新されます。

JPQLクエリメソッドにInterstage永続性プロバイダのクエリヒントを使用

JPQLクエリーにリフレッシュのヒントを指定しクエリメソッドを実行すると、永続性コンテキストキャッシュと共有キャッシュ

を検索せずにデータベースに問い合わせます。成功した場合、レコードを取得してEntityインスタンスのコピーを作成

して、コピーを共有キャッシュに格納し、もとのEntityインスタンスをアプリケーションに返却します。永続性コンテキス

トキャッシュにそのEntityがすでに存在した場合、既存のオブジェクトが非管理状態になり、まだフラッシュしなかった

修正がデータベースに更新されません。共有キャッシュにEntityがすでに存在した場合、既存のオブジェクトを新しい

オブジェクトに上書きします。

注意

データの新化の各機能における注意事項を以下に説明します。

・エンティティマネージャのrefreshメソッドを実行する場合

－コンテナ管理のエンティティマネージャを使用した場合、このメソッドをトランザクション中しか実行できないため、

データ更新のない操作でもトランザクションを開始する必要があります。

－ refreshメソッドに指定するEntityインスタンスを取得した時にもSQL文を発行するので、データベースへ2回アクセ

スします。

・ Interstage永続性プロバイダのクエリヒントを使用する場合

－永続性コンテキストですでに行った更新やEntity間のリレーション関係の整合性を保てません。

- 129 -

－ Interstage永続性プロバイダの独自機能であるため、その他の永続性プロバイダで該当するヒントがない可能性

があり、移植性に影響があります。

リフレッシュ機能は以下のクエリヒントで指定します。

クエリヒント名値 (太字:省略値) 説明

toplink.refresh true キャッシュに問い合わせせずにデータベースを検索しま

す。検索したEntityのコピーを作成しコピーを共有キャッ

シュに格納します。もとのEntityインスタンスをアプリケー

ションに返却します。

false データベースからの検索結果をキャッシュ内のEntityと

比較し、すでに存在した場合、キャッシュされたEntityイ

ンスタンスをアプリケーションに返却します。

toplink.refresh.cascade

CascadeAllParts 検索したEntityをリフレッシュします。このEntityとリレー

ションが持つEntityが検索結果に含まれている場合、そ

のEntityもリフレッシュします。

CascadeByMapping

検索したEntityをリフレッシュします。リレーションの

cascade定義にCascadeType.REFRESHまたは

CascadeType.ALLを指定したEntityもリフレッシュしま

す。その他のリレーションのEntityインスタンスをリフレッ

シュしません。

NoCascading 検索したEntityをリフレッシュしますが、このEntityインス

タンスとリレーションが持つEntityインスタンスはキャッシュ

内に存在した場合、データをリフレッシュせずにキャッ

シュしたオブジェクトを返却します。

値は大文字と小文字を区別しません。

toplink.refresh.cascadeヒントの設定を有効にするためには、toplink.refreshヒントをtrueに指定する必要があります。

クエリヒントはマッピング定義ファイルdeployment descriptor (orm.xml)のquery-hintタグ、アノテーション(@QueryHint)、ま

たはQuery.setHintメソッドで指定します。

例

リフレッシュのヒントの定義例

@NamedQuery(name="Order.findOrdersByPK",

query="SELECT o FROM Order o WHERE o.id = :id",

hints={@QueryHint(name="toplink.refresh",

value="true"),

@QueryHint(name="toplink.refresh.cascade",

value="CascadeAllParts")})

5.9.2 永続性ユニットの共有キャッシュ

永続性ユニットはEntityクラスごとに共有キャッシュを管理しています。このキャッシュはすべての永続性コンテキストから

参照できます。

このキャッシュのライフサイクルは永続性ユニットと同じなので、エンティティマネージャファクトリの作成からクローズまで

使用されます。

以下に永続性ユニットの共有キャッシュの特徴を説明します。

- 130 -

共有キャッシュの参照タイミング

共有キャッシュの参照タイミングについては、「5.9.1 永続性コンテキストキャッシュ」を参照してください。

共有キャッシュの更新タイミング

永続性コンテキストをクローズする時、キャッシュ内のEntityインスタンスがコピーされ、共有キャッシュにマージされます。

以下に永続性コンテキストキャッシュと共有キャッシュの関係図と検索順番を示します。

1. クライアントからの要求により検索メソッドが実行される場合、まずは永続性コンテキストキャッシュから検索します。

2. 永続性コンテキストキャッシュにある場合、そのEntityインスタンスを返却します。ない場合は共有キャッシュを検索

します。

3. 共有キャッシュにある場合、そのEntityインスタンスのコピーを作成してコピーを永続性コンテキストキャッシュに格

納し、アプリケーションに返却します。共有キャッシュにもない場合、データベースへ問い合わせします。

データ更新の場合は、共有キャッシュ内のデータとデータベースのデータの整合性を保つために、キャッシュ機能を行

のロック機能と合わせて使用してください。行のロック機能については、「Java EE運用ガイド」－「行のロック機能」を参照


共有キャッシュの解放タイミング

共有キャッシュ内に格納されているEntityインスタンスはエンティティマネージャファクトリがクローズされるタイミングで解

放されます。コンテナ管理のエンティティマネージャを使用した場合、アプリケーションの停止時にエンティティマネージャ

ファクトリがクローズされます。チューニング設定により、Entityインスタンスがガーベッジコレクション(以降、GC)により破棄

されます。

以下に、共有キャッシュに格納されるEntityインスタンスがGC対象になるタイミングを制御するオプションを説明します。

この永続性ユニットプロパティを deployment descriptor (persistence.xml) または javax.persistence.Persistence の

createEntityManagerFactory(String, Map)メソッドに指定してください。

プロパティ名値 (太字:省略値) 説明

toplink.cache.type.<ENTITY>

・ Full

・ Weak

・ HardWeak

・ SoftWeak

特定のEntityに対応する共有キャッシュのタイプ

toplink.cache.type.default

その他のEntityの共有キャッシュのタイプ

toplink.cache.size.<ENTITY>

0～

MAX_INTEGER省略値:1000

特定のEntityに対応する共有キャッシュタイプによるサ

イズ

- 131 -

プロパティ名値 (太字:省略値) 説明

toplink.cache.size.default

その他のEntityの共有キャッシュタイプによるサイズ

toplink.cache.shared.<ENTITY>

・ true

・ false

特定のEntityに対応する共有キャッシュを有効・無効に

する

toplink.cache.shared.default

その他のEntityの共有キャッシュを有効・無効にする

値は大文字と小文字を区別します。

プロパティの<ENTITY>にEntity名またはパッケージ名を含むEntityクラス名を記載します。定義しないEntityにはdefaultを記載したプロパティの設定、または省略値が使用されます。

フィールドの更新を行わずにテーブルからいつも新の情報を取得したい場合は共有キャッシュを無効にしますが、一

般的には共有キャッシュを無効にする必要はありません。

特定のEntityに対応する共有キャッシュを無効にした場合、データの一貫性を保つためにそのEntityとrelationshipが持

つEntityの共有キャッシュも無効にしてください。

各共有キャッシュタイプについて以下に説明します。

キャッシュタ

イプ

意味推奨条件

Full Entityは削除されない限りメモリからフラッシュ

されません。指定したキャッシュサイズは初期

サイズとして使用され、上限サイズの設定はあ

りません。

データが少なく、メモリが多い場合

に使用します。

Weak 弱い参照(java.lang.ref.WeakReference)でEntityインスタンスを参照することにより、Fullよりメモリ使用量が少なくなります。指定したキャッ

シュサイズは初期サイズとして使用され、上限

サイズの設定はありません。

Java VM上でオブジェクトの参照が

なくなるとEntityインスタンスがGCに

より破棄される可能性があるため、

開始したトランザクションがサーバ側

で継続される場合だけ使用します。

HardWeak

Weakに似ていますが、ハード参照を参照する

サブキャッシュも持っています。サブキャッシュ

サイズを超えると使用頻度が低いEntityインス

タンスがサブキャッシュから弱い参照を使用し

ているキャッシュに移動されます。

指定したキャッシュサイズはサブキャッシュに格

納するEntityインスタンスの大数です。

ハード参照されるEntityインスタンス

が破棄されないため、キャッシュす

るインスタンスの大数をトランザク

ション中に参照するEntityインスタン

スの大数と同じに設定してくださ

い。

SoftWeak HardWeakとほぼ同じですが、サブキャッシュに

ソフト参照(java.lang.ref.SoftReference)を使用

しています。指定したキャッシュサイズはサブ

キャッシュに格納するEntityインスタンスの大

数です。

通常の環境でこのタイプを使用しま

す。

キャッシュするインスタンスの大数

をトランザクション中に参照する

Entityインスタンスの大数と同じに

設定してください。

アプリケーションの運用でサブキャッ

シュにキャッシュされるオブジェクト

が頻繁にGCにより破棄される場合、

HardWeakの使用を検討してくださ

い。

- 132 -

例

共有キャッシュタイプの定義例

<persistence xmlns="http://java.sun.com/xml/ns/persistence"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/persistence

http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"

version="1.0">

<persistence-unit name="com.company.my.pu">

<jta-data-source>jdbc/myDatasource</jta-data-source>

<properties>

<property name="toplink.cache.type.CountryCode" value="Full"/>

<property name="toplink.cache.size.CountryCode" value="100"/>

<property name="toplink.cache.shared.StockQuote" value="false"/>

<property name="toplink.cache.size.default" value="200"/>

</properties>

</persistence-unit>

</persistence>

5.10 Webサービスのチューニング

Webサービスでは、Webコンテナの同時処理数や接続数などのチューニングが有効です。これらの設定については、

「5.6 Webコンテナのチューニング」を参照してください。

また、エンドポイントがStateless Session Beanの場合、EJBコンテナのインスタンスプールのチューニングも有効です。イン

スタンスプールのチューニングについては「5.8.3 Enterprise Beanインスタンスのプーリング」を参照してください。

5.11 データベース連携環境のチューニング

物理的なデータベース接続はプール管理されてアプリケーションで共有されます。アプリケーションから接続の要求が

あった場合、アプリケーションサーバは、接続プールから接続を取得して、アプリケーションに返却します。また、アプリ

ケーションが接続を解放した場合、アプリケーションサーバは、その接続をプールに返却します。このJDBC接続プール

に対して以下のチューニングができます。

・プール内の接続数

・接続検証

・トランザクション管理

・詳細属性

各項目のチューニングは、Interstage Java EE管理コンソールの[JDBC] > [接続プール]、およびasadminコマンドで設定

できます。詳細は、以下のマニュアルを参照してください。また、詳細属性の定義項目は、JDBC接続プールの作成後に

値を更新してください。



・「リファレンスマニュアル(コマンド編)」－「create-jdbc-connection-poolサブコマンド」

・「リファレンスマニュアル(コマンド編)」－「resources.jdbc-connection-poolの定義項目」

5.11.1 プール内の接続数

JDBC接続プールの接続数をチューニングするため、以下を設定できます。

プールサイズのスケールアップは、アプリケーションから接続要求を受けたときに必要に応じて実行されます。また、プー

ルサイズのスケールダウンは一定時間の間隔で定期的に実行されます。

プールされた接続は、IJServerクラスタまたはInterstage Java EE DASサービスの停止時に削除されます。

- 133 -

・初期および小プールサイズ

・大プールサイズ

・プールサイズ変更量

・アイドルタイムアウト

・大待ち時間

これらの項目のチューニングは、Interstage Java EE管理コンソールまたはasadminコマンドで設定できます。

・ Interstage Java EE管理コンソールの場合

以下の画面で、設定できます。

－「リソース」>「JDBC」>「接続プール」>「一般」

詳細はInterstage Java EE管理コンソールヘルプを参照してください。

・ asadminコマンドの場合

JDBC接続プールを作成する時は、「リファレンスマニュアル(コマンド編)」－「create-jdbc-connection-poolサブコマン

ド」を参照してください。

JDBC接続プールの項目を更新する時は、「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」と

「resources.jdbc-connection-poolの定義項目」を参照してください。

以下に、プールサイズのスケールダウン、およびスケールアップの動作について説明します。

プールの定期監視(プールサイズのスケールダウン)

アプリケーションサーバでは、接続プールの状態を定期的に監視し、プールのリサイズを行います。以下の契機でプー

ル監視用のリサイザがスケジューリングされ、アイドルタイムアウトの間隔でリサイズタスクを実行します。

・プールの初期化時(注1)

・「すべての障害で」を有効に設定し、接続障害が検出された時(注2)

注1)プールの初期化は、IJServerクラスタまたはInterstage Java EE DASサービスがアプリケーションから初の接続要求

を受けたときに実行されます。

注2)接続障害と判断される条件は、「5.11.2 接続検証」を参照してください。

プールのリサイズタスクでは、アイドルタイムアウトまたは接続検証に失敗するような不正な接続をすべてプールから取り

除き、プールサイズ変更量を超えない範囲でサイズをスケールダウンさせようとします。不正な接続の数によっては、プー

ルサイズ変更量を超えるだけ削除されることがあります。削除の結果プールサイズの小値を下回ってしまった場合に

は、小値に達するまで接続を補完します。

具体的には、以下の手順で処理を実行します。ただし、説明のため以下の定義を使用します。

[プール内の接続数] = [使用されていない接続数] + [使用中の接続数][削除予定数] = [プールサイズ変更量] - [1.～2.の処理で削除した数][削除許容数] = [プール内の接続数] - [初期および小プールサイズ]

1. アイドルタイムアウトが発生した接続を削除

接続のタイムスタンプから、アイドルタイムアウトが発生した接続を検出しプールから削除します。

2. 接続検証に失敗した接続を削除

検証に失敗した接続をプールから削除します。接続検証の詳細は、「5.11.2 接続検証」を参照してください。

3. 大でも削除予定数だけの接続を削除

以下の条件を満たす場合、使用されていない接続を検索し、[削除予定数]を大としてプールから削除します。

条件を満たさない場合は削除されません。

- 134 -

0 < [削除予定数] <= [削除許容数]

4. プールサイズの修正

1.～3.の処理の結果、以下を満たした場合は、[初期および小プールサイズ]に達するまで接続を作成します。

[プール内の接続数] < [初期および小プールサイズ]

接続要求に応じたプールサイズのスケールアップ

アプリケーションからの接続要求の処理時、プール内の使用されていない接続の中で以下の2つの条件を満たす接続が

存在しない場合、プールサイズ変更量を超えない範囲でサイズをスケールアップさせます。

・接続のマッチングに成功

・接続検証に成功

スケールアップ時のプール内の動作は、以下です。次の2つの定義を説明の中で使用します。

[プール内の接続数] = [使用されていない接続数] + [使用中の接続数][生成許容数] = [ 大プールサイズ] - [プール内の接続数]

条件プール内の動作

[初期および小プールサイズ]未満 (注1) [初期および小プールサイ

ズ]へ達するまで接続を生成し

ます。

[初期および小プールサイ

ズ]以上、[ 大プールサイズ]未満

[プールサイズ変更量]だけ生

成可能な場合

[プールサイズ変更量]だけ接

続を生成します。


成すると、[ 大プールサイズ]を超えてしまう場合

[生成許容数]だけ接続を生成

します。

[ 大プールサイズ]と一致接続は生成されません。(注2)

注1) 接続検証の失敗により、プール内の使用されていない接続がすべて削除された場合などに該当します。

注2) ただし、接続のマッチングに失敗した未使用の接続が存在する場合、大でプールサイズ変更量分だけ接続を再

作成します。

接続のマッチング

接続のマッチングとは、プール内の接続の認証情報が接続要求時の認証情報と一致しているかを検証する機能です。

接続要求時の認証情報の指定方法は、「Java EE運用ガイド」－「リソースアクセス時の認証情報」を参照してください。

5.11.2 接続検証

プールされた接続をアプリケーションに返却する前に、アプリケーションサーバは接続が有効か検証できます。この検証

によって、データベースがネットワーク障害かデータベース・サーバ障害により利用不可となった場合、その接続をプー

ルから破棄し、再度プールから接続を獲得して有効な接続を返却します。プールに有効な接続が存在しなかった場合、

データベースから新たな接続を獲得するため、データベース接続を再確立できます。

接続検証が有効の場合には、以下が設定できます。

・検証方法

・テーブル名

・すべての障害で


- 135 -










また、接続検証が有効の場合には、アプリケーションサーバは以下の契機で接続検証を実効します。

接続検証の実行契機

A)プールの定期監視時の接続検証

アイドルタイムアウトの間隔で定期的に接続検証を実行します。

B)アプリケーションからの接続要求時の接続検証

接続を生成してからプールへ格納する前(B1)とプールから取得後にアプリケーションへ返却する前(B2)の2種類の契

機で接続検証が実行されます。

B1)接続生成時の接続検証

アプリケーションサーバはDBとの接続確立の直後、プールへ格納する前に事前に接続検証を実行します。

接続検証に失敗した場合、接続生成に失敗と判断し、アプリケーションへ例外を返却します。

B2)プール内から取得した接続に対する接続検証

プール内から取得した接続をアプリケーションへ返却する前に、接続検証を実行します。

プールサイズのスケールアップにより新規作成された接続のうちアプリケーションへ返却する接続に対しては、検

証不要のため接続検証をスキップします。プール初期化時に生成される接続は、プール内から取得した接続と見

なし接続検証を実行します。

- 「すべての障害で」が有効の時:「すべての障害で」の処理で一時的にプール内の接続が0になるのを補うために新たな接続を生成します。も

しこの時点で再確立の処理が完了し未使用な接続があれば、置き換えて(破棄して)要求元へ接続を返却し

ます。

- 「すべての障害で」が無効の時:検証失敗の接続を削除し、プールから次の接続を取り出して再度接続検証を実施します。プール内の使用

されていない接続がすべて接続検証に失敗した場合の動作は、「接続要求に応じたプールサイズのスケー

ルアップ」を参照してください。

注意

Interstage側のプーリング機能が無効の場合、接続を生成してからプールへ格納する前(B1) のタイミングのみで接続検

証が実行されます。

接続障害と判断される条件

「すべての障害で」が有効の場合に接続障害と判断される条件は、以下です。

・接続検証の実行時にJDBCドライバから例外が返却された場合

- 136 -

注意

・データベース接続を再確立できなかった場合には、例外が返却されます。

・自動的に再接続を行うことでデータベースで異常が発生しても業務継続ができるため、接続検証を有効にすること

がお勧めですが、アプリケーションでgetConnectionメソッドを実行して接続プールから接続を獲得する時にも検証を

行うため、性能オーバーヘッドが発生します。接続検証が不要な場合で、処理性能を向上させたい場合には必要に

応じて接続検証を無効にしてください。

・接続検証を無効に設定した場合、検証方法およびテーブル名の指定も無効となります。

・接続生成時に実行される接続検証は、モニタロギングの採取対象外です。このため、「検証に失敗した物理接続数」

は更新されません。

5.11.3 トランザクション管理

JDBC接続プールのトランザクション管理では、以下を設定できます。詳細は、「Java EE運用ガイド」－「データベース連

携アプリケーションの作成方法」を参照してください。

・非トランザクション接続

・トランザクション開始後の接続のみ参加

・トランザクション遮断

・遮断レベル











5.11.4 詳細属性

定義済みのJDBC接続プールをチューニングするため、以下を設定できます。

・文のタイムアウト

・プーリング

・リークタイムアウト

・リーク再要求

・作成再試行回数

・再試行間隔

・監査ログへのアクセス情報出力




- 137 -

－「リソース」>「JDBC」>「接続プール」>「詳細」



「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」と「resources.jdbc-connection-poolの定義項目」を参照


各定義項目の詳細は、「Java EE運用ガイド」－「JDBC接続プールの定義項目」を参照してください。

注意

文のタイムアウトに関する注意事項

・データベースにSymfowareを使用する場合、文のタイムアウトは利用できません。

・ PowerGres PlusはStatementのsetQueryTimeoutメソッドをサポートしません。setQueryTimeoutメソッドは実装されてい

ません。このメソッドを使用する場合、エラーとはならず、文のタイムアウトも発生しません。

詳細は、以下のURLを参照してください。

http://archives.postgresql.org/pgsql-bugs/2008-04/msg00161.php

PowerGres Plusの詳細は、PowerGres Plusのマニュアルを参照してください。

リークタイムアウトとリーク再要求に関する注意事項

リーク再要求が有効と設定された場合、接続リークが検出されると、自動的にその物理接続を破棄します。接続時にデー

タベースにアクセス中、または、トランザクション中の場合、ユーザアプリケーションの実行に失敗する可能性があります。

このようなことを避けるために、アプリケーションが発行するSQL文の実行時間や環境に応じて見積もった値を、利用す

るJDBC接続プールの「文のタイムアウト」に設定してください。

SQL文の実行時間を制限することにより、リーク再要求で自動的に物理接続を破棄するとき、その接続がデータベース

にアクセスしている可能性を低下させます。

なお、「リークタイムアウト」に十分に長い時間を設定することにより、検出された接続に確実にリークが発生した(つまり、

接続がデータベースアクセスに使われない)ことを保証します。また、JDBC接続を利用するときに、同一の接続を長時間

利用しないように、利用完了後すぐにクローズしてください。

プーリングに関する注意事項

Interstage側のプーリング機能が無効の場合、以下のチューニングはできません。

・初期および小プールのサイズ

・大プールのサイズ

・プールサイズの変更量


・大待ち時間


5.12 コネクタのチューニング

物理的なEISとの接続はプール管理されてアプリケーションで共有されます。アプリケーションから接続の要求があった

場合、アプリケーションサーバは、接続プールから接続を取得して、アプリケーションに返却します。また、アプリケーショ

ンが接続を解放した場合、アプリケーションサーバは、その接続をプールに返却します。このコネクタ接続プールに対し

て以下のチューニングができます。

・プール内の接続数

・接続検証

- 138 -

・トランザクション管理

・シャットダウンタイムアウト

各項目のチューニングは、Interstage Java EE管理コンソールの[コネクタ] > [コネクタ接続プール]、およびasadminコマン

ドで設定できます。詳細は、以下のマニュアルを参照してください。



・「リファレンスマニュアル(コマンド編)」－「create-connector-connection-poolサブコマンド」

・「リファレンスマニュアル(コマンド編)」－「resources.connector-connection-poolの定義項目」

5.12.1 プール内の接続数

コネクタ接続プールの接続数をチューニングするため、以下を設定できます。

プールサイズのスケールアップは、アプリケーションから接続要求を受けたときに必要に応じて実行されます。また、プー

ルサイズのスケールダウンは一定時間の間隔で定期的に実行されます。プールされた接続は、IJServerクラスタまたは

Interstage Java EE DASサービスの停止時に削除されます。

・初期および小プールサイズ

・大プールサイズ

・プールサイズ変更量


・大待ち時間

以下に、プールサイズのスケールダウン、およびスケールアップの動作について説明します。

プールの定期監視(プールサイズのスケールダウン)

アプリケーションサーバでは、接続プールの状態を定期的に監視し、プールのリサイズを行います。以下の契機でプー

ル監視用のリサイザがスケジューリングされ、アイドルタイムアウトの間隔でリサイズタスクを実行します。

・プールの初期化時(注1)

・「すべての障害で」を有効に設定し、接続障害が検出された場合(注2)

注1)プールの初期化は、IJServerクラスタまたはInterstage Java EE DASサービスがアプリケーションから初の接続要求

を受けたときに実行されます。

注2)接続障害と判断される条件は、「5.11.2 接続検証」を参照してください。

プールのリサイズタスクでは、アイドルタイムアウトまたは接続検証に失敗するような不正な接続をすべてプールから取り

除き、プールサイズ変更量を超えない範囲でサイズをスケールダウンさせようとします。不正な接続の数によっては、プー

ルサイズ変更量を超えるだけ削除されることがあります。削除の結果プールサイズの小値を下回ってしまった場合に

は、小値に達するまで接続を補完します。

具体的には、以下の手順で処理を実行します。ただし、説明のため以下の定義を使用します。

[プール内の接続数] = [使用されていない接続数] + [使用中の接続数][削除予定数] = [プールサイズ変更量] - [1.～2.の処理で削除した数][削除許容数] = [プール内の接続数] - [初期および小プールサイズ]

1. アイドルタイムアウトが発生した接続を削除

接続のタイムスタンプから、アイドルタイムアウトが発生した接続を検出しプールから削除します。

2. 接続検証に失敗した接続を削除

検証に失敗した接続をプールから削除します。接続検証の詳細は、「5.11.2 接続検証」を参照してください。

- 139 -

3. 大でも削除予定数だけの接続を削除

以下の条件を満たす場合、使用されていない接続を検索し、[削除予定数]を大としてプールから削除します。

条件を満たさない場合は削除されません。

0 < [削除予定数] <= [削除許容数]

4. プールサイズの修正

1.～3.の処理の結果、以下を満たした場合は、[初期および小プールサイズ]に達するまで接続を作成します。

[プール内の接続数] < [初期および小プールサイズ]

接続要求に応じたプールサイズのスケールアップ

アプリケーションからの接続要求の処理時、プール内の使用されていない接続の中で以下の2つの条件を満たす接続が

存在しない場合、プールサイズ変更量を超えない範囲でサイズをスケールアップさせます。

・接続のマッチングに成功

・接続検証に成功

スケールアップ時のプール内の動作は、以下です。次の2つの定義を説明の中で使用します。

[プール内の接続数] = [使用されていない接続数] + [使用中の接続数][生成許容数] = [ 大プールサイズ] - [プール内の接続数]

条件プール内の動作

[初期および小プールサイズ]未満 (注1) [初期および小プールサイ

ズ]へ達するまで接続を生成し

ます。

[初期および小プールサイ

ズ]以上、[ 大プールサイズ]未満


成可能な場合

[プールサイズ変更量]だけ接

続を生成します。


成すると、[ 大プールサイズ]を超えてしまう場合

[生成許容数]だけ接続を生成

します。

[ 大プールサイズ]と一致接続は生成されません。(注2)

注1) 接続検証の失敗により、プール内の使用されていない接続がすべて削除された場合などに該当します。

注2) ただし、接続のマッチングに失敗した未使用の接続が存在する場合、大でプールサイズ変更量分だけ接続を再

作成します。

接続のマッチング

接続のマッチングとは、プール内の接続の認証情報が接続要求時の認証情報と一致しているかを検証する機能です。

接続のマッチングが成功、または失敗と判定される条件は以下です。また、接続要求時の認証情報の指定方法は、「JavaEE運用ガイド」－「リソースアクセス時の認証情報」を参照してください。

・マッチングに失敗：

javax.resource.spi.ManagedConnectionFactoryインタフェースのmatchManagedConnections()メソッドの返却値がnull、またはResourceExceptionが返却される場合

・マッチングに成功：

javax.resource.spi.ManagedConnectionFactoryインタフェースのmatchManagedConnections()メソッドの返却値が

ManagedConnectionオブジェクトの場合

5.12.2 接続検証

プールされた接続をアプリケーションに返却する前に、アプリケーションサーバは接続が有効か検証できます。この検証

によって、EISがネットワーク障害かEIS自身の障害により利用不可となった場合、その接続をプールから破棄し、再度

- 140 -

プールから接続を獲得して有効な接続を返却します。プールに有効な接続が存在しなかった場合、EISから新たな接続

を獲得するため、接続を再確立できます。

接続検証には、以下が設定できます。

・接続検証


接続検証の成功/失敗について

接続検証が有効の場合、以下の処理により判定します。

・検証成功

－ javax.resource.spi.ValidatingManagedConnectionFactoryインタフェースを実装していない時

－ ValidatingManagedConnectionFactoryインタフェースのgetInvalidConnections()メソッドの返却値がnull、サイズ0のSetオブジェクト、またはjavax.resource.ResourceExceptionを返却する時

・検証失敗

－ ValidatingManagedConnectionFactoryインタフェースのgetInvalidConnections()メソッドの返却値が0より大きなサ

イズのSetオブジェクトを返却する時

－接続検証の実行前に、すでに対象となる接続で障害が検出されているとき

接続検証の実行契機

A)プールの定期監視時の接続検証

アイドルタイムアウトの間隔で定期的に接続検証を実行します。接続検証に失敗した場合の動作は、「プールの定期

監視(プールサイズのスケールダウン)」を参照してください。

B)アプリケーションからの接続要求時の接続検証

プール内から取得した接続をアプリケーションへ返却する前に、接続検証を実行します。プールサイズのスケール

アップにより新規作成された接続のうちアプリケーションへ返却する接続に対しては、検証不要のため接続検証をス

キップします。また、プール初期化時に生成される接続は、プール内から取得した接続と見なし接続検証を実行しま

す。接続検証に失敗した場合は、「すべての障害で」が有効かどうかで動作が変わります。

－「すべての障害で」が有効の時:「すべての障害で」の処理で一時的にプール内の接続が0になるのを補うために新たな接続を生成します。もしこ

の時点で再確立の処理が完了し未使用な接続があれば、置き換えて(破棄して)要求元へ接続を返却します。

－「すべての障害で」が無効の時:検証失敗の接続を削除し、プールから次の接続を取り出して再度接続検証を実施します。プール内の使用され

ていない接続がすべて接続検証に失敗した場合の動作は、「接続要求に応じたプールサイズのスケールアップ」


接続障害と判断される条件

「すべての障害で」が有効の場合に接続障害と判断される条件は、以下です。

・ javax.resource.spi.ManagedConnectionインタフェースのcleanup()メソッドの実行時に例外が発生した場合

・ javax.resource.spi.ConnectionEventListenerインタフェースのconnectionErrorOccurred()メソッドをリソースアダプタか

ら呼び出した場合

javax.resource.spi.ConnectionEventListenerの実装は、アプリケーションサーバからjavax.resource.spi.ManagedConnectionのaddConnectionEventListener()メソッドが呼び出されたときに渡されます。「すべての障害で」を有効にする場合、EISと

の接続障害に対する通知処理を実装してください。

注意

・接続を再確立できなかった場合には、例外が返却されます。

- 141 -

・接続の検証には若干の性能オーバーヘッドが発生します。

5.12.3 トランザクション管理

コネクタ接続プールのトランザクション管理では、以下を設定できます。詳細は、「Java EE運用ガイド」－「アウトバウンド・

リソースアダプタのトランザクション制御」を参照してください。

・トランザクションサポート

5.12.4 シャットダウンタイムアウト

コネクタサービスで以下を設定できます。

・シャットダウンタイムアウト

リソースアダプタクラスを実装したアプリケーションを運用する場合、アプリケーションサーバーは、リソースアダプタの停

止処理であるendpointDeactivation()メソッドおよびstop()メソッドの完了を指定した時間だけ待ち合わせます。

指定した時間内に停止処理が完了しない場合、アプリケーションサーバーはその後のアプリケーションの非活性化処理

を継続します。endpointDeactivation()メソッドやstop()メソッドからの復帰が遅延する可能性のあるアプリケーションの運用

に有効です。

リソースアダプタの停止処理は、リソースアダプタ単位に生成される停止用スレッドにより並列に処理されます。シャットダ

ウンタイムアウトは、Interstage Java EE DASサービスやIJServerクラスタの単位に設定でき、設定したターゲットに配備さ

れた全リソースアダプタに対して適用されます。

以下の方法で設定してください。

1. ツリービューから「設定」を選択し、設定名をクリックします。

2. 「コネクタサービス」を選択します。

3. シャットダウンタイムアウト(秒)を入力し「保存」をクリックします。

4. IJServerクラスタ、またはInterstage Java EE DASサービスを再起動します。

同様の操作は、asadminコマンドのsetサブコマンドからも行うことができます。詳細は、「リファレンスマニュアル(コマンド

編)」－「configsの定義項目」を参照してください。

注意

リソースアダプタの停止処理はendpointDeactivation()メソッド、stop()メソッドの順番に実行されます。endpointDeactivation()メソッドからの復帰がシャットダウンタイムアウトで指定した時間以内に完了せず、エンドポイントの回収処理がstop()メソッ

ドの呼び出し直前に未完了だった場合、再度endpointDeactivation()メソッドを呼び出してからstop()を呼び出します。

5.13 トランザクションサービスのチューニング

トランザクションサービスのチューニングについて、以下に説明します。

各定義項目の詳細は、「Java EE運用ガイド」－「トランザクションサービスの定義項目」を参照してください。

トランザクションサービスの時間監視機能の設定値について

トランザクションサービスの時間監視機能には以下の3種類の機能があります。

機能名説明

トランザクションタイムアウトトランザクションが完了するまでの時間を監視します。

再試行タイムアウトグローバルトランザクション使用時に使用できます。

トランザクションが複数のサーバにわたっている場合、

トランザクション情報の問い合わせに失敗したサーバ

に対して再接続を試みる時間を設定します。

- 142 -

機能名説明

XAResourceに設定するトランザクションタイ

ムアウト

グローバルトランザクション使用時に使用できます。

グローバルトランザクションで利用するXAResourceに対してsetTransactionTimeoutメソッドを使用してタイム

アウト値を設定します。

上記の監視機能を併用する場合、時間の設定は以下のように設定してください。

・ T(x)＞T(t)＞T(r)T(x)：XAResourceに設定するトランザクションタイムアウト

T(t)：トランザクションタイムアウト

T(r)：再試行タイムアウト

キーポイント処理

キーポイント処理とは、トランザクションログファイルを圧縮する処理のことです。トランザクションサービスの定義でキーポ

イント処理を実行するトランザクション数の間隔を指定できます。

キーポイント処理の実行頻度の大小は、トランザクションのログファイルサイズとパフォーマンスに対して以下のように影

響します。設定値のキーポイント処理への影響度合いは、トランザクションの処理内容に依存します。

・大きくした場合

－ログファイルサイズ：大きくなる

－パフォーマンス：向上する

・小さくした合

－ログファイルサイズ：小さくなる

－パフォーマンス：劣化する

ログファイルサイズは以下の式で見積もりできます。

・キーポイント間隔の設定値 × 0.0005Mバイト＋ 0.15Mバイト

5.14 ORBのチューニング

ORBのチューニングについて説明します。

5.14.1 ORBJava EEは、異なるマシンに配置されているオブジェクトや別プロセスのオブジェクト間でリクエストを呼び出す場合、ORBを介してIIOP通信できます。

ORBの設定について以下に説明します。

IJServerクラスタの場合、以下に示すORBの設定項目を変更できます。

ORB設定デフォルト値意味効果

総接続数 1024 IIOP通信の大同時接続数を指定

します。 (注1)(注2)総接続数を超えて同時に通信する

ことはできません。 (注3)

大同時接続数を指定することに

よって、コネクション接続で使用する

メモリやリソースを制御します。

大メッセージ分

割サイズ

（byte単位）

1024 IIOPメッセージの大フラグメントサ

イズを設定します。 (注4)(注5) (注6)(注7)

IIOPメッセージのエンコード処理を

大フラグメントサイズで行います。

全データをまとめてエンコードするの

に比べて使用するJavaヒープ領域を

圧縮できます。

- 143 -

アプリケーションクライアントコンテナまたはスタンドアロンクライアントの場合、以下に示すORBの設定項目を変更できま

す。

ORB設定デフォルト値意味効果

大メッセージ分

割サイズ

（byte単位）

4096 IIOPメッセージの大フラグメントサ

イズを設定します。(注4)(注5)(注6)(注7)

IIOPメッセージのエンコード処理を

大フラグメントサイズで行います。

全データをまとめてエンコードするの

に比べて使用するJavaヒープ領域を

圧縮できます。

注1) 100未満の値を設定しても、接続数が100以上にならないと接続の回収は行われません。

注2) 確立済みの接続が存在する場合、その接続を使用して通信します。例えばあるプロセスがマルチスレッドでリクエス

トを呼び出した場合、呼出し先が単一プロセスならば接続は1つだけ使用されます。

注3) 接続数がこの値を超えるとアイドル状態の接続の回収(コネクション切断)が行われます。使用中の接続数が総接続

数まで到達している状態で、新規接続を行おうとすると、新規接続のコネクション自身が回収されます。

注4) 大メッセージ分割サイズはデータ送信時の設定であり、クライアントからのリクエスト送信時と、サーバーからのリ

プライ送信時に有効な機能になります。

例えば、エンコードされた通信データが70000byteで、大メッセージ分割サイズが30000byteの場合、図のように分割し

て、IIOP通信が開始されます。

送信された通信データは、受信側の受信バッファに格納された後、先頭データから順に業務データにデコードされ、ユー

ザアプリケーションに渡されます。

- 144 -

注5) 1024byteより小さな値は設定しないでください。大メッセージ分割サイズが1024byteより小さい場合、想定される

大クライアント多重度の２倍のスレッドが必要になります。このため、サーバー側で必要なスレッド数が見積もり数を超過

してしまう可能性があります。

なお、スレッド数の見積もりについては、「5.8.1 スレッドプーリング」を参照してください。

注6) 256000以上の値を設定する場合、接続先の大受信バッファサイズを本設定値より大きい値とする必要がありま

す。大受信バッファサイズについては、「5.14.2 通信データサイズに関する注意事項」を参照してください。

注7) 設定値は、Java VM上でのヒープ使用量に影響します。

大メッセージ分割サイズにより、IIOP通信時に獲得するバッファ領域のサイズが変動しますので、大メッセージ分割

サイズを変更する際は、実際に送受信される業務データとは別に、大メッセージ分割サイズの設定によるヒープ使用

量を考慮して、Java VMのヒープ領域サイズを見積もってください。

以下の計算式のうち、大きいほうの結果が必要なヒープ使用量になります。

・ IJServerクラスタ起動時に必要なヒープ使用量

IJServerクラスタを起動するためのIIOP通信では、以下のヒープ使用量が必要です。

IJServerクラスタ起動時のヒープ使用量＝大メッセージ分割サイズ×3

・アプリケーション実行時に必要なヒープ使用量

アプリケーションを実行するためのIIOP通信では、以下のヒープ使用量が必要です。

クライアント側で必要なヒープ使用量＝（大メッセージ分割サイズ＋大受信バッファサイズ）× 大同時リクエス

ト送信数

サーバー側で必要なヒープ使用量＝（大メッセージ分割サイズ＋大受信バッファサイズ）×想定される大クラ

イアント同時接続数

大同時リクエスト送信数：クライアントプロセスの同時実行スレッド数に相当します。

想定される大クライアント同時接続数：デフォルトスレッドプールの大プールサイズに相当します。

ORB設定は、以下の方法で設定します。

- 145 -

総接続数

Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更・参照できます。詳細については、以下のマ

ニュアルを参照してください。


・リファレンスマニュアル（コマンド編）の「configs.config.iiop-serviceの定義項目」のorb.max-connections(総接続数)

設定変更時は、IJServerクラスタを再起動する必要があります。

大メッセージ分割サイズ


Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更・参照できます。詳細については、以下の

マニュアルを参照してください。


－リファレンスマニュアル（コマンド編）「configs.config.iiop-serviceの定義項目」の orb.message-fragment-size( 大

メッセージ分割サイズ)


・アプリケーションクライアントコンテナに設定する場合

環境変数VMARGSに以下の値を設定します。

-Dcom.sun.corba.ee.giop.ORBFragmentSize=設定値

詳細については、以下のマニュアルを参照してください。

－「Java EE運用ガイド」－「Java EEアプリケーションクライアントの環境設定」

・スタンドアロンクライアントの場合

Java VMオプションに以下の値を設定します。

-Dcom.sun.corba.ee.giop.ORBFragmentSize=設定値

5.14.2 通信データサイズに関する注意事項

最大受信バッファサイズの拡張について

大メッセージ分割サイズの拡張や、非フラグメントモード使用時、接続先の送信データサイズが256000byteを超える場

合がないか確認してください。

接続先の送信データサイズが256000byteを超える場合、大受信バッファサイズを拡張する必要があります。

大受信バッファサイズの設定は、Java VMオプションで指定します。

大受信バッファサイズはデータ受信時の設定であり、クライアントからのリクエスト受信時と、サーバーからのリプライ受

信時に有効な機能になります。

プロパティ名

com.sun.corba.ee.transport.ORBMaximumReadByteBufferSize

設定値

byte

値の範囲

256000～2147483647

デフォルト値

256000

- 146 -

設定方法

－スタンドアロンクライアントの場合

Java VMオプションに設定します。

-Dcom.sun.corba.ee.transport.ORBMaximumReadByteBufferSize=設定値

－アプリケーションクライアントコンテナに設定する場合

環境変数VMARGSに設定します。


- 「Java EE運用ガイド」－「Java EEアプリケーションクライアントの環境設定」

－ IJServerクラスタに設定する場合

Interstage Java EE管理コンソール、またはasadminコマンドを使用してJava VMオプションに設定します。

-Dcom.sun.corba.ee.transport.ORBMaximumReadByteBufferSize=設定値



- リファレンスマニュアル（コマンド編）の「configs.config.java-configの定義項目」のjava-config.jvm-options（JVMオプション）


接続先から受信したデータは、受信バッファに格納されます。受信バッファのサイズは、受信するデータサイズにより、初

期値64000byteから、大受信バッファサイズの設定値まで、2倍ずつ（64000→128000→256000)拡張されます。

受信するデータサイズが、大受信バッファサイズを超過した場合、データ受信処理は失敗し、以下の警告メッセージ

が通知されます。

・ IOP00410233

本警告メッセージが通知された場合は、接続先の送信データサイズが大受信バッファサイズより小さくなるようにチュー

ニングしてください。

Windows Server(R) 2008/Windows Server(R) 2008 R2における処理遅延について

オペレーションシステムの仕様(KB2020447)により、以下の条件でデータ送受信中に5秒間の処理遅延が発生する場合

があります。

・ Java EEのクライアントとサーバを同一マシンで運用する。

・ 65536バイトから1048576バイトの通信データを一度に送受信する。

本現象を回避するためには、以下のどちらかの対処を行ってください。

・大メッセージ分割サイズを65536バイト未満に設定する。

・ユーザーアプリケーションで一度に送受信する通信データサイズを以下の範囲で調整する。

－ 65536バイト未満

－ 1048577バイト以上

5.15 予兆監視機能から警告が通知された場合の対処

予兆監視機能が提供する警告メッセージ(ISJEE_OM3204)には、以下の2つの種類があります。事象の種類は、警告メッ

セージの可変情報である詳細メッセージで通知します。

・予兆監視警告メッセージ(Javaヒープ)Java VMのメモリ割当てプール(注)およびPermanent世代領域を監視して、Javaヒープ不足の危険性を警告メッセー

ジで通知します。

- 147 -

・予兆監視警告メッセージ(ガーベジコレクション)Java VMのガーベジコレクション処理の影響で業務レスポンス低下が発生する可能性を検出し、警告メッセージで通

知します。

注) Javaヒープは、メモリ割当てプール(New世代領域とOld世代領域)およびPerm世代領域に大別されます。以下の説

明で、単に「Javaヒープ」と記載している場合は、メモリ割当てプールを指します。Javaヒープの構造については、「チュー

ニングガイド」の「JDK/JREのチューニング」の「基礎知識」を参照してください。

なお、警告メッセージに含まれる詳細メッセージが同一の場合、同一Java VMプロセス上で同じ詳細メッセージの予兆が

検出されても、前回の出力から10分間抑止します。これは同一原因のメッセージの出力過多を防ぐためです。

また、何らかの要因でJavaアプリケーションの実行環境が変わった場合には、たとえ実行するJavaアプリケーション自体

に変更がない場合であっても、Javaアプリケーション実行時におけるオブジェクトの使われ方(オブジェクトの生成や不要

となるタイミングなど)が変化し、それに伴ってガーベジコレクション処理の発生状況も変化する場合があります。

その結果、従来環境では出力されなかった本メッセージが、変更後の実行環境では出力されるようになることがありま

す。

そのためJavaアプリケーションを変更しない場合であっても、以下の例のような要因でJavaアプリケーションの実行環境を

変更した場合には、Javaヒープに関する指定を、再度、チューニングする必要があります。

例

・アプリケーションサーバーのバージョンを変更した場合

・ JDK/JREのバージョンを変更した場合

・実行モードを32ビットから64ビットの環境へ変更した場合

・ハードウェアを変更した場合

・ OSを変更した場合

5.15.1 予兆監視警告メッセージ(Javaヒープ)Java VMのメモリ割当てプールおよびPermanent世代領域を監視して、Javaヒープ不足の危険性を警告メッセージ

(ISJEE_OM3204)で通知します。

JavaヒープおよびPermanent世代領域の問題を通知する警告メッセージには、3種類の詳細メッセージがあります。この他

の詳細メッセージは、「5.15.2 予兆監視警告メッセージ(ガーベジコレクション)」を参照してください。

詳細メッセージは、以下の発生条件で出力されます。

なお、詳細メッセージに含まれる時刻情報のフォーマットは「年/月/日時:分:秒.ミリ秒」となります。

詳細メッセージ警告の意味発生条件

There are possibilities ofOutOfMemoryError because ofthe lack of the memory:TIME={0} SIZE={1}TIME: 発生時刻

SIZE: Javaヒープ領域への追

加量の目安(バイト単位)(注)

Javaヒープ不足のため、

OutOfMemoryErrorが発生す

る危険性があります。

Full GC直後のJavaヒープ使用

率が95%より大きい場合。

または、Full GC直後のJavaヒープ使用率が90%より大きく、

かつ、前回のFull GC発生時よ

りJavaヒープ使用サイズが増加

している状態が3回以上続いた

場合。

There are possibilities ofOutOfMemoryError because ofthe lack of the Perm region:TIME={0} SIZE={1}TIME: 発生時刻

SIZE: Permanent世代領域へ

の追加量の目安(バイト単位)(注)

Permanent世代領域不足のた

め、OutOfMemoryErrorが発

生する危険性があります。

Permanent世代領域の使用量

が90%より大きい場合。

- 148 -


OutOfMemoryError warning isoccurred because the Permregion is exhausted: TIME={0}SIZE={1}TIME: 発生時刻

SIZE: Permanent世代領域の

増加量(バイト単位)

Permanent世代領域の使用量

が急増しているため、

OutOfMemoryErrorが発生す

る危険性があります。

前回の測定からのPermanent世代領域の使用量の増加が、

Permanent世代領域全体の１割

より大きく、かつ、次も同じ割合

で増えると仮定したときの

Permanent世代領域の使用率

が、90%より大きい場合。

なお「SIZE」として通知している

値は、同じ割合で増えると仮定

した際に用いた大きさ(増加量)です。

注) 警告を回避するためには、警告発生時のJavaヒープ領域またはPermanent世代領域のサイズを大きくする必要があり

ます。「SIZE」として通知している値は、そのための目安となる追加量です。

なお「SIZE」として通知している値は、あくまで目安です。実際に必要な追加量とは異なる場合がありますので、不足リ

ソースの情報を元に、きちんとチューニングを実施してください。

予兆監視警告メッセージ(Javaヒープ不足)の想定される原因と対処

Javaヒープ不足により警告メッセージが出力される原因は、Java VMによってあらかじめ予約されたJavaヒープまたは

Permanent世代領域の不足です。予約するJavaヒープサイズ、Permanent世代領域のサイズが不適切(小さすぎる、または

大きすぎる)な場合や、Javaアプリケーションがメモリリークを起こしている可能性があります。

警告メッセージが出力された場合、そのまま業務を継続するとメモリ不足やレスポンス低下などの問題が発生する可能性

があります。これらの問題を解決するために警告メッセージに記載されている不足リソースの情報やモニタロギング機能

を使用してチューニングを実施してください。

警告メッセージを回避するひとつの方法として、以下のようにJavaヒープまたはPermanent世代領域を増加する方法があ

ります。

1. 現在の不足リソースの上限値を20％増加させて運用を再開します。

2. それでも警告が出力された場合にはさらに20％増加させ、警告が出力されなくなるまで繰り返しチューニングを実

施します。

チューニングを繰り返して警告メッセージが出力されない状態とすることにより、安定稼動するシステムを構築できます。

JavaヒープサイズとPermanent世代領域サイズの上限値を増加しても回避できない場合は、Javaアプリケーションが大量

にメモリを消費していないか、メモリリークを起こしていないか見直しを行ってください。

Java VMのヒープ領域およびPerm領域をチューニングする場合、IJServerクラスタのJava VMオプションに、ヒープ領域お

よびPerm領域の上限値を設定するオプションを記載します。詳細は、「5.3.2 Java VMのヒープ領域サイズ/Perm領域サイ

ズ」を参照してください。

なお、チューニングは開発フェーズ(システムテスト)で実施し、問題を解決してください。

また、チューニング方法には、上記に挙げたヒープ領域またはPerm領域を増加する方法の他に、IJServerクラスタのサー

バーインスタンスを追加する方法もあります。

5.15.2 予兆監視警告メッセージ(ガーベジコレクション)Java VMのガーベジコレクション処理の影響で業務レスポンス低下が発生する可能性を検出し、警告メッセージ

(ISJEE_OM3204)で通知します。

Java VMのガーベジコレクションの影響を通知する警告メッセージには、5種類の詳細メッセージがあります。この他の詳

細メッセージは、「5.15.1 予兆監視警告メッセージ(Javaヒープ)」を参照してください。

・ガーベジコレクション処理時間に関する警告メッセージ(1種類)

・ガーベジコレクション間隔に関する警告メッセージ(4種類)

警告メッセージは、ガーベジコレクション処理による業務レスポンス低下の危険性を通知するもので、Java VMの動作異

常を示すものではありません。また、警告が出力された状態で業務を継続したときに、Javaアプリケーションの実行に支

- 149 -

障が発生すると一概に言えませんが、警告メッセージが出力されない状態にすることにより、安定稼動するシステムを構

築できます。

ガーベジコレクション処理時間に関する警告メッセージ

詳細メッセージは、以下の発生条件で出力されます。



It takes long time to do thegarbage collections manytimes: TIME={0}AVERAGE={1}TIME: 発生時刻

AVERAGE: 過去3回のFullGCの平均時間(ミリ秒単位)

Full GCに長い時間かかる状態

が続いています。

過去3回のFull GC時間の平均

値が5秒より長い場合。

ガーベジコレクション処理中は、メッセージに記載されたFull GCの平均時間の間、アプリケーションが停止する場合があ

ります。メッセージが出力された場合、レスポンス低下などの問題が発生する可能性があります。

予兆監視警告メッセージ(ガーベジコレクション処理時間)の原因と対処

ガーベジコレクション処理時間に関する警告メッセージが出力される原因は、以下が考えられます。

・物理メモリの枯渇など、システムのリソースが不足している。

・ CPU負荷の高い別のアプリケーションが同時に動作しているなど、メッセージの対象となったJavaプロセスの実行が

阻害されている。

・ Javaヒープのサイズ指定が大きすぎて、ガーベジコレクション処理に時間を要している。

アプリケーションのレスポンスに問題がある場合は、これらの要因を確認してください。

Javaヒープサイズの指定を小さくするチューニングは、十分な検証が必要です。JavaアプリケーションがJavaヒープを多く

消費するプログラムの場合、Javaヒープサイズの指定を小さくするとOufOfMemoryErrorが発生することも考えられます。

ガーベジコレクション間隔に関する警告メッセージ

詳細メッセージは、以下の発生条件で出力されます。いずれも、ガーベジコレクションが短い間隔で連続して発生した場

合に発生します。頻繁なガーベジコレクション処理の実行は、アプリケーションのレスポンス低下などの問題が発生する

可能性があります。


詳細メッセージ警告の意味発生条件 (注)

Inefficient garbage collectionsare run with the short intervals:TIME={0} WEIGHT={1}TIME: 発生時刻

WEIGHT: Full GC直前の旧世

代の使用率(%単位)

非効率なFull GCが短い間隔

で発生しています。

過去3回のFull GC間隔時間が

20秒より短い場合、かつ、FullGC直前のOld世代領域の使用

率が65%よりも小さい場合。

The garbage collections are runwith the short intervals becauseof the lack of the memory:TIME={0} SIZE={1}TIME: 発生時刻

SIZE: Javaヒープ領域への追

加量の目安(バイト単位)(注2)

Javaヒープ不足のため、FullGCが短い間隔で発生していま

す。


20秒より短い場合、かつ、FullGC直後のJavaヒープ使用率が

65%より大きい場合。

System.gc() are run with theshort intervals: TIME={0}INTERVAL={1}

java.lang.System.gc()メソッドや

java.lang.Runtime.gc()メソッド

が短い間隔で発生しています。


20秒より短い場合、かつ、

java.lang.System.gc()メソッドや

- 150 -

詳細メッセージ警告の意味発生条件 (注)

TIME: 発生時刻

INTERVAL:java.lang.System.gc()メソッドや


のインターバル時間(ミリ秒単

位)


によって発生したFull GCの頻

度が高い場合。

The garbage collections are runwith the short intervals:TIME={0} INTERVAL={1}TIME: 発生時刻

INTERVAL: Full GCのイン

ターバル時間(ミリ秒単位)

Full GCが短い間隔で発生して

います。


20秒より短い場合。

注1) 発生条件を満たした場合でも、ガーベジコレクションの処理時間が短い場合は、メッセージの出力を行わない場合

があります。

注2) 警告を回避するためには、警告発生時のJavaヒープ領域のサイズを大きくする必要があります。「SIZE」として通知

している値は、そのための目安となる追加量です。

なお「SIZE」として通知している値は、あくまで目安です。実際に必要な追加量とは異なる場合がありますので、不足リ

ソースの情報を元に、きちんとチューニングを実施してください。

予兆監視警告メッセージ(ガーベジコレクション間隔)の原因と対処

「Inefficient garbage collections are run with the short intervals」が出力された場合

Javaヒープの空きがあるにもかかわらず、ガーベジコレクション処理が発生している可能性があります。原因として以

下が考えられます。

－ Javaヒープの初期サイズ(-Xms)が小さく、Javaヒープ拡張を繰り返している。

－ JavaヒープのNew世代領域の割合が大きくなるように指定している(New世代領域については、「チューニングガ

イド」の「JDK/JREのチューニング」の「基礎知識」を参照してください)。

アプリケーションのレスポンスに問題がある場合は、Javaヒープに関するチューニングオプションに問題がないか確認


「The garbage collections are run with the short intervals because of the lack of the memory」が出力され

た場合

Javaヒープの不足が考えられます。「予兆監視警告メッセージ(Javaヒープ不足)の想定される原因と対処」を参照し

て、対処してください。Javaヒープサイズの上限値を増加しても警告が出力される場合、Javaアプリケーションが短時

間に大量のメモリを消費している可能性があります。

「System.gc() are run with the short intervals」が出力された場合

アプリケーションがjava.lang.System.gc()メソッド、java.lang.Runtime.gc()メソッドを短い間隔で呼び出しています。頻繁

なガーベジコレクション実行が、アプリケーションのレスポンスに影響している場合は、これらのメソッドの利用が必要

かアプリケーションの見直しを行ってください。

FJVMのjava.lang.System.gc()実行時におけるスタックトレース出力機能を利用すると、java.lang.System.gc()メソッド、

java.lang.Runtime.gc()メソッドの実行箇所を特定することができます。詳細は、以下のマニュアルを参照してください。

「チューニングガイド」> 「JDK/JREのチューニング」>「FJVM」>「java.lang.System.gc()実行時におけるスタックトレース

出力機能」

なお、JavaのRMI機能による自動ガーベジコレクション間隔が極端に短く設定されている場合、本メッセージが出力

されることがあります。アプリケーションでjava.lang.System.gc()メソッド、java.lang.Runtime.gc()メソッドを頻繁に実行し

ていない場合は、JavaのRMI機能による自動ガーベジコレクション間隔の設定値を確認してください。詳細は、「5.3.3ガーベジコレクション発生回数」を参照してください。

上記の3つのメッセージの発生条件以外で、ガーベジコレクション処理が短い間隔で発生した場合

「The garbage collections are run with the short intervals」のメッセージが出力されます。

- 151 -

5.16 Interstage Java EE DASサービスのヒープ領域サイズとアドレス空間

ヒープ領域サイズ

作成したIJServerクラスタ、サーバーインスタンスの数が多い場合や、配備済みアプリケーションの数が多い場合、メモリ

不足によりInterstage Java EE DASサービスの起動失敗やプロセスダウンが発生することがあります。

メモリ不足が発生している場合は、Interstage Java EE DASサービスのヒープ領域サイズをデフォルトの512MBから増や

してください。--targetオプションには server を指定します。

設定例

asadmin delete-jvm-options --target server \-Xmx512masadmin create-jvm-options --target server \-Xmx1024m

asadmin delete-jvm-options --target server \\-Xmx512masadmin create-jvm-options --target server \\-Xmx1024m

上記設定には、Interstage Java EE DASサービスが起動している必要があります。Interstage Java EE DASサービスが起

動できない場合は、「Interstage Java EE DASサービスが起動しない場合の対処方法」を参照してください。

アドレス空間

上記ヒープ領域サイズを増やしても起動に失敗する場合、Interstage Java EE DASサービスが、プロセスのアドレス空間

の上限を超えている可能性があります。

Interstage Java EE DASサービスが使用するプロセスのアドレス空間の領域は、以下の見積もり式で算出してください。

IJServerクラスタ数およびサーバーインスタンスの数を元に算出した値が、プロセスのアドレス空間の上限値を下回ること

を確認してください。もし上限値を超える場合は、上限値を超えない範囲にまでIJServerクラスタ数およびサーバーインス

タンスの削除を検討してください。

上限を超え、Interstage Java EE DASサービスが起動できない場合は、IJServerクラスタを削除してください。削除手順は

「IJServerクラスタを削除する方法」を参照してください。

[ 大ヒープ領域サイズ] ＋ [ 大Perm領域サイズ] ＋ [数値1] ＋ ( [IJServerクラスタ数] × 22 ＋ [サーバーインスタンス数] × 10 ＋ 82 ) × [数値2]

数値1、数値2

使用するプラットフォームにより異なります。数値1、数値2は下記表を参照してください。

項番プラットフォーム数値1 数値2

1 Windows(R) 300 Mバイト 0.25 Mバイト

2 Solaris 500 Mバイト 1.0 Mバイト

3 Linux 500 Mバイト 0.5 Mバイト

最大ヒープ領域サイズ、最大Perm領域サイズ

Interstage Java EE DASサービスの大ヒープ領域サイズ、大Perm領域サイズは、以下のコマンドで確認してくだ

さい。

asadmin get server.java-config.jvm-options

大ヒープ領域サイズ： -Xmx (デフォルトは512Mバイト)大Perm領域サイズ： -XX:MaxPermSize (デフォルトは192Mバイト)

- 152 -

Interstage Java EE DASサービスが起動しない場合の対処方法

IJServerクラスタの数が多く、Interstage Java EE DASサービスが起動しない場合は、下記手順に従いdomain.xmlを編集


domain.xmlの格納先



編集手順

1. Interstage Java EE Node Agentサービスを停止してください。

2. Interstage Java EE DASサービスを停止してください。通常停止を実施できない場合には、本手順実施後にシステ

ムを再起動してください。

3. domain.xmlを編集し、ヒープ領域サイズを増やしてください。

テキストエディタなどでファイルを開き、下記 -Xmx512m を -Xmx1024m に変更してください。

－編集する要素

<domain><configs><config dynamic-reconfiguration-enabled="true" name="server-config"><java-config><jvm-options>-Xmx512m</jvm-options>

4. Interstage Java EE DASサービスを起動してください。通常停止を行う際に失敗していた場合は、システムを再起動


5. Interstage Java EE Node Agentサービスを起動してください。

IJServerクラスタを削除する方法

上記の見積もり式に当てはめて削除する必要のあるIJServerクラスタ数を算出し、以下の手順でIJServerクラスタを削除し

てください。作業を行う前に、事前にIJServerクラスタの配備資源やdomain.xml、workers2.propertiesのバックアップをとる

ことを推奨します。バックアップの方法は、「運用ガイド(基本編)」－「資源のバックアップとリストア」を参照してください。

domain.xmlの格納先



workers2.propertiesの格納先

C:\Interstage\F3FMjs5\conf\jk2\[Webサーバ名]\workers2.properties

/opt/FJSVjs5/conf/jk2/[Webサーバ名]/workers2.properties

- 153 -

IJServerクラスタの削除手順

1. Interstage Java EE Node Agentサービスを停止してください。通常停止を実施できない場合には、プロセスを強制

停止してください。

2. Interstage Java EE DASサービスを停止してください。通常停止を実施できない場合には、プロセスを強制停止し

てください。

3. Webサーバを停止してください。 (注1)

4. Interstage管理コンソールを停止してください。 (注2)

5. domain.xmlを編集し、削除対象のIJServerクラスタに対応した以下の要素を削除してください。

－ config要素の削除

削除対象のIJServerクラスタに対応したconfig要素を削除してください。

<config dynamic-reconfiguration-enabled="true" name="${IJServerクラスタ名}-config">～

</config>

－ cluster要素の削除

削除対象のIJServerクラスタに対応したcluster要素を削除してください。

<cluster config-ref="${IJServerクラスタ名}-config"heartbeat-address="${ハートビートアドレス}"heartbeat-enabled="${ハートビート}"heartbeat-port="${ハートビートポート}" name="${IJServerクラスタ名}">～

</cluster>

－ server要素の削除

削除対象のIJServerクラスタに対応したserver要素を削除してください。

サーバーインスタンスが2つ以上のIJServerクラスタの場合、複数のserverタグを削除する必要があります。

<server config-ref="${IJServerクラスタ名}-config" lb-weight="100"name="${IJServerクラスタ名}-${シーケンス番号}" node-agent-ref="ijna"start-instance-in-startup="true">～

</server>

6. Webサーバコネクタの環境設定ファイルworkers2.propertiesを編集し、削除対象のIJServerクラスタに対応した以下

の定義が存在する場合は定義を削除します。workers2.propertiesはWebサーバごとに存在します。Webサーバが

複数存在する場合は、すべてのworkers2.propertiesを編集してください。

－ channel.socketセクションの削除

削除対象のIJServerクラスタのサーバーインスタンスに対応したchannel.socketセクションを削除します。

[channel.socket:${IJServerクラスタのIPアドレス}_${サーバーインスタンスのポート番号}]～

disabled=0

－ httpセクションの削除

削除対象のIJServerクラスタのサーバーインスタンスに対応したhttpセクションを削除します。

[http :${IJServerクラスタのIPアドレス}_${サーバーインスタンスのポート番号}]～

debug=0

－ lbセクションの削除

削除対象のIJServerクラスタに対応したlbセクションを削除します。

- 154 -

[lb: ${IJServerクラスタ名}]～

worker=http:${IJServerクラスタのIPアドレス}_${サーバーインスタンスのポート番号}～

createdby=javaee

－ uriセクションの削除

groupプロパティに削除対象のIJServerクラスタ名が設定されているuriセクションをすべて削除します。

[uri:/${コンテキストルート}/*]group=${IJServerクラスタ名}

7. Webサーバを起動してください。 (注1)

8. Interstage管理コンソールを起動してください。 (注2)

9. Interstage Java EE DASサービスを起動してください。

10. Interstage Java EE Node Agentサービスを起動してください。サービス起動時に、4.で削除したIJServerクラスタの定

義情報に対応する資源は自動的に削除されます。

注1) 詳細は、「Interstage HTTP Server 運用ガイド」を参照してください。

注2) 詳細は、「運用ガイド（基本編）」を参照してください。

5.17 時間監視機能の相関関係

アプリケーションからの要求でネットワーク通信が発生する以下の機能について応答時間に影響する時間監視機能と、

その各時間監視機能の相関関係を説明します。

応答時間に影響する時間監視機能以外の、不当に残存したオブジェクトを解放する無通信時間を監視する機能（コネク

ションプーリング機能など）については、各機能説明を参照してください。

・ HTTP通信

・ IIOP通信

・トランザクションとデータベースアクセス

時間監視機能により異常を検出するまでの時間をタイムアウト時間と呼び、タイムアウト時間を超過したことにより異常を

検知することをタイムアウトと呼びます。

タイムアウトによる異常を検出して呼び出し元で処理を中断するか再実行するかなどの判断を行うため、タイムアウト時間

は呼び出し元に近いほど大きな値に設定するのが一般的です。

相関関係の図において実線は処理の流れを表します、点線は時間監視機能の監視間隔を表します。

緑色の部分がアプリケーションの処理部分です。

- 155 -

HTTP通信

相関関係

※1 HTTPリスナー/Webコンテナに接続されてからリクエストの処理が開始するまでの待機時間です。詳細は以下を参照


・「5.6 Webコンテナのチューニング」

・「5.19.3 性能情報の分析」

時間監視項目監視対

象とな

る時間

時間監視機能説明

(a) Webサーバコネクタの送受信タイムアウト

<設定方法>以下の項目でタイムアウト時間を設定します。

「5.6 Webコンテナのチューニング」

・ Webサーバコネクタの送受信タイムアウト

その際、以下の関係を満たすように設定してくださ

い。

(a) ＞ (b) ＋ (c) ＋図中※1

WebサーバコネクタがHTTPリスナー/Webコンテナとの間でデータパケットを送受信

するときの待機時間を監視します。

注)本項目はWebサーバ(Webサーバコネク

タ)を使用する運用の場合のみWebサーバ

コネクタにより監視されます。

その際、Webサーバコネクタは相関関係

図の「クライアント」に相当します。

(b) HTTPリスナーのタイムアウト


・「Java EE運用ガイド」－「HTTPサービスの定義項

目」

－項目名：タイムアウト時間

HTTPリスナー/Webコンテナがクライアント

からのデータパケットを受信するときの待

機時間を監視します。

- 156 -

監視対

象とな

る時間

時間監視機能説明

－プロパティ名： connectionUploadTimeout

(c) アプリケーション大処理時間


・「Java EE運用ガイド」－「プロセス制御の定義項

目」

－項目名：アプリケーション大処理時間

ユーザアプリケーションの呼び出しからレ

スポンス送信までの処理時間を監視しま

す。

監視対象の時間にはリクエストのメッセー

ジボディの読み込み時間も含まれます。

ポイント

以下の現象が頻繁に発生する場合、対処方法を行うことで回避できる可能性があります。

回避できない場合は、サーバの処理能力を超えている可能性があります。

サーバの増設または、より性能の良いサーバへのリプレースを検討してください。

－現象：WebサーバコネクタのログにIJServer12035、IJServer12044が出力される

対処方法：(a)の設定値を大きくする

－現象：イベントログ/システムログにISJEE_OM1005、またはISJEE_OM1020が出力される

対処方法：(c)の設定値を大きくする

注意

以下の条件に該当する場合、プロセスが強制停止します。

－ (b) ＞ (c) に設定した、かつ

－プロセス制御の定義項目 [アプリケーション大処理時間超過時の制御]を"true"に設定した、かつ

－相関関係図における“リクエストのメッセージボディの送信”が(ｃ)の設定値を超えても完了しなかった場合

- 157 -

IIOP通信

相関関係

時間監視項目

時間監視間隔時間監視機能

(a) IIOP接続の待機時間監視機能

(b) IIOP通信ソケットの送受信待機時間監視機能

(c) IIOP通信時のサーバメソッド復帰時間監視機能

(d) アプリケーションの大処理時間監視機能

(e) IIOP通信クライアントの無通信監視機能

- 158 -

トランザクションとデータベースアクセス

相関関係

時間監視項目

時間監視間隔時間監視機能

(a) EJBコンテナのトランザクション完了時間監視機能

(b) トランザクションサービスのトランザクションタイムアウ

ト

(c) JDBC接続プールの大待ち時間

(d) JDBC接続プールの文のタイムアウト

5.18 モニタリング情報の監視

Interstage Java EE管理コンソールにて、運用中のサーバーインスタンスの稼動情報を参照できます。これにより、ボトル

ネックを検出したり、性能チューニングの効果を確認することができます。

稼働情報には、以下の情報が出力されます。各項目の意味については、項目と合わせて表示される説明を参照してく

ださい。

- 159 -

表示項目説明

ランタイム Java VMの情報などプロセスの情報が表示されます。

アプリケーションサーバーインスタンスに配備された各アプリケーショ

ンの情報が表示されます。

リソースサーバーインスタンスに有効になっている各リソース

の情報が表示されます。

トランザクションサーバーインスタンスで動作している各トランザクショ

ンの情報が表示されます。

監視を有効にするには、監視サービスの設定で各項目に対して「LOW」もしくは「HIGH」を設定します。

Java VMの情報として表示されるUpTime（開始時間）とHeapSize（ヒープサイズ）の情報はデフォルトで表示されます。

「LOW」より「HIGH」を指定することで多くの情報を表示することができますが、表示項目が多いと若干の性能影響があり

ます。このため、必要な監視情報のみ有効にしてください。

モニタロギング機能を使用することで、表示される情報をログに出力することもできます。モニタロギング機能について

は、「5.19 モニタロギング」を参照してください。

5.18.1 注意事項

JDBCリソース/JMS/コネクタリソースの監視情報について

JDBCリソース/JMS/コネクタリソースの監視情報は、サーバーインスタンス上で各リソースのConnectionFactoryに対してコ

ネクションの獲得要求を実行した時の情報が反映されます。このため、以下の情報は反映されません。

・ Message-driven Beanのメッセージ受信で使用するコネクション

Message-driven Beanのメッセージ受信で使用するコネクションの情報は、JMS/コネクタリソースの監視情報に反映さ

れません。Message-driven Beanでは、Message-driven Beanの起動時にメッセージブローカへのコネクションが1つ生

成され、このコネクションが使用されます。 JMS/コネクタリソースの監視情報でコネクション数を確認する場合には、表示される情報以外に運用中のMessage-driven Beanの数分のコネクションが使用されていると判断してください。

・クライアントアプリケーションで使用するコネクションクライアントアプリケーション（Java EEアプリケーションクライアントなど）で使用するコネクションの情報はサーバーイ

ンスタンスの監視情報には反映されません。

5.19 モニタロギング

IJServerクラスタの性能情報をロギングする機能が提供されています。この機能を利用することで、JavaVMやJDBCデー

タソースなどの性能情報を定期的に採取し、結果をログファイルへ出力することができます。ログファイルはCSV形式の

ファイルに出力されるため、容易にExcelなどで読み込んで性能情報を分析することができ、統計情報の蓄積にも役立ち

ます。

IJServerクラスタのモニタロギングは以下の図に示すようにasadminコマンドを使用します。

asadminコマンドのsetサブコマンド、またはInterstage Java EE管理コンソールによりIJServerクラスタのモニタロギングを有

効に設定すると、Interstage Java EE DASサービスを経由してIJServerクラスタの各サーバーインスタンスへ定義変更イベ

ントが通知されます。

サーバーインスタンスのプロセスでは、指定された時間間隔で性能情報をCSV形式のファイルに出力します。

なお、モニタロギングが無効に設定された場合、以降の性能情報の出力は行われません。

- 160 -

設計方法

IJServerクラスタ運用中に継続してモニタロギング機能を使用してログを採取することにより、業務運用中の性能情報の

記録が残るため、問題発生時の原因究明が確実かつ簡単になります。

しかし、ログ採取タイミングではログ情報をファイルに出力するためにJava VMのヒープメモリ使用量やCPU使用率が若

干増加します。このため、大量の情報を頻繁にログファイルに出力すると性能に影響が発生する可能性があります。テス

ト運用中にモニタロギング機能を評価し、運用に影響がないログ採取間隔で採取してください。

5.19.1 モニタロギングの操作手順

ここでは、モニタロギングの以下運用操作について説明します。

・モニタロギングの開始操作

・モニタロギングの終了操作

・監視操作(特定時刻のログだけ採取する場合)

・監視操作(継続的にログを採取する場合)

モニタロギングの開始操作

モニタロギングを開始するには、監視したい項目に応じて「監視サービス」の監視レベルを変更し、モニタロギングを有効

に設定します。

1. 監視レベルの変更

IJServerクラスタ起動前に、asadmin コマンドのsetサブコマンドを利用して、IJServerクラスタの「監視サービス」の定

義項目のうち、監視したい性能情報の監視レベルを「LOW」または「HIGH」に設定します。

例えば、Java VMの性能情報を監視したい場合は、以下のように操作します。

asadmin set IJServer001.monitoring-service.module-monitoring-levels.jvm=LOW

2. モニタロギングの有効化

asadminコマンドを利用し、IJServerクラスタのモニタロギングを有効に設定します。

asadmin set IJServer001.monitoring-service.logging-enabled=true

- 161 -

ポイント

・モニタロギングによる性能情報の出力は、対象のIJServerクラスタの運用中にのみ行われます。

・ IJServerクラスタの運用中に設定変更した場合は、設定値はすぐに反映され、指定された採取間隔経過後に性能情

報がログファイルに出力されます。

モニタロギングの終了操作

asadminコマンドを利用し、モニタロギングを無効に設定します。

asadmin set IJServer001.monitoring-service.logging-enabled=false

注意

モニタロギングの終了操作では、監視レベルの変更は不要です。「LOW」または「HIGH」に設定した性能情報を監視す

る必要がなくなった場合、監視レベルを「OFF」にしてください。

監視操作(特定時刻のログだけ採取する場合)

トラブル調査などのため、ある特定の時間だけ性能情報を採取したい場合は、以下のようにIJServerクラスタの起動後に

モニタロギングを開始します。

1. IJServerクラスタの起動

Interstage Java EE管理コンソール、またはasadminコマンドのstart-clusterサブコマンドでIJServerクラスタを起動しま

す。

2. 監視レベルの変更

Interstage Java EE管理コンソール、またはasadminコマンドのsetサブコマンドで監視レベルを変更します。

3. モニタロギングの開始

Interstage Java EE管理コンソール、またはasadminコマンドのsetサブコマンドでモニタロギングを有効に設定しま

す。

4. 性能情報の分析

出力された情報をMicrosoft(R) Excelなどで分析します。

5. モニタロギングの終了

Interstage Java EE管理コンソール、またはasadminコマンドのsetサブコマンドでモニタロギングを無効に設定しま

す。

6. 3.～5.を繰り返します。

7. IJServerクラスタの停止

Interstage Java EE管理コンソール、またはasadminコマンドのstop-clusterサブコマンドでIJServerクラスタを停止しま

す。

監視操作(継続的にログを採取する場合)

継続的にログを採取して性能チューニングの妥当性を検証したい場合は、以下のようにモニタロギングを有効に設定し

た後にIJServerを起動してください。

1. モニタロギングの設定変更

Interstage Java EE管理コンソール、またはasadminコマンドのsetサブコマンドで監視レベルを変更し、モニタロギン

グを有効に設定します。

2. IJServerクラスタの起動

Interstage Java EE管理コンソール、またはasadminコマンドのstart-clusterサブコマンドでIJServerクラスタを起動しま

す。

- 162 -

3. 性能情報の分析

出力された情報をMicrosoft(R) Excelなどで分析します。

4. IJServerクラスタの停止

Interstage Java EE管理コンソール、またはasadminコマンドのstop-clusterサブコマンドでIJServerクラスタを停止しま

す。

5. 2.～4.を繰り返します。

注意

Interstage Java EE DASサービスのメモリについて

モニタロギングを利用するために、IJServerクラスタやInterstage Java EE DASサービスの監視サービスの定義を有効にす

ると、サーバーインスタンス数、配備済みのアプリケーション数に応じてInterstage Java EE DASサービスのメモリが使用さ

れます。

監視サービスを有効に設定した場合は、Interstage Java EE DASサービスでメモリ不足が発生していないことを確認して

ください。メモリ不足が発生した場合は、「5.16 Interstage Java EE DASサービスのヒープ領域サイズとアドレス空間」を参

照して対処を行ってください。

5.19.2 モニタロギングのログファイル

モニタロギングのログファイルについて、以下を説明します。

・ログファイル名

・ローテーション後のファイル名

・ログファイルのライフサイクル

・ファイルのアクセス権

・出力ディレクトリ

ログファイル名

モニタ情報を出力するログファイルは、プロセスごと、かつ、採取対象ごとに出力されます。ログファイルのファイル名は以

下の命名規則で出力されます。

命名規則：monitor-[採取対象名].log

ファイル名一覧を以下に記載します。

ファイルファイル名

Java VM情報ログファイル monitor-jvm.log

HTTP接続キュー情報ログファイル monitor-connectionqueue.log

HTTPリスナー情報ログファイル monitor-httplistener.log

IIOPコネクション情報ログファイル monitor-connection.log

スレッドプール情報ログファイル monitor-threadpool.log

Stateless Session Bean情報ログファイル monitor-statelesssession.log

Stateful Session Bean情報ログファイル monitor-statefulsession.log

Message-driven Bean情報ログファイル monitor-messagedriven.log

Entity Bean情報ログファイル monitor-entitybean.log

JDBC接続プール情報ログファイル monitor-jdbcpool.log

- 163 -

ファイルファイル名

トランザクション情報ログファイル monitor-transaction.log

JMS/コネクタ接続プール情報ログファイル monitor-connectorpool.log

ローテーション後のファイル名

出力されたログファイルは一定間隔でローテーションされます。ローテーション後のログファイルは、以下のようにローテー

ションした日時情報を付加してバックアップされます。ログファイル名の末尾に、日時を示す文字列が追加されます。ま

た、ログファイル名と日時文字列の間はハイフン（「_」）で区切られます。

ファイル名：monitor-[採取対象名].log_yyyy_MM_dd-hh_mm_ss

日時情報について以下に説明します。

YYYY 年を4桁の数字(0000～9999)で表示します。

MM 月を2桁の数字(01～12)で表示します。

DD 日を2桁の数字(01～31)で表示します。

hh 時を2桁の数字(00～23)で表示します。

mm 分を2桁の数字(00～59)で表示します。

ss 秒を2桁の数字(00～59)で表示します。

例

monitor-jvm.log_2006_06_24-01_00_00

ログファイルのライフサイクル

ログファイルのライフサイクルについて説明します。

IJServerクラスタプロセスがログを出力する場合、ログ出力ディレクトリに「ログファイル名」で説明しているファイルが存在

しなければファイルを新規に作成します。また、ログファイルは以下の条件の場合にローテーションされます。ローテー

ションのタイプ、開始時刻、サイズは、モニタロギングを開始する前に定義項目として設定できます。詳細は、「リファレン

スマニュアル(コマンド編)」－「Java EE運用コマンド」の「asadmin」を参照してください。

ローテーション条件

－ローテーションのタイプが「サイズ」の場合

- ログファイルのサイズがローテーションサイズに達する場合

－ローテーションのタイプが「時刻」の場合

- ローテーション時刻にIJServerクラスタプロセスが起動している場合

- ログが採取されるタイミングで、以前のログファイルがログ出力ディレクトリに残存しており、かつ、そのファイル

の更新日時が前回のローテーション日時より前の場合

ローテーションは以下のように行われます。

1. 既存のログファイルを「ローテーション後のファイル名」で説明している名前に変名してバックアップします。

2. 新規に「ログファイル名」で説明している名前の新規ファイルを作成します。

3. バックアップされているファイルのファイル数がログファイルの世代数以上となっている場合、ファイルの更新日時

が古いファイルを削除します。バックアップされたファイルのファイル数が世代数となるまで削除します。

- 164 -

ファイルのアクセス権

出力されるファイルの所有者はIJServerクラスタの起動ユーザとなり、ファイルの権限は「644」となります。

出力ディレクトリ

モニタロギングのログファイルは、IJServerクラスタのログ出力ディレクトリに出力されます。

IJServerクラスタのログ出力ディレクトリについては、「Java EE運用ガイド」－「IJServerクラスタのファイル構成」を参照して

ください。

5.19.3 性能情報の分析

ログファイルに採取した性能情報の分析方法について説明します。

出力情報

モニタ情報ログファイルは、以下のようにCSV形式(カンマ区切りで並べた形式)で出力されます。

D1,D2,D3,D4,D5,・・・

性能情報の項目内容

IJServerクラスタで使用できるモニタロギングでは、IJServerクラスタ起動時からのデータが出力されます。

性能情報中の日時情報は、以下の値が「DD/MM/YYYY hh:mm:ss.SSS」のフォーマットで出力されます。

DD 日を2桁の数字(01～31)で表示します。

MM 月を2桁の数字(01～12)で表示します。

YYYY 年を4桁の数字(0000～9999)で表示します。

hh 時を2桁の数字(00～23)で表示します。



SSS ミリ秒を3桁の数字(000～999)で表示します。

例

24/06/2006 01:00:00.200

性能情報中の「ミリ秒」単位は、以下の値が「h:mm:ss.SSS」のフォーマットで出力されます。

h 時を可変桁の数字(0～)で表示します。値が0の場合は「0」と表示します。



SSS ミリ秒を3桁の数字(000～999)で表示します。

例

0:00:00.200

性能情報として出力される項目について説明します。各表の項番に書かれているD1、D2、・・・は、CSV形式で出力され

るD1、D2、・・・に対応しています。

なお、先頭の出力項目は、必ず当該レコードの性能情報を採取した日時となります。

- 165 -

性能情報を出力するには、asadminコマンドのsetサブコマンドでconfigs.config.monitoring-serviceの定義項目に、出力す

る情報の監視レベルを指定する必要があります。各表の監視レベルは、指定した監視レベルによって出力される情報で

す。監視レベルがHIGHの項目(薄い緑色の行)は、指定された監視レベルがHIGHの場合だけ出力される項目です。そ

れ以外は指定された監視レベルにかかわらず出力される項目です。

性能情報一覧

1) Java VM情報

2) HTTP接続キュー情報

3) HTTPリスナー情報

4) IIOPコネクション情報

5) スレッドプール情報

6) Stateless Session Bean情報

7) Stateful Session Bean情報

8) Message-driven Bean情報

9) Entity Bean情報

10) JDBC接続プール情報

11) トランザクション情報

12) JMS/コネクタ接続プール情報

性能情報の説明

1) Java VM情報

アプリケーションを運用しているJava VMの性能情報です。

項番項目の内容採取条件

D1 当該レコードの性能情報を採取した日時

D2 インスタンス名

D3 プロセスID

D4 Java VM起動時間(単位:ミリ秒)

D5 Java VMヒープサイズの下限値(単位:バイト)

D6 Java VMヒープサイズの上限値(単位:バイト) (注)

D7 Java VMヒープサイズの小値(単位:バイト)

D8 Java VMヒープサイズの大値(単位:バイト) (注)

D9 Java VMヒープサイズの現在値(単位:バイト)

D10 Perm領域の上限値(単位:バイト)

D11 Perm領域の小使用量(単位:バイト)

D12 Perm領域の大使用量(単位:バイト)

D13 Perm領域の現在使用量(単位:バイト)

D14 ガーベジコレクション発生回数

D15ガーベジコレクション処理トータル時間(単位: ミリ

秒)

注)：Java VMヒープサイズの上限値は動的に増減するため、Java VMヒープサイズの上限値をJava VMヒープサイズの

大値が上回る場合があります。

- 166 -

2) HTTP接続キュー情報

HTTPの接続キューの性能情報です。




D3 プロセスID

D4 キューがいっぱいになったためにHTTPリクエスト

を格納できなかった回数

D5 キュー内に現在存在しているHTTPリクエストの数

D6 キュー内HTTPリクエスト数の過去15分間におけ

る平均値

D7 キュー内HTTPリクエスト数の過去1分間における

平均値

D8 キュー内HTTPリクエスト数の過去5分間における

平均値

D9 受け付けられたHTTPリクエストの合計数

D10 キューに格納されたHTTPリクエストの合計数

1つのHTTPリクエストがキュー内に複数回格納さ

れる可能性があります。そのため、D9の「受け付

けられたHTTPリクエストの合計数」より値が大きく

なる場合があります。

D11 キューのID

D12 キューの大サイズ

D13 キュー内に同時に存在していたHTTPリクエストの

大数

3) HTTPリスナー情報

HTTPリスナーの性能情報です。




D3 プロセスID

D4 各要求プロセッサが受信したバイトの累計値(単位:バイト)

D5 各要求プロセッサが送信したバイトの累計値(単位:バイト)

D6 使用しません







- 167 -







D18 現在HTTPリスナーが受け付けているHTTPリクエ

ストの数

この情報が利用不可能な場合は0。

D19 その他の応答コードを含む応答の合計数

D20 HTTPリスナー内に現在存在している要求処理ス

レッドの数

D21 現在使用されている要求処理スレッドの数

D22 エラー回数の累計値

応答コードが400以上になった場合の回数を表し

ます。

D23 HTTPリスナーが同時に受け付けることの出来る

HTTPリクエストの大数

この情報が利用不可能な場合は0。

D24 存在可能な未使用要求処理スレッドの大数

D25 リスナーが作成する要求処理スレッドの大数

D26 スレッド処理時間の大値(単位:ミリ秒)

D27 存在可能な未使用要求処理スレッドの小数

D28 各要求の処理に要した時間の累計値(単位:ミリ

秒)

D29 その時点までに処理された要求の合計数

要求処理スレッドの平均処理時間の求め方

D28(各要求の処理に要した時間の累計値) ÷ D29(その時点までに処理された要求の合計数)

4) IIOPコネクション情報

ORBへの接続の性能情報です。




D3 プロセスID

D4 ORBへの接続のうち、アイドル状態の接続の合

計数

D5 ORBへの接続のうち、使用中の接続の合計数

D6 ORBへの接続の下限数

D7 ORBへの接続の上限数

D8 ORBへの接続の小数

D9 ORBへの接続の大数

- 168 -


D10 ORBへの接続の合計数

5) スレッドプール情報

EJBコンテナのスレッドプール(※)に対する性能情報です。スレッドプールごとに情報を出力します。

スレッドプール追加時、モニタ情報を有効にするにはIJServerクラスタの再起動が必要です。

※：主にEJBコンテナがスレッド制御を行うアクセスパターンで呼出しが行われた場合に使用されます。

EJBコンテナのスレッドプールについての詳細については「5.8.1 スレッドプーリング」を参照してください。




D3 プロセスID

D4 スレッドプール名

D5 キュー内の要求が処理されるまで待っていた

小待ち時間(単位:ミリ秒)

D6 キュー内の要求が処理されるまで待っていた

大待ち時間(単位:ミリ秒)

D7 キュー内の要求が処理されるまでの平均待ち時

間(単位:ミリ秒)

D8 1つの作業の平均完了時間の短時間(単位:ミリ秒)

D9 1つの作業の平均完了時間の長時間(単位:ミリ秒)

D10 1つの作業の平均完了時間(単位:ミリ秒)

D11 要求処理スレッドの下限数

D12 要求処理スレッドの上限数

D13 要求処理スレッドの小数

D14 要求処理スレッドの大数

D15 要求処理スレッドの現在数

D16 利用可能なスレッドの数

D17 作業中状態のスレッドの数

D18 その時点までに作業キューに追加された作業項

目の合計数なお、1つの要求を実行するため

に、1つ以上の作業項目が作業キューに追加さ

れます。

D19 キュー内の作業項目の下限数

D20 キュー内の作業項目の上限数

D21 キュー内の作業項目の小数

D22 キュー内の作業項目の大数

D23 キュー内の作業項目の数

6) Stateless Session Bean情報

Stateless Session Beanの性能情報です。Beanごとに情報を出力します。

- 169 -

・指定したIJServerクラスタにユーザがStateless Session Beanを配備していない場合でも、システムが利用するアプリ

ケーションである「MEjbApp」の情報が出力されます。

・ HotDeployしたアプリケーションの情報は、次回の採取タイミングから反映されます。

・初期化に失敗したアプリケーションの情報は出力されません。




D3 プロセスID

D4 Application名 EARファイルパッケージで配備

した場合、拡張子を除くアプリ

ケーション名を出力します。

JARファイル単体で配備した場

合、拡張子を除くejb-jarファイル

名を出力します。

D5 EJBモジュール名 EARファイルパッケージで配備

した場合、拡張子を除くejb-jarファイル名を出力します

D6 Stateless Session Bean名

D7 プール内のインスタンスの小数

D8 プール内のインスタンスの大数

D9 プール内のインスタンスの現在数

D10 EJBのcreateメソッドが呼び出された回数

D11 EJBのremoveメソッドが呼び出された回数（注）

注）採取対象外です。

7) Stateful Session Bean情報

Stateful Session Beanの性能情報です。Beanごとに情報を出力します。

・指定したIJServerクラスタにStateful Session Beanがひとつも配備されていない場合は情報が出力されません。






D3 プロセスID









- 170 -


D6 Stateful Session Bean名

D7 Passivateされたインスタンス数の小値

D8 Passivateされたインスタンス数の大値

D9 Passivateされたインスタンス数

D10 キャッシュ内のアイドル状態となっているBeanイ

ンスタンスの小数


ンスタンスの大数


ンスタンスの現在数

D13 EJBのcreateメソッドが呼び出された回数

D14 EJBのremoveメソッドが呼び出された回数

8) Message-driven Bean情報

Message-driven Beanの性能情報です。Beanごとに情報を出力します。

・指定したIJServerクラスタにMessage-driven Beanがひとつも配備されていない場合は情報が出力されません。






D3 プロセスID









D6 Message-driven Bean名

D7 Message-driven Beanに対して受信されたメッ

セージ数

D8 Message-driven Beanのcreateメソッドが呼び出

された回数

D9 Message-driven Beanのremoveメソッドが呼び出

された回数

9) Entity Bean情報

Entity Beanの性能情報です。Beanごとに情報を出力します。

・指定したIJServerクラスタにEntity Beanがひとつも配備されていない場合は情報が出力されません。


- 171 -





D3 プロセスID









D6 Entity Bean名

D7 プール内のインスタンスの小数

D8 プール内のインスタンスの大数

D9 プール内のインスタンスの現在数


ンスタンスの小数


ンスタンスの大数


ンスタンスの現在数

注) 以下のシステムが利用するアプリケーションの性能情報が出力されます。

__ejb_container_timer_app

10) JDBC接続プール情報

JDBC接続プールの性能情報です。接続プールごとに情報を出力します。

指定したIJServerクラスタに関連付けられたJDBCリソースがひとつもない場合は情報が出力されません。なお、関連付け

を行った後は情報が出力されます。

プーリングが無効の場合には一部の情報が出力されません。この場合、"プーリングが無効の場合"の欄が「－」の項目

には必ず0が出力されます。

背景色が薄い緑色の行は、監視レベルがHIGHの項目です。

項番項目の内容プーリングが無

効の場合

採取条件

D1 当該レコードの性能情報を採取した日時 ○

D2 インスタンス名 ○

D3 プロセスID ○

D4 JDBC接続プール名 ○

D5 接続要求の平均待機時間(単位:ミリ秒)(注1)

○

D6 接続要求の短待機時間(単位:ミリ秒)(注1)

○

D7 接続要求の長待機時間(単位:ミリ秒)(注1)

○

- 172 -

項番項目の内容プーリングが無

効の場合

採取条件

D8 近受け付けた接続要求の待機時間(単位:ミリ秒) (注1)

○

D9 プールから獲得した論理接続数 (注1) ○

D10 作成された物理接続数 (注2) ○

D11 破棄された物理接続数 (注2) ○ ・プーリングが有効の場合、以下の時に物

理接続が破棄されます。

－アイドルタイムアウトにより接続が破

棄された時

－接続検証で失敗して接続が破棄され

た時。「すべての障害で」が有効の場

合には、接続検証で失敗した接続以

外も破棄されます。

・プーリングが無効の場合、以下の時に物

理接続が破棄されます。

－アプリケーションでConnectionオブ

ジェクトに対してcloseメソッドが実行

された時。ただし、トランザクション内

で接続がキャッシュされている場合

には、トランザクションが完了した時。

D12 検証に失敗した物理接続数 (注1)(注2) －・接続検証の有効時、かつ接続検証に失

敗した時

・接続検証の有効時、かつ「すべての障害

で」の有効時、かつ接続障害と判断され

た時

D13 使用されていない物理接続の小数 (注2)

－

D14 使用されていない物理接続の大数 (注2)

－

D15 使用されていない物理接続の現在数 (注2)

－

D16 認証情報のマッチングに失敗した物理接

続数 (注1)(注2)○ 接続のマッチングに失敗した時

D17 プールに戻された論理接続数 (注1) ○

D18 認証情報のマッチングに成功した物理接

続数 (注1)(注2)○ 接続のマッチングに成功した時

D19 タイムアウトになった物理接続数 (注1)(注2)

－接続要求のタイムアウト発生時( 大待ち時

間 > 0)

D20 使用中の物理接続の小数 (注2) ○

D21 使用中の物理接続の大数 (注2) ○

D22 使用中の物理接続の現在数 (注2) ○

D23 待機しているキュー内の接続要求の数－プール内の接続数が大値に達し、全接続

が使用中の時 (注3)

D24 リークが発生した接続の数(注1) ○ 接続リーク発生時

- 173 -

注1)：この項目は、監視レベルをHIGHに設定した場合のみ出力されます。

注2)：この物理接続は、JDBCドライバ側から取得した接続です。通常、JDBCドライバ側から取得した接続は物理接続と

なります。JDBCドライバ側のプーリング機能を利用する場合、実際の物理接続は、JDBCドライバ側でキャッシュされるた

め、JDBCドライバ側から取得した接続は実際の物理接続ではない場合もあります。

注3)：プーリングが無効のときに、接続プールから取得する接続は大プールサイズの制限がありません。そのため、

プーリングが無効の場合、プール内の接続数は大値に達しません。

JDBCリソースの接続を取得する場合でも監視情報に反映されない場合があります。詳細は「5.18.1 注意事項」を参照し

てください。

11) トランザクション情報

トランザクションの性能情報です。




D3 プロセスID

D4 ロールバックされたトランザクションの数

D5 コミットされたトランザクションの数

D6 アクティブなトランザクションの数

12) JMS/コネクタ接続プール情報

JMS接続ファクトリ、またはコネクタ接続プールの性能情報です。プールごとに情報を出力します。

コネクタ接続プールの場合、指定したIJServerクラスタに関連付けられたコネクタリソースがひとつもない場合は情報が出

力されません。なお、関連付けを行った後は情報が出力されます。

背景色が薄い緑色の行は、監視レベルがHIGHの項目です。




D3 プロセスID

D4 コネクタ接続プール名

D5 接続要求の平均待機時間(単位:ミリ秒) (注)

D6 接続要求の短待機時間(単位:ミリ秒) (注)

D7 接続要求の長待機時間(単位:ミリ秒) (注)

D8 近受け付けた接続要求の待機時間(単位:ミリ

秒) (注)

D9 プールから獲得した論理接続数 (注)

D10 作成された物理接続数

D11 破棄された物理接続数アイドルタイムアウトにより接続が

破棄された時

D12 検証に失敗した物理接続数 (注) ・接続検証の有効時、かつ接

続検証に失敗した時

・接続検証の有効時、かつ「す

べての障害で」の有効時、か

つ接続障害と判断された時

D13 使用されていない物理接続の小数

- 174 -


D14 使用されていない物理接続の大数

D15 使用されていない物理接続の現在数

D16 認証情報のマッチングに失敗した物理接続数 (注) 接続のマッチングに失敗した時

D17 プールに戻された論理接続数 (注)

D18 認証情報のマッチングに成功した物理接続数 (注) 接続のマッチングに成功した時

D19 タイムアウトになった物理接続数 (注) 接続要求のタイムアウト発生時(大待ち時間 > 0)

D20 使用中の物理接続の小数

D21 使用中の物理接続の大数

D22 使用中の物理接続の現在数

D23 待機しているキュー内の接続要求の数プール内の接続数が大値に達

し、全接続が使用中の時

D24 採取対象外の項目です。 (注)

注)：この項目は、監視レベルをHIGHに設定した場合のみ出力されます。

JMSまたはコネクタリソースの接続を取得する場合でも監視情報に反映されない場合があります。詳細は「5.18.1 注意事

項」を参照してください。

5.20 プロファイラ設定

プロファイラ設定により、プロファイラツール用の設定を管理できます。

必要に応じてプロファイラの有効/無効を切り替えることができるため、普段はプロファイラを無効にしておき、性能問題の

解析が必要となった際、プロファイラを有効にして分析を行うといった運用が可能です。

定義項目の詳細については、「Java EE運用ガイド」－「Java VMの定義項目」を参照してください。

なお、プロファイラツールと組み合わせた運用については、Interstage Application Serverの技術情報サイト(http://software.fujitsu.com/jp/technical/interstage/apserver/)でも情報を公開しています。

5.20.1 プロファイラ設定の運用方法

プロファイラ設定の基本運用の流れは、以下のとおりです。

- 175 -

プロファイラ設定の作成

プロファイラ設定の作成は、Interstage Java EE管理コンソール、またはasadminコマンドにより行います。

操作方法の詳細については、以下を参照してください。


－「リファレンスマニュアル(コマンド編)」－「create-profilerサブコマンド」

プロファイラ設定の削除

プロファイラ設定の削除は、Interstage Java EE管理コンソール、またはasadminコマンドにより行います。



－「リファレンスマニュアル(コマンド編)」－「delete-profilerサブコマンド」

プロファイラ設定配下のJVMオプションの作成

プロファイラ設定配下のJVMオプションの作成は、Interstage Java EE管理コンソール、またはasadminコマンドにより行

います。



－「リファレンスマニュアル(コマンド編)」－「create-jvm-optionsサブコマンド」

プロファイラ設定配下のJVMオプションの削除

プロファイラ設定配下のJVMオプションの削除は、Interstage Java EE管理コンソール、またはasadminコマンドにより行

います。



- 176 -

－「リファレンスマニュアル(コマンド編)」－「delete-jvm-optionsサブコマンド」

- 177 -

第6章 J2EEのチューニング

J2EEのチューニングについては、「J2EE ユーザーズガイド(旧版互換)」を参照してください。

- 178 -

第7章業務構成管理機能のチューニング

業務構成管理機能が管理するリポジトリの設定値をチューニングすることで、適な状態での運用を行うことが可能とな

ります。ここでは、業務構成管理機能が管理するリポジトリのチューニングについて説明します。

7.1 リポジトリのチューニング

リポジトリのチューニングについては、以下のマニュアルを参照してください。

・ “運用ガイド(基本編)”の“業務構成管理機能”

- 179 -

第8章 JDK/JREのチューニング

CやC++では、メモリに割り当てた領域は、不要になった時点でプログラマーが明示的に解放する必要があります。しか

し、この解放処理に漏れやミスがあると、メモリリーク、プログラム停止および暴走が発生するデメリットがあります。

Javaでは、ガーベジコレクション(GC)を導入したことにより、プログラマーがメモリ管理において作業の負担を軽減できる

ようになりました。その反面、GCが発生するたびにJavaアプリケーションが一時停止するため、パフォーマンス劣化の要

因になることがあります。また、Java独特のメモリリークも存在します。

Javaでは、スレッドを管理しやすいため、大量のスレッドを生成する傾向があります。このため、スタックが大量に生成さ

れて、メモリ不足になることもあります。

以上から、多くの場合において、JDK/JREのチューニングは、スタックサイズ、または、GCの発生頻度とその処理時間を

調整することになります。本章では、Javaアプリケーションのチューニングにあたって、必要な基礎知識やチューニング方

法などを説明します。

8.1 基礎知識

本項では、JDK/JREのチューニングを行う際に必要な知識を説明します。

8.1.1 JDK関連のドキュメント

■JDKドキュメント

本製品に搭載しているJDK 6、7のドキュメントは、それぞれ次のURLにあります。

・ JDK 6 : http://docs.oracle.com/javase/jp/6/

・ JDK 7 : http://docs.oracle.com/javase/7/docs/ (英語)

上記のドキュメントは、マニュアルパッケージの次の箇所にも格納しています。

・ JDK 6 : \ApplicationServer\javadocs\jdk6-jdkdocs.zip

・ JDK 7 : \ApplicationServer\javadocs\jdk7-jdkdocs.zip (英語)

Java VisualVMのドキュメントは、マニュアルパッケージに含まれていません。

Java VisualVMに関しては、以下のURLを参照してください。

http://docs.oracle.com/javase/jp/6/technotes/guides/visualvm/index.html

なお、Java VisualVMは、JDK 6から搭載しているツールです。

また、javaコマンドおよびJava VMのオプションには、チューニングに関するオプションがあります。本章では、これらの

オプションを随所で紹介します。

各オプションの詳細は、次を参照してください。なお、本マニュアル内で具体的に説明していないJava VMのチューニ

ングに関するオプションは、富士通版Java VMではサポートしておりません。

・ javaコマンドのオプション

JDKドキュメントの「JDKツールとユーティリティ」の「java」

・ Java HotSpot VM Optionshttp://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

■Java プラットフォーム移行ガイド

JDK 1.3で開発されたJavaプログラムを、JDK 5.0に移行する際の非互換や問題点については、「Java プラットフォーム

移行ガイド (バージョン 1.3 から 5.0 へ)」を参照してください。

このガイドは、マニュアルパッケージの次の箇所に格納しています。

- 180 -

・ \ApplicationServer\JavaplatformMigration\jm_white_paper_r6a-jp.pdf

JDK5.0からJDK6への移行については、以下のURLを参照してください。

・ http://www.oracle.com/technetwork/java/javase/adoptionguide-137484.html

JDK6からJDK7への移行については、以下のURLを参照してください。

・ http://docs.oracle.com/javase/7/docs/webnotes/adoptionGuide/index.html

8.1.2 Java VM

■製品搭載のJava VM

JDK/JREには、Javaのバイトコードを解釈・実行するエンジン部であるJava仮想マシン(Java VM)があります。

“表8.1 Java VMの種類と特徴”に、Java VMの種類と特徴を示します。

表8.1 Java VMの種類と特徴

Java VMの名

称

Java VMの特徴

Java HotSpotClient VM

アプリケーション起動時間を短縮し、メモリ消費を抑制するように設計され

たクライアント環境向けのJava VMです。

富士通版Java HotSpot Client VMでは、Oracle CorporationのJava VMであるJava HotSpot Client VMをベースに、富士通独自技術によるトラブ

ルシューティングに関する機能強化などを追加実装しています。

そのため、ベースとしたJava HotSpot Client VMと機能的な互換性を基本

的にもっています。

追加実装された機能項目については、“8.1.3 FJVM”を参照してくださ

い。

Java HotSpotServer VM(FJVM)

アプリケーション起動時間の短縮などよりも、安定性および、スループット

の向上を考慮して設計されたサーバ環境向けのJava VMです。

富士通版Java HotSpot Server VMでは、Oracle CorporationのJava VMであるJava HotSpot Server VMをベースに、富士通独自技術による性能改

善やトラブルシューティングに関する機能強化などを追加実装しています。

そのため、ベースとしたJava HotSpot Server VMと機能的な互換性を基

本的にもっています。

富士通版Java HotSpot Server VMは、Interstage Application Server搭載のJDK/JREにおけるデフォルトのJava VMであることから、このJava VMを特にFJVMと呼びます。

追加実装された機能項目については、“8.1.3 FJVM”を参照してくださ

い。

Interstage Application Server搭載のJDK/JREでは、Java HotSpot Client VMとFJVM(=Java HotSpot Server VM)を搭載しています。

デフォルトのJava VMは、FJVMです。これは、javaコマンドのオプションに、“-server”または“-fjvm”を指定することと同

義です。Java HotSpot Client VMを使用したい場合は、オプションに“-client”を指定してください。

実行モードが64ビットモードのJDK/JREではFJVMのみ使用可能です。Java HotSpot Client VMは搭載していませ

ん。

エルゴノミクス機能によるJava VMの自動選択機能

富士通版JDK/JRE 6、7では、エルゴノミクス機能によるJava VMの自動選択機能（マシンのCPU数や物理メモリ量など

に応じて、使用するJava VMを自動的に選択する機能）は無効になっています。

- 181 -

■Java VM関係の資料

Java VMの詳細は、JDKドキュメンテーションの次を参照してください。

・ JDK 6の場合 : [Java SE 6 概要] > [Java 仮想マシン] および

http://docs.oracle.com/javase/jp/6/technotes/guides/vm/index.html

・ JDK 7の場合 : [Description of Java Conceptual Diagram] > [Java Virtual Machine] および

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/index.html

他にも、Java VMに関連する資料があります。

・ Java Language and Virtual Machine Specificationshttp://docs.oracle.com/javase/specs/

・ Java HotSpot VM Optionshttp://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

・ Java SE 6 HotSpot Virtual Machine Garbage Collection Tuninghttp://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

8.1.3 FJVM 本章におけるJava VMに関する情報は、デフォルトのJava VMである「富士通版Java HotSpot Server VM(=FJVM)」を

中心に説明しています。なお、特に断り書きの無い限り、それらの情報は「富士通版Java HotSpot Client VM(=Java HotSpotClient VM)」に対しても、そのまま適用されます。

FJVMにおいて提供される「富士通独自技術により強化された機能および固有機能」は以下のとおりです。

FJVM固有機能を除き、Java HotSpot Client VMも同様です。

・ New世代領域用制御処理並列化機能付きGC（パラレルGC）

・コンカレント・マーク・スイープGC付きパラレルGC（CMS付きパラレルGC）

・オブジェクト参照の圧縮機能 (注)

・ガーベジコレクションのログ出力

・コンパイラ異常発生時の自動リカバリ機能 (注)

・長時間コンパイル処理の検出機能 (注)

・動的コンパイル発生状況のログ出力機能 (注)

・クラスのインスタンス情報出力機能

・ java.lang.System.gc()実行時におけるスタックトレース出力機能

・ Java VM終了時における状態情報のメッセージ出力機能

・ログ出力における時間情報のフォーマット指定機能

・ FJVMログ

・メモリ領域不足事象発生時のメッセージ出力機能の強化

・スタックオーバーフロー検出時のメッセージ出力機能

注) FJVMにだけ提供されるFJVM固有機能です。

8.1.4 仮想メモリと仮想アドレス空間

Javaアプリケーションを開発・運用するにあたり、OSのメモリ管理の概要を知っておく必要があります。本節では、OSの

一般的なメモリ管理技法の1つである仮想アドレス空間を説明します。

なお、仮想アドレス空間の具体的なアーキテクチャーはOSごとに異なりますが、本節では各OSに共通する内容を説明

します。

- 182 -

■仮想メモリ

OSは、物理メモリ(RAM)だけでなくスワップファイルを活用することにより、多くのメモリ領域を使用することができます。

このテクノロジーを仮想メモリといいます。仮想メモリの容量は、RAMとスワップファイルのサイズの合計になります。

図1 OSが利用可能なメモリ容量

ただし、ハードディスクへのアクセスはRAMより低速なので、メモリのスワッピングは性能に大きく影響を与えますので、

注意が必要になります。

■仮想アドレス空間

OS上でプログラムを起動すると、OSがプログラムを実行・管理する単位としてのプロセスが生成されます。同様にして、

Javaアプリケーションを起動すると、Javaプロセスが生成されます。

OS上で生成されたプロセスには、仮想アドレス空間が割り当てられます。仮想アドレス空間は、それぞれのプロセスで

独立したものであり、あるプロセスから別のプロセスの仮想アドレス空間にアクセスすることはできません。マシンに積んで

いる物理メモリ(RAM)のサイズとは関係なく、仮想アドレス空間のサイズは、常に一定です。たとえば、32ビットアーキテク

チャーのOSの場合、物理メモリ(RAM)のサイズに依存せず、仮想アドレス空間のサイズは常に4GB(2の32乗バイト)です。

このため、大量の仮想メモリを用意しても、1つのプロセスで使用できるメモリ量の上限は仮想アドレス空間の上限になり

ますから、プロセスが仮想アドレス空間の大きさ（実際には後述のユーザ空間の大きさ）を越えるメモリ量を必要とする場

合は、メモリ不足の状態になります。

逆に、プロセスが必要とするメモリ量が仮想アドレス空間の大きさ（実際には後述のユーザ空間の大きさ）の上限未満

だったとしても、そのメモリ量に相当する仮想メモリ量がOS上になければ、メモリ不足の状態になります。

また、大量の仮想メモリを用意しても、OS上で大量のプロセスが動作していて仮想メモリを大量に消費している状態で

あれば、各プロセスに割り当てられた仮想アドレス空間を使い切っていなくても、メモリ不足の状態になる場合がありま

す。

■ユーザ空間

プロセスが持つ仮想アドレス空間のうち、実際にプロセスが使用できる空間を、ユーザ空間といいます。ユーザ空間に

は、プログラムの実体(Windows(R)でJavaアプリケーションを実行する場合は、java.exeなど)がコピーされるだけでなく、

スタックやヒープなどのさまざまなセグメントがあります。更にユーザ空間は、実行するプログラムだけでなく、そのプログ

ラムを実行させるためのOS側のプログラムなどでも使用します。Javaプロセスのユーザ空間の場合には、前述の各セグメ

ントの他に、Javaオブジェクトを格納するセグメント(=Javaヒープ)があります。このため、Javaアプリケーションをチューニン

グする際の対象となるJavaヒープのサイズの上限値は、ユーザ空間のサイズよりも少なくなります。

Javaアプリケーションのチューニングを実施する際は、仮想メモリの容量やプロセスの使用状況など、システムの状態を

考慮する必要があります。なおOSの種類やアプリケーションの実行モードによって、ユーザ空間として使用できる上限値

が異なるため、注意が必要です。

なお、各セグメント獲得・解放時の実際の制御処理はOSが行います。そのため、各セグメントに関する管理方法/動作

仕様/大きさについては、JDK/JREを実行する各OSの仕様に依存します。そして、プロセス外部からはユーザ空間に空き

が存在するように見える場合であっても、OSの制御処理上は利用できる空きが無いと判断され、セグメントに対応するメ

モリ領域が獲得できず、プロセス動作が異常となる場合がありますので注意してください。

また、OSの制御処理上、各セグメント間には、アプリケーションから利用できない隙間領域が存在する場合があります。

そのため、通常、ユーザ空間としての上限値まで仮想メモリを使用することはできません。プロセスが使用するメモリ量と

して、ユーザ空間の上限値まで使えることを前提とした設計にはしないでください。

■実行モード

実行モードが変わると、プログラムの実行に必要な基本メモリ量が変わります。

具体的には、プログラムの実行モードを32ビットモードから64ビットモードに変更して実行する場合、ポインタを扱うため

- 183 -

に必要となるメモリ量の単位が、４バイトから８バイトになります（OSによっては、整数を扱う際に必要となるメモリ量の単位

も異なります）。そのため、同じソースから作られたプログラムの場合であっても、64ビットOS上で64ビットモードのプログラ

ムを使ってアプリケーションを動作させる場合は、32ビットOSまたは64ビットOS上で32ビットモードのプログラムを使って

アプリケーションを動作させる場合よりも、より大きなメモリ量が必要となります。

64ビットモード時のCデータ型モデル

LP64モデル：long型/ポインタが32ビット(4バイト)から64ビット(8バイト)へ変更されます。

P64モデル：ポインタが32ビット(4バイト)から64ビット(8バイト)へ変更されます。

Javaアプリケーションの場合もC/C++アプリケーションの場合と同様、実行モードが変わると、プログラムの実行に必要な

基本メモリ量が変わります。

特に、オブジェクトを構成するデータ内容にはポインタを扱う情報も多数あるため、 64ビットモードの場合、1オブジェク

トあたりに必要となるメモリ域の大きさは32ビットモードの場合よりも大きくなります。

そのため、通常、64ビットOS上で64ビットモードのJDK/JREを使ってJavaアプリケーションを動作させる場合、32ビットOSまたは64ビットOS上で32ビットモードのJDK/JREを使ってJavaアプリケーションを動作させた場合の設定に対して、1.5～

2倍のJavaヒープ量が必要です。

8.1.5 スタック

ここでは、スタックについて簡単に説明します。

プログラムがスレッドを生成すると、OSがそのスレッドに対してスタックと呼ばれるメモリ領域をそのスレッドの終了時まで

自動的に割り当てます。スタックは、スレッド上で実行されるメソッドや関数が使用するローカル変数などの一時的なデー

タを格納するための作業域として使用されます。

スレッド上では多くのメソッドや関数が入れ子状態で呼び出されるので、これらのメソッドや関数が使用する一時的な作

業域を管理するために、OSはフレームと呼ばれる区切りで個々の作業域をスタック上に積み上げることで管理していま

す。(メソッドや関数が呼び出されるごとに、これらが使用する作業域をフレームという区切りでスタック上に積み上げ、フ

レーム内のデータは呼び出したメソッドや関数からの復帰時に破棄されます。)

このため、あるメソッドを再帰的に無限に呼び出すなどしてメソッドを深く呼び出した場合や、非常に大きなサイズのロー

カル変数などを使用するメソッドを呼び出した場合などには、スタック域の枯渇により、スタック上にフレームを積み上げ

ることができなくなり、スタックオーバーフローが発生する場合があります。

Javaアプリケーションの場合、通常、スタックオーバーフローが発生すると、java.lang.StackOverflowErrorがスローされま

す。ただし、Javaプロセス中のネイティブモジュール実行時の処理でスタックオーバーフローが発生した場合には、

java.lang.StackOverflowErrorはスローされません。なお、FJVMを使用しているJavaプロセス中のネイティブモジュール実

行時にスタックオーバーフローが発生した場合は、“8.6.3.1 スタックオーバーフロー検出時のメッセージ出力機能”によっ

てスタックオーバーフローの発生を検出できる場合があります。

スタック領域の管理

スタック領域の実際の管理はOSが行います。そのため、スタック領域に関する管理方法/動作仕様/大きさについて

は、JDK/JREを実行する各OSの仕様に依存します。

なお、Javaアプリケーション実行時のスタックオーバーフロー発生をJava VMが検出できる様にするために、スタック

領域の一部をJava VMの制御用領域として使用します。そのため、Javaアプリケーションから使用できるスタック領域

の大きさは、スタックとして割り当られた領域の大きさよりも若干小さな大きさになります。

クラスファイル実行時のスタック領域の利用

Javaの実行環境であるJava VMが起動された後、Java VMは、実行対象プログラムであるクラスファイルを読み込

み、クラスファイルを以下の2つの方法を用いて実行します。

・インタプリタによるバイトコードの実行

- 184 -

・動的コンパイルにより、バイトコードを機械命令に翻訳してから実行

あるクラスファイル中の同じJavaメソッドを実行する場合であっても、Java VMによる実行方法が異なる場合は、実行

時に使用されるスタックの大きさが異なります。

なお、クラスファイルの実行方法については、“8.3 動的コンパイル”を参照してください。

ユーザ空間のメモリ不足によるスレッド生成エラー

スタックは、プロセス内のユーザ空間から割り当てられます。

そして、ユーザ空間のメモリ不足によりスタックなどを割り当てることができなった場合には、スレッド生成処理でエ

ラーが発生します。

Javaプロセスの場合、Javaヒープなどのサイズを大きく確保すると、その分だけスタックとして割当て可能な領域が減

少するため、Javaプロセス内で生成可能なスレッドの個数も減少します。

このため、Javaプロセス内のスレッド生成処理がエラーとなる要因の1つとして、Javaヒープなどのサイズを大きく確保

したことによるユーザ空間のメモリ不足が考えられます。

Javaプロセスの消滅

Windows(R)では、Javaプロセス内でスタックオーバーフローが発生した場合、システム状態やプログラム状態によっ

ては、OSからFJVMやワトソン博士に制御が渡らず、痕跡を残さずにJavaプロセスが消滅する場合があります。

なお、ワトソン博士の説明は、“8.5.9.1 クラッシュダンプ”を参照してください。

8.1.6 Javaヒープとガーベジコレクション

ここでは、Javaヒープとガーベジコレクション(GC)を説明します。

Javaヒープは、Javaプロセス内に存在するJavaオブジェクトを格納するための領域です。

Javaヒープは、New世代領域、Old世代領域およびPermanent世代領域に大別され、Java VMが管理・制御します。な

お、New世代領域とOld世代領域は、メモリ割り当てプールという形で各領域を合わせて一括的に管理・制御します。

Java VMは、Javaアプリケーションの実行時に、JavaオブジェクトをJavaヒープの各領域に格納します。Javaヒープの空

き容量がなくなった場合は、java.lang.OutOfMemoryErrorがスローされます。

また、不要となったJavaオブジェクトはGCにより回収され、Javaヒープの空き領域が増加します。なお、New世代領域に

存在する不要となったJavaオブジェクトを回収するGC処理を「NewGC処理(またはマイナーGC処理)」といいます(NewGCまたはマイナーGCと略す場合もあります)。また、New世代領域だけでなく、Old世代領域やPermanent世代領域を含む

Javaヒープ全体に存在する不要となったJavaオブジェクトを回収するGC処理を「FullGC処理」といいます(FullGCと略す

場合もあります)。

図1 Javaヒープの構造

・ New世代領域とOld世代領域(メモリ割り当てプール)

New世代領域とOld世代領域は、インスタンスや配列などのJavaオブジェクトを管理する領域です。

New世代領域は寿命の短いJavaオブジェクトを管理します。通常、Javaアプリケーションで要求されたオブジェクト

は、New世代領域に生成されます。一定期間New世代領域で生存したJavaオブジェクトは、GC処理によってOld世

代領域に移動されます。そして、Old世代領域に存在する不要となったJavaオブジェクトは、FullGC処理によって回

収されます。領域がNew世代とOld世代に分かれるのは、世代別にGC処理を実行するためです。

なお、メモリ割り当てプール全体のサイズの初期値および大値は、それぞれ、“-Xms”オプションおよび“-Xmx”

オプションで指定することができます。

- 185 -

・ Permanent世代領域

Permanent世代領域は、Javaのクラス、メソッドや定数など、永続的に参照される静的オブジェクトを管理する領域です。

Permanent世代領域に存在する不要となったオブジェクトは、FullGC処理によって回収されます。

なお、Permanent世代領域の大きさの初期値および大値は、それぞれ、“-XX:PermSize”オプションおよび“-XX:MaxPermSize”オプションで指定することができます。

ユーザ空間

Javaヒープは、Javaプロセスのユーザ空間内に割り当てられます。

また指定された大値までJavaヒープが利用できる環境にするため、Java VM起動時に、メモリ割り当てプールおよび

Permanent世代領域を、各大値の大きさで連続領域としてリザーブします（同一プロセス内の他の処理から使用でき

ないようにします）。

このため、Javaヒープの大値を大きく設定すると、その分だけスタックなど他の処理に割り当てられるメモリ領域が減

少します。

別な言い方をすれば、ユーザ空間内で使用できるメモリ量の上限から、Javaアプリケーション自身、Java VM、そしてネ

イティブモジュール(OSを含む)が使用するメモリ量などを差し引いた値が、Javaヒープとして使用できる上限となります。

なおJava VM起動時に指定されたJavaヒープの大きさが利用できない場合、Java VMは以下のメッセージを出力し、

Javaプロセスを終了させます。

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

このメッセージが出力された場合は、Javaヒープを小さくするチューニングを行ってください。

またSolaris用およびLinux用のJava VMにおいて、Java VM起動時またはJavaアプリケーション実行中に「ユーザ空間

不足」または「仮想メモリ不足」が発生した場合、Java VMは以下のメッセージを出力し、Javaプロセスを終了させます。

Java VM起動時の場合:

制御名: mmap failed: errno=エラー情報, 制御情報....Error occurred during initialization of VMmmap failure

Javaアプリケーション実行中の場合:

制御名: mmap failed: errno=エラー情報, 制御情報....(上記メッセージに続いて、java.lang.OutOfMemoryErrorメッセージが出力される場合があり

ます。)

制御名 : メモリ不足が発生した際のJava VMの制御名

エラー情報：メモリ不足が発生した際のJava VMのエラー情報

制御情報 : メモリ不足が発生した際のJava VMの制御情報

ユーザ空間が不足している場合は、Javaヒープを小さくするチューニングを行ってください。

仮想メモリが不足している場合は、他の不要なプロセスを終了して仮想メモリに余裕を持たせるか、物理メモリ(RAM)またはスワップファイルを拡張して仮想メモリを増やすようにチューニングを行ってください。

ユーザ空間

Java VMは、OSの仮想メモリ資源を効率的に利用するために、起動時にJavaヒープの各領域の初期値を割り当て、各

領域の大値まで段階的に拡大する制御方法を用いています。

具体的には、Javaプロセスの起動時はメモリ割り当てプールおよびPermanent世代領域の各初期値のサイズを割り当

てます。その後、FullGC処理の結果、各領域が不足した場合、各領域の大値まで、段階的に拡大していきます（GC

- 186 -

処理としてメモリ割り当てプールの小使用量保証機能を無効にしたパラレルGCを使用している場合は、メモリ割り当て

プールの大きさが、初期値よりも小さくなる場合があります）。

なお、各領域を拡大していく過程で、OS側で物理メモリの資源をディスクにスワップする処理が発生する場合がありま

す。このスワップ処理により、各領域を拡大するFullGC処理に時間がかかる場合があります。FullGC処理中のスワップ

処理発生による時間遅延が問題になる場合は、Javaヒープの各領域に対する初期値と大値は同じ値に指定してください。

パラレルGCについては、“8.2.3 New世代領域用制御処理並列化機能付きGC（パラレルGC）”を参照してください。

8.1.7 FJVMに対して指定可能なチューニング用オプション

Javaヒープのチューニングなど、FJVMに対して指定可能なJava VMのチューニングに関するオプションを、図1に示し

ます。

各オプションの使用法については、本マニュアルを参照してください。

なお、本マニュアル内で具体的に説明していないJava VMのチューニングに関するオプションは、FJVMではサポートし

ておりません。

図1 FJVMに対して指定可能なJava VMのチューニングに関するオプション

【Javaヒープチューニング用のオプション】

-Xms-Xmx-XX:NewSize-XX:MaxNewSize-XX:NewRatio-XX:SurvivorRatio-XX:TargetSurvivorRatio-XX:PermSize-XX:MaxPermSize

【スタックサイズチューニング用のオプション】

-Xss-XX:CompilerThreadStackSize

【使用するガーベジコレクション処理を選択するオプション】

-XX:+UseSerialGC-XX:+UseParallelGC-XX:UseFJcmsGC

【ガーベジコレクション処理のチューニング用オプション】

パラレルGC用：

-XX:ParallelGCThreads-XX:+UseAdaptiveSizePolicyMinHeapSizeLimit-XX:-UseAdaptiveSizePolicyMinHeapSizeLimit-XX:+AutomaticallyJavaHeapSizeSetting-XX:GCTimeLimit-XX:GCHeapFreeLimit-XX:+UseGCOverheadLimit

CMS付きパラレルGC用：

-XX:ParallelGCThreads-XX:ConcGCThreads

- 187 -

共通：

-XX:-UseCompressedOops (64ビットモード版JDK/JREの場合)

【チューニングの際に使用するログ出力などのデバッグ用オプション】

ガーベジコレクションのログ出力用：

-verbose:gc-XX:+UseFJverbose-XX:+ClassUnloadingInfo-Xloggc

動的コンパイルのログ出力用：

-XX:+PrintCompilationCPUTime-XX:+FJPrintCompilation

ログ出力共通：

-XX:FJverboseTime

その他：

-XX:-OmitStackTraceInFastThrow-XX:+PrintClassHistogram-XX:+PrintJavaStackAtSystemGC-XX:+VMTerminatedMessage-Xcheck:jni-XX:+PrintCompilerRecoveryMessage-XX:CompileTimeout

8.1.8 Java Native Interface(JNI) アプリケーションミスのトラブルの確実な事前防止のためには、(CやC++等を使用した)ネイティブプログラムを、JavaNative Interface(JNI)経由で利用してはいけません。実現しようとしている機能が、Javaにより記述できないか設計段階で

十分に検討を行ってください。やむをえず利用する場合でも、JNIの利用は小限にし、十分な確認とデバッグを実施し

てください。

JNIを利用する場合の前提スキルとして、以下は必須です。

・ C/C++によるマルチスレッドプログラミングの経験がある

・トラブル発生時、自分でデバッグできる

ファイナライズ処理を期待したリソース管理は、行わないでください。JNI関連で、もっともトラブルが多いのは、ネイティ

ブプログラム側で確保したメモリの後処理漏れです。例えば、次のようなプログラミングをしてはいけません。

------- Java ---------------

class A {

native long nativeAlloc();

native void nativeFree(long a);

long address;

A() {

address = nativeAlloc();

}

- 188 -

public void finalize() {

nativeFree(address);

}

}

------- Java ---------------

------- C ------------------

JNIEXPORT jlong JNICALL Java_A_nativeAlloc(JNIEnv *env, jobject o)

{

return (jlong)malloc(10);

}

JNIEXPORT void JNICALL Java_A_nativeFree(JNIEnv *env, jobject o, jlong p)

{

free((void*)p);

}

------- C -------------------

エラー処理は、必ず行ってください。ネイティブプログラム側でJNI関数呼び出しをしたとき、色々なケースでJavaレベル

のエラーになることがあります。このエラーに対する後処理をネイティブプログラム側で行わないと、例外がスローされて

いる状態のままになり、それ以降のJNI関数の呼び出しに失敗し、アプリケーションが正しく動作しません。

なお「JNI関数」とは、以下のJNI仕様書に記述されている関数のことです。

http://docs.oracle.com/javase/jp/6/technotes/guides/jni/spec/functions.html

これらを使う場合は、その度にExceptionOccurredを使用しエラーチェックをする必要があります。

Solaris、Linux上でJNIを利用される場合は、連携するネイティブプログラムまたは、ネイティブライブラリにおいてシグナ

ルハンドラの書き替えを絶対に行わないでください。

なお、JDK/JRE 1.4.0以降でサポートされたシグナル連鎖機能(Signal Chaining)を利用する場合、マルチスレッド環境に

おけるシグナル動作など、OSやJava VM自身のシグナル動作およびプログラミングについての知識が前提として必要です。

安定稼動が要求されるシステムの設計においては、この機能の使用もお勧めできません。

8.2 ガーベジコレクション(GC) 本節では、ガーベジコレクション(GC)について説明します。

8.2.1 FJVMでサポートされるガーベジコレクション処理

FJVMでサポートされるガーベジコレクション(GC)処理には、JavaヒープのNew世代領域に対するGC制御方法の違い

により、以下の3種類があります。

・標準GC（シリアルGC）

・ New世代領域用制御処理並列化機能付きGC（パラレルGC）

・コンカレント・マーク・スイープGC付きパラレルGC（CMS付きパラレルGC）

なお、JDK/JREのバージョン、実行モード、Java VMの種類により、サポートされるGCの種類が異なります。また、JavaVMの種類により、デフォルトで動作するGCが異なります。

“表8.2 サポートされるGCの種類”に、サポートされるGCの種類とデフォルトのGCを示します。

- 189 -

表8.2 サポートされるGCの種類

JDK/JREのバージョン JDK/JRE 6、7

JDK/JREの実行モード 32ビットモード 64ビットモード

Java VMの種類 Client VM FJVM FJVM ※

シリアルGC ◎ ○ ○

パラレルGC ○ ◎ ◎

CMS付きパラレルGC □ □ □

○：サポートされるGC◎：サポートされるGC、かつデフォルトのGC□：Interstage Application Server Enterprise EditionでだけサポートされるGC※実行モードが64ビットモードのClient VMは提供していません。

GCは、デフォルトのGCの使用を推奨します。

通常、デフォルトのGCを変更する必要はありません。

注意

JDK/JRE 6、7では、New世代領域用GC制御に対し「New世代領域サイズ自動調整機能」を追加して構成されたGC処

理「FJGC」を提供していません。

Java HotSpot Client VMに対して“-XX:+UseFJGC”オプションを指定した場合は、図1のエラーメッセージが標準エラー

出力へ出力され、Javaプロセスの起動に失敗します。

FJVMに対して“-XX:+UseFJGC”オプションを指定した場合は、図1のワーニングメッセージが標準エラー出力へ出力さ

れ、オプションの指定は無効になります。

図1 -XX:+UseFJGCを指定した際に出力されるメッセージ

【Java HotSpot Client VMの場合】

Unrecognized VM option '+UseFJGC'

【実行モードが32ビットモードのFJVMの場合】

warning: -XX:+UseFJGC is not supported in Java HotSpot Server VM.

【実行モードが64ビットモードのFJVMの場合】

warning: -XX:+UseFJGC is not supported in Java HotSpot 64-Bit Server VM.

■New世代領域の使われ方

NewGC処理では、New世代領域を「eden space」、「from space」および「to space」の3つの内部領域に細分割し、当該

領域上において、一般に世代別GC制御と言われる制御方法を用いて、Javaアプリケーションが生成要求したオブジェク

トを管理・制御しています。

このうち、「from space」および「to space」は、Java VMがNewGC処理を行う際の作業域的な役割を持つ領域となってい

ます。そのため、「from space」および「to space」の各領域が占める大きさのうち、Javaアプリケーションからのオブジェクト

生成要求のために使用される大きさは、その領域の一部分だけとなります。

そのため、ガーベジコレクションのログ出力などの出力データにおいて、メモリ割り当てプールやNew世代領域に空き

があるように見える場合であっても、実際には空きがない場合があります（空きがあるように見える場合であっても、その

差は、NewGC処理用の作業域的な役割で使用済となっている場合があります）。

■ガーベジコレクション処理の実行抑止

“表8.3 ガーベジコレクション処理の実行が抑止される機能”に示す機能を使用するJavaアプリケーションを実行すると、

Javaヒープ内に存在する全オブジェクトの移動が禁止されるクリティカルセクションと呼ばれる状態が、当該機能の利用

状況に応じて発生します。

クリティカルセクション状態発生時は、オブジェクトの移動が禁止されるため、オブジェクト移動が必須となるGC処理の

- 190 -

実行が抑止される状態となります。

Java VMは、JavaアプリケーションによりGC処理の実行が抑止されている際に発生したオブジェクト生成要求に対し、

New世代領域に空きが無い場合には、Old世代領域の空き領域を一時的に使用して対応します。

そして、要求されたオブジェクト量を満たす空きがOld世代領域にない場合には、java.lang.OutOfMemoryError例外を

発生させます。

そのため“表8.3 ガーベジコレクション処理の実行が抑止される機能”の機能を多用するJavaアプリケーションの場合は、

GC処理実行が抑止される状態も多数発生する可能性が高くなり、当該機能を多用しないJavaアプリケーションに比べ、

GC処理実行抑止に因るjava.lang.OutOfMemoryError例外が発生しやすい状態にあります。

特にOld世代領域が小さい状態でJavaアプリケーションを実行した場合は、Old世代領域の空きとなり得る大値（仮に

Old世代領域を全く使用しない場合だと、Old世代領域自身の大きさ）もその大きさに比例して小さいため、その傾向が強

まることがあります。

なおFJVMでは、GC処理の実行抑止によりjava.lang.OutOfMemoryError例外が発生したかどうかの情報を出力する機

能を提供しています。

詳しくは“8.6.1.1 メモリ領域不足事象発生時のメッセージ出力機能の強化”を参照してください。

表8.3 ガーベジコレクション処理の実行が抑止される機能

【GC処理の実行が抑止される状態となるJNI関数】

- GetPrimitiveArrayCritical()実行からReleasePrimitiveArrayCritical()実行までの間

- GetStringCritical()実行からReleaseStringCritical()実行までの間

【GC処理の実行が抑止される状態となるJVMPI関数】(注)

- DisableGC()実行からEnableGC()実行までの間

【GC処理の実行が抑止される状態となるJVMPIイベント】(注)

- JVMPI_EVENT_THREAD_START - JVMPI_EVENT_CLASS_LOAD - JVMPI_EVENT_CLASS_UNLOAD - JVMPI_EVENT_JNI_GLOBALREF_ALLOC - JVMPI_EVENT_JNI_GLOBALREF_FREE - JVMPI_EVENT_JNI_WEAK_GLOBALREF_ALLOC - JVMPI_EVENT_JNI_WEAK_GLOBALREF_FREE - JVMPI_EVENT_OBJECT_ALLOC - JVMPI_EVENT_MONITOR_CONTENDED_ENTER - JVMPI_EVENT_MONITOR_CONTENDED_ENTERED - JVMPI_EVENT_MONITOR_CONTENDED_EXIT - JVMPI_EVENT_MONITOR_WAIT - JVMPI_EVENT_MONITOR_WAITED - JVMPI_EVENT_HEAP_DUMP - JVMPI_EVENT_METHOD_ENTRY - JVMPI_EVENT_METHOD_ENTRY2 - JVMPI_EVENT_METHOD_EXIT

注) JDK/JRE 6、7では、Java Virtual Machine Profiling Interface(JVMPI)をサポートしていません。

■JVMPIとJVMTI

JDK/JRE 6、7では、Java Virtual Machine Profiling Interface(JVMPI)をサポートしていません。

- 191 -

JDK/JRE 6、7でJVMPI相当の機能を使用する場合には、Java Virtual Machine Tool Interface(JVMTI)を使用してくだ

さい。

■RMI処理の分散GC

JavaのRMI処理では、クライアントで不要となった参照に対するサーバ側のオブジェクトを破棄するため、DistributedGC(分散GC)という処理を行います。その処理の一貫として、以下のプロパティで設定された時間間隔(デフォルトの時間

間隔は1時間)ごとに、java.lang.System.gc()実行によるFull GCが発生します。なお、分散GCとメモリ不足等による通常の

ガーベジコレクション(GC)が同時に発生した場合は、メモリ不足等による通常のGCが実行され、分散GCによるFullGCは

実行されません（メモリ不足等による通常のGCがNewGC処理だった場合は、FullGCにはなりません）。

-Dsun.rmi.dgc.server.gcInterval=時間間隔(ミリ秒)-Dsun.rmi.dgc.client.gcInterval=時間間隔(ミリ秒)

分散GCは独自のタイマー制御の元で実行されるため、メモリ不足等による通常のGCの実行とは関係せずに実行され

ます。そのため、GC処理の結果ログを見た場合、Javaアプリケーションとしての処理がほとんど動作していない時間帯や

メモリ不足とは思われない状態のときに、FullGC処理が実行されているように見える場合があります。

またプロパティで指定された時間間隔が短い場合、Interstage Application Serverの予兆監視機能により警告を受ける

(EXTP4368メッセージやISJEE_OM3204メッセージが出力される)場合がありますので、注意してください。

8.2.2 標準GC（シリアルGC）

New世代領域用GC制御に対して何も付加機能を追加していない「標準機能のみ」で構成されたGC処理です。後述の

パラレルGCとの対比から、標準GCのことをシリアルGCと呼ぶ場合もあります。

Java HotSpot Client VM、および図1のオプションを指定した場合のFJVMでは、シリアルGCが実行されます。なお、

図1のオプションは、シリアルGCによるGC制御を有効にするオプションです。

図1 FJVMでシリアルGCを有効にする場合に指定するオプション

-XX:+UseSerialGC

図2はシリアルGC使用時に利用可能となる「Javaヒープのチューニング用オプション」です。

図2 Javaヒープチューニング用オプション（シリアルGC使用時）

-Xms-Xmx-XX:NewSize-XX:MaxNewSize-XX:NewRatio-XX:SurvivorRatio-XX:TargetSurvivorRatio-XX:PermSize-XX:MaxPermSize

8.2.3 New世代領域用制御処理並列化機能付きGC（パラレルGC）

New世代領域用GC制御に対し、「当該処理を並列化して実行する機能」を追加して構成されたGC処理です。New世

代領域用のGC制御を並列化して実行することから、このGCをパラレルGCと呼ぶ場合もあります。

図1のオプションは、パラレルGCによるGC制御を有効にするオプションです。

JDK/JRE 6、7のFJVMの場合は、デフォルトでこのGC処理が実行されます。

図1 JDK/JRE 6、7でパラレルGCを有効にする場合に指定するオプション

-XX:+UseParallelGC

図2はパラレルGC使用時に利用可能となる「Javaヒープのチューニング用オプション」です。

- 192 -

なお、パラレルGC使用時は、JavaヒープのNew世代領域およびOld世代領域の大きさに関する値が自動的に調整およ

び適化されるため、通常、New世代領域の大きさやNew世代領域とOld世代領域の大きさのバランスをチューニング

するためのオプションを使用する必要はありません。

図2 Javaヒープチューニング用オプション（パラレルGC使用時）

-Xms-Xmx-XX:NewSize (*)-XX:MaxNewSize (*)-XX:NewRatio (*)-XX:PermSize-XX:MaxPermSize

(*) New世代領域の大きさや、New世代領域とOld世代領域の大きさのバランスをチューニングするためのオプションで

す。

GC処理用スレッド数

パラレルGCを使用した場合は、実行するハードウェアに搭載しているCPU数に依存した数のGC処理用スレッドがJavaプロセス内に作成されます。そのため、GC処理用スレッドの数分だけ、スタック域などのスレッド用のメモリ領域が必要と

なります。

Javaプロセス内でのメモリ量を抑えるためなど、GC処理用スレッドの数を調整する場合には、図3のオプションでGC処

理用スレッドの数を指定することにより、GC処理用スレッドの数を調整することができます。

なおGC処理用スレッドの数を抑制した分だけGC処理における性能がおちる場合もありますので、このオプションを用

いる場合には、十分な性能確認を実施してください。また、一般的に、CPU数以上の数のGC処理用スレッドを作成して

も、GC処理における性能向上にはつながりません。

図3 パラレルGCで使用するGC処理用スレッドの数を指定するオプション

-XX:ParallelGCThreads=New世代領域GC用スレッドの数

New世代領域用GC処理を行なうGCスレッドの数を指定します。

「0」が指定された場合は、デフォルト値となります。

デフォルト値は以下のとおりです。

- 実行するハードウェアに搭載しているCPU数が7以下の場合 = CPU数分

- 実行するハードウェアに搭載しているCPU数が8以上の場合 = 8

メモリ割り当てプールの省略値自動調整機能

FJVMのパラレルGCでは、JDK/JRE 6、7の機能であるエルゴノミクス機能によるメモリ割り当てプールの初期値(-Xms)および大値(-Xmx)の省略値自動調整機能（マシンの物理メモリ量などに応じて、-Xmsおよび-Xmxの各オプションに

対する省略値を自動的に決定する機能）を無効にしています。

JDK/JRE 6、7のFJVMで、エルゴノミクス機能によるメモリ割り当てプールの省略値自動調整機能を有効にする場合

は、図4のオプションを指定してください。

ただし、このオプション指定は、システムのメモリ資源不足の要因となる場合があるため、システム内に複数のJavaプロ

セスを起動、実行する場合には使用しないでください。

図4 JDK/JRE 6、7でメモリ割り当てプールの省略値自動調整機能を有効にするオプション

-XX:+AutomaticallyJavaHeapSizeSetting

- 193 -

メモリ領域不足事象の検出機能

FJVMのパラレルGCでは、JDK/JRE 6、7の機能であるエルゴノミクス機能によるメモリ領域不足事象の検出機能（図5の各オプション指定値による条件が同時に成立した場合に、メモリ領域不足事象（java.lang.OutOfMemoryError）として

検出する機能）を無効にしています。

JDK/JRE 6、7のFJVMでエルゴノミクス機能によるメモリ領域不足事象検出機能を有効にする場合は、図6のオプション

を指定してください。

ただし、このオプション指定で検出されるメモリ領域不足事象は、Javaヒープの使用量だけではなく、メモリ領域不足事

象検出用オプションで指定された値、およびガーベジコレクション処理の動作状況から得られた統計情報などを元に決

定されるため、Javaヒープの使用量が不足していない状態であっても、メモリ領域不足事象が検出される場合があります

ので注意してください。

図5 メモリ領域不足事象検出条件

-XX:GCTimeLimit=GC処理に要する時間の上限値 (デフォルトは98)Javaアプリケーションの合計処理時間に対して、GC処理に要した時間の上限値をパーセント

単位(%)で指定します。

指定された上限値を超えた場合、検出条件の一方が成立します。

-XX:GCHeapFreeLimit=GC処理後のJavaヒープ量の空きスペースの下限値 (デフォルトは2)メモリ割り当てプールの大値に対する、GC処理後のJavaヒープ量の空きスペースの下限値

をパーセント単位(%)で指定します。

指定された下限値を下回った場合、検出条件の一方が成立します。

図6 JDK/JRE 6、7でメモリ領域不足事象検出を有効にするオプション

-XX:+UseGCOverheadLimit

パラレルGC処理のエルゴノミクス機能およびメモリ割り当てプールの小使用量保証機能

FJVMでパラレルGCを使用した場合、JDK/JRE 6、7の機能であるパラレルGC処理のエルゴノミクス機能（メモリ割り当

てプール内の各世代領域サイズの動的変更機能）により、Javaアプリケーションの実行状況や負荷／GC処理に掛かる

時間などの情報から、GC処理としての適動作状態になるように、メモリ割り当てプール内の各世代領域サイズが自動

的に調整・変更および適化されます。

その際、メモリ割り当てプールの使用量が-Xmsオプションで指定した値（メモリ割り当てプールの初期値）よりも小さくな

ることあります（-Xmsオプションで指定した値よりも下回るメモリ割り当てプールの使用量で、GC処理としての適動作状

態になることがあります）。

パラレルGCを使用してJavaアプリケーションを実行する際、メモリ割り当てプールの使用量についての操作を行なう場

合は、以下のオプションを指定してください。

メモリ割り当てプールの小使用量保証機能を操作するオプション

【-Xmsオプションで指定した値よりもメモリ割り当てプールの使用量を小さくしない場合】

-XX:+UseAdaptiveSizePolicyMinHeapSizeLimit

パラレルGC処理のエルゴノミクス機能動作時、-Xmsオプション指定値によるメモリ割り当てプールの小使用量保証

機能を有効にします。

Javaアプリケーション実行時に使用されるメモリ割り当てプールの大きさは，「-Xmsオプション指定値」から「-Xmxオプ

ション指定値」の範囲で変動します。

（-Xmsオプション指定値と-Xmxオプション指定値が等しい場合、使用中となるメモリ割り当てプールの大きさは変動し

ません。）

この状態は、JDK/JRE 6、7でパラレルGCを使用する場合のデフォルト状態です。

- 194 -

【-Xmsオプションで指定した値よりもメモリ割り当てプールの使用量を小さくして良い場合】

-XX:-UseAdaptiveSizePolicyMinHeapSizeLimit

パラレルGC処理のエルゴノミクス機能動作時、-Xmsオプション指定値によるメモリ割り当てプールの小使用量保証

機能を無効にします。

Javaアプリケーション実行時に使用されるメモリ割り当てプールの大きさは，「Java VMとしての下限値」から「-Xmxオプ

ション指定値」の範囲で変動します。

（-Xmsオプション指定値と-Xmxオプション指定値が等しい場合であっても、使用中となるメモリ割り当てプールの大きさ

は変動します。）

なお、Javaアプリケーションの実行時に使用されるメモリ割り当てプールの大きさが-Xmsオプション指定値よりも小さく

なった場合、Full GCの発生間隔が、Javaプロセス起動時近辺における発生間隔よりも短くなってしまう場合があります。

しかし、パラレルGC処理のエルゴノミクス機能は、GC処理に掛かる時間情報も考慮した上で、GC処理としての適動作

状態となるように調整しています(メモリ割り当てプールを縮小しても、Full GCに掛かる時間が少ない状態の場合に適

動作状態としています)。そのため、メモリ割り当てプールの縮小によりFull GCの発生間隔が短くなった場合でも、Javaアプリケーション実行時の性能に対する影響はほとんどありません。

なお、このオプションは、パラレルGCを動作させたJDK/JRE 5.0で実行していたアプリケーションを、パラレルGCを動作さ

せるJDK/JRE 6、7を用いて実行させる際、使用中となるメモリ割り当てプールの大きさに対する挙動の互換性を向上させ

る必要がある場合に使用します。

通常、このオプションを指定する必要はありません。

なおメモリ割り当てプールの小使用量保証機能の有効／無効に関わらず、Javaプロセス起動時に使用されるメモリ割

り当てプールの大きさは、-Xmsオプションで指定された値となります。

8.2.4 コンカレント・マーク・スイープGC付きパラレルGC（CMS付きパラレルGC）

New世代領域用GC制御を並列化して実行する機能、およびJavaアプリケーションと同時並列に動作するOld世代領

域・Permanent世代領域用GC制御「コンカレント・マーク・スイープGC(CMS-GC)機能」を追加して構成されたGC処理で

す。CMS-GC機能を追加されたパラレルGC制御であることから、このGCをCMS付きパラレルGCと呼ぶ場合もあります。

図1のオプションは、CMS付きパラレルGCによるGC制御を有効にするオプションです。

CMS付きパラレルGC

CMS付きパラレルGCによるGC制御は、以下のエディションに搭載されたJDK/JRE にだけ提供しています。


CMS-GC

CMS-GCは、JavaアプリケーションがFull GCによって停止されることにより影響を受ける「アプリケーションの応答性能の

平準化」を改善するために実行される「Old世代領域内およびPermanent世代領域内の不要オブジェクト回収用のGC機

構」です。

Javaアプリケーションを停止させて実行するFull GCに対し、CMS-GCはJavaアプリケーションと同時並列に動作し、Old世代領域内およびPermanent世代領域内の不要オブジェクトを回収します。CMS-GCの実行により、Old世代領域(New世代領域にあるオブジェクトの移動先や巨大オブジェクトの生成先となる領域) およびPermanent世代領域(Javaのクラス、

メソッドや定数などの格納先となる領域)の空きを、Javaアプリケーション動作と並行して増加させることができるため、FullGCの発生を抑えることができます。これにより、JavaアプリケーションはFull GCにより停止される影響を受けにくくなり、応

答性能平準化の改善が期待できます。

なおCMS-GC動作中は、NewGC処理/Full GC処理の実行開始が遅延する場合があります。そして遅延期間中は、Javaアプリケーションとしての動作も停止します。そのため、ガーベジコレクション処理の結果ログ内のNewGC処理/Full GC処理に対して出力されたGC処理実行時間よりも長い間、Javaアプリケーションとしての動作が停止している場合がありま

す。

- 195 -

図1 JDK/JRE 6、７でCMS付きパラレルGCを有効に場合に指定するオプション

-XX:UseFJcmsGC=タイプ

タイプとして以下の値が指定できます

[CMS-GCによる不要オブジェクトの回収対象を「Old世代領域内」とする場合]

type0type1type2

[CMS-GCによる不要オブジェクトの回収対象を「Old世代領域内およびPermanent世代領域

内」とする場合]

type0ptype1ptype2p

CMS-GCによる不要オブジェクトの回収対象を、Old世代領域内だけでなくPermanent世代領域内にまで拡大した場合、

CMS-GCとしての処理対象域が増加することになるため、CMS-GC完了までの実行時間増加に繋がり易くなります。

その結果、実行するアプリケーションや実行環境によっては、CMS-GCによる回収処理が間に合わなくなり、FullGCの

発生に繋がる場合もありえます。

そのため、回収対象が「Old世代領域内」で正常動作していた環境において、回収対象を「Old世代領域内および

Permanent世代領域内」にまで拡大する場合は、再度のチューニング作業が必要となります．

-XX:UseFJcmsGC=type0またはtype0pが指定された場合

図2は-XX:UseFJcmsGC=type0およびtype0p指定時に利用可能となる「Javaヒープのチューニング用オプション」です。

図2に示すチューニング用オプションを用いて、利用者が細かくチューニング作業を行なうことが可能なCMS付きパラレ

ルGCを使用する場合に指定します。

図2 Javaヒープチューニング用オプション（-XX:UseFJcmsGC=type0およびtype0p指定時）

-Xms-Xmx-XX:NewSize-XX:MaxNewSize-XX:SurvivorRatio-XX:TargetSurvivorRatio-XX:PermSize-XX:MaxPermSize


New世代領域用GCでのオブジェクト回収を重視した調整が成されたCMS付きパラレルGCを使用する場合に指定しま

す。

実行されるアプリケーションの特徴が「大半のオブジェクトが、少ない回数のNew世代領域用GCによって回収されるオ

ブジェクト」である場合に、CMS-GCによる応答性能平準化の改善効果が得やすい調整になっています。

Javaヒープのチューニングを行なう場合は、まず-Xms/-Xmxおよび-XX:PermSize/-XX:MaxPermSizeの各オプションによ

り、メモリ割り当てプールおよびPermanent世代領域の大きさを調整します。そして必要に応じて、-XX:NewSize/-XX:MaxNewSizeの各オプションでNew世代領域の大きさを調整します。

なおNew世代領域サイズとして、メモリ割り当てプール大サイズ未満の値を指定できます。ただしNew世代領域サイ

ズを大きくしすぎると、Full GCが発生しやすくなってしまうので注意が必要です。



- 196 -

-Xms-Xmx-XX:NewSize-XX:MaxNewSize-XX:PermSize-XX:MaxPermSize


CMS-GCでのオブジェクト回収を重視した調整が成されたCMS付きパラレルGCを使用する場合に指定します。

実行されるアプリケーションの特徴が「大半のオブジェクトが、何回かのGCを経てから回収される(長期間常駐せず、あ

る程度の短期間で回収される)オブジェクト」である場合に、CMS-GCによる応答性能平準化の改善効果が得やすい調

整になっています。

Javaヒープのチューニングを行なう場合は、まず-Xms/-Xmxおよび-XX:PermSize/-XX:MaxPermSizeの各オプションに

より、メモリ割り当てプールおよびPermanent世代領域の大きさを調整します。そして必要に応じて、-XX:NewSize/-XX:MaxNewSizeの各オプションでNew世代領域の大きさを調整します。

なおNew世代領域サイズとして、メモリ割り当てプール大サイズ未満の値を指定できます。ただしNew世代領域サイ

ズを大きくしすぎると、Full GCが発生しやすくなってしまうので注意が必要です。



-Xms-Xmx-XX:NewSize-XX:MaxNewSize-XX:PermSize-XX:MaxPermSize

GC処理用スレッド数

CMS付きパラレルGCを使用した場合は、実行するハードウェアに搭載しているCPU数に依存した数のGC処理用スレッ

ドがJavaプロセス内に作成されます。そのため、GC処理用スレッドの数分だけ、スタック域などのスレッド用のメモリ領域

が必要となります。

Javaプロセス内でのメモリ量を抑えるためなど、GC処理用スレッドの数を調整する場合には、図5のオプションでGC処

理用スレッドの数を指定することにより、GC処理用スレッドの数を調整することができます。

なおGC処理用スレッドの数を抑制した分だけGC処理における性能がおちる場合もありますので、このオプションを用

いる場合には、十分な性能確認を実施してください。また、一般的に、CPU数以上の数のGC処理用スレッドを作成して

も、GC処理における性能向上にはつながりません。

図5 CMS付きパラレルGCで使用するGC処理用スレッドの数を指定するオプション

-XX:ParallelGCThreads=New世代領域GC用スレッドの数

New世代領域用GC処理を行なうGCスレッドの数を指定します。

小値は「2」です。

「0」または「1」が指定された場合は、デフォルト値となります。

デフォルト値は以下のとおりです。

- 実行するハードウェアに搭載しているCPU数が1の場合 = 2- 実行するハードウェアに搭載しているCPU数が2以上7以下の場合 = CPU数分

- 実行するハードウェアに搭載しているCPU数が8以上の場合 = 8

CMS-GC処理用スレッド数

- 197 -

CMS付きパラレルGCを使用した場合は、以下のCMS-GC処理用スレッドがJavaプロセス内に作成されます。そのため、

CMS-GC処理用スレッドの数分だけ、スタック域などのスレッド用のメモリ領域が必要となります。

・ CMSスレッド (必ず1つ作成されます)

・コンカレント・マーク処理専用スレッド

CMSスレッドの他、CMS-GC処理の中のコンカレント・マーク処理を複数スレッドで並列化して実行するために、コンカ

レント・マーク処理専用スレッドを追加で作成することができます。図6のオプションでCMS-GC処理用スレッドの数を指定

することにより、CMS-GC処理用スレッドの数を調整することができます。

なお一般的に、CPU数以上の数のCMS-GC処理用スレッドを作成しても、CMS-GC処理における性能向上にはつなが

りません。

図6 CMS付きパラレルGCで使用するCMS-GC処理用スレッドの数を指定するオプション

-XX:ConcGCThreads=CMS-GC処理用スレッドの数

コンカレント・マーク処理専用スレッドの数を指定します。

小値は「2」です．

オプションの指定がない場合、または「1」が指定された場合は、CMSスレッドだけ生成されます。

「0」が指定された場合は、自動的に以下の値が設定されます。

（実行するハードウェアに搭載しているCPU数の1/4(端数切り上げ)をAとした場合）

- Aが1の場合 = 0(CMSスレッドだけ生成されます)- Aが2以上7以下の場合 = A- Aが8以上の場合 = 8なお指定値および自動設定値いずれの場合も、「-XX:ParallelGCThreads」の値よりも大きい

場合は、「-XX:ParallelGCThreads」の値となります。

8.2.5 オブジェクト参照の圧縮機能

Javaアプリケーションを64ビットモードのJDK/JRE上で動作させる場合、通常のC/C++アプリケーションの場合と同様、実

行モード上の制約から、Javaヒープに格納されるオブジェクト参照（ポインタ情報）で必要となる領域は「64ビット表現/8バ

イト域」が管理単位となります。

そのため64ビットモードのJDK/JRE上でJavaアプリケーションを動作させる場合、32ビットモードのJDK/JRE上で動作さ

せる場合に対して、1.5～2倍のJavaヒープ量が必要となります。

しかし64ビットモードで実行されるJDK/JRE 6、7搭載のFJVMの場合は、Javaヒープの大きさ（メモリ割り当てプールと

Permanent世代領域の大きさの合計）が32GB未満の場合に限り、オブジェクト参照で必要となる領域を「32ビット表現/4バイト域」に圧縮して管理する機能「64ビットモード実行時におけるオブジェクト参照圧縮機能」により、当該機能のない

64ビットモードで実行されるJDK/JREよりも少ないJavaヒープ量でJavaアプリケーションが実行できます。

1オブジェクト参照当たりで必要となるJavaヒープの領域が減るため、たとえば極端な例ですが、従来はある大きさに100個のオブジェクト参照を格納できていた場合、当該機能により200個のオブジェクト参照がJavaヒープ上に格納できるよう

になります。つまり当該機能がないもしくは使用しない場合に必要となるJavaヒープ量を、当該機構を用いた場合に適用

した場合、相対的により大きなJavaヒープ値を指定したことと等価となります。その結果、ガーベジコレクション処理の発行

回数が減り、アプリケーション実行性能の向上が期待できます。

オブジェクト参照圧縮機能の無効化

本来「64ビット表現/8バイト域」が必要なメモリ域を「32ビット表現/4バイト域」に圧縮して管理するため、オブジェクト参照

使用時には、圧縮した情報を「64ビット表現/8バイト域」に展開する必要があります。その圧縮／展開処理は従来よりも余

分なCPU消費に繋がるため、Javaアプリケーションとしての実行性能が落ちる可能性が考えられます。

64ビットモードで実行されるJDK/JRE 6、7搭載のFJVMの場合は、デフォルト状態でオブジェクト参照圧縮機能が有効

になっています。そのため、Javaアプリケーションとしての実行性能が問題となった場合は、図1のオプションを指定する

ことで、FJVMのオブジェクト参照圧縮機能を無効にすることができます。

図1 64ビットモードで実行されるFJVMのオブジェクト参照圧縮機能を無効にするオプション

-XX:-UseCompressedOops

- 198 -

注) 64ビットモードで実行されるJDK/JRE 6、7の場合に指定できます。

8.2.6 ガーベジコレクションのログ出力

ガーベジコレクション(GC)のログを採取する場合は、図1のオプションを指定します。本オプションの指定により、GCが

発生するたびに、GC処理の結果ログが標準出力へ1行ずつ出力されます。

図1 GC処理の結果ログを出力するオプション

-verbose:gc

出力フォーマットを図2、出力例を図3に示します。

図2 GCログの出力フォーマット

[GCの種類 GC前のヒープ使用量->GC後のヒープの使用量(ヒープのサイズ), GCの処理時

間]

GCの種類が“GC”の場合はマイナーGC(またはNewGC処理)で、“FullGC”の場合はFullGCであることを示します。

なお“Javaヒープの中のメモリ割り当てプール”を“ヒープ”と略記しています。

CMS付きパラレルGCを使用している場合は、以下の出力フォーマットのGCログもあります。

[GC ヒープ使用量(ヒープのサイズ), マーク処理時間]

このフォーマットで出力された場合は、CMS-GC処理のinitialマーク処理またはfinalマーク処理が実行されたことを示し

ます。

なお“Javaヒープの中のメモリ割り当てプール”を“ヒープ”と略記しています。

図3 GCログの出力例

[GC 80229K->31691K(259776K), 0.4795163 secs][FullGC 57654K->4623K(259776K), 0.3844278 secs]

なおFJVMでは、GC処理の結果ログ出力機能の強化を行っています。

より詳細なGC処理の結果ログ情報を得る場合には、当該機能を使用してください。詳細は、“8.2.6.1 ガーベジコレクショ

ン処理の結果ログ出力機能の強化”を参照してください。

New世代領域の使われ方







そのため、ガーベジコレクションのログ出力において、メモリ割り当てプールやNew世代領域に空きがあるように見える

場合であっても、実際には空きがない場合があります（空きがあるように見える場合であっても、その差は、NewGC処理

用の作業域的な役割で使用済となっている場合があります）。

ログ出力量の増加

本オプションの指定により、ログ出力が増大します。

本オプションを指定する場合は、ログ出力量についての注意が必要です。

- 199 -

クラスのアンロード情報

Javaアプリケーションがクラスのアンローディング処理を行っていた場合に、FullGC処理中に該当するクラスのアンロー

ド情報”[Unloading class アンロードされたクラス名]”を結果ログ出力の途中に挿入したい場合は、図4のオプションを指

定してください。

図4 GC処理の結果ログに対してクラスのアンロード情報を出力するオプション

-XX:+ClassUnloadingInfo

GC処理結果ログの格納先ファイルの指定

図5のオプションを指定すると、GC処理の結果ログおよびクラスのインスタンス情報を、標準出力ではなく、指定したファ

イルへ出力先を切り換えることができます。

なお、Interstage Application Server配下でJavaアプリケーションを実行する際に図5のオプションを指定した場合、以下

の問題が発生します。

・図5のオプションによるファイル出力処理には、ログローテーションなどの世代管理機能はありません。何らかの理由

でJavaプロセスが自動的に再起動した場合、格納先として同じファイルが用いられることになるため、再起動後のGC処理の結果ログで再起動前の結果ログが上書きされ、ログ情報として使えなくなります。

・ Javaアプリケーションを複数のプロセスで多重動作させる場合、同一のオプション定義で複数のプロセスが動作しま

す。そのため、複数のプロセスから同じファイルに対してGC処理の結果ログを書き込むことになり、ログ情報として使

えなくなります。

・ Interstage Application Server配下でJavaアプリケーションを実行する際のログの出力先は、Interstage ApplicationServerとしての制御により、出力先ファイルが管理されています。図5のオプション指定でGC処理の結果ログが別の

ファイルとなった場合、エラー発生時に、他のエラー情報とGC処理の結果ログが分離することになるため、エラーの

解析が難しくなる場合があります。

そのため、Interstage Application Server配下でJavaアプリケーションを実行する場合には、図5のオプションを指定しな

いでください。

図5のオプションは、Interstage Application Serverとは関係しない単独のJavaアプリケーションを実行する場合に、必要

に応じて指定してください。

図5 GC処理の結果ログの格納先ファイルを指定するオプション

-Xloggc:GC処理の結果ログの格納先ファイル名

注1) このオプションを指定すると、自動的に“-verbose:gc”オプションも指定したと見做されます。そのため、“-verbose:gc”オプションの指定がない場合でも、GC処理の結果ログが出力され、また、ガーベジコレクション処理の結果ログ出力機能

の強化を使用することもできます。

なお、“-Xloggc”オプション指定により出力されたGC処理の結果ログの先頭には、「Java VMが起動されてからの経過時

間(秒)」が「GC処理の実行開始時間」として自動的に付加されます（以下の形式で出力されます）。

GC処理の実行開始時間: GC処理の結果ログ(図2の出力フォーマットと同じ)

「GC処理の実行開始時間」のフォーマットは変更できません。

（ガーベジコレクション処理の結果ログ出力機能の強化も使用して出力されたGC処理の結果ログの場合は、「GC処理の

実行開始時間」のフォーマットを、ログ出力における「8.5.7 ログ出力における時間情報のフォーマット指定機能」により指

定できます。）

注2) 格納先ファイル名の指定には、絶対パスや相対パスのディレクトリ名を付加した形式も可能です。

注3) 格納先ファイル名の中にあるディレクトリが存在しないなど、何らかの理由で指定された格納先ファイルにアクセス

できなかった場合、GC処理の結果ログは、指定された格納先ファイルではなく、従来通り、標準出力へ出力されます。

- 200 -

8.2.6.1 ガーベジコレクション処理の結果ログ出力機能の強化

FJVMでは、“-verbose:gc”オプション指定時に出力されるガーベジコレクション(GC)処理の結果ログを、より詳細に出

力する「ガーベジコレクション処理の結果ログ出力機能の強化」を行っています。

“-verbose:gc”オプションを指定してGC処理の結果ログを出力する際、図1のオプションを追加指定することにより、GC処理の結果ログとして出力される情報が、図2から図5に示す形式に拡張されます。また、図6から図8に出力例を示しま

す。

図1 GC処理の結果ログとして出力される情報を拡張するオプション

-XX:+UseFJverbose

図2 GC処理の結果ログとして出力される情報の拡張形式

$1: [$2, [$3 : $4->$5($6)], [$7 : $8->$9($10)] $11->$12($13), [$14 : $15->$16($17)], $18 secs]

図2の各要素について、以下で説明します。

$1: GC処理の実行開始時間(ログ出力時の時間)

GC処理の実行開始時間(ログ出力時の時間)を示します。

ログ出力時の時間のフォーマットは、ログ出力における「8.5.7 ログ出力における時間情報のフォーマット指定機能」によ

り指定できます。

デフォルトは、「Java VMが起動されてからの経過時間(秒)」です。

$2: GC種別

実行したGC処理の種別を以下の名称で示します。

・ GCNew世代領域を対象とするGC処理(NewGC処理またはマイナーGC処理)における結果情報です。

・ Full GCJavaヒープ域全体(メモリ割り当てプール(New世代領域、Old世代領域)およびPermanent世代領域)を対象とするGC処理(FullGC処理)における結果情報です。

・ Full GC*使用されているGC処理がシリアルGCまたはCMS付きパラレルGCの場合で、かつ、直前に実行されたNewGC処理

では十分な空き領域が確保できず、そのNewGC処理に続けて実行されたFullGC処理における結果情報です("FullGC"の後に"*"の付く表示になります)。なおこの名称は“-verbose:gc”オプションだけを指定した場合には出力されません(単に"Full GC"として出力されま

す)。

・ CMS initial-markOld世代領域を対象とするCMS-GC処理のうち、initialマーク処理における結果情報です。

CMS-GCでは、不要オブジェクトを検出するために行なう処理(initialマーク処理)を実行する際、極わずかな時間だ

けJavaアプリケーションを停止させます。

注)不要オブジェクトの検出処理だけであるため、GC処理開始前後での各世代領域におけるオブジェクト量に変化

はありません。

・ CMS remarkOld世代領域を対象とするCMS-GC処理のうち、finalマーク処理における結果情報です。

CMS-GCでは、不要オブジェクトを検出するために行なう処理(finalマーク処理)を実行する際、極わずかな時間だけ

Javaアプリケーションを停止させます。

注)不要オブジェクトの検出処理だけであるため、GC処理開始前後での各世代領域におけるオブジェクト量に変化

はありません。

$3: New世代領域の識別名

New世代領域の識別名を示します。

使用されているGC処理の違いにより、以下の識別名が出力されます。

・ DefNew: シリアルGCの場合

- 201 -

・ PSYoungGen: パラレルGCの場合

・ ParNew: CMS付きパラレルGCの場合

$4: GC処理前のオブジェクト量(New世代領域)

GC処理実行前のNew世代領域に存在したオブジェクトの総量(バイト)です。

$5: GC処理後のオブジェクト量(New世代領域)

GC処理実行後のNew世代領域に存在するオブジェクトの総量(バイト)です。

$6: New世代領域の大きさ

New世代領域の大きさ(バイト)です。

注)使用されているGC処理がシリアルGC、パラレルGCまたはCMS付きパラレルGCの場合は、この大きさに「to space」領

域の大きさが含まれません。

（シリアルGC、パラレルGCまたはCMS付きパラレルGCの場合、GC処理はNew世代領域を「eden space」、「from space」

および「to space」の3つの内部領域に細分割して制御しています。）

$7: Old世代領域の識別名

Old世代領域の識別名を示します。


・ Tenured: シリアルGCの場合

・ PSOldGen: パラレルGCの場合

・ CMS: CMS付きパラレルGCの場合

$8: GC処理前のオブジェクト量(Old世代領域)

GC処理実行前のOld世代領域に存在したオブジェクトの総量(バイト)です。

$9: GC処理後のオブジェクト量(Old世代領域)

GC処理実行後のOld世代領域に存在するオブジェクトの総量(バイト)です。

$10: Old世代領域の大きさ

Old世代領域の大きさ(バイト)です。

$11: GC処理前のオブジェクト量(メモリ割り当てプール)

GC処理実行前のメモリ割り当てプールに存在したオブジェクトの総量(バイト)です。

$4+$8の値です。

$12: GC処理後のオブジェクト量(メモリ割り当てプール)

GC処理実行後のメモリ割り当てプールに存在するオブジェクトの総量(バイト)です。

$5+$9の値です。

$13: メモリ割り当てプールの大きさ

メモリ割り当てプールの大きさ(バイト)です。

$6+$10の値です。

注)使用されているGC処理がシリアルGC、パラレルGCまたはCMS付きパラレルGCの場合は、この大きさにNew世代領

域の「to space」領域の大きさが含まれません。

（シリアルGC、パラレルGCまたはCMS付きパラレルGCの場合、GC処理はNew世代領域を「eden space」、「from space」

および「to space」の3つの内部領域に細分割して制御しています。）

$14: Permanent世代領域の識別名

Permanent世代領域の識別名です。


・ Perm: シリアルGCの場合

・ PSPermGen: パラレルGCの場合

・ CMS Perm: CMS付きパラレルGCの場合

- 202 -

$15: GC処理前のオブジェクト量(Permanent世代領域)

GC処理実行前のPermanent世代領域に存在したオブジェクトの総量(バイト)です。

$16: GC処理後のオブジェクト量(Permanent世代領域)

GC処理実行後のPermanent世代領域に存在するオブジェクトの総量(バイト)です。

$17: Permanent世代領域の大きさ

Permanent世代領域の大きさ(バイト)です。

$18: GC処理実行時間

GC処理実行に要した時間(秒)です。

注)GC処理は、Javaアプリケーションとしての動作を停止させて実行されます。

$2、$11、$12、$13、および$18に対する出力情報は、GC処理の結果ログ出力機能として“-verbose:gc”オプションだけ

を指定した際に出力される情報と対応します。

図3 GC処理の結果ログとして出力される情報の拡張形式(CMS-GCの開始)

$1: CMS start


$1: CMS-GC処理の実行開始時間(ログ出力時の時間)

CMS-GC処理の実行開始時間(ログ出力時の時間)を示します。




図4 GC処理の結果ログとして出力される情報の拡張形式(FullGC発生によるCMS-GCの終了要求)

$1: CMS stop-req


$1: CMS-GC処理の終了要求時点(ログ出力時の時間)

Full GC要求発生時にCMS-GC処理が実行中であった場合、CMS-GC処理の終了要求時点(ログ出力時の時間)を示し

ます。




注)CMS-GC処理が動作している中にJavaヒープ不足やjava.lang.System.gc()実行などによりFull GC要求が発生し

た場合、Full GC処理は、実行中のCMS-GC処理の終了を待ってから開始されます。その際、CMS-GCが処理している

データの整合性を維持させるため、CMS-GC処理の終了は強制的な打ち切り終了ではなく、CMS-GC内で打ち切り可能

な処理まで完了させてからの終了になります。そのため、CMS-GC処理が実行中であった場合、Full GC処理要求の発

生から実際にFull GC処理が開始されるまでに、ある程度の時間差が生じる可能性があります。

なおCMS-GC処理の終了要求時点からCMS-GC処理の実行が終了するまで、Javaアプリケーションとしての動作は停止

します。そのため、CMS-GC処理の終了要求時点からFull GC処理の実行完了までが、この出力があった場合のFull GC処理によるJavaアプリケーション動作の実際の停止期間となります。

図5 GC処理の結果ログとして出力される情報の拡張形式(CMS-GCの終了)

パターン1：

CMS-GCの対象が「Old世代領域内」の場合

$1: CMS stop($2), [CMS : $3->$4($5)], $9 secs

- 203 -

CMS-GCの対象が「Old世代領域内およびPermanent世代領域内」の場合

$1: CMS stop($2), [CMS : $3->$4($5)], [CMS Perm : $6->$7($8)], $9 secs

パターン2：

$1: CMS stop($2), $9 secs


$1: CMS-GC処理の実行終了時間(ログ出力時の時間)

CMS-GC処理の実行終了時間(ログ出力時の時間)を示します。




$2: 終了コード

CMS-GC処理の実行結果に対する終了コードを示します。

終了コードの違いにより、情報の出力形式パターンが異なります。

終了コードの種類および意味は以下のとおりです。

・ 00: CMS-GC処理が終了しました。

Old世代領域内またはOld世代領域内およびPermanent世代領域内で検出済の不要オブジェクトは回収しました。

パターン1の出力形式で情報が出力されます。

・ 10: Javaヒープ不足によるFull GC要求があったため、実行中のCMS-GC処理を終了しました。



・ 20: java.lang.System.gc()などの外部要因によるFull GC要求があったため、実行中のCMS-GC処理を終了しました。



・ 11: Javaヒープ不足によるFull GC要求があったため、実行中のCMS-GC処理を終了しました。

Old世代領域内またはOld世代領域内およびPermanent世代領域内の不要オブジェクトは回収していません。


・ 21: java.lang.System.gc()などの外部要因によるFull GC要求があったため、実行中のCMS-GC処理を終了しました。

Old世代領域内またはOld世代領域内およびPermanent世代領域内の不要オブジェクトを回収していません。


$3: CMS-GC処理前のオブジェクト量(Old世代領域)

CMS-GC処理実行前のOld世代領域に存在したオブジェクトの総量(バイト)です。

通常はCMS-GC処理のfinalマーク処理実行時のOld世代領域に存在したオブジェクトの総量と等しくなります。

finalマーク処理実行時のOld世代領域に存在したオブジェクトの総量と等しくない場合は、CMS-GCによる不要オブジェ

クトの回収処理前にNew世代領域用GCが実行された、またはJavaアプリケーションの実行によりOld世代領域にオブジェ

クトが割り当てられたことを示します。

$4: CMS-GC処理後のオブジェクト量(Old世代領域)

CMS-GC処理実行後のOld世代領域に存在するオブジェクトの総量(バイト)です。

$5: Old世代領域の大きさ

Old世代領域の大きさ(バイト)です。

$6: CMS-GC処理前のオブジェクト量(Permanent世代領域)

CMS-GC処理実行前のPermanent世代領域に存在したオブジェクトの総量(バイト)です。

通常はfinalマーク実行時のPermanent世代領域に存在したオブジェクトの総量と等しくなります。

finalマーク処理実行時のPermanent世代領域に存在したオブジェクトの総量と等しくない場合は、CMS-GCによる不要オ

- 204 -

ブジェクトの回収処理前に、Javaアプリケーションの実行によりPermanent世代領域にオブジェクトが割り当てられたことを

示します。

$7: CMS-GC処理後のオブジェクト量(Permanent世代領域)

CMS-GC処理実行後のPermanent世代領域に存在するオブジェクトの総量(バイト)です。

$8: Permanent世代領域の大きさ

Permanent世代領域の大きさ(バイト)です。

$9: CMS-GC処理実行時間

CMS-GC処理実行に要した時間(秒)です(CMS-GC開始からの経過時間です)。

有効なGC処理

このオプション指定により出力形式が拡張されるのは、使用するGC処理が以下の場合です。

・シリアルGC

・パラレルGC

・ CMS付きパラレルGC

ログ出力量の増加

本オプションの指定により、ログ出力が増大します。

本オプションを指定する場合は、ログ出力量についての注意が必要です。

■ ログの見方

図6から図8に、GC処理の結果ログとして出力される情報の拡張形式の出力例を示します。

図6 GC処理の結果ログとして出力される情報の拡張形式の出力例

23.646: [Full GC, [PSYoungGen : 1584K->0K(5504K)], [PSOldGen : 57764K->26302K(58304K)] 59348K->26302K(63808K), [PSPermGen : 4655K->4655K(16384K)], 0.1353549 secs]

この出力情報から、以下のことが分かります。

・ Java VMが起動されてから23.646秒後にFullGC処理が実行された。

・使用されているGC処理はパラレルGCである。

・ GC処理後のNew世代領域の大きさは5504KBである。

・ GC処理により、New世代領域に存在するオブジェクト量は1584KBから0KBになった。

（不要オブジェクトが削除され、また必要に応じてOld世代領域へ生存オブジェクトが移動した）

・ GC処理後のOld世代領域の大きさは58304KBである。

・ GC処理により、Old世代領域に存在するオブジェクト量は57764KBから26302KBになった。

（不要オブジェクトが削除され、また必要に応じてNew世代領域から生存オブジェクトが移動してきた）

・ GC処理後のメモリ割り当てプールの大きさは63808KBである。

・ GC処理により、メモリ割り当てプールに存在するオブジェクト総量は59348KBから26302KBになった。

（不要オブジェクトが削除された）

・ GC処理後のPermanent世代領域の大きさは16384KBである。

・ GC処理により、Permanent世代領域に存在するオブジェクト量は変化していない。

・ GC処理に要した時間は0.1353549秒である。

図7 GC処理の結果ログとして出力される情報の拡張形式の出力例(CMS付きパラレルGCの場合-1)

- 205 -

150.207: CMS start150.208: [CMS initial-mark, [ParNew : 1863K->1863K(14784K)], [CMS : 53791K->53791K(65536K)] 55654K->55654K(80320K), [CMS Perm : 4664K->4664K(16384K)], 0.0030212 secs]150.351: [GC, [ParNew : 14782K->1598K(14784K)], [CMS : 53791K->57981K(65536K)] 68573K->59579K(80320K), [CMS Perm : 4664K->4664K(16384K)], 0.0328537 secs]150.466: [CMS remark, [ParNew : 8277K->8277K(14784K)], [CMS : 57981K->57981K(65536K)] 66258K->66258K(80320K), [CMS Perm : 4664K->4664K(16384K)], 0.0097905 secs]150.549: [GC, [ParNew : 14782K->1598K(14784K)], [CMS : 50163K->54371K(65536K)] 64946K->55969K(80320K), [CMS Perm : 4664K->4664K(16384K)], 0.0303271 secs]150.583: CMS stop(00), [CMS : 57981K->54200K(65536K)], 0.3753996 secs


・使用されているGC処理はCMS付きパラレルGC(CMS-GCの対象はOld世代領域)である。

・ Java VMが起動されてから150.207秒後にCMS-GC処理が開始され、150.583秒後に終了した。

・終了したCMS-GCにより不要オブジェクトが回収された。

・ CMS-GC処理後のOld世代領域の大きさは65536KBである。

・ CMS-GC処理により、Old世代領域に存在するオブジェクト量は57981KBから54200KBになった。

・ CMS-GC処理に要した時間は0.3753996秒である。

・ CMS-GC処理中にNew世代領域用GC処理が実行された。またその実行開始は、遅延している可能性がある。

図8 GC処理の結果ログとして出力される情報の拡張形式の出力例(CMS付きパラレルGCの場合-2)

137.803: CMS start137.804: [CMS initial-mark, [ParNew : 206690K->206690K(314560K)], [CMS : 655731K->655731K(699072K)]862421K->862421K(1013632K), [CMS Perm : 3892K->3892K(16384K)], 0.4101250 secs]139.069: [GC, [ParNew : 279616K->34943K(314560K)], [CMS : 655731K->673280K(699072K)] 935347K->708223K(1013632K), [CMS Perm : 3892K->3892K(16384K)], 0.2177910 secs]142.140: CMS stop-req142.501: CMS stop(11), 4.6984060 secs142.501: [Full GC, [ParNew : 314559K->0K(314560K)], [CMS : 673280K->657037K(699072K)] 987839K->657037K(1013632K), [CMS Perm : 3892K->3892K(16384K)], 1.8642510 secs]


・使用されているGC処理はCMS付きパラレルGC(CMS-GCの対象はOld世代領域)である。

・ Java VMが起動されてから137.803秒後にCMS-GC処理が開始され、142.501秒後に終了した。

・ Java VMが起動されてから142.140秒後にFullGC要求があり、そのため実行中のCMS-GCが終了した。

・終了したCMS-GCによる不要オブジェクト回収は実行されていない。

・ CMS-GC処理の終了要求時点(142.140)からCMS-GC処理の実行が終了(142.501)するまでの0.361秒、および142.501に実行開始したFullGCの実行時間1.8642510秒の合計2.225251秒の間、Javaアプリケーション動作が停止された。

8.3 動的コンパイル

本節では、動的コンパイルについて説明します。

C/C++やCOBOLなどで作られたプログラムを実行する場合は、各言語に対応したコンパイラによって、プログラムのソー

スコードを実行対象プラットフォーム上で動作可能な機械命令へ翻訳（後述の動的コンパイルとの対比で静的コンパイ

ルと呼ばれることがあります）し、事前にプラットフォーム依存の実行バイナリを作成する必要があります。

Javaで作られたプログラムを実行する場合は、javacコマンドによって、プログラムのソースコードをJava VMが解釈／実

行できる命令「バイトコード」へ変換し、事前にプラットフォーム非依存の実行バイナリである「クラスファイル」を作成する

必要があります。

- 206 -

Javaの実行環境であるJava VMが起動された後、Java VMは、実行対象プログラムであるクラスファイルを読み込み、ク

ラスファイルを以下の2つの方法を用いて実行します。

・インタプリタによるバイトコードの実行

Java VMのインタプリタは、クラスファイル内のバイトコードを1命令ずつ解釈して実行します。

機械命令の実行に比べ、実行性能が低速になります。

・動的コンパイルにより、バイトコードを機械命令に翻訳してから実行

Javaアプリケーションの実行中、Java VMは、クラスファイル内のJavaメソッドに対応するバイトコードを、実行対象プ

ラットフォーム上で動作可能な機械命令へ自動的に翻訳してから実行します。Javaアプリケーション実行中に自動的

に行われる翻訳処理であるため、その翻訳処理を動的コンパイルと呼びます。

インタプリタによるバイトコードの実行に比べ、高速に実行できます。

なお、動的コンパイル処理は、翻訳時における機械命令の適化処理で必要となる各Javaメソッドの実行頻度や呼

び出し関係などの情報を、Javaアプリケーション実行と同時に行われる各Javaメソッドに関するプロファイリング処理

の結果から得ます。そのため、プロファイリング処理によりある程度の情報量が得られるまで何度か再翻訳が繰り返

され、次第にJavaアプリケーションの実行状況に合った翻訳結果に適化されることで、機械命令部分の実行性能

が向上する傾向があります。

Java VMが行う動的コンパイル自体は、Javaアプリケーションの実行から見ると、オーバーヘッド部分になります。そのた

め、インタプリタによる実行性能(低速)、動的コンパイルによるオーバーヘッド、および動的コンパイル結果である機械命

令による実行性能(高速)の三者をバランス良く調整することで、Javaアプリケーション全体としての実行性能を良くする必

要があります。

Java VMは、実行頻度の高いJavaメソッドを優先的にコンパイルし、あまり使われることのないJavaメソッドはインタプリタ

実行のままにすることで、インタプリタ実行、動的コンパイル、および動的コンパイル結果である機械命令実行のバランス

を取り、Javaアプリケーション全体としての実行性能を良くする調整を行っています。

なお、実行対象となるJavaアプリケーション内で、各Javaメソッドの実行頻度がどの位になるのかについては、実際にJavaアプリケーションが実行されない限り分かりません。そのため、Java VMはJavaアプリケーション実行と同時に各Javaメソッ

ドに関するプロファイリング処理を行い、その結果を用いて動的コンパイルの対象となるJavaメソッドを決定しています。プ

ロファイリング処理によりある程度の情報量が得られるまで、すなわちJava VM起動直後はインタプリタ実行だけですが、

次第にインタプリタ実行と動的コンパイル結果による機械命令実行との混合動作になります。

FJVMでは、動的コンパイルに関する以下の機能を富士通版独自機能として実装しています。

なお、いずれの機能もFJVM固有機能です。

・コンパイラ異常発生時の自動リカバリ機能

・長時間コンパイル処理の検出機能

・動的コンパイル発生状況のログ出力機能

8.3.1 コンパイラ異常発生時の自動リカバリ機能

Java VMはJavaアプリケーションとして実行されるJavaメソッドに対して必要に応じて自動的にコンパイル処理を行いま

すが、コンパイル処理を行っている際にコンパイラ内で何らかの異常が発生すると、当該Javaメソッドに対するコンパイル

処理だけでなくJava VMとしての動作も異常状態として停止させてしまう場合があります。

FJVMでは、コンパイラ内で何らかの異常が発生した場合に自動的にリカバリ処理を行い、Java VMとしての動作を継

続させる機能を「コンパイラ異常発生時の自動リカバリ機能」として実装しています。

コンパイラ異常発生時の自動リカバリ機能はFJVM固有機能です。

なお、本機能によるリカバリ処理が行なわれた際にコンパイル対象となっていたJavaメソッドは、以降、コンパイル処理の

対象とはなりません。当該Javaメソッドについてはコンパイルされず、インタプリタモードのままJavaアプリケーションとして

の実行が継続されます。

- 207 -

また、本機能はFJVMの内部処理として動作する機能であるため、コンパイラ内で何らかの異常が発生してもリカバリ処

理が正常に行われた場合には、外部に対する通知などは何も行いません。リカバリ処理が正常に行われた場合でもコン

パイラ内で何らかの異常が発生したことを情報として受け取る場合には、図1のオプションを指定してください。

図1のオプションを指定した場合、リカバリ処理の情報が図2の形式で標準出力に出力されます。

図1 リカバリ処理実施後に通知を受け取るオプション

-XX:+PrintCompilerRecoveryMessage

図2 リカバリ処理実施後に通知される情報

CompilerRecovery: Information:The compilation was canceled for method method_nameReason for the cancellation: reason [code:c, addr:xxxxxxxx]

method_name: コンパイル処理で異常が発生した際にコンパイル対象となっていたJavaメ

ソッドの名前。

reason: コンパイル処理で発生した異常の原因情報。原因情報として以下の項目

があります。

・ assert:コンパイル処理で内部処理矛盾を検出した

・ error:コンパイル処理で何らかの誤りを検出した

・ stack overflow:コンパイル処理でスタックオーバーフローを検出した

c: 異常コード。

xxxxxxxx: コンパイル処理で異常が発生した際のアドレス。

8.3.2 長時間コンパイル処理の検出機能

Java VMはJavaアプリケーションとして実行されるJavaメソッドに対して必要に応じて自動的にコンパイル処理を行い、通

常は極短時間でその処理を完了します。

しかし、コンパイル処理自身や同じJavaプロセス内で動作させている他の処理の障害などによりCPU資源が占有され続

けてしまうと、数分を経過してもコンパイル処理が終了しない場合が考えられます。このような状態が継続すると、システ

ム全体に対して悪影響を与える可能性が考えられます。

このため、FJVMでは、各Javaメソッドのコンパイル処理に要している時間を監視し、コンパイル処理で必要と考えられる

程度の時間を経過してもコンパイル処理が終了していない場合には、Javaプロセス内の処理で何らかの問題が発生して

いると判断し、当該Javaプロセスを強制的に終了させる機能を「長時間コンパイル処理の検出機能」として実装していま

す。

コンパイラ異常発生時の自動リカバリ機能はFJVM固有機能です。

本機能は、図1のオプションでコンパイル処理に対する監視時間(コンパイル処理に要する時間の上限値)を指定した場

合に有効となります。ただし、オプション値として「0」を指定した場合には、本機能は有効となりません。

図1のオプションで指定された時間を超過してもコンパイル処理が終了していない場合、本機能はJavaプロセス内の処

理で何からの問題が発生していると判断し、当該Javaプロセスを強制的に終了させます。

図1 長時間コンパイル処理の検出機能を有効にするオプション

-XX:CompileTimeout=<nn>

- 208 -

<nn>には、本機能による異常有無の判断条件とされるコンパイル処理に要する時間の上限値(単位:秒)を指定します。

デフォルト値は「0」であり、本機能は無効となっています。

なお、本機能による時間監視の小単位は30秒であるため、その単位での時間誤差があります。

なお、本機能によってJavaプロセスを強制終了する場合、FJVMは図2のメッセージを標準出力に出力してから終了し

ます。また、本機能によるJavaプロセスの強制終了時にはコアダンプも出力されます。

図2 長時間コンパイル処理の検出機能によるJavaプロセス強制終了時の出力メッセージ

CompilerRecovery: Information: CompilerRecovery got the VM abortedbecause the compiler thread(nnnnnnnn) has not completed.(compiling method: method_name)

nnnnnnnn: コンパイラスレッドの内部識別子

method_name: 本機能によるチェックでJavaプロセス内に異常が検出された際にコンパイル対象となっていたJavaメソッド

の名前

長時間コンパイル処理の検出機能に対する注意事項

何らかの要因によりJavaプロセス内のコンパイル処理へCPU資源が十分に割り当てられず、コンパイル処理自体が進ん

でいない場合でも、コンパイル処理開始から-XX:CompileTimeoutオプションで指定された監視時間を超過した場合に

は、本機能による当該Javaプロセスの強制終了となります。

このため、当該Javaプロセスを実行するシステムのCPU負荷が高い場合には、コンパイル処理に対してCPU資源が十

分に割り当てられず、この結果として本機能による強制終了が発生する可能性が考えられます。

本機能による強制終了が発生した場合には、まず以下の事項を確認してください。

・当該Javaプロセスを実行しているシステムのCPU資源量は十分か。

・当該Javaプロセス以外の他のプロセスでCPU資源が占有されていないか。

・ “-XX:CompileTimeout=0”を指定した場合に本機能による強制終了が回避され、かつ、当該Javaプロセスが正常に

終了する、または未負荷時に正常なアイドル状態に遷移するか。

上記事項に合致する場合は、コンパイル処理に対してCPU資源が十分に割り当てられなかった結果として発生し

た強制終了と考えられます。

長時間コンパイル処理の検出機能を有効にしてこの状態が発生した場合には、“-XX:CompileTimeout”オプション

で指定する監視時間として、より大きな値に設定する形で調整してください。

長時間コンパイル処理の検出機能に対する監視メッセージの出力

図3のオプションを指定した場合、Javaメソッドのコンパイル処理において1分が経過すると、図4の形式で監視メッセー

ジが出力されます。

その後は、30秒経過するごとに同じ監視メッセージが出力されます。

なお、本機能による時間監視の小単位は30秒であるため、その単位での時間誤差があります。

図3 長時間コンパイル処理の検出機能の監視メッセージ出力を有効にするオプション

-XX:+PrintCompilerRecoveryMessage

図4 長時間コンパイル処理の検出機能が出力する監視メッセージ

CompilerRecovery: Information: The compiler thread(0xnnnnnnnn) might not return fromcompiling method method_name.

nnnnnnnn: コンパイラスレッドの内部識別子

method_name: 本機能によるチェックで検出された際にコンパイル対象となっていたJavaメソッドの名前

- 209 -

8.3.3 動的コンパイル発生状況のログ出力機能

Java VMは、Javaアプリケーションとして実行されるJavaメソッドに対して、必要に応じて自動的にコンパイル処理を行い

ます(動的コンパイル)。

FJVMでは、動的コンパイルの発生状況を出力する機能を「動的コンパイル発生状況のログ出力機能」として実装して

います。

動的コンパイル発生状況のログ出力機能では、以下の情報を出力します。

・コンパイラスレッドのCPU使用状況

コンパイラスレッド(動的コンパイルを行っているスレッド)が20個のJavaメソッドをコンパイルするごとに、コンパイルを

行うのに使用したCPU時間と経過時間を出力します。

経過時間に対してCPU時間の割合が高い場合には、Javaアプリケーションの実行性能に動的コンパイルが影響を与

えている可能性があります。

・動的コンパイル結果情報

どのJavaメソッドが、いつコンパイルされたかの情報を出力します。

Javaメソッドのコンパイルが、短い間に連続して発生している場合、Javaアプリケーションの実行性能に動的コンパイ

ルが影響を与えている可能性があります。

コンパイラスレッドのCPU使用状況を出力する場合は、図1のオプションを指定します。

コンパイラスレッドのCPU使用状況および動的コンパイル結果情報を出力する場合は、図2のオプションを指定します。

図1および図2のオプションの指定により、動的コンパイルが発生するたびに、その発生状況ログが標準出力へ、図3お

よび図4に示す形式で出力されます。

また、図5および図6に出力例を示します。

動的コンパイル発生状況のログ出力機能はFJVM固有機能です。

図1 コンパイラスレッドのCPU使用状況を出力するオプション

-XX:+PrintCompilationCPUTime

図2 コンパイラスレッドのCPU使用状況および動的コンパイル結果情報を出力するオプション

-XX:+FJPrintCompilation

図3 コンパイラスレッドのCPU使用状況の出力形式

$1: [$2: cpu=$3ms elapsed=$4ms $5]


$1: ログ出力時の時間

ログ出力時の時間を示します。




$2: コンパイラスレッド名

情報の出力対象となるコンパイラスレッドの名前を「CompilerThread数字」の形式で示します。

$3: CPU時間

$2のコンパイラスレッドが、20個のJavaメソッドのコンパイルを行うのに使用したCPU時間(ミリ秒)を示します。

- 210 -

なお、コンパイル対象となるJavaメソッドがネイティブメソッドだった場合は、コンパイル処理としての時間を必要としないた

め、当該メソッドに関する処理はCPU時間に含まれていません。

$4: 経過時間

$2のコンパイラスレッドが、20個のJavaメソッドのコンパイルを行うまでに経過した時間(ミリ秒)を示します。

$5: 通し番号

コンパイラスレッドごとの本情報の出力数を、通し番号で示します。

通し番号×20」の値が、そのコンパイラスレッドでコンパイルしたJavaメソッドの累計数になります。

図4 動的コンパイル結果情報の出力形式

$1: $2 $3 ($4 bytes) $5


$1: Javaメソッドのコンパイル要求発生時間(ログ出力時の時間)

Javaメソッドのコンパイル要求が発生した時間(ログ出力時の時間)を示します。




$2: 通し番号

コンパイル要求の数(コンパイル要求が発生したJavaメソッドの数)を通し番号で示します。

通し番号の後ろに「%」がない場合は、コンパイル対象のJavaメソッド全体をコンパイルする要求です。

通し番号の後ろに「%」がある場合は、コンパイル対象のJavaメソッドを部分的にコンパイルする要求です。

通し番号の後ろに「%」がない場合とある場合は、別の通し番号になります。

$3: Javaメソッド名

コンパイル要求が発生したJavaメソッドの名前を示します。

Javaメソッドを部分的にコンパイルする要求の場合($2に「%」の表示が含まれる場合)、Javaメソッド名の後に、Javaメソッド

(バイトコード)のどの部分からコンパイルの対象になっているかを示す情報「(@ 数字)」が付加されます。

$4: Javaメソッドのバイト数

コンパイル対象となったJavaメソッドの大きさ(バイトコード・サイズ)をバイト数で示します。

$5: 空白または(static)

コンパイル対象となったJavaメソッドが、コンパイル処理としての時間を必要としないネイティブメソッドだった場合、“(static)”と出力されます。

Javaメソッドが、ネイティブメソッドでない場合は、この位置に何も出力されません。

なお、動的コンパイル結果情報の出力対象Javaメソッドとしてネイティブメソッドを含むのは、JDK/JRE 7の場合です。JDK/JRE 6の場合は、動的コンパイル結果情報の出力対象Javaメソッドとしてネイティブメソッドを含みません。

図5 -XX:+PrintCompilationCPUTime指定時の出力例

0.586: [CompilerThread1: cpu=78.13ms elapsed=450.72ms 1]0.822: [CompilerThread0: cpu=437.50ms elapsed=686.32ms 1]1.312: [CompilerThread0: cpu=218.75ms elapsed=489.93ms 2]1.637: [CompilerThread1: cpu=546.88ms elapsed=1050.52ms 2]2.385: [CompilerThread0: cpu=296.88ms elapsed=1073.57ms 3]3.365: [CompilerThread0: cpu=140.63ms elapsed=979.67ms 4]3.557: [CompilerThread1: cpu=343.75ms elapsed=1919.97ms 3]4.096: [CompilerThread1: cpu=390.63ms elapsed=539.47ms 4]4.995: [CompilerThread1: cpu=140.63ms elapsed=898.45ms 5]

図6 -XX:+FJPrintCompilation指定時の出力例

- 211 -

0.074: 1 java.util.Properties$LineReader::readLine (383 bytes)0.102: 2 java.io.Win32FileSystem::normalize (143 bytes)0.107: 3 java.lang.String::hashCode (60 bytes)0.179: 4 sun.security.provider.SHA::implCompress (494 bytes)0.206: 5 sun.reflect.UTF8::utf8Length (81 bytes)0.229: 6 java.util.jar.Manifest$FastInputStream::readLine (167 bytes)0.232: 7 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (1814 bytes)0.244: 1% sun.text.NormalizerDataReader::read @ 38 (139 bytes)0.261: 8 java.math.BigInteger::mulAdd (82 bytes)(中略)0.742: [CompilerThread1: cpu=406.25ms elapsed=677.52ms 1]0.744: 40 java.lang.String::replace (142 bytes)

8.4 チューニング方法

チューニングのポイントとして、次があります。

・メモリ消費量と処理速度は深い関係にあり、メモリ消費量を抑制すれば処理速度が低下するのが一般的です。しか

し、JDK/JREにおいては、Javaヒープのサイズを必要以上に大きく確保した場合、New GCの発生頻度が少なくなる

反面、FullGCの処理時間が増大し、処理速度が低下するという特徴があります。

・プロセスに割り当てられたメモリ資源は限られています。JDK/JREにおいては、スタック、Javaヒープおよびネイティブ

モジュールの動作に必要な領域などの各セグメントがユーザ空間に割り当てられます。このため、あるセグメントの領

域を大きく確保すれば、その分だけ他のセグメントの領域が少なくなります。

上のポイントを踏まえた上で、JDK/JREのチューニングを行います。

8.4.1 Javaヒープのチューニング

本節では、Javaヒープのチューニング方法および、チューニングによる影響範囲を説明します。


Javaヒープの各領域のサイズは、“表8.4 Javaヒープに関するオプション”に示すオプションをJava起動時に指定すること

で設定ができます。

なお、メモリ割り当てプールのデフォルトの初期値および大値を、“表8.5 メモリ割り当てプールのデフォルトのサイズ”

に示します。

また、Permanent世代領域のデフォルトの初期値および大値を、“表8.6 Permanent世代領域のデフォルトのサイズ”

に示します。

また各オプションにおいて、“表8.4 Javaヒープに関するオプション”中に記載されていないデフォルト値を、“表8.7 Javaヒープに関するオプション(-XX:NewSize/-XX:NewRatio)のデフォルト値”に示します。

表8.4 Javaヒープに関するオプション

オプションオプションの機能 (注1)

-Xms メモリ割り当てプールの初期値を指定します。

たとえば、メモリ割り当てプールの初期値を128MBに設定す

る場合、”-Xms128m”と指定します。

本オプションのデフォルト値は“表8.5 メモリ割り当てプールの

デフォルトのサイズ”のとおりです。

なお、指定値が1MB未満の場合、または-XX:NewSizeオプ

ションの値(デフォルト値を含む)よりも小さな値の場合、初期

化エラーとなり、Javaプロセスは終了します。

-Xmx メモリ割り当てプールの大値を指定します。

たとえば、メモリ割り当てプールの大値を256MBに設定す

る場合、”-Xmx256m”と指定します。

(実際に使用される値は、ページサイズなどのシステム情報を

元に、Java VMによる制御が適となるように調整された値

- 212 -


「調整値」となるため、指定された値と若干異なる場合があり

ます。)本オプションのデフォルト値は“表8.5 メモリ割り当てプールの


なお、指定値(または調整値)が、-Xmsオプションで指定され

た値よりも小さな値の場合、初期化エラーとなり、Javaプロセ

スは終了します。

-XX:NewSize New世代領域のヒープサイズを指定します。

たとえば、New世代領域のヒープサイズを128MBに設定する

場合、”-XX:NewSize=128m”と指定します。

本オプションの指定が有効な場合のデフォルト値は以下のと

おりです。

・ type0またはtype0pのCMS付きパラレルGCを使用してい

る場合は、メモリ割り当てプールの初期値の1/8です。





・上記以外の場合のデフォルト値は“表8.7 Javaヒープに関

するオプション(-XX:NewSize/-XX:NewRatio)のデフォル

ト値”のとおりです。

なお、指定値がJava VMとしての下限値未満の場合、初期化

エラーとなり、Javaプロセスは終了します。そのため、本オプ

ションを指定する場合は、1MB以上の値を指定してください。

-XX:MaxNewSize New世代領域の大ヒープサイズを設定します。

たとえば、New世代領域の大ヒープサイズを128MBに設定

する場合、”-XX:MaxNewSize=128m”と指定します。

本オプションの指定が有効な場合のデフォルト値は以下のと

おりです。


る場合は、メモリ割り当てプールの大値の1/8です。





・上記以外の場合、デフォルト値はありません(本オプショ

ンの値を用いてNew世代領域の大ヒープサイズは決

定されません)。

なお、指定値が、-XX:NewSizeオプションで指定された値よ

りも小さな値の場合は、-XX:NewSizeオプションで指定され

た値となります。

-XX:NewRatio (注3) New世代領域とOld世代領域のサイズ比率を指定します。

たとえば、New世代領域とOld世代領域のサイズ比率を2とす

る場合、”-XX:NewRatio=2”と指定します。

本オプションの指定が有効な場合のデフォルト値は“表8.7Javaヒープに関するオプション(-XX:NewSize/-XX:NewRatio)のデフォルト値”のとおりです。

- 213 -


-XX:SurvivorRatio (注2)(注4)

New世代領域を構成するEden領域とSurvivor領域のサイズ

比率を指定します。

たとえば、Eden領域とSurvivor領域のサイズ比率を8とする

場合、”-XX:SurvivorRatio=8”と指定します。

本オプションの指定が有効な場合のデフォルト値は8です。

-XX:TargetSurvivorRatio(注2)(注4)

ガーベジコレクション(GC)処理後の生存オブジェクトが

Survivor領域を占める割合を、指定したパーセンテージ値

に調整します。

たとえば、GC処理後の生存オブジェクトがSurvivor領域を占

める割合を半分とする場合、”-XX:TargetSurvivorRatio=50”

と指定します。

本オプションの指定が有効な場合のデフォルト値は50です。

-XX:PermSize Permanent世代領域の初期値を指定します。

たとえば、Permanent世代領域の初期値を32MBに設定する

場合、”-XX:PermSize=32m”と指定します。

本オプションのデフォルト値は“表8.6 Permanent世代領域の


なお、指定値が1MB未満の場合は初期化エラーとなり、Javaプロセスは終了します。

-XX:MaxPermSize Permanent世代領域の大値を指定します。

たとえば、Permanent世代領域の大値を128MBに設定す

る場合、”-XX:MaxPermSize=128m”と指定します。

(実際に使用される値は、ページサイズなどのシステム情報を

元に、Java VMによる制御が適となるように調整された値

「調整値」となるため、指定された値と若干異なる場合があり

ます。)本オプションのデフォルト値は“表8.6 Permanent世代領域の


なお、指定値(または調整値)が、-XX:PermSizeオプションで

指定された値よりも小さな値の場合は、-XX:PermSizeオプショ

ンで指定された値となります。

注1) サイズを指定するオプションでは単位として次の文字を指定できます。

KB（キロバイト）を指定する場合:”k”または”K”

MB（メガバイト）を指定する場合:”m”または”M”

注2) パラレルGCを使用する場合、このオプションへの指定値は無効となります。

注3) CMS付きパラレルGCを使用する場合、このオプションへの指定値は無効となります。

注4) CMS付きパラレルGCを使用する場合、かつ-XX:UseFJcmsGC=type0またはtype0p指定でない場合、このオプショ

ンへの指定値は無効となります。

表8.5 メモリ割り当てプールのデフォルトのサイズ

JDK/JREの

バージョン

OS JDK/JREの実行

モード

GC処理初期値最大値

JDK/JRE 6 Windows

Linux for x86

Linux forIntel64

32ビットモードシリアル

GC5.0MB 64MB

パラレル

GC (注1)8.0MB

CMS付き

パラレル

GC

(注2)

Solaris 32ビットモードシリアル

GC6.125MB

- 214 -

JDK/JREの

バージョン

OS JDK/JREの実行

モード

GC処理初期値最大値

パラレル

GC (注1)8.0MB

CMS付き

パラレル

GC

(注2)

WindowsServer(R) x64Editions

Linux forIntel64


GC7.75MB 84MB

パラレル

GC (注1)9.1875MB

CMS付き

パラレル

GC

(注2)

JDK/JRE 7 Windows

Linux for x86

Linux forIntel64


GC5.0MB 96MB

パラレル

GC (注1)7.375MB

CMS付き

パラレル

GC

(注2)

Solaris 32ビットモードシリアル

GC5.0MB

パラレル

GC (注1)FJVMの場

合：8.0MBClient VMの場合:7.375MB

CMS付き

パラレル

GC

(注2)


Linux forIntel64


GC6.4375MB 126MB

パラレル

GC (注1)8.3125MB

CMS付き

パラレル

GC

(注2)

注1) デフォルトで使用されるGC処理です。

注2) メモリ割り当てプールの大値が64MB未満の場合は、メモリ割り当てプールの大値と等しくなります。メモリ割り

当てプールの大値が64MB以上の場合は、64MBとなります。

表8.6 Permanent世代領域のデフォルトのサイズ

JDK/JREの

バージョン

OS JDK/JREの実行

モード

Java VM 初期値最大値

JDK/JRE 6 Windows

Solaris

Linux for x86

32ビットモード JavaHotSpotClient VM

12MB 64MB

- 215 -

JDK/JREの

バージョン

OS JDK/JREの実行

モード

Java VM 初期値最大値

Linux forIntel64

FJVM (注1)

16MB


Linux forIntel64

64ビットモード FJVM (注1)

20.75MB

84MB

JDK/JRE 7 Windows

Solaris

Linux for x86

Linux forIntel64

32ビットモード JavaHotSpotClient VM

12MB 64MB

FJVM (注1)

16MB


Linux forIntel64

64ビットモード FJVM (注1)

20.75MB

84MB

注1) デフォルトで使用されるJava VMです。

表8.7 Javaヒープに関するオプション(-XX:NewSize/-XX:NewRatio)のデフォルト値

JDK/JREの

バージョン

OS JDK/JREの実行モード Java VM -XX:NewSize -XX:NewRatio

JDK/JRE 6 Windows

Linux for x86

Linux for Intel64

32ビットモード Java HotSpot ClientVM

1024KB 12

FJVM (注1) 8

Solaris 32ビットモード Java HotSpot ClientVM

2176KB 8

FJVM (注1) 2

Windows Server(R) x64Editions

Linux for Intel64

64ビットモード FJVM (注1) 2624KB 2

JDK/JRE 7 Windows

Solaris

Linux for x86

Linux for Intel64

32ビットモード Java HotSpot ClientVM

1024KB 2

FJVM (注1)


Linux for Intel64

64ビットモード FJVM (注1) 1280KB

注1) デフォルトで使用されるJava VMです。

■チューニングの方針

Javaヒープをチューニングする際、次の方針があります。

- 216 -

1. FullGCを実行したにもかかわらず、メモリ不足が発生する場合、GCのログを採取し、メモリ割り当てプールまたは

Permanent世代領域のいずれかの領域が不足しているかどうかを確認します。

2. FullGCはコストがかかります。このため、メモリ不足が発生しなくても、Javaアプリケーションがハングアップしたかの

ように一時的に無反応になる場合、FullGCの影響を受けている場合があります。GCのログを採取し、Javaヒープ

が必要以上に大きなサイズになっていれば、Javaヒープのサイズを縮小する方針でチューニングします。

3. 効率的なNew GCに対して、FullGCはコストがかかります。このため、New世代領域とOld世代領域のサイズのバ

ランスを考慮する必要があります。なお、GC処理としてパラレルGCを使用する場合は、JavaヒープのNew世代領

域およびOld世代領域の大きさに関する値が自動的に調整および適化されるため、通常はこのバランスを考慮

する必要はありません。

4. 仮想メモリに余裕がある場合は、Javaプロセスを複数起動して、プロセス多重度を上げる方法を検討します。プロ

セス多重度を上げることにより、プロセスごとのユーザ空間を有効に使うことが可能になります。ただし、メモリのス

ワッピングによるスローダウンに注意する必要があります。

■チューニングの影響範囲

メモリ割り当てプールの大きさ(-Xmxオプションの指定値)や、New世代領域とOld世代領域の大きさのバランスを変更し

た場合の影響範囲を、次に示します。

・メモリ割り当てプールの大きさを縮小した場合、GCが頻発することがあります。

・メモリ割り当てプールの大きさを拡張した場合、FullGCに時間がかかることがあります。

・メモリ割り当てプールの大きさを拡張した場合、その分ユーザ空間や仮想メモリが少なくなるため、スタックやネイティ

ブモジュールの動作に必要な領域を確保できず、メモリ不足になることがあります。

・ New世代領域の大きさがメモリ割り当てプールの大きさの半分となるようなチューニングを行った場合、一般的に、

FullGCが発生しやすくなる傾向があります。なお、Javaアプリケーション実行時のオブジェクト生成／解放などの特性

に依存しますので、どのアプリケーションの場合でもFullGCが発生しやすいというわけではありません。

overcommit memory機能が有効な場合の注意事項

「overcommit memory機能」が有効な場合、Linuxは、Javaヒープの各領域の大値に相当する仮想メモリ資源を、JavaVMの起動時に、Javaプロセスに対して予約します。

このため、-Xms値と-Xmx値を異なる値にしてJavaプロセスを起動する場合、本機能の有効/無効によって、Javaプロセ

ス起動時にJavaヒープとして必要となる仮想メモリの量が異なります。

・ overcommit memory機能が無効、またはovercommit memory機能がないシステムの場合

Javaヒープ用仮想メモリ量＝「-Xms値」＋「Perm域初期値」

・ overcommit memory機能が有効なシステムの場合

Javaヒープ用仮想メモリ量＝「-Xmx値」＋「-XX:MaxPermSize値」

この結果、仮に同量の仮想メモリ資源を持つシステムの場合であっても、本機能の有効/無効によって、同時に起動

できるJavaプロセスの数が異なる場合があります。

Linuxで仮想メモリ資源の見積もりを行う場合には、overcommit memory機能の有無に注意してください。

8.4.2 スタックのチューニング

本節では、Javaアプリケーションで使用するスレッドのスタックのチューニング方法および、チューニングによる影響範囲

を説明します。


Java APIで生成するスレッドのスタックサイズは、“-Xss”オプションで指定することができます。

“-Xss”オプションは、バイト単位でスタックサイズを指定します。例えば、スタックサイズを512KBに設定する場合、“-Xss512k”と指定します。

またJDK/JRE内で実行されるJavaメソッドを自動的にコンパイルする専用スレッド(コンパイラスレッド)のスタックサイズは、

“-XX:CompilerThreadStackSize”オプションで指定することができます。

- 217 -

通常、コンパイラスレッドのスタックサイズを指定する必要はありません。

“-XX:CompilerThreadStackSize”オプションは、キロバイト(Kバイト)単位でコンパイラスレッドのスタックサイズを指定しま

す。例えば、スタックサイズを1024KBに設定する場合、”-XX:CompilerThreadStackSize=1024”と指定します。

Java APIで生成したスレッドおよびコンパイラスレッドのデフォルトのスタックサイズを、“表8.8 Java APIで生成したスレッ

ドおよびコンパイラスレッドのデフォルトのスタックサイズ”に示します。

なお、スタック領域の実際の管理はOSが行います。そのためスタック領域に関する管理方法/動作仕様については、JDK/JREを実行する各OSの仕様に依存します。

表8.8 Java APIで生成したスレッドおよびコンパイラスレッドのデフォルトのスタックサイズ

JDK/JREのバージョ

ン

OS JDK/JREの実行

モード

Java APIで生成し

たスレッド(注1)コンパイラス

レッド (ClientVM)(注1)

コンパイラスレッ

ド (FJVM)

JDK/JRE 6

Windows 32ビットモード 320KB 320KB 2048KB

Linux for x86

Linux for Intel64

32ビットモード 320KB 512KB 2048KB

Solaris 32ビットモード 512KB 512KB 2048KB


Linux for Intel64

64ビットモード 1024KB －(注2) 4096KB

JDK/JRE 7

Windows 32ビットモード 320KB 320KB 2048KB

Linux for x86

Linux for Intel64

32ビットモード 320KB 512KB 2048KB

Solaris 32ビットモード 512KB 512KB 2048KB


Linux for Intel64

64ビットモード 1024KB －(注2) 4096KB

注1) Windows版JDK/JREにおけるスタックサイズは、java.exeなどWindows版JDK/JREが提供するJDKツールを用いた

場合の値です。JNIを用いて独自にJava VMを起動しているWindowsアプリケーションの場合は、Java VMを起動したプ

ログラムのメインスレッドに対するスタックサイズと同じ値になります。

注2) 実行モードが64ビットモードのJDK/JREでは、Java HotSpot Client VMは搭載していません。

■チューニングの影響範囲

スタックのサイズを変更した場合の影響範囲を、次に示します。

・スタックのサイズを縮小した場合、スタックオーバーフローが発生することがあります。

・スタックのサイズを拡張した場合、その分ユーザ空間や仮想メモリが少なくなるため、Javaヒープやネイティブモジュー

ルの動作に必要な領域を確保できず、メモリ不足になることがあります。

8.4.3 暖機運転

本項では、Javaアプリケーション実行において、動的コンパイルから受ける影響の確認方法、およびその対応方法であ

る暖機運転について説明します。


“8.3 動的コンパイル”で説明したように、Javaアプリケーションの実行は、Java VM起動直後はインタプリタ実行だけで行

われ、次第にインタプリタ実行と動的コンパイル結果による機械命令実行との混合動作になります。また動的コンパイル

により翻訳された機械命令の内容も、Javaアプリケーションの実行が進むにつれて、次第にJavaアプリケーションの実行

状況に合った翻訳結果に適化されます。つまりJavaアプリケーションの実行には、以下の動的コンパイルによるオー

- 218 -

バーヘッドや適化状態の推移があるため、Javaアプリケーションとして安定した実行性能になるまで、プロセス起動時

からある程度の時間を必要とする場合があります。

・実行対象プログラムであるクラスファイルを実行時に読み込むため、Javaアプリケーションとしての起動直後には、ク

ラスファイルのロードおよび内容検査によるオーバーヘッドが発生します。

・実行時に機械命令への翻訳処理を行うため、そのオーバーヘッドが発生します。

・機械命令への翻訳・適化処理で必要とする情報を、Javaアプリケーション実行と同時に収集するため、Javaアプリ

ケーション開始直後は適化状態の推移が少なく、結果として実行性能が遅い機械命令となっている場合がありま

す。

なお、Javaアプリケーションとして安定した実行性能になるまでに掛かる時間は、各アプリケーションによって異なりま

す。

(1) 動的コンパイル発生状況の調査

Javaアプリケーション実行時における動的コンパイルから受ける影響の有無は、Javaアプリケーションによる業務が開始

された際に、動的コンパイルの発生頻度が高いかどうかを判断することで行います。

具体的には、“8.3.3 動的コンパイル発生状況のログ出力機能”を用いてコンパイラスレッドのCPU使用状況や動的コン

パイル結果情報を出力し、その結果から以下の傾向が見て取れ、かつJavaアプリケーションとして安定した実行性能に

なるまでに掛かる時間との関連性が見て取れるかどうかを元に判断します。

・コンパイラスレッドのCPU使用状況において、経過時間に対してCPU時間の割合が高い場合

・動的コンパイル結果情報において、Javaメソッドのコンパイルが、短い間に連続して発生している場合

Javaアプリケーション起動時や、業務を開始してJavaアプリケーションへの入力が始まる時に、動的コンパイル処理が発

生する頻度が高くなる傾向は、Javaアプリケーション実行時の一般的な傾向です。そのため、動的コンパイル発生状況

の調査の結果として、「コンパイラスレッドのCPU時間の割合が高い」や「動的コンパイルの発生頻度が高い」などの傾向

が見て取れる場合であっても、インタプリタ実行と機械命令による実行がバランス良く行われており、対応が不要な場合

が多々あります。

動的コンパイル発生状況の調査は、Javaアプリケーションとして安定した実行性能になるまでに掛かる時間が実運用上

の問題となった場合に行ってください。

Javaアプリケーション起動直後の性能に影響を与える処理は、動的コンパイル処理だけではありません。Javaアプリケー

ション自体の初期化処理や関連するアプリケーションの起動待ちなど、Javaアプリケーションの起動直後でだけ動作する

動的コンパイル以外の要因についても考慮する必要があります。

ServletやEJBなどのJavaアプリケーションがInterstage Application Server配下で動作する場合、「Javaアプリケーションの

起動(開始)」には以下の2つの意味があります。

a. Interstage Application Serverの起動(J2EE環境のワークユニット起動、JavaEE環境のクラスタ起動）

b. 業務アプリケーションの運用開始

動的コンパイル処理が行われる頻度が高まるのは(a)の直後と(b)の直後の両方ですが、業務としての影響を確認するこ

とが目的であるため、動的コンパイル発生状況の調査対象は(b)の状況になります。

- 219 -

なお、動的コンパイル結果情報(-XX:+FJPrintCompilationオプション指定時の出力結果)から、(b)の始まりを調べるに

は、システムログなどから(a)の完了時刻を調べ、その時刻以降に発生した動的コンパイルを対象に調査を行います。

JavaアプリケーションがJSPで作成されている場合、アプリケーションを配備する際にJSPのプリコンパイル（javacコマンド

によりJavaソースをクラスファイルへ変換する処理）が実施されていないと、Javaアプリケーション起動時にjavacコマンド実

行によるオーバヘッドが発生する場合があります。

JSPのプリコンパイル運用ができる場合は、JSPのプリコンパイルを実施することで、Javaアプリケーションとして安定した実

行性能になるまでに掛かる時間が小さくなるかどうかを確認してださい。

(2) 暖機運転

Javaアプリケーションを起動した後、業務としての運用を開始する時点で安定した実行性能を得る状態にするために

は、暖機運転という運用を行います。

暖機運転とは、Javaアプリケーションを起動した後、実際の業務を開始する前に、業務と同様のダミーデータを用いて疑

似実行させることで、事前に主なJavaメソッドを動作させ、クラスファイルのロードやJavaメソッドの動的コンパイルを完了さ

せておくことを言います。

暖機運転により、動的コンパイルなどのオーバーヘッドを減らすことができ、また機械命令への翻訳・適化処理もその

時点で行われるようになるため、業務としての運用開始時点から安定した実行性能を得ることができるようになります。

なお暖機運転をどの程度の期間行ったら良いのかについては、Javaアプリケーションの実行性能が運用要件を満たす

ところまで安定しているかのかどうかが、判断の基準になります。ただし、Javaアプリケーションを起動してから業務開始ま

での時間は無限にあるわけではないので、“8.3.3 動的コンパイル発生状況のログ出力機能”の動的コンパイル結果情報

の出力結果を参考に、暖気運用に掛ける時間をある程度のところで区切る判断をする必要があります。

図1に、動的コンパイル結果情報(-XX:+FJPrintCompilationオプション指定時)の出力例を示します。

通常、Javaアプリケーションの実行には、実行結果の表示、データの更新などの結果を伴います。暖機運転による実行

結果が、Javaアプリケーションの運用自体に影響を与えないように注意する必要があります。

例えば、暖機運転用のダミーデータをそのままデータベースに登録してしまい、運用時に誤ったデータを返却するなど

の問題が発生しないように注意してください。

Javaアプリケーション自体の初期化処理や関連するアプリケーションの起動待ちなど、動的コンパイル以外の要因でJavaアプリケーションとして安定した実行性能になるまでに時間が掛かっている場合は、暖機運転では対処することができま

せん。

図1 動的コンパイル結果情報(-XX:+FJPrintCompilationオプション指定時)の出力例

0.133: 1 sun.misc.ASCIICaseInsensitiveComparator::compare (143 bytes)0.137: 2 java.lang.String::charAt (33 bytes)0.142: 3 java.lang.String::hashCode (64 bytes)0.204: 4 java.lang.String::equals (88 bytes)0.210: 5 java.lang.String::indexOf (151 bytes)0.215: 6 java.lang.AbstractStringBuilder::append (40 bytes)0.226: 7 java.lang.String::replace (142 bytes)(中略)0.444: 30 java.util.jar.Attributes::read (410 bytes)0.470: 31 java.lang.String::<init> (111 bytes)

- 220 -

0.486: [CompilerThread0: cpu=140.63ms elapsed=367.55ms 1]0.486: 32 java.util.jar.Attributes$Name::isValid (32 bytes)0.487: 33 java.util.jar.Attributes$Name::isAlpha (30 bytes)0.487: 34 sun.nio.cs.ext.MS932$Decoder::decodeSingle (19 bytes) (中略) Application Server起動時は、頻繁に動的コンパイルが発生

15.449: 796 net.jxta.impl.document.LiteXMLElement::addAttribute (450 bytes)15.538: 797 java.io.ObjectOutputStream::writeHandle (21 bytes)15.574: 798 java.util.Hashtable$Enumerator::hasNext (5 bytes)15.600: 799 com.sun.enterprise.config.ConfigBean::addXPathToChild (27 bytes)15.606: [CompilerThread0: cpu=250.00ms elapsed=781.02ms 24]15.630: 800 java.util.regex.Matcher::<init> (84 bytes)23.535: 801 java.util.Arrays::copyOf (47 bytes)25.542: 802 java.util.Arrays::copyOf (13 bytes)25.545: 803 net.jxta.document.MimeMediaType::findNextSeperator (39 bytes)43.567: 804 net.jxta.impl.document.LiteXMLElement::getTagRanges (1697 bytes)この時点でInterstage Application Serverとしての起動が完了し、動的コンパイルの発生がいったん減少

(Interstage Application Serverの起動(J2EE環境のワークユニット起動、JavaEE 環境のクラスタ起動)の完了時間は、

Interstage Application Serverのログ(サーバ情報のログ) から調べることができます。)44.212: 805 org.apache.tomcat.util.buf.Ascii::toLower (14 bytes)44.223: 806 org.apache.tomcat.util.buf.ByteChunk::equalsIgnoreCase (76 bytes)44.224: 807 sun.nio.cs.ISO_8859_1$Decoder::decodeArrayLoop (263 bytes)44.240: 18% java.util.Properties$LineReader::readLine @ 21 (452 bytes)44.258: 808 org.apache.coyote.http11.InternalInputBuffer::parseHeader (585 bytes)44.265: 809 java.util.Properties$LineReader::readLine (452 bytes)44.290: 810 java.lang.ThreadLocal$ThreadLocalMap::nextIndex (15 bytes)44.332: 811 java.util.Hashtable$Enumerator::next (27 bytes)44.387: 812 java.net.URI::quote (208 bytes)44.412: 19% sun.nio.cs.ext.DoubleByteEncoder::encodeArrayLoop @ 55 (608 bytes)(中略) 業務が開始し、再び頻繁に動的コンパイルが発生

158.121: 1128 sun.util.calendar.ZoneInfo::getOffsetsByWall (8 bytes)160.374: 1129 javax.management.NotificationBroadcasterSupport::sendNotification (118 bytes)160.698: 1130 java.util.TimeZone$DisplayNames::access$000 (4 bytes)161.405: 1131 com.sun.jmx.remote.internal.ArrayNotificationBuffer::addNotification (144 bytes)163.572: 1132 sun.nio.cs.ext.DoubleByteDecoder::decodeLoop (28 bytes)164.460: 1133 sun.util.calendar.CalendarDate::isDaylightTime (22 bytes)170.743: 1134 java.util.AbstractCollection::toArray (116 bytes)業務開始からしばらく経過した時点で、動的コンパイルの発生が減少

8.5 チューニング/デバッグ技法

ここでは、チューニング技法およびデバッグ技法を紹介します。

8.5.1 スタックトレース

Javaアプリケーションで例外(java.lang.Throwableのインスタンス)がスローされた場合などに出力されるスタックトレース

は、エラーが発生するまでの経緯(メソッドの呼び出し順番)が示されています。このスタックトレースを解析することにより、

エラーが発生した箇所と原因を確認することができます。

■スタックトレースの出力先

スタックトレースの出力先は、標準エラーです。通常のJavaアプリケーションの場合は、コンソールに出力されますが、

Servlet/JSP/EJBアプリケーションの場合は、ログファイル（標準出力、標準エラー出力あるいはJava VMの出力を格納す

るファイルなど）に出力されます。

- 221 -

■スタックトレースの出力方法

Javaでスローされた例外をcatch節でキャッチし、例外のprintStackTraceメソッドを実行することにより、スタックトレースを

出力することができます。

java.lang.Throwable.printStackTrace()でスタックトレースを出力する方法を、図1に示します。

図1 printStackTraceメソッドでスタックトレースを出力する方法

try {

SampleBMPSessionRemote bmpSessionRemote = bmpSessionHome.create();

} catch(Exception e) {

e.printStackTrace();

}

なお、スローされた例外をtry-catch構文で処理するメソッドがスレッドにない場合、そのスレッドは停止され、Java VMに

よってスタックトレースが出力されます。

■スタックトレースの出力フォーマット

スタックトレースの出力フォーマットを、図1に示します。

図1 スタックトレースの出力フォーマット

例外クラス名: エラーメッセージ

at クラス名.メソッド名1(ソース名:行番号) 呼び出し先

at クラス名.メソッド名2(ソース名:行番号)

:

:

at クラス名.メソッド名N(ソース名:行番号) 呼び出し元

・初の1行目は、スローされた例外のクラス名とエラーメッセージです。

エラーメッセージがない場合もあります。

・ 2行目以降は、メソッドの呼び出し元(クラス名.メソッド名N)から呼び出し先(クラス名.メソッド名1)に向かって下から上

に出力されます。

2行目(クラス名.メソッド名1)が、例外をスローしたメソッドの情報です。

・ “メソッド名”が“<init>”の場合、コンストラクタを示します。

・ “メソッド名”が“<cinit>”が場合、static initializerを示します。

・ “(ソース名:行番号)”が“(Native Method)”の場合、Javaのネイティブメソッド(.soや.dllファイル)を示します。

・クラスのコンパイル時にデバッグ情報を削除した場合、“(ソース名:行番号)”には、ソース名しか表示されなかったり、

“Unknown Source”と表示されたりする場合があります。

8.5.1.1 スタックトレースの解析方法(その1) 図1の出力例をもとにして、解析方法を説明します。

図1の先頭の“数字:”は、説明の便宜上、付加しています。

図1 スタックトレースの出力例

1:java.lang.NullPointerException

2: at agency.attestation.CheckLoginInfo.doCheck(CheckLoginInfo.java:150)

3: at agency.attestation.AttestationServlet.doGet(AttestationServlet.java:96)

4: at agency.attestation.AttestationServlet.doPost(AttestationServlet.java:161)

5: at javax.servlet.http.HttpServlet.service(HttpServlet.java:772)


:

■読み方

図1のスタックトレースは、6行目から上方向に読むと、次の流れで例外が発生したことがわかります。

- 222 -

1. javax.servlet.http.HttpServlet.service()が、HttpServlet.javaの865行目で、javax.servlet.http.HttpServlet.service()を実行し、

2. javax.servlet.http.HttpServlet.service() が、 HttpServlet.java の 772 行目で、

agency.attestation.AttestationServlet.doPost()を実行し、

3. agency.attestation.AttestationServlet.doPost() が、 AttestationServlet.java の 161 行目で、

agency.attestation.AttestationServlet.doGet()を実行し、

4. agency.attestation.AttestationServlet.doGet() が、 AttestationServlet.java の 96 行目で、

agency.attestation.CheckLoginInfo.doCheck()を実行した結果、

5. agency.attestation.CheckLoginInfo.doCheck() 内の CheckLoginInfo.java の 150 行目で、

java.lang.NullPointerExceptionという例外が発生した

■解析方法

図1のスタックトレースの解析例を、次に示します。

1. 1行目の例外情報から、原因を特定できるかどうか確認します。

NullPointerExceptionがスローされていることがわかります。

2. 2行目のCheckLoginInfo.javaの開発担当者であれば、150行目の実装に問題がないかどうかを確認します。

3. 2行目のCheckLoginInfo.javaの開発担当者でない場合、スタックトレース中で上行にある開発担当者が開発し

たクラスを探します。そして、そのクラスの実装に問題がないかどうかを確認します。それでも、原因を特定できない

場合は、開発したクラスが使用しているクラスの提供元に調査を依頼します。

または、スタックトレースが、想定された流れでメソッドを実行しているかどうかを確認するのも1つの方法です。

8.5.1.2 スタックトレースの解析方法(その2) 図1の出力例をもとにして、解析方法を説明します。

図1の先頭の“数字:”は、説明の便宜上、付加しています。

図1 スタックトレースの出力例

1:java.util.MissingResourceException: Can't find bundle for base name sample.SampleResource, locale ja_JP

2: at java.util.ResourceBundle.throwMissingResourceException(Unknown Source)

3: at java.util.ResourceBundle.getBundleImpl(Unknown Source)

4: at java.util.ResourceBundle.getBundle(Unknown Source)

5: at sample.SampleMessage.getMessage(SampleMessage.java:15)

6: at sample.SampleServlet.doGet(SampleServlet.java:10)



:

:

■解析方法

図1のスタックトレースの解析例を、次に示します。

1. 1行目の例外情報から、原因を特定できないかを確認します。

APIリファレンスによると、java.util.MissingResourceExceptionは、Javaのリソースがない場合に発生する例外です。

また、エラーメッセージによると、sample.SampleResourceというリソースファイルの日本語版(ja_JP)がないということ

がわかります。

2. リソースファイルを確認します。

a. リソースファイル名を誤っていないか

SampleMessage.java の 15 行目の sample.SampleMessage.getMessage () 内で、

java.util.ResourceBundle.getBundle()を実行した結果、例外がスローされています。したがって、そこで

java.util.ResourceBundle.getBundle()に渡しているリソースファイル名に誤りがないかどうかを確認します。

- 223 -

b. リソースファイルが、所定のディレクトリ構成内に存在するか

a)のリソースファイル名が正しい場合、所定のディレクトリ構成(/sample/)に、次のいずれかのリソースファイル

があるかどうかを確認します。

- SampleResource_ja_JP.properties

- SampleResource_ja_JP.class

- SampleResource_ja.properties

- SampleResource_ja.class

- SampleResource.properties

- SampleResource.class

8.5.1.3 スタックトレースの解析方法(その3) JDK/JRE 1.4以降、java.lang.Throwableに次のコンストラクタとメソッドが追加されました。

・ Throwable(java.lang.String, java.lang.Throwable)

・ Throwable(java.lang.Throwable)

・ initCause(java.lang.Throwable)

これにより、スタックトレースには、原因となる例外のスタックトレースも出力されるようになりました。

以降、図1のサンプルを使って、説明します。

図1 サンプルプログラム

1 :public class Test {

2 :

3 : public static void main(String[] args) {

4 : new Test();

5 : }

6 :

7 : Test() {

8 : try{

9 : parentMethod();

10: } catch (Exception e) {

11: e.printStackTrace();

12: }

13: }

14:

15: void parentMethod() throws HiLevelException {

16: try {

17: childMethod();

18: } catch (Exception e) {

19: throw new HiLevelException("HiLevel", e);

20: }

21: }

22:

23: void childMethod() throws LowLevelException {

24: throw new LowLevelException("LowLevel");

25: }

26:}

27:

28:class HiLevelException extends Exception {

29: HiLevelException(String msg, Throwable cause) {

30: super(msg, cause);

31: }

32:}

33:

34:class LowLevelException extends Exception {

35: LowLevelException(String msg) {

- 224 -

36: super(msg);

37: }

38:}

図1のサンプルを実行すると、図2のスタックトレースが出力されます。

図2 スタックトレース

HiLevelException: HiLevel

at Test.parentMethod(Test.java:19)

at Test.<init>(Test.java:9)

at Test.main(Test.java:4)

Caused by: LowLevelException: LowLevel

at Test.childMethod(Test.java:24)


... 2 more

HiLevelExceptionに続いて、“Caused by:”以降に、原因となるLowLevelExceptionのスタックトレースが出力されていま

す。終行の“... 2 more”は、“Caused by:”の直前の2行が続きのスタックトレースであることを示しています。

つまり、図3のように解釈することができます。

図3 原因となる例外の解釈

Caused by: LowLevelException: LowLevel

at Test.childMethod(Test.java:24)


at Test.<init>(Test.java:9)

at Test.main(Test.java:4)

以上から、次のことがわかります。

・スタックトレースの原因は、LowLevelExceptionである

・ Test.main(Test.javaの4行目)が、初の呼び出し元である。

詳細は、Java APIリファレンスのjava.lang.ThrowableのprintStackTraceメソッドの解説を参照してください。

8.5.2 例外発生時のスタックトレース出力

FJVMを使用してJavaアプリケーションを実行している場合、以下の例外については、実行性能の観点から、Java VMの動的コンパイル処理が行なう適化処理により例外発生時のスタックトレース出力処理が省略され、例外発生時のス

タックトレースが出力されない場合があります（例外発生時のスタックトレース出力抑止）。

JDK/JRE 6、7のFJVMの場合

・ java.lang.NullPointerException

・ java.lang.ArithmeticException

・ java.lang.ArrayIndexOutOfBoundsException

・ java.lang.ArrayStoreException

・ java.lang.ClassCastException

動的コンパイル処理により例外発生時のスタックトレース出力処理が省略されないようにする場合は、“-XX:-OmitStackTraceInFastThrow”オプションを指定します。

ただし該当する例外の発生頻度が高い場合に当該オプションを指定し、例外発生時のスタックトレース出力を行なった

場合は、Javaアプリケーションの実行性能が低下する場合があります。

当該オプションを指定する場合は、性能検証を行った上で使用するか、開発作業において例外が発生している場所を

特定したい場合においてだけ使用してください。

- 225 -

“-XX:-OmitStackTraceInFastThrow”オプションはFJVM固有機能です。

インタプリタで実行しているJavaメソッド内で上記例外が発生した場合は、当該オプションの指定に関係なく、例外発生

時のスタックトレースが出力されます。

8.5.3 スレッドダンプ

スレッドダンプには、Javaプロセスの各スレッドの情報(スタックトレース形式)が含まれているため、ハングアップやデッド

ロックなどの動作具合を調査することができます。

スレッドダンプの出力先は、標準出力です。スレッドダンプが出力される契機および出力先を、“表8.9 スレッドダンプの

出力契機と出力先”に示します。

表8.9 スレッドダンプの出力契機と出力先

プログラムの種類出力契機出力先

Java EEアプリケー

ション

J2EEア

プリケーション

一定の条件を満たした場合、コンテナの機能により

自動的に採取される場合と利用者の任意のタイミン

グで手動による採取があります。

自動採取：

アプリケーションがタイムアウトまたは無応答になっ

た場合

手動採取：

“スレッドダンプツール”で採取することができま

す。スレッドダンプツールの詳細は、“トラブルシュー

ティング集”の“スレッドダンプツール”を参照してく

ださい。

kill -QUIT [プロセスID]でJava VMに対してQUITシグナルを送り採取することができます。

標準出力、

JavaVMの出力

をロギングして

いるファイル

上記以外のJavaプログラム

利用者の任意のタイミングで手動で採取することが

できます。

コマンドプロンプトからJavaプログラムを起動した場

合：

以下、いずれかの方法で採取できます。

１）[Ctrl]+[Break]キー押下

２）“スレッドダンプツール”

コマンドプロンプト以外からJavaプログラムを起動し

た場合：

“スレッドダンプツール”で採取します。

スレッドダンプツールの詳細は、“トラブルシューティ

ング集”の“スレッドダンプツール”を参照してくださ

い。

ターミナルからJavaプログラムを起動した場合：

以下、いずれかの方法で採取できます。

コンソール(標準

出力)

- 226 -

プログラムの種類出力契機出力先

１）[Ctrl]+[\]キー（英語キーボードの場合バックス

ラッシュキー）押下

２）kill -QUIT [プロセスID]

ターミナル以外からJavaプログラムを起動した場合：

kill -QUIT [プロセスID]で採取します。

“-Xrs”オプションが指定されたJavaプロセスの場

合、当該プロセスへ送られた[Ctrl]+[Break]キー押

下またはQUITシグナルに対する動作は、OSのデ

フォルト動作になります。

そのため、“-Xrs”オプションを指定したJavaプロセ

スに対して[Ctrl]+[Break]キー押下またはQUITシグ

ナルが送られると、当該Javaプロセスは強制終了ま

たは異常終了します。

スレッドダンプを出力する可能性があるJavaプロセ

スに対して、“-Xrs”オプションは指定しないでくださ

い。

ただし、Windows(R)でサービスとして登録される

Javaプロセスの場合は、“-Xrs”オプションを指定し

ない場合、ログオフ時に強制終了してしまいます。

これが不都合な場合は、“-Xrs”オプションを指定し

てください。

図1の出力例をもとにして、スレッドダンプの解析方法を説明します。

図1 サンプルプログラム

1 :public class DeadlockSample {

2 : static boolean flag;

3 : static Thread1 thread1;

4 : static Thread2 thread2;

5 :

6 : public static void main(String[] args) {

7 : thread1 = new Thread1();

8 : thread2 = new Thread2();

9 : thread1.start();

10: thread2.start();

11: }

12:}

13:

14:class Thread1 extends Thread {

15: public Thread1(){

16: super("Thread1");

17: }

18:

19: public void run(){

20: synchronized(this){

21: System.out.println("Thread1開始");

22: while(DeadlockSample.flag==false){ // Thread2が開始するのを待つ

23: yield();

24: }

25: DeadlockSample.thread2.method();

26: notify();

27: }

28: }

- 227 -

29:

30: public synchronized void method(){

31: try{wait(1000);}catch(InterruptedException ex){}

32: System.out.println("Thread1.method()終了");

33: }

34:}

35:

36:class Thread2 extends Thread {

37: public Thread2(){

38: super("Thread2");

39: }

40:

41: public void run() {

42: synchronized(this){

43: DeadlockSample.flag = true;

44: System.out.println("Thread2開始");

45: DeadlockSample.thread1.method();

46: notify();

47: }

48: }

49:

50: public synchronized void method() {

51: try{wait(1000);}catch(InterruptedException ex){}

52: System.out.println("Thread2.method()終了");

53: }

54:}

図1のサンプルでは、Thread1とThread2がお互いに排他処理を行っています。

このサンプルを実行すると、次のように処理が進められます。

1. Thread1で、Thread1のロックを獲得する(20行目のsynchronized節)

2. Thread2で、Thread2のロックを獲得する(42行目のsynchronized節)

3. Thread1で、Thread2.method()を実行しようとして、ロック解放待ちになる(50行目のsynchronized修飾子)

4. Thread2で、Thread1.method()を実行しようとして、ロック解放待ちになる(50行目のsynchronized修飾子)

この結果、Thead1とThread2がお互いに、解放されないロックを待ち続けるデッドロック状態になります。

デッドロック状態で、スレッドダンプを採取したものを、図2に示します。

図2 スレッドダンプ

"DestroyJavaVM" prio=5 tid=0x002856c8 nid=0x5f4 waiting on condition [0..6fad8]

"Thread2" prio=5 tid=0x0092f4d8 nid=0x640 waiting for monitor entry [182ef000..182efd64]

at Thread1.method(DeadlockSample.java:31)

- waiting to lock <0x1002ffe8> (a Thread1)

at Thread2.run(DeadlockSample.java:45)

- locked <0x10030ca0> (a Thread2)

"Thread1" prio=5 tid=0x0092f370 nid=0x294 waiting for monitor entry [182af000..182afd64]


- waiting to lock <0x10030ca0> (a Thread2)


- locked <0x1002ffe8> (a Thread1)

"Signal Dispatcher" daemon prio=10 tid=0x0098eb80 nid=0x634 waiting on condition [0..0]

"Finalizer" daemon prio=9 tid=0x0092a540 nid=0x5e8 in Object.wait() [1816f000..1816fd64]

at java.lang.Object.wait(Native Method)

- waiting on <0x10010498> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)

- locked <0x10010498> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)

- 228 -

at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x0096da70 nid=0x5e4 in Object.wait() [1812f000..1812fd64]


- waiting on <0x10010388> (a java.lang.ref.Reference$Lock)

at java.lang.Object.wait(Object.java:429)

at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)

- locked <0x10010388> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=5 tid=0x0096c950 nid=0x624 runnable

"VM Periodic Task Thread" prio=10 tid=0x0092c008 nid=0x2a0 waiting on condition

"Suspend Checker Thread" prio=10 tid=0x0098e118 nid=0x478 runnable

Found one Java-level deadlock:

=============================

"Thread2":

waiting to lock monitor 0x00929c3c (object 0x1002ffe8, a Thread1),

which is held by "Thread1"

"Thread1":

waiting to lock monitor 0x00929c5c (object 0x10030ca0, a Thread2),

which is held by "Thread2"

Java stack information for the threads listed above:

===================================================

"Thread2":


- waiting to lock <0x1002ffe8> (a Thread1)


- locked <0x10030ca0> (a Thread2)

"Thread1":


- waiting to lock <0x10030ca0> (a Thread2)


- locked <0x1002ffe8> (a Thread1)

Found 1 deadlock.

■解析方法

スレッドダンプの各スレッドの情報は、スタックトレース形式です。

Thread1とThread2の両方のスタックトレースには、“locked”と“waiting to lock”があります。また、スレッドダンプの下の方

にも、“deadlock”の文字列があり、デットロックが発生していることが確認できます。

このように、スレッドダンプで全スレッドの動作状況を確認するにより、Javaプロセスがハングアップしているか、あるい

は、デッドロック状態かを確認することができます。特に、短い間隔で複数のスレッドダンプを採取し、スレッドに動きがな

ければ、ハングアップの可能性があります。

スレッドダンプの詳細は、“トラブルシューティング集”も参照してください。

オブジェクトをロックしているスレッドがスレッドダンプ上に出ない

通常スレッドダンプ上のあるスレッドで次のように表示される場合があります。

- waiting to lock <オブジェクトID> (a クラス名)

このような場合、別のスレッドがそのオブジェクトIDのロックを持っていて、そのスレッドのトレース上のどこかで次の表示

がされています。

- locked <オブジェクトID> (a クラス名)

- 229 -

しかし、スレッドダンプを表示するタイミングによっては“- locked <オブジェクトID> (a クラス名)”の表示がどのスレッドにも

現われず、“- waiting to lock <オブジェクトID> (a クラス名)”だけ表示される場合があります。

以下のプログラムを例とします。

1 class NoLockOwner extends Thread

2 {

3 static Object lock = new Object();

4

5 public static void main(String[] arg)

6 {

7 new NoLockOwner().start();

8 new NoLockOwner().start();

9 }

10

11 public void run()

12 {

13 while (true) {

14 synchronized (lock) {

15 dumb();

16 }

17 }

18 }

19

20 void dumb()

21 {

22 int n = 0;

23 for (int i = 0 ; i < 1000 ; ++i)

24 n += i;

25 }

26

27 }

(0)スレッドダンプを取ると、通常はこのようになります。

"Thread-1" prio=1 tid=0x10 nid=0x5 waiting for monitor entry [0x3000..0x4000]

at NoLockOwner.run(NoLockOwner.java:14)

- waiting to lock <0x800> (a java.lang.Object)

"Thread-0" prio=1 tid=0x20 nid=0x6 runnable [0x5000..0x6000]

at NoLockOwner.dumb(NoLockOwner.java:23)


- locked <0x800> (a java.lang.Object)

(1)先頭フレームでオブジェクトをロックしている場合は“- locked”ではなく、“- waiting to lock”と表示されることがありま

す。







この場合、スレッドの状態を見て、runnableであれば、ロック待ちではなく、ロック取得後同じフレームを実行中の状態で

あると考えます。

Thread-0、Thread-1ともに、“- waiting to lock <0x800> (a java.lang.Object)”と表示されているので、どちらもロック待ちの

ように見えます。

しかし、Thread-0の状態は、runnbleなので、ロック待ち状態ではありません。

(2) “- waiting to lock”と表示されるのは、ロック待ちの状態だけではなく、ロック獲得処理の中でもそのように表示され

ます。

- 230 -







Thread-0、Thread-1ともに、“- waiting to lock <0x800> (a java.lang.Object)”と表示されているので、どちらもロック待ちの

ように見えます。

さらに、スレッドの状態も、どちらも、“waiting for monitor entry”になっています。

“- waiting to lock”と表示されるのは、ロック待ちの状態だけではなく、ロック獲得処理の中でもそのように表示されま

す。

したがって、この場合、Thread-0またはThread-1のいずれか一方、あるいは両方がロック獲得処理の中であると考えま

す。

しかし、この状態は長く続かず、短時間で(0)または(1)に移行します。

(3) ロックを開放した直後の状態






Thraed-0がちょうどロックを開放した直後の状態です。

この状態も長く続くとはなく、短時間で(0)または(1)に移行します。

スレッドダンプからアプリケーションの状態を判断する場合、ひとつのスレッドダンプから状態を判断することは困難です。

適切な判断をするためには、複数回のスレッドダンプを総合的に見ることが必要です。

スレッドダンプ中に表示されるsynchronizedメソッドの行番号について

次のようなプログラムを考えます。

1 class SyncMethod extends Thread

2 {

3 static volatile int k;

4


6 {

7 new SyncMethod().start();

8 }

9


11 {

12 while (true) {

13 dumb();

14 }

15 }

16

17 synchronized void dumb()

18 {

19 /*

20 meaningless comments

21 */

22 int i = 0;

23 for ( ; i < 10 ; ++i)

24 k += i;

25 }

26

27 }

- 231 -

このようなプログラムのスレッドダンプを取ると以下のように出力されることがあります。

"Thread-0" prio=1 tid=0x300 nid=0x61 runnable [1000..2000]

at SyncMethod.dumb(SyncMethod.java:23)

- waiting to lock <0xa00> (a SyncMethod)

at SyncMethod.run(SyncMethod.java:13)

23行目でロックを獲得しているように見えますが、23行目は、“for ( ; i < 10 ; ++i)”であり、何もロック獲得に関係している

ようにソースコード上は見えません。

これは、synchronizedメソッドがロックを獲得する行番号は、初に実行される行番号になるためです。

スレッドダンプ中、複数のスレッドがロックを獲得している場合ついて

次のようなプログラムを考えます。

1 class NoNotify extends Thread

2 {

3 static Object o = new Object();

4


6 {

7 new NoNotify().start();

8 new NoNotify().start();

9 }

10


12 {

13 try {

14 synchronized (o) {

15 o.wait();

16 }

17 } catch (Exception e) {}

18 }

19

20 }

このプログラムには誤りがあります。

このプログラムでは誰もnotifyするスレッドがないため、どちらのスレッドも永久に起こされることはありません。

このプログラムのスレッドダンプを採取すると次のように示される場所があります。

"Thread-1" prio=1 tid=0x800 nid=0x6 in Object.wait() [1000..2000]


- waiting on <0x200> (a java.lang.Object)


at NoNotify.run(NoNotify.java:15)


"Thread-0" prio=1 tid=0x900 nid=0x7 in Object.wait() [3000..4000]


- waiting on <0x200> (a java.lang.Object)


at NoNotify.run(NoNotify.java:15)


このスレッドダンプから分かることは、複数のスレッドがロックを獲得しているのではなく、どのスレッドもロックを獲得してい

ないということです。

Thread-0、Thraed-1ともに、同じオブジェクト“ID<0x200>”のオブジェクトをロックしているように見えます。

しかし“- locked”と表示されているスレッドが、現在のロックオーナであることは意味しません。（“- locked”の正確な意味

するところは、そのフレームにおいてロックしたということに過ぎません。）

- 232 -

先頭フレームでは、“- waiting on”と表示されています。

これは、ロックが解放されたら起こされる可能性のある“- waiting to lock”とは異なり、ロックが解放されても自動的に起こ

されることを意味しません。

Java VM制御用のスレッド

スレッドダンプにおいて、以下の名前で出力されているスレッドは、Java VM自身の制御用スレッドです。そのため、以下

の名前で出力されているスレッドの情報には、アプリケーションとしての動作状態を解析する際の直接的な情報は含まれ

ていません。

・ "Attach Listener"

・ "C2 CompilerThread*" ("*"部分は数字です)

・ "Finalizer"

・ "RAS Control Thread"

・ "Reference Handler"

・ "Signal Dispatcher"

・ "VM Periodic Task Thread"

・ "VM Thread"

・ "Low Memory Detector" (JDK/JRE 6の場合に存在します)

・ "Service Thread" (JDK/JRE 7の場合に存在します)

・ "GC task thread#* (ParallelGC)" (パラレルGC使用時に存在します) (注1)

・ "Concurrent Mark-Sweep GC Thread" (CMS付きパラレルGC使用時に存在します)

・ "Surrogate Locker Thread (Concurrent GC)" (CMS付きパラレルGC使用時に存在します)

・ "Gang worker#* (Parallel GC Threads)" (CMS付きパラレルGC使用時に存在します) (注1)

・ "Gang worker#* (Parallel CMS Threads)" (CMS付きパラレルGC使用時に存在します) (注2)

注1) "-XX:ParallelGCThreads"オプションで指定したGC処理用スレッドの数だけ存在します。なお、名前の"*"部分

は数字です。

注2) "-XX:ConcGCThreads"オプションで指定したCMS-GC処理用スレッドの数だけ存在します。なお、名前の"*"部分は数字です。

Javaヒープ領域に関する情報の出力

JDK/JRE 6、7の場合、スレッドダンプの出力と合わせて、Javaヒープ領域に関する情報も出力されます。

Javaヒープ領域に関する情報は、各ガーベジコレクション処理の違いにより、New世代領域、Old世代領域、Permanent世代領域の各領域に対応する出力文字列が異なります。

なお、パーセントで示されている値は、情報出力時点でJava VMがJavaヒープ用に利用可能な状態にしている(コミット

している)メモリ量に対する比率です。利用可能な上限値に対する比率ではありません。そのため、パーセントで示されて

いる値は参照せず、K(キロ)単位で表示されているメモリ使用量の値と、オプションで指定された値(デフォルト値を含む)とを比較する方法で各値を利用してください。

・シリアルGC使用時:「def new generation」が「New世代領域」、「tenured generation」が「Old世代領域」、「compacting perm gen」が

「Permanent世代領域」に関する情報です。

・パラレルGC使用時:「PSYoungGen」が「New世代領域」、「PSOldGen」が「Old世代領域」、「PSPermGen」が「Permanent世代領域」に関す

る情報です。

- 233 -

・ CMS付きパラレルGC使用時:「par new generation」が「New世代領域」、「concurrent mark-sweep generation」が「Old世代領域」、「concurrent-mark-sweep perm gen」が「Permanent世代領域」に関する情報です。

なお「Old世代領域」および「Permanent世代領域」における「object space」についての情報は出力されません。

出力例：

Heap

PSYoungGen total 7168K, used 5158K [0x0fd60000, 0x10470000, 0x10470000)

eden space 7104K, 72% used [0x0fd60000,0x102658f0,0x10450000)

from space 64K, 25% used [0x10450000,0x10454000,0x10460000)

to space 64K, 0% used [0x10460000,0x10460000,0x10470000)

PSOldGen total 4096K, used 162K [0x0c470000, 0x0c870000, 0x0fd60000)

object space 4096K, 3% used [0x0c470000,0x0c498870,0x0c870000)

PSPermGen total 16384K, used 2103K [0x08470000, 0x09470000, 0x0c470000)

object space 16384K, 12% used [0x08470000,0x0867dd40,0x09470000)

8.5.4 クラスのインスタンス情報出力機能

図1のオプションを指定したJavaプロセスに対してスレッドダンプ出力の操作を行った場合、スレッドダンプの出力に続

いて、Javaヒープ内に生存する各クラスのインスタンス情報が図2の形式で出力されます。FJVMでは、当該機能を「クラ

スのインスタンス情報出力機能」として実装しています。

クラスのインスタンス情報として、クラス毎のインスタンス数および合計サイズが出力されるため、Javaヒープ内におけるメ

モリリークなどの調査で利用することができます。

クラスのインスタンス情報の出力先は、標準出力です。クラスのインスタンス情報が出力される契機および出力先は、

“8.5.3 スレッドダンプ”が出力される契機および出力先と同じです。

なお、-Xloggcオプションの指定がある場合は、クラスのインスタンス情報の出力先が標準出力から-Xloggcオプションで

指定したファイルへ切り替わります。

図1 スレッドダンプに続いて、クラスのインスタンス情報を出力する機能を有効にするオプション

-XX:+PrintClassHistogram

図2 クラスのインスタンス情報の出力形式

num #instances #bytes class name

----------------------------------------------

$1: $2 $3 $4

:

(略)

:

Total $5 $6


$1: 順位

クラスのインスタンス情報は、各クラスのインスタンスの合計サイズが大きい順に、ソートされて出力されます。

$2: クラスのインスタンス数

$3: クラスのインスタンスの合計サイズ

$4: クラス名

$5: $2の値の合計

$5: $3の値の合計

- 234 -

クラスのインスタンス情報出力機能では、不要なインスタンスを排除した後の情報を採取・出力します。そのため、事前処

理としてFullGCを実行します。クラスのインスタンス情報出力の過度の使用は、FullGCの多発となるので注意してくださ

い。

クラスのインスタンス情報出力に先立って行われるはずのFullGCが、ガーベジコレクション処理の実行抑止により実行で

きない状態にある場合は、図3のメッセージを標準出力へ出力した後、クラスのインスタンス情報出力の要求は取り消され

ます。

図3 クラスのインスタンス情報出力要求が取り消された場合に出力されるメッセージ

The PrintClassHistogram operation was canceled because GC could not be run.

8.5.5 java.lang.System.gc()実行時におけるスタックトレース出力機能

Javaアプリケーションが以下のJavaメソッドを頻繁に実行すると、Java VMに負荷がかかり、アプリケーションの応答性能

を低下させる要因になることがあります。

・ java.lang.System.gc()

・ java.lang.Runtime.gc()

以降、java.lang.System.gc()(以降、System.gc()と略する)で代表して説明します。

FJVMでは、Javaアプリケーション実行時にSystem.gc()メソッドの実行状態の確認ができるように、当該メソッドを実行し

たJavaスレッドのスタックトレースを出力する機能を「java.lang.System.gc()実行時におけるスタックトレース出力機能」とし

て実装しています。

java.lang.System.gc()実行時におけるスタックトレース出力機能は、図1のオプションを指定した場合に有効となります。

本機能が有効な場合、Javaアプリケーション内でSystem.gc()メソッドが実行された場合には、当該メソッドを実行したJavaスレッドのスタックトレース情報が、図2のような形で標準出力へ出力されます。

なお、標準出力への出力結果は、FJVMのログ情報としてファイルへも格納されます。また“-verbose:gc”オプション指

定などでガーベジコレクション処理の結果ログ出力を指定していた場合は、java.lang.System.gc()実行時におけるスタッ

クトレース出力後に出力された結果ログ出力も、合わせてファイルへ格納されます。ファイル名や格納先はJava VM異常

終了時のログ出力時と同じです。“8.5.8 FJVMログ”を参照してください。

図1 java.lang.System.gc()実行時におけるスタックトレース出力機能を有効にするオプション

-XX:+PrintJavaStackAtSystemGC

図2 java.lang.System.gc()実行時におけるスタックトレース出力機能による出力例

"main" prio=10 tid=0x087c1c00 nid=0xd2a runnable [0xb75ab000..0xb75ab214]

java.lang.Thread.State: RUNNABLE

at java.lang.Runtime.gc(Native Method)

at java.lang.System.gc(System.java:928)

at SystemGC.main(SystemGC.java:8)

"main" prio=10 tid=0x087c1c00 nid=0xd2a runnable [0xb75ab000..0xb75ab214]


at java.lang.Runtime.gc(Native Method)

at SystemGC.foo(SystemGC.java:4)

at SystemGC.main(SystemGC.java:10)

図2の出力例の場合、SystemGC.mainからjava.lang.System.gc()が実行され、SystemGC.fooからjava.lang.Runtime.gc()が実行されたことを確認することができます。

- 235 -

JDK/JRE 6からスタックトレース情報にスレッドの状態を表す情報（トレース情報の前の行）が表示されるようになりまし

た。

図中の例では「 java.lang.Thread.State: RUNNABLE 」となっていますが、 "RUNNABLE" の部分

が、 "NEW"、 "TIMED_WAITING (sleeping)"、 "WAITING (on object monitor)"、 "TIMED_WAITING (on objectmonitor)" 、 "WAITING (parking)" 、 "TIMED_WAITING (parking)" 、 "BLOCKED (on objectmonitor)"、"TERMINATED"、"UNKNOWN"などの表示の場合があります。

8.5.6 Java VM終了時における状態情報のメッセージ出力機能

特別なメッセージ出力などがないまま、Javaプロセスが予想外の状態で終了してしまった場合の原因の1つとして、Javaアプリケーションが以下のいずれかの処理を実行した場合が考えられます。

・ java.lang.System.exit()を予想外の箇所で実行した

・ java.lang.Runtime.exit()を予想外の箇所で実行した

・ java.lang.Runtime.halt()を予想外の箇所で実行した

以降は、java.lang.System.exit()(以降、System.exit()と略する)で代表して説明します。

System.exit()の実行によりJavaアプリケーションが明示的にJavaプロセスを終了させた場合、Java VM側から見ると正常

な仕様動作であるため、Java VMとして特別なメッセージ出力などは行いません。このため、ソースがないなど、内部処

理動作の詳細が不明なJavaアプリケーションが予想外の状態で終了した場合には、ソース確認などが行えないため、

System.exit()が実行されたかどうかを確認することができません。

このためFJVMでは、Javaプロセス終了時にSystem.exit()が実行されたかどうかを確認可能にするための機能を、「JavaVM終了時における状態情報のメッセージ出力機能」として実装しています。

Java VM終了時における状態情報のメッセージ出力機能は、図1のオプションを指定した場合に有効となります。

図1 Java VM終了時における状態情報のメッセージ出力機能を有効にするオプション

-XX:+VMTerminatedMessage

本機能が有効な場合、JavaプロセスがSystem.exit()の実行で終了した場合には、System.exit()を実行したスレッドのス

タックトレース情報などが、図2のような形で標準出力へ出力されます。スタックトレース情報の出力の有無および内容を

確認することにより、System.exit()実行の有無を確認することができます。

なお、標準出力への出力結果は、FJVMのログ情報としてファイルへも格納されます。ファイル名や格納先はJava VM異常終了時のログ出力時と同じです。“8.5.8 FJVMログ”を参照してください。

そして、本機能が有効な場合で、かつJavaプロセス終了時に図2のようなスタックトレースの情報が出力されなかった場

合(「#### JavaVM terminated: …」から始まるメッセージ出力だけの場合)は、System.exit()が使用されず、Javaアプリケー

ション側の制御論理として終了したと考えられます。

また、本機能が有効な場合で、かつJavaプロセス終了時に図2のような情報が何も出力されなかった場合は、ネイティブ

モジュールの中からCランタイムのexit()関数呼び出しによりJavaプロセスが終了したなど、別原因によるJavaプロセスの終

了だと考えられます。

図2 Java VM終了時における状態情報のメッセージ出力機能による出力例

Thread dump at JVM_Halt(status code=1234):

"main" prio=3 tid=0x00030000 nid=0x2 runnable [0xfe5ff000..0xfe5ffd80]


at java.lang.Shutdown.halt0(Native Method)

at java.lang.Shutdown.halt(Shutdown.java:105)

- locked <0xfa81e7d0> (a java.lang.Shutdown$Lock)

at java.lang.Shutdown.exit(Shutdown.java:179)

- locked <0xf3dc8dd8> (a java.lang.Class for java.lang.Shutdown)

at java.lang.Runtime.exit(Runtime.java:90)

at java.lang.System.exit(System.java:906)

at JVM_Halt.main(JVM_Halt.java:5)

#### JavaVM terminated: Java HotSpot(TM) Server VM

(**.*.**_FUJITSU_MODIFIED-B** mixed mode), [pid=29500] TimeMillis=1243580170483

Time=Fri May 29 15:56:10 2012

- 236 -

図2の出力例の場合、JVM_Halt.main()がSystem.exit()を実行し、その結果としてJavaプロセスが終了したことを確認す

ることができます。


た。



この情報はJava VM終了時における状態の判定には使用しません。

8.5.7 ログ出力における時間情報のフォーマット指定機能

以下のオプションで出力されるログに含まれる「ログ出力時の時間」情報のフォーマットを、図1のオプションで指定する

ことができます。

図1のオプションによる指定がない場合、ログ出力時の時間は「Java VMが起動されてからの経過時間(秒)」(「-XX:FJverboseTime=type1」が指定された場合の形式)で出力されます。

・ガーベジコレクションのログ出力

-verbosegc -XX:+UseFJverbose

・動的コンパイル発生状況のログ出力機能

-XX:+PrintCompilationCPUTime-XX:+FJPrintCompilation

図1 ログ出力における時間情報のフォーマットを指定するオプション

-XX:FJverboseTime=タイプ

タイプとして以下の値が指定できます

type1type2type3

-XX:FJverboseTime=type1が指定された場合

ログ出力時の時間を、「Java VMが起動されてからの経過時間(秒)」で示します。

例) 0.165:


ログ出力時の時間を、「日時(iso8601フォーマット)」で示します。

例) 2010-10-01T13:37:36.881+0900:


ログ出力時の時間を、「日時(iso8601フォーマット)」とJava VMが起動されてからの「経過時間(秒)」で示します。出力順

序は、「日時」「経過時間」です。

例) 2010-10-01T13:37:45.830+0900: 0.164:

8.5.8 FJVMログ

FJVMでは「Java VM異常終了時のログ出力機能」の強化を行っています。

何らかの原因でJavaプロセスが異常終了した場合、Java VM異常終了時のログとしてFJVMログが出力されます。

Javaプロセスが異常終了した原因の調査のために、このFJVMログを活用することができます。

- 237 -

■FJVMログの出力先

FJVMログは、Javaプロセスのカレントディレクトリに、図1のファイル名で出力されます。

図1 FJVMのファイル名

fjvm_pid***.log (***は異常終了したJavaプロセスのプロセスID)

IJServerクラスタ使用時のカレントディレクトリの詳細は、“Java EE運用ガイド”の“IJServerクラスタ”を参照してください。

IJServer使用時のカレントディレクトリの詳細は、“J2EE ユーザーズガイド(旧版互換)”の“J2EEアプリケーションが運用さ

れる環境(IJServer)”を参照してください。

■FJVMログの調査

FJVMログとしてJavaプロセス異常終了時の各種情報が格納されますが、その中から以下の情報を原因調査用の情報

として使用することができます。

・異常終了箇所の情報

・異常終了時のシグナルハンドラ情報(Solaris版/Linux版)

・異常終了時のJavaヒープに関する情報

各情報の内容について、以下で説明します。

8.5.8.1 異常終了箇所の情報

異常終了箇所に関する図1の情報が確認できます。

図1 異常終了箇所に関する情報

1. 異常終了時に発生した例外に関する情報(シグナルコードおよび例外発生アドレス)

「Unexpected Signal :」から始まる情報です。

2. 異常終了した関数名(実際には異常終了したアドレスに一番近いシンボル名) 「Function name=」から始まる情報です。

3. 異常終了した関数を含むライブラリ名

「Library=」から始まる情報です。

4. 異常終了時のJavaスレッドのスタックトレース

「Current Java thread:」から始まる情報です。

5. 異常終了時のダイナミックライブラリ一覧

「Dynamic libraries:」から始まる情報です。

6. 発生時間

「Local Time =」から始まる情報です。

■調査手順

まず、図1の1～3の情報で異常終了した関数を特定し、実行しているJavaアプリケーションから呼び出す関数かどうかを

確認します。ただし、図1の2の異常終了した関数名として出力される名前は、異常終了したアドレスに一番近いシンボル

名情報であるため、実際に異常終了した関数とは別の名前が出力されている場合がありますので注意してください。

そして、実行しているJavaアプリケーションが使用する関数の場合には、当該関数使用に際して何らかの問題がないか

確認します。

実行しているJavaアプリケーションで使用していない関数の場合には、図1の4のスタックトレースを調査します。

スタックトレース情報の初のメソッドがネイティブメソッドだった場合（メソッド名の後ろに「(Native Method)」が付加されて

いる場合）はJNI処理に関係した問題である可能性が高いため、スタックトレース情報で出力された処理のJNI処理に関

わる制御で何らかの問題がないか確認します。

- 238 -

また異常終了した関数を含むライブラリ名が利用者作成のライブラリである場合は、利用者側作成のライブラリ内の問

題である可能性が高いため、当該ライブラリ内の処理および当該ライブラリを呼び出すJNI処理に何らかの問題がないか

確認します。

スタックトレースの調査方法は、“8.5.1 スタックトレース”を参照してください。

■スタックオーバーフローの検出

図1の1の異常終了時に発生した例外に関する情報に、図2のシグナルコードの表記がある場合、例外が発生したスレッ

ドでスタックオーバーフローが発生した（図2の１、３の表記）、または発生した可能性がある（図2の２、４の表記）ことを示

しています。

この場合、例外が発生したスレッドに対するスタックのサイズを大きくすることで問題が解決する可能性があります。

スタックオーバーフロー発生の原因が、Java APIで生成されたスレッドに対するスタックのサイズにある場合は、“8.4.2スタックのチューニング”を参照して、Java APIで生成されるスレッドに対するスタックのサイズをチューニングしてくださ

い。

図2 スタックオーバーフローを示すシグナルコード

1)「EXCEPTION_STACK_OVERFLOW」

2)「EXCEPTION_ACCESS_VIOLATION (Stack Overflow ?)」

3)「SIGSEGV (Stack Overflow)」4)「SIGSEGV (Stack Overflow ?)」

ワトソンログの分析

スタックオーバーフローが原因で発生した異常終了の場合、OS側からFJVM側の処理へ制御が渡らず、そのままワトソ

ン博士へ制御が渡されることがあります。この場合は、FJVMログが出力されないため、ワトソン博士のログファイルを確

認してください。

ワトソンログに図3の例外番号が出力されている場合には、スタックオーバーフローが原因と考えられます。


図3 スタックオーバーフローを示す例外番号

c00000fd (スタックオーバーフロー)

8.5.8.2 異常終了時のシグナルハンドラ情報 Java VMの実行制御で必要となる“表8.10 Java VMの制御で必要となるシグナル”の各シグナルに対するシグナルハン

ドラ情報が確認できます。

表8.10 Java VMの制御で必要となるシグナル

Solaris版Java VM Linux版Java VM

SIGSEGVSIGPIPESIGBUSSIGILLSIGFPEINTERRUPT_SIGNAL (デフォルトは

SIGUSR1)ASYNC_SIGNAL (デフォルトはSIGUSR2)SIGQUIT (注1)SIGINT (注1)SIGHUP (注1)

SIGSEGVSIGPIPESIGBUSSIGILLSIGFPEINTERRUPT_SIGNAL (デフォルトは

SIGUSR1) (注2)SR_SIGNUM (デフォルトはSIGUSR2)SIGQUIT (注1)SIGINT (注1)SIGHUP (注1)

- 239 -

Solaris版Java VM Linux版Java VM

SIGTERM (注1)SIGXFSZ (注3)

SIGTERM (注1)SIGXFSZ (注3)

注1) -Xrsオプションで操作対象となるシグナルです。

注2) Java VMでリザーブしているシグナルです。

注1)および注2)のシグナルに関するシグナルハンドラ情報は出力しません。

注3) JDK/JRE 6、７のJava VMで使用されているシグナルです。

シグナルハンドラ情報として、以下の情報が出力されています。

・登録されているシグナルハンドラのアドレス

・登録されているシグナルハンドラがJava VMで登録したシグナルハンドラかどうかの正否情報(Java VM以外の処理

で登録されたシグナルハンドラの場合には、該当するシグナルハンドラ情報の行に“(not in VM)”が出力されます)

“表8.10 Java VMの制御で必要となるシグナル”のシグナルハンドラがJava VM以外の処理で登録されていた場合、JavaVMは正常に動作しません。この場合、当該シグナルハンドラを登録しないようにアプリケーションを修正してください。

8.5.8.3 異常終了時のJavaヒープに関する情報

異常終了時のJavaヒープの使用状況が確認できます。

Javaヒープのサイズによる異常終了の場合、異常終了時にどのJavaヒープの枯渇により異常終了が発生したのかが確

認できます。

8.5.8.4 出力例と調査例

ここでは、Solaris版JDK/JRE 6での出力例を元に説明します。

--------------------------------------------------------------------------------

#### Java VM: Java HotSpot(TM) Server VM (**.*.**_FUJITSU_MODIFIED-B**[*****] mixed mode)

>>>> Logging process start. [pid=27758] Time=Wed May 30 19:48:01 2012

(1) 異常終了箇所の情報

異常終了箇所に関する情報が確認できます。

libjvm.soのsysThreadAvailableStackWithSlack関数の近くでSIGSEGV(メモリアクセスで不

正なセグメントを参照)が発生しています。

本例の場合、Java VM内で異常が発生していると判断します。

異常終了箇所がJavaアプリケーション内でないため、異常発生時のスタックトレース情報を

調査します。

本例の場合、com.appli.ap.business.AL02ABB00000.toStringの延長で不正なアクセスが発

生しているので、そこからAL02ABB00000.javaの489行目で不正なアクセスを招きそうな箇

所がないか調べます。

Unexpected Signal : SIGSEGV [0xb] occurred at PC=0xff092068, pid=27758, nid=1

Function name=sysThreadAvailableStackWithSlack

Library=/opt/FJSVawjbk/jdk6/jre/lib/sparc/fjvm/libjvm.so

Current Java thread:

0xfb8e2850 - 0xfb8e4b7c at com.appli.ap.business.AL02ABB00000.toString(AL02ABB00000.java:489)

0xfb8e2850 - 0xfb8e4b7c at com.appli.ap.business.AL02ABB00000.toString(AL02ABB00000.java:520)

at java.lang.String.valueOf(String.java:1942)

at java.lang.StringBuffer.append(StringBuffer.java:365)

- locked <f6db38d8> (a java.lang.StringBuffer)

at com.appli.ap.business.AL02ABB25201.doExecute(AL02ABB25201.java:774)

at com.appli.ap.formula.AFCC6842.doDelegate(AFCC6842.java:221)

at com.appli.ap.formula.ejb.session.AFSF6801.doExecuteOrdinarily(AFSF6801.java:381)

- 240 -

at

com.appli.ap.formula.ejb.session.FJAFSF6801_AFSF6801RemoteImpl.doExecuteOrdinarily(FJAFSF6801_AFSF6801Remote

Impl.java:464)

- locked <df672838> (a com.appli.ap.formula.ejb.session.FJAFSF6801_AFSF6801RemoteImpl)

at

com.appli.ap.formula.ejb.session._FJAFSF6801_AFSF6801RemoteImpl_Tie._invoke(_FJAFSF6801_AFSF6801RemoteImpl_T

ie.java:76)

0xfb98c930 - 0xfb98cc68 at com.fujitsu.ObjectDirector.CORBA.ServerRequest.call_invoke(ServerRequest.java:961)

at com.fujitsu.ObjectDirector.PortableServer.POA.MsgRecv(POA.java:2578)

at com.fujitsu.ObjectDirector.PortableServer.POAManager.MsgRecv(POAManager.java:1061)

at com.fujitsu.ObjectDirector.PortableServer.POAnc.MsgRecv(POAnc.java:163)

Dynamic libraries:

0x10000 /opt/FJSVawjbk/jdk6/bin/java

0xff370000 /usr/lib/libthread.so.1

0xff3fa000 /usr/lib/libdl.so.1

～～～～～～～

略

～～～～～～～

0xbef70000 /lib/libgen.so.1

0xbd6b0000 /lib/libextpiswu.so

Local Time = Wed May 30 19:48:01 2012

Elapsed Time = 9885

注意:

Error IDの行が出力されている場合、Error IDとして出力されている値は、Java VMが内部

処理矛盾を自己検出した場合に出力する内部情報コードです。SIGSEGVやSIGBUSなど

OSが検出した異常の場合には、常に同じ値(4F530E435050****)が出力されます。そのた

めError IDの先頭が「4F530E435050」で始まるコードの場合は、通常、意味を持ちません。

Error IDの先頭が「4F530E435050」以外で始まるコードの場合には、障害情報検索時や判

断時のキーワード情報としての意味を持ちます。

#

# HotSpot Virtual Machine Error : SIGSEGV (0xb)

# [ pc=0xff092068, pid=27758(0x6c6e), nid=1(0x00000001), tid=0x00034d10 ]

#

# Please report this error to FUJITSU

#

# JRE version: 6.0-b04

# Java VM: Java HotSpot(TM) Server VM (**.*.**_FUJITSU_MODIFIED-B** mixed mode solaris-sparc )

～～～～～～～

略

～～～～～～～

(2)異常終了時のシグナルハンドラ情報

異常終了時のシグナルハンドラに関する情報が確認できます。

本例では、すべて「(in VM)」表示なので、シグナルハンドラの登録変更に関する問題はあ

りません。

##>> Signal Handlers

VM signal handler[1]=0xfe1ec0a0, VM signal handler[2]=0xfe4ff780, SIG_DFL= 0x00000000, SIG_IGN=0x00000001,

INT_SIG=(16,16), ASYNC_SIG=(17,17)

SIGSEGV :signal handler=0xfe4ff780 (in VM *)

SIGPIPE :signal handler=0xfe1ec0a0 (in VM)

SIGBUS :signal handler=0xfe1ec0a0 (in VM *)

SIGILL :signal handler=0xfe1ec0a0 (in VM)

- 241 -

SIGFPE :signal handler=0xfe1ec0a0 (in VM)

SIGXFSZ :signal handler=0xfe1ec0a0 (in VM)

INTERRUPT_SIGNAL :signal handler=0xfe4ff010 (in VM +)

ASYNC_SIGNAL :signal handler=0xfe1ec0a0 (in VM)

(3)異常終了時のJavaヒープ領域に関する情報

異常終了時のJavaヒープ領域に関する情報が確認できます。

JDK/JRE 6、7のFJVMの場合：

パラレルGC使用時: 「PSYoungGen」が「New世代領域」、

「PSOldGen」が「Old世代領域」、

「PSPermGen」が「Permanent世代領域」

に関する情報です。

CMS付きパラレルGC使用時: 「par new generation」が「New世代領域」、

「concurrent mark-sweep generation」が「Old世代領域」、

「concurrent-mark-sweep perm gen」が「Permanent世代領域」


なお「Old世代領域」および「Permanent世代領域」における「object space」についての情

報は出力されません。

シリアルGC使用時: 「def new generation」が「New世代領域」、

「tenured generation」が「Old世代領域」、

「compacting perm gen」が「Permanent世代領域」


本例の場合、異常終了時点における「New世代領域」＋「Old世代領域」の領域(-Xmxで

大量が指定される領域)には、空きがあることがわかります。

また「Permanent世代領域」に対しても、余裕があることがわかります。

注意: パーセントで示されている値は、異常終了した時点でFJVMがJavaヒープ用に利用可能な

状態にしている(コミットしている)メモリ量に対する比率です。利用可能な上限値に対する比

率ではありません。

パーセントで示されている値は参照せず、K(キロ)単位で表示されているメモリ使用量の値

と、オプションで指定された値(デフォルト値を含む)とを比較して判断してください。

注意：

パラレルGCを使用していた場合、以下の「-Xms=」「-Xmx=」に続いて表示される値は、-Xmsオプション/-Xmxオプションで指定された値およびページサイズなどのシステム情報を

元に、Java VMが適となるよう初期値/ 大値を計算し直し、実際にJava VMが使用した値

が出力されます。そのため、指定された値と異なる場合があります。

##>> Heap

PSYoungGen total 3584K, used 277K [0xfa400000, 0xfa800000, 0xfbc00000)

eden space 3072K, 9% used [0xfa400000,0xfa4457b0,0xfa700000)

from space 512K, 0% used [0xfa780000,0xfa780000,0xfa800000)

to space 512K, 0% used [0xfa700000,0xfa700000,0xfa780000)

PSOldGen total 4096K, used 0K [0xf7800000, 0xf7c00000, 0xfa400000)

object space 4096K, 0% used [0xf7800000,0xf7800000,0xf7c00000)

PSPermGen total 16384K, used 2520K [0xf3800000, 0xf4800000, 0xf7800000)

- 242 -

object space 16384K, 15% used [0xf3800000,0xf3a762e0,0xf4800000)

(-Xms=8192K, -Xmx=65536K, -XX:PermSize=16384K, -XX:MaxPermSize=65536K)

8.5.9 クラッシュダンプ・コアダンプ

Javaアプリケーションが異常終了(プロセスが消滅)したときに、各OS上に用意されたクラッシュダンプやコアダンプを採

取することにより、異常終了の原因を調査することができる場合があります。

8.5.9.1 クラッシュダンプ

ここでは、Windows(R)上で異常を調査する場合に採取する、クラッシュダンプの採取方法を説明します。

■ワトソン博士について

ワトソン博士はMicrosoft Corporationのソフトウェアで、プログラムエラーのためのデバッガです。

プログラムエラーが発生すると、ワトソン博士が自動的にログファイルにデバッグ情報を出力します。なお、ログファイル

名は、「drwtsn32.log」です。また、ログファイルの出力先は、ワトソン博士を起動して、設定することができます。

ワトソン博士の詳細は、Microsoft CorporationのWebページを参照してください。

■ワトソン博士の設定

クラッシュダンプの採取には、Windows(R)に同梱されている「ワトソン博士」を使用します。

次の例を参考にして、「ワトソン博士」を設定してください。この設定を行うことにより、異常終了時に、自動的にクラッシュ

ダンプが出力されるようになります。

ワトソン博士の設定例 (Windows Server(R) 2003、Windows(R) XPの場合)

1. MS-DOSコマンドプロンプトなどで“drwtsn32 -i”コマンドを投入します。[ワトソン博士が既定のアプリケーションデバッガとしてインストールされました。]のメッセージが表示されます。

2. 更に、MS-DOSコマンドプロンプトなどで、“drwtsn32”コマンドを実行します。[Windows ワトソン博士]の設定画面

が表示されますので、以下を確認してください。

－ [ログファイルパス(L)]、[クラッシュダンプ(P)]が正しく指定されているか

－ [クラッシュダンプの種類(Y)]を[完全]と設定しているか

－ [すべてのスレッドコンテキストをダンプ(A)]のチェックボックスがチェックされているか

－ [既定のログファイルに追加(E)]のチェックボックスがチェックされているか

－ [メッセージボックスによる通知(U)]のチェックボックスがチェックされているか

－ [クラッシュダンプファイルの作成(T)]のチェックボックスがチェックされているか

Windows Server(R) 2003 x64 Editionの場合

32ビットモード版のワトソン博士の環境設定を行う場合は、MS-DOSコマンドプロンプトなどで“%SystemRoot%\SysWow64\drwtsn32”コマンドを実行し、上述と同様の設定をしておく必要があります。

Windows Vista(R) SP1、Windows(R) 7、Windows Server(R) 2008、Windows Server(R) 2008 R2の場合

Windows Vista（R）、Windows(R) 7、Windows Server(R) 2008、Windows Server(R) 2008 R2ではワトソン博士の機能が

提供されていません。

ワトソン博士の代わりにWindowsエラー報告（Windows Error Reporting（WER））の機能を使用します。

次の例を参考にして、WERを設定してください。

- 243 -

WERの設定例

1. MS-DOSコマンドプロンプトなどで“regedit”コマンドを投入し、レジストリエディタを起動します。

2. 「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps」キー

を作成します。

3. LocalDumpsキーにREG_DWORD型でDumpTypeという値を作成し、「2」を設定します。

WERに関する設定の方法については、以下の情報も参照ください。

・富士通製サーバ製品の場合：

http://primeserver.fujitsu.com/primergy/soft/ssupportguide/

・上記製品以外の場合：

http://msdn.microsoft.com/en-us/library/bb787181.aspx

■注意事項

Windows Server(R) 2003の初期版においては、ユーザダンプが出力されない問題をはじめとして、その他にもJavaの実

行動作に影響を及ぼす問題などがあります。

たとえば、次のような問題があります。

・ http://support.microsoft.com/kb/836080/en-us



Windows Server(R) 2003を使用する場合は、Service Pack 1以降またはHotfixを適用してください。

8.5.9.2 コアダンプ（Solaris）

ここでは、Solaris上でのコアダンプ採取のための注意事項を説明します。

■コアダンプが出力されない場合の確認

コアダンプが出力されない場合の原因として、システムリソース等の問題がまず考えられます。カレントディレクトリの書

込み権、ディスク容量、limit(1)コマンド結果を確認してください。

8.5.9.3 コアダンプ（Linux）

ここでは、Linux上でのコアダンプ採取のための注意事項を説明します。

■コアダンプが出力されない場合の確認

コアダンプが出力されない場合の原因として、システムリソース等の問題がまず考えられます。カレントディレクトリの書

込み権、ディスク容量、limit(1)コマンド結果を確認してください。

また、Linuxではハード/OSの出荷時もしくはOSのUpdate適用により、デフォルトでコアダンプの出力が設定されていな

い場合があります。以下を実施してコアダンプが出力されるようにしてください。

《コアダンプ出力設定方法》

・ isstartコマンドでInterstageを起動させる場合

- 244 -

sh(bash)で"ulimit -c unlimited"コマンド実行後、Interstageを起動させます。ワークユニット起動ユーザがInterstage起動

ユーザと違う場合は、ワークユニット起動前に"ulimit -c unlimited"コマンドを実行してから、ワークユニットを起動させま

す。

・ RCプロシジャでOS起動時に自動的にInterstageが起動するように設定されている場合

以下の方法を実施することで、OS再起動後にcoreが出力されるようになります。

/etc/init.d/functionsファイルに、

# make sure it doesn't core dump anywhere; while this could mask

# problems with the daemon, it also closes some security problems

ulimit -S -c 0 >/dev/null 2>&1

または、

ulimit -S -c ${DAEMON_COREFILE_LIMIT:-0} >/dev/null 2>1

と記述されていますので、上記の設定で"0"を、"unlimited"に変更してください。

ulimit -S -c unlimited >/dev/null 2>&1

/etc/rc2.d/S99startisに、以下の<---の記述を追加してください。

#!/bin/sh# Interstage Application Server

# S99starttis : Interstage Application Server start procedure

OD_HOME=/opt/FJSVod

export OD_HOME

ulimit -c unlimited <---

/opt/FJSVod/bin/odalive > /dev/null

while [ "$?" != "0" ]

do

sleep 1

/opt/FJSVod/bin/odalive > /dev/null

done

/opt/FJSVtd/bin/isstart

8.5.10 JNI処理異常時のメッセージ出力

Java以外の言語と連携する場合、Java Native Interface(JNI)を使用します。

しかし、JNIの使用方法を誤ると、Javaプロセスの終了(異常終了)などの原因となります。

このとき、図1のオプションを指定することにより、JNI処理で異常が発生した場合にメッセージが出力されますので、JNIのパラメーターなどの確認に活用してください。

図1 JNI処理異常時にメッセージを出力するオプション

-Xcheck:jni

上記の“-Xcheck:jni”パラメーターを指定したときに、図2のメッセージが出力されることがあります。

図2 JNI処理異常時に出力されるメッセージ

FATAL ERROR in native method: (詳細メッセージ)

“(詳細メッセージ)”の部分には、以降で説明する文字列が出力されます。

以降、図2の“詳細メッセージ”が出力される例と注意事項を説明します。

以降の説明を参考にして、JNIの処理部分を見直してください。

- 245 -

■メッセージの説明

JNI received a class argument that is not a class

[異常例]

char buf[1];(*env)->AllocObject(env, (jclass)buf); //jclass型の第2引数に違う型を指定

JNI received a null class

[異常例]

(*env)->AllocObject(env, NULL); //jclass型の第2引数にnullを指定

JNI string operation received a non-string

[異常例]

(*env)->GetStringUTFChars(env, NULL, 0); //jstring型の第2引数にNULLを指定

Non-array passed to JNI array operations

[異常例]

(*env)->GetArrayLength(env, (jarray)(*env)->NewStringUTF(env, "abc")); //jarray型の

第2引数に配列でない型を指定

[注意事項] 次の場合は、“-Xcheck:jni”オプションによるメッセージは出力されません。

char buf[1];(*env)->GetArrayLength(env, (jarray)buf);

Static field ID passed to JNI

[異常例]

jclass cls = (*env)->GetObjectClass(env, obj);jfieldID fid = (*env)->GetFieldID(env, cls, "static_data", "I"); (*env)->GetIntField(env,obj, fid); //jfieldID型の第3引数にstaticフィールドを指定

Null object passed to JNI

[異常例]

jclass cls = (*env)->GetObjectClass(env, obj);jfieldID fid = (*env)->GetFieldID(env, cls, "instance_data", "I");(*env)->GetIntField(env, NULL, fid); //object型の第2引数にNULLを指定

[注意事項] instance変数かどうかのチェック時のみに出力されるメッセージです。

次の場合は、“-Xcheck:jni”オプションによるメッセージは出力されません。

(*env)->GetObjectClass(env, NULL); //objectの第2引数にNULLを指定

Wrong field ID passed to JNI

[異常例]

(*env)->GetIntField(env, obj, -1); //jfieldID型の第3引数に数値を指定

- 246 -

[注意事項] instance変数かどうかのチェック時のみに出力されるメッセージです。

Non-static field ID passed to JNI

[異常例]

jclass cls = (*env)->GetObjectClass(env, obj);(*env)->GetStaticIntField(env, cls, -1); //jfiedlID型第2引数に数値を指定

[注意事項] 次の場合は、“-Xcheck:jni”オプションによるメッセージは出力されません。

jclass cls = (*env)->GetObjectClass(env, obj);jfieldID fid = (*env)->GetStaticFieldID(env, cls, "instance_data", "I");(*env)->GetStaticIntField(env, cls, fid);

Array element type mismatch in JNI

[異常例]

jintArray intarray = (*env)->NewIntArray(env, 2);(*env)->GetFloatArrayElements(env, intarray, 0); //floatArray型の第2引数にjintArrayを

指定

Object array expected but not received for JNI array operation

[異常例]

jclass cls = (*env)->GetObjectClass(env, obj);jobjectArray objarray = (*env)->NewObjectArray(env, 1, cls, obj);(*env)->GetIntArrayElements(env, objarray, 0); //intArray型の第2引数にjobjectArray型

を指定

Field type (static) mismatch in JNI get/set field operations

[異常例]

jclass cls = (*env)->GetObjectClass(env, obj);jfieldID fid = (*env)->GetStaticFieldID(env, cls, "static_data", "I");(*env)->GetStaticFloatField(env, cls, fid); //GetStaticFloatFieldではなくGetStaticIntFieldでなければならない

Field type (instance) mismatch in JNI get/set field operations

[異常例]

jclass cls = (*env)->GetObjectClass(env, obj);jfieldID fid = (*env)->GetFieldID(env, cls, "instance_data", "I");(*env)->GetFloatField(env, obj, fid); //GetFloatFieldではなくGetIntFieldでなければならな

い

Wrong static field ID passed to JNI

[異常例]

jclass cls = (*env)->GetObjectClass(env, obj);jclass cls2 = (*env)->GetObjectClass(env, (*env)->NewStringUTF(env, "abc"));jfieldID fid = (*env)->GetStaticFieldID(env, cls, "static_data", "I");(*env)->GetStaticObjectField(env, cls2, fid); //第2引数はcls2ではなくclsでなければなら

ない

- 247 -

Using JNIEnv in the wrong thread

[解説]

実行しているスレッドのためのものではないJNIEnvを使用したためのエラーです。

Java VMは、JNIインタフェースポインタ(JNIEnv)が参照する領域を、スレッド固有のデータ領域に割り当てることが

あります。このため、JNIインタフェースポインタは、カレントスレッドに対してのみ有効です。ネイティブメソッドは、JNIインタフェースポインタを別のスレッドに渡すといった使い方はできません。

JNI call made with exception pending

[解説]

ネイティブプログラムで何らかの例外が発生後、その例外を処理せずに引き続きJNI関数を実行したためのエラーです。

ネイティブプログラムでJNI関数を呼び出した後は、その都度ExceptionOccurredを使用して例外の発生状況をチェッ

クし、必要に応じて、例外のクリア、または、例外を上位メソッドへスローしてください。

8.6 異常発生時の原因振り分け

本項では、異常が発生したときに、原因を振り分ける方法を説明します。

8.6.1 java.lang.OutOfMemoryErrorがスローされた場合

本節では、OutOfMemoryErrorがスローされた場合、考えられる原因とその対処方法を説明します。

なお、OutOfMemoryErrorがスローされた場合に出力されるメッセージ情報については、“8.6.1.1 メモリ領域不足事象発

生時のメッセージ出力機能の強化”も参照してください。

■想定される原因(メモリリーク)

VMがガーベジコレクションを繰り返しても、時間の経緯とともにメモリ消費量が増大していく場合、プログラム中メモリリー

クを起こしている可能性があります。

メモリリークの結果、Javaのヒープ不足が発生しOutOfMemoryErrorがスローされる場合があります。

この場合、ガーベジコレクションのログを採取して、Javaヒープの消費状況を確認してください。ガーベジコレクションの

ログを採取する方法は、“8.2.6 ガーベジコレクションのログ出力”を参照してください。

■想定される原因(Javaヒープ不足)

通常、OutOfMemoryErrorは、Javaヒープ不足が原因でスローされます。

ガーベジコレクションのログを採取して、Javaヒープの消費状況を確認してください。

Javaヒープの空き容量がないことが確認されたら、Javaヒープをチューニングしてください。

ガーベジコレクションのログを採取する方法は、“8.2.6 ガーベジコレクションのログ出力”を参照してください。

Javaヒープのチューニング方法は、“8.4.1 Javaヒープのチューニング”を参照してください。

■想定される原因(ユーザ空間不足)

多量のスレッドを生成して、多量のスタックがユーザ空間内に割り当てられ、ユーザ空間不足になった場合、次の

OutOfMemoryErrorがスローされる、あるいはエラーメッセージとして表示を行いプロセスが終了します。

java.lang.OutOfMemoryError: unable to create new native thread

また、JavaヒープやOSの仮想メモリに余裕があるにもかかわらず、ユーザ空間内にメモリを確保できなかった場合、次の

OutOfMemoryErrorが出力されプログラムが終了します。

java.lang.OutOfMemoryError: requested サイズ bytes 制御名. Out of swap space?

サイズ: 確保できなかったメモリの大きさ

制御名: メモリが確保できなかったJava VMの制御名(該当情報がある場合にだけ表示)

- 248 -

ユーザ空間が不足している場合は、Javaヒープまたはスタックのサイズを小さくするなどのチューニングを行ってください。

スタックのサイズをチューニングする方法は、“8.4.2 スタックのチューニング”を参照してください。


なお、仮想メモリに余裕がある場合は、Javaプロセスを複数起動して、プロセス多重度を上げる方法もあります。J2EEア

プリケーションまたはJavaEEアプリケーションの場合、J2EEまたはJavaEEのチューニングを行ってください。J2EEまたは

JavaEEのチューニング方法の詳細は、それぞれのマニュアルを参照してください。

■想定される原因(仮想メモリ不足)

仮想メモリが不足してスレッドが生成できない場合、次のOutOfMemoryErrorがスローされる、あるいはエラーメッセー

ジとして表示を行いプロセスが終了します。

java.lang.OutOfMemoryError: unable to create new native thread

また、OSの仮想メモリが不足した場合、次のOutOfMemoryErrorが出力されプログラムが終了します。

java.lang.OutOfMemoryError: requested サイズ bytes 制御名. Out of swap space?

サイズ: 確保できなかったメモリの大きさ

制御名: メモリが確保できなかったJava VMの制御名(該当情報がある場合にだけ表示)

仮想メモリが不足した場合は、他の不要なプロセスを終了して仮想メモリに余裕を持たせるか、物理メモリ(RAM)または

スワップファイルを拡張して仮想メモリを増やすようにチューニングを行ってください。

■想定される原因(ガーベジコレクション処理の実行抑止)

ガーベジコレクション処理(GC処理)の実行抑止により、クリティカルセクション状態時にOutOfMemoryErrorがスローさ

れた場合は、必要に応じて、GC処理の実行抑止による影響ができるだけ小さくなるように、実行するアプリケーションの

処理内容を見直してください（アプリケーション処理内の、GC処理の実行抑止に関係する機能の利用見直しを行ってく

ださい）。

GC処理の実行抑止については、“8.2.1 FJVMでサポートされるガーベジコレクション処理”を参照してください。

なお、Javaヒープのチューニングにより、GC処理の実行抑止によるOutOfMemoryErrorの発生が緩和できる場合があ

ります。

・クリティカルセクション状態時に、ネイティブプログラムからJNIを利用してJavaのオブジェクトの生成要求を行ってい

ないアプリケーションの場合は、Old世代領域を大きくする(メモリ割り当てプール全体を大きくする)チューニングで、

GC処理の実行抑止によるOutOfMemoryErrorの発生が緩和できる場合があります。

・クリティカルセクション状態時に、ネイティブプログラムからJNIを利用してJavaのオブジェクトの生成要求を行っている

アプリケーションの場合は、New世代領域を大きくするチューニングで、GC処理の実行抑止によるOutOfMemoryErrorの発生が緩和できる場合があります。



GC処理の実行抑止により、クリティカルセクション状態でOutOfMemoryErrorがスローされたかどうかは、“メモリ領域

不足事象発生時のメッセージ出力機能の強化”で出力されるメッセージを参照して判断してください。

また、EXTP4435メッセージまたはISJEE_OM1018メッセージが出力されている場合は、IJServerのコンテナ情報ログ

(info.log)およびIJServerクラスタのJava VMログ(jvm.log)に出力される「Java VMのヒープ域不足の詳細情報」を参照して

判断してください。

- 249 -

8.6.1.1 メモリ領域不足事象発生時のメッセージ出力機能の強化

FJVMでは、メモリ領域不足事象発生時に出力されるメッセージ情報の強化を行なっています。

これによりFJVMでは、メモリ領域不足事象が発生した場合に、java.lang.OutOfMemoryErrorの例外メッセージ情報に

加え、不足した領域の種別情報を図1の形式で出力します。

図1 メモリ領域不足事象が発生した場合に出力される不足した領域の種別情報

The memory was exhausted area_nameJava heap size / max Java heap size = heap_size / max_heap_sizeJava perm size / max Java perm size = perm_size / max_perm_size

area_name: メモリ領域不足事象が発生した領域の名前や領域不足となったオブジェ

クトの要求サイズ（不足領域情報）を表示します。

不足領域情報としては以下の項目があります。

・ on Java heap space. : requested <NNNN> bytesNNNNバイトのオブジェクト生成要求において、メモリ割り当てプール

(New世代領域またはOld世代領域)に対してメモリ領域不足事象が発

生した場合です。

なお、JDK/JRE 6、7のエルゴノミクス機能によるメモリ領域不足事象

の検出機能が有効な場合で、かつ当該機能によりメモリ領域不足事

象を検出した場合、この項目になる場合があります。

・ on Java heap space. : requested <NNNN> bytes (in critical section)意味は「on Java heap space. : requested <NNNN> bytes」と同じで

すが、メモリ領域不足事象発生時、クリティカルセクション状態でGC処理の実行が抑止されていたことを示しています。

・ on Java perm space. : requested <NNNN> bytesNNNNバイトのオブジェクト生成要求において、Permanent世代領域

に対してメモリ領域不足事象が発生した場合です。




・ on Java perm space. : requested <NNNN> bytes (in critical section)意味は「on Java perm space. : requested <NNNN> bytes」と同じで

すが、メモリ領域不足事象発生時、クリティカルセクション状態でGC処理の実行が抑止されていたことを示しています。

・ (なし)スタックやヒープなど、Javaヒープ以外の領域に対してメモリ領域不足

事象が発生した場合です。特にjava.lang.OutOfMemoryErrorの例外

メッセージ情報が“java.lang.OutOfMemoryErrorがスローされた場合”

の「ユーザ空間不足」または「仮想メモリ不足」の場合に出力される形

式の場合は、スタックやヒープなど、Javaヒープ以外の領域に対してメ

モリ領域不足事象が発生した場合と断定できます。

またはJavaアプリケーション実行時における配列生成式の評価の段

階で、配列オブジェクトの長さ（配列要素の数）から、当該配列オブ

ジェクトを割り当てるための領域が十分でないと評価された場合（配

列の長さ（配列要素の数）が大きすぎ、配列オブジェクトとしての大き

さが２ギガバイト程度もしくはそれ以上の大きさになる配列の定義があ

る場合）。

またはクラスのロード処理でメモリ不足が発生した場合。




heap_size: メモリ領域不足事象が発生した際に使用中となっているメモリ割り当てプー

ルのサイズ(単位:byte)。

- 250 -

max_heap_size: 利用可能なメモリ割り当てプールの大サイズ(単位:byte)。

perm_size: メモリ領域不足事象が発生した際に使用中となっているPermanent世代領

域のサイズ(単位:byte)。

max_perm_size: 利用可能なPermanent世代領域の大サイズ(単位:byte)。

メモリ領域不足事象が発生した際に出力される各領域の使用中サイズ(heap_size、perm_size)には、メモリ領域不足の

原因となったオブジェクトの大きさは含まれません。

そのため巨大サイズのオブジェクト生成要求などによりメモリ領域不足事象が発生した場合には、「大サイズ」と「使用

中サイズ」の差が大きい場合（空き領域がたくさんあるように見える場合）がありますので注意してください。







そのため、出力データにおいて、メモリ割り当てプールやNew世代領域に空きがあるように見える場合であっても、実際

には空きがない場合がありますので注意してください（空きがあるように見える場合であっても、その差は、NewGC処理


メモリ割り当てプールに対してメモリ領域不足事象が発生した場合に出力されるheap_sizeの値は、New世代領域での

使用中サイズとOld世代領域での使用中サイズの合計値です。

New世代領域とOld世代領域は別々のオブジェクト格納域として管理・制御されますから、max_heap_sizeとheap_sizeの差の大きさが、そのまま生成要求できるオブジェクトの大サイズにはなりませんので注意してください。

図2 メモリ領域不足事象が発生した場合に出力されるメッセージ出力例

Exception in thread "main" java.lang.OutOfMemoryError: Java heap spaceThe memory was exhausted on Java heap space. : requested 4016 bytes Java heap size / max Java heap size = 495974032 / 536870912 Java perm size / max Java perm size = 1678376 / 67108864

図2の出力例の場合、4016バイトのオブジェクト生成要求において、メモリ割り当てプールに対してメモリ領域不足が発

生したことを確認することができます。

8.6.2 EXTP4435メッセージまたはISJEE_OM1018メッセージが出力された場合

Interstage Application Server配下のJavaアプリケーション実行時において、以下のメッセージが出力された場合は、メモ

リ領域不足事象が原因による異常となります。

Javaヒープをチューニングしてください。


・ EXTP4435メッセージ

・ ISJEE_OM1018メッセージ

- 251 -

各メッセージの内容については、“メッセージ集”を参照してください。

なお、IJServerのコンテナ情報ログ(info.log)およびIJServerクラスタのJava VMログ(jvm.log)に出力される「Java VMのヒー

プ域不足の詳細情報」の出力形式は、図1のとおりです。

図1 Java VMのヒープ域不足の詳細情報の出力形式

------------------------------------------------------------------OutOfMemory Log------------------------------------------------------------------pid=process_idheap_type=heap_type_codeheap_size=heap_sizemax_heap_size=max_heap_sizeperm_size=perm_sizemax_perm_size=max_perm_sizerequested_size=requested_size------------------------------------------------------------------VM is terminated by occurred OutOfMemoryError on heap_type.stack_trace

process_id: メモリ領域不足事象が発生したJavaプロセスのプロセス番号。

heap_type_code: メモリ領域不足事象が発生した領域に対応する番号です。表示され

る番号については、heap_typeの説明を参照してください。

heap_size: メモリ領域不足事象が発生した際に使用中となっているメモリ割り当

てプールのサイズ(単位:byte)。

max_heap_size: 利用可能なメモリ割り当てプールの大サイズ(単位:byte)。

perm_size: メモリ領域不足事象が発生した際に使用中となっているPermanent世代領域のサイズ(単位:byte)。

max_perm_size: 利用可能なPermanent世代領域の大サイズ(単位:byte)。

requested_size: 領域不足となったオブジェクトの要求サイズ(単位:byte)。

heap_type: 不足領域情報（メモリ領域不足事象が発生した領域の名前など）を表

示します。

不足領域情報としては以下の項目があります。

・ Java heaprequested_sizeバイトのオブジェクト生成要求において、メモリ割り

当てプール(New世代領域またはOld世代領域)に対してメモリ領

域不足事象が発生した場合です。

この項目のときのheap_type_codeは「1」になります。

なお、JDK/JRE 6、7のエルゴノミクス機能によるメモリ領域不足事

象の検出機能が有効な場合で、かつ当該機能によりメモリ領域不

足事象を検出した場合、この項目になる場合があります。

・ Java heap in critical section意味は「Java heap」と同じですが、メモリ領域不足事象発生時、

クリティカルセクション状態でGC処理の実行が抑止されていたこ

とを示しています。

・ Java Permrequested_sizeバイトのオブジェクト生成要求において、Permanent世代領域に対してメモリ領域不足事象が発生した場合です。



- 252 -



・ Java Perm space in critical section意味は「Java Perm」と同じですが、メモリ領域不足事象発生時、

クリティカルセクション状態でGC処理の実行が抑止されていたこ

とを示しています。

・ C heap 制御情報

スタックやヒープなど、Javaヒープ以外の領域に対してメモリ領域

不足事象が発生した場合（requested_sizeバイトのメモリ割り当て

要求が失敗した場合）です。


なお、現象発生時の要求サイズが不明な場合のrequested_sizeは「0」になります。

また、次行に制御情報(メモリが確保できなかったJava VM制御の

情報)が出力される場合があります。

・ unknown spaceJavaアプリケーション実行時における配列生成式の評価の段階

で、配列オブジェクトの長さ（配列要素の数）から、当該配列オブ

ジェクトを割り当てるための領域が十分でないと評価された場合

（配列の長さ（配列要素の数）が大きすぎ、配列オブジェクトとして

の大きさが２ギガバイト程度もしくはそれ以上の大きさになる配列

の定義がある場合）。

またはクラスのロード処理でメモリ不足が発生した場合。




この項目のときのheap_type_codeは「-1」になります。

なお、この項目の場合のrequested_sizeは「0」になります。

stack_trace: メモリ領域不足事象が発生したスレッドがJavaアプリケーションを実行

しているスレッドだった場合は、当該スレッドのスタックトレースが出力

されます。それ以外のスレッドの場合、またはリソース不足によりスタッ

ク情報が取り出せない場合は、スタックトレースは出力されません。

メモリ領域不足事象が発生した際に出力される各領域の使用中サイズ(heap_size、perm_size)には、メモリ領域不足の

原因となったオブジェクトの大きさは含まれません。

そのため巨大サイズのオブジェクト生成要求などによりメモリ領域不足事象が発生した場合には、「大サイズ」と「使用

中サイズ」の差が大きい場合（空き領域がたくさんあるように見える場合）がありますので注意してください。







そのため、出力データにおいて、メモリ割り当てプールやNew世代領域に空きがあるように見える場合であっても、実際

には空きがない場合がありますので注意してください（空きがあるように見える場合であっても、その差は、NewGC処理


- 253 -

メモリ割り当てプールに対してメモリ領域不足事象が発生した場合に出力されるheap_sizeの値は、New世代領域での

使用中サイズとOld世代領域での使用中サイズの合計値です。

New世代領域とOld世代領域は別々のオブジェクト格納域として管理・制御されますから、max_heap_sizeとheap_sizeの差の大きさが、そのまま生成要求できるオブジェクトの大サイズにはなりませんので注意してください。

図2 Java VMのヒープ域不足の詳細情報の出力例

--------------------------------------------------------------------------------

OutOfMemory Log

--------------------------------------------------------------------------------

pid=4696

heap_type=1

heap_size=136800

max_heap_size=6291456

perm_size=2052320

max_perm_size=67108864

requested_size=40000016

--------------------------------------------------------------------------------

VM is terminated by occurred OutOfMemoryError on Java heap.

"main" prio=6 tid=0x00307000 nid=0x12a8 runnable [0x0092f000]


at test.<init>(test.java:10)

at test.main(test.java:5)


た。



8.6.3 java.lang.StackOverflowErrorがスローされた場合

StackOverflowErrorがスローされた場合、スタックオーバーフローが原因です。

スタックのサイズをチューニングしてください。

スタックのチューニング方法は、“8.4.2 スタックのチューニング”を参照してください。

なお、StackOverflowErrorがスローされず、そのままJavaプロセスが異常終了する場合もあります。

その場合の解析方法については、“8.6.3.1 スタックオーバーフロー検出時のメッセージ出力機能”を参照してください。

8.6.3.1 スタックオーバーフロー検出時のメッセージ出力機能

Javaプロセスが不当なメモリアクセスにより異常終了した場合の原因の1つとして、スレッドに対するスタックのサイズ不

足、すなわちスタックオーバーフローの発生が考えられます。

FJVMでは、スタックオーバーフローが原因と考えられる不当なメモリアクセスによりJavaプロセスが異常終了した場合、

その旨を原因調査情報としてFJVMログへ出力する機能を、「スタックオーバーフロー検出時のメッセージ出力機能」とし

て実装しています。

FJVMログの見方については、“8.5.8 FJVMログ”を参照してください。

- 254 -

スタックオーバーフロー発生の原因が、Java APIで生成されたスレッドに対するスタックのサイズにある場合は、“8.4.2スタックのチューニング”を参照して、Java APIで生成されるスレッドに対するスタックのサイズをチューニングしてくださ

い。

検出対象となるスレッド

本機能でスタックオーバーフローの検出対象となるスレッドは、原則Java APIで生成されたスレッドです。

次のスレッドは、本機能による検出対象スレッドとはなりません。

・ネイティブモジュールからOSのAPIを直接使用して生成されたスレッド

・ mainメソッドを実行するスレッド(Java APIで生成されたスレッドではないため)

スタックオーバフローの検出には、OSの機能を利用しています。ご使用中のOSがWindowsの場合は、上記スレッド

の場合であっても、そのスレッドで実行されるJavaメソッドの中から呼び出されたネイティブメソッド内で直接発生した

スタックオーバーフローについては、本機能による検出の対象となります。

注意事項

スタックオーバーフローが発生しても、OS側からFJVM側の処理へ制御が渡らないことがあります。その場合はFJVMログが出力されません。

OSの制御処理がワトソン博士へ直接例外制御を渡した場合には、ワトソン博士が出力するログファイルを確認してくだ

さい。ワトソン博士の説明は、“8.5.9.1 クラッシュダンプ”を参照してください。

なお、スタックオーバーフロー発生時のスタック残量が少ない場合には、以下の状態でJavaアプリケーションが終了す

る場合があるので注意してください。

・以下のメッセージが標準出力へ出力されただけで、FJVMログが出力されないままJavaアプリケーションが終了して

しまうことがあります。

スタックオーバーフロー検出に関するFJVMログが出力されない場合であっても、以下のメッセージが出力された場

合は、スタックオーバーフローが発生したことを示します。

An unrecoverable stack overflow has occurred.

・スタックオーバーフロー発生例外に対する制御が、OS側からFJVM側の処理およびワトソン博士のどちらにも渡ら

ず、そのままJavaアプリケーションが終了してしまうことがあります。

その場合は、スタックオーバーフロー発生を検出することができません。

8.6.4 SIGBUS発生により異常終了した場合

Solaris上で実行しているプロセスが、以下の状態のSIGBUS発生により異常終了した場合は、システムのメモリ資源／

スワップ不足により発生した異常終了です。

signal no : 10(SIGBUS)

signal code : 3(BUS_OBJERR)

signal error: 12(ENOMEM)

そして、Javaプロセスが異常終了した場合に出力されるFJVMログにおいて、以下の情報が出力されている場合が、上

記状態に相当します(JDK/JREのバージョンにより異なります)。

siginfo:si_signo=SIGBUS: si_errno=Not enough space, si_code=3(BUS_OBJERR), si_addr=16進数

または

siginfo:si_signo=10, si_errno=12, si_code=3, si_addr=16進数

異常終了時の情報として上記情報が出力された場合は、不要なプロセスを終了して仮想メモリに余裕を持たせるか、物

理メモリ(RAM)またはスワップファイルを拡張して仮想メモリを増やすようにチューニングを行ってください。

- 255 -

8.6.5 プロセスが消滅(異常終了)した場合

本節では、何の痕跡も残さずに突然プロセスが消滅した場合に、考えられる原因とその対処方法を説明します。

■想定される原因(スタックオーバーフロー)

FJVMには、スタックオーバーフロー検出時にメッセージを出力する機能を備えています。FJVMログを分析することに

より、スタックオーバーフローが発生したかどうかを確認することができます。FJVMログの分析方法は、“8.6.3.1 スタック

オーバーフロー検出時のメッセージ出力機能”を参照してください。

スタックオーバーフローが発生したことを確認できた場合、該当するスタックのサイズをチューニングしてください。スタッ

クのチューニング方法は、“8.4.2 スタックのチューニング”を参照してください。

通常、スタックオーバーフローが発生した場合、java.lang.StackOverflowErrorがスローされ、ワトソン博士が検知してユー

ザダンプおよびワトソンログを出力します。

しかし、OSが高負荷状態になったり、スタックオーバーフロー発生時のスタック残量が少なかったりすると、OSからFJVMにもワトソン博士にも制御が渡らないまま、痕跡を残さずにプロセスが消滅することがあります。

したがって、プロセスが消滅した原因が不明な場合は、スタックのサイズを拡張して、現象が改善できるかどうかを確認

してください。スタックのサイズを拡張しても改善できない場合は、別の原因を調査してください。


■想定される原因(長時間コンパイル処理の検出機能による終了)

FJVMの“長時間コンパイル処理の検出機能”による終了の可能性があります。

詳細は、“8.3.2 長時間コンパイル処理の検出機能”を参照してください。

Javaアプリケーションを“-XX:CompileTimeout”オプション付きで起動した場合は、標準出力にFJVMからのメッセージ

が出力されていないかどうかを確認してください。

■想定される原因(シグナルハンドラ)

Java VM以外のモジュールで、シグナルハンドラを登録した場合、Javaアプリケーションが正常に動作せずに、異常終

了することがあります。詳細は、“8.5.8.2 異常終了時のシグナルハンドラ情報 ”を参照してください。

FJVMを使用している場合は、FJVMログにシグナルハンドラ情報が出力されますので、それを確認してください。

■想定される原因(JNI処理の異常)

JNI経由でJava以外の言語で開発したネイティブモジュールと連携する際、JNIの使用方法を誤ると、プロセス消滅の原

因となります。

このようなときは、“-Xcheck:jni”オプションを指定して、JNI処理でメッセージが出力されないかどうかを確認してくださ

い。“-Xcheck:jni”オプションの詳細は、“8.5.10 JNI処理異常時のメッセージ出力”を参照してください。

JNI処理に誤りがなくても、ネイティブモジュールで異常終了またハングアップが発生すると、Javaアプリケーションのプ

ロセスが消滅する場合があります。たとえば、スレッドアンセーフな関数を使用している場合は、注意が必要です。

スレッドアンセーフな関数の例

次の関数を使用したときに、障害が発生した事例があります。

・ vfork

■想定される原因(プログラムによる終了)

Javaプロセスが、特別なメッセージ出力などがないまま、予想外の状態で終了した場合、原因の1つとして、次のいずれ

かが考えられます。

- 256 -

・ java.lang.Runtime.exit()を予想外の箇所で実行した

・ java.lang.Runtime.halt()を予想外の箇所で実行した

・ java.lang.System.exit()を予想外の箇所で実行した

FJVMを使用している場合は、“8.5.6 Java VM終了時における状態情報のメッセージ出力機能”を参照して、対処して

ください。

■想定される原因(Windows Server(R) 2003の問題)

Windows Server(R) 2003の初期版においては、ユーザダンプが出力されない問題をはじめとして、その他にもJavaの実

行動作に影響を及ぼす問題などがあります。

たとえば、次のような問題があります。




Windows Server(R) 2003を使用する場合は、Service Pack 1以降またはHotfixを適用してください。

8.6.6 ハングアップ(フリーズ)した場合

本節では、Javaプロセスが残っているにもかかわらず、プログラムが無応答になった場合、考えられる原因とその対処方

法を説明します。

■想定される原因(デッドロック)

デッドロックが発生した場合、そのスレッドが停止されます。

ハングアップしたときに、スレッドダンプを採取して、デッドロックがないかどうかを確認してください。

スレッドダンプの採取方法および解析方法の詳細は、“8.5.3 スレッドダンプ”を参照してください。

■想定される原因(ガーベジコレクション)

ガーベジコレクションが発生すると、ガーベジコレクションが終了するまでの間、Javaアプリケーションのすべてのスレッ

ドが停止されます。

これにより、Javaアプリケーションがハングアップしたかのように見える場合があります。

ガーベジコレクションのログを採取して、ガーベジコレクションが動作したタイミングを照合してください。ガーベジコレク

ションが原因で無応答のような現象になる場合は、Javaヒープをチューニングして、ガーベジコレクションの動作具合を改

善してください。



■想定される原因(JNI処理の異常)

JNI経由でJava以外の言語で開発したネイティブモジュールと連携する際、JNIの使用方法を誤ると、ハングアップの原

因となります。

このようなときは、“-Xcheck:jni”オプションを指定して、JNI処理でメッセージが出力されないかどうかを確認してくださ

い。“-Xcheck:jni”オプションの詳細は、“8.5.10 JNI処理異常時のメッセージ出力”を参照してください。

JNI処理に誤りがなくても、JNIモジュールで異常終了またハングアップが発生すると、Javaアプリケーションがハングアッ

プする場合があります。たとえば、スレッドアンセーフな関数を使用している場合は、注意が必要です。

スレッドアンセーフな関数の例

- 257 -

次の関数を使用したときに、ハングした事例があります。

・ vfork

8.6.7 スローダウンが発生した場合

本節では、Javaアプリケーションの動きが遅くなる現象(スローダウン)が発生した場合に、考えられる原因とその対処方

法を説明します。

■想定される原因(ガーベジコレクション)

ガーベジコレクションが発生すると、ガーベジコレクションが終了するまでの間、Javaアプリケーションのすべてのスレッ

ドが停止されます。このため、Javaアプリケーションのレスポンス(応答)が遅くなる場合があります。

ガーベジコレクションのログを採取して、ガーベジコレクションが動作したタイミングとスローダウンが発生したタイミング

を照合してください。ガーベジコレクションが原因でスローダウンになる場合は、Javaヒープをチューニングして、ガーベジ

コレクションの動作具合を改善してください。



スローダウンの事例

同じソフトウェアとJavaアプリケーションが動作している複数のWebサーバのうち、一部のサーバだけがスローダウンした

という事例があります。この原因は、マシンに搭載されている物理メモリ(RAM)の容量の違いでした。

物理メモリ(RAM)が少ないマシンの場合、ガーベジコレクションの実行に伴い、ディスクのスワッピングが発生し、スロー

ダウンすることがあります。

8.7 Javaツール機能

本製品では、Javaプログラムのチューニングやトラブルシューティングに有用なツールを提供しています。ツールには、

次の5つがあります。

・メソッドのトレースを出力するメソッドトレース機能

・ Javaヒープ使用量を出力するjheap

・スレッドダンプを出力するスレッドダンプツール(Windows(R)のみ)

・ Java監視機能

・ JDKに含まれるトラブルシューティングに役立つツール

ツールの格納先

・メソッドのトレースを出力するメソッドトレース機能

・ Javaヒープ使用量を出力するjheap

・スレッドダンプを出力するスレッドダンプツール(Windows(R)のみ)

・ Java監視機能

－ JDK 6使用時 : [Interstageインストールフォルダ]\jdk6\tools

－ JRE 6使用時 : [Interstageインストールフォルダ]\jre6\tools

－ JDK 7使用時 : [Interstageインストールフォルダ]\jdk7\tools

－ JRE 7使用時 : [Interstageインストールフォルダ]\jre7\tools

- 258 -

以下の“$DIR”はインストール時に指定する相対ディレクトリ名です。“$DIR”のシステム推奨名は“opt”です。

－ JDK 6使用時 : /$DIR/FJSVawjbk/jdk6/tools

－ JRE 6使用時 : /$DIR/FJSVawjbk/jre6/tools

－ JDK 7使用時 : /$DIR/FJSVawjbk/jdk7/tools

－ JRE 7使用時 : /$DIR/FJSVawjbk/jre7/tools

・ JDKに含まれるトラブルシューティングに役立つツール

－ JDK 6使用時 : [Interstageインストールフォルダ]\jdk6\bin

－ JDK 7使用時 : [Interstageインストールフォルダ]\jdk7\bin

以下の“$DIR”はインストール時に指定する相対ディレクトリ名です。“$DIR”のシステム推奨名は“opt”です。

－ JDK 6使用時 : /$DIR/FJSVawjbk/jdk6/bin

－ JDK 7使用時 : /$DIR/FJSVawjbk/jdk7/bin

各ツールの詳細は、“トラブルシューティング集”の“Javaツール機能”を参照してください。

- 259 -

第9章データベース連携サービスのチューニング

Interstageのシステム構成に応じて、データベース連携サービスで提供するパラメタをチューニングする必要があります。

ここでは、データベース連携サービスのiniファイル内のパラメタについて説明します。

9.1 データベース連携サービスのiniファイル設定情報

データベース連携サービスのiniファイルには、以下の表に示すパラメタを設定します。

システムチューニングを行ってデータベース連携サービスを使用する場合は、iniファイルを変更します。iniファイルを変

更しない場合、データベース連携サービスは、初期値で動作します。

iniファイルは、インストール時に、以下に格納されます。設定例については、“9.2 iniファイルの設定例”を参照してくだ

さい。

■ファイル名

C:\Interstage\ots\etc\ots.ini

注）本製品のインストールパスがデフォルトの場合のパスです。

■パラメタ一覧

タイプパラメタ意味初期値最小値最大値チューニ

ング

共用メモリ shmmni 共用メモリ識別子の数 100 25 16777215

－

shmseg プロセスごとのセグメント数 100 25 16777215

－

セマフォ semmni セマフォid数 (注1) 100 25 16777215

○

semmsl idごとの大セマフォ数 (注1) 25 25 16777215

○

semvmx セマフォ大値 32768 32768 16777215

－

メッセージ

キュー

msgmap messageマップ内のエントリ数 50 25 16777215

－

msgmax メッセージ大サイズ 4096 4096 16777215

－

msgmni メッセージ待ち行列id数 10 10 16777215

－

msgssz メッセージセグメントサイズ 8 8 255 －

msgtql メッセージキューidごとのヘッダ数 20 20 16777215

－

msgseg メッセージセグメント数 2048 2048 16777215

－

Windows(R)固有パラ

メタ

msgemuwait

メッセージキューwaitプロセス数 (注2)

64 64 16777215

○

insmax 内部プロセス間通信メッセージ長 32768 32768 16777215

－

- 260 -

タイプパラメタ意味初期値最小値最大値チューニ

ング

msgwait 内部プロセス間通信待ち合わせ

数 (注2)64 64 1677721

5○

execmax 大プロセス数 (注2) 64 64 16777215

○

prntmax 大親プロセス数 (注2) 64 10 16777215

○

ftokmax 大ファイル名数 (注2) 64 64 16777215

○

interval プロセス終了監視間隔時間(秒) 1 1 16777215

－

inthndl 資源監視間隔時間(秒) 10 1 16777215

－

mutexmax 大mutex数 300 150 16777215

－

○：チューニング可能です。

－：基本的には、初期値から変更しないでください。

注1）“9.3 セマフォ資源”を参照して設定してください。

注2）“9.4 Windows(R)固有パラメタ”を参照して設定してください。

9.2 iniファイルの設定例

iniファイルの設定例を以下に示します。

[shminfo]

# shared memory id count

shmmni=100

# segment count of process

shmseg=100

[seminfo]

# semaphore id count

semmni=100

# semaphore count of id

semmsl=25

# maximum semaphore

semvmx=32768

[msginfo]

# entry count in message map

msgmap=50

# maximum message size

msgmax=4096

# message queue count(id count)

msgmni=10

# message segment size

msgssz=8

# header count of system message

msgtql=20

# message segment count

msgseg=2048

# message queue WAIT process count

msgemuwait=64

[insinfo]

# length of interprocess communication

insmax=32768

- 261 -

# wait count of interprocess communication

msgwait=64

# maximum process count

execmax=64

# maximum parent process count

prntmax=64

# maximum count of ftok file name

ftokmax=64

# process finish observation space time

interval=1

# space time

inthndl=10

# mutex count

mutexmax=300

#で始まる行は、コメントです。

設定値には、半角数字だけ使用できます。

9.3 セマフォ資源

データベース連携サービスを使用する場合、同期制御／排他制御のため、セマフォ資源を使用します。

セマフォ資源は、以下の算出式で見積ります。

セマフォ資源意味種類必要数

semmni セマフォの組加算値 5 ＋ x（注）

semmsl 組あたりのセマフォの大数設定値 25 以上

注）x：起動するリソース管理プログラムの種類 × 4（リソース管理プログラムを起動する場合）

9.4 Windows(R)固有パラメタ

Windows(R)固有パラメタは、以下の算出式で見積ります。

パラメタ意味種類初期値必要数

msgemuwait

メッセージキューwaitプロセス数設定値 64 10 ＋ a（注1）

msgwait 内部プロセス間通信待ち合わせ数設定値 64 10 ＋ b ＋ c（注2）

execmax 大プロセス数設定値 64 10 ＋ b ＋ c（注2）

prntmax 大親プロセス数設定値 64 10 ＋ b ＋ c（注2）

ftokmax 大ファイル数設定値 64 25 ＋ d（注3）

注1）a：リソース管理プログラムの大多重度

注2）b：リソース管理プログラムの多重度の合計、c：ワークユニットの多重度の合計(サーバアプリケーションの合計)注3）d：リソース定義ファイルの合計

- 262 -

付録A CORBAサービスの動作環境ファイル

CORBAサービスの動作環境ファイルについて説明します。各ファイルは、以下に格納されます。

格納パス

C:\Interstage\ODWIN\etc (インストールパスはデフォルト)

/etc/opt/FSUNod(インストールパスはデフォルト、

インストール時に動作環境ディレクトリ(“Fixed configuration install directory”)として変更可能)

/etc/opt/FJSVod

ファイル

(Interstage Application Server Enterprise Editionにおいて提供)

config gwconfig inithost/initial_hosts queue_policy nsconfig irconfig

(Interstage Application Server Standard-J Editionにおいて提供)

config inithost/initial_hosts queue_policy nsconfig irconfig

(Interstage Web Server Expressにおいて提供)

config inithost/initial_hosts

・上記以外のファイルは、CORBAサービスの動作環境としてカスタマイズできません。エディタなどで編集しないでく

ださい。

・上記のファイル内に日本語は記載できません。

・システムの異常停止などに起因して動作環境ファイルなどの資源が破壊されると、CORBAサービスが正常に起動で

きない場合があります。

正常に起動できない、かつ以下のメッセージが発生する場合は、資源が破壊されている可能性があるので、環境の

再構築を行うか、バックアップした資源を復元してCORBAサービスの再起動を行う必要があります。

メッセージ番号:od10400, od10402, od10404, od10406, od10504, od10509, od10510万が一のため、運用環境を構築したら資源のバックアップを行うことを推奨します。

- 263 -

バックアップについては、“運用ガイド(基本編)”の“メンテナンス(資源のバックアップ/他サーバへの資源移行/ホスト

情報の変更)”で説明されています。

A.1 config

■概要

configファイルは、CORBAサービスの各種動作環境に関する定義が格納されたファイルです。

■ファイル名

C:\Interstage\ODWIN\etc\config (インストールパスはデフォルト)

Solarisサーバ: /etc/opt/FSUNod/config (インストールパスはデフォルト)Windows(R)クライアント: C:\Interstage\ODWIN\etc\config (インストールパスはデフォルト)

Linuxサーバ: /etc/opt/FJSVod/config (インストールパスはデフォルト)Windows(R)クライアント: C:\Interstage\ODWIN\etc\config (インストールパスはデフォルト)

■ファイル内情報

configファイルは、以下の形式で値を設定します。

◆形式:

パラメタ名 = 設定値

半角のシャープ(#)を行の先頭に指定した場合は、その行はコメントとして扱われます。また、空行は解析時に無視されます。

# コメント

◆記述例:

# comment period_receive_timeout = 72

◆パラメタ:

以下の動作環境について、パラメタ設定値を変更することができます。

・ホスト情報に関する動作環境

・ネットワーク環境に関する動作環境

・アプリケーション資源に関する動作環境

・タイムアウト監視に関する動作環境

・セキュリティ機能に関する動作環境

・コード変換機能に関する動作環境

- 264 -

・保守機能に関する動作環境

・旧バーションの互換に関する動作環境

・パラメタ値を変更した場合、次回のCORBAサービス起動時より有効となります。

・ configファイル内に日本語は記載できません。

・下表に記載していないパラメタは初期値を変更しないでください。

・備考欄に“必須パラメタ”と記載されているパラメタは省略することはできません。(Solaris版および Linux版には必須

パラメタはありません)

・数値を指定するパラメタ(period_receive_timeout等)に数値以外の文字列(“abc”など)を指定した場合、“0”が設定さ

れたものとして扱われます。

◆ホスト情報に関する動作環境

パラメタ名初期値意味備考

省略値

指定範囲

IIOP_hostname

－マシンにIPアドレス(またはホスト名)が複数設定されてい

る場合に、CORBAサーバアプリケーションで使用する

IPアドレスを限定した運用を行う場合に設定します。

IPアドレス(またはホスト名)を設定すると、サーバアプリ

ケーションのオブジェクトリファレンスの生成時には、ここ

で設定したIPアドレスが組み込まれ、クライアントからの

接続時に使用されます。また、CORBAサービスは指定

されたIPアドレスのみでバインドを行います。

本パラメタが省略された場合はすべてのIPアドレスに対

してバインドが行われます。ただし、IPv4/IPv6のどちら

の(または両方の)IPアドレスをバインドするかどうかはIP-versionパラメタの設定に依存します。

サーバ機能

のみ有効。

(注1) (注2)(注3)

－

－

IIOP_port 8002 CORBAサービスが使用するポート番号。

Windowsの場合、省略できません。

Solaris、Linuxの場合、初期値(8002)以外を指定すると

きは必ず指定してください。

(注4)

－

－

注1) Interstage Web Server Expressでは指定不可。

注2) 例えばLANカードが複数装着されたマシンにおいて、1つのLANカードからのみ接続要求を受け付けることができます。

ホスト名が指定された場合はIP-versionの値に従って名前解決が行われます。

IP-versionがv4-dualの場合はIPv4での名前解決が優先的に行われます。

IP-versionがv6の場合はIPv6での名前解決が優先的に行われます。

Windows版においてリンクローカルのIPv6アドレスを指定する場合はscope-idも記載する必要があります。(例:fe80::1234:5678:9abc:def0%4)

注3) 必要のない限り本パラメタを設定しないでください。注2)に記述されているような特殊用途以外では設定する必要はあ

りません。誤ったホスト名を設定するとInterstageの起動が失敗します。

また、“localhost”を設定すると“127.0.0.1”(IPv4環境の場合)のみでバインドが行われ、他ホストからのリクエストが受け

付けられなくなりますので“localhost”と設定しないで下さい。“127.0.0.1”(IPv4環境の場合)のIPアドレスで定義されてい

- 265 -

るホスト名を設定した場合も同様に他ホストからのリクエストが受け付けられなくなります。

LinuxではOSインストール直後の状態では自ホスト名に対するIPアドレスが127.0.0.1に設定されており、自ホスト名を

IIOP_hostnameに設定すると他ホストからの接続を受け付けることができなくなります。

注4) Windowsの場合、必須パラメタです。

Solaris、Linuxの場合、この値が無効になると/etc/servicesの設定値が有効になります。

◆ネットワーク環境に関する動作環境


省略値

指定範囲

con_accept all ・ all:すべてのマシンからの接続を受け付けます。

・ localhost:クライアントからの接続受付を自ホストに制限する

場合に指定します。自ホストからの接続のみを受け

付け、他ホストからの接続を受け付けません。

システムセキュリティなどの理由で、他ホストからの

接続要求を許可しない場合に指定してください。

サーバ機能

のみ有効。

(注)all

all,localhost

IP-version v4-dual 運用するIPバージョンを設定します。

・ v4: IPv4のみを利用してCORBAアプリケーションを

運用します(IPv6は使用しません)。

・ v4-dual: IPv4およびIPv6を利用してCORBAアプリ

ケーションを運用します。

サーバとして動作する際はIPv4およびIPv6の両方

を受け付けます。

クライアントとしての動作する際にIPv4を優先的に

利用します。

・ v6: IPv4およびIPv6環境で、CORBAアプリケーショ

ンを運用します。

サーバとして動作する際はIPv4およびIPv6の両方

を受け付けます。

クライアントとしての動作する際にIPv6を優先的に

利用します。

IPv6に対応していない環境で“v4-dual”もしくは“v6”を

指定した場合、“v4”が設定されます。

v4-dual

v4, v4-dual,v6

read_interval_timeout 30 ソケットに対する読み込みの待機時間。

この時間を超えても読み込みできない状態が持続する

場合、アプリケーションにシステム例外

(COMM_FAILURE)が通知されます。

この値が実際の時間(秒)となります。0を設定した場合、

時間監視をしません。

このパラメタによる監視は電文の受信処理が始まって

から開始されます。例えば、リプライの受信待ちの状態

においてパケットが1つも届かなければ

read_interval_timeoutによる監視は行いません。この場

合はperiod_receive_timeoutによる監視が行われます。

パケットが1つでも届くと電文の受信処理を開始するた

めread_interval_timeoutによる監視が行われます。

30

0～

100000000

- 266 -


省略値

指定範囲

write_interval_timeout 30 ソケットに対する書き込みの待機時間。

この時間を超えて書き込みできない状態が持続する場

合、アプリケーションにシステム例外

(COMM_FAILURE)が通知されます。

この値が実際の時間(秒)となります。0を設定した場合、

時間監視をしません。

このパラメタによる監視は電文の送信処理が始まって

から開始されます。

30

0～

100000000

tcp_nodelay no TCP_NODELAY機能を有効にするか無効にするかを

設定します。

・ yes: 電文送信時においてNagleアルゴリズムを無効

にします。

・ no : Nagleアルゴリズムは有効となります。

Nagleアルゴリズムが有効の場合、送信データのバッ

ファリングを行うためネットワーク使用効率が上がりま

す。Nagleアルゴリズムを無効にした場合、送信データ

のバッファリングを行わないためネットワーク使用効率

が下がり通信全体の性能が下がる可能性があります

が、データの送受信に発生するタイムラグが減少し、応

答性能が向上する場合があります。

no

yes, no

注) Interstage Web Server Expressでは初期値から変更しないでください。

◆アプリケーション資源に関する動作環境(プロセス/スレッド多重度、使用コネクション数など)

これらのパラメタに実際に指定可能な値はOSの資源によって制限されます。


省略値

指定範囲

max_exec_instance 512 (注8) サーバアプリケーションのリクエスト実行用スレッド

(またはプロセス)の大数。

サーバ機

能のみ有

効。

(注1) (注3)(注4)

256

16～

1000000

max_IIOP_local_init_con 256 クライアントアプリケーションが使用するサーバホス

トへのコネクションの大値。

ポイント参

照256

1～

1000000

max_IIOP_local_init_requests 4096 クライアントアプリケーションが同時に送信できるリク

エスト数の大値。

4096

1～

1000000

max_IIOP_resp_con 8 (注8) クライアントアプリケーションと確立できる接続の

大値。

サーバ機

能のみ有8

- 267 -


省略値

指定範囲

1～

500000

効。

(注2) (注4)(注11)(注12)ポイント参

照

limit_of_max_IIOP_resp_con 0 (意味参

照)max_IIOP_resp_conの自動拡張の大値。

0またはmax_IIOP_resp_con以上の値を指定してく

ださい。

0を指定すると以下の値が設定されます。

max_IIOP_resp_con × 1.3 (小数部分切り捨て)

サーバ機

能のみ有

効。

(注1) (注4)(注6)

0 (意味参

照)

0～

1000000

max_IIOP_resp_con_extend_number 0 (意味参

照)max_IIOP_resp_conの自動拡張の拡張数。


(limit_of_max_IIOP_resp_con －max_IIOP_resp_con) ÷ max_IIOP_resp_con (小数

部分切り上げ)

サーバ機

能のみ有

効。

(注1) (注6)(注7)

0 (意味参

照)

0～

1000000

max_IIOP_resp_requests 128 (注8) サーバホストにおいて同時に受信できるリクエスト数

の大値。

サーバ機

能のみ有

効。

(注2) (注4)(注10)

128

1～

500000

limit_of_max_IIOP_resp_requests 0 (意味参

照)max_IIOP_resp_requestsの自動拡張の大値。

0またはmax_IIOP_resp_requests以上の値を指定し

てください。


max_IIOP_resp_requests × 1.3 (小数部分切り捨

て)

サーバ機

能のみ有

効。

(注1) (注4)(注6) (注10)

0 (意味参

照)

0～

1000000

max_IIOP_resp_requests_extend_number

0 (意味参

照)max_IIOP_resp_requestsの自動拡張の拡張数。


(limit_of_max_IIOP_resp_requests －max_IIOP_resp_requests) ÷max_IIOP_resp_requests (小数部分切り上げ)

サーバ機

能のみ有

効。

(注1) (注6)(注7)

0 (意味参

照)

0～

1000000

max_processes 20 (注8) 大プロセス数。(起動クライアント＋サーバ数) サーバ機

能のみ有

効。

(注4) (注5)

16

1～

1000000

max_impl_rep_entries 512 インプリメンテーションリポジトリの大登録数。サーバ機

能のみ有

効。

(注2)

256

100～

1000000

- 268 -


省略値

指定範囲

number_of_common_buffer 0 (意味参

照)CORBAサービスのキュー制御で使用するデフォル

トバッファのバッファ数を指定します。

ワークユニット運用されているCORBAアプリケーショ

ンでワークユニット定義の“Buffer Number:通信バッ

ファ数”を指定しているCORBAアプリケーションを

除く、CORBAサービスの通信で使用します。

サーバマシン上で同時に処理される大リクエスト

数を指定してください。

0を指定すると、以下の値が設定されます。

max_IIOP_resp_requests × 0.2 (小数部分切り捨

て)

サーバ機

能のみ有

効。

(注2) (注4)0 (意味参

照)

0～

500000(注10)

limit_of_number_of_common_buffer 0 (意味参

照)number_of_common_bufferの自動拡張の大値。

0またはnumber_of_common_buffer以上の値を指

定してください。


limit_of_max_IIOP_resp_requests

サーバ機

能のみ有

効。

(注1) (注4)(注6)

0 (意味参

照)

0～

1000000(注10)

number_of_common_buffer_extend_number

0 (意味参

照)number_of_common_bufferの自動拡張の拡張数。


(limit_of_number_of_common_buffer －number_of_common_buffer) ÷number_of_common_buffer (小数部分切り上げ)

サーバ機

能のみ有

効。

(注1) (注6)(注7)

0 (意味参

照)

0～

1000000

max_bind_instances 0 (意味参

照)CORBAサービスに登録可能な「サーバプロセスと

オブジェクトのバインド関係」の数。


1024 × max_processes( 計算結果が65535を超えた場合は65535 )

サーバ機

能のみ有

効。

(注2) (注4)(注9)

0 (意味参

照)

0～

1000000

注1) Interstage Web Server Expressでは指定不可。

注2) Interstage Web Server Expressでは初期値から変更しないでください。

注3) 設定値の目安:

登録アプリケーション数(*1) × プロセス大多重度(*2) × スレッド大多重度(*3)＋接続クライアント数(*4) ＋ 64

登録アプリケーション数(*1) × プロセス大多重度(*2) × スレッド大多重度(*3)＋接続クライアント数(*4) ＋ 172

*1) OD_impl_instコマンドで登録したアプリケーション数

*2) OD_impl_instコマンドで指定するproc_conc_max値

*3) OD_impl_instコマンドで指定するthr_conc_maximum値

*4) isgendefコマンドのscale-valueに対応した接続クライアント数

- 269 -

注4) サーバ機能では、本パラメタの設定値および実際の消費量をodprtcurparamコマンドにより確認することができます。

初期値より増加させる場合、システム資源(共用メモリなど)のチューニングが必要です。詳細については、“3.1.1 CORBAサービスのシステム資源の設定”を参照してください。

また、Linuxの場合は、bashまたはボーンシェルの場合はulimitコマンドを、Cシェルの場合はlimitコマンドを使用して、

ファイルディスクリプタ数を“max_IIOP_resp_con値＋ max_processes値”だけ拡張してからCORBAサービスおよびCORBAアプリケーションを起動してください。

注5) CORBAサービスのプロセス(CORBAサービス、ネーミングサービス、インタフェースリポジトリサーバ、インタフェースリポ

ジトリキャッシュサーバ)も含みます。見積もりを行う場合、Interstageのサービスの使用分(20)にアプリケーション使用分を

加算してください。

CORBAサービスのコマンドも含みます。コマンドを同時に複数起動する場合は、その数を加算してください。

注6)自動拡張について

自動拡張を行うパラメタについてはlimit_of_[パラメタ名]というパラメタと[パラメタ名]_extend_numberというパラメタが存

在します。例えば、 max_IIOP_resp_con というパラメタについては limit_of_max_IIOP_resp_con ・

max_IIOP_resp_con_extend_numberが存在します。

そして、各パラメタは初期値を[パラメタ名]、大値をlimit_of_[パラメタ名]として、[パラメタ名]_extend_number分割で

必要に応じて拡張を行います。

以下に例を示します。

---------------------------------------------------------------------max_IIOP_resp_con = 100limit_of_max_IIOP_resp_con = 140max_IIOP_resp_con_extend_number = 2---------------------------------------------------------------------

上記のパラメタの場合、max_IIOP_resp_conは初期値を100として、120、140と大2回の拡張を行います。

なお、isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定した場合、自動拡張に関するパラメ

タは無視され拡張は行いません。isconfig.xmlについての詳細に関しては“運用ガイド(基本編)”を参照してください。

注7) 一度の拡張処理で増加できるサイズは初期値のサイズに制限されます。

一度の拡張サイズが初期値のサイズを超える拡張を行う設定がされた場合、拡張数は0が設定された場合と同様の値

に補正されます。

また、自動拡張の大値と初期値との差分よりも拡張数が大きい場合は、拡張数は自動拡張の大値と初期値との差

分の値に補正されます。

---------------------------------------------------------------------max_IIOP_resp_con = 100limit_of_max_IIOP_resp_con = 300max_IIOP_resp_con_extend_number = 1---------------------------------------------------------------------

上記のパラメタの場合、max_IIOP_resp_con_extend_numberは2に補正されます。

注8) 以下の場合は初期値が異なります。

Interstage Application Server Enterprise Edition/Standard-J Editionの場合。

Interstage Web Server Expressでは初期値に変更はありません。

Interstage Application Server Enterprise Edition/Standard-J Editionで標準インストール・カスタムインストール・GUIインストーラを使用したインストールを行った場合(pkgaddコマンドによるインストールを行わない場合)。Interstage Application Server Enterprise Editionの拡張システムおよびInterstage Web Server Expressでは初期値に変

更はありません。

- 270 -

Interstage Application Server Enterprise Edition/Standard-J Editionで標準インストール・カスタムインストール・GUIインストーラを使用したインストールを行った場合(rpmコマンドによるインストールを行わない場合)。Interstage Web Server Expressでは初期値に変更はありません。

初期値は以下のように変更されています。

パラメタ名初期値

max_IIOP_resp_con 512

max_IIOP_resp_requests 2048

max_processes 512

max_exec_instance 16384

注9) C++のCORBAアプリケーションがCORBA::ORB::bind_object関数を発行して登録するオブジェクト数と別JavaVMから呼び出されるEJBアプリケーションについてSession BeanとEntity BeanのEJB objectのインスタンス数の加算値よ

りも大きな値を設定してください。

注10) number_of_common_bufferとlimit_of_number_of_common_bufferの設定可能な値は65535が大値になります。

number_of_common_bufferとlimit_of_number_of_common_bufferの設定可能な値はSEMVMXのOS実装値(32767)が大値になります。

なお、 number_of_common_buffer と limit_of_number_of_common_buffer の設定を省略した場合は、

max_IIOP_resp_requestsとlimit_of_max_IIOP_resp_requestsの値から求まる各パラメタの値が設定可能な大値を超

過しないか確認をお願いします。

注11) 以下に示すOSでは、"max_IIOP_resp_con"の大値がOSの仕様により制限されます。

－ Red Hat Enterprise Linux 5以前

65520

－ Solarisシステムパラメタのsemmslまたは、process.max-sem-nsemsの大値に制限されます。

システムパラメタの大値は、Solarisのドキュメントを参照してください。

注12) OSのメモリ使用状況によっては、指定可能範囲であってもod10730メッセージが出力される場合があります。

od10730メッセージが出力された場合、以下の対処を行ってください。

－ Interstage起動時

Interstageを再度起動してください。

－ CORBAアプリケーション運用時

CORBAサーバアプリケーションへ再接続してください。

ポイント: max_IIOP_local_init_con、max_IIOP_resp_conについて

CORBAサービスは、サーバアプリケーションが動作しているマシンごとに1つのコネクションを使用します。

max_IIOP_local_init_conは、各アプリケーションが使用するサーバホストへのコネクション数の大値を指定します。

max_IIOP_resp_conは、各ホストで使用するアプリケーション間のコネクション数を指定します。

原則として、アプリケーション間のコネクションはクライアントアプリケーションのプロセス単位に生成されます。例えば、

クライアントアプリケーションから1つのサーバアプリケーションに複数のリクエストが同時に発行されても、コネクション数

- 271 -

は1になります。

SSL連携機能を使用する場合、SSL接続のコネクションとSSL接続でないコネクションは別コネクションとして数える必要

があります。例えば、クライアントアプリケーションから、1つのサーバマシンにSSL接続のコネクションとSSL接続でないコ

ネクションを使用した場合、コネクション数は2になります。

なお、以下の場合にはコネクションを使用するので必要に応じて加算する必要があります。

・ CORBAサービスのコマンド実行時は1コネクション使用します。コマンドを同時に複数起動する場合は、その数を加

算して指定しておいてください。

・インタフェースリポジトリ動作時は、1コネクションを使用します。

・ロードバランス機能の動作時は、ネーミングサービスおよびロードバランス機能はそれぞれをサーバとしたクライアン

トとして動作するため、2コネクションを使用します。

・インタフェースリポジトリ、ネーミングサービス、ロードバランス機能などの各サービスはサーバアプリケーションです。

そのため、ネーミングサービスへ参照、登録などのリクエストを発行すると１コネクションを使用します。他ホスト上のイ

ンタフェースリポジトリ、ネーミングサービスを参照する設定の場合は、参照先ホストのIIOP_resp_conが1消費されます。

例えばTYPE3 EJBで初期化したホスト上でネーミングサービスへアクセスするアプリケーションを起動すると、ネーミ

ングサービスが起動しているホスト上のIIOP_resp_con資源が1消費されることになります。

以下に、各パラメタのコネクション数のカウント方法を示します。

max_IIOP_local_init_con:

クライアントアプリケーションが動作しているホスト上で、クライアントアプリケーション(プロセス単位)からサーバアプリケー

ション(ホスト単位)へのコネクション数の大値を指定します。

・設定値の目安(インタフェースリポジトリ動作時):max_IIOP_local_init_con ＝ [1つのクライアントアプリケーションが接続するサーバホスト数の大値]と 256のうちの大値

・設定値の目安(インタフェースリポジトリ動作時、SSL連携機能を使用):max_IIOP_local_init_con ＝ [1つのクライアントアプリケーションが接続するサーバホスト数の大値×2]と 256のうちの大値

max_IIOP_resp_con:

サーバアプリケーションが動作しているホスト上で、接続するクライアントアプリケーションのプロセス数の合計を指定し

ます。同一ホスト上でクライアントアプリケーションとサーバアプリケーションが接続する場合も、そのコネクション数を加算

する必要があります。

・設定値の目安(インタフェースリポジトリ動作時):max_IIOP_resp_con ＝接続するクライアントアプリケーションのプロセス数＋ 2

・設定値の目安(インタフェースリポジトリ動作時、SSL連携機能を使用):max_IIOP_resp_con ＝ (接続するクライアントアプリケーションのプロセス数 × 2) ＋ 2

- 272 -

ポイント: max_IIOP_local_init_requests、max_IIOP_resp_requestsについて

CORBAサービスでは、クライアントアプリケーションが同時に送信するリクエスト数に応じてmax_IIOP_local_init_requestsを設定する必要があります。また、サーバアプリケーションが同時に受信するリクエスト数に応じてmax_IIOP_resp_requestsを設定する必要があります。

max_IIOP_local_init_requests:

クライアントアプリケーションが同時に送信できるリクエスト数の大値を指定します。下の図ではクライアントアプリケー

ション1が5個のリクエストを同時に送信し、アプリケーション2が1個のリクエストを同時に送信しています。このため、

max_IIOP_local_init_requestsは5以上の値を設定する必要があります。

ただし、算出された値が4096以下の場合は初期値の4096のままで問題ありません。この例では4096に満たないので

max_IIOP_local_init_requestsはデフォルトの4096から変更の必要はありません。

max_IIOP_resp_requests:

CORBAサーバアプリケーションが同時に受信できるリクエスト数の大値を指定します。

それぞれのクライアントマシンから発行されたリクエストがサーバマシンに到達し、CORBAサーバアプリケーションで同

時に処理される数になるので、個々のクライアントマシンから同時に発行されるリクエストの合計値を見積もる必要があります。

下の図ではそれぞれのクライアントマシンから発行されたリクエストが同時に9個サーバマシンに到達しているので、

max_IIOP_resp_requestsには9以上を設定する必要があります。

- 273 -

◆タイムアウト監視に関する動作環境


省略値

指定範囲

period_client_idle_con_timeout 96 (480秒) クライアントにおける、無通信状態(サーバへのリクエスト

送信なし)の監視時間(リクエスト返信完了後のコネクショ

ン維持時間)。この時間を超えてもサーバへのリクエスト送信がない場

合、サーバとのコネクションの切断を行います。(注3)この値に5を乗じた値が実際の時間(秒)となります。0を

設定すると無通信監視を行いません。

96 (480秒)

0～

20000000

period_idle_con_timeout 120 (600秒) サーバにおける、無通信状態(クライアントからのリクエス

ト送信なし)の監視時間(リクエスト返信完了後のコネク

ション維持時間)。この時間を超えてもクライアントからのリクエスト送信がな

い場合、クライアントとのコネクションを切断し、リクエスト

処理に使用したメモリ資源を解放します。

この値に5を乗じた値が実際の時間(秒)となります。0を

設定すると無通信監視を行いません。

サーバ機能

のみ有効。

(注1) (注4)1 (5秒)

0～

20000000

period_receive_timeout 72 (360秒) クライアントにおける、リクエスト送信から返信までの待機

時間。この時間を超えてもサーバからの返信がない場

合、クライアントにタイムアウトが通知されます。

この値に5を乗じた値が実際の時間(秒)となります。

72 (360秒)

0～

20000000

period_server_timeout 120 (600秒)(注2)

Persistentタイプ以外のサーバアプリケーションとその他

のアプリケーションで意味が異なります。

Persistentタイプ以外のサーバアプリケーションにおいて

はアプリケーション起動からCORBA_ORB_initメソッド完

了までの監視時間となります。この時間以内に

CORBA_ORB_initメソッドが完了しないとクライアントに

システム例外(NO_IMPLEMENT)が通知されます。

クライアントアプリケーションとPersistentタイプのサーバ

アプリケーションにおいてはCORBA_ORB_initメソッド

発行からCORBA_ORB_initメソッド完了までの監視時間

サーバ機能

のみ有効。

(注1)120 (600秒)

1～

20000000

- 274 -


省略値

指定範囲

となります。

この値に5を乗じた値が実際の時間(秒)となります(0は指

定できません)。


注2) 初期値より減少させた場合は、インタフェースリポジトリの起動に失敗することがあります。

注3) 次回リクエスト送信時にサーバとのコネクションの再接続を行います。

なお、クライアントアプリケーションがプロセスモードの場合は、時間超過のタイミングではコネクション切断は行わず、次

回リクエスト送信時にサーバとのコネクションの切断・再接続を行います。

注4) サーバ側の無通信監視時間超過によるコネクション切断のタイミングでクライアントがリクエストを発行すると、クライアン

トに通信異常が通知される場合があります。この問題を回避するためには、クライアント側のperiod_client_idle_con_timeoutにサーバ側のperiod_idle_con_timeoutよりも小さな値を設定してください。

タイムアウト時間は、連携するアプリケーションに適用されるタイムアウト時間を考慮して設定する必要があります。詳細

は“OLTPサーバ運用ガイド”(Interstage Application Server Enterprise Editionで提供)の“CORBAアプリケーション運用

時のタイマ監視”を参照してください。

◆セキュリティ機能に関する動作環境(アプリケーション間通信)


省略値

指定範囲

http_proxy proxy_host HTTPプロキシサーバのホスト名。 (注1) (注2)

null(値は設定さ

れません)

－

http_proxy_port 8080 HTTPプロキシサーバのポート番号。 (注1) (注2)

0

－

http_proxy_use no HTTPプロキシサーバの使用を指定。

・ yes:使用する

・ no :使用しない

(注1) (注2)

no

yes, no

UNO_IIOP_ssl_use

no SSL連携の有効/無効を選択。

・ yes:有効

・ no :無効

(注3)

no

yes, no

UNO_IIOP_ssl_port

4433 SSL連携で使用するポート番号。

UNO_IIOP_ssl_useが“yes”の場合に有効です。

- 275 -


省略値

指定範囲

4433

－


注2) プレインストール型ランタイム(Portable-ORB以外の実行環境)でHTTPプロキシサーバを経由してHTTPトンネリングを使

用する場合に指定します。http_proxy、http_proxy_portは、“http_proxy_use=yes”のときに有効であり、Webブラウザで使

用しているHTTPプロキシサーバのホスト名とポート番号を指定します。

注3) SSL接続のコネクションとSSL接続でないコネクションは別コネクションとして数える必要があります。max_IIOP_resp_con、

max_IIOP_local_init_conパラメタを見積もる際には注意してください。

◆セキュリティ機能に関する動作環境(CORBAサービス資源)


省略値

指定範囲

iss_use no CORBAサービス資源のセキュリティ強化機能の有効/無効を指定。“yes”を指定すると、CORBAアプリケーション

はiss_groupのグループに属するユーザ(またはroot)のみ

が起動可能となります。

(注1) (注2)

no

yes, no

iss_group root(0) CORBAサービス資源のセキュリティ強化機能有効時

（iss_use=yes指定）のアプリケーション動作のグループIDを指定します。

(注1) (注2) (注3)(注4)

root(0)

－

注1) インストール時のセキュリティ設定として“強化セキュリティモード”を選択した場合、初期値は以下のように変更されてい

ます。

パラメタ名初期値

iss_use yes

iss_group インストール時に指定した“Interstage運用グループ名”

注2) CORBAサービス資源のセキュリティ強化機能に関する設定を変更する場合、issetsecuritymodeコマンドの使用を推奨

します。詳細は“セキュリティシステム運用ガイド”の“共通の対策”および“リファレンスマニュアル(コマンド編)”の

“issetsecuritymode”を参照してください。

注3) すでにシステムに登録されているグループを指定してください。

なお、指定したグループのエントリ情報の取得処理が行われます。また、指定した値に関わらず、sysとotherグループの

エントリ情報の取得処理も行われます。このとき、OSの設定(nsswitch.conf)によってはLDAP等と通信する場合もありま

す。詳細はOSのマニュアルを参照してください。

注4) CORBAアプリケーションの実行は、iss_groupに指定したグループに属するユーザまたはrootに限定され、他の一般ユー

ザは実行できなくなりますので、アプリケーションの実行ユーザに注意してください(“リファレンスマニュアル(コマンド編)”の“OD_impl_inst”を参照)。

- 276 -

◆コード変換機能に関する動作環境


省略値

指定範囲

undefined_char_conversion single 未定義文字をコード変換した場合の動作を設定します。

・ single: デフォルト

すべての未定義文字は半角のアンダースコアに変換

します。 (注1)

・ multi半角の未定義文字は半角のアンダースコアに変換し、

全角の未定義文字は全角のアンダースコアに変換しま

す。

・ fail未定義文字の変換を行うとアプリケーションにシステム

例外DATA_CONVERSIONを通知します。

(注2)

single

single,multi, fail

注1) 文字コードがUNICODEまたはUTF8の場合は、“multi”を指定した場合と同様に全角の未定義文字は全角のアンダー

スコアに変換します。

注2) クライアントおよびサーバの両方で設定してください。コード変換機能の詳細については“OLTPサーバ運用ガイド”の

“コード変換”を参照してください。

◆保守機能に関する動作環境


省略値

指定範囲

access_log_policy start(初期値を推奨)

CORBAサービス起動時のアクセスログの採取/非採取

の状態。

・ start: 起動時からログ採取する

・ standby: ログ採取しない

サーバ機能

のみ有効

(注1)start

start, standby

access_log_size 3000000 アクセスログファイルの大サイズ。(バイト単位) サーバ機能

のみ有効

(注1)3000000

1～2147483647(longの大値)

access_log_level send_stex:recv_stex:send_userex:recv_userex:close_resp_info

アクセスログ採取レベルのキーワードを連結して指定。

(区切り文字はコロン(“:”)、空白は指定不可)“all”を指定すると、すべての採取レベルを指定したも

のとみなされます。

サーバ機能

のみ有効

(注1) (注2)

send_stex:recv_stex:send_userex:recv_userex:close_resp_info

- 277 -


省略値

指定範囲

－

error_log_policy start(初期値を推奨)

CORBAサービス起動時のエラーログの採取/非採取の

状態。



(注1)

start

start, standby

error_log_size 3000000 エラーログファイルの大サイズ。(バイト単位) (注1)

3000000

1～2147483647(longの大値)

info_log_policy start(初期値を推奨)

CORBAサービス起動時のインフォメーションログの採

取/非採取の状態。



(注1)

start

start, standby

info_log_size 3000000 インフォメーションログファイルの大サイズ。(バイト単

位)(注1)

3000000

1～2147483647(longの大値)

logging no 内部ログの採取を指定。

・ yes: 採取する

・ no : 採取しない

(注3)

no

yes, no

log_file_size 10000000 内部ログのファイルサイズの上限値。(バイト単位)“logging = yes”とする場合、本パラメタは省略しないで

ください。

(注3)

-1

4096～

2147483647(longの大値)

process_log_policy start(初期値を推奨)

CORBAサービス起動時のプロセスログの採取/非採取

の状態。



(注1)

start

start, standby

process_log_size 3000000 プロセスログファイルの大サイズ。(バイト単位) (注1)

3000000

1～2147483647(longの大値)

log_file_path －ログファイルの出力先を絶対パスで指定します。本パラ

メタで指定したパスには、以下のログファイルが出力さ

れます。

・アクセスログ

・エラーログ

・インフォメーションログ

・プロセスログ

(注1) (注3)(注4)

－

－

- 278 -


省略値

指定範囲

・内部ログ

本パラメタで指定したパスが存在しなかった場合、

CORBAサービスの起動に失敗します。

128バイトより長いパスは指定できません。128バイトより

長いパスを指定した場合、無効となります。

また、空白および“=”を含むパスは指定できません。空

白または“=”を含むパスを指定した場合、その直前ま

でが有効となります。

“\”と“/”は区別されず、共にフォルダの区切りとして使

用されます。

snap_size 40000 スナップショットサイズの上限値。(バイト単位) サーバ機能

のみ有効40000

1024～

2147483647(longの大値)(注5)

snap_use yes スナップショットの採取を指定。



サーバ機能

のみ有効yes

yes, no

trace_file_synch_level stop トレースファイルへの出力タイミングを指定。複数指定

可能(セパレータは“&”)。

・ none:odformtraceコマンド実行時のみ出力。

・ exit:アプリケーション正常終了時、終了したアプリ

ケーションのトレース情報を出力。

・ vanish:アプリケーション異常終了時、終了したアプ

リケーションのトレース情報を出力。

・ stop:CORBAサービス終了時、すべてのアプリケー

ションのトレース情報を出力。

・ loop:メモリ上に採取されたトレース情報のサイズが

trace_size_per_processを超えた場合に出力。

サーバ機能

のみ有効stop

－

trace_size_per_process 10000 プロセスごとのトレース情報サイズの大値(バイト単

位)。サーバ機能

のみ有効10000

1024～

100000000(注5)

trace_size_of_daemon 0 CORBAサービスのデーモンプロセスに対するトレース

情報サイズの大値(バイト単位)。0を指定すると、“trace_size_per_process × 32”が設定

されます。

なお、計算結果が100000000を超えた場合は

100000000が設定されます。

trace_size_per_processよりも小さな値を設定した場合

は、trace_size_per_processの値に補正されます。

0

0, 1024～

100000000

- 279 -


省略値

指定範囲

trace_use yes(初期値を推奨)

トレース情報の採取を指定



サーバ機能

のみ有効

yes

yes, no

注1) アクセスログ・プロセスログ・エラーログ・インフォメーションログは、“log_file_path”で指定したパスに採取されます。

“log_file_path”を指定しなかった場合は、以下のパスに採取されます。

また、ディスク領域として、以下のログファイルサイズの合計分が必要となります。

ログファイル格納パス

C:\Interstage\ODWIN\var 配下 (インストールパスはデフォルト)

/var/opt/FSUNod 配下 (インストールパスはデフォルト)

/var/opt/FJSVod 配下

ログファイル名とファイルサイズ

ログ名ログファイル名ログファイルサイズ

アクセスログ accesslogaccesslog.old

access_log_size×2

プロセスログ

(サーバ用ライブラリ(ODSV.DLL,libOM.so)をリンクしている場合)

proclogproclog.old

process_log_size×2

プロセスログ

(クライアント用ライブラリ

(ODWIN.DLL)をリンクしている場合)

proclogclproclogcl.old

process_log_size×2

エラーログ


errlogerrlog.old

error_log_size×2

エラーログ



errlogclerrlogcl.old

error_log_size×2

インフォメーションログ


infologinfolog.old

info_log_size×2

インフォメーションログ



infologclinfologcl.old

info_log_size×2

以下のログファイルを採取するためには、ログファイル格納パスに、管理者権限グループに対する書き込みのアク

セス許可が必要です。

- 280 -

－アクセスログ

－プロセスログ(サーバ用ライブラリをリンクしている場合)

－エラーログ(サーバ用ライブラリをリンクしている場合)

－インフォメーションログ(サーバ用ライブラリをリンクしている場合)

また、以下のログファイルを採取するためには、ログファイル格納パスに、クライアントアプリケーションを実行するユー

ザが所属しているグループに対する書き込みのアクセス許可が必要です。

－プロセスログ(クライアント用ライブラリをリンクしている場合)

－エラーログ(クライアント用ライブラリをリンクしている場合)

－インフォメーションログ(クライアント用ライブラリをリンクしている場合)

上記のアクセス許可がない場合はログファイルの出力に失敗しますが、この際、特にエラーメッセージなどが表示さ

れない場合があります。このため、ログファイルを採取する際には、運用前にログファイル格納パスのアクセス許可が

正しく設定されているか確認してください。

注2) access_log_level(アクセスログ採取レベル)に指定可能なキーワードは、“トラブルシューティング集”の“障害調査資

料の採取”－“CORBAサービスのログ情報の採取”を参照してください。

注3) “logging=yes”を指定した場合、内部ログファイルへの出力処理に時間を要するため、CORBAサービスの性能が劣

化し、CORBAアプリケーションのレスポンス性能が低下します。また、インタフェースリポジトリやネーミングサービスの

起動に時間がかかります。

なお、インタフェースリポジトリおよびネーミングサービスの起動に1分以上かかった場合、Interstageの起動に失敗し

ますので注意してください。“logging=yes”を指定してInterstageの起動に失敗した場合は、“トラブルシューティング

集”の“Interstageの起動/停止時の異常”を参照して対処を実施してください。

“logging=yes”を指定した場合、内部ログは“log_file_path”で指定したパスに採取されます。“log_file_path”を指定

しなかった場合は、以下のパスに出力されます。ファイル名は“log_file_path”の指定にかかわらず共通です。

パス: C:\Interstage\ODWIN\varファイル名: ・log (log.old) ・アプリケーションごとのappNNNN.log(appNNNN.old) (NNNNは英数字)

パス: /var/opt/FSUNodファイル名: /log (log.old)

パス: /var/opt/FJSVodファイル名: /log (log.old)

プレインストール型Javaライブラリ使用時は、上記に加えて、以下のファイルに出力されます。“log_file_path”の値は

影響しません。

－ユーザ作業ディレクトリ(Java VMのシステムプロパティのuser.dirの指す位置)配下

JVxxxxxxxxxx.log (xxxxxxxxxxは数字)アプレット運用の場合、user.dirはJava VMの起動オプションで変更可能です。

注4) マルチシステムを使用する場合、デフォルトシステムとマルチシステムで同じ値を指定しないでください。ログファイ

ルが正常に出力されない場合があります。

注5) Interstage Web Server Expressでは、初期値より大きい値は指定しないでください。

- 281 -

◆旧バーションの互換に関する動作環境


省略値

指定範囲

msg_output_compatible

no 以下のメッセージの出力有無を指定します。システムログ

に以下のメッセージを出力する場合は、メッセージ番号を

指定します。複数指定する場合は、アンパサンド(&)で区

切って指定します。以下のメッセージを出力しない場合は、

“no”を指定します。

・ od10301

・ od10605

・ od10924

・ od10925

・ od10926

・ od10941

・ od11101

・ od60003

no

od10301,od10605,od10924,od10925,od10926,od10941,od11101,od60003,no

A.2 gwconfig

■概要

gwconfigファイルは、HTTPトンネリング使用時に、Webサーバで起動されるHTTP-IIOPゲートウェイの動作環境を定義

するファイルです。

CORBAサービスのタイムアウト監視に関連する項目を修正した場合に、同様の項目について定義を修正する必要が

あります。

なお、初期値から変更しない場合、gwconfigファイルは必要ありません。

■ファイル名

C:\Interstage\ODWIN\etc\gwconfig (インストールパスはデフォルト)

/etc/opt/FSUNod/gwconfig (インストールパスはデフォルト)

/etc/opt/FJSVod/gwconfig


gwconfigファイルは、以下の形式で値を設定します。

◆形式:



# コメント

- 282 -

◆記述例:

timeout_response=60

◆パラメタ:

設定値を変更することのできるパラメタを下表に示します。

パラメタ名初期値意味

指定範囲

timeout_response 360 リクエストの返信待ち時間

HTTP-IIOPゲートウェイにおける、リクエスト送信から返信までの待機時間

(秒)。この時間内にサーバメソッドから返信されないと、クライアントにタイムアウ

トが通知されます。クライアント側で、CORBAサービスの

period_receive_timeout(クライアント側のリクエスト送信から返信までの待

機時間。configファイルで定義)を変更した場合、このパラメタは、

period_receive_timeout値以下になるよう変更する必要があります。0を指

定するとタイムアウトを行いません。

0～

100000000

timeout_session 180 セション保持時間(クライアント間無通信監視時間)HTTP-IIOPゲートウェイにおける、クライアントの管理単位の保持時間(秒)。サーバからの返信待ちがない状態で、この時間内にクライアントから新た

なリクエスト送信がない場合には、クライアントの管理情報は破棄されま

す。0を指定するとタイムアウトを行いません。

0～

2147483647

timeout_connection 60 コネクション保持時間(サーバ間無通信監視時間)HTTP-IIOPゲートウェイにおける、無通信状態の監視時間。

サーバからの返信待ちがない状態で、この時間内にクライアントから新た

なリクエスト送信がない場合には、サーバとのコネクションを切断します。0を指定するとタイムアウトを行いません。

0～

2147483647

logmode 5 HTTP-IIOPゲートウェイの内部ログ採取の有無 (注)以下から指定します。

・ 5:内部ログ情報を採取しません。

・ 3:リクエストデータおよびエラー発生時の情報を採取します。

・ 2:“3”で採取する情報に加えて、リプライデータおよび内部処理の情

報を採取します。

・ 1:“2”で採取する情報に加えて、トレース情報を採取します。

1～5

max_log_file_size 1048576 ログファイルサイズ(バイト単位)

1048576～

10485760

注)

・ HTTP-IIOPゲートウェイの内部ログは、以下に出力されます。

内部ログの出力先は環境変数OD_HTTPGW_HOMEまたはOD_HOMEより変更可能です。

C:\Interstage\ODWIN\var\httpgw*_0.log(httpgw*_1.log) (*は英数字)

/opt/FSUNod/var/httpgw*_0.log(httpgw*_1.log) (*は英数字)

- 283 -

/opt/FJSVod/var/httpgw*_0.log(httpgw*_1.log) (*は英数字)

・内部ログ採取を終了するためには、gwconfigにパラメタを設定した後、Webサーバを再起動する必要があります。

・ HTTP-IIOPゲートウェイの内部ログが出力されるディレクトリにInterstage HTTP Serverのサーバプロセスを実行する

ユーザ名/グループ名の書き込み権を設定してください。書き込み権がない場合、システムログにメッセージod40102が出力されます。

・定義情報を変更した場合、次回のWebサーバ起動時より有効となります。

・ gwconfigファイルの格納位置

gwconfigファイルの格納場所は、環境変数OD_HTTPGW_HOMEまたはOD_HOMEで指定することが可能です。両

方指定されている場合にはOD_HTTPGW_HOMEが優先され、指定されたディレクトリ配下のetcディレクトリに格納

します。また、同ディレクトリ配下にvarディレクトリを作成してください。

・終行には、必ず改行を入れてください。

・設定値に数字以外が含まれた場合、数字までを有効とします。

・ SolarisまたはLinuxの場合、通信ごとにコネクションを解放します。このため、timeout_sessionおよびtimeout_connectionを設定する必要はありません（設定しても値は無視されます）。

Windowsの場合、timeout_sessionおよびtimeout_connectionのタイムアウトの契機でコネクションを解放します。この

ため、これらのパラメタに0を設定すると、コネクションがリークする可能性があります。

A.3 inithost/initial_hosts

■概要

inithost/initial_hostsファイルは、ネーミングサービス、インタフェースリポジトリのホスト情報を定義するファイルです(ネー

ミングサービス、インタフェースリポジトリは、CORBAアプリケーション連携を行う場合に必要となる、アプリケーションの所

在、インタフェース情報が登録されているサービスです)。

inithost/initial_hostsには、サービスが存在するホスト名(またはIPアドレス)とCORBAサービスのポート番号(デフォルト

8002)を指定します。ホスト名・ポート番号は大16組まで指定できます。

サービスの問い合わせは定義順に行われ、参照するサービスが存在しない場合は次行に定義されているホストに問い

合わせを行います。ただしCORBAサービス起動時に名前解決に失敗したホストに対する問い合わせは、名前解決に成

功した全てのホストへの問い合わせに失敗した後に行われます。

なお、ネーミングサービス・インタフェースリポジトリをローカルホスト上で動作させる場合は、ホスト名・ポート番号の設定

は必要ありません。

■ファイル名

C:\Interstage\ODWIN\etc\inithost (インストールパスはデフォルト)

Solarisサーバ: /etc/opt/FSUNod/initial_hosts (インストールパスはデフォルト)Windows(R)クライアント: C:\Interstage\ODWIN\etc\inithost (インストールパスはデフォルト)

- 284 -

Linuxサーバ: /etc/opt/FJSVod/initial_hosts (インストールパスはデフォルト)Windows(R)クライアント: C:\Interstage\ODWIN\etc\inithost (インストールパスはデフォルト)


inithost/initial_hostsファイルは、以下の形式で値を設定します。

◆形式:

ホスト名ポート番号


# コメント

◆記述例:

# comment hostname 8002

◆パラメタ:



ホスト名なしネーミングサービス、またはインタフェースリポジトリサービスが動作して

いるホスト名(またはIPアドレス)を指定します。ホスト名の長さとして、64バ

イトまで指定できます。 (注1)(注2)

ポート番号なし上記サービスが動作しているホストで定義されているCORBAサービスの

ポート番号を指定します。

注1) サーバ側のイニシャルサービスやネーミングサービスに登録されているオブジェクトリファレンスに設定されているホスト

名に対して名前解決(IPアドレスへの変換)が可能である必要があります。登録されているオブジェクトリファレンスの情報

を参照する場合は、サーバ側でOD_or_admコマンド(-lオプション)及びodlistnsコマンド(-lオプション)を実行してください。

なお、自ホスト側/サーバ側(サービスが動作しているホスト)のホスト名定義と統一させて指定する必要があります。

[自ホスト側] Windows(R)システムフォルダ\system32\drivers\etc配下のlmhostsまたはhosts

[自ホスト側] /etc/hostsまたはNIS+など

[サーバ側] サーバ側のホスト名定義

注2) ホスト名に自ホストのホスト名やIPアドレスは指定しないでください。自ホスト名を指定した場合、サービスの問い合わせ

がループする場合があります。

- 285 -

・定義情報の変更について

定義情報を変更した場合、次回のCORBAサービス起動時より有効となります。

・ isinit、ismodifyserviceコマンドの実行および設定について

－ isinitおよびismodifyserviceコマンドを実行する場合は、inithost/initial_hostsファイルに指定されているインタフェー

スリポジトリサービスおよびネーミングサービスのホスト名を、コメントまたは削除してください。

－ inithost/initial_hostsファイルの設定は、isinitおよびismodifyserviceコマンドの実行後に可能になります。

－ inithost/initial_hostsファイルにホスト名が設定されている場合でも、isinitおよびismodifyserviceコマンドで設定し

たホスト名が優先されます。

また、isinitおよびismodifyserviceコマンドで設定したホスト名は、inithost/initial_hostsファイルに設定する必要は

ありません。

－ isinitおよびismodifyserviceコマンドを実行して環境設定を行った場合、inithost/initial_hostsファイルを使用して

ネーミングサービスのリモートホスト運用を行うことはできません。それは、isinitおよびismodifyserviceコマンドを

使用すると、ネーミングサービスのリモートホスト名がイニシャルサービスに設定されるため、inithost/initial_hostsファイルが使用されないためです。

－ inithost/initial_hostsファイルを使用してネーミングサービスのリモートホスト運用が行えるのは、isinitおよび

ismodifyserviceコマンドが含まれないCORBAサービスクライアントでの運用に限られます。

・不要なホスト情報定義について

Windows(R)クライアントのinithostに、存在しない、または通信不可状態のホストが定義された場合、クライアントアプ

リケーションの動作が遅くなることがあります。不要なホスト名は削除してください。

ホスト名・ポート番号の設定は、odsethostコマンドでも行うことができます。

A.4 queue_policy

■概要

queue_policyファイルは、キュー制御機能のキューポリシーとして使用されるファイルです。

サンプルファイルとして queue_policy.default を提供していますので、キュー制御機能を使用する場合は、

queue_policy.defaultを編集してqueue_policyファイルを作成してください。

■ファイル名

C:\Interstage\ODWIN\etc\queue_policy (インストールパスはデフォルト)

/etc/opt/FSUNod/queue_policy (インストールパスはデフォルト)

/etc/opt/FJSVod/queue_policy


queue_policyには、[QUEUEGROUP]セクション、[QUEUE]セクション、[GUARANTY]セクションに分かれています。

[QUEUEGROUP]セクションおよび[QUEUE]セクションは、odsetqueコマンドで更新します。

- 286 -

[GUARANTY]セクションはエディタなどで変更してください。[GUARANTY]セクションが未定義の場合の大値は、

“リファレンスマニュアル(コマンド編)”の“odsetque”を参照してください。

◆形式:

[GUARANTY] キュー名 = キューの上限値

◆記述例:

[GUARANTY] queue1 = 64

◆パラメタ:


パラメタ名指定範囲意味

キュー名 (注2) － odsetqueコマンドで登録したキュー名を指定します。

キューの上限値 1～2147483647(longの大値)

キューの上限値を指定します。(省略不可) (注1)

注1) すべての上限値の合計が、limit_of_max_IIOP_resp_requests以下になるように設定する必要があります。

limit_of_max_IIOP_resp_requestsのデフォルト値は以下となります。

max_IIOP_resp_requests × 1.3 (小数部分切り捨て)

0が指定された場合、デフォルト値となります。

isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場合

は、max_IIOP_resp_requestsとなります。

注2) CORBAサービスが持っているキューと設定値について下表に示します。

キュー名設定値(キューの上限値)

SYSTEM_GLOBAL 変更不可

OD_ORB_QUEUE 変更不可

COS_NAMING_QUE max_IIOP_resp_con以上の値

INTERFACE_REP_QUE max_IIOP_resp_con以上の値

・定義情報を変更した場合、次回のCORBAサービス起動時より有効となります。

・ odsetqueコマンドで登録した際、[GUARANTY]にはキュー情報が追加されません。キューの上限値を設定する場

合、新たに定義を追加する必要があります。

A.5 nsconfig

- 287 -

■概要

nsconfigファイルは、ネーミングサービスの動作環境を設定するファイルです。

■ファイル名

C:\Interstage\ODWIN\etc\nsconfig (インストールパスはデフォルト)

/etc/opt/FSUNod/nsconfig (インストールパスはデフォルト)

/etc/opt/FJSVod/nsconfig


nsconfigファイルは、以下の形式で値を設定します。

◆形式:


パラメタ名と設定値の間の文字列は、“ = ”(半角スペース＋半角イコール＋半角スペース)を設定します。


# コメント

◆記述例:

file_sync = yes trace_level = update bl_how_many = 65536 ogl_how_many = 256 ext_intf = yes cn_userexception_log_use = yes cn_userexception_log_size = 2000000

◆パラメタ:

設定値を変更することのできるパラメタを下表に示します。なお、指定が必須となるパラメタはありません。


指定範囲

file_sync yes ネーミングサービスのデータベースへの更新処理でファイルの同期書き

込みを行うかを設定します。

・ yes: ファイルの同期書き込みを行う。

・ no : ファイルの同期書き込みを行わない。

初期創成などの大量データの更新時に、このパラメタをnoにすることによ

り処理を高速化することができます。ネーミングサービスの運用中には、

信頼性を向上させるため、本パラメタはyesにしてください。

yes, no

trace_level update メソッド実行の自動トレースを採取するトレースレベルを指定します。

・ update: 更新ログだけを採取する。

- 288 -


指定範囲

update,all

・ all: すべてのトレースを採取する。

bl_how_many 65536 NamingContext::list, BindingIterator::next_nで返されるバインディング数

の大値を指定します。0～

65536

ogl_how_many 256(初期値を

推奨)

ロードバランスオブジェクトグループのリストの大値を指定します。

注) ネーミングサービスでは、ロードバランスオブジェクトグループのリスト

を作成する際、本パラメタの設定値によりメモリを獲得します。使用するメ

モリ容量に影響が発生するため、メモリ容量を考慮して必要小限の値

を設定してください。128～

256

ext_intf yes ネーミングサービスの拡張機能を使用するかを指定します。

・ yes: ネーミングサービスの拡張機能を使用する。

・ no : ネーミングサービスの拡張機能を使用しない。

noを指定すると、ネーミングコンテキスト拡張インタフェース

(NamingContextExtインタフェース)を使用できません。V2.X以前のクライ

アントアプリケーションを動作させる場合は、noを指定する必要がありま

す。

yes, no

cn_userexception_log_use yes ユーザ例外ログを採取するかを指定します。

・ yes: ユーザ例外ログを採取する。

・ no : ユーザ例外ログを採取しない。

yes, no

cn_userexception_log_size 2000000 ユーザ例外ログのファイルサイズを指定します。

1000～

2000000

・変更した値は、次回のネーミングサービス起動時より有効となります。

・パラメタext_intfに“no”を設定してV2.X以前のクライアントアプリケーションを動作させる場合は、運用に応じた対処

が必要となる場合があります。V2.X以前のネーミングサービスを使用する場合の注意事項については、“アプリケー

ション作成ガイド（CORBAサービス編）”の“旧バージョンからの移行上の注意”－“ネーミングサービスに関する注意

事項（V2以前のバージョンからの移行）”を参照してください。

A.6 irconfig

■概要

irconfigファイルは、インタフェースリポジトリのバックアップやログ情報などの動作環境を設定するファイルです。

■ファイル名

C:\Interstage\ODWIN\etc\irconfig (インストールパスはデフォルト)

- 289 -

/etc/opt/FSUNod/irconfig (インストールパスはデフォルト)

/etc/opt/FJSVod/irconfig


irconfigファイルは、以下の形式で値を設定します。

◆形式:



# コメント

◆記述例:

auto backup = no(yes) auto backup path = auto recovery = no(yes) logging = no(yes) logging memory size = 512 logfile path = sync = no select cache obj =

◆パラメタ:

設定値を変更することのできるパラメタを下表に示します。なお、指定が必須となるパラメタはありません。


指定範囲

autobackup

no インタフェースリポジトリ起動時に自動的にバックアップを行うかを指定し

ます。

・ yes: 自動的にバックアップを行う。

・ no : 自動的にバックアップを行わない。

注）バックアップは、インタフェースリポジトリ起動時に1回だけ行います。

yes, no

autobackuppath

－バックアップデータの格納場所を指定します。auto backup=yesと指定した

場合、必ずパスを指定する必要があります。パスを指定しないとバックアッ

プは行われません。

注）格納場所には、作成したデータベースサイズ以上の空き領域が必要

です。

－

autorecovery

no トランザクション処理中のシステムダウンなどによりデータベースの異常を

検出した場合に、バックアップデータを元に自動的にリカバリを行うかを

指定します。

・ yes: 自動的にリカバリを行う。

・ no : 自動的にリカバリを行わない。

注）本機能を使用する場合は“auto backup=yes”と指定し、auto backuppathを指定する必要があります。

- 290 -


指定範囲

yes, no

ir_timeout 1800(秒) IDLコンパイル(IDLc)およびインタフェース情報移入(odimportir)におい

て、インタフェースリポジトリへのリクエストの復帰までの待機時間を指定

します。0を指定すると、リクエスト復帰までの待機時間は監視されませ

ん。

0～

100000000(秒)

iss_use

no 資源保護機能の有効/無効を指定します。

・ yes: 資源保護機能を有効とする。

・ no : 資源保護機能を無効とする。

“yes”を指定すると、インタフェースリポジトリはデータベース管理者(デフォ

ルト：root)のみが運用可能となります。

注）インストール時のセキュリティ設定として“強化セキュリティモード”を選

択した場合、初期値は“yes”になります。

yes, no

logging no トラブル発生時にログ情報を採取するかを指定します。

・ yes : ログ情報を採取する。

・ no : ログ情報を採取しない。

採取したログは、irlogdumpコマンドによりファイルに出力できます。通常

は、初期値(no)で運用します。

yes, no

loggingmemorysize

512(KB) ログ情報を格納する共用メモリのサイズを指定します。logging=noとした

場合、この値は意味を持ちません。1～4096(KB)

logfilepath

－ “logging=yes”とした場合、irlogdumpコマンドにより出力されるログ情報の

格納ディレクトリをフルパスで指定します。パスを指定しない場合は、

CORBAサービスの動作ディレクトリと同一のディレクトリに格納されます

(“A.1 config”参照)。“logging=no”と指定した場合、この値は意味を持ちません。

－

selectcache obj

－インタフェースリポジトリ起動時にキャッシュ対象とするオブジェクトを指定

します。

キャッシュ対象オブジェクトは、テキストファイル内にキャッシュ対象オブ

ジェクトのリポジトリIDを記述し、そのファイル名をフルパスで指定します。

ファイル名が指定されない場合は、全登録オブジェクトがキャッシュ対象

となります。

ファイルの作成例および注意事項については、以下のキャッシュ対象オ

ブジェクトの指定方法を参照してください。

－

sync no 同期モードを指定します。

yes:同期モードを指定します。

no:同期モードを指定しません。

“no”を指定すると、データベースへの書き込みと同期しないモードで動

作するため、インタフェースリポジトリ更新処理のスループットが向上しま

す。ただし、更新中のシステムダウンなどで発生するデータベース破壊を

認識できない場合があります。

“yes”を指定すると、トランザクション単位での書き込みを保証するため、

同期モードで動作します。信頼性が要求されるシステムを構築する場合

に設定します(データベース破壊の認識可)。同期モードを指定した場合、指定しない場合に比べて更新処理のスルー

プットは低下します。このとき、クライアントへのサーバメソッドの復帰時間

が長くなるため、タイムアウトが発生する可能性があります。これを防ぐに

は、“A.1 config”のperiod_receive_timeout値をチューニングしてください。

yes, no

- 291 -

◆キャッシュ対象オブジェクトの指定方法

インタフェースリポジトリ起動時、キャッシュ対象オブジェクトを限定することにより、インタフェースリポジトリに大量のオブ

ジェクトが登録されている場合の起動性能を改善することができます。

ただし、キャッシュ対象オブジェクトを指定した場合は、キャッシュ対象としないオブジェクトに対する参照性能は低下す

るため、運用に関しては注意が必要です。

また、キャッシュ対象オブジェクトを指定してインタフェースリポジトリを起動した場合は、以後、インタフェースリポジトリ

に対する登録/更新(IDLc, tdc, odimportir)を行うことができません。運用時(インタフェースリポジトリの登録/更新を行わな

い)に使用してください。

キャッシュ対象オブジェクトは、ユーザがテキストファイル内にキャッシュ対象オブジェクトのリポジトリIDを記述します。

リポジトリIDは、Repositoryオブジェクト(ルートオブジェクト)に直接包含されるModuleDefオブジェクトまたはInterfaceDefオブジェクトのみ指定可能で、指定されたオブジェクトに包含されるオブジェクトすべてがキャッシュ対象となります。

キャッシュ対象オブジェクトが継承またはスコープ参照で他のモジュールと関連付けられている場合は、そのモジュー

ルもキャッシュ対象として指定する必要があります。

インタフェースリポジトリで管理するオブジェクトの種類、およびインタフェースリポジトリオブジェクトの包含/継承関係に

ついては“アプリケーション作成ガイド(CORBAサービス編)”(Interstage Application Server Enterprise Editionで提供)の“インタフェースリポジトリサービスのプログラミング”を参照してください。

なお、インタフェースリポジトリに登録されているオブジェクトと包含関係については、odlistirコマンドで表示できます。

キャッシュ対象オブジェクトを指定するためのファイルの記述例を以下に示します。

IDL:testmodule1:1.0

IDL:testmodule2:1.0

IDL:testmodule3:1.0

注) 1行に、キャッシュ対象オブジェクトのリポジトリIDを1つだけ記述できます。

コメントは、使用できません。

・変更した値は、次回のインタフェースリポジトリサービス起動時より有効となります。

・ ismodifyserviceで環境設定を行う際に“auto backup”が指定されていた場合は、データベースが空の状態でバック

アップが行われます。この状態でバックアップされたデータベースは、使用できません。

・ auto backup機能はインタフェースリポジトリ起動時の状態でバックアップが行われます。起動後に更新されたインタ

フェース定義情報はバックアップに反映されません。起動後に更新された情報が必要な場合は、Interstage(インタ

フェースリポジトリ)を再起動するか、またはodbackupsysコマンドを使用してバックアップを行ってください。

・ odbackupsysコマンドでは、キャッシュ対象オブジェクトを指定したファイルをバックアップできません。ファイルのコピー

コマンドなどでバックアップを行ってください。

・インタフェースリポジトリのデータベース管理者がroot（デフォルト）以外であり、かつirconfigファイルに“iss_use=yes”を設定すると、ログ情報採取機能の有効化（irconfigファイルの“logging=yes”）を指定しても、インタフェースリポジト

リ（データベースアクセス機能）のログ情報が採取されなくなります（キャッシュサーバのログ情報は採取されます）。

また、irconfigファイルに"iss_use=yes"を設定した場合は、irlogdumpコマンド（ログ情報の出力・制御）は管理者権限

（root）で実行する必要があります。

- 292 -

付録B コンポーネントトランザクションサービスの環境定義

コンポーネントトランザクションサービスの環境定義ファイルについて説明します。本定義ファイルは、以下に格納されま

す。

格納パス

(インストールパスはデフォルト)

C:\Interstage\etc\sysdef


/var/opt/FSUNtd/etc/sysdef

/var/opt/FJSVtd/etc/sysdef

本定義ファイルは、コンポーネントトランザクションサービスが停止している時に、変更可能です。

コンポーネントトランザクションサービスの環境定義の記述形式と制御文について説明します。

注意

万一のため、運用環境を構築したら資源のバックアップを行うことを推奨します。バックアップについては、“運用ガイド

(基本編)”の“メンテナンス(資源のバックアップ/他サーバへの資源移行/ホスト情報の変更)”を参照してください。

B.1 記述形式

通常ファイル記述形式は、以下の構文により構成されます。なお、通常ファイルの記述形式に誤りがあった場合、構文エ

ラーとなります。構文エラー時には、そのファイルに記述されているすべての内容が無効となります。

・ステートメント

・セクション

・コメント行

・空行

B.1.1 ステートメント

ステートメントとは、情報を設定するための行であり、以下の形式で記述します。

キーワード: 設定内容(\n)

ステートメントは、キーワード、“:”(コロン)、および設定内容から構成されています。

ステートメントの記述規則を以下に示します。

・ステートメントを省略する場合、対象ステートメントを削除するか、設定内容だけ省略します。

・ステートメントを記述している行にコメントは記述できません。

ステートメントを構成する情報の詳細を以下に説明します。

■キーワード

固有のキーワードを設定します。キーワードには、以下の規則があります。

・キーワードは対象行の先頭の英数字から“:”(コロン)の直前までを意味します。

・キーワードには英数字で始まる英数字とスペースで構成されている文字列を指定できます。

- 293 -

・キーワード中に指定されている英字の大文字/小文字の区別はしません。

・キーワード中にスペースを含むことができます。

・キーワード中に連続したスペースが指定された場合、1つのスペースが指定されたものとみなされます。

・対象行の先頭にスペースやタブが指定されている場合、そのスペースやタブは無視されます。

■:(コロン)

キーワードと設定内容の区切りをあらわす文字として使用し、以下の規則があります。

・コロンは必ず半角で指定する必要があります。

・コロンの前後にスペースやタブが記述されている場合、そのスペースやタブは無視されます。

■設定内容

キーワードに対応する内容を設定します。設定内容には、以下の規則があります。

・設定内容は、対象行の“:”の直後から指定できます。それ以降の“:”は設定内容に含まれる文字として扱われます。

・設定内容の終わりはスペース、タブ、改行('\n')、またはEOFで示します。

・設定内容に指定されている英字の大文字/小文字は区別されます。

・設定内容は、1つの文字列しか指定できません。

・設定内容中にスペースやタブが含まれる場合、二重引用符で囲む必要があります。

・設定内容を複数記述する場合、ステートメントを繰り返し記述します。

ステートメントの設定例

例1)キーワード“Keyword:”には“Information”を設定します。

Keyword: Information(\n) KEYWORD: Information(\n) KeyWord: Information(\n) Keyword: Information(\n) Keyword: Information(\n)

以上のステートメントはすべて同じように解析されます。

例2)キーワード“This is a Keyword:”には“Information Area”を設定します。

This is a Keyword: "Information Area"(\n) THIS IS A KEYWORD: "Information Area"(\n) This is a keyword: "Information Area"(\n) This is a Keyword: "Information Area"(\n)

以上のステートメントはすべて同じように解析されます。

構文エラーとなるステートメントの例

# 設定内容が2つ指定されている(\n)

Keyword: Information Area(\n)

# ステートメントを記述している行にコメントが指定されている(\n)

Keyword: Information # This is a Statement(\n)

# 二重引用符で終了していない(\n)

Keyword: "START Information. (\n)

- 294 -

# キーワードと設定内容が2行で指定されている(\n)

Keyword: "START Information. (\n) Information END" (\n)

また、登録されていないキーワードを指定した場合も構文エラーとなります。

B.1.2 セクション

セクションとは、ステートメントの集合(グループ)であり、以下の形式で記述します。

[セクション名](\n) キーワード: 設定内容 (\n) キーワード: 設定内容 (\n)

セクションは、“[セクション名]”と複数のステートメントから構成されており、以下の規則があります。

・セクションとは“[セクション名]”で始まり、次のセクション、またはEOFまでを意味します。

・セクションを省略する場合、セクションをすべて削除するか、コメントにする必要があります。

・ “[セクション名]”だけのセクションは指定できません。

・ “[セクション名]”を記述する行に“[セクション名]”以外は記述できません。

・セクション名は必ず[ ](角括弧)で囲む必要があります。

・セクション名には英数字で始まる英数字とスペースで構成されている文字列を指定できます。

・セクション名に指定されている英字の大文字/小文字の区別はしません。

・ “[セクション名]”を記述している行にコメントは指定できません。

正常なセクションの設定例

# セクションにステートメントが1つある(\n)

[Section] (\n) Keyword: Information(\n)

# セクションにステートメントが3つある(\n)

[Section] (\n) Keyword1: Information(\n) Keyword2: Information(\n) Keyword3: Information(\n)

構文エラーとなるセクションの例

# [セクション名]が記述されている行にコメントが指定されている(\n)

[Section] # This is a Section(\n) Keyword: Information(\n)

# [セクション名]の角括弧が正しく終了していない(\n)

[Section(\n) Keyword: Information. (\n)

また、登録されていないセクション名を指定した場合も構文エラーとなります。

- 295 -

B.1.3 コメント行

コメント行は、通常ファイル中にコメント(注釈)を記述する時に使用します。以下の形式で記述します。

# コメント(\n)

コメント行には以下の規則があります。

・コメント行の先頭に#(シャープ)を指定します。

・ #は半角文字で指定する必要があります。

B.1.4 空行

空行を記述することができます。

空行は、解析時無視されます。

B.2 環境定義ファイルの制御文

B.2.1 [SYSTEM ENVIRONMENT]セクション

◆形式

[SYSTEM ENVIRONMENT]セクションは以下の形式で記述します。なお、本セクションは省略できません。

[SYSTEM ENVIRONMENT]

System Scale: システムの規模

Using Session Information Management Object: SMOの使用の有無

Name of Session Information Management Object: SMOのオブジェクト名

Number of Maximum WRAPPER Hold Session: システム大保留セション数

Number of Communication Buffer: トランザクションアプリケーションの

通信バッファ数

Using Interface Check: インタフェース情報チェック機能使

用の有無





Number of Maximum WRAPPER Hold Session: システム大保留セション数




用の有無

IP version: 使用するネットワークのバージョン


- 296 -







用の有無

◆設定内容

System Scale:システムの規模

システムの規模を指定します。

Interstage統合コマンドにより初期化を行った場合には、適切なシステム規模が設定されますので、修正する必要はあり

ません。

システム規模は、接続クライアント数より選択します。各定義値の意味を、以下に示します。

設定値システム規模接続クライアント数

small 小規模 1～5 1～50

moderate 中規模 6～10 51～100

large 大規模 11～50 101～500

super 超大規模 51～100 501～1000

Using Session Information Management Object:セション情報管理機能の使用の有無

セション情報管理機能の使用の有無を指定します。

・ YES: セション情報管理機能を使用する。

・ NO : セション情報管理機能を使用しない。省略値。

Name of Session Information Management Object:セション情報管理機能のオブジェクト名

セション情報管理機能のネーミングサービス登録時の名前を指定します。

指定できる値は、OD_or_admコマンドの-nオプションに指定可能な255バイト以内の値です。ただし、ネーミングコンテキ

ストの指定はできません。省略値は、“ISTD::SMO”です。

Using Session Information Management Object ステートメントに“NO”が指定された場合は、本ステートメントは無視され

ます。

Number of Maximum WRAPPER Hold Session:システム最大保留セション数

システム全体でのセション保留数を指定します。

0を指定した場合にはセションの抑制は行いません。

本定義は、[WRAPPER]セクションで指定するPSYS NameステートメントおよびNumber of Maximum Sessionステートメン

トを定義した場合に有効となります。

指定できる値は、0～1000です。省略値は、0です。

Number of Communication Buffer:トランザクションアプリケーションの通信バッファ数

トランザクションアプリケーションに対する通信時に使用するバッファの数です。本ステートメントで指定した通信バッファ

数に、4096byteを積算したサイズの通信バッファが用意されます。

指定できる値は、500～10000です。

1回の通信データ長×同時接続クライアント数を計算し、その値をもとに通信バッファ数を見積もってください。

- 297 -

通信バッファは、十分なサイズを用意してください。

なお、システムスケールにより、以下の省略値が設定されます。

small 500

moderate 1000

large 1500

super 2000

Using Interface Check:インタフェース情報チェック機能使用の有無

インタフェース情報チェック機能使用の有無を指定します。

・ YES: インタフェース情報チェック機能を使用する。

・ NO : インタフェース情報チェック機能を使用しない。省略値。

IP version:使用するネットワークのバージョン

使用するネットワークのバージョンを指定します。

・ v6: IPv6ネットワークを使用する。

・ v4: 従来のIPv4ネットワークを使用する。省略値。

B.2.2 [WRAPPER]セクション

◆形式

[WRAPPER]セクションは以下の形式で記述します。

[WRAPPER]

PSYS Name: 負荷抑制対象DPCF通信パス名

Number of Maximum Session: 大同時通信セション数

◆設定内容

PSYS Name:負荷抑制対象DPCF通信パス名

負荷抑制の対象とするDPCF通信パス名を8文字以内の英数字で指定します。

DPCF通信パス名については、以下を参照してください。

IDCMヘルプ

IDCM使用手引書

Number of Maximum Session:最大同時通信セション数

PSYS Nameステートメントで設定したDPCF通信パスにおける同時に通信できるセション数の大値を指定します。

指定できる値は、1～1000です。この値を超えたセションが、負荷抑制の対象となります。

注意

・負荷抑制機能を使用する場合、[SYSTEM ENVIRONMENT]セクションと[WRAPPER]セクションの各ステートメント

をすべて定義してください。

・ [WRAPPER]セクションのPSYS NameステートメントとNumber of Maximum Sessionステートメントはペアで指定します。

- 298 -

・複数のDPCF通信パスに対して負荷抑制を行う場合には、複数の[WRAPPER]セクションにPSYS Nameステートメン

トとNumber of Maximum Sessionステートメントをペアで指定します。

・ Number of Maximum Sessionステートメントに指定する値は、IDCMネットワーク定義で指定した優先会話コネクショ

ン数以下の値を指定してください。優先会話コネクション数より大きな値を指定した場合、負荷抑制されないことがあ

ります。

IDCMネットワーク定義の詳細は、以下を参照してください。

IDCMヘルプ

IDCM使用手引書

- 299 -

付録C データベース連携サービスの環境定義

データベース連携サービスの環境定義について説明します。

C.1 configファイル

■概要

configファイルは、OTSシステム起動時に反映される情報を管理している定義ファイルです。

注意

・ configファイルの修正を反映させるには、OTSシステムを再起動する必要があります。

・本ファイルで編集した値をInterstage管理コンソールから参照するためには、Interstage管理コンソールを再起動する

必要があります。Interstage管理コンソールの起動・停止方法は、“運用ガイド（基本編）”の“Interstage管理コンソール

によるInterstage運用”－“Interstage管理コンソールの起動・停止”を参照してください。

■ファイル名

configファイルは、インストール時に、以下に格納されます。


C:\Interstage\ots\etc\config


/opt/FSUNots/etc/config

/opt/FJSVots/etc/config


◆形式:

キー名=設定値

◆設定例

OBSERVE_CYCLE_TIME=6 (注)

TRAN_TIME_OUT=300

2PC_TIME_OUT=60

COM_RETRY_TIME=2 (注)

COM_RETRY_MAX=3 (注)

RECOVER_RETRY_TIME=30 (注)

RECOVER_RETRY_MAX=60 (注)

RESOURCE_TRANMAX=5

OTS_TRACE_SIZE=4096 (注)

RESOURCE_TRACE_SIZE=4096 (注)

RECOVERY_TRACE_SIZE=4096 (注)

OBSERVE_TRACE_SIZE=4096 (注)

DATABASE_RETRY_TIME=5 (注)

- 300 -

DATABASE_RETRY_MAX=5 (注)

MEM_RETRY_TIME=5 (注)

MEM_RETRY_MAX=5 (注)

RSCSTOP_CHECK_COUNT=100 (注)

OTS_VERSION=5 (注)

JTS_VERSION=5 (注)

TRACE_MODE=1

TRACE_LEVEL=1

JAVA_VERSION=14

PATH=C:\Interstage\JDK6\bin\java.exe....(Windows(R)の場合)

PATH=/opt/FJSVawjbk/jdk6/bin/java.......(Solaris/Linuxの場合)

注）インストール時に作成されたconfigファイルには、該当項目は記載されていません。項目を指定すると、値は有効とな

りますが、省略値から変更しないことを推奨します。

ポイント

・タイムアウトの詳細については、“OLTPサーバ運用ガイド”を参照してください。

・ configファイルの項目は、すべて省略可能です。省略時は、省略値が有効となります。

◆キー一覧

キー意味

OBSERVE_CYCLE_TIME 監視周期の指定

TRAN_TIME_OUT トランザクションタイムアウト検出時間の指定

2PC_TIME_OUT フェーズ間タイムアウト検出時間の指定

COM_RETRY_TIME トランザクション処理エラー時のリトライ間隔指定

COM_RETRY_MAX トランザクション処理リトライ上限回数の指定

RECOVER_RETRY_TIME OTSシステムリカバリ処理リトライ間隔指定

RECOVER_RETRY_MAX OTSシステムリカバリ処理リトライ上限回数の指定

RESOURCE_TRANMAX 1リソース管理プログラムのトランザクションの大多重度

OTS_TRACE_SIZE OTSシステムのトレースログサイズ指定

RESOURCE_TRACE_SIZE リソース管理プログラムのトレースログサイズ指定

RECOVERY_TRACE_SIZE リカバリプロセスのトレースログサイズ指定

OBSERVE_TRACE_SIZE 監視プロセスのトレースログサイズ指定

DATABASE_RETRY_TIME データベースシステムアクセスのリトライ間隔指定

DATABASE_RETRY_MAX データベースシステムアクセスのリトライ上限回数指定

MEM_RETRY_TIME OTSシステム処理中のエラーでのリトライ間隔指定

MEM_RETRY_MAX OTSシステム処理中のエラーでのリトライ上限回数指定

RSCSTOP_CHECK_COUNT 通常停止からのトランザクション待ち合わせ回数指定

OTS_VERSION OTSのバージョン

JTS_VERSION JTSのバージョン

JAVA_VERSION JDK/JREのバージョン

PATH JDK/JREのパス

TRACE_MODE トレースの出力形式

TRACE_LEVEL トレースの出力レベル

- 301 -

◆キー詳細

OBSERVE_CYCLE_TIME:監視周期の指定

OTSシステムが監視を実施する周期（秒単位）を指定します。以下の点に注意して設定してください。

－本値に小さい値を設定すると、頻繁に監視が行われるため、システムのパフォーマンスが低下します。

－本値に大きい値を設定すると、監視の間隔が長くなるため、異常の検出が遅くなります。

指定可能な範囲は、1～60です。省略値は、5です。

TRAN_TIME_OUT:トランザクションタイムアウト検出時間の指定

データベース連携サービスがトランザクションタイムアウト（beginからcommitまで）を検出する時間（秒単位）を指定し

ます。アプリケーションにおいてset_timeoutメソッドでタイムアウト時間を設定した場合は、アプリケーションの設定が

有効となります。


2PC_TIME_OUT:フェーズ間タイムアウト検出時間の指定

OTSシステムがトランザクションの2PC（2フェーズコミット）で、リソース管理プログラムにおいて1フェーズと2フェーズ間

のタイムアウトを検出する時間（秒単位）を指定します。


注意

CORBA サービスのクライアント側の無通信監視時間（ CORBA サービスの動作環境ファイルのパラメタ

“period_client_idle_con_timeout”の設定値×5）が“0”ではない場合、本値にはこの値よりも小さい値を設定してくだ

さい。

COM_RETRY_TIME:トランザクション処理エラー時のリトライ間隔指定

トランザクション処理で通信異常などのエラーが発生した場合に、その通信をリトライする間隔（秒単位）を指定します。


COM_RETRY_MAX:トランザクション処理リトライ上限回数の指定

トランザクション処理で通信異常などのエラーが発生した場合に、その通信をリトライする上限回数を指定します。


RECOVER_RETRY_TIME:OTSシステムリカバリ処理リトライ間隔指定

OTSシステムのリカバリ処理で通信異常などのエラーが発生した場合に、その通信をリトライする間隔（秒単位）を指

定します。


RECOVER_RETRY_MAX:OTSシステムリカバリ処理リトライ上限回数の指定

OTSシステムのリカバリ処理で通信異常などのエラーが発生した場合に、その通信をリトライする上限回数を指定します。


- 302 -

RESOURCE_TRANMAX:1リソース管理プログラムのトランザクションの最大多重度

1リソース管理プログラムのトランザクションの大多重度を指定します。


ポイント

OTSシステムのスレッド多重度と1リソース管理プログラムのトランザクションの大多重度は、以下の関係を保つよう

に設定してください。

OTSシステムのスレッド多重度＝＜ 1リソース管理プログラムのトランザクションの最大多重度

OTS_TRACE_SIZE:OTSシステムのトレースログサイズ指定

OTSシステムのトレースログサイズ（Kバイト単位）を指定します。

指定可能な範囲は、128～2147483647です。省略値は、4096（Kバイト）です。

RESOURCE_TRACE_SIZE:リソース管理プログラムのトレースログサイズ指定

リソース管理プログラムのトレースログサイズ（Kバイト単位）を指定します。


RECOVERY_TRACE_SIZE:リカバリプロセスのトレースログサイズ指定

リカバリプロセスのトレースログサイズ（Kバイト単位）を指定します。


OBSERVE_TRACE_SIZE:監視プロセスのトレースログサイズ指定

監視プロセスのトレースログサイズ（Kバイト単位）を指定します。


DATABASE_RETRY_TIME:データベースシステムアクセスのリトライ間隔指定

OTSシステムでのデータベースシステムへのアクセス時に、メモリ資源不足などのリトライ可能なエラーが発生した場

合のリトライ間隔（秒単位）を指定します。


DATABASE_RETRY_MAX:データベースシステムアクセスのリトライ上限回数指定

OTSシステムでのデータベースシステムへのアクセス時に、メモリ資源不足などのリトライ可能なエラーが発生した場

合にリトライする上限回数を指定します。


MEM_RETRY_TIME:OTSシステム処理中のエラーでのリトライ間隔指定

OTSシステムの処理中に、メモリ資源不足などのリトライ可能なエラーが発生した場合のリトライ間隔（秒単位）を指定

します。


- 303 -

MEM_RETRY_MAX:OTSシステム処理中のエラーでのリトライ上限回数指定

OTSシステムの処理中に、メモリ資源不足などのリトライ可能なエラーが発生した場合にリトライする上限回数を指定

します。


RSCSTOP_CHECK_COUNT:通常停止からのトランザクション待合せ回数指定

トランザクション処理中にリソース管理プログラムを通常停止し、トランザクション完了をOBSERVE_CYCLE_TIMEの

監視同期に合わせた待合せ回数を指定します。

OBSERVE_CYCLE_TIME × RSCSTOP_CHECK_COUNT秒間、トランザクションの完了を待ち合わせ、時間内に

完了しない場合は、リソース管理プログラムの停止を通常停止から強制停止に切り替えます。


OTS_VERSION:OTSのバージョン

OTSのバージョンを指定します。通常、変更しないでください。

省略値は、5です。

JTS_VERSION:JTSのバージョン

JTSのバージョンです。通常、変更しないでください。


JAVA_VERSION:JDK/JREのバージョン

JTS用リソース管理プログラムが利用するJavaのバージョンです。14を指定します。


PATH:JDK/JREのパス

JTS用リソース管理プログラムが利用するjavaコマンドへのパスをフルパスで指定します。java実行体を含めるパスを

指定してください。

初期値は、JDK/JRE 6のバージョンに対応したパスです。通常、変更しないでください。

注意

－ JTS用のリソース管理プログラムを利用する場合は、必ず指定してください。

－ Interstage Application Serverに同梱されているJDK/JREのパスを指定してください。

TRACE_MODE:トレースの出力形式

JTSを利用した環境で出力されるトレースの出力形式を、以下から選択して指定します。

－異常発生時に、OTSのインストールパス/var配下にトレースファイルを出力する場合：“1”

注）通常、“1”を選択してください。

－システムの状態に関係なく、常時、OTSのインストールパス/var配下にトレースファイルを出力する場合：“2”

注）常時出力されるため、ファイルサイズに注意してください。

－トレースファイルを出力しない場合：“3”

- 304 -

TRACE_LEVEL:トレースの出力レベル

JTSを利用した環境で出力されるトレースのモードを、“1”から“5”までの数値で指定します。数値が大きいほど、詳細

なトレース情報を出力します。

通常運用時は、“1”が指定されます。パフォーマンスに影響があるため、通常、変更しないでください。

C.2 セットアップ情報ファイル

■概要

セットアップ情報ファイルは、otssetupコマンドによるOTSシステム動作環境の設定時に指定するファイルです。isinitコマ

ンドでInterstageの初期化を行う場合は、“Interstage動作環境定義”をカスタマイズする必要があります。Interstage動作環

境定義の詳細については、“運用ガイド(基本編)”を参照してください。

セットアップ情報ファイルは、otssetupコマンド実行時に作成します。1度作成したセットアップ情報ファイルは、次回のセッ

トアップ時にも使用可能であるため、保管しておいてください。


◆形式:

パラメタ名=設定値

◆設定例

MODE=SYS

LOGFILE=c:\ots\logfile........(Windows(R)の場合)

LOGFILE=/dev/rdsk/c0t0d0s0....(Solarisの場合)

LOGFILE=/dev/raw/raw1.........(Linuxの場合)

TRANMAX=10

PARTICIPATE=4

OTS_FACT_THR_CONC=5

OTS_RECV_THR_CONC=2

JTS_RMP_PROC_CONC=5

JTS_RMP_THR_CONC=16

HOST=otshost

PORT=8002

LOCALE=EUC

ポイント

太字以外の項目は、省略可能です。省略時は、省略値が有効となります。

C.2.1 MODE: セットアップ種別

OTSシステムが動作するホストか、リソース管理プログラムだけが動作するホストかを、以下から選択して指定します。大

文字で指定してください。

・ OTSシステムおよびリソース管理プログラムが動作するホストの場合：“SYS”

OTSシステム動作環境のセットアップ、リソース管理プログラムの動作環境のセットアップ、およびシステムログファイ

ルの作成を行います。

・リソース管理プログラムだけが動作するホストの場合：“RMP”

リソース管理プログラムの動作環境のセットアップだけを行います。

注）“RMP”を設定してセットアップした環境では、OTSシステムを起動できません。

Interstage動作環境定義ファイルの“OTS Setup mode”に相当します。

- 305 -

“RMP”を設定する場合、リソース管理プログラムを正しく動作させるために、OTSシステムが動作するホストのネーミング

サービスを参照する必要があります。以下のどちらかの方法でセットアップを行ってください。

・ “RMP”を設定すると同時に、OTSシステムが動作しているホストの“HOST”／“PORT”／“LOCALE”を指定してセッ

トアップを行います。この場合、ネーミングサービスはOTSシステムではなく、“RMP”を設定したホストのネーミング

サービスが利用されます。“RMP”を設定したホストとOTSシステムが動作するホストのネーミングサービスをそれぞれ

独立させて運用させることが可能となります。

・ isinitコマンドに“type3”を指定してInterstageの初期化（NS Use／NS Host／NS Port Number／NSに、OTSシステム

が動作するホストのネーミングサービスを設定）を行った後、“RMP”を設定してotssetupコマンドでセットアップを行っ

てください。これにより、OTSシステムが動作するホストと“RMP”を設定したホストのネーミングサービスは、共有され

ます。

注意

・ “SYS”を設定したホスト同士のネーミングサービスを共有することはできません。必ず1つのネーミングサービスには

1つの“SYS”を設定したホストになるようにしてください。“RMP”を設定する場合は、複数のホストでネーミングサービ

スを共有できます。

・ “RMP”を設定した場合、otsstartコマンドではOTSシステムを起動できません。otsstartrscコマンドでリソース管理プロ

グラムの起動だけを行うことができます。

C.2.2 LOGFILE: システムログファイルのパス

OTSシステムのシステムログファイルを指定します。

OTSシステムのシステムログファイルへのパス（ドライブ名を含む絶対パス）を、制御文字（ShiftJISコードの0x00～0x1F,0x7F）を除く文字列で指定します。半角英文字の大文字と小文字、全角英文字の大文字と小文字は区別されませ

ん。

OTSシステムのシステムログファイルと使用するローデバイスまたはファイル名を、スラッシュ(/)で始まる空白文字と半

角カナを除く文字列で指定します。

“MODE”に“SYS”を設定した場合に有効となります。

大長は、255文字です。

Interstage動作環境定義ファイルの“OTS path for system log”に相当します。

ポイント

ローデバイスの作成手順を以下に示します。

1. オペレーティングシステムのpartedコマンド／fdiskコマンドで、ローデバイスのパーティションを作成します。

2. ディスクのパーティションに対応するudevのブロックデバイス名を特定します。

partedコマンドを使用した場合の例を以下に示します（#：プロンプト）。

[RHEL5の場合]

# parted /dev/sda

(parted) p

:

番号開始終了サイズタイプファイルシステムフラグ

1 32.3kB 107MB 107MB プライマリ ext3 boot

2 107MB 9656MB 9550MB プライマリ lvm

3 9656MB 10.7GB 1078MB プライマリ lvm

- 306 -

(parted) q

# udevinfo -q path -n /dev/sda3

/block/sda/sda3

# udevinfo -q env -p /block/sda/sda3 | grep ID_PATH

ID_PATH=pci-0000:00:10.0-scsi-0:0:0:0

[RHEL6の場合]

# parted /dev/sda

(parted) p

:

番号開始終了サイズタイプファイルシステムフラグ

1 1049kB 211MB 210MB primary ext4 boot

2 211MB 32.4GB 32.2GB primary ext4

:

8 77.5GB 78.5GB 974MB logical

(parted) q

# udevadm info --query=path --name=/dev/sda8

/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda8

# udevadm info --query=property --path=/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/

block/sda/sda8 | grep ID_PATH

ID_PATH=pci-0000:00:1f.2-scsi-0:0:0:0

3. udevの設定ファイル（/etc/udev/rules.d/60-raw.rules）を編集し、作成したパーティションをバインドします。

[RHEL5の場合]

ACTION=="add", KERNEL=="sda3", ENV{ID_PATH}=="pci-0000:00:10.0-scsi-0:0:0:0", RUN+="/bin/raw /dev/raw/

raw1 %N"

[RHEL6の場合]

ACTION=="add", KERNEL=="sda8", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", RUN+="/bin/raw /dev/raw/

raw1 %N"

4. udevによりローデバイスのアクセス権限が正しく設定されるように、/etc/udev/rules.d/配下の追加パーミッションルー

ルファイルを必要に応じて編集します。

注意

・ローデバイスをバインドするブロックデバイスは、パーティションを指定してください。パーティション番号のないハー

ドディスクデバイス（/dev/sdgなど）は、ディスクラベル（パーティションテーブル）を含んでいるため、ローデバイスとし

て使用しないでください。

・セットアップ情報ファイルのログファイルの指定には、必ずキャラクタデバイスにバインドしたデバイス名を指定してく

ださい。

C.2.3 TRANMAX: 最大トランザクション多重度

トランザクションの大数を指定します。必ず指定する必要があります。

また、MODEに“RMP”を設定した場合は、連携するOTSシステム（MODEに“SYS”を設定しているシステム）と同じ値を

設定してください。

設定可能な範囲は、1～256です。

- 307 -


Interstage動作環境定義ファイルの“OTS maximum Transaction”に相当します。

C.2.4 PARTICIPATE: 1トランザクションに参加するリソース数

1トランザクションに参加するリソースの大数を指定します。

MODEに“SYS”を設定した場合に有効となります。

設定可能な範囲は、2～32です。省略値は、4です。

Interstage動作環境定義ファイルの“OTS Participate”に相当します。

C.2.5 OTS_FACT_THR_CONC: OTSシステムのスレッド多重度

OTSシステムのスレッド多重数を指定します。指定した数だけ、begin/commit/rollbackなどのCurrentインタフェース、およ

びUserTransactionインタフェースを同時に動作させることが可能となります。



Interstage動作環境定義ファイルの“OTS Multiple degree”に相当します。

大値を超えた場合は、警告メッセージ“ots9013”が出力され、自動的に31が設定されます。

ポイント

OTSシステムのスレッド多重度は、トランザクション処理性能を大限に引き出すようにチューニングされているため、省

略値から変更する必要はありません。

変更する場合は、以下の関係を保つように設定してください。

OTSシステムのスレッド多重度＝＜リソース管理プログラムの多重度(注)

OTSシステムのスレッド多重度＝＜ 1リソース管理プログラムのトランザクションの最大多重度

注）JTS用リソース管理プログラムにおける多重度は、以下の算出式で見積もってください。

JTS用のリソース管理プログラムのプロセス多重度（JTS_RMP_PROC_CONC） ×

JTS用のリソース管理プログラムのスレッド多重度（JTS_RMP_THR_CONC）

C.2.6 OTS_RECV_THR_CONC: リカバリプロセスのスレッド多重度

リカバリプログラムのスレッド多重数を指定します。指定した数だけ、リカバリ処理を同時に動作させることが可能となります。



Interstage動作環境定義ファイルの“OTS Recovery”に相当します。

C.2.7 JTS_RMP_PROC_CONC: JTS用のリソース管理プログラムのプロセス多重度

JTS用のリソース管理プログラムのプロセス多重度を指定します。使用するリソース（データベース、リソースアダプタなど）

の数だけ指定することを推奨します。

設定可能な範囲は、1～32です。省略値は、2です。5以下の場合、変更する必要はありません。

Interstage動作環境定義ファイルの“OTS JTS's RMP Multiple degree of Process”に相当します。

大値を超えた場合は、警告メッセージ“ots9017”が出力され、自動的に32が設定されます。

- 308 -

ポイント

リソース管理プログラムの多重度は、トランザクション処理性能を大限に引き出すようにチューニングされているため、

省略値から変更する必要はありません。

変更する場合は、OTSシステムのスレッド多重度とリソース管理プログラムの多重度の関係を以下のように設定してくださ

い。



JTS用のリソース管理プログラムのプロセス多重度（JTS_RMP_PROC_CONC） ×

JTS用のリソース管理プログラムのスレッド多重度（JTS_RMP_THR_CONC）

C.2.8 JTS_RMP_THR_CONC: JTS用のリソース管理プログラムのスレッド多重度

JTS用のリソース管理プログラムのスレッド多重度を指定します。

設定可能な値は、1～2147483647です。省略値は、16です。

通常、変更する必要はありません。

Interstage動作環境定義ファイルの“OTS JTS's RMP Multiple degree of Thread”に相当します。

ポイント

リソース管理プログラムの多重度は、トランザクション処理性能を大限に引き出すようにチューニングされているため、

省略値から変更する必要はありません。

変更する場合は、OTSシステムのスレッド多重度とリソース管理プログラムの多重度の関係を以下のように設定してくださ

い。



JTS用のリソース管理プログラムのプロセス多重度:JTS_RMP_PROC_CONC ×

JTS用のリソース管理プログラムのスレッド多重度:JTS_RMP_THR_CONC

C.2.9 HOST: OTSシステムが動作するホスト名

OTSシステムが利用するネーミングサービスのホスト名を、英数字、マイナス記号(-)、またはピリオド(.)から構成される64文字以内の英字から始まる文字列で指定します。後の文字には、マイナス記号(-)、またはピリオド(.)を記述できません。

MODEに“RMP”を設定した場合に有効となります。

本ステートメントは、省略可能です。設定する場合は、PORTを同時に設定する必要があります。

本ステートメントの利用方法については、MODEを参照してください。

Interstage動作環境定義ファイルの“OTS Host”に相当します。

注意

“isinit”コマンドで“type3”を選択している場合は、使用しないでください。

C.2.10 PORT: OTSシステムが動作するホストのCORBAサービスのポート番号

OTSシステムが利用するネーミングサービスのポート番号を指定します。

MODEに“RMP”を設定した場合に有効となります。


- 309 -

本ステートメントは、省略可能です。設定する場合は、HOSTを同時に設定する必要があります。

本ステートメントの利用方法については、MODEを参照してください。

Interstage動作環境定義ファイルの“OTS Port”に相当します。

注意

isinitコマンドに“type3”を指定してInterstageを初期化した場合は、使用しないでください。

C.3 RMPプロパティ

■概要

JTS用リソース管理プログラムに対するプロパティファイルです。

RMPプロパティは、Javaのプロパティリストの形式で、その他のキーを設定することもできます。設定されたキーと値は、

JTS用リソース管理プログラムが動作するJavaVMのシステムプロパティに反映されます。

■ファイル名

RMPプロパティファイルは、インストール時に、以下に格納されます。

C:\Interstage\ots\etc\RMP.properties

/opt/FSUNots/etc/RMP.properties

/opt/FJSVots/etc/RMP.properties

注意

本製品のインストールパスがデフォルトの場合のパスです。


◆形式:

パラメタ名=設定値

◆パラメタ

RecoveryTarget: リカバリ対象

JTS用のリソース管理プログラムの起動時にリカバリを行う対象をリソース定義名で指定します。リカバリ対象が設定され

ていない場合、リカバリ対象が複数の場合は、空白で区切って指定してください。

ポイント

RecoveryTargetを省略した場合でも、登録済みリソースに対してリカバリ処理を行います。

- 310 -

例

リカバリ対象が3つの場合

RecoveryTarget=Oracle_resource1 Oracle_resource2 Oracle_resource3

JavaPath: Javaコマンドへのパス

必要な場合に、記述を追加します。通常、指定しないでください。指定した場合、動作の保証はできません。

JavaCommandOption: Javaコマンドに受け渡すオプション


Classpath: 追加するクラスパス


クラスタサービス機能利用時に、リソースと連携するために必要となるクラスライブラリへのパスを設定します。クラスラ

イブラリの詳細については、“アプリケーション作成ガイド(データベース連携サービス編)”の“リソース管理プログラム

の作成から起動まで”を参照してください。

Librarypath:追加するライブラリパス

リソースと連携するために必要となるライブラリへのパスを指定します。

JTS用のリソース管理プログラムの環境変数PATHに追加されます。

JTS用のリソース管理プログラムの環境変数LD_LIBRARY_PATHに追加されます。

Environ:追加する環境変数

リソースと連携するために必要となる環境変数を指定します。

例

環境変数ORACLE_HOMEを指定する場合

Environ ORACLE_HOME=C:\app\user\product\11.2.0\db

Environ ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome

C.4 リソース定義ファイル

- 311 -

■概要

OTS／JTSが連携するリソース（データベース、リソースアダプタなど）に接続するための情報を定義するファイルです。

otssetrscコマンドを利用して、リソース単位に登録します。


◆形式:

キー名=設定値

◆設定例

OTS用リソース定義ファイル

# 環境変数

ENVIRON ORACLE_SID=orac

ENVIRON ORACLE_HOME=/opt/oracle.............(Solaris/Linuxの場合)

ENVIRON LD_LIBRARY_PATH=/opt/oracle/lib.....(Solaris/Linuxの場合)

# 使用するデータベースシステム名とOPENINFO文字列、CLOSEINFO文字列

NAME=oracle_rmp_thread

RMNAME=Oracle_XA

OPENINFO=Oracle_XA+Acc=P/system/manager+SesTm=0+Threads=true

CLOSEINFO=

THREADS=TRUE................................(Solaris/Linuxの場合)

JTS用リソース定義ファイル

# database1

name=xads1

rscType=JTS

type=JDBC

lookUpName=jdbc/XADataSource

initialContextFactory=com.sun.jndi.fscontext.RefFSContextFactory

providerURL=file:/tmp/JNDI

user=dbuser

password=dbpass

logfileDir=c:\interstage\ots\var............(Windows(R)の場合)

logfileDir=/opt/FSUNots/var.................(Solarisの場合)

logfileDir=/opt/FJSVots/var.................(Linuxの場合)

注意

キーの名前は、OTSおよびJTSで大文字／小文字が異なりますが、同じ意味を持ちます。

◆キー一覧

キー(OTS) キー(JTS) 意味

ENVIRON －環境変数の設定

NAME name リソース定義名

RMNAME －リソースマネージャ名

OPENINFO －オープン文字列

- 312 -

キー(OTS) キー(JTS) 意味

CLOSEINFO －クローズ文字列

THREADS －スレッドモード

OTS_RMP_PROC_CONC

－ OTS用のリソース管理プログラムの多重度

RSCTYPE rscType リソース定義ファイルの種類

－ type リソースの種類

－ lookupName リソースの検索名

－ initialContextFactory initialContextFactory名

－ providerURL プロバイダURL

USER －ユーザ名

－ user ユーザ名

－ password パスワード

GROUP －グループ名

－ logfileDir リソースのログファイル格納ディレクトリ

◆キー詳細

ENVIRON: 環境変数の設定(OTS)

値dataに、リソース管理プログラム、またはリソース管理プログラムと同じプロセス内で動作するデータベースライブラリ

に渡す環境変数envを指定します。省略可。

リソース管理プログラムを使用するサーバアプリケーションの起動時に指定するデータベースへの環境変数と同一の

環境変数を指定してください。

また、リソース定義ファイルには、以下のような$指定できません。

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/oracle/lib

使用するデータベースがSymfoware/RDBの場合は、環境変数LD_LIBRARY_PATHにSymfoware/RDBの必須製

品であるライブラリのパス名を指定してください。

NAME、name: リソース定義名(OTS、JTS)

otssetrscコマンドでの登録時に、本パラメタに指定したリソース定義名で登録します。1度登録されたリソース定義ファ

イルは、すべてリソース定義名で扱うことができます。リソース定義名は、32文字以内で指定します。省略不可。

“JTSRMP”は予約語であるため、リソース定義名として使用できません（一部またはすべてを小文字にしても使用で

きません）。

JTS用リソース定義ファイルでは、isj2eeadminコマンドで登録するJ2EEリソース定義の接続対象となるリソースの“定義

名”を指定してください。詳細については、“リファレンスマニュアル（コマンド編）”の“isj2eeadmin”を参照してくださ

い。

RMNAME: リソースマネージャ名(OTS)

system_nameに、データベースのシステム名を以下から選択して指定します。

－ Oracleの場合：“Oracle_XA”

－ Symfoware/RDBの場合：“RDBII”

－SQL Serverの場合：“MS_SQL_Server”

- 313 -

－ MQDの場合：“XA_MQD”

OPENINFO: オープン文字列(OTS)

open_dataに、データベースのベンダが公開する、データベースをオープンする場合に必要なopen文字列を、256文

字以内の文字列で指定します。

指定する内容については、各データベースのマニュアルを参照してください。

注意

－ OPENINFOに指定するユーザ名は、各データベースに対するアクセス権限がないと、リソース管理プログラムの

起動に失敗します。必要な権限については、各データベースのマニュアルを参照してください。

－プロセスモード／スレッドモードのタイプが、リソース管理プログラム作成時と動作時（リソース定義ファイル内のス

レッド指定）とで異なる場合、リソース管理プログラムの起動が誤動作する可能性があります。必ずタイプをあわせ

て運用してください。

CLOSEINFO: クローズ文字列(OTS)

close_dataに、データベースのベンダが公開する、データベースをクローズする場合に必要なclose文字列を、256文

字以内の文字列で指定します。

指定する内容については、各データベースのマニュアルを参照してください。

THREADS: スレッドモード(OTS)

リソース管理プログラムのモードを以下から選択して指定します。

－プロセスモードの場合：“FALSE”（省略時）

－スレッドモードの場合：“TRUE”

OTS_RMP_PROC_CONC: OTS用のリソース管理プログラムの多重度(OTS)

OTS用のリソース管理プログラムの多重数を指定します。通常、変更する必要はありません。


大値を超えた場合は、警告メッセージ“ots9017”を出力し、31を自動的に設定します。

注意

リソース管理プログラムの多重度は、トランザクション処理性能を大限に引き出すようにチューニングされているた

め、省略値から変更する必要はありません。

変更する場合は、OTSシステムのスレッド多重度とリソース管理プログラムの多重度の関係を以下のように設定してく

ださい。

OTSシステムのスレッド多重度＝＜リソース管理プログラムの多重度

RSCTYPE、rscType: リソース定義ファイルの種類(OTS、JTS)

リソース定義ファイルの種別を以下から選択して指定します。

－ OTSを利用する場合：“OTS”（省略時）

- 314 -

－ JTSを利用する場合：“JTS”

注）JTSを利用する場合は、必ず“JTS”を指定してください。

type: リソースの種類(JTS)

リソースの種類を以下から選択して指定します。省略不可。

－ JDBCを利用してデータベースと接続する場合：“JDBC”／“DBMS”(旧バージョンでの指定方法)

－ J2EE Connector Architectureを利用してリソースアダプタと接続する場合は、“JCA”

lookupName: リソースの検索名(JTS)

JDBCを利用してデータベースと接続する場合は、データベースが提供するデータソースをバインドした名前を指定

します。isj2eeadminコマンドで登録するJ2EEリソース定義で設定したデータソース名と同じ値を指定してください。

J2EE Connector Architectureを利用してリソースアダプタと接続する場合は、リソースアダプタの配備時に設定した“リ

ソース名”を指定してください。

initialContextFactory: initialContextFactory名(JTS)

バインドされたデータソース参照時に使用するinitialContextFactoruy名を指定します。isj2eeadminコマンドで登録す

るJ2EEリソース定義で設定したクラス名と同じ値を指定してください。JDBCを利用してデータベースと接続する場合

は、必ず指定してください。

providerURL: プロバイダURL(JTS)

バインドされたデータソース参照時に使用するprovider URLを指定します。isj2eeadminコマンドで登録するJ2EEリソー

ス定義で設定したクラス名と同じ値を指定してください。

USER: ユーザ名(OTS)

リソース管理プログラムの実行ユーザを指定します。otssetrscコマンド実行時に、-uオプションを指定した場合は、オ

プションに指定されたユーザ名が有効となります。

“GROUP”と同時に指定する必要があります。

指定したユーザは、“GROUP”に指定するグループに所属している必要があります。

強化セキュリティモードの場合は、強化セキュリティモード設定時に指定したグループに所属している必要がありま

す。

user: ユーザ名(JTS)

リソースとの接続時にユーザ名が必要な場合に指定します。isj2eeadminコマンドで登録するJ2EEリソース定義によっ

て設定したユーザ名を指定してください。

password: パスワード(JTS)

リソースとの接続時にパスワードが必要な場合に指定します。isj2eeadminコマンドで登録するJ2EEリソース定義によっ

て設定したユーザのパスワードを指定してください。

GROUP: グループ名(OTS)

リソース管理プログラムの実行ユーザを指定します。otssetrscコマンド実行時に、-gオプションを指定した場合は、オ

プションに指定されたグループ名が有効となります。

“USER”と同時に指定する必要があります。

強化セキュリティモードの場合、本設定は無効となり、強化セキュリティモード設定時に指定したグループ名が有効と

なります。

- 315 -

logfileDir: リソースのログファイル格納ディレクトリ(JTS)

接続したリソースのトラブルを調査する場合は、トレースログを採取するディレクトリを指定してください。ディレクトリ名

の後に、セパレータを付加しないでください。

通常、指定しません。

C.5 OTSシステム用業務システム情報定義ファイル

■概要

トランザクションサービスがSystemwalker Resource Coordinatorと連携して動的ダウンリカバリを実現するためのOTSシス

テム用業務システム情報定義ファイルです。


◆形式:

キー名=設定値

◆パラメタ

factory_quemode: トランザクション処理閉塞の動作(OTS、JTS)

トランザクションサービスのトランザクション処理閉塞の動作を、以下から選択して指定します。

－トランザクション開始処理を受け付けず、トランザクション開始要求をエラーとする場合：“que”

－トランザクション開始処理を受け付け、トランザクション処理を待ち状態とする場合：“dsp”

C.6 アプリケーション用業務システム情報定義ファイル

■概要

トランザクションサービスがSystemwalker Resource Coordinatorと連携して動的ダウンリカバリを実現するためのアプリケー

ション用業務システム情報定義ファイルです。


◆形式:

キー名=設定値

◆パラメタ

resource: リソース管理プログラムの情報(OTS)

対象となる業務で使用しているリソース管理プログラムのフルパスとリソース定義名を、カンマ(,)で区切って指定しま

す。

注意

－リソース管理プログラムのフルパスは、必ずダブルクォーテーション("")で囲んでください。

－複数指定する場合は、複数行で指定してください。

- 316 -

workUnit: ワークユニットの情報(OTS、JTS)

対象となる業務のワークユニット名を指定します。

ポイント

複数指定する場合は、カンマ(,)で区切ります。複数行で指定することもできます。

- 317 -

付録D イベントサービスの環境定義

イベントサービスの動作環境ファイル、およびイベントチャネル・サプライヤ・コンシューマ総数の見積もり方法について

説明します。

イベントサービスの動作環境ファイルは、以下に格納されます。

格納パス


C:\Interstage\eswin\etc


/etc/opt/FJSVes

/etc/opt/FJSVes

ファイル

traceconfig

注意

上記以外のファイルは、イベントサービスの動作環境としてカスタマイズできません。エディタなどで編集しないでくださ

い。

D.1 traceconfig

■概要

traceconfigファイルは、イベントサービスのトレース動作環境に関する定義が格納されたファイルです。

■ファイル名


C:\Interstage\eswin\etc\traceconfig


/etc/opt/FJSVes/traceconfig

/etc/opt/FJSVes/traceconfig


traceconfigファイルは、以下の形式で値を設定します。

- 318 -

◆形式:


◆パラメタ:

以下の動作環境について、パラメタ設定値を変更することができます。

注意

パラメタ値を変更した場合、次回のイベントサービス起動時より有効となります。


省略値

指定範囲

trace_size 1024 トレース情報の採取に使用するバッファのサイズをキロバイ

ト単位で指定します。 (注1)512

512～102400

trace_file_number

50

10

採取するトレース情報ファイルの大数を指定します。トレー

ス情報ファイルの数が指定値を超えた場合は、古いトレー

ス情報ファイルに上書きします。

50

10

50～1000

10～1000

trace_auto yes トレース情報の自動採取を有効にするかを指定します。

・ yes: トレース情報の自動採取を有効とする。 (注2)

・ no : トレース情報の自動採取を無効とする。

yes

yes, no

trace_buffer

process 内部トレースを採取する単位を指定します。

・ process: プロセス単位で内部トレースを採取する。

・ system: イベントサービス単位で内部トレースを採取す

る。

process

process, system

注1)

トレース情報の出力サイズはチャネル数、コンシューマ数、サプライヤ数、および通信頻度によって異なります。起動処

理系、通信処理系、および停止処理系で使用するトレース情報のバッファサイズを以下に記載します。

- 319 -

プロセス単位で内部トレースを採取する(trace_buffer = process)場合、トレース情報の出力サイズはチャネル数、コン

シューマ数、サプライヤ数、および通信頻度によって異なります。起動処理系、通信処理系、および停止処理系で使用

するトレース情報のバッファサイズを以下に記載します。

なお、イベントサービス単位で内部トレースを採取する(trace_buffer = system)場合は、起動処理系、通信処理系、およ

び停止処理系で使用するトレース情報を1つのバッファに格納されるため、それぞれを加算してください。

・起動処理系

イベントチャネル起動: 3.2KB サプライヤ起動処理(pushメソッドを出すまで): 1.0KB コンシューマ起動処理(pullメソッドを出すまで): 1.0KB

・通信処理系

pushメソッド: 0.8KB pullメソッド(受信成功): 1.2KB pullメソッド(COMM_FAILURE[minor=0x464a09c1]): 1.0KB

・停止処理系

イベントチャネル停止: 3.4KB サプライヤdisconnect処理: 0.5KB コンシューマdisconnect処理: 0.8KB

トレース情報バッファサイズを初期設定で運用した場合の計算例を以下に示します。

例

1チャネルで、コンシューマ数:サプライヤ数が1:1の場合

1回の通信(push/pull)で2.0KB(0.8KB＋1.2KB)のバッファサイズが必要となります。

トレース情報バッファは、バッファを半分ずつサイクリックに使用するため、トレース情報バッファ(サイズ:1024KB)に格納

できる通信のトレース情報数は256回となります。

(トレース情報バッファサイズ ÷ 2) ÷ 1回の通信に必要なバッファサイズ＝ (1024KB ÷ 2) ÷ 2.0KB ＝ 256回

40秒に1回の通信を行うと仮定した場合、約2.8時間の通信をロギングできることになります。

256 × 40秒＝ 10240秒＝約2.8時間

上記の例では、トレース情報を自動採取する事象が発生するまでの約2.8時間分のトレース情報を採取することができ

ます。

トレース情報バッファサイズは、少なくとも5分以上のトレース情報が採取可能なサイズを指定してください。

トレース情報バッファサイズを初期値から変更した場合、その増分だけ共用メモリ使用量が増加します(キロバイト単位)。

注2) トレース情報の自動採取を有効とする(trace_auto = yes)場合、トレースファイルは以下のファイル名で出力されます。

(XXX:3桁の10進数の数値)

C:\Interstage\eswin\var\ESLOGXXX

/var/opt/FJSVes/ESLOGXXX

プロセス単位で内部トレースを採取する(trace_buffer = process)場合

- 320 -

・イベントサービスのデーモンプロセスのログ情報

/var/opt/FJSVes/ESLOGDUMPDAEMONXXX

・イベントファクトリプロセスのログ情報

/var/opt/FJSVes/ESLOGDUMPFACTORYXXX

・静的イベントチャネルプロセスのログ情報

/var/opt/FJSVes/ESLOGDUMPグループ名XXX

・動的イベントチャネルプロセスのログ情報

/var/opt/FJSVes/ESLOGDUMPインプリメンテーション名XXX

イベントサービス単位で内部トレースを採取する(trace_buffer = system)場合

/var/opt/FJSVes/ESLOGXXX

D.2 サプライヤ・コンシューマ総数の見積もり方法

不揮発チャネル運用時、同じユニットを使用するイベントチャネルに接続するサプライヤ・コンシューマの総数は、以下の

見積もり式を参考にして見積もってください。

イベントチャネルの最大接続数の合計値(注) ＋ 10 ＜ユニット定義ファイルのtranmax値

注）

同じユニットを使用するすべてのイベントチャネルについて、イベントチャネルごとに以下の値を求めて、その合計値

を算出してください。

イベントチャネルの最大接続数 (esmkchnlコマンドの-mオプションの指定値(省略値：16)) × 2

イベントチャネルの最大接続数 (esmkchnlコマンドの-mオプションの指定値(省略値：16)) ＋ 16

- 321 -

付録E Interstage HTTP Serverの環境定義

Interstage HTTP Serverの運用状態をチューニングするには、Interstage管理コンソールを使用して設定する方法と、

Interstage HTTP Serverの環境定義ファイル(httpd.conf)を使用して設定する方法があります。

Interstage管理コンソールを使用して設定する場合、以下の手順で環境設定を行います。Interstage管理コンソールの起

動については“運用ガイド（基本編）”の“Interstage管理コンソールによるInterstage運用”を、Interstage管理コンソールの

定義詳細についてはInterstage管理コンソールのヘルプを参照してください。

・ Interstage管理コンソールのスタンドアロンサーバで環境設定を行う場合

1. スタンドアロンサーバのInterstage管理コンソールにログインします。

2. [システム] > [サービス] > [Webサーバ] > [Webサーバ名] > [環境設定]タブ > [Webサーバ:環境設定](詳細

設定[表示])画面を使用して環境設定を行います。

・ Interstage管理コンソールの管理サーバで環境設定を行う場合

1. 管理サーバのInterstage管理コンソールにログインします。

2. [一括操作] > [Interstage管理コンソール] > [Interstage Application Server] > [サービス] > [Webサーバ] >[FJapache(サーバグループ名またはサーバ名)] > [環境設定]タブ > [Webサーバ:環境設定](詳細設定[表示])画面を使用して環境設定を行います。

ここでは、環境定義ファイル(httpd.conf)の定義方法について説明します。

なお、Interstage HTTP Serverの環境定義ファイルは、以下に格納されています。


C:\Interstage\F3FMihs\servers\(Webサーバ名)\conf\httpd.conf


/var/opt/FJSVihs/servers/(Webサーバ名)/conf/httpd.conf

/var/opt/FJSVihs/servers/(Webサーバ名)/conf/httpd.conf

E.1 タイムアウト時間

■タイムアウト時間の設定

タイムアウト時間を設定する場合、環境定義ファイル(httpd.conf)の以下のディレクティブを編集します。

Timeout クライアント送受信タイムアウト時間(秒)

クライアントとの間でデータパケットを送受信するときに待機する長の時間(秒)を指定します。待機時間には、0から

65535までを指定できます。

Interstage HTTP Serverは、指定された時間に達してもパケットを受信できない場合、TCPコネクションが切断されます。

接続しているネットワークのトラフィックが増大し、TCPコネクションの接続が頻繁に中断される場合は、待機時間を増や

すことにより中断回数を減少させることができます。

クライアント送受信タイムアウト時間の初期値は“600”、省略値は“300”です。

- 322 -

ポイント

クライアントからTCPコネクションが接続されたあとにリクエストが届かない場合は、指定した時間（秒）に達すると、TCPコ

ネクションが切断されます。

SSLHandshakeTimeout SSLコネクション確立時の送受信タイムアウト時間(秒)

SSLコネクションの確立処理でクライアントからのデータパケットを送受信するときに待機する長の時間(秒)を設定しま

す。待機時間には、0から65535までを指定できます（0を指定した場合、無制限）。

Interstage HTTP Serverは、指定された時間に達してもパケットを受信できない場合は、TCPコネクションが切断されます。

通常、SSLコネクションの確立処理にかかる時間をチューニングしたい場合に設定します。

SSLコネクション確立時の送受信タイムアウト時間の初期値は、ありません。省略値は、Timeoutディレクティブの設定値

です。

■HTTP Keep-Alive機能の設定

HTTP Keep-Alive機能を設定する場合、環境定義ファイル(httpd.conf)の以下のディレクティブを編集します。

KeepAlive On|Off

Interstage HTTP Serverでは、クライアント(Webブラウザ)との間で持続的な接続を維持できます。

“Off”を指定した場合は、1つの要求が完了するたびに接続を閉じて、次の要求に対して新しく接続しますが、“On”を指

定することにより複数の要求を同じ接続で繰り返し使えるため、クライアントのレスポンスが向上します。

初期値・省略値は、“On”です。

KeepAliveTimeout 次のリクエストまでのタイムアウト時間(秒)

クライアントの1つのリクエストが完了してから、コネクションを閉じずに次の新しいリクエストを待つ時間(秒)を指定します

(“KeepAlive On”の場合のみ有効)。接続維持時間には、0から65535までを指定できます。この時間を経過しても次のリ

クエストがない場合は、接続を閉じます。

接続維持時間の初期値・省略値は、“15”です。

■タイムアウト時間の構成図

タイムアウト時間(TimeoutおよびKeepAliveTimeout)の構成図を以下に示します。

- 323 -

T1:Timeout(初期値 600秒)

クライアントとの間でデータパケットを送受信するときに待機する長の時間(秒)。注) POSTまたはPUTリクエストにおいて、データを分割して複数回送受信される場合は、個々のデータの送受信時

にかかる長の時間となります。

T2:KeepAliveTimeout(初期値 15秒)

クライアントの1つのリクエストが完了してから、コネクションを閉じずに次の新しいリクエストを待つ時間(秒)。

E.2 クライアントの同時接続数

クライアントの同時接続数を設定する場合、環境定義ファイル(httpd.conf)の以下のディレクティブを編集します。

クライアントの同時接続数の構成図については、“Interstage HTTP Server 運用ガイド”の“Webサーバのプロセス構成”を


ThreadsPerChild クライアントの同時接続数

Interstage HTTP Serverが、クライアント(Webブラウザ)からの接続要求を同時に受け付けることができる大数を指定し

ます。大数には、1からThreadLimitディレクティブに指定した値までを指定できます。

本値を大きくすることにより同時アクセス可能な数は多くなりますが、メモリ資源や一時ファイルなどの消費に伴いシステ

ム全体の性能が劣化する可能性があります。

同時アクセス大数の初期値は“50”、省略値は“64”です。

ThreadLimit 通信スレッドの上限数

ThreadsPerChildディレクティブに設定するクライアント数の上限値を設定します。1から15000までを指定できます。1より

小さな値を指定した場合は、1で動作します。15000より大きな値を指定した場合は、15000で動作します。

本ディレクティブは、ThreadsPerChildディレクティブに1920よりも大きな値に設定する必要がある場合にだけ使用してくだ

さい。

通信スレッドの上限数の初期値は、ありません。省略値は“1920”です。

MaxClients クライアントの同時接続数

Interstage HTTP Serverが、クライアント(Webブラウザ)からの接続要求を同時に受け付けることができる大数を指定し

ます。大数には、1からServerLimitディレクティブで指定した値までを指定できます。1より小さな値を指定した場合は、

1で動作します。ServerLimitディレクティブで指定した値より大きな値を指定した場合は、ServerLimitディレクティブで指

定した値で動作します。

- 324 -

本値を大きくすることにより同時アクセス可能な数は多くなりますが、メモリ資源や一時ファイルなどの消費に伴いシステ

ム全体の性能が劣化する可能性があります。

クライアントの同時接続数の初期値は“50”、省略値は“256”です。

なお、この設定値を超過するクライアントの接続要求があった場合は、リクエスト処理待ちキューに保存されます。リクエ

スト処理待ちキュー数は、ListenBacklogディレクティブで設定します。

ServerLimit 通信プロセスの上限数

MaxClientsディレクティブに設定するクライアントの同時接続数の上限値を設定します。1から20000までを指定できます。

1より小さな値を指定した場合は、1で動作します。20000より大きな値を指定した場合は、20000で動作します。

本ディレクティブは、MaxClientsディレクティブに256よりも大きな値に設定する必要がある場合にだけ使用してください。

通信プロセスの上限数の初期値は、ありません。省略値は“256”です。

ListenBacklog リクエスト処理待ちキューの最大数

ThreadsPerChildディレクティブで設定したクライアントの同時接続数よりも多くの接続要求があった場合に、本ディレクティ

ブの設定値がオペレーティングシステム内にキューイングされる数の大値となります。大数には、1から200までを指

定できます。

リクエスト処理待ちキューの大数の省略値は、“200”です。

ListenBacklog リクエスト処理待ちキューの最大数

MaxClientsディレクティブで設定したクライアントの同時接続数よりも多くの接続要求があった場合に、以下の条件に応

じた値がオペレーティングシステム内にキューイングされる数の大値となります。大数には、1から2147483647までを

指定できます。

リクエスト処理待ちキューの大数の省略値は、“511”です。

条件リクエスト処理待ちキューの最大数

本ディレクティブの設定値 ≦ 待機中TCPコネクションの大値

(注)本ディレクティブの設定値

本ディレクティブの設定値＞待機中TCPコネクションの大値

(注)待機中TCPコネクションの大値 (注)

注）待機中TCPコネクションの大値は、オペレーティングシステムに設定されています。以下のコマンドを実行して確認

してください。待機中TCPコネクションの設定およびコマンドの詳細については、オペレーティングシステムのドキュメント


待機中TCPコネクションの最大値コマンド実行例

tcp_conn_req_max_q /usr/sbin/ndd /dev/tcp tcp_conn_req_max_q

/proc/sys/net/core/somaxconn /sbin/sysctl -n net.core.somaxconn

- 325 -

付録F Interstage シングル・サインオンの環境定義

Interstage シングル・サインオンを運用するための、環境定義のチューニングについて説明します。

F.1 1台のサーバにリポジトリサーバを構築する場合のチューニング

1台のサーバに、リポジトリサーバを構築する場合のチューニングについて説明します。

■Webサーバ(Interstage HTTP Server)のチューニング

リポジトリサーバのチューニングは、Webサーバ(Interstage HTTP Server)の環境定義を変更することにより行います。

詳細については、“付録E Interstage HTTP Serverの環境定義”を参照してください。

クライアントの同時接続数

以下のディレクティブに、想定する同時アクセス大数以上を設定します。(初期値:50)

ThreadsPerChild

MaxClients

クライアント送受信タイムアウト時間

Timeoutにクライアントとの間でデータパケットを送受信するときに待機する長の時間(秒)を指定します。(初期値:600)

◆チューニングの例

想定する同時アクセス大数が256ユーザのシステムの場合

Interstage HTTP Server ThreadsPerChild＝256＋α(注1) Timeout＝600(注2)

Interstage HTTP Server MaxClients＝256＋α(注1) Timeout＝600(注2)

注1) システムを安定稼動させるため、αには10～100までの値を設定してください。

注2) 接続しているネットワークのトラフィックが増大し、接続が頻繁に中断される場合には、本時間を増やしてくださ

い。

■TCP/IPパラメタのチューニング

セション管理の運用を行う場合は、リポジトリサーバ(更新系)のマシンのTCP/IPパラメタのチューニングを行います。(注)

詳細については、“3.4 TCP/IPパラメタのチューニング”を参照してください。

注) リポジトリサーバ(更新系)への同時アクセス大数が増大し、セション管理サーバとの通信に失敗し、以下のメッセー

ジが出力される場合があります。この場合には、TCP/IPパラメタのチューニングを行ってください。

・ sso00114

・ sso00119

- 326 -

F.2 1台のサーバに認証サーバを構築する場合のチューニング

1台のサーバに、認証サーバを構築する場合のチューニングについて説明します。


認証サーバのチューニングは、Webサーバ(Interstage HTTP Server)の環境定義を変更することにより行います。




ThreadsPerChild

MaxClients







想定する同時アクセス大数500ユーザを、5台の認証サーバにて負荷分散するシステムにおける認証サーバ1台あ

たりのチューニング





い。

- 327 -

F.3 1台のサーバにリポジトリサーバと認証サーバを構築する場合のチューニング

1台のサーバに、リポジトリサーバと認証サーバを構築する場合のチューニングについて説明します。


リポジトリサーバ、および認証サーバのチューニングは、Webサーバ(Interstage HTTP Server)の環境定義を変更するこ

とにより行います。



以下のディレクティブに、想定する同時アクセス大数×2以上を設定します。(初期値:50)

ThreadsPerChild

MaxClients





Interstage HTTP Server ThreadsPerChild＝256×2＋α(注1) Timeout＝600(注2)

Interstage HTTP Server MaxClients＝256×2＋α(注1) Timeout＝600(注2)



い。

■TCP/IPパラメタのチューニング

セション管理の運用を行う場合は、リポジトリサーバ(更新系)のマシンのTCP/IPパラメタのチューニングを行います。(注)

詳細については、“3.4 TCP/IPパラメタのチューニング”を参照してください。

注) リポジトリサーバ(更新系)への同時アクセス大数が増大し、セション管理サーバとの通信に失敗し、以下のメッセー

ジが出力される場合があります。この場合には、TCP/IPパラメタのチューニングを行ってください。

・ sso00114

・ sso00119

- 328 -

F.4 業務サーバを構築する場合のチューニング

業務サーバを構築する場合のチューニングについて説明します。

キャッシュサイズ、キャッシュ数、および使用するWebサーバのチューニングを行ってください。

■キャッシュサイズ、キャッシュ数のチューニング

セションの管理を行う運用の場合、認証した利用者の認証情報を業務サーバでキャッシュすることで認可性能を向上さ

せることができます。キャッシュを効果的に行うためにはシステムの同時利用者数、および利用者の認証情報サイズに応

じて、キャッシュサイズ、キャッシュ数を適切に設定する必要があります。

キャッシュサイズ、キャッシュ数の設定については、業務サーバのInterstage管理コンソールを使用して、[システム] > [セキュリティ] > [シングル・サインオン] > [業務システム] > [業務システム名] > [環境設定] > [詳細設定[表示]]をクリックし、

以下より行います。

・ [認証情報のキャッシュ]の[キャッシュサイズ]

・ [認証情報のキャッシュ]の[キャッシュ数]

キャッシュサイズ

認証情報のサイズを以下の計算式で見積り、Kバイト単位で設定します。

認証情報サイズ = (150 + DNの文字列長

+ ユーザIDの文字列長

+ 認証方式の文字列長

+ ロールサイズ(注1) + 拡張ユーザ情報サイズ(注2) ) × 1.4バイト

注1)設定するロール名の文字列長の総和 + 10×ロール数

注2)設定する属性名の文字列長の総和 + 属性値の文字列長の総和 + 10×拡張ユーザ情報数

キャッシュ数

認証情報のキャッシュは、利用者の終アクセス時からアイドル監視時間が経過するまで保持します。アイドル監視

時間内で想定する同時アクセス大数 + α(注)を設定してください。

注)1人の利用者が、アイドル監視時間内にサインオン、サインオフを繰り返した場合でも、キャッシュ数を消費するた

め、想定する同時アクセス大数よりも少し大きめの値を設定してください。

設定したキャッシュサイズ、キャッシュ数を超える利用があった場合も継続して利用可能ですが、システムのログに

sso03062、もしくはsso03063のメッセージが出力されます。

認可性能が低下する可能性があるため、メッセージに従い対処してください。


利用者の情報が以下の場合を例に説明します。

項目文

字

列

長

値

DN 55 cn=FujitsuTarou,ou=User,ou=interstage,o=fujitsu,dc=com

ユーザID 5 tarou

認証方式 19 basicAuthOrCertAuth

- 329 -

ロール名 5 Admin

ロール名 6 Leader

拡張ユーザ情報(属性

名)4 mail


値)20 [email protected]


名)14 employeeNumber


値)6 100001

ロールサイズ

2つのロールが設定されるため、以下のようになります。

(Admin(5文字) + Leader(6文字)) + 10×ロール数(2個) = 31

拡張ユーザ情報サイズ

2つの属性が設定されるため、以下のようになります。

(mail(4文字) + employeeNumber(14文字)) + ([email protected](20文字) + 100001(6文字)) + 10×拡張ユーザ情報

数(2個) = 64

上記より、認証情報サイズは以下のようになります。

認証情報サイズ = (150 + DNの文字列長(55文字) + ユーザIDの文字列長(5文字) + 認証方式の文字列長(19文字) + ロールサイズ(31文字) + 拡張ユーザ情報サイズ(64文字) ) × 1.4バイト

= 約454バイト

[キャッシュサイズ]には、上記認証情報サイズを切り上げ、1Kバイトを設定します。





ThreadsPerChild

MaxClients



■Microsoft(R) Internet Information Servicesのチューニング

Microsoft(R) Internet Information Servicesのチューニングについては、“Microsoft(R) Internet Information Services”の

プロパティ情報に以下の定義を設定することによりチューニングを行います。

最大接続数

大接続数フィールドに想定する同時アクセス数以上を設定します。(default:1,000)

- 330 -

付録G マルチサーバ管理の環境定義

マルチサーバ管理の環境定義ファイルのチューニングについて説明します。

G.1 マルチサーバ管理定義ファイル

■概要

マルチサーバ管理定義ファイルは、マルチサーバ管理の動作環境に関する定義が格納されたファイルです。

■ファイル名


C:\Interstage\jmx\etc\ssv.xml


/etc/opt/FJSVisjmx/ssv.xml

■ファイル形式

<ssv>をルートタグとするXML形式。

■タグ・属性一覧

タグ名:site

属性名内容デフォルト値値の範囲

server.limit サイトに所属する管理対象

サーバ数の上限

100 1～

INT_MAX (注)

servergroup.limit サイトに所属するサーバグ

ループ数の上限

100 1～

INT_MAX (注)

server.limit.inservergroup サーバグループに所属す

る管理対象サーバの上限

100 1～

INT_MAX (注)

注) マルチサーバ管理定義ファイルに記述された値が範囲内に納まっていない場合、デフォルト値で動作します。

タグ名:ijserver

属性名内容デフォルト値値の範囲

deploy.path 配備対象アーカイブファイ

ルの一時格納ディレクトリ C:\Interstage\jmx\var\ssv_ijs

/etc/opt/FJSVisjmx/var/ssv_ijs

－

- 331 -

付録H Portable-ORBの環境設定

Portable-ORBの動作環境ファイルは、porbeditenvコマンドを使用して設定します。Portable-ORBを使用する場合は、

porbeditenvコマンドを使用して以下の環境設定を行ってください。

・動作環境情報

・ホスト情報

・セキュリティ

・ネットワーク環境

porbeditenvコマンドの詳細については、“リファレンスマニュアル(コマンド編)”の“porbeditenv”を参照してください。

Portable-ORBの動作環境ファイルの詳細については、“アプリケーション作成ガイド(CORBAサービス編)”の“Portable-ORB動作環境ファイルの指定”を参照してください。

また、運用環境を構築した場合は、万が一に備えて、資源のバックアップを行うことを推奨します。資源のバックアップ

については、“運用ガイド（基本編）”の“メンテナンス(資源のバックアップ/他サーバへの資源移行/ホスト情報の変更)”を


- 332 -

付録I Webサーバ(Sun Java System Web Server)の環境定義

Webサーバ(Sun Java System Web Server)の環境定義については、「J2EE ユーザーズガイド(旧版互換)」を参照してくだ

さい。

- 333 -

索　引[数字]

1台のサーバに認証サーバを構築する場合のチューニング3271台のサーバにリポジトリサーバと認証サーバを構築する場合の

チューニング...........................................................................3281台のサーバにリポジトリサーバを構築する場合のチューニング

................................................................................................3261トランザクションに参加するリソース数.................................308

[C]CMS付きパラレルGC.............................................................195config......................................................................................264configファイル.........................................................................300CORBAサービスのシステム環境の設定................................57CORBAサービスのシステム資源............................................57CORBAサービスの動作環境ファイル...................................263CORBAワークユニットのチューニング..................................105

[E]EJBコンテナのチューニング..................................................122Enterprise Beanインスタンスのキャッシング...........................125Enterprise Beanインスタンスのプーリング..............................127EXTP4435メッセージまたはISJEE_OM1018メッセージが出力さ

れた場合.................................................................................251

[F]FJVMログ...............................................................................237FJVM......................................................................................182FJVMでサポートされるガーベジコレクション処理................189FJVMに対して指定可能なチューニング用オプション.........187

[G]gwconfig.................................................................................282

[H]HOST......................................................................................309

[I]IIOP_port................................................................................265IJServerクラスタのチューニング.............................................111IJServerまたはEJBサービスのシステム資源の設定...............78IJServerワークユニットのチューニング..................................105inithost/initial_hosts................................................................284iniファイルの設定例...............................................................261Interstage HTTP Server..........................................................322Interstage HTTP Serverのシステム資源..................................78Interstage HTTP Serverのシステム資源の設定......................78Interstage Java EE DASサービスのチューニング.................107Interstage Java EE DASサービスのヒープ領域サイズとアドレス

空間........................................................................................152Interstage Java EE Node Agentサービスのチューニング......110Interstage Java EE管理コンソールのチューニング...............113Interstage管理コンソールのシステム資源...............................92Interstage管理コンソールのシステム資源の設定...................92Interstage機能を使用するためのチューニング.......................44Interstage シングル・サインオンの環境定義.........................326Interstage シングル・サインオンのシステム資源......................82Interstage シングル・サインオンのシステム資源の設定..........82

Interstage ディレクトリサービスのシステム資源.......................85Interstage ディレクトリサービスのシステム資源の設定............85Interstage統合コマンドのシステム資源...................................92Interstageのチューニング.........................................................36IPCキー値..............................................................................101IPC資源のカスタマイズ..........................................................101IPv6環境での運用...................................................................49irconfig....................................................................................289

[J]J2EE互換のシステム資源........................................................78J2EEのチューニング..............................................................178Java EE機能のチューニング..................................................107java.lang.OutOfMemoryErrorがスローされた場合...............248java.lang.StackOverflowErrorがスローされた場合...............254Java Native Interface(JNI)......................................................188Java VM..................................................................................181Java VM終了時における状態情報のメッセージ出力機能. .236Java VMのヒープ領域サイズ/Perm領域サイズ.....................111Javaツール機能......................................................................258Javaヒープとガーベジコレクション..........................................185Javaヒープのチューニング.....................................................212JDK/JREのチューニング........................................................180JDK関連のドキュメント...........................................................180JDKドキュメント.......................................................................180JNI処理異常時のメッセージ出力..........................................245JPAのチューニング................................................................128JTS_RMP_PROC_CONC......................................................308JTS_RMP_THR_CONC........................................................309JTS用のリソース管理プログラムのスレッド多重度................309JTS用のリソース管理プログラムのプロセス多重度...............308

[L]LOGFILE................................................................................306

[M]max_exec_instance.................................................................267max_IIOP_resp_con...............................................................267max_impl_rep_entries............................................................268max_processes........................................................................268MessageQueueDirectorのシステム資源...................................80MessageQueueDirectorのシステム資源の設定.......................80MODE....................................................................................305MQ連携サービスを使用する場合...........................................22

[N]New世代領域用制御処理並列化機能付きGC（パラレルGC）192nsconfig..................................................................................287number_of_common_buffer...................................................269

[O]ORB........................................................................................143ORBのチューニング...............................................................143OTS_FACT_THR_CONC.....................................................308OTS_RECV_THR_CONC.....................................................308

- 334 -

OTSシステムが動作するホストのCORBAサービスのポート番号

................................................................................................309OTSシステムが動作するホスト名...........................................309OTSシステムのスレッド多重度..............................................308OTSシステム用業務システム情報定義ファイル...................316

[P]PARTICIPATE.......................................................................308period_idle_con_timeout........................................................274period_receive_timeout..........................................................274period_server_timeout............................................................274PORT......................................................................................309Portable-ORBの環境設定.....................................................332

[Q]queue_policy...........................................................................286

[R]read_interval_timeout.............................................................266RMPプロパティ.......................................................................310

[S]SIGBUS発生により異常終了した場合..................................255SSL通信の利用.....................................................................115[SYSTEM ENVIRONMENT]セクション...............................296

[T]TCP/IPパラメタのチューニング................................................99traceconfig..............................................................................318TRANMAX............................................................................307

[W]Webコンテナのチューニング.................................................116Webサーバ(Sun Java System Web Server)の環境定義.......333Webサーバコネクタのシステム資源........................................94Webサービスのチューニング.................................................133Windows(R)固有パラメタ.......................................................262[WRAPPER]セクション..........................................................298write_interval_timeout............................................................267

[あ]アップロードファイルの大サイズのチューニング...............114アプリケーション大処理時間.............................................112アプリケーション追加によるチューニング................................42アプリケーション用業務システム情報定義ファイル..............316異常終了箇所の情報............................................................238異常終了時のJavaヒープに関する情報................................240異常終了時のシグナルハンドラ情報....................................239異常発生時の原因振り分け..................................................248イベントサービス.......................................................................45イベントサービスの環境定義.................................................318イベントサービスのシステム環境の設定.................................73イベントサービスのシステム資源.............................................73イベントサービスの動作環境ファイル....................................318サプライヤ・コンシューマ総数の見積もり方法......................321運用時に必要なディスク容量....................................................1永続性コンテキストキャッシュ................................................128永続性ユニットの共有キャッシュ...........................................130オブジェクト参照の圧縮機能.................................................198

[か]仮想メモリと仮想アドレス空間...............................................182環境定義ファイルの制御文...................................................296環境変数..................................................................................48ガーベジコレクション処理の結果ログ出力機能の強化........201ガーベジコレクションのログ出力...........................................199ガーベジコレクション発生回数..............................................112ガーベジコレクション(GC)......................................................189記述形式................................................................................293基礎知識................................................................................180業務構成管理機能のチューニング.......................................179業務サーバを構築する場合のチューニング........................329共有メモリ.................................................................................99共有メモリ量の見積もり方法....................................................99空行........................................................................................296クライアントアプリケーションを追加した場合...........................42クライアント機能を使用する場合........................................22,35クライアント、サーバ兼用アプリケーションを追加した場合....43クライアントの同時接続数......................................................324クラスのインスタンス情報出力機能.......................................234クラッシュダンプ......................................................................243クラッシュダンプ・コアダンプ..................................................243グループ管理サービスの設定...............................................112コアダンプ...............................................................................244コネクタのチューニング..........................................................138コメント行................................................................................296コンカレント・マーク・スイープGC付きパラレルGC（CMS付きパ

ラレルGC）..............................................................................195コンポーネントトランザクションサービスの環境定義.............293コンポーネントトランザクションサービスのシステム環境の設定65コンポーネントトランザクションサービスのシステム資源.........65

[さ]大トランザクション多重度...................................................307

サーバアプリケーションを追加した場合..................................42サーバ機能運用時に必要なシステム資源.............................54サーバ機能を使用する場合.................................................1,23サーバマシン状態監視............................................................47時間監視機能の相関関係....................................................155システム...............................................................................97,98システム構成情報の見積もり方法 (Linuxの場合)..................98システム構成情報の見積もり方法 (Solarisの場合)................97システムのチューニング...........................................................54システムログファイルのパス...................................................306シャットダウンタイムアウト.......................................................142出力例と調査例.....................................................................240詳細属性................................................................................137シリアルGC.............................................................................192スタック....................................................................................184スタックオーバーフロー検出時のメッセージ出力機能.........254スタックトレース.......................................................................221スタックトレースの解析方法.....................................222,223,224スタックのチューニング..........................................................217ステートメント..........................................................................293スレッドダンプ.........................................................................226スレッドプーリング...................................................................122スローダウンが発生した場合.................................................258

- 335 -

性能監視ツール使用時に必要なシステム資源......................97性能情報の分析....................................................................165セクション................................................................................295セッションタイムアウト.............................................................113セッションリカバリ機能のチューニング..................................120接続検証.........................................................................135,140セットアップ種別.....................................................................305セットアップ情報ファイル.......................................................305セマフォ資源..........................................................................262想定するシステム形態(Java EE).............................................36想定するシステム形態（マルチ言語サービス）.......................37

[た]タイムアウト監視.....................................................................274タイムアウト時間.....................................................................322暖機運転................................................................................218チューニング/デバッグ技法...................................................221チューニング方法...................................................................212チューニング方法(Java EE).....................................................41チューニング方法(マルチ言語サービス)................................42長時間コンパイル処理の検出機能.......................................208通信データサイズに関する注意事項....................................146定義ファイルの設定値.............................................................38ディスク容量...............................................................................1データベース連携環境のチューニング................................133データベース連携サービス.....................................................44データベース連携サービスのiniファイル設定情報..............260データベース連携サービスの環境定義...............................300データベース連携サービスのシステム環境の設定................69データベース連携サービスのシステム資源............................69データベース連携サービスのチューニング..........................260同一Java VM内のリモートアクセスでデータコピーを防ぐ機能128動的コンパイル.......................................................................206動的コンパイル発生状況のログ出力機能............................210トランザクションアプリケーションのチューニング...................105トランザクション管理........................................................137,142トランザクションサービスのチューニング...............................142

[は]配備時のチューニング...........................................................116パラレルGC............................................................................192ハングアップ(フリーズ)した場合............................................257必要資源....................................................................................1標準GC（シリアルGC）............................................................192複数プロセス運用..................................................................111フレーム..................................................................................184プロセスが消滅(異常終了)した場合.....................................256プロセス強制停止時間のチューニング.................................104プロファイラ設定.....................................................................175プロファイラ設定の運用方法.................................................175プール内の接続数..........................................................133,139ホスト情報(IPアドレス/ホスト名)の変更方法............................53ポート番号..............................................................................115

[ま]マルチサーバ管理機能を使用する時に必要なシステム資源97マルチサーバ管理定義ファイル............................................331マルチサーバ管理の環境定義.............................................331

マルチサーバ管理を使用する場合...................................21,35メモリ容量.................................................................................23メモリ領域不足事象発生時のメッセージ出力機能の強化...250モニタロギング.................................................................159,160モニタロギングの操作手順....................................................161モニタロギングのログファイル................................................163

[や]ユーティリティワークユニットのチューニング.........................106予兆監視機能から警告が通知された場合の対処...............147予兆監視警告メッセージ(Javaヒープ)...................................148予兆監視警告メッセージ(ガーベジコレクション)..................149

[ら]ラッパーワークユニットのチューニング..................................105リカバリプロセスのスレッド多重度..........................................308リソース定義ファイル..............................................................311リポジトリのチューニング........................................................179例外発生時のスタックトレース出力.......................................225ログ出力における時間情報のフォーマット指定機能...........237ロードバランス...........................................................................45

[わ]ワークユニット数、オブジェクト数、プロセス数のチューニング103ワークユニットのチューニング................................................103

- 336 -

Interstage Web Server Express Interstage Application...

Documents

Transcript of Interstage Web Server Express Interstage Application...