印刷版 ( 2.3 MB) - ソフトウェア

Interstage Application Server/
Interstage Web Server
チューニングガイド
Windows/Solaris/Linux
B1WS-0946-04Z0(00)
2012年2月
まえがき
本書の目的
本書は、運用形態を変更したり、システム規模を変更する場合などに必要な環境設定のチューニングについて説明しています。
本書は、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)を使用する場合の環境定義について説明します。
輸出許可
本ドキュメントを非居住者に提供する場合には、経済産業大臣の許可が必要となる場合がありますので、ご注意ください。
著作権
Copyright 2011-2012 FUJITSU LIMITED
2012年2月 第4版
2011年7月 初版
- ii -
目　次
第1章 必要資源.........................................................................................................................................................................1
1.1 運用時に必要なディスク容量.............................................................................................................................................................1
1.1.1 サーバ機能を使用する場合........................................................................................................................................................1
1.1.2 マルチサーバ管理を使用する場合...........................................................................................................................................18
1.1.3 MQ連携サービスを使用する場合.............................................................................................................................................20
1.1.4 クライアント機能を使用する場合...............................................................................................................................................20
1.2 メモリ容量...........................................................................................................................................................................................21
1.2.1 サーバ機能を使用する場合......................................................................................................................................................21
1.2.2 マルチサーバ管理を使用する場合...........................................................................................................................................32
1.2.3 クライアント機能を使用する場合...............................................................................................................................................32
第2章 Interstageのチューニング..............................................................................................................................................34
2.1 想定するシステム形態......................................................................................................................................................................34
2.1.1 想定するシステム形態(Java EE)................................................................................................................................................34
2.1.2 想定するシステム形態（マルチ言語サービス）.........................................................................................................................35
2.2 定義ファイルの設定値......................................................................................................................................................................36
2.3 チューニング方法..............................................................................................................................................................................39
2.3.1 チューニング方法(Java EE).......................................................................................................................................................39
2.3.2 チューニング方法(マルチ言語サービス)..................................................................................................................................39
2.3.2.1 チューニング方法(アプリケーション追加によるチューニング)...........................................................................................39
2.3.2.1.1 クライアントアプリケーションを追加した場合...............................................................................................................40
2.3.2.1.2 サーバアプリケーションを追加した場合......................................................................................................................40
2.3.2.1.3 クライアント、サーバ兼用アプリケーションを追加した場合.........................................................................................41
2.3.2.2 チューニング方法(Interstageの機能を使用するためのチューニング)..............................................................................41
2.3.2.2.1 データベース連携サービス..........................................................................................................................................42
2.3.2.2.2 ロードバランス...............................................................................................................................................................43
2.3.2.2.3 イベントサービス...........................................................................................................................................................43
2.3.2.2.4 サーバマシン状態監視................................................................................................................................................45
2.4 環境変数について............................................................................................................................................................................45
2.5 IPv6環境での運用について.............................................................................................................................................................47
2.6 ホスト情報(IPアドレス/ホスト名)の変更方法について......................................................................................................................49
第3章 システムのチューニング.................................................................................................................................................50
3.1 サーバ機能運用時に必要なシステム資源......................................................................................................................................50
3.1.1 CORBAサービスのシステム資源の設定...................................................................................................................................53
3.1.2 コンポーネントトランザクションサービスのシステム資源の設定...............................................................................................62
3.1.3 データベース連携サービスのシステム資源の設定..................................................................................................................67
3.1.4 イベントサービスのシステム資源の設定...................................................................................................................................71
3.1.5 J2EE互換のシステム資源の設定..............................................................................................................................................76
3.1.6 Interstage HTTP Serverのシステム資源の設定.........................................................................................................................76
3.1.7 MessageQueueDirectorのシステム資源の設定.........................................................................................................................78
3.1.8 Interstage シングル・サインオンのシステム資源の設定............................................................................................................80
3.1.9 Interstage ディレクトリサービスのシステム資源の設定..............................................................................................................85
3.1.10 Interstage管理コンソールのシステム資源の設定....................................................................................................................92
3.1.11 Interstage統合コマンドのシステム資源の設定........................................................................................................................92
3.1.12 Webサーバコネクタのシステム資源の設定.............................................................................................................................94
3.1.13 Java EEのシステム資源の設定................................................................................................................................................98
3.2 マルチサーバ管理機能を使用する時に必要なシステム資源........................................................................................................98
3.3 性能監視ツール使用時に必要なシステム資源...............................................................................................................................99
3.3.1 システム構成情報の見積もり方法 (Solarisの場合) ..................................................................................................................99
3.3.2 システム構成情報の見積もり方法 (Linuxの場合) .................................................................................................................100
3.3.3 共有メモリ量の見積もり方法....................................................................................................................................................100
3.4 TCP/IPパラメタのチューニング.......................................................................................................................................................101
3.5 IPC資源のカスタマイズ...................................................................................................................................................................102
- iii -
第4章 ワークユニットのチューニング.......................................................................................................................................104
4.1 ワークユニット数、オブジェクト数、プロセス数のチューニング......................................................................................................104
4.2 プロセス強制停止時間のチューニング..........................................................................................................................................105
4.3 CORBAワークユニットのチューニング...........................................................................................................................................106
4.4 IJServerワークユニットのチューニング............................................................................................................................................106
4.5 トランザクションアプリケーションのチューニング............................................................................................................................106
4.6 ラッパーワークユニットのチューニング...........................................................................................................................................106
4.7 ユーティリティワークユニットのチューニング..................................................................................................................................106
第5章 Java EE機能のチューニング........................................................................................................................................108
5.1 Interstage Java EE DASサービスのチューニング...........................................................................................................................108
5.2 Interstage Java EE Node Agentサービスのチューニング...............................................................................................................111
5.3 IJServerクラスタのチューニング......................................................................................................................................................112
5.3.1 複数プロセス運用.....................................................................................................................................................................112
5.3.2 Java VMのヒープ領域サイズ/Perm領域サイズ.......................................................................................................................112
5.3.3 ガーベジコレクション発生回数................................................................................................................................................113
5.3.4 アプリケーション最大処理時間................................................................................................................................................113
5.3.5 グループ管理サービスの設定.................................................................................................................................................113
5.4 Interstage Java EE管理コンソールのチューニング.........................................................................................................................114
5.4.1 セッションタイムアウト................................................................................................................................................................114
5.4.2 アップロードファイルの最大サイズのチューニング.................................................................................................................115
5.4.3 ポート番号................................................................................................................................................................................116
5.4.4 SSL通信の利用........................................................................................................................................................................116
5.5 配備時のチューニング....................................................................................................................................................................117
5.6 Webコンテナのチューニング..........................................................................................................................................................117
5.7 EJBコンテナのチューニング...........................................................................................................................................................121
5.7.1 スレッドプーリング.....................................................................................................................................................................121
5.7.2 Enterprise Beanインスタンスのキャッシング.............................................................................................................................124
5.7.3 Enterprise Beanインスタンスのプーリング................................................................................................................................126
5.7.4 同一Java VM内のリモートアクセスでデータコピーを防ぐ機能..............................................................................................127
5.8 JPAのチューニング.........................................................................................................................................................................127
5.8.1 永続性コンテキストキャッシュ...................................................................................................................................................127
5.8.2 永続性ユニットの共有キャッシュ..............................................................................................................................................129
5.9 Webサービスのチューニング..........................................................................................................................................................132
5.10 データベース連携環境のチューニング........................................................................................................................................132
5.10.1 プール内の接続数.................................................................................................................................................................132
5.10.2 接続検証................................................................................................................................................................................134
5.10.3 トランザクション管理...............................................................................................................................................................135
5.10.4 詳細属性................................................................................................................................................................................136
5.11 コネクタのチューニング.................................................................................................................................................................137
5.11.1 プール内の接続数.................................................................................................................................................................137
5.11.2 接続検証................................................................................................................................................................................139
5.11.3 トランザクション管理...............................................................................................................................................................140
5.11.4 シャットダウンタイムアウト.......................................................................................................................................................140
5.12 トランザクションサービスのチューニング......................................................................................................................................141
5.13 ORBのチューニング......................................................................................................................................................................142
5.13.1 ORB........................................................................................................................................................................................142
5.13.2 通信データサイズに関する注意事項....................................................................................................................................144
5.14 予兆監視機能から警告が通知された場合の対処......................................................................................................................145
5.14.1 予兆監視警告メッセージ(Javaヒープ)...................................................................................................................................146
5.14.2 予兆監視警告メッセージ(ガーベジコレクション)...................................................................................................................147
5.15 Interstage Java EE DASサービスのヒープ領域サイズとアドレス空間..........................................................................................149
5.16 時間監視機能の相関関係............................................................................................................................................................153
5.17 モニタリング情報の監視................................................................................................................................................................157
5.17.1 注意事項................................................................................................................................................................................158
5.18 モニタロギング...............................................................................................................................................................................158
5.18.1 モニタロギングの操作手順....................................................................................................................................................159
- iv -
5.18.2 モニタロギングのログファイル................................................................................................................................................161
5.18.3 性能情報の分析.....................................................................................................................................................................163
5.19 プロファイラ設定............................................................................................................................................................................172
5.19.1 プロファイラ設定の運用方法.................................................................................................................................................172
第6章 J2EEのチューニング....................................................................................................................................................174
第7章 業務構成管理機能のチューニング................................................................................................................................175
7.1 リポジトリのチューニング.................................................................................................................................................................175
第8章 JDK/JREのチューニング..............................................................................................................................................176
8.1 基礎知識.........................................................................................................................................................................................176
8.1.1 JDK関連のドキュメント.............................................................................................................................................................176
8.1.2 Java VM....................................................................................................................................................................................177
8.1.3 FJVM........................................................................................................................................................................................178
8.1.4 仮想メモリと仮想アドレス空間..................................................................................................................................................178
8.1.5 スタック......................................................................................................................................................................................180
8.1.6 Javaヒープとガーベジコレクション............................................................................................................................................181
8.1.7 FJVMに対して指定可能なチューニング用オプション...........................................................................................................183
8.1.8 Java Native Interface(JNI)........................................................................................................................................................184
8.2 ガーベジコレクション(GC)...............................................................................................................................................................185
8.2.1 FJVMでサポートされるガーベジコレクション処理..................................................................................................................185
8.2.2 標準GC（シリアルGC）..............................................................................................................................................................187
8.2.3 New世代領域サイズ自動調整機能付きGC（FJGC）..............................................................................................................188
8.2.4 New世代領域用制御処理並列化機能付きGC（パラレルGC）..............................................................................................190
8.2.5 コンカレント・マーク・スイープGC付きパラレルGC（CMS付きパラレルGC）..........................................................................193
8.2.6 オブジェクト参照の圧縮機能...................................................................................................................................................196
8.2.7 ガーベジコレクションのログ出力..............................................................................................................................................196
8.2.7.1 ガーベジコレクション処理の結果ログ出力機能の強化...................................................................................................198
8.3 動的コンパイル................................................................................................................................................................................204
8.3.1 コンパイラ異常発生時の自動リカバリ機能..............................................................................................................................205
8.3.2 長時間コンパイル処理の検出機能.........................................................................................................................................206
8.3.3 動的コンパイル発生状況のログ出力機能..............................................................................................................................207
8.4 チューニング方法............................................................................................................................................................................209
8.4.1 Javaヒープのチューニング.......................................................................................................................................................209
8.4.2 スタックのチューニング.............................................................................................................................................................214
8.4.3 暖機運転..................................................................................................................................................................................215
8.5 チューニング/デバッグ技法............................................................................................................................................................218
8.5.1 スタックトレース.........................................................................................................................................................................218
8.5.1.1 スタックトレースの解析方法(その1)..................................................................................................................................219
8.5.1.2 スタックトレースの解析方法(その2)..................................................................................................................................220
8.5.1.3 スタックトレースの解析方法(その3)..................................................................................................................................221
8.5.2 例外発生時のスタックトレース出力.........................................................................................................................................222
8.5.3 スレッドダンプ...........................................................................................................................................................................222
8.5.4 クラスのインスタンス情報出力機能..........................................................................................................................................230
8.5.5 java.lang.System.gc()実行時におけるスタックトレース出力機能............................................................................................231
8.5.6 Java VM終了時における状態情報のメッセージ出力機能.....................................................................................................232
8.5.7 ログ出力における時間情報のフォーマット指定機能..............................................................................................................233
8.5.8 FJVMログ..................................................................................................................................................................................234
8.5.8.1 異常終了箇所の情報........................................................................................................................................................234
8.5.8.2 異常終了時のシグナルハンドラ情報 ..............................................................................................................................235
8.5.8.3 異常終了時のJavaヒープに関する情報...........................................................................................................................236
8.5.8.4 出力例と調査例.................................................................................................................................................................236
8.5.9 クラッシュダンプ・コアダンプ....................................................................................................................................................239
8.5.9.1 クラッシュダンプ.................................................................................................................................................................239
8.5.9.2 コアダンプ（Solaris）...........................................................................................................................................................240
8.5.9.3 コアダンプ（Linux）............................................................................................................................................................240
8.5.10 JNI処理異常時のメッセージ出力..........................................................................................................................................241
-v-
8.6 異常発生時の原因振り分け...........................................................................................................................................................244
8.6.1 java.lang.OutOfMemoryErrorがスローされた場合..................................................................................................................244
8.6.1.1 メモリ領域不足事象発生時のメッセージ出力機能の強化..............................................................................................245
8.6.2 EXTP4435メッセージまたはISJEE_OM1018メッセージが出力された場合...........................................................................247
8.6.3 java.lang.StackOverflowErrorがスローされた場合.................................................................................................................250
8.6.3.1 スタックオーバーフロー検出時のメッセージ出力機能....................................................................................................250
8.6.4 SIGBUS発生により異常終了した場合....................................................................................................................................251
8.6.5 プロセスが消滅(異常終了)した場合.......................................................................................................................................251
8.6.6 ハングアップ(フリーズ)した場合..............................................................................................................................................253
8.6.7 スローダウンが発生した場合...................................................................................................................................................253
8.7 Javaツール機能...............................................................................................................................................................................254
第9章 データベース連携サービスのチューニング....................................................................................................................255
9.1 データベース連携サービスのiniファイル設定情報.......................................................................................................................255
9.2 iniファイルの設定例........................................................................................................................................................................256
9.3 セマフォ資源...................................................................................................................................................................................256
9.4 Windows(R)固有パラメタ................................................................................................................................................................257
付録A CORBAサービスの動作環境ファイル...........................................................................................................................258
A.1 config..............................................................................................................................................................................................259
A.2 gwconfig.........................................................................................................................................................................................276
A.3 inithost/initial_hosts........................................................................................................................................................................278
A.4 queue_policy...................................................................................................................................................................................280
A.5 nsconfig...........................................................................................................................................................................................282
A.6 irconfig............................................................................................................................................................................................283
付録B コンポーネントトランザクションサービスの環境定義......................................................................................................287
B.1 記述形式.........................................................................................................................................................................................287
B.1.1 ステートメント............................................................................................................................................................................287
B.1.2 セクション..................................................................................................................................................................................289
B.1.3 コメント行..................................................................................................................................................................................290
B.1.4 空行..........................................................................................................................................................................................290
B.2 環境定義ファイルの制御文............................................................................................................................................................290
B.2.1 [SYSTEM ENVIRONMENT]セクション.................................................................................................................................290
B.2.2 [WRAPPER]セクション ...........................................................................................................................................................292
付録C データベース連携サービスの環境定義........................................................................................................................294
C.1 configファイル.................................................................................................................................................................................294
C.2 セットアップ情報ファイル................................................................................................................................................................299
C.2.1 MODE: セットアップ種別.........................................................................................................................................................299
C.2.2 LOGFILE: システムログファイルのパス..................................................................................................................................300
C.2.3 TRANMAX: 最大トランザクション多重度..............................................................................................................................301
C.2.4 PARTICIPATE: 1トランザクションに参加するリソース数.......................................................................................................301
C.2.5 OTS_FACT_THR_CONC: OTSシステムのスレッド多重度...................................................................................................302
C.2.6 OTS_RECV_THR_CONC: リカバリプロセスのスレッド多重度..............................................................................................302
C.2.7 JTS_RMP_PROC_CONC: JTS用のリソース管理プログラムのプロセス多重度....................................................................302
C.2.8 JTS_RMP_THR_CONC: JTS用のリソース管理プログラムのスレッド多重度........................................................................303
C.2.9 HOST: OTSシステムが動作するホスト名................................................................................................................................303
C.2.10 PORT: OTSシステムが動作するホストのCORBAサービスのポート番号............................................................................303
C.3 RMPプロパティ...............................................................................................................................................................................303
C.4 リソース定義ファイル.......................................................................................................................................................................305
C.5 OTSシステム用業務システム情報定義ファイル............................................................................................................................309
C.6 アプリケーション用業務システム情報定義ファイル.......................................................................................................................310
付録D イベントサービスの環境定義........................................................................................................................................311
D.1 traceconfig.......................................................................................................................................................................................311
D.2 サプライヤ・コンシューマ総数の見積もり方法...............................................................................................................................314
付録E Interstage HTTP Serverの環境定義...........................................................................................................................315
- vi -
E.1 タイムアウト時間..............................................................................................................................................................................315
E.2 クライアントの同時接続数...............................................................................................................................................................317
付録F Interstage シングル・サインオンの環境定義.................................................................................................................319
F.1 1台のサーバにリポジトリサーバを構築する場合のチューニング..................................................................................................319
F.2 1台のサーバに認証サーバを構築する場合のチューニング........................................................................................................320
F.3 1台のサーバにリポジトリサーバと認証サーバを構築する場合のチューニング...........................................................................320
F.4 業務サーバを構築する場合のチューニング.................................................................................................................................321
付録G マルチサーバ管理の環境定義.....................................................................................................................................324
G.1 マルチサーバ管理定義ファイル....................................................................................................................................................324
付録H Portable-ORBの環境設定.......................................................................................................................................... 325
付録I Webサーバ(Sun Java System Web Server)の環境定義.............................................................................................. 326
索引...................................................................................................................................................................................... 327
- vii -
第1章 必要資源
1.1 運用時に必要なディスク容量
運用時に必要なディスク容量は次のとおりです。
1.1.1 サーバ機能を使用する場合
以下の各機能を使用する場合のディスク容量を示します。
・ Interstage動作環境
・ Interstage管理コンソール
・ 業務構成管理
・ Interstage HTTP Server
・ Interstage JMXサービス
・ Interstage シングル・サインオン
・ Interstage ディレクトリサービス
・ J2EE
・ IJServerワークユニット
・ Interstage JMS
・ Servletサービス(OperationManagement)
・ ワークユニット
・ CORBAサービス
・ イベントサービス
・ Portable-ORB
・ コンポーネントトランザクションサービス
・ データベース連携サービス
・ ロードバランス
・ 性能監視ツール
・ MessageQueueDirector
・ フレームワーク
・ Java EE
機能: Interstage動作環境
ディレクトリ
コンポーネントトランザクションサービスのイ
ンストールディレクトリ\var\td001
(Interstage動作環境定義ファイルの“TD
path for system”で指定)
ディスク容量
(単位:Mバイト)
60 以上
備考(用途)
Interstage動作環境作成
時
機能: Interstage管理コンソール
-1-
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
ログ情報
(注)
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
ディスク容量
(単位:Mバイト)
備考(用途)
運用の内容により、必要と
するサイズを検討してくだ
さい。 (注)
デフォルトから変更した場
合は、変更先
/var/opt/FJSVisas/repository
注)
業務構成管理のリポジトリの格納先のサイズは、“Interstage Application Server 運用ガイド(基本編)”の“業務構成管理機能”を参
照してください。
機能: Interstage HTTP Server
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
アクセスログ、エラーログ、トレースログ格納
ディレクトリ
運用の内容により、必要と
するサイズを検討してくだ
さい。
アクセスログ、エラーログ、
トレースログ
2
オペレーションログ
10
保守ログ
Interstage HTTP Serverのインストールディ
レクトリ\var\opelog
/var/opt/FJSVihs/var/opelog
Interstage HTTP Serverのインストールディ
-2-
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
運用の内容により、必要と
するサイズを検討してくだ
さい。
コンテンツ(HTML文書な
ど)
ディスク容量
(単位:Mバイト)
備考(用途)
レクトリ\var\.ihsapi
/var/opt/FJSVihs/var/.ihsapi
コンテンツ格納するディレクトリ
機能: Interstage JMXサービス
ディレクトリ
Interstage JMXサービスのインストールディ
レクトリ
14以上 (注)
ディレクトリ
ディスク容量
(単位:Mバイト)
/var/opt
14 以上 (注)
/var/opt
32 以上 (注)
/etc/opt
0.1 以上
備考(用途)
注)
Interstage JMXサービスのカスタマイズでログインログのファイルサイズの上限値を変更している場合、以下のディスク所要量が必
要となります。
－ ログインログ
ログインログのファイルサイズの上限値 × 2 (Mバイト)
上限値を変更していない場合、ログインログのファイルサイズの上限値は1に設定されています。
機能: Interstage シングル・サインオン
Interstage シングル・サインオンの業務サーバ機能
ディレクトリ
Interstage シングル・サインオンのインス
トールディレクトリ\ssoatzag\log
ディスク容量
(単位:Mバイト)
備考(用途)
運用の内容により、必要と
するサイズを検討してくだ
さい。 (注1)
アクセスログなどのログ情
報
(アクセスログファイルの出
力先ディレクトリ)
/var/opt/FJSVssoaz/log
2
Interstage シングル・サインオンのインス
トールディレクトリ\ssocm\etc
/var/opt/FJSVssocm/etc
Interstage シングル・サインオンのインス
トールディレクトリ
運用の内容により、必要と
するサイズを検討してくだ
さい。
/etc/opt
-3-
アクセス制御情報
Interstage シングル・サインオンの認証サーバ機能
ディレクトリ
Interstage シングル・サインオンのインス
トールディレクトリ\ssoatcag\log
ディスク容量
(単位:Mバイト)
備考(用途)
運用の内容により、必要と
するサイズを検討してくだ
さい。 (注1)
アクセスログなどのログ情
報
(アクセスログファイルの出
力先ディレクトリ)
/var/opt/FJSVssoac/log
Interstage シングル・サインオンのインス
トールディレクトリ\ssofsv\log
運用の内容により、必要と
するサイズを検討してくだ
さい。 (注1)(注2)
/var/opt/FJSVssofs/log
2 (注3)(注4)
Interstage シングル・サインオンのインス
トールディレクトリ\ssocm\etc
/var/opt/FJSVssocm/etc
Interstage シングル・サインオンのリポジトリサーバ機能
ディレクトリ
Interstage シングル・サインオンのインス
トールディレクトリ\ssoatcsv\log
ディスク容量
(単位:Mバイト)
備考(用途)
運用の内容により、必要と
するサイズを検討してくだ
さい。 (注1)(注5)
アクセスログなどのログ情
報
(アクセスログファイル、お
よびセション管理ログファ
イルの出力先ディレクトリ)
/var/opt/FJSVssosv/log
2
Interstage シングル・サインオンのインス
トールディレクトリ\ssocm\etc
/var/opt/FJSVssocm/etc
注1)
デフォルト設定のままでは使用ディスクサイズの上限なしにログが採取されます。ディスク不足発生を防止するために、定期的に
不要になったログファイルを削除するか、ログの採取方法を変更してください。
注2)
認証サーバ間連携を行わない場合は、0Mバイトです。
注3)
統合Windows認証を行う場合には、2Mバイトを加算してください。
注4)
認証サーバ間連携を行う場合には、2Mバイトを加算してください。
注5)
セション管理を行うリポジトリサーバをクラスタシステム上で運用する場合には、52Mバイトを加算してください。
機能: Interstage ディレクトリサービス
ディレクトリ
Interstage ディレクトリサービスのインストー
ルディレクトリ\var
ディスク容量
(単位:Mバイト)
20 × リポジトリ作成数 ＋
20
-4-
備考(用途)
ログ情報
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
/var/opt
0.5 × リポジトリ作成数
環境定義
Interstage ディレクトリサービスのアクセスロ
グ作成ディレクトリ
Interstage管理コンソール
のアクセスログの設定値に
依存
サイズ × 世代管理数
アクセスログ
Interstage ディレクトリサービスのデータベー
ス格納先ディレクトリ
(注1)
データベース格納先
(リポジトリのデータベース
として標準データベースを
使用する場合)
Interstage ディレクトリサービス SDKのイン
ストールディレクトリ\var
プロセス数 × 8
/var/opt/FJSVirepc
同時接続数 × 8 (注2)
Interstage ディレクトリサービスのインストー
ルディレクトリ\etc
/etc/opt
Interstage ディレクトリサー
ビス SDKのログ情報
注1)
1つのリポジトリあたりで、以下のディスク所要量が必要です。
－ レプリケーション環境のマスタのリポジトリ
0.2 × n × s ÷ 500 ＋ 200
－ 上記以外
0.1 × n × s ÷ 500 ＋ 200
n: エントリ数
s: 1エントリをLDIFで記述したときのサイズ(単位:バイト)
計算式は目安です。ディスク容量は十分に余裕を持たせてください。
データベース格納先に指定したディスク領域が不足すると、メッセージirep30023を表示し、リポジトリを強制終了します。メッセー
ジirep30023の対処は、“メッセージ集”の“メッセージ番号がirepで始まるメッセージ”を参照してください。
注2)
同時接続数には、以下の必要数の総和を指定して見積もってください。
－ スレッド多重のアプリケーションを使用してリポジトリにアクセスする場合の、アプリケーションのプロセス数
－ プロセス多重のアプリケーションを使用してリポジトリにアクセスする場合の、アプリケーションのプロセス多重度
－ Interstage シングル・サインオン機能を使用する場合の、Interstage シングル・サインオンのリポジトリサーバ機能を組み込んだ
Webサーバのクライアント同時接続数
機能: J2EE
ディレクトリ
J2EE共通ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
運用の内容により、必要と
するサイズを検討してくだ
さい。
J2EEアプリケーションの資
産一式
/var/opt/FJSVj2ee/deployment
機能: IJServerワークユニット
-5-
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
24 以上 (注1)
J2EE共通ディレクトリ\ijserver\IJServer名\logディレクトリ
J2EE共通ディレクトリ/ijserver/IJServer名/logディレクトリ
2 以上 (注2)
Interstageのインストールディレクトリ\F3FMjs5\logs\jk2
/var/opt/FJSVjs5/logs/jk2
(注3)
Servletサービスのセション
リカバリ機能使用時
セションの永続化有効時、
Session Registry Serverを
運用する環境で必要で
す。
J2EE共通ディレクトリ\ijserver\Session Registry
Server(IJServer)名\apps\srs.ear\srs.war\serializedata
\sessionrecovery
J2EE共通ディレクトリ/ijserver/Session Registry Server(IJServer)
名/apps /srs.ear/srs.war/serializedata/sessionrecovery
注1)
IJServerワークユニット1つにつき以下を加算してください。
プロセス多重度 ×
4(コンテナログとコンテナ情報ログのデフォルトディスク使用量) ×
6(世代分のバックアップ) 以上
アプリケーションのタイムアウトが多発する場合、アプリケーションで短時間に大量のメッセージを出力する場合、およびデバッグ
情報出力を行う場合は、“J2EE共通ディレクトリ/ijserver/IJServer名/log”配下のコンテナ情報ログのディスク使用量が大きくなりま
す。このような操作が想定される場合は、十分なディスク容量をご用意ください。
注2)
Webサーバ1つにつきデフォルトで2Mバイトです。アプリケーションで短時間に大量のメッセージを出力する場合、デバッグ情報
出力を行う場合は、ディスク使用量が大きくなります。このような操作が想定される場合は、十分なディスク容量をご用意ください。
注3)
セションリカバリ機能を使用して、セションの永続化を有効にした場合は、Session Registry Server環境定義ファイルで指定したセ
ションの永続化ファイルの保存先にセションの永続化ファイルが生成されます。配備するWebアプリケーション1つについて、次の
ディスク容量が必要です。(単位:Mバイト)
(0.005 ＋ (0.005 ＋ セションの保持するデータ容量) × セション数) × 2
(0.001 ＋ (0.002 ＋ セションの保持するデータ容量) × セション数) × 2
(0.008 ＋ (0.008 ＋ セションの保持するデータ容量) × セション数) × 2
“セションの保持するデータ容量”は、Webアプリケーションでセションの属性(Attribute)にセットするオブジェクトおよびキーのサイ
ズの合計値です。
上記の値は、利用しているファイルシステムによっては値が増減する場合があります。
なお、Session Registry Serverは、Interstage Application Server Enterprise Editionで運用可能です。
機能: Interstage JMS
ディレクトリ
Interstage JMSのインストールディレクトリ
\etc
ディスク容量
(単位:Mバイト)
0.01 ＋
(durable Subscriber数 ×
0.002)
/etc/opt
-6-
備考(用途)
定義情報
ディレクトリ
ディスク容量
(単位:Mバイト)
10 以上
備考(用途)
コンソールファイル
Interstage JMSのインストールディレクトリ
\var
/var/opt
機能: Servletサービス(OperationManagement)
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
ログ情報
12
Servletサービス(OperationManagement)
インストールディレクトリ\log
/var/opt/FJSVjs2su/log
機能: ワークユニット
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
Interstage動作環境定義の定義項目“TD
path for system”で指定
1つのワークユニット定義
サイズ × ワークユニット定
義数 (注)
ワークユニット定義登録時
1つのワークユニット定義
サイズ × ワークユニット起
動数 (注)
ワークユニット運用時
注)
1つのワークユニット定義サイズ ＝
1000 ＋
(500 × “[Application Program]セクション定義数”) ＋
(500 × “[Resource Manager]セクション定義数”) ＋
(500 × “[Nonresident Application Process]セクション定義数”) ＋
(500 × “[Multiresident Application Process]セクション定義数”) ＋
ユーザ任意指定文字列データ長
機能: CORBAサービス
Interstage Application Server Standard-J Editionの場合
Interstage Application Server Enterprise Editionの場合
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
0.1 以上
インプリメンテーション情
報、ネーミングサービス、
インタフェースリポジトリの
データサイズに依存しま
す。
4.1 以上 (注1)
ネーミングサービス情報
CORBAサービスのインストールディレクト
リ\etcフォルダ
/etc/opt
8 以上
CORBAサービスのインストールディレクト
リ\varフォルダ
ログ情報
42.0
-7-
ディレクトリ
/var/opt
ディスク容量
(単位:Mバイト)
備考(用途)
24.0
(デフォルト時の最大サイ
ズ) (注2)
2.0 以上 (注3)
内部ログ採取時(プレイン
ストール型Javaライブラリ
以外の場合)
4.0 以下 (注1)
ネーミングサービスのユー
ザ例外ログ情報
4.0 以下 (注1)
ネーミングサービスの実行
トレース情報(サービス動
作時のみ)
32.3 以下
インタフェースリポジトリ
サービスのログ情報(サー
ビス動作時のみ)
10.4 (注4)
トレース情報
10.3 以上 (注5)
インタフェースリポジトリ
サービス情報
1.0 以上
IDL定義の量に依存
C/C++コンパイラ動作時に
は、別途作業用のディスク
容量が必要
IDLコンパイラ動作時
Java VMのシステムプロパティのuser.dirで
指定
(注6)
内部ログ採取時(プレイン
ストール型Javaライブラリの
場合)
環境変数OD_HTTPGW_HOMEまたは
OD_HOMEで指定されたvarディレクトリ
2.0 以上 (注7)
HTTP-IIOPゲートウェイの
内部ログ採取時
CORBAサービスのインストールディレクト
リ\var\traceフォルダ
/var/opt/FSUNod/trace
/var/opt/FJSVod/trace
コンポーネントトランザクションサービスイ
ンストールディレクトリ\var\IRDB
コンポーネントトランザクションサービスイ
ンストールディレクトリ/var/IRDB
(Interstage統合コマンド使用時のデフォル
ト)
/tmp
Interstage Web Serverの場合
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
8.0 以上
CORBAサービスのインストールディレクト
リ\varフォルダ
ログ情報
42.0
/var/opt
-8-
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
24.0
(デフォルト時の最大サイ
ズ) (注2)
2.0 以上 (注3)
内部ログ採取時(プレイン
ストール型Javaライブラリ
以外の場合)
10.4 (注4)
トレース情報
(注6)
内部ログ採取時(プレイン
ストール型Javaライブラリの
場合)
CORBAサービスのインストールディレクト
リ\var\traceフォルダ
/var/opt/trace
Java VMのシステムプロパティのuser.dirで
指定
注1)
CORBAサービスのサーバマシンにネーミングサービスを構築する場合に、必要となるディスク容量について以下に示します。
－ ディスク容量
用途
ネーミングサー
ビス情報
容量
オブジェクトリポジトリ
(固定)16Kバイト
制御ファイル
(固定)2056Kバイト
データファイル
(可変)2048(Kバイト) × コンテキスト数 ＋
(オブジェクトリファレンス長 × オブジェクト数
× 2)
実行トレース情報
(最大)4096Kバイト
ユーザ例外ログ情報
(最大)4096Kバイト
注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は英数字)
-9-
の名前で採取されます。
自ホストでネーミングサービス、インタフェースリポジトリを動作させる場合には、それぞれ、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
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
計算式(単位:バイト)
項目
包含数
意味
包含する型宣言数
- 10 -
記
号
項目
意味
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の通信プロセスごとにログファイルが作成されま
す。なお、ログファイルは、不要になった時点で、削除してください。
機能: イベントサービス
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
チャネル情報
イベントサービスのインストールディレクトリ
\etc
0.1 以上
/etc/opt
1.0 以上
イベントサービスのインストールディレクトリ
\var
61(Mバイト) ＋
essetcnfコマンドの-s logsizeオプションの指定
値×2(Kバイト)以上
/var/opt
ログ情報
トレース情報
traceconfigファイルの
trace_size × トレースファ
イルの世代数
トレースの採取方法によっ
て異なります。 (注1)
Interstage管理コンソールで保存先(新規作
成)の格納ディレクトリで指定、またはイベ
ントサービスのユニット定義ファイルの
“trandir”、“sysdir”、“userdir”で指定
不揮発チャネル運用時
38 × イベントサービスで
作成したユニット数以上
(注2)
運用の内容により、必要と
するサイズを検討してくだ
さい。 (注2)
- 11 -
注1)
－ プロセス単位で内部トレースを採取する
(traceconfigファイルのtrace_buffer = process)場合
traceconfigファイルのtrace_size × イベントチャネルのプロセス数 ×
トレースファイルの世代数
イベントチャネルのプロセス数 ＝
静的イベントチャネルグループ数 ＋ 動的イベントチャネルのプロセス数
動的イベントチャネルのプロセス数:
isinitコマンドでInterstage初期化時に設定したInterstage動作環境定義の定義“Event maximum Process”の指定値。
ノーティフィケーションサービスを使用している場合は、“動的イベントチャネルのプロセス数×2”としてください。
－ イベントサービス単位で内部トレースを採取する
(traceconfigファイルのtrace_buffer = system)場合
traceconfigファイルのtrace_size × トレースファイルの世代数
注2)
Interstage管理コンソールで設定した場合は、保存先(新規作成)の格納ディレクトリには、以下の容量が必要となります。
－ イベントデータ用ファイル容量
－ システム用ファイル容量
－ トランザクション用ファイル容量:
((トランザクション多重度 × 4) ＋ 256 ＋
(1トランザクション内最大メッセージサイズ × 2)) × 16 (KB)
ユニット定義ファイルで設定した場合は、各ユニット定義ファイルで指定した以下の容量が必要となります。
－ “sysdir”で指定したディレクトリには、“syssize”で指定したサイズ
－ “userdir”で指定したディレクトリには、“usersize”で指定したサイズ
－ “trandir”で指定したディレクトリには、
((tranmax×4) ＋ 256 ＋ (tranunitmax × 2)) × 16 (Kバイト)
機能: Portable-ORB
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
ログ情報
(注2)
Portable-ORBインストールディレクトリ (注1)
/var/opt (注1)
注1)
アプレットとして動作する場合は、アプレットが動作するクライアントマシン上のローカルディスクに、porbeditenvコマンドで“ログ格
納ディレクトリ”として指定したディレクトリとなります。
注2)
porbeditenvコマンドで“ログ情報を採取”を指定した場合、
設定した“ログファイルサイズ” × 2 × 動作するアプリケーション/アプレット数
機能: コンポーネントトランザクションサービス
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
ログトレースファイル
25以上
コンポーネントトランザクションサービスの
インストールディレクトリ\var
- 12 -
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
/var/opt/FSUNtd/
15.0 以上
動作環境
運用の内容により、必要と
するサイズを検討してくだ
さい。 (注)
異常終了した場合に採取
されるcoreファイル
/opt/FSUNtd/etc/isreg(Interstageの動作環
境ディレクトリ)
/opt/FJSVtd/etc/isreg(Interstageの動作環
境ディレクトリ)
/var
注)
ディスク所要量の算出方法は以下のとおりです。
CORBAサービス関連の共有メモリサイズ(*1) × 3 ＋
コンポーネントトランザクションサービスの共有メモリサイズ(*2) ＋
ワークユニット数 × 0.26 ＋
ワークユニットに含まれるIDL定義のパラメタ数(*3) × 0.00005 ＋
基本サイズ(*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
クライアント数とは、Interstageシステム定義を生成するために、isgendefコマンドで指定したシステム規模により次のとおり見積
もってください。
small : 50
moderate : 100
large : 500
super : 1000
－ *3: ワークユニットに含まれるIDL定義のパラメタ数
ワークユニット数やIDL定義内のパラメタ数が多い場合に加算してください。
各オペレーションのパラメタに構造体がある場合、パラメタごとに構造体のメンバ数を加算してください。
－ *4: 基本サイズ
コンポーネントトランザクションサービスの環境定義ファイル(/var/opt/FJSVtd/etc/sysdef)のSystem Scale: ステートメントに指定し
た値に応じて、以下のようになります。
small : 250
moderate : 330
large : 840
super : 1400
small : 270
moderate : 350
- 13 -
large : 860
super : 1420
機能: データベース連携サービス
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
(注)
システムログファイル
トランザクション数 × 0.008
＋ 0.001
データベース連携サービ
ス運用時
－
ログファイル格納ディレクトリ
トレースログファイル格納ディレクトリ
運用環境の
OTS_TRACE_SIZE ×
0.001
リソース管理トレースログファイル格納ディ
レクトリ
運用環境の
RESOUCE_TRACE_SIZ
E × 0.001
リカバリトレースログファイル格納ディレクト
リ
運用環境の
RECOVERY_TRACE_S
IZE × 0.001
監視プロセストレースログファイル格納ディ
レクトリ
運用環境の
OBSERVE_TRACE_SIZ
E × 0.001
リソース定義ファイル格納ディレクトリ
登録したリソース定義ファ
イル数 × 0.001
5.0 以上
/opt/FSUNots/var
(otsgetdumpコマンドによるダンプファイル
格納ディレクトリ)
注)
データベース連携サービスのシステムログファイルは、isgendefコマンドで指定したシステム規模により異なりますので、以下のと
おり見積もってください。
small : 1Mバイト以上
moderate : 2Mバイト以上
large : 8Mバイト以上
super : 16Mバイト以上
機能: ロードバランス
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
データファイル
(注)
CORBAサービスのインストールディレクトリ
\etcフォルダ
/etc/opt
注)
以下のディスク所要量が必要です。
ロードバランスグループ数 × ((1ロードバランスグループあたりのオブジェクトリファレンス数 × オブジェクトリファレンス長) ＋ 0.0005)
初期量として、8256Kバイトを、初回起動時に獲得します。
これを超過した場合、1024Kバイト単位で拡張します。
- 14 -
機能: 性能監視ツール
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
格納ディレクトリ
1.0以上 (注1)
性能ログファイル
/var
6.4 × 性能監視ツールの
共有メモリサイズ(注2) ×
6
異常終了した場合に採取
されるcoreファイル
注1)
所要量 ＝ ispmakeenvで指定する共用メモリサイズ × (測定時間 ÷ インターバル時間)
注2)
ispmakeenvコマンドの-mオプションで指定する共有メモリサイズです。
機能: MessageQueueDirector
ディレクトリ
－
ディスク容量
(単位:Mバイト)
備考(用途)
運用の内容により、必要と
するサイズを検討してくだ
さい
詳細は
“MessageQueueDirector 説
明書”の“ファイル容量の見
積り”を参照してください
ディスク容量
(単位:Mバイト)
備考(用途)
機能: フレームワーク
ディレクトリ
Java VMのシステムプロパティの
java.io.tmpdirで指定
クライアント(Webブラウ
ザ)からアップロードされる
ファイルサイズ
ファイルアップロード機能
の使用時 (注)
運用の内容により、必要
とするサイズを検討してく
ださい。
フレームワークのログ機能で指定したファ
イルが格納されるディレクトリ
運用の内容により、必要と
するサイズを検討してくだ
さい。
フレームワークのログ機能
の使用時
注)
このディレクトリには、WebブラウザからアップロードされたファイルのサイズがWebアプリケーションの指定したファイル転送用メモ
リサイズを超えた場合に、アップロードされたファイルが格納されます。
機能: Java EE
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
配備ファイルのサイズ × 2
配備時に使用する一
時領域
配備ファイルを展開した資産のサイ
ズ×2
Java EEアプリケーショ
ンの資産一式
[Java EE共通ディレクトリ]\work
[Java EE共通ディレクトリ]/work
[Java EE共通ディレクトリ]
- 15 -
ディレクトリ
ディスク容量
(単位:Mバイト)
配備モジュールの誤りに依存
[Java EE共通ディレクトリ]\domains\interstage\logs
\verifier-results
[Java EE共通ディレクトリ]/domains/interstage/logs/verifierresults
・ 時間によるローテーションを指定
した場合
1回あたりの出力サイズ × 1日あ
たりの採取回数 × (保存するロ
グファイルの世代数 ＋ 1)
[Java EE共通ディレクトリ]\nodeagents\ijna\サーバーイン
スタンス名\logs
[Java EE共通ディレクトリ]/nodeagents/ijna/サーバーインス
タンス名/logs
・ サイズによるローテーションを指
定した場合
ログファイルのサイズ × (保存す
るログファイルの世代数 ＋ 1)
※1回あたりの出力サイズは、ログファ
イル1つにつき約0.0001Mバイト～
0.0005Mバイトです。
※1日あたりの採取回数は、コマンド
起動時に指定された採取間隔により
決まります。
採取間隔の指定単位は1分のため、
「1440÷採取間隔」で1日あたりの採
取回数を求めることができます。
※ログファイルのサイズは、ログ設定
で指定したログファイルのサイズで
す。
※保存するログファイルの世代数
は、ログ設定で指定したログファイル
の世代数です。
[Java EE共通ディレクトリ]\domains\interstage\applications
\j2ee-apps
配備するエンタープライズアプリケー
ション(.ear)を展開した資産のサイズ
[Java EE共通ディレクトリ]/domains/interstage/applications/
j2ee-apps
[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
配備するアプリケーションの構成に
依存します。
なお、大容量、および多数の配備モ
ジュールを配備する場合、開発環境
でアプリケーションの配備を行い、生
- 16 -
備考(用途)
配備モジュールの検
証結果を格納する領
域
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
成物の容量を事前に確認することを
推奨します。
最大4Mバイト
[Java EE共通ディレクトリ]\commands
[Java EE共通ディレクトリ]/commands
[Java EE共通ディレクトリ]\domains\interstage\imq
\instances\ブローカインスタンス名
初期値1MBに下記で算出した値を
加算してください。
・ 物理格納先ごとに以下の値を算
出し、合計してください。
最大蓄積件数×(メッセージボ
ディに設定する最大サイズ＋メッ
セージプロパティに設定する最
大サイズ＋0.0003)×2
[Java EE共通ディレクトリ/domains/interstage/imq/instances/
ブローカインスタンス名
メッセージブローカを
複数起動する場合に
は、メッセージブローカ
ごとに左記の値を算出
し、各値を合計して
ディスク容量を算出し
てください。
・ imq.log.file.rolloverbytesプロパ
ティに設定したサイズ×10
(トランザクションを使用する場合)
・ トランザクションの合計数×0.002
・ トランザクション中に受信するメッ
セージの最大数をnとして、n×
(512＋32×n)×トランザクション
の合計数×0.000001
(Durable Subscription機能を使用
する場合)
・ durable Subscriberの最大数×
0.003
[Java EE共通ディレクトリ]\nodeagents\ijna\サーバーイン
スタンス名\logs\iiop
IIOPアクセスログのログサイズ × (保
存するログファイルの世代数 ＋ 1)
[Java EE共通ディレクトリ]/nodeagents/ijna/サーバーインス
タンス名/logs/iiop
[トランザクションログの位置]
キーポイント間隔の設定値 ×
0.0005Mバイト ＋ 0.15Mバイト
トランザクションログファ
イルの格納先
[セッション格納位置]
passivateされたBeanインスタンスの
ファイルサイズ × passivateされた
Beanインスタンス数
「5.7.2 Enterprise Bean
インスタンスのキャッシ
ング」を参照しEJBコン
テナ定義のチューニン
グを実施したり、負荷
試験や運用リハーサ
ルを実施したりしてど
の程度のディスク容量
が必要になるかどうか
事前に想定し、見積も
ることを推奨します。
Beanインスタンスのファイルサイズや
passivateされる数量は、配備するア
プリケーションやアプリケーションの
運用方法に依存します。
IJServerクラスタのHTTPトレースログ
HTTPトレースログのログサイズ ×
(保存するログファイルの世代数 ＋
1)
- 17 -
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
[Java EE共通ディレクトリ]\nodeagents\ijna\サーバーインス
タンス名\logs\http
[Java EE共通ディレクトリ]/nodeagents/ijna/サーバーインスタ
ンス名/logs/http
Interstage Java EE DASサービスのHTTPトレースログ
[Java EE共通ディレクトリ]\domains\interstage\logs\http
[Java EE共通ディレクトリ]/domains/interstage/logs/http
IJServerクラスタのHTTPアクセスログ
・ サイズによるローテーションを指
定した場合
ログファイルのサイズ × (保存す
るログファイルの世代数 ＋ 1)
[Java EE共通ディレクトリ]\nodeagents\ijna\サーバーインス
タンス名\logs\http
・ 時間によるローテーションを指定
した場合
1回あたりの出力サイズ × 1日あ
たりの採取回数 × (保存するロ
グファイルの世代数 ＋ 1)
[Java EE共通ディレクトリ]/nodeagents/ijna/サーバーインスタ
ンス名/logs/http
Interstage Java EE DASサービスのHTTPアクセスログ
[Java EE共通ディレクトリ]\domains\interstage\logs\http
[Java EE共通ディレクトリ]/domains/interstage/logs/http
※1回あたりの出力サイズは、形式で
指定した項目によって変動しますが、
通常は、ログファイル1つにつき約
0.0001Mバイト～0.0010Mバイト程度
です。
※1日あたりの採取回数は、コマンド
起動時に指定された採取間隔により
決まります。
採取間隔の指定単位は1分のため、
「1440÷採取間隔」で1日あたりの採
取回数を求めることができます。
※ログファイルのサイズは、ログ設定
で指定したログファイルのサイズで
す。
※保存するログファイルの世代数
は、ログ設定で指定したログファイル
の世代数です。
1.1.2 マルチサーバ管理を使用する場合
マルチサーバ管理を使用する場合、以下に示すディスク容量が追加で必要です。
■管理サーバ機能を使用する場合
管理サーバ機能を使用する場合は以下にあげる項目に関するディスク容量が必要です。ディレクトリおよび容量については“1.1.1
サーバ機能を使用する場合”の同一項目名の記述を参照してください。
・ Interstage管理コンソール
- 18 -
・ Interstage HTTP Server
・ Interstage ディレクトリサービス
・ Interstage JMXサービス
・ 業務構成管理
また、以下のディスク容量も必要です。
ディレクトリ
(デフォルト)
ディスク容量
(単位:Mバイト)
Interstage JMXサービスのインストールディ
レクトリ\var\ssv_ijs
備考(用途)
配備するアプリケーションのサイ
ズ×2
Interstage管理コン
ソールからのアプリ
ケーションの配備
(注)
Interstage管理コン
ソールからのログ参照
/var/opt/FJSVisjmx/ssv_ijs
Interstage管理コンソールのインストールディ
レクトリ\isAdmin\var\download
/var/opt/FJSVisgui/tmp/download
注)
Interstage管理コンソールの以下の統合管理画面において、ログファイルをダウンロードする場合、同時にダウンロードするログファイ
ルのサイズ分のディスク容量が一時的に必要となります。
機能
Interstage HTTP Server
画面(スタンドアロン)
[統合管理] > [Interstage管理コンソール] > [Interstage Application
Server] > [サーバグループ名] > [サーバ名] > [システム] > [サービス]
> [Webサーバ] > [FJapache] > [ログ参照]タブ
[統合管理] > [Interstage管理コンソール] > [Interstage Application
Server] > [サーバグループ名] > [サーバ名] > [システム] > [サービス]
> [Webサーバ] > [FJapache] > [バーチャルホスト] > [バーチャルホスト
名] > [ログ参照]タブ
Webサーバコネクタ
[統合管理] > [Interstage管理コンソール] > [Interstage Application
Server] > [サーバグループ名] > [サーバ名] > [システム] > [サービス]
> [Webサーバ] > [FJapache] > [Webサーバコネクタ] > [ログ参照]タブ
IJServerワークユニット
[統合管理] > [Interstage管理コンソール] > [Interstage Application
Server] > [サーバグループ名] > [サーバ名] > [システム] > [ワークユ
ニット] > [ワークユニット名] > [ログ参照]タブ
ログファイルのサイズについては、各機能のログ情報のディスク容量を参照し、運用の内容により必要とするサイズを検討してください。
なお、ログファイルのサイズが大きいため、ディスク容量の不足によりログファイルのダウンロードに失敗する場合は、FTPなどを使用
してダウンロードしてください。
注意
管理サーバ機能は、以下の製品で利用可能です。
・ Interstage Application Server Enterprise Edition
- 19 -
■管理対象サーバとして運用する場合
管理対象サーバとして運用する場合は、使用する機能に関するディスク容量が必要です。ディレクトリおよび容量については“1.1.1
サーバ機能を使用する場合”の同一項目名の記述を参照してください。
また、以下のディスク容量も必要です。
ディレクトリ
(デフォルト)
ディスク容量
(単位:Mバイト)
備考(用途)
サイトへ追加される場
合
1
Interstage JMXサービスのインストールディ
レクトリ\etc
/etc/opt/FJSVisjmx
■共存サーバとして運用する場合
共存サーバでは管理サーバ機能とInterstageのサーバ機能(管理対象サーバ)が同一マシン上で動作しています。上記の記事を参照
して、管理サーバ機能とInterstageのサーバ機能で使用するサービスを列挙してください。各サービスが必要とするディスク容量は“1.1.1
サーバ機能を使用する場合”の同一項目名の記述を参照してください。
注意
管理サーバ機能とInterstageのサーバ機能で同一サービスを使用する場合、そのサービスの必要資源量を2倍する必要はありませ
ん。
1.1.3 MQ連携サービスを使用する場合
本ソフトウェアの動作時に必須となる動的ディスク所要量の詳細は、“MQ連携サービス 説明書”の“MQDBRIDGEシステム向け
Interstage環境の作成”を参照してください。
1.1.4 クライアント機能を使用する場合
本ソフトウェアを以下の運用で動作させるとき、各ディレクトリにはインストールに必要な“静的ディスク資源”に加えて以下のディスク
容量が必要です。空き容量が足りない場合は、該当するファイルシステムのサイズを拡張してください。
機能: CORBAサービス
注) Interstage Web Serverでは、本機能を使用できません。
ディレクトリ
ディスク容量
(単位:Mバイト)
備考(用途)
/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で設定することができます。アプリケーション
- 20 -
ごとにJVxxxxxxxxxx.log/JVxxxxxxxxxx.old(xxxxxxxxxxは一意の数字)の名前で採取されます。なお、ログファイルは、不要になっ
た時点で、削除してください。
機能: Portable-ORB
注) Interstage Web Serverでは、本機能を使用できません。
ディレクトリ
/var/opt (注)
ディスク容量
(単位:Mバイト)
備考(用途)
“ログファイルサイズ”×2×動作
するアプリケーション/アプレット
数
porbeditenvコマンドで“ログ情報
を採取”を指定した場合のログ
情報
注)
アプレットとして動作する場合は、アプレットが動作するクライアントマシン上のローカルディスクに、porbeditenvコマンドで“ログ格
納ディレクトリ”として指定したディレクトリとなります。
1.2 メモリ容量
本ソフトウェアを動作させるために必要なメモリ容量は次のとおりです。
注意
動作させるために必要なメモリ容量が確保されていない場合、動作に不具合が生じる場合があります。
1.2.1 サーバ機能を使用する場合
注) Interstage Web Serverでは、以下の機能を使用できます。
・ Interstage管理コンソール
・ Interstage HTTP Server
・ IJServerワークユニット(“Webアプリケーションのみ運用”)
・ CORBAサービス
以下の各機能を使用する場合のメモリ所要量を示します。
・ Interstage管理コンソール
・ Interstage HTTP Server
・ Interstage JMXサービス
・ Interstage シングル・サインオン
・ Interstage ディレクトリサービス
・ IJServerワークユニット
・ Session Registry Server
・ CORBAサービス(Interstage Web Serverの場合)
・ CORBAサービス
・ イベントサービス／ノーティフィケーションサービス
・ Portable-ORB
・ コンポーネントトランザクションサービス
・ データベース連携サービス
- 21 -
・ ロードバランス
・ セション情報管理機能
・ MessageQueueDirector
・ フレームワーク
・ Java EE
機能: Interstage管理コンソール
備考
メモリ所要量(単位:Mバイト)
121.0 以上
機能: Interstage HTTP Server
備考
メモリ所要量(単位:Mバイト)
HTMLファイルを複数クラ
イアント同時アクセス時
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ファイル同時アクセス数
機能: Interstage JMXサービス
備考
メモリ所要量(単位:Mバイト)
(注)
90.0 以上
81.3 以上
270.0 以上
130.0 以上
200.0 以上
注)
下段はWindows Server(R) 2003 x64 Editionsを使用した場合の所要量です。
機能: Interstage シングル・サインオン
備考
メモリ所要量(単位:Mバイト)
10.0 以上 (注1)
業務サーバ機能
10.0 以上 (注2)
認証サーバ機能
10.0 以上 (注3)
リポジトリサーバ機能
注1)
運用に応じて以下の式で見積もった値を加算してください。(単位:バイト)
－ (2,400 ＋ (ロール数 ＋ ロールセット数 ＋ (ロールセット数 × ロール数)) × 2,048以上) × パス定義数 + 業務サーバ数 ×
(2,000,000 ＋ キャッシュサイズ × キャッシュ数)
ロール数
: SSOリポジトリに定義した保護リソースの、チューニングを行う業務サーバのパス定義に設定したロールの総数
ロールセット数 : SSOリポジトリに定義した保護リソースの、チューニングを行う業務サーバのパス定義に設定したロールセットの総数
パス定義数 : SSOリポジトリに定義した保護リソースの、チューニングを行う業務サーバのパス定義の総数
- 22 -
キャッシュサイズ: “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
機能: Interstage ディレクトリサービス
備考
メモリ所要量(単位:Mバイト)
340.0 以上 (注1)
150.0 以上 (注1)
217.0以上 (注1)
スタンドアロン、データ
ベース共用、またはスレー
ブで運用する場合 (注2)
50.0 以上
(前項のスタンドアロンで運用する場合に加えて必要となる値)
マスタで運用する場合 (注
2)
2.0 以上
エントリ管理コマンドを使
用する場合
22.0 以上
60.0 以上
60.0 以上
m×n×3
m: 1エントリの登録に使用したLDIFファイルのサイズ
n: 検索により通知されるエントリ数
エントリ管理ツールを使用
する場合
Interstage ディレクトリサー
ビス SDK
検索時
注1)
リポジトリを複数作成して運用する場合は、リポジトリ数を乗算してください。
注2)
表中の“マスタ”、および“スレーブ”は、リポジトリのデータベースに標準データベースを使用したレプリケーション形態で運用する
場合の、マスタ、およびスレーブサーバについて説明しています。
リポジトリのデータベースにRDBを使用したレプリケーション形態で運用する場合の、マスタ、およびスレーブサーバのメモリ所要
量は、スタンドアロンで運用する場合と同じです。
- 23 -
機能: IJServerワークユニット
“WebアプリケーションとEJBアプリケーションを同一JavaVMで運用”時 (注1)(注2)
メモリ所要量(単位:Mバイト)
(*)
59.6 以上
56.5 以上
107.4 以上
90.2 以上
備考(以下のサンプルアプリケーションを
運用した場合)
EjbBmp(Web,Session,BMP)
114.3 以上
62.1 以上
56.6 以上
108.7 以上
65.8 以上
EjbCmp11(Web,Session,CMP1.1)
115.1 以上
65.8 以上
61.2 以上
114.7 以上
89.9 以上
EjbCmp20(Web,Session,CMP2.0)
118.8 以上
71.6 以上
66.2 以上
119.2 以上
99.6 以上
EjbMessageDriven(Web,Session,MDB)
125.3 以上
*) 下段はWindows Server(R) 2003 x64 Editionsを使用した場合の所要量です。
“Webアプリケーションのみ運用”時 (注1)
メモリ所要量(単位:Mバイト)
(*)
51.6 以上
53.1 以上
97.7以上
81.4 以上
備考(以下のサンプルアプリケーションを
運用した場合)
HelloServlet(Web)
94.4 以上
*) 下段はWindows Server(R) 2003 x64 Editionsを使用した場合の所要量です。
“EJBアプリケーションのみ運用”時 (注2)
メモリ所要量(単位:Mバイト)
(*)
54.3 以上
55.8 以上
98.2 以上
87.7 以上
備考(以下のサンプルアプリケーションを
運用した場合)
EjbBmp(Session,BMP)
106.3 以上
55.8 以上
55.9 以上
100.9 以上
86.4 以上
EjbCmp11(Session,CMP1.1)
107.6 以上
57.9 以上
58.6 以上
107.9 以上
86.4 以上
EjbCmp20(Session,CMP2.0)
- 24 -
メモリ所要量(単位:Mバイト)
(*)
備考(以下のサンプルアプリケーションを
運用した場合)
111.8 以上
59.8 以上
60.2 以上
109.9 以上
96.9 以上
EjbMessageDriven(Session,MDB)
118.3 以上
*) 下段はWindows Server(R) 2003 x64 Editionsを使用した場合の所要量です。
注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)
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、Interstage Application
Server Standard-J Editionで運用可能です。
ServletはJava VM上で動作するため、実際のメモリ使用量(ヒープ領域を含む)は、以下に示す要因により異なります。
－ newするクラス型
－ newするインスタンスの個数
－ インスタンスのライフサイクル
- 25 -
－ 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バイトです。
2. Java VMが使用するメモリ量の最大値(javaコマンドの-Xmxオプションで指定する値)
EJBアプリケーションを、本番運用のピーク時と同一条件で動作させます。Java VMが使用するメモリ量(最大値)が不足する
と、IJServer21033またはEJB1033メッセージが出力されますので、試行錯誤によりメモリ量(最大値)を最適な値としてくださ
い。このようにして求めたメモリ量(最大値)をそのまま本番運用時のメモリ量(最大値)として利用します。メモリ量(最大値)の
省略値は64Mバイトです。
3. 1プロセスで必要な全メモリ量
1)と2)でJava VMが使用するメモリ量を見積り時、同時に1プロセスで必要な全メモリ量も実測して見積もってください。
機能: Session Registry Server
備考
メモリ所要量(単位:Mバイト)
(例)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: セション数
- 26 -
例: 対象とする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が使用するメモリが不足すると、イベントログにメッセージが出力さ
れますので、ヒープ領域の最大値を増やして、最適な値としてください。求めたヒープ領域の最大値をそのまま本番運用時の
値として利用します。
なお、Session Registry Serverは、Interstage Application Server Enterprise Editionで運用可能です。
機能: CORBAサービス(Interstage Web Serverの場合)
メモリ所要量(単位:Mバイト)
備考
メモリ所要量(単位:Mバイト)
備考
32.0 以上
機能: CORBAサービス
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バイト以上のメモリが必要となります。
- 27 -
注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)
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
列挙型メンバ数
列挙型宣言でのメンバ数
機能: イベントサービス／ノーティフィケーションサービス
備考
メモリ所要量(単位:Mバイト)
16.0 以上
8.0 以上
8.0 以上
ユニット数 × 100 ＋
イベントサービスのユニット定義ファイルのshmmaxの合計
不揮発チャネル運用時
- 28 -
備考
メモリ所要量(単位:Mバイト)
(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)
(メッセージ本文のサイズ＋(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)
イベントサービスの形式については、“アプリケーション作成ガイド（イベントサービス編）”の“イベントデータの形式”を参照してく
ださい。
機能: Portable-ORB
備考
メモリ所要量(単位:Mバイト)
1.5 以上
3.0 以上
機能: コンポーネントトランザクションサービス
備考
メモリ所要量(単位:Mバイト)
48.0 以上 (注1)
50.0 以上 (注2)
－
4.0 以上 (注3)
サービスの起動
注1)
この値はCORBAサービスのメモリ容量を含んでいませんので、加算してください。
注2)
ユーザ認証機能を使用する場合は、0.9Mバイト加算してください。
アクセス制御を使用する場合は、0.6Mバイト加算してください。
- 29 -
注3)
1つのワークユニットでプロセス多重度を1とした場合の値です。
詳細は以下の式で見積もってください。
－ 4.0 × ワークユニット配下のプロセス数の総和
機能: データベース連携サービス
備考
メモリ所要量(単位:Mバイト)
サービスの起動
(データベース連携サービ
ス動作マシン)
54.0 ＋ 0.010 × m ＋ 43.0 × n 以上
64.0 ＋ 0.011 × m ＋ 32.0 × n 以上
30.0 ＋ 0.010 × m ＋ 75.0 × n 以上
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の総数
機能: ロードバランス
備考
メモリ所要量(単位:Mバイト)
2.0
機能: セション情報管理機能
備考
メモリ所要量(単位:Mバイト)
7.0 以上
機能: MessageQueueDirector
注) MQDシステムが複数ある場合には、それぞれのMQDシステムについて見積もった値の合計が所要量になります。
備考
メモリ所要量(単位:Mバイト)
基本機能使用時
100.0 ＋ m ＋ s ÷ 1000 以上
100.0 ＋ m
m: MQD環境定義のMQDConfigurationセクションの
MessageBufferMaxSize
s: MQD環境定義のMemoryQueueセクションのsize
- 30 -
メモリ所要量(単位:Mバイト)
備考
39.0 ＋ sc × 0.3 ＋ rc × 0.3 以上
sc: イベントチャネル連携サービスのCHANNELセクション定義数
rc: イベントチャネル連携サービスのRCHANNELセクション定義全部の
総集信数
イベントチャネル連携サー
ビス使用時
同報配信サービス使用時
10.0 以上
SMTP連携サービス使用
時
305 ＋ sq × 0.2 ＋ rq × 0.1 ＋ メッセージ長 以上
sq: SMTP連携サービス定義中の送信メッセージキュー数
rq: SMTP連携サービス定義中の受信メッセージキュー数
機能: フレームワーク
備考
メモリ所要量(単位:Mバイト)
Application Serverが使用するメモリ使用量 ＋ 32.0
備考
メモリ所要量(単位:Mバイト)
サンプル“model”を実行し
た場合
2.9 [参考値] (注)
注)
フレームワークを使用して作成した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:
- 31 -
使用するプラットフォームにより異なります。数値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クラスタ数およびサーバーインスタンス数
の削減を検討してください。
上限を超え、Interstage Java EE DASサービスが起動できない場合は、IJServerクラスタを削除してください。削除手順は「トラブ
ルシューティング集」－「運用環境に関する異常」を参照してください。
1.2.2 マルチサーバ管理を使用する場合
マルチサーバ管理を使用する場合、以下に示すメモリ容量が追加で必要です。
■管理サーバ機能を使用する場合
管理サーバ機能を使用する場合は以下にあげる項目に関するメモリ容量が必要です。容量については“1.2.1 サーバ機能を使用す
る場合”の同一項目名の記述を参照してください。
・ Interstage管理コンソール
・ Interstage HTTP Server
・ Interstage ディレクトリサービス
・ Interstage JMXサービス
管理サーバ機能は以下の製品で利用可能です。
・ Interstage Application Server Enterprise Edition
■管理対象サーバとして運用する場合
管理対象サーバとして運用する場合は、使用する機能に関するメモリ容量が必要です。容量については“1.2.1 サーバ機能を使用す
る場合”の同一項目名の記述を参照してください。
■共存サーバとして運用する場合
共存サーバでは管理サーバ機能とInterstageのサーバ機能(管理対象サーバ)が同一マシン上で動作しています。上記の記事を参照
して、管理サーバ機能とInterstageのサーバ機能で使用するサービスを列挙してください。各サービスが必要とするメモリ容量は“1.2.1
サーバ機能を使用する場合”の同一項目名の記述を参照してください。
管理サーバ機能とInterstageのサーバ機能で同一サービスを使用する場合、そのサービスの必要資源量を2倍する必要はありませ
ん。
1.2.3 クライアント機能を使用する場合
本ソフトウェアを以下の運用で動作させるときに使用するメモリ容量を示します。
- 32 -
機能: Interstage ディレクトリサービス
注) Interstage Web Serverでは、本機能を使用できません。
備考
メモリ所要量(単位:Mバイト)
22.0 以上
エントリ管理ツールを使用する場合
- 33 -
第2章 Interstageのチューニング
Interstageはシステム規模の指定だけで、システム運用が可能となるようなモデルケースを設定して各サービスの定義を登録していま
す。しかし、システムによっては、より詳細なシステム構築が必要となります。
Interstageをチューニングする場合は、isregistdefコマンドで各サービスの定義を登録した後で実施してください。チューニングした内
容はInterstageの初期化機能で有効となり、Interstageの起動で反映されます。
Interstageのチューニングは、以下の定義ファイルに対して行います。
・ Interstage動作環境定義
・ CORBAサービスの動作環境ファイル
・ コンポーネントトランザクションサービスの環境定義 (注)
・ データベース連携サービスのシステム環境定義
注) 本定義は、Interstage Application Server Enterprise Editionのみです。
2.1 想定するシステム形態
2.1.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層モデルです。
- 34 -
上記のモデルを使用する場合のチューニングポイントとしては、以下があります。
・ 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.1.2 想定するシステム形態（マルチ言語サービス）
Interstageの初期化時に、トランザクションアプリケーションを使用した連携をモデルケースとして設定しています。
トランザクションアプリケーションを利用した連携は、以下のとおりです。
・ ローカルトランザクション連携
・ グローバルトランザクション連携
・ セション管理を利用した連携
・ 既存システム(グローバルサーバ)との連携 (注)
注) Interstage Application Server Enterprise Editionでのみ連携できます。
トランザクションアプリケーションは、以下の条件で設計しています。
・ すべてのトランザクションアプリケーションは、他サーバ(自システム内の連携も含みます)と連携することを想定しています。
・ トランザクションアプリケーションのオブジェクトのプロセス数は、最大接続クライアント数の10分の1です。
・ トランザクションアプリケーションのオブジェクトから接続するサーバマシンは、1台です。
- 35 -
・ リソースはサーバマシンに1つ、リソース管理プログラムの多重度は5です。
・ データベース連携サービスの多重度は5、リカバリプログラムの多重度は2です。
CORBAアプリケーションの運用、ロードバランス、サーバマシン状態監視を使用する場合は、Interstageのチューニングが必要です。
2.2 定義ファイルの設定値
各定義ファイルには、Interstageシステム定義のSystem Scaleステートメントに設定されているシステム規模に応じた値が設定されま
す。
システム規模には、以下の4種類があり、isgendefコマンドでInterstageシステム定義を生成する際に指定します。isgendefコマンドの詳
細については、「リファレンスマニュアル(コマンド編)」の「isgendef」を参照してください。
・ small（小規模システム）
・ moderate（中規模システム）
・ large（大規模システム）
・ super（超大規模システム）
なお、インストール直後のセットアップ環境では、以下のシステム規模が設定されています。
・
large（大規模システム）
・
small（小規模システム）
各定義ファイルに設定される値を以下に示します。
・ Interstage動作環境定義の“FJapache”は、Interstage Application Server Enterprise Editionのみ有効です。
・ コンポーネントトランザクションサービスの環境定義は、Interstage Application Server Enterprise Editionのみ有効です。
■システム規模ごとの設定値
定義名
ステートメント
値(System Scaleごとの)
small
Interstage動作環境
定義
Corba Host Name
ありません。
Corba Port Number
ありません。
moderate
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
- 36 -
large
super
定義名
ステートメント
値(System Scaleごとの)
small
NS JP
moderate
large
super
no
NS Locale
SJIS
EUC
LBO USE
no
TD path for system
TD_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
10
50
100
50
100
500
1000
5
10
50
100
50
100
500
1000
OTS Setup mode
sys
OTS JTS's RMP Multiple degree of
Process
5
OTS JTS's RMP Multiple degree of
Thread
16
OTS Participate
4
OTS Host
ありません。
OTS Port
ありません。
OTS Locale
ありません。
Event Service
no
Event maximum Process
2
Event maximum Connection
Event Locale
SJIS
EUC
Event Auto Disconnect
no
Event SSL
no
SSL USE
no
SSL Port Number
4433
- 37 -
定義名
ステートメント
値(System Scaleごとの)
small
CORBAサービスの
動作環境ファイル (注
5)
IS Monitor Mode
mode2
FJapache
no
moderate
large
super
max_IIOP_resp_con
33
40
100
175 (注6)
80
135
575
1024
772
896
1920
3968
1920
2944
10112
20352
29
31
51
76
31
36
76
126
448
448
448
448
1046
2046
large
super
max_IIOP_resp_requests
max_processes
max_exec_instance
コンポーネントトラン
ザクションサービスの
環境定義
[SYSTEM ENVIRONMENT]
System Scale
small
データベース連携
サービスの環境定義
ありません。
ありません。
moderate
注1)
TD_HOME:Interstageのインストールフォルダ\td
注2)
TD_HOME:コンポーネントトランザクションサービスのインストールディレクトリ
注3)
運用形態が「TYPE3」の場合は、必ず指定してください。
注4)
運用形態が「TYPE2」の場合は、必ず指定してください。
注5)
CORBAサービスの動作環境ファイル内の値に表中の値がisregistdefコマンド実行時に加算されます。また、isregistdefコマンドの
投入が初回でない場合は、前回のコマンド投入時に加算した値を、現在設定されている値から減算し、新たに指定したSystem Scale
の値が加算されます。詳細については、“■CORBAサービスの動作環境ファイルの設定について”を参照してください。
注6)
1024以上の値は、設定できません。
- 38 -
■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.3 チューニング方法
2.3.1 チューニング方法(Java EE)
特にシステムとしてチューニングする項目はありません。業務運用するサーバーインスタンスの各種チューニングを実施してください。
2.3.2 チューニング方法(マルチ言語サービス)
2.3.2.1 チューニング方法(アプリケーション追加によるチューニング)
クライアントアプリケーション、サーバアプリケーションを追加する場合に修正する各サービスの定義のステートメントと加算する値を説
明します。
- 39 -
なお、追加するアプリケーションがCORBAアプリケーションかトランザクションアプリケーションにより加算する値は異なります。
以下に示すアプリケーションを追加した場合のチューニング方法について説明します。
・ クライアントアプリケーションを追加した場合
・ サーバアプリケーションを追加した場合 (注)
・ クライアント、サーバ兼用アプリケーションを追加した場合 (注)
注) 本項目は、Interstage Application Server Enterprise Edition、およびStandard-J Editionにおいてチューニングを行う必要があります。
2.3.2.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.3.2.1.2 サーバアプリケーションを追加した場合
CORBAアプリケーション
定義名
CORBAサービスの
動作環境ファイル
ステートメント
加算値
max_processes (注)
プロセス数の合計
max_exec_instance
リクエスト実行用スレッドの合計
注)
max_processesを変更した場合は、システムパラメタの設定が必要です。
EJBアプリケーション
定義名
CORBAサービスの
動作環境ファイル
ステートメント
max_processes (注)
加算値
追加するEJBアプリケーションのプロセス数
max_exec_instance
・ EJBアプリケーション作成の際に、スレッ
ド動作可としている場合
追加するEJBアプリケーションのプロセ
ス数 × 16
- 40 -
定義名
ステートメント
加算値
・ EJBアプリケーション作成の際に、スレッ
ド動作不可としている場合
追加するEJBアプリケーションのプロセ
ス数
追加するEJBアプリケーションのプロセス
数 × 16
注)
max_processesを変更した場合は、システムパラメタの設定が必要です。
トランザクションアプリケーション
考慮の必要はありません。
2.3.2.1.3 クライアント、サーバ兼用アプリケーションを追加した場合
サーバアプリケーションから他のオブジェクトを呼び出したり、オブジェクトリファレンスを獲得したり、セション管理機能、XA連携など
を使用する場合など、CORBAクライアントとしても動作するアプリケーションを示します。
CORBAアプリケーション
定義名
CORBAサービスの
動作環境ファイル
ステートメント
max_processes (注1)
加算値
プロセス数の合計
max_IIOP_resp_con (注1)(注2)
max_exec_instance
リクエスト実行用スレッドの合計
注1)
max_processes、max_IIOP_resp_conを変更した場合は、システムパラメタの設定が必要です。
注2)
SSL接続のコネクションとSSL接続でないコネクションは別コネクションとして数える必要があります。そのため、SSL連携機能を使用
する場合、加算値は“プロセス数の合計 × 2”となります。
トランザクションアプリケーション
定義名
CORBAサービスの
動作環境ファイル
ステートメント
max_processes (注1)
加算値
プロセス数の合計
max_IIOP_resp_con (注1)(注2)
注1)
max_processes、max_IIOP_resp_conを変更した場合は、システムパラメタの設定が必要です。
注2)
SSL接続のコネクションとSSL接続でないコネクションは別コネクションとして数える必要があります。そのため、SSL連携機能を使用
する場合、加算値は“プロセス数の合計 × 2”となります。
2.3.2.2 チューニング方法(Interstageの機能を使用するためのチューニング)
Interstageの機能を使用する場合のチューニング方法について説明します。
以下の表を参照し、使用する製品に応じて、以降に示すサービスのチューニングを行ってください。
- 41 -
Interstage Application
Server Enterprise Edition
Interstage Application
Server Standard-J
Edition
Interstage Web Server
データベース連携サービス
○
○
×
ロードバランス
○
×
×
イベントサービス (注)
○
○
×
サーバマシン状態監視
○
×
×
○:チューニングを行う必要があります。
×:チューニングを行う必要はありません(該当製品では、サービスが使用できないため)。
注) Interstage JMSを使用する場合、イベントサービスのチューニングを行う必要があります。
2.3.2.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)
加算、設定値
リカバリプログラムの多重度
max_exec_instance (注2)
注1)
値を設定します。
注2)
値を加算します。
リソース管理プログラムのチューニング
リソース管理プログラムを複数起動する場合または、リソース管理プログラムの多重度を変更する場合は以下の値を加算します。
- 42 -
定義名
CORBAサービスの
動作環境ファイル
ステートメント
加算値
(リソース管理プログラムの多重度 ＋ 1)の合
計
max_processes (注)
max_IIOP_resp_con (注)
max_exec_instance
注)
max_processes、max_IIOP_resp_conを変更した場合は、システムパラメタの設定が必要です。
2.3.2.2.2 ロードバランス
ロードバランス機能を使用する場合は、以下の値を加算します。
定義名
CORBAサービスの
動作環境ファイル
ステートメント
max_processes (注)
加算値
定数: 1
max_IIOP_resp_con (注)
max_exec_instance
odsetlboコマンドの-mオプションに指定した値
注)
max_processes、max_IIOP_resp_conを変更した場合は、システムパラメタの設定が必要です。
2.3.2.2.3 イベントサービス
イベントサービスを使用する場合は、以下の値を設定または加算します。
定義名
CORBAサービスの
動作環境ファイル
ステートメント
加算、設定値
max_exec_instance
(注2)
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コネクションで同時に接続(受
信)できるリクエスト数
max_IIOP_resp_con (注1)
すべてのイベントチャネルに接続するコン
シューマ・サプライヤの合計値 ＋ 1 (注4)
max_IIOP_resp_requests
以下のいずれかの最大値
・ max_IIOP_resp_conの加算値 × (mixモ
デルのコンシューマ／サプライヤが1コネ
クションで同時に接続(送信)できるリクエ
スト数 ＋ 1)
- 43 -
定義名
ステートメント
加算、設定値
・ 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”として計算してください。
－ イベントチャネル側(イベントファクトリを使用する場合)
「イベントチャネルの最大プロセス数(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を加算してください。
- 44 -
注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.3.2.2.4 サーバマシン状態監視
サーバマシン状態監視機能を使用する場合は、以下の値を加算します。
監視サーバのチューニング
定義名
ステートメント
CORBAサービスの動作環境ファ
イル
加算値
定数: 1
max_processes (注)
max_IIOP_resp_con (注)
定数: 4
max_exec_instance
注)
max_processes、max_IIOP_resp_conを変更した場合は、システムパラメタの設定が必要です。
被監視サーバのチューニング
定義名
ステートメント
CORBAサービスの動作環境ファ
イル
加算値
定数: 1
max_processes (注)
max_IIOP_resp_con (注)
max_exec_instance
注)
max_processes、max_IIOP_resp_conを変更した場合は、システムパラメタの設定が必要です。
2.4 環境変数について
以下にInterstageで使用する環境変数を示します。
環境変数名
OD_HOME
用途
CORBAサービスのインストールパスを指定します。
例)
OD_HOME=Interstageのインストールフォルダ\ODWIN
- 45 -
環境変数名
用途
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画面でトランザクションリストを表示
する行数を指定します。
例) 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の動作環境ファイル検索時にも使用)
- 46 -
環境変数名
用途
例)
PORB_HOME=Portable-ORBのインストールフォルダ
PORB_HOME=/opt/FJSVporb
IS_ISSTOP_MONITOR_TI
MER
Interstage 停止やワークユニット停止が無応答になる現象が発生した場合、自
動的にトラブル調査資料を採取する内部機構において、調査資料を採取する
までの監視時間を変更する場合に秒単位で設定します。環境変数を指定しな
い場合はデフォルト5分の監視時間となります。Interstage 停止やワークユニッ
ト停止をコマンドで行う場合には、監視時間はisstopおよびisstopwuコマンド
の-t オプションで指定可能です。環境変数の指定より、コマンドのオプション指
定が優先されます。本環境変数は必須ではありません。無応答になるトラブル
が発生して資料の採取が必要な際に、デフォルトの監視時間を変更したい場
合のみ設定してください。
本環境変数はブート時に取得可能なシステム環境変数として設定してくださ
い。つまり、本環境変数を有効とするには、システム環境変数として設定した
後にOSの再起動が必要です。
isstartコマンドでInterstageを起動する場合には、コマンドを入力する前に環境
変数を設定してください。rcプロシジャからInterstageを起動する場合には、rc
プロシジャ内で設定してください。管理コンソールからInterstageを起動する場
合には、システムの環境変数として設定してください。
2.5 IPv6環境での運用について
Interstageでは、IPv6環境での運用が可能です。IPv6環境での運用方法を説明します。(注)
注) InterstageはIPv6/IPv4デュアルスタックのみをサポートしています。InterstageはIPv6/IPv4デュアルスタックで利用してください。IPv4
を無効にした場合の運用はサポートしておりません。
■運用可能なプラットフォーム
以下の機能は、Windows(R)、Solaris、およびLinuxでIPv6環境での運用が可能です。その他の機能は、Solarisだけで運用可能で
す。
・ CORBAサービス
・ データベース連携サービス
・ イベントサービス
・ Interstage HTTP Server
・ Interstage シングル・サインオン
・ Interstageディレクトリサービス
■運用可能なサービス
IPv6環境において、Interstageの以下の機能が使用できます。
・ CORBAサービス(SSL連携、Proxy連携機能を除く)
IPv6環境でのCORBAアプリケーション連携(IIOP通信)ができます。
- 47 -
・ コンポーネントトランザクションサービス(Interstage Web Serverは除く。また、サーバマシン状態監視機構、IPCOM連携を利用した
負荷分散を除く)
IPv6環境でのトランザクションアプリケーション連携ができます。
・ データベース連携サービス(Interstage Web Serverは除く)
IPv6環境でデータベース連携サービスを利用することができます。
・ イベントサービス(Interstage Web Serverは除く)
IPv6環境でイベントサービスを利用することができます。
・ MessageQueueDirector(Interstage Application Server Enterprise Editionのみ)
IPv6環境でMessageQueueDirectorの運用が可能です。
・ Interstage HTTP Server
IPv6環境でのHTTP/HTTPS通信を行うことが可能です。
・ Interstage シングル・サインオン
IPv6環境でInterstage シングル・サインオンを利用することが可能です。
・ Interstageディレクトリサービス
■運用方法
InterstageをIPv6環境で運用するには、以下のサービスの環境設定が必要です。その他のサービスでは、特別な設定は不要です。
・ pingコマンドなどを実行して対象ホストとの通信が可能であるかの確認をしてください。通信ができない場合は、OSのルーティング
の設定の確認をお願いします。設定方法の詳細については、OSのマニュアルおよびヘルプを参照してください。今後、サイトロー
カルアドレスはOSの機能としてサポートされなくなる可能性があります。そのため、サイトローカルアドレスは使用しないことを推奨
します。
・ IPv6環境でリンクローカルアドレスまたはサイトローカルアドレスを用いて通信を行う際には、scope-idを意識する必要があります。
・ Interstage Application Serverでは、リンクローカルアドレスを用いた通信をサポートしません。
CORBAサービスの環境設定
IPv6環境でCORBAアプリケーション連携を行う場合には、config(CORBAサービス)に以下を設定し、CORBAサービスを再起動
してください。
IP-version=v4-dual または v6 (デフォルト:v4-dual)
コンポーネントトランザクションサービス
IPv6環境でトランザクションアプリケーション連携を行う場合には、コンポーネントトランザクションサービスの環境定義ファイルに以
下の制御文を設定し、コンポーネントトランザクションサービスを再起動してください。
IP version:v6
(デフォルト:v4)
データベース連携サービス
IPv6環境でデータベース連携サービスを利用する場合は、CORBAサービスのIPv6環境を設定する必要があります。CORBAサー
ビスのIPv6環境の設定については、“CORBAサービスの環境設定”を参照してください。
- 48 -
イベントサービス
IPv6環境でイベントサービスを利用する場合は、CORBAサービスのIPv6環境を設定する必要があります。CORBAサービスのIPv6
環境の設定については、“CORBAサービスの環境設定”を参照してください。
MessageQueueDirector
MessageQueueDirectorではIPv6環境でSMTP連携サービスを使用する場合、サービス環境定義(MXHost)にIPv6形式のIPアドレ
ス(またはホスト名)を記述します。
詳細は、“MessageQueueDirector 説明書”を参照してください。
2.6 ホスト情報(IPアドレス/ホスト名)の変更方法について
Interstageを運用しているサーバのホスト情報(IPアドレスやホスト名)を変更する場合には、1台のサーバで、Interstageの資源移出と資
源移入を行うことで実施できます。資源移入時に、変更したいホスト情報を指定して資源移入の操作を行ってください。詳細について
は、“運用ガイド(基本編)”の“メンテナンス(資源のバックアップ/他サーバへの資源移行/ホスト情報の変更)”を参照してください。
- 49 -
第3章 システムのチューニング
この章では、システムチューニングについて説明します。
3.1 サーバ機能運用時に必要なシステム資源
Interstageの各サービスの運用に必要となるシステム資源について説明します。
以下の表を参照し、使用する製品に応じて、以降に示すサービスのチューニングを行ってください。各機能の説明を参照する前に
“■システムパラメタについて”を参照してください。
なお、システムパラメタを算出するためのExcelファイルがマニュアルCDの“ApplicationServer\tuning”配下のサブフォルダに“ISASIPCtuning.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)
EE : Interstage Application Server Enterprise Edition
SJE: Interstage Application Server Standard-J Edition
WS: Interstage Web Server
○:チューニングを行う必要があります。
×:チューニングを行う必要はありません(該当製品ではサービスが使用できないため)。
注1) Interstage JMSを使用する場合、イベントサービスのシステム環境を設定する必要があります。
注2) Interstage シングル・サインオンの業務サーバのシステム資源だけ設定します。
注3) Webサーバコネクタの故障監視機能のシステム資源を設定する必要はありません。
■システムパラメタについて
◆システムパラメタの変更方法
IPC資源のパラメタに値を設定するために、以下のいずれかの方法を選択してください。
・ /etc/systemファイルの修正
/etc/systemファイルを編集し、必要なパラメタ値を変更します。変更後は、変更した値を反映するためにシステムをリブートしてくだ
さい。なお、変更方法の詳細については、Solarisのドキュメントを参照してください。
注) Solaris 10以降において、この方法でシステムチューニングする場合、shmmaxおよびshmmniは以下の関係が成り立つような値
を設定してください。
- 50 -
project.max-shm-memory ＝ shmmax × shmmni
・ 資源制御(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あたりのセマフォの最大数
semopm
process.max-sem-ops
セマフォコールあたりのセマフォ操作の最大数
- 51 -
パラメタ
資源制御
意味
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
共用メモリセグメントの最大数
セマフォ
セマフォの設定値は、各パラメタ値を以下の形式で指定します。
－ kernel.sem = para1 para2 para3 para4
パラメタ
意味
para1
セマフォIDあたりのセマフォの最大数
para2
システム全体のセマフォの最大数
para3
セマフォコールあたりのセマフォ操作の最大数
- 52 -
パラメタ
意味
セマフォIDの最大数
para4
メッセージキュー
パラメタ
意味
kernel.msgmax
メッセージの最大サイズ
kernel.msgmnb
メッセージキュー上のメッセージの最大バイト数
kernel.msgmni
メッセージキューIDの最大数
ファイルディスクリプタ
パラメタ
意味
システム全体のファイルディスクリプタの最大数
fs.file-max
◆リソース制限
システムのリソースを制限するには、/etc/security/limits.confファイルを編集し、必要なパラメタ値を変更します。変更後は、変更した
値を反映するためにシステムをリブートしてください。
変更方法の詳細については、OSのドキュメントを参照してください。
「種類」の意味
リソース制限の表中の「種類」の意味は、以下のとおりです。
・ soft
ソフトウェアリミット値を変更してください。
・ hard
ハードウェアリミット値を変更してください。
各パラメタの意味
リソース制限のパラメタ名と意味は、以下のとおりです。
ファイルディスクリプタ
パラメタ
nofile
意味
ユーザにおいてオープン可能なファイルディスクリプタの最大数
3.1.1 CORBAサービスのシステム資源の設定
CORBAサービスを用いたシステムの運用時には、接続するクライアント/サーバ数、オブジェクト数などによりシステム資源を拡張する
必要があります。ここでは、以下について説明します。
・ システムパラメタ
－ CORBAサービス
－ インタフェースリポジトリ
－ ネーミングサービス
・ プロセス・スレッド
・ ファイルディスクリプタ
- 53 -
■システムパラメタ
一般的な CORBAサービスが使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニングについて説明します。
CORBAサービスの他に共用メモリ、セマフォ、メッセージキューを使用するアプリケーションが存在する場合、そのアプリケーションが
使用する資源にCORBAサービスの資源量を加算してください。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタの設定は、Solaris 10以降の場合のみ可能です。
CORBAサービス
CORBAサービスで必要となるシステム資源について、以下に示します。
各表に記述されているパラメタ名(max_IIOP_resp_conなど)は、CORBAサービスのconfigファイルで指定します。詳細については、
“A.1 config”を参照してください。
共用メモリ
パラメタ
shmmax(注
7)
資源制御
－
種類
設定値
必要数
[Solaris 9の場合]
以下の値のうち、最大値を指定します。
・ max_IIOP_resp_con × 16K ＋
(max_IIOP_resp_con_extend_number(注2) ＋ 1) × 0.2K ＋
max_IIOP_resp_requests × 16K ＋
(max_IIOP_resp_requests_extend_number(注2) ＋ 1) × 0.2K
＋
max_impl_rep_entries × 6K ＋
max_bind_instances(注8) × 0.1K ＋ 100K 以上
－ [trace_use=yesの場合]
上記値 ＋
max_processes × trace_size_per_process ＋
trace_size_of_daemon(注3) ＋ 20K 以上
－ [snap_use=yesの場合]
上記値 ＋ snap_size ＋ 10K 以上
・ number_of_common_buffer(注4) × 4K 以上 ＋
(number_of_common_buffer_extend_number( 注 2) ＋ 1) ×
0.2K
・ max_exec_instance × 0.15KB 以上
・ [Buffer Size、Buffer Number(ワークユニット定義)を指定した
CORBAワークユニット起動時]
(Buffer Size ＋ 0.2K) × Buffer Number 以上 (注5)
－
project.maxshm-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(注9) × 5K ＋
number_of_common_buffer_extend_number(注2) × 0.1K ＋
max_processes × 0.6K ＋
- 54 -
パラメタ
資源制御
種類
必要数
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(注8) × 0.1K ＋ 3,200K 以上
[SSL連携機能を使用する場合]
上記値 ＋ limit_of_max_IIOP_resp_con × 5K 以上
[トレース機能を使用する場合]
上記値 ＋ max_processes × trace_size_per_process ＋
trace_size_of_daemon(注3) ＋ 20K 以上
[スナップショット機能を使用する場合]
上記値 ＋ snap_size ＋
(max_impl_rep_entries ＋ max_processes) × 0.1K 以上
[CORBAワークユニットを使用する場合]
上記値 ＋ (Buffer Size ＋ 0.2KB) × Buffer Number ×
“Buffer Size、Buffer Number(ワークユニット定義)を指定したアプリ
ケーション数” (注5)
shmmni
project.maxshm-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が指定された場合も、以下と同様になります。Solaris 9の場合、
limit_of_[パラメタ名]は、0が指定された場合は自動計算されます。計算式の詳細については、“config”を参照してください。
(limit_of_[パラメタ名] － [パラメタ名]) ÷ [パラメタ名] (小数部分切り上げ)
isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場合は、0となりま
す。
注3)
デフォルトは以下です。0が指定された場合も、以下と同様になります。
trace_size_per_process × 32
注4)
デフォルトは以下です。0が指定された場合も、以下と同様になります。
max_IIOP_resp_requests × 0.2
注5)
Solaris 10以降の場合、Buffer Size、Buffer Numberを指定したCORBAワークユニット定義の中で、“(Buffer Size ＋ 0.2KB) × Buffer
Number”の最大値に、“Buffer Size、Buffer Number(ワークユニット定義)を指定したアプリケーション数”を積算した値が該当します。
Solaris 9の場合、Buffer Size、Buffer Numberを指定したCORBAワークユニット定義の中で、“(Buffer Size ＋ 0.2KB) × Buffer
Number”の最大値が該当します。
なお、“(Buffer Size ＋ 0.2KB) × Buffer Number”の最大値が 2,147,483,647より小さい値になるようにBuffer Size、Buffer Number
の値を設定してください。
- 55 -
注6)
マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。
マルチシステム機能はInterstage Application Server Enterprise Editionで使用できます。
注7)
Solaris 10以降でshmmaxを設定する場合、Solarisのドキュメントおよび“■システムパラメタについて”を参照して値を決定してくだ
さい。
注8)
デフォルトは以下です。0が指定された場合も、以下と同様になります。
max_processes × 1024 (計算結果が65,535を超えた場合は65,535)
注9)
デフォルトは以下です。0が指定された場合も、以下と同様になります。
limit_of_max_IIOP_resp_requests
共用メモリ
パラメタ
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)
[パラメタ名]_extend_numberのデフォルト値は以下となります。0が指定された場合も、以下と同様になります。limit_of_[パラメタ名]
は、0が指定された場合は自動計算されます。計算式の詳細については、“config”を参照してください。
(limit_of_[パラメタ名] － [パラメタ名]) ÷ [パラメタ名] (小数部分切り上げ)
isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場合は、0となりま
す。
- 56 -
注2)
デフォルトは以下です。0が指定された場合も、以下と同様になります。
trace_size_per_process × 32
注3)
デフォルトは以下です。0が指定された場合も、以下と同様になります。
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
の値を設定してください。
注5)
デフォルトは以下です。0が指定された場合も、以下と同様になります。
max_processes × 1024 (計算結果が65,535を超えた場合は65,535)
セマフォ
パラメタ
semmni
資源制御
project.maxsem-ids
種類
加算値
必要数
以下の値のうち、最大値を指定します。
・ 512
・ max_IIOP_resp_con_extend_number(注3) × 5 ＋
max_IIOP_resp_requests_extend_number(注3) ＋
max_impl_rep_entries ＋
プロセスモードのCORBAサーバアプリケーションの起動プロセ
ス数(注4) ＋
“Buffer Size、Buffer Number(ワークユニット定義)を指定したア
プリケーション数” × 2 ＋ 100 以上
semmns
(注1)
－
加算値
limit_of_max_IIOP_resp_con(注2) × 4 ＋
max_IIOP_resp_con_extend_number(注3) ＋
max_IIOP_resp_requests_extend_number(注3) ＋
max_impl_rep_entries ＋
max_processes × 3 ＋
プロセスモードのCORBAサーバアプリケーションの起動プロセス数
(注4) ＋
“Buffer Size、Buffer Number(ワークユニット定義)を指定したアプリ
ケーション数” × 2 ＋ 14 以上
[トレース機能を使用する場合]
上記値 ＋ 1 以上
[スナップショット機能を使用する場合]
上記値 ＋ 1 以上
[SSL連携機能を使用する場合]
上記値 ＋ limit_of_max_IIOP_resp_con(注2) 以上
semmnu
(注1)
－
加算値
max_impl_rep_entries ＋ max_processes × 3 ＋
“Buffer Size、Buffer Number(ワークユニット定義)を指定したアプリ
ケーション数” × 2 ＋ 6 以上
[トレース機能を使用する場合]
上記値 ＋ 1 以上
[スナップショット機能を使用する場合]
上記値 ＋ 1 以上
semmsl
process.maxsem-nsems
設定値
以下の値のうちの最大値以上の値を指定します。
- 57 -
パラメタ
資源制御
種類
必要数
・ max_IIOP_resp_con
・ max_processes
semopm
process.maxsem-ops
設定値
50 以上
semume
(注1)
－
加算値
limit_of_max_IIOP_resp_con(注2) × 3 ＋
max_IIOP_resp_con_extend_number(注3) ＋
max_IIOP_resp_requests_extend_number(注3) ＋
max_impl_rep_entries ＋
max_processes × 2 ＋
“Buffer Size、Buffer Number(ワークユニット定義)を指定したアプリ
ケーション数” × 2 ＋ 11 以上
[トレース機能を使用する場合]
上記値 ＋ 1 以上
[スナップショット機能を使用する場合]
上記値 ＋ 1 以上
[SSL連携機能を使用する場合]
上記値 ＋ limit_of_max_IIOP_resp_con(注2) 以上
semvmx(注
1)
－
設定値
以下の値のうち、最大値を指定します。
・ OSデフォルト値(32767)
・ Buffer Number(ワークユニット定義)の最大値
注1)
Solaris 9でのみ有効です。
注2)
limit_of_[パラメタ名]のデフォルト値は以下となります。0が指定された場合も、以下と同様になります。
[パラメタ名] × 1.3 (小数部分切り捨て)
isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場合は、[パラメタ
名]となります。
注3)
[パラメタ名]_extend_numberのデフォルト値は以下となります。0が指定された場合も、以下と同様になります。
(limit_of_[パラメタ名] － [パラメタ名]) ÷ [パラメタ名] (小数部分切り上げ)
isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場合は、0となりま
す。
注4)
起動プロセス数が分からない場合は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 ＋
- 58 -
パラメタ
種類
必要数
プロセスモードのCORBAサーバアプリケーションの起動プロセス数
(注3) ＋
“Buffer Size、Buffer Number(ワークユニット定義)を指定したアプリ
ケーション数” × 2 ＋ 14 以上
[トレース機能を使用する場合]
上記値 ＋ 1 以上
[スナップショット機能を使用する場合]
上記値 ＋ 1 以上
[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)
[パラメタ名]_extend_numberのデフォルト値は以下となります。0が指定された場合も、以下と同様になります。
(limit_of_[パラメタ名] － [パラメタ名]) ÷ [パラメタ名] (小数部分切り上げ)
isconfig.xmlファイルの定義項目AutoConfigurationModeにMANUALを指定し、自動拡張を行わない設定にした場合は、0となりま
す。
注3)
起動プロセス数が分からない場合はmax_processesを指定してください。
メッセージキュー
パラメタ
資源制御
種類
必要数
msgmax
(注)
－
設定値
16,384 以上
msgmnb
process.maxmsg-qbytes
設定値
32,768 以上
msgmni
project.maxmsg-ids
加算値
512 以上
注)
Solaris 9でのみ有効です。
メッセージキュー
- 59 -
パラメタ
種類
必要数
kernel.msgmax
設定値
16,384 以上
kernel.msgmnb
設定値
32,768 以上
kernel.msgmni
加算値
512 以上
インタフェースリポジトリ
インタフェースリポジトリを使用する場合に必要となるシステム資源を以下に示します。
共用メモリ
パラメタ
資源制御
種類
必要数
shmmax(注
1)
－
設定値
[ログ採取時][Solaris 9の場合]
logging memory size ＋ 16K (注2)
－
project.maxshm-memory
加算値
[ログ採取時(EJBサービス未使用)][Solaris 10以降の場合]
(logging memory size ＋ 16K) × 3 (注2)
[ログ採取時(EJBサービス使用)][Solaris 10以降の場合]
(logging memory size ＋ 16K) × 4 (注2)
shmmni
project.maxshm-ids
加算値
[EJBサービスを使用しない場合]
3
[EJBサービスを使用する場合]
4
注1)
Solaris 10以降でshmmaxを設定する場合、Solarisのドキュメントおよび“■システムパラメタについて”を参照して値を決定してくだ
さい。
注2)
“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のドキュメントを参照して
ください。
- 60 -
■アプリケーションで使用するスレッド数・プロセス数
CORBAサービスでアプリケーションを実行する場合、アプリケーションから生成されるプロセス数・スレッド数が多くなる場合には、シ
ステムパラメタを変更する必要があります。
アプリケーションをマルチスレッドで作成している場合に、生成されるスレッド数の目安を以下に示します。
分類
スレッド数
CORBAサービス
25個 ＋ クライアントアプリケーションとの接続数
＋ CORBAアプリケーションプロセス数
サーバアプリケーション
1プロセスにつき (6個 ＋ スレッド多重度数)
クライアントアプリケーション
1プロセスにつき8個
システムパラメタで、変更が必要となるものを以下に示します。
パラメタ
内容
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サービスで多数のアプリケーションを動作させ(多端末接続時など)、使用するファイルディスクリプタ数がシステムのデフォル
ト値を超える場合は、システムパラメタにその値を設定してください。
- 61 -
パラメタ
rlim_fd_cur
(システムパラメタ)
内容
使用するファイルディスクリプタ数がデフォルト値を超える場合に設
定。
システムパラメタで、変更が必要となるものを以下に示します。
パラメタ
内容
システム全体のファイルディスクリプタの上限値。
fs.file-max
システムパラメタ以外で、考慮するパラメタを以下に示します。
パラメタ
nofile (注1)
内容
各ユーザのオープン可能なファイルディスクリプタの上限値
注1)
/etc/security/limits.conf ファイルを編集します。limits.conf ファイルの詳細については、オペレーティングシステムのドキュメントを参
照してください。
3.1.2 コンポーネントトランザクションサービスのシステム資源の設定
コンポーネントトランザクションサービスの動作時には、使用する機能によりシステム資源を拡張する必要があります。ここでは、以下
について説明します。
・ システムパラメタ
－ コンポーネントトランザクションサービスの基本機能
－ セション情報管理機能
－ 性能監視ツール
以降に示す値は、CORBAサービスの値を含んでいません。“3.1.1 CORBAサービスのシステム資源の設定”を参照し、必要な値を
加算してください。
■システムパラメタ
コンポーネントトランザクションサービスが使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニングについて
説明します。
コンポーネントトランザクションサービスの基本機能のほかに各機能を使用する場合は、コンポーネントトランザクションサービスの基
本機能の資源に各機能で使用する資源量を加算してください。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタは、Solaris 10以降の場合に設定可能です。
- 62 -
コンポーネントトランザクションサービスの基本機能
コンポーネントトランザクションサービスの基本機能を使用する場合に必要となるシステム資源について、以下に示します。
共用メモリ
パラメタ
shmmax
資源制御
－
種類
設定値
必要数
Interstage Application Server Enterprise Edition/ Interstage
Application Server Standard-J Editionの場合
・ システム規模がsmallの場合
12498508以上
・ システム規模がmoderateの場合
23736108以上
・ システム規模がlargeの場合
34973708以上
・ システム規模がsuperの場合
54736908以上
Interstage Web Serverの場合
・ 12498508以上
－
project.maxshm-memory
加算値
Interstage Application Server Enterprise Editionの場合
・ ラッパーワークユニット未使用時
－ システム規模がsmallの場合
36096468以上
－ システム規模がmoderateの場合
48500404以上
－ システム規模がlargeの場合
61728660以上
－ システム規模がsuperの場合
83718036以上
・ ラッパーワークユニット使用時
－ システム規模がsmallの場合
36222932以上
－ システム規模がmoderateの場合
48744628以上
－ システム規模がlargeの場合
62914964以上
－ システム規模がsuperの場合
86081940以上
Interstage Application Server Standard-J Editionの場合
・ システム規模がsmallの場合
35971540以上
・ システム規模がmoderateの場合
48257716以上
・ システム規模がlargeの場合
60543892以上
- 63 -
パラメタ
資源制御
種類
必要数
・ システム規模がsuperの場合
81355668以上
Interstage Web Serverの場合
・ 35971540以上
shmmni
project.maxshm-ids
加算値
22 (注)
注)
マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。
マルチシステム機能はInterstage Application Server Enterprise Editionで使用できます。
共用メモリ
パラメタ
種類
必要数
設定値
kernel.shmmax
[システム規模がsmallの場合]
12498508以上
[システム規模がmoderateの場合]
23736108以上
[システム規模がlargeの場合]
34973708以上
[システム規模がsuperの場合]
54736908以上
18,219,144 以上
加算値
kernel.shmmni
22
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
29 (注2)
semmns
(注1)
－
加算値
21 (注2)
semmsl
process.maxsem-nsems
設定値
12 以上 (注2)
semopm
process.maxsem-ops
設定値
3 以上
注1)
Solaris 9でのみ有効です。
注2)
マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。
マルチシステム機能はInterstage Application Server Enterprise Editionで使用できます。
セマフォ
パラメタ
para1
種類
設定値
必要数
12 以上
- 64 -
パラメタ
種類
必要数
para2
加算値
21
para3
設定値
3 以上
para4
加算値
29
メッセージキュー
パラメタ
資源制御
種類
必要数
msgmax
(注1)
－
設定値
528 以上
msgmnb
process.maxmsg-qbytes
設定値
4,572 ＋ (528 × 同時実行コマンド数) (注2)
msgmni
project.maxmsg-ids
加算値
11 (注3)
msgtql
process.maxmsg-messages
設定値
[Solaris 10以降の場合]
15 ＋ 同時実行コマンド数 以上(注2)(注3)(注4)
－
加算値
[Solaris 9の場合]
15 ＋ 同時実行コマンド数 (注2)(注3)(注4)
注1)
Solaris 9でのみ有効です。
注2)
同時実行コマンド数とは、以下のコマンドを同時に実行した数のことです。
－ Interstage Application Server Enterprise Editionの場合
isstartwu 、 isstopwu 、 tdstartwu 、 tdstopwu 、 tdinhibitobj 、 tdpermitobj 、 tdmodifyprocnum 、 tdmodifywu 、 tdstandbywu、
tdreleasewu
－ Interstage Application Server Standard-J Editionの場合
isstartwu、isstopwu
また、Systemwalker Operation Manager、Interstage運用APIを使用してワークユニットの起動/停止、オブジェクト閉塞/閉塞解除、
ラッパーワークユニットのオブジェクト情報の獲得を行う場合は、同時に操作する回数が同時実行コマンド数となります。
オブジェクト閉塞/閉塞解除、ラッパーワークユニットのオブジェクト情報の獲得はInterstage Application Server Enterprise Editionで
使用できます。
注3)
マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。
マルチシステム機能はInterstage Application Server Enterprise Editionで使用できます。
注4)
AIM連携機能を使用する場合は、2,040を加算してください。
AIM連携機能はInterstage Application Server Enterprise Editionで使用できます。
メッセージキュー
パラメタ
種類
必要数
kernel.msgmax
設定値
528 以上
kernel.msgmnb
設定値
4,572 ＋ (528 × 同時実行コマンド数) (注)
kernel.msgmni
加算値
11
注)
同時実行コマンド数とは、以下のコマンドを同時に実行した数のことです。
- 65 -
－ 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.maxshm-ids
種類
加算値
必要数
1 (注)
注)
マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。
マルチシステム機能はInterstage Application Server Enterprise Editionで使用できます。
共用メモリ
パラメタ
種類
加算値
kernel.shmmni
必要数
1
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
1 (注2)
semmns
(注1)
－
加算値
1
注1)
Solaris 9でのみ有効です。
注2)
マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。
マルチシステム機能はInterstage Application Server Enterprise Editionで使用できます。
セマフォ
パラメタ
種類
必要数
para2
加算値
1
para4
加算値
1
- 66 -
性能監視ツール
性能監視ツールを使用する場合に追加となるシステム資源については、“3.3 性能監視ツール使用時に必要なシステム資源”を参照
してください。
3.1.3 データベース連携サービスのシステム資源の設定
データベース連携サービスの動作時には、利用するシステム形態によりシステム資源を拡張する必要があります。ここでは、以下に
ついて、利用するシステム形態ごとに説明します。
・ システムパラメタ
－ OTSシステムのみが動作する場合
－ リソース管理プログラムのみが動作する場合
－ OTSシステムとリソース管理プログラムの両方が動作する場合
■システムパラメタ
データベース連携サービスが使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニングについて、システム
形態ごとに説明します。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタは、Solaris 10以降の場合に設定可能です。
OTSシステムのみが動作する場合
OTSシステムのみが動作する場合に必要となるシステム資源について、以下に示します。
共用メモリ
パラメタ
資源制御
種類
必要数
shmmax
－
設定値
17,830,204以上 (注)
－
project.maxshm-memory
加算値
17,830,204 (注)
shmmni
project.maxshm-ids
加算値
12
共用メモリ
パラメタ
種類
必要数
kernel.shmmax
設定値
17,830,204 (注)
kernel.shmmni
加算値
12
注)
以下のデフォルト環境で算出した値です。
－ データベース連携サービスの環境定義のconfigファイル
OTS_TRACE_SIZE = 4096
RECOVERY_TRACE_SIZE = 4096
OBSERVE_TRACE_SIZE = 4096
- 67 -
－ データベース連携サービスの環境定義のセットアップ情報ファイル
TRANMAX = 100
PARTICIPATE = 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
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
8
semmns
(注)
－
加算値
24
semmsl
process.maxsem-nsems
設定値
12 以上
semopm
process.maxsem-ops
設定値
3 以上
注)
Solaris 9でのみ有効です。
セマフォ
パラメタ
種類
必要数
para1
設定値
12 以上
para2
加算値
24
para3
設定値
3 以上
para4
加算値
8
メッセージキュー
パラメタ
資源制御
種類
必要数
msgmax
(注)
－
設定値
528 以上
msgmnb
process.maxmsg-qbytes
設定値
4,572 以上
msgmni
project.maxmsg-ids
加算値
3
msgtql
process.maxmsg-messages
設定値
[Solaris 10以降の場合]
2,040以上
－
加算値
[Solaris 9の場合]
2,040
- 68 -
注)
Solaris 9でのみ有効です。
メッセージキュー
パラメタ
種類
必要数
kernel.msgmax
設定値
528 以上
kernel.msgmnb
設定値
4,572 以上
kernel.msgmni
加算値
3
リソース管理プログラムのみが動作する場合
リソース管理プログラムのみが動作する場合に必要となるシステム資源について、以下に示します。
共用メモリ
パラメタ
資源制御
種類
必要数
shmmax
－
設定値
12,840,416以上 (注)
－
project.maxshm-memory
加算値
12,840,416 (注)
shmmni
project.maxshm-ids
加算値
リソース管理プログラムの種類 × 11
共用メモリ
パラメタ
種類
必要数
kernel.shmmax
設定値
12,840,416 (注)
kernel.shmmni
加算値
リソース管理プログラムの種類 × 11
注)
リソース管理プログラムの種類が1つの場合で、かつ、以下のデフォルト環境で算出した値です。
－ データベース連携サービスの環境定義のconfigファイル
RESOURCE_TRANMAX = 10
RESOURCE_TRACE_SIZE = 4096
OBSERVE_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
セマフォ
パラメタ
semmni
資源制御
project.maxsem-ids
種類
加算値
必要数
リソース管理プログラムの種類 × 7
- 69 -
セマフォ
パラメタ
種類
加算値
para4
必要数
リソース管理プログラムの種類 × 7
OTSシステムとリソース管理プログラムの両方が動作する場合
OTSシステムとリソース管理プログラムの両方が動作する場合に必要となるシステム資源について、以下に示します。
共用メモリ
パラメタ
資源制御
種類
必要数
shmmax
－
設定値
17,830,204以上 (注)
－
project.maxshm-memory
加算値
17,830,204(注)
shmmni
project.maxshm-ids
加算値
12 ＋ リソース管理プログラムの種類 × 11
共用メモリ
パラメタ
種類
必要数
kernel.shmmax
設定値
17,830,204 (注)
kernel.shmmni
加算値
12 ＋ リソース管理プログラムの種類 × 11
注)
リソース管理プログラムの種類が1つの場合で、かつデフォルト環境での値です。定義値を変更している場合、以下の計算式で求
めてください。
必要数 ＝
OTSシステムのみが動作する場合の必要数 ＋
リソース管理プログラムのみが動作する場合の必要数 － 4,915,600
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
8 ＋ リソース管理プログラムの種類 × 7
semmns
(注)
－
加算値
24
semmsl
process.maxsem-nsems
設定値
12 以上
semopm
process.maxsem-ops
設定値
3 以上
注)
Solaris 9でのみ有効です。
セマフォ
パラメタ
種類
必要数
para1
設定値
12 以上
para2
加算値
24
- 70 -
パラメタ
種類
必要数
para3
設定値
3 以上
para4
加算値
8 ＋ リソース管理プログラムの種類 × 7
メッセージキュー
パラメタ
資源制御
種類
必要数
msgmax
(注)
－
設定値
528 以上
msgmnb
process.maxmsg-qbytes
設定値
4,572 以上
msgmni
project.maxmsg-ids
加算値
3
msgtql
process.maxmsg-messages
設定値
[Solaris 10以降の場合]
2,040以上
－
加算値
[Solaris 9の場合]
2,040
注)
Solaris 9でのみ有効です。
メッセージキュー
パラメタ
種類
必要数
kernel.msgmax
設定値
528 以上
kernel.msgmnb
設定値
4,572 以上
kernel.msgmni
加算値
3
3.1.4 イベントサービスのシステム資源の設定
イベントサービスを用いたシステムの運用時には、チャネル数、接続するコンシューマ/サプライヤ数などによりシステム資源を拡張す
る必要があります。ここでは、以下について説明します。
・ システムパラメタ
以降に示す値は、CORBAサービスの値を含んでいません。“3.1.1 CORBAサービスのシステム資源の設定”を参照し、必要な値を
加算してください。
■システムパラメタ
一般的なイベントサービスが使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニングについて説明します。
イベントサービスの他に共用メモリ、セマフォ、メッセージキューを使用するアプリケーションが存在する場合、そのアプリケーションが
使用する資源にイベントサービスの資源量を加算してください。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタは、Solaris 10以降の場合に設定可能です。
- 71 -
揮発チャネル運用と不揮発チャネル運用を併用している場合は、不揮発チャネル運用の必要数を使用してください。
共用メモリ
パラメタ
shmmax(注
1)
資源制御
－
種類
設定値
必要数
[揮発チャネル運用の場合][Solaris 9の場合]
以下の値のうち、最大値を指定します。
・ 1,040 × イベントチャネル最大作成数(注2) ＋ 600K
・ traceconfigファイルのtrace_sizeパラメタに指定したバイト数(注
3)
[不揮発チャネル運用の場合][Solaris 9の場合]
以下の値のうち、最大値を指定します。
・ 1,040 × イベントチャネル最大作成数(注2) ＋
184 × 同時実行可能なグローバルトランザクション数(注4) ＋
600K
・ 17 × 1,024 × 1,024 ＋
576 × トランザクションの多重度 ＋
88 × (システム用データ格納域の数 ＋
イベントデータ用データ格納域の数) ＋
ユニットで使用する共用メモリサイズ × 1,024 × 1,024 (注5)
・ traceconfigファイルのtrace_sizeパラメタに指定したバイト数(注
3)
・ [MessageQueueDirectorのイベントチャネル連携サービスのパッ
キング転送機能を使用する場合]
イベントデータの平均サイズ(注6) ×
packmsg_cntキーワード値(注7) × 23 －
42 × 1,024 × 1,024
－
project.maxshm-memory
加算値
[揮発チャネル運用の場合][Solaris 10以降の場合]
以下の値を加算します。
・ 1,040 × イベントチャネル最大作成数(注2) ＋ 600K
・ traceconfigファイルのtrace_sizeパラメタに指定したバイト数(注
3)
[不揮発チャネル運用の場合][Solaris 10以降の場合]
以下の値を加算します。
・ 1,040 × イベントチャネル最大作成数(注2) ＋
184 × 同時実行可能なグローバルトランザクション数(注4) ＋
600K
・ 17 × 1,024 × 1,024 ＋
576 × トランザクションの多重度 ＋
88 × (システム用データ格納域の数 ＋
イベントデータ用データ格納域の数) ＋
ユニットで使用する共用メモリサイズ × 1,024 × 1,024 (注5)
・ traceconfigファイルのtrace_sizeパラメタに指定したバイト数(注
3)
・ [MessageQueueDirectorのイベントチャネル連携サービスのパッ
キング転送機能を使用する場合]
イベントデータの平均サイズ(注6) ×
- 72 -
パラメタ
資源制御
種類
必要数
packmsg_cntキーワード値(注7) × 23 －
42 × 1,024 × 1,024
shmmni
project.maxshm-ids
加算値
[揮発チャネル運用の場合]
4
[不揮発チャネル運用の場合]
ユニット数 × 100 以上
注1)
Solaris 10以降でshmmaxを設定する場合、Solarisのドキュメントおよび“■システムパラメタについて”を参照して値を決定してくだ
さい。
注2)
イベントチャネル最大作成数 ＝
静的生成イベントチャネル最大作成数 ＋ 動的生成イベントチャネル最大作成数
注3)
traceconfigファイルの詳細については、“D.1 traceconfig”を参照してください。
注4)
同時実行可能なグローバルトランザクション数は、イベントサービスの構成情報管理コマンド(essetcnf)による-gtrnmaxオプションの
設定値です。
注5)
各値は、ユニット作成コマンド(esmkunit)による以下のユニット定義の設定値です。
なお、複数のユニットを使用する場合は、それぞれのユニットに対して、算出してください。
ユニット定義の項目
トランザクションの多重度
tranmaxの設定値
システム用データ格納域の数
sysqnumの設定値
イベントデータ用データ格納域の数
userqnumの設定値
ユニットで使用する共用メモリサイズ
shmmaxの設定値(42より小さい場合は、42)
注6)
イベントデータの平均サイズは、以下の計算式で求めます(小数点以下は、切り上げ)。
Ev_size: アプリケーション内で送受信するイベントデータの平均サイズ
－ [Ev_sizeが2Kバイト以内の場合]
イベントデータの平均サイズ ＝ ((Ev_size ＋ 1) ÷ 512) × 512
－ [Ev_sizeが2Kバイトを超える場合]
イベントデータの平均サイズ ＝ 2K ＋ ((Ev_size － 2K) ÷ 16K) × 16K
注7)
packmsg_cntキーワード値は、MessageQueueDirectorのイベントチャネル連携サービスのサービス定義で指定したCHANNELセク
ションのpackmsg_cntキーワード値です。
共用メモリ
パラメタ
kernel.shmmax
種類
設定値
必要数
[揮発チャネル運用の場合]
2,064 × イベントチャネル最大作成数(注1) ＋
600K ＋trace_sizeパラメタに指定したバイト数(注2) ＋ 3,328
[不揮発チャネル運用の場合]
以下の値のうち、最大値を指定します。
- 73 -
パラメタ
種類
必要数
・ 2,064 × イベントチャネル最大作成数(注1) ＋
184 × 同時実行可能なグローバルトランザクション数(注3) ＋
600K ＋trace_sizeパラメタに指定したバイト数(注2) ＋ 3,328
・ 134,217,728 以上
・ ユニットで使用する共用メモリサイズ(複数ユニットがある場合、
最大値)(注4)
加算値
kernel.shmmni
[揮発チャネル運用の場合]
・ プロセス単位で内部トレースを採取する(trace_buffer=process)
場合(注2)
4 ＋ イベントチャネルのプロセス数(注5)
・ イベントサービス単位で内部トレースを採取する
(trace_buffer=system)場合(注2)
4
[不揮発チャネル運用の場合]
・ プロセス単位で内部トレースを採取する(trace_buffer=process)
場合(注2)
100 以上の値 (ユニット単位に加算) ＋ イベントチャネルのプロ
セス数(注5)
・ イベントサービス単位で内部トレースを採取する
(trace_buffer=system)場合(注2)
100 以上の値 (ユニット単位に加算)
注1)
イベントチャネル最大作成数 ＝
静的生成イベントチャネル最大作成数 ＋ 動的生成イベントチャネル最大作成数
注2)
trace_sizeパラメタおよびtrace_bufferパラメタは、イベントサービスの動作環境ファイル（traceconfig）で指定します。詳細について
は、“D.1 traceconfig”を参照してください。
注3)
同時実行可能なグローバルトランザクション数は、イベントサービスの構成情報管理コマンド(essetcnf)による-gtrnmaxオプションの
設定値です。
注4)
ユニットで使用する共用メモリサイズは、ユニットの作成コマンド(esmkunit)のユニット定義ファイルで指定した項目shmmaxの設定
値です。
注5)
イベントチャネルのプロセス数 ＝
静的イベントチャネルグループ数 ＋ 動的イベントチャネルのプロセス数
－ 動的イベントチャネルのプロセス数:
イベントサービスのセットアップコマンド(essetup)による-pオプションの設定値。
ノーティフィケーションサービスを使用している場合は、“動的イベントチャネルのプロセス数 × 2”としてください。
セマフォ
パラメタ
semmni
資源制御
project.maxsem-ids
種類
加算値
必要数
3
- 74 -
パラメタ
semmns
(注)
資源制御
－
種類
加算値
必要数
[揮発チャネル運用の場合]
3 以上
[不揮発チャネル運用の場合]
4 以上
注)
Solaris 9でのみ有効です。
セマフォ
パラメタ
種類
必要数
para1
設定値
29
para2
加算値
[揮発チャネル運用の場合]
6 以上
[不揮発チャネル運用の場合]
ユニット数 × 29 ＋ 13 以上
para3
設定値
29
para4
加算値
ユニット数 × 256
メッセージキュー
パラメタ
資源制御
種類
必要数
msgmax
(注)
－
設定値
[不揮発チャネル運用の場合]
2,048 以上
msgmnb
process.maxmsg-qbytes
設定値
[不揮発チャネル運用の場合]
4,096 以上
msgmni
project.maxmsg-ids
加算値
[揮発チャネル運用の場合]
2
[不揮発チャネル運用の場合]
ユニット数 × 3 ＋ 2
msgtql
process.maxmsg-messages
設定値
[不揮発チャネル運用の場合][Solaris 10以降の場合]
以下をユニットごとに求めた合計値
・ 6 ＋ (ユニット定義ファイルのtranmax値 × 4 × 1.3)
－
加算値
[不揮発チャネル運用の場合][Solaris 9の場合]
以下をユニットごとに求めた合計値
・ 6 ＋ (ユニット定義ファイルのtranmax値 × 4 × 1.3)
注)
Solaris 9でのみ有効です。
メッセージキュー
パラメタ
種類
必要数
kernel.msgmax
設定値
[不揮発チャネル運用の場合]
2,048 以上
kernel.msgmnb
設定値
[不揮発チャネル運用の場合]
4,096 以上
- 75 -
パラメタ
種類
加算値
kernel.msgmni
必要数
[不揮発チャネル運用の場合]
ユニット数 × 9
3.1.5 J2EE互換のシステム資源の設定
IJServerまたはEJBサービスでは以下の機能を使用する場合に、システム資源を拡張する必要があります。ここでは、以下について説
明します。
・ システムパラメタ
■システムパラメタ
IJServerまたはEJBサービスを使用する際には、以下のシステムパラメタのチューニングを行ってください。
ワークユニット定義の通信バッファ数(Buffer Number)、通信バッファ長(BufferSize)を指定する場合は、“3.1.1 CORBAサービスのシ
ステム資源の設定”についても参照してください。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタの設定は、Solaris 10以降の場合のみ可能です。
メッセージキュー
パラメタ
資源制御
種類
必要数
msgmax
(注)
－
設定値
4,096 以上
msgmnb
process.maxmsg-qbytes
設定値
4,096 以上
msgmni
project.maxmsg-ids
加算値
2 以上
msgtql
process.maxmsg-messages
設定値
[Solaris 10以降の場合]
1,024 以上
－
加算値
[Solaris 9の場合]
512 以上
注)
Solaris 9でのみ有効です。
メッセージキュー
パラメタ
種類
必要数
kernel.msgmax
設定値
4,096 以上
kernel.msgmnb
設定値
4,096 以上
kernel.msgmni
加算値
2 以上
3.1.6 Interstage HTTP Serverのシステム資源の設定
Interstage HTTP Serverを用いたシステムの運用時には、システム資源を拡張する必要があります。ここでは、以下について説明しま
す。
・ システムパラメタ
- 76 -
・ ファイルディスクリプタ
■システムパラメタ
Interstage HTTP Serverを運用するためのサービスが使用するセマフォのシステムパラメタのチューニングについて説明します。
システムパラメタの変更方法や、パラメタの意味については、“■システムパラメタについて”を参照してください。
セマフォ
パラメタ
種類
必要数
para1
設定値
1以上
para2
加算値
Webサーバ数×2
para3
設定値
1以上
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プログラム内で必要となるファイルディスクリプタの数は、別途加算してください。
- 77 -
以下の表を参照して必要なファイルディスクリプタ数を算出してください。
リソース制限については、本値がシステムのデフォルト値を超える場合、/etc/security/limits.confファイルに本値を設定してください。リ
ソース制限の変更方法や、パラメタの意味については、“◆リソース制限 ”を参照してください。
システムパラメタについては、ファイルディスクリプタ数が不足する現象が発生した場合、システムパラメタに本値を加算設定してくださ
い。複数のWebサーバを作成している場合は、Webサーバごとに必要数を加算してください。システムパラメタの変更方法や、パラメタ
の意味については、“■システムパラメタについて”を参照してください。
パラメタ
[リソース制限]
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が使用するシステムパラメタのチューニングについて説明します。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタの設定は、Solaris 10以降の場合のみ可能です。
共用メモリ
- 78 -
パラメタ
資源制御
種類
必要数
shmmax
(注1)
－
設定値
[Solaris 9の場合]
MessageBufferMaxSize × 1,000,000 以上
－
project.maxshm-memory
加算値
[Solaris 10以降の場合]
MessageBufferMaxSize × 1,000,000 × MQDシステム数
shmmni
project.maxshm-ids
加算値
100 × MQDシステム数
注1)
Solaris 10以降でshmmaxを設定する場合、Solarisのドキュメントおよび“■システムパラメタについて”を参照して値を決定してくだ
さい。
共用メモリ
パラメタ
種類
必要数
kernel.shmmax
設定値
134,217,728 以上
kernel.shmmni
加算値
100 × MQDシステム数
セマフォ
パラメタ
種類
必要数
para1
設定値
29
para2
加算値
MQDシステム数 × 29
para3
設定値
29
para4
加算値
MQDシステム数 × 256
メッセージキュー
パラメタ
資源制御
種類
必要数
msgmax
(注1)
－
設定値
2,048 以上
msgmnb
process.maxmsg-qbytes
設定値
44 × 1,024 × 4 × 1.3 (注2)
msgmni
project.maxmsg-ids
加算値
3 × MQDのシステム数
msgtql
－
加算値
[Solaris 9の場合]
[MQDのアプリケーションインタフェースを使用する場合]
MQDシステム数 × (6 ＋ (1,024 × 4 × 1.3)) (注2)
[Solaris 9の場合]
[MQDのアプリケーションインタフェースを使用しない場合]
MQDシステム数 × (6 ＋ (n × 4 × 1.3)) (注2)(注3)
－
process.maxmsg-messages
設定値
[Solaris 10以降の場合]
[MQDのアプリケーションインタフェースを使用する場合]
MQDシステム数 × (6 ＋ (1,024 × 4 × 1.3)) 以上 (注2)
[Solaris 10以降の場合]
[MQDのアプリケーションインタフェースを使用しない場合]
MQDシステム数 × (6 ＋ (n × 4 × 1.3)) 以上 (注2)(注3)
注1)
Solaris 9でのみ有効です。
- 79 -
注2)
1.3は余裕値です。
注3)
MQDの拡張機能を使用する場合、nには以下の式に従った値をいれてください。また、nには3以上の数値をいれてください。
拡張機能
nの値
イベントチャネル連携サービス(非同期メッセージ
基盤にMQDを使用する場合)
3 ＋ 送信キュー数 ＋ 受信キュー数 を加算
イベントチャネル連携サービス(非同期メッセージ
基盤にMQDを使用しない場合)
3 を加算
同報配信サービス
同報配信グループ数 ＋ 1 を加算
SMTP連携サービス
3 ＋ 送信キュー数 × 2 ＋ 受信キュー数 ＋ 100 を
加算
メッセージキュー
パラメタ
種類
必要数
kernel.msgmax
設定値
16,384 以上
kernel.msgmnb
設定値
32,768 以上
kernel.msgmni
加算値
9 × MQDシステム数
■ファイルディスクリプタ数
MessageQueueDirectorでSMTP連携サービスを使用する場合には、MQDを起動するshellに対してulimitコマンドで設定するパラメタ
を変更する必要があります。
パラメタ
descriptors
内容
20 ＋ (送信キュー数定義数 × 2)
3.1.8 Interstage シングル・サインオンのシステム資源の設定
Interstage シングル・サインオンを用いたシステムの運用時には、システム資源を拡張する必要があります。ここでは、以下について説
明します。
・ システムパラメタ
－ Interstage シングル・サインオンのリポジトリサーバ機能を使用する際のシステムパラメタのチューニング
－ Interstage シングル・サインオンの認証サーバ機能を使用する際のシステムパラメタのチューニング
－ Interstage シングル・サインオンの業務サーバ機能を使用する際のシステムパラメタのチューニング
■システムパラメタ
Interstage シングル・サインオンが使用するシステムパラメタのチューニングについて説明します。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタの設定は、Solaris 10以降の場合に設定可能です。
- 80 -
なお、以降に示す値は、Interstage HTTP Serverで必要な値を含んでいません。“Interstage HTTP Serverのシステム資源の設定”を参
照し、必要な値を加算してください。
Interstage シングル・サインオンのリポジトリサーバ機能を使用する際のシステムパラメタのチューニング
リポジトリサーバでは、“Interstage ディレクトリサービス”を使用しています。“Interstage ディレクトリサービス”で必要としているチューニ
ングについては、“3.1.9 Interstage ディレクトリサービスのシステム資源の設定”を参照してください。
共用メモリ
パラメタ
資源制御
種類
必要数
shmmax
(注1)
－
設定値
[Solaris 9の場合]
12,800,000 ＋ (164 × サイト定義数(注2)) ＋
(ロール数(注3) ＋ ロールセット数(注4) ＋
ロールセット数(注4) × ロール数(注3)) × 1,024 以上 (注5)
－
project.maxshm-memory
加算値
26,000,000 ＋ (164 × サイト定義数(注2)) ＋
(ロール数(注3) ＋ ロールセット数(注4) ＋
ロールセット数(注4) × ロール数(注3)) × 1,024 × 3 (注6)
shmmni
project.maxshm-ids
加算値
13
注1)
Solaris 10以降でshmmaxを設定する場合、Solarisのドキュメントおよび“■システムパラメタについて”を参照して値を決定してくだ
さい。
注2)
SSOリポジトリの保護リソースに登録したサイト定義の総数
注3)
SSOリポジトリに定義したロールの総数
注4)
SSOリポジトリに定義したロールセットの総数
注5)
ユーザ情報を登録するディレクトリサービスにActive Directoryを使用し、シングル・サインオンの拡張スキーマを使用しない場合
は、運用に応じて以下の式で見積もった値を加算してください。
Active Directoryのロール/ロールセットに使用する属性の総数 × 524
注6)
ユーザ情報を登録するディレクトリサービスにActive Directoryを使用し、シングル・サインオンの拡張スキーマを使用しない場合
は、運用に応じて以下の式で見積もった値を加算してください。
Active Directoryのロール/ロールセットに使用する属性の総数 × 524 × 3
共用メモリ
パラメタ
種類
必要数
kernel.shmmax
設定値
12,800,000 ＋ (164 × サイト定義数(注1)) ＋
(ロール数(注2) ＋ ロールセット数(注3) ＋
ロールセット数(注3) × ロール数(注2)) × 1,024 以上(注4)
kernel.shmmni
加算値
13
注1)
SSOリポジトリの保護リソースに登録したサイト定義の総数
- 81 -
注2)
SSOリポジトリに定義したロールの総数
注3)
SSOリポジトリに定義したロールセットの総数
注4)
ユーザ情報を登録するディレクトリサービスにActive Directoryを使用し、シングル・サインオンの拡張スキーマを使用しない場合
は、運用に応じて以下の式で見積もった値を加算してください。
Active Directoryのロール/ロールセットに使用する属性の総数 × 524
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
9
semmns
(注)
－
加算値
9
semmnu
(注)
－
加算値
Interstage HTTP Serverが作成する最大プロセス数(httpd.confの
MaxClients値) × 9
semume
(注)
－
加算値
9
注)
Solaris 9でのみ有効です。
セマフォ
パラメタ
種類
必要数
para2
加算値
9
para4
加算値
9
Interstage シングル・サインオンの認証サーバ機能を使用する際のシステムパラメタのチューニング
共用メモリ
パラメタ
資源制御
種類
必要数
shmmax
(注1)
－
設定値
[Solaris 9の場合]
14,000,000 ＋ パス定義の総数(注2) × 2,048 以上
－
project.maxshm-memory
加算値
27,000,000 ＋ パス定義の総数(注2) × 2,048
shmmni
project.maxshm-ids
加算値
11
注1)
Solaris 10以降でshmmaxを設定する場合、Solarisのドキュメントおよび“■システムパラメタについて”を参照して値を決定してくだ
さい。
注2)
SSOリポジトリの保護リソースに登録した各サイト定義に定義したパス定義の総数
共用メモリ
- 82 -
パラメタ
種類
必要数
kernel.shmmax
設定値
14,000,000 ＋ パス定義の総数(注) × 2,048 以上
kernel.shmmni
加算値
11
注)
SSOリポジトリの保護リソースに登録した各サイト定義に定義したパス定義の総数
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
10
semmns
(注)
－
加算値
10
semmnu
(注)
－
加算値
Interstage HTTP Serverが作成する最大プロセス数(httpd.confの
MaxClients値) ×10
semume
(注)
－
加算値
10
注)
Solaris 9でのみ有効です。
セマフォ
パラメタ
種類
必要数
para2
加算値
10
para4
加算値
10
Interstage シングル・サインオンの業務サーバ機能を使用する際のシステムパラメタのチューニング
共用メモリ
パラメタ
資源制御
種類
必要数
shmmax
(注1)
－
設定値
[Solaris 9の場合]
13,000,000 ＋
(1 + キャッシュサイズ(注2)) × 1024 × キャッシュ数(注3) +
(ロール数(注4) ＋ 拡張ユーザ情報数(注5)＋ 1) × パス定義の最
大数(注6) × 1,200
－
project.maxshm-memory
加算値
(13,000,000 ＋
(1 + キャッシュサイズ(注2)) × 1024 × キャッシュ数(注3) +
(ロール数(注4) ＋ 拡張ユーザ情報数(注5)＋ 1) × パス定義の最
大数(注6) × 1,200 × 2) × 業務サーバ数
shmmni
project.maxshm-ids
加算値
10 × 業務サーバ数
注1)
Solaris 10以降でshmmaxを設定する場合、Solarisのドキュメントおよび“■システムパラメタについて”を参照して値を決定してくだ
さい。
- 83 -
注2)
セションの管理を行う運用の場合、業務サーバでキャッシュする利用者の認証情報サイズ(Kバイト)を設定します。セションの管理
を行わない運用の場合は、0で計算してください。
キャッシュサイズについては、“F.4 業務サーバを構築する場合のチューニング”を参照してください。
注3)
セションの管理を行う運用の場合、システムの同時アクセス最大数以上を設定します。セションの管理を行わない運用の場合は、0
で計算してください。
キャッシュ数については、“F.4 業務サーバを構築する場合のチューニング”を参照してください。
注4)
SSOリポジトリに定義したロールの総数
注5)
業務アプリケーションに対して通知するユーザ情報の数
セションの管理を行う運用の場合、リポジトリサーバのInterstage管理コンソールの以下に設定されている属性名の数を設定します。
セションの管理を行わない運用の場合は、0で計算してください。
[システム] > [セキュリティ] > [シングル・サインオン] > [認証基盤] > [リポジトリサーバ] > [環境設定] > [リポジトリサーバ詳細設定
[表示]] > [業務システムに通知する情報] > [拡張ユーザ情報]
注6)
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)
SSOリポジトリに定義したロールの総数
注4)
業務アプリケーションに対して通知するユーザ情報の数
セションの管理を行う運用の場合、リポジトリサーバのInterstage管理コンソールの以下に設定されている属性名の数を設定します。
セションの管理を行わない運用の場合は、0で計算してください。
[システム] > [セキュリティ] > [シングル・サインオン] > [認証基盤] > [リポジトリサーバ] > [環境設定] > [リポジトリサーバ詳細設定
[表示]] > [業務システムに通知する情報] > [拡張ユーザ情報]
注5)
SSOリポジトリの保護リソースに登録した各サイト定義の保護パスに設定されているパス定義の最大数
セマフォ
- 84 -
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
7 × 業務サーバ数
semmns
(注1)
－
加算値
7 × 業務サーバ数
semmnu
(注1)
－
加算値
[WebサーバにInterstage HTTP Serverを使用する場合(注2)]
(7 ＋ (Interstage HTTP Serverが作成する最大プロセス数(注3) ×
7)) × Interstage HTTP Serverを使用しているWebサーバ数
[WebサーバにSun Java System Web Serverを使用する場合(注2)]
14
semume
(注1)
－
加算値
7 × 業務サーバ数
注1)
Solaris 9でのみ有効です。
注2)
WebサーバにInterstage HTTP ServerとSun Java System Web Serverを同時に使用する場合は、それぞれの値を加算してください。
注3)
使用する各Webサーバのhttpd.confに設定されているMaxClientsの最大値
セマフォ
パラメタ
種類
必要数
para2
加算値
7 × 業務サーバ数
para4
加算値
7 × 業務サーバ数
3.1.9 Interstage ディレクトリサービスのシステム資源の設定
Interstage ディレクトリサービスを用いたシステムの運用時には、システム資源を拡張する必要があります。ここでは、以下について説
明します。
・ システムパラメタ(Interstage ディレクトリサービスの運用に必要なシステム資源)
・ システムパラメタ(標準データベースの運用に必要なシステム資源)
・ システムパラメタ(Symfoware Serverの運用に必要なシステム資源)
・ システムパラメタ(Oracleデータベースの運用に必要なシステム資源)
■システムパラメタ(Interstage ディレクトリサービスの運用に必要なシステム資源)
Interstage ディレクトリサービスが使用するシステムパラメタのチューニングについて説明します。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタは、Solaris 10以降の場合に設定可能です。
共用メモリ
パラメタ
shmmax
資源制御
－
種類
設定値
必要数
リポジトリ数 × 1,572,864 ＋
(5 × (リポジトリ数 × 1,843,200)) 以上 (注1)
- 85 -
パラメタ
資源制御
種類
必要数
－
project.maxshm-memory
加算値
(リポジトリ数 × 1,572,864 ＋
(5 × (リポジトリ数 × 1,843,200))(注1)) ×
(4 × リポジトリ数)
shmmni
project.maxshm-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以下となる
ように設定してください。
最大ファイルディスクリプタ数のハードリミットを変更するには、以下を変更してください。
・
システムパラメタを変更してください。システムパラメタの変更方法については、“■システムパラメタについて”を参照してください。
・
リソース制限を変更してください。システムパラメタの変更方法については、“◆リソース制限 ”を参照してください。
ファイルディスクリプタ
パラメタ
資源制御
種類
rlim_fd_ma
x
process.maxfile-descriptor
設定値
必要数
256以上、65,536以下
資源制御で最大ファイルディスクリプタ数のソフトリミットの設定を行った場合、ハードリミットが「無制限」に拡張されます。ソフトリミット
を設定した場合は、合わせてハードリミットも設定してください。
- 86 -
例）
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ユーザを個別に設定して
ください。
例）
*
oms
hard
hard
nofile
nofile
524288
65536
■システムパラメタ(Symfoware Serverの運用に必要なシステム資源)
Symfoware Serverの運用に必要なシステムパラメタの設定は、Symfoware Serverをインストールしたマシンで変更してください。
・ Symfoware ServerをSolarisにインストールした場合
・ Symfoware ServerをLinuxにインストールした場合
ここで示す各システムパラメタの必要数の値は、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」(共用メモリセグメントの最小サイズ)は設定しないでください。
- 87 -
Symfoware ServerをSolarisにインストールした場合
共用メモリ
パラメタ (注)
資源制御
種類
必要数
shmmax
project.maxshm-memory
設定値
13,524,992 以上
shmmni
project.maxshm-ids
加算値
10
注)
パラメタ欄には、“shmsys:shminfo_xxxxxx”の“xxxxxx”を記載しています。
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
300
semmns
(注)
－
加算値
1,112
semmnu
(注)
－
加算値
64
semmsl
process.maxsem-nsems
設定値
48 以上
注)
Solaris 9でのみ有効です。
セマフォ
パラメタ (注
1)
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
300
semmns
(注2)
－
加算値
1,112
semmnu
(注2)
－
加算値
64
semmsl
process.maxsem-nsems
設定値
48 以上
注1)
パラメタ欄には、“semsys:seminfo_xxxxxx”の“xxxxxx”を記載しています。
注2)
Solaris 9でのみ有効です。
メッセージキュー
- 88 -
パラメタ
資源制御
種類
必要数
msgmax
(注)
－
設定値
128 以上
msgmnb
process.maxmsg-qbytes
設定値
4,096 以上
msgmni
project.maxmsg-ids
加算値
2
msgtql
process.maxmsg-messages
設定値
[Solaris 10以降の場合]
64以上
－
加算値
[Solaris 9の場合]
64
注)
Solaris 9でのみ有効です。
メッセージキュー
パラメタ (注
1)
資源制御
種類
必要数
msgmax
(注2)
－
設定値
128 以上
msgmnb
process.maxmsg-qbytes
設定値
4,096 以上
msgmni
project.maxmsg-ids
加算値
2
msgtql
process.maxmsg-messages
加算値
64
注1)
パラメタ欄には、“msgsys:msginfo_xxxxxx”の“xxxxxx”を記載しています。
注2)
Solaris 9でのみ有効です。
Symfoware ServerをLinuxにインストールした場合
共用メモリ
パラメタ
種類
必要数
kernel.shmmax
設定値
13,524,992 以上
kernel.shmmni
加算値
10
セマフォ
パラメタ
種類
必要数
para1
設定値
48 以上
para2
加算値
1,112
すでに設定されている値
para3
para4
加算値
300
- 89 -
メッセージキュー
パラメタ
種類
必要数
kernel.msgmax
設定値
128 以上
kernel.msgmnb
設定値
4,096 以上
kernel.msgmni
加算値
2
■システムパラメタ(Oracleデータベースの運用に必要なシステム資源)
Oracleデータベースの運用に必要なシステムパラメタの設定は、Oracleデータベースをインストールしたマシンで変更してください。
・ OracleデータベースをSolarisにインストールした場合
・ OracleデータベースをLinuxにインストールした場合
レプリケーション運用をするときは、レプリケーションの運用に必要なシステム資源の設定をしてください。設定内容は、Oracleデータ
ベースのマニュアルを参照してください。
OracleデータベースをSolarisにインストールした場合
共用メモリ
パラメタ (注)
資源制御
種類
必要数
shmmax
project.maxshm-memory
設定値
4,294,967,295 以上
shmmni
project.maxshm-ids
設定値
100 以上
注)
パラメタ欄には、“shmsys:shminfo_xxxxxx”の“xxxxxx”を記載しています。
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
設定値
100 以上
semmns
(注)
－
設定値
1,024 以上
semmsl
project.maxsem-nsems
設定値
256 以上
semvmx
(注)
－
設定値
32,767 以上
注)
Solaris 9でのみ有効です。
セマフォ
- 90 -
パラメタ (注
1)
資源制御
種類
必要数
semmni
project.maxsem-ids
設定値
100 以上
semmns
(注2)
－
設定値
1,024 以上
semmsl
project.maxsem-nsems
設定値
256 以上
semvmx
(注2)
－
設定値
32,767 以上
注1)
パラメタ欄には、“semsys:seminfo_xxxxxx”の“xxxxxx”を記載しています。
注2)
Solaris 9でのみ有効です。
OracleデータベースをLinuxにインストールした場合
共用メモリ
パラメタ
種類
必要数
kernel.shmall
設定値
2,097,152 以上
kernel.shmmax
設定値
物理メモリのサイズ(バイト)の1/2 以上
kernel.shmmni
設定値
4,096 以上
セマフォ
パラメタ
種類
必要数
para1
設定値
250 以上
para2
設定値
32,000 以上
para3
設定値
100 以上
para4
設定値
128 以上
ファイルシステム
パラメタ
種類
fs.file-max
(最大ファイル・ハンドル数)
設定値
必要数
65,536 以上
ネットワーク
パラメタ
種類
必要数
net.ipv4.ip_local_port_range
(ポート番号の範囲)
設定値
最小：1,024
最大：65,000
net.core.rmem_default
(受信用ウィンドウ・サイズの
デフォルト値)
設定値
1,048,576 以上
- 91 -
パラメタ
種類
必要数
net.core.rmem_max
(受信用ウィンドウ・サイズの
最大値)
設定値
1,048,576 以上
net.core.wmem_default
(送信用ウィンドウ・サイズの
デフォルト値)
設定値
262,144 以上
net.core.wmem_max
(送信用ウィンドウ・サイズの
最大値)
設定値
262,144 以上
3.1.10 Interstage管理コンソールのシステム資源の設定
Interstage管理コンソールを用いたシステムの運用時には、システム資源を拡張する必要があります。ここでは、以下について説明しま
す。
・ システムパラメタ
Interstage管理コンソールを使用する場合は、Interstage統合コマンドのシステム資源も拡張する必要があります。“3.1.11 Interstage統
合コマンドのシステム資源の設定”を参照し、必要な値を加算してください。
■システムパラメタ
Interstage管理コンソールを運用するためのサービスが使用するセマフォのシステムパラメタのチューニングについて説明します。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
セマフォ
パラメタ
種類
必要数
para1
設定値
1以上
para2
加算値
1
para3
設定値
1以上
para4
加算値
1
3.1.11 Interstage統合コマンドのシステム資源の設定
Java EE、マルチ言語サービス、J2EE互換機能のいずれかを利用する場合は、各機能で追加したシステム資源に加えて、Interstage統
合コマンドで使用するシステム資源を拡張する必要があります。ここでは、以下について説明します。
・ システムパラメタ
■システムパラメタ
Interstage統合コマンドで使用する共用メモリ、セマフォ、メッセージキューのシステムパラメタのチューニングについて説明します。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタは、Solaris 10以降の場合に設定可能です。
- 92 -
共用メモリ
パラメタ
資源制御
種類
必要数
shmmax
－
設定値
1106440 以上
－
project.maxshm-memory
加算値
2015552 以上
shmmni
project.maxshm-ids
加算値
22 (注)
注)
マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。
マルチシステム機能は、Interstage Application Server Enterprise Editionで使用できます。
共用メモリ
パラメタ
種類
必要数
設定値
kernel.shmmax
12503496 以上
13208308 以上
加算値
kernel.shmmni
19
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
2 (注2)
semmns
(注1)
－
加算値
2 (注2)
semmsl
process.maxsem-nsems
設定値
12 以上 (注2)
semopm
process.maxsem-ops
設定値
3 以上
注1)
Solaris 9でのみ有効です。
注2)
マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。
マルチシステム機能は、Interstage Application Server Enterprise Editionで使用できます。
セマフォ
パラメタ
種類
必要数
para1
設定値
12 以上
para2
加算値
2
para3
設定値
3 以上
- 93 -
パラメタ
種類
加算値
para4
必要数
2
メッセージキュー
パラメタ
資源制御
種類
必要数
msgmax
(注1)
－
設定値
528 以上
msgmnb
process.maxmsg-qbytes
設定値
4572 ＋ (528 × 同時実行コマンド数) (注2)
msgmni
project.maxmsg-ids
加算値
12 (注3)
msgtql
process.maxmsg-messages
設定値
[Solaris 10以降の場合]
15 ＋ 同時実行コマンド数 以上(注2)(注3)
－
加算値
[Solaris 9の場合]
15 ＋ 同時実行コマンド数 (注2)(注3)
注1)
Solaris 9でのみ有効です。
注2)
同時実行コマンド数とは、Interstage統合コマンドを同時に実行した数のことです。
また、Systemwalker Operation Manager、Interstage運用APIを使用してワークユニットの起動／停止、オブジェクト閉塞／閉塞解除
を行う場合は、同時に操作する回数が同時実行コマンド数となります。
注3)
マルチシステム機能を使用する場合は、拡張システム数を積算した値を加算してください。
マルチシステム機能は、Interstage Application Server Enterprise Editionで使用できます。
メッセージキュー
パラメタ
種類
必要数
kernel.msgmax
設定値
528 以上
kernel.msgmnb
設定値
4572 ＋ (528 × 同時実行コマンド数) (注)
kernel.msgmni
加算値
12
注)
同時実行コマンド数とは、Interstage統合コマンドを同時に実行した数のことです。
また、Systemwalker Operation Manager、Interstage運用APIを使用してワークユニットの起動／停止、オブジェクト閉塞／閉塞解除
を行う場合は、同時に操作する回数が同時実行コマンド数となります。
3.1.12 Webサーバコネクタのシステム資源の設定
Webサーバコネクタを使用する場合には、システム資源を拡張する必要があります。ここでは、以下について説明します。
・ システムパラメタ
－ Webサーバコネクタを使用する場合
－ Webサーバコネクタの故障監視機能を使用する場合
- 94 -
■システムパラメタ
Webサーバコネクタを使用する際には、以下のシステムパラメタのチューニングを行ってください。
Webサーバコネクタの故障監視機能を使用する場合は、Webサーバコネクタで使用する資源にWebサーバコネクタの故障監視機能
で使用する資源量を加算してください。
システムパラメタの変更方法や、各パラメタの意味については、“■システムパラメタについて”を参照してください。
なお、資源制御によるIPC資源のパラメタの設定は、Solaris 10以降の場合に可能です。
Webサーバコネクタ
Webサーバコネクタを使用する場合に必要となるシステム資源について、以下に示します。
セマフォ
パラメタ
semmni
資源制御
project.maxsem-ids
種類
加算値
必要数
以下をWebサーバごとに求めた合算値 (注2)(注3)
・ ((IJServerワークユニット数の合計値 ＋
各IJServerワークユニットのプロセス多重度の合計値 ＋ 2)×2)
＋4
semmns
(注1)
－
加算値
以下をWebサーバごとに求めた合算値 (注3)
・ ((IJServerワークユニット数の合計値 ＋
各IJServerワークユニットのプロセス多重度の合計値 ＋ 2)×2)
＋4
semmnu
(注1)
－
加算値
[Interstage HTTP Serverを使用する場合]
以下をWebサーバごとに求めた合算値 (注3)
・ (((IJServerワークユニット数の合計値 ＋
各IJServerワークユニットのプロセス多重度の合計値 ＋ 2)×2)
＋ 4) ×
Interstage HTTP Serverが作成する最大プロセス数(httpd.conf
のMaxClients値)
[Sun Java System Web Serverを使用する場合]
・ (((IJServerワークユニット数の合計値 ＋
各IJServerワークユニットのプロセス多重度の合計値 ＋ 2)×2)
＋ 4) ×
Sun Java System Web Server が 作 成 す る 最 大 プ ロ セ ス 数
(magnus.confのMaxProcs値)
semmsl
process.maxsem-nsems
設定値
1 以上
semopm
process.maxsem-ops
設定値
2 以上
semume
(注1)
－
加算値
((IJServerワークユニット数の合計値 ＋
各IJServerワークユニットのプロセス多重度の合計値 ＋ 2)×2) ＋
4
semvmx
(注1)
－
設定値
32,767 以上
注1)
Solaris 9でのみ有効です。
- 95 -
注2)
Solaris 10以降の場合のチューニングの例を以下に示します。
条件
IJServerワークユニット
Webサーバ
WU001
プロセス多重度:3
WU002
プロセス多重度:3
WU003
プロセス多重度:3
web001
接続先:WU001、WU002
web002
接続先:WU003
－ semmni
web001の必要数 ＝
((2(IJServerワークユニット数の合計値) ＋
6(各IJServerワークユニットのプロセス多重度の合計値) ＋ 2)×2) ＋ 4
＝ 24
web002の必要数 ＝
((1(IJServerワークユニット数の合計値) ＋
3(各IJServerワークユニットのプロセス多重度の合計値) ＋ 2)×2) ＋ 4
＝ 16
semmni ＝ 24(web001の必要数) ＋ 16(web002の必要数) ＝ 40
注3)
Solaris 9の場合のチューニングの例を以下に示します。
条件
IJServerワークユニット
Webサーバ
WU001
プロセス多重度:3
WU002
プロセス多重度:3
WU003
プロセス多重度:3
web001
最大プロセス多重数:50
接続先:WU001、WU002
web002
最大プロセス多重数:50
接続先:WU003
－ semmni
web001の必要数 ＝
((2(IJServerワークユニット数の合計値) ＋
6(各IJServerワークユニットのプロセス多重度の合計値) ＋ 2)×2) ＋ 4
＝ 24
web002の必要数 ＝
((1(IJServerワークユニット数の合計値) ＋
3(各IJServerワークユニットのプロセス多重度の合計値) ＋ 2)×2) ＋ 4
＝ 16
semmni ＝ 24(web001の必要数) ＋ 16(web002の必要数) ＝ 40
－ semmns
semmniと同様に計算してください。
－ semmnu
web001の必要数 ＝
(((2(IJServerワークユニット数の合計値) ＋
6(各IJServerワークユニットのプロセス多重度の合計値) ＋
2)×2) ＋ 4) × 50
- 96 -
＝ 1200
web002の必要数 ＝
(((1(IJServerワークユニット数の合計値) ＋
3(各IJServerワークユニットのプロセス多重度の合計値) ＋
2)×2) ＋ 4) × 50
＝ 800
semmnu ＝ 1200(web001の必要数) ＋ 800(web002の必要数) ＝ 2000
セマフォ
パラメタ
種類
必要数
para1
設定値
1以上
para2
加算値
以下をWebサーバごとに求めた合算値 (注)
・ ((IJServerワークユニット数の合計値 ＋
各IJServerワークユニットのプロセス多重度の合計値 ＋ 2)×2)
＋4
para3
設定値
2 以上
para4
加算値
以下をWebサーバごとに求めた合算値 (注)
・ ((IJServerワークユニット数の合計値 ＋
各IJServerワークユニットのプロセス多重度の合計値 ＋ 2)×2)
＋4
注)
チューニングの例を以下に示します。
条件
IJServerワークユニット
Webサーバ
WU001
プロセス多重度:3
WU002
プロセス多重度:3
WU003
プロセス多重度:3
web001
接続先:WU001、WU002
web002
接続先:WU003
－ para2
web001の必要数 ＝
((2(IJServerワークユニット数の合計値) ＋
6(各IJServerワークユニットのプロセス多重度の合計値) ＋ 2)×2) ＋ 4
＝ 24
web002の必要数 ＝
((1(IJServerワークユニット数の合計値) ＋
3(各IJServerワークユニットのプロセス多重度の合計値) ＋ 2)×2) ＋ 4
＝ 16
para2 ＝ 24(web001の必要数) ＋ 16(web002の必要数) ＝ 40
－ para4
para2と同様に計算してください。
Webサーバコネクタの故障監視機能
Webサーバコネクタの故障監視機能を使用する場合に追加となるシステム資源について、以下に示します。
共用メモリ
- 97 -
パラメタ
資源制御
種類
必要数
shmmax
－
設定値
6,720,012 以上
－
project.maxshm-memory
加算値
6,720,012 × (Webサーバ数 + 1)
shmmni
project.maxshm-ids
加算値
Webサーバ数 + 1
共用メモリ
パラメタ
種類
必要数
kernel.shmmax
設定値
6,720,012 以上
kernel.shmmni
加算値
Webサーバ数 + 1
セマフォ
パラメタ
資源制御
種類
必要数
semmni
project.maxsem-ids
加算値
3
semmns
(注)
－
加算値
3
semmnu
(注)
－
加算値
2
semume
(注)
－
加算値
2
注)
Solaris 9でのみ有効です。
セマフォ
パラメタ
種類
必要数
para1
設定値
2 以上
para2
加算値
3
para3
設定値
2 以上
para4
加算値
3
3.1.13 Java EEのシステム資源の設定
Interstage Java EEの運用に必要なシステム資源について説明します。
Webサーバコネクタのシステム資源の設定
WebサーバとIJServerクラスタを連携させる場合は、「チューニングガイド」の「Webサーバコネクタのシステム資源の設定」の内容にした
がってシステムパラメタを設定してください。その際、「IJServerワークユニット」は「IJServerクラスタ」に読み替えて設定してください。
3.2 マルチサーバ管理機能を使用する時に必要なシステム資源
Interstageのマルチサーバ管理機能を使用する時に必要となるシステム資源について説明します。
なお、システムパラメタを算出するためのExcelファイルがマニュアルCDの“ApplicationServer\tuning”配下のサブフォルダに“ISASIPCtuning.xlsx”として格納されています。Microsoft(R) Excel 2007もしくは以降のバージョンのMicrosoft(R) Excelをお持ちの場合は
- 98 -
“ISAS-IPCtuning.xlsx”を使用してシステムパラメタを算出することが可能です。使用方法などの詳細については、当該Excelファイル
内の説明記事を参照してください。
■管理サーバ機能を使用する場合
管理サーバ機能を使用する場合は、“Interstage ディレクトリサービス”のシステム資源が必要です。
管理サーバ機能を使用する場合に必要なシステム資源量は、“3.1 サーバ機能運用時に必要なシステム資源”の同一サービスの説
明を参照してください。
■管理対象サーバとして運用する場合
管理対象サーバとして運用する場合は、使用する機能に関するシステム資源が必要です。必要量については、“3.1 サーバ機能運
用時に必要なシステム資源”の同一サービスの説明を参照してください。
■共存サーバとして運用する場合
共存サーバでは管理サーバ機能とInterstageのサーバ機能(管理対象サーバ)が同一マシン上で動作しています。共存サーバ運用
時に必要なシステム資源については、“■管理サーバ機能を使用する場合”と“■管理対象サーバとして運用する場合”を参照して使
用するサービスを列挙してください。各サービスが必要とするシステム資源は、“3.1 サーバ機能運用時に必要なシステム資源”の同一
サービスの説明を参照してください。
管理サーバ機能とInterstageのサーバ機能で同一サービスを使用する場合、そのサービスの必要資源量を2倍する必要はありませ
ん。
3.3 性能監視ツール使用時に必要なシステム資源
性能監視ツールで性能監視環境として使用する資源の見積もり方法を説明します。
3.3.1 システム構成情報の見積もり方法 (Solarisの場合)
システム構成情報は、以下の見積もり式を参考に見積もり、見積もり値以上の値を設定してください。
セマフォ
システム構成情報
資源制御
種類
見積もり
semsys:
seminfo_semmnu (注1)
－
加算値
セマフォ数 (*)
semsys:
seminfo_semmni
project.maxsem-ids
加算値
1
semsys:
seminfo_semmns (注1)
－
加算値
セマフォ数 (*)
semsys:
seminfo_semmsl
process.maxsem-nsems
設定値
セマフォ数 (*) 以上の値
*)
セマフォ数 ＝ 性能監視ツール起動時に指定する共有メモリ量(MB) × 10 ＋ 2
ただし、最大52
- 99 -
注1)
Solaris 10以降の場合、指定する必要はありません。
共有メモリ
システム構成情報
資源制御
種類
見積もり
shmsys:
shminfo_shmmax
project.maxshm-memory
設定値
“3.3.3 共有メモリ量の見積もり方法”を参照
shmsys:
shminfo_shmmni
project.maxshm-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 共有メモリ量の見積もり方法”を参照
kernel.shmmni
加算値
1
3.3.3 共有メモリ量の見積もり方法
共有メモリ量は、以下の見積もり式を参考に必要な共有メモリ量を求め、その共有メモリ量をメガバイト単位に切り上げた値で見積もっ
てください。
変更方法の詳細については、“■システムパラメタについて”を参照してください。
共有メモリ量の見積もり(単位:バイト)
1. 性能監視ツールの性能監視対象とする全オブジェクト（アプリケーション）に対して、オブジェクト（アプリケーション）ごとに必要な
共有メモリ量を、以下の方法で求めてください。
a. 各オブジェクト（アプリケーション）に定義されているプロセス多重度を確認してください。
b. 各オブジェクト（アプリケーション）に定義されているスレッド多重度を確認してください。
- 100 -
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パラメタのチューニング方法を説明します。
■チューニング方法
レジストリエディタを使用して以下のレジストリ情報を追加した後、システムを再起動してください。
・ レジストリキー:
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」が表示される場合
があります。
上記情報を追加することで、使用可能なソケット数を増やし、また、使用済みのソケットを早く開放するようになります。
- 101 -
・ レジストリ情報がない場合は、新しく作成してください。
・ 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に対して影響を与えるため、システム管理者に相談してから実施してください。
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キー値の重複発生を通知するメッセージが出力された場合は、この対処により運用することができます。
- 102 -
■概要
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”となります。
・
クラスタシステムを使用する場合、MQDシステム用の定義ファイルは、mqd環境定義ファイル中の以下で指定したディレクトリの中
に定義ファイル(ipc_key)を作成してください。
－ [Cluster]
SystemDirectory = MQDのクラスタサービスが使用するディレクトリの名前
FFF
この定義例の場合、Interstageが使用する上位20ビットを0x01280とすると、IPCキー値は、16進表示で、以下のようになります。
0x01280FFF
・ IPCキー値の定義は、Interstageを全強制停止モードで停止し、さらにInterstage JMXサービスを停止してから行ってください。
Interstageの運用中に本定義を変更しないでください。
・
IPCキー値の定義は、システム間で重複することのないように定義してください。
- 103 -
第4章 ワークユニットのチューニング
ワークユニットには、様々な機能があり、これらをチューニングすることで、最適な状態での運用を行うことが可能となります。ここでは、
ワークユニットのチューニングについて説明します。
4.1 ワークユニット数、オブジェクト数、プロセス数のチューニング
起動できるワークユニット数、オブジェクト数およびプロセス数は以下の条件式を満たす必要があります。
(ワークユニット数×２)＋(オブジェクト総数×ｍ)＋(プロセス総数×ｎ)＋１ ≦ 2010
この条件式を超えてワークユニットを起動する場合は、大規模システム用環境定義ファイルをコピーする必要があります。なお、Linux
for Intel64版では、標準で大規模システム用環境定義ファイルが使用されています。
大規模システム用環境定義ファイルを使用した場合、以下の条件式まで起動できるワークユニット数、オブジェクト数およびプロセス
数が拡張されます。
(ワークユニット数×２)＋(オブジェクト総数×ｍ)＋(プロセス総数×ｎ)＋１ ≦ 6030
条件式のオブジェクト総数とは、ワークユニット定義の[Application Program]セクションの総数です。
IJServerの場合、各ワークユニットのオブジェクト数は以下となります。
オブジェクト数
IJServerタイプ
WebアプリケーションとEJBアプリケーションを同一JavaVMで運用
1
Webアプリケーションのみ運用
EJBアプリケーションのみ運用
WebアプリケーションとEJBアプリケーションを別JavaVMで運用
2
条件式のｍ、ｎについては、ｍ＝１、ｎ＝２を基準値とし、以下に該当する場合は、変更してください。
・ islistwuおよびislistobjコマンドを使用する場合
ｍ＝２
・ islistaplprocコマンドを使用する場合
ｎ＝３
・ Interstage管理コンソールを使用する場合
ｍ＝２、ｎ＝３
大規模システム用環境定義ファイル
コピー元
コピー先
Interstageインストール先フォルダ\extp
\etc\sys\td\extp.ini.large
Interstageインストール先フォルダ\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
通常システム用環境定義ファイル
通常のシステム定義に復元する場合は、以下の通常システム用環境定義ファイルをコピーしてください。
- 104 -
コピー元
コピー先
Interstageインストール先フォルダ\extp
\etc\sys\td\extp.ini
Interstageインストール先フォルダ\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秒を設定しています。
業務運用中にワークユニットを停止することがある場合は、アプリケーション処理時間を考慮する必要があります。以下の条件式を参
考にしてください。
プロセス強制停止時間はアプリケーションの処理時間とプロセスの停止処理時間の合計を上回るように設定してください。
プロセス強制停止時間(秒) ＞ アプリケーション処理時間(秒) ＋ アプリケーションプロセス停止処理時間(秒)
- 105 -
アプリケーション処理時間：
アプリケーション処理中にワークユニットを停止するような運用を実施する場合、そのアプリケーションの処理が正常に完了するために
必要な、最も長い時間を設定してください。
ワークユニット同期停止は、アプリケーション処理中に実行すると、処理中の要求が完了するのを待ってからプロセスを停止します。
アプリケーション処理時間の考慮がされていないと、ワークユニット同期停止において、処理中の要求が途中で強制終了されます。
注)IJServerワークユニットの通常停止は同期停止と同じ動きとなります。
アプリケーションプロセス停止処理時間：
■条件式のアプリケーションプロセス停止処理時間を参照してください。
アプリケーション処理時間が120秒で、アプリケーションプロセス停止処理時間が5秒の場合、プロセス強制停止時間は、126秒以上を
設定してください。
4.3 CORBAワークユニットのチューニング
CORBAワークユニットは、以下の製品で使用可能です。
・ Interstage Application Server Enterprise Edition
ワークユニットのチューニングについては、以下のマニュアルを参照してください。
・ “OLTPサーバ運用ガイド”の“ワークユニットの作成”
・ “OLTPサーバ運用ガイド”の“CORBAワークユニット”
4.4 IJServerワークユニットのチューニング
IJServerワークユニットについては、以下を参照してください。
・ “J2EE ユーザーズガイド(旧版互換)”－“IJServerのチューニング”
4.5 トランザクションアプリケーションのチューニング
トランザクションワークユニットは、以下の製品で使用可能です。
・ Interstage Application Server Enterprise Edition
トランザクションワークユニットについては、以下のマニュアルを参照してください。
・ “OLTPサーバ運用ガイド”の“ワークユニットの作成”
・ “OLTPサーバ運用ガイド”の“トランザクションアプリケーションのワークユニット”
4.6 ラッパーワークユニットのチューニング
ラッパーワークユニットは、以下の製品で使用可能です。
・ Interstage Application Server Enterprise Edition
ラッパーオブジェクトワークユニットについては、以下のマニュアルを参照してください。
・ “OLTPサーバ運用ガイド”の“ワークユニットの作成”
・ “OLTPサーバ運用ガイド”の“ラッパーオブジェクトのワークユニット”
4.7 ユーティリティワークユニットのチューニング
ユーティリティワークユニットは、以下の製品が使用可能です。
・ Interstage Application Server Enterprise Edition
- 106 -
ユーティリティワークユニットについては、以下のマニュアルを参照してください。
・ “OLTPサーバ運用ガイド”の“ワークユニットの作成”
・ “OLTPサーバ運用ガイド”の“ユーティリティのワークユニット”
- 107 -
第5章 Java EE機能のチューニング
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"キー値"="設定する値"
運用管理用HTTPリスナーのポート番号を変更する場合
以下の手順で変更します。
1. Interstage Java EE DASサービスの起動
以下のサービスを起動します。
- Interstage Java EE DASサービス
- 108 -
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ファイル」
を参照してください。
例
ポート番号を8929に変更する場合
AS_ADMIN_PORT=8929
AS_ADMIN_PROFILE=cluster
AS_ADMIN_SECURE=true
AS_ADMIN_REALM=os
4. Interstage Java EE DASサービスの再起動
以下のサービスを再起動します。
- Interstage Java EE DASサービス
ijdasstopコマンドを実行後、ijdasstartコマンドを実行してサービスを再起動します。
運用管理用HTTPリスナーのポート番号を変更する場合(Interstage Java EE DASサービスを起動できない場合)
運用管理用HTTPリスナーのポートが他のアプリケーションで使用されているなど、Interstage Java EE DASサービスを起動できない場
合は、domain.xmlを修正します。
domain.xmlの修正方法
以下のファイルをテキストエディタなどで開いて、name属性に「server-config」が設定されているconfigタグ配下のhttp-listenerタグのport
属性を編集します。
ファイルの格納先
[Java EE共通ディレクトリ]\domains\interstage\config\domain.xml
[Java EE共通ディレクトリ]/domains/interstage/config/domain.xml
- 109 -
例
ポート番号を8929に変更する場合
<config dynamic-reconfiguration-enabled="true" name="server-config">
<http-service>
<access-log ・・・
<http-listener ・・・
<!-- Interstage Java EE DAS port number -->
<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サービスの起動
以下のサービスを起動します。
- 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ファイルを修正します。
修正方法の詳細は、「リファレンスマニュアル(コマンド編)」の「Java EE運用コマンド」－「asadmin」の「asadminenv.confファイル」
を参照してください。
例
SSL通信を利用する設定に変更する場合
AS_ADMIN_PORT=12001
AS_ADMIN_PROFILE=cluster
- 110 -
AS_ADMIN_SECURE=true
AS_ADMIN_REALM=os
4. Interstage Java EE DASサービスの再起動
以下のサービスを再起動します。
- Interstage Java EE DASサービス
ijdasstopコマンドを実行後、ijdasstartコマンドを実行してサービスを再起動します。
監視サービスの定義項目を有効にする場合
IJServerクラスタや、Interstage Java EE DASサービスの監視サービスの定義項目を有効にすると、サーバーインスタンス数、配備済み
のアプリケーション数に応じてInterstage Java EE DASサービスのメモリが使用されます。
監視サービスを有効に設定した場合は、Interstage Java EE DASサービスでメモリ不足が発生していないことを確認してください。メモ
リ不足が発生した場合は、「5.15 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"/>タグの数値を、見積もり式で計算した値に修正します。
5. Interstage Java EE DASサービスを起動します。
6. Interstage Java EE Node Agentサービスを起動します。
注意
・ その他の設定値は修正しないでください。
・ サーバーインスタンスを増やすと、システム全体のメモリ使用量が増加する場合があるため注意してください。
- 111 -
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領域サイズを変更できます。
項目
デフォルト値
Java VMオプション
Java VMの最大ヒープ領域サイズ
-Xmx
-Xmx256m
Java VMのPerm領域サイズ
-XX:MaxPermSize
-XX:MaxPermSize=192m
Java VMオプションの値は、Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更できます。詳細については、以
下のマニュアルを参照してください。
・ Interstage Java EE管理コンソールヘルプ
・ 「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」
・ 「リファレンスマニュアル(コマンド編)」－「configs.config.java-configの定義項目」
- 112 -
アプリケーションの運用中に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コマンドを使用して変更できます。詳細については、以
下のマニュアルを参照してください。
・ Interstage Java EE管理コンソールヘルプ
・ 「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」
・ 「リファレンスマニュアル(コマンド編)」－「configs.config.java-configの定義項目」
なお、RMI機能による自動ガーベジコレクションの発生間隔をチューニングしても、ガーベジコレクション発生回数が削減されない場
合、Java VMのヒープ領域サイズが不足している可能性があります。この場合、Java VMのヒープ領域サイズのチューニングを行うこと
で削減される場合があります。「5.3.2 Java VMのヒープ領域サイズ/Perm領域サイズ」を参照してください。
5.3.4 アプリケーション最大処理時間
想定される業務アプリケーションの最大処理時間を指定します。
アプリケーション最大処理時間の値は、Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更できます。詳細につ
いては、以下のマニュアルを参照してください。
・ Interstage Java EE管理コンソールヘルプ
・ 「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」
・ 「リファレンスマニュアル(コマンド編)」－「configs.config.ijserver-controlの定義項目」
5.3.5 グループ管理サービスの設定
IJServerクラスタはサーバーインスタンスが互いに起動状態を監視するためにグループ管理サービスを使用します。このサービスを利
用する機能については「Java EE運用ガイド」－「グループ管理サービス」を参照してください。
このサービスを使用すると、クラスタに設定されているハートビートアドレスとハートビートポートに各サーバーインスタンスが定期的に
ハートビートの信号を送信し、その信号を別のサーバーインスタンスが受信することでサーバーインスタンスが正常に運用されているこ
とを認識します。ハートビート信号が送信されなかったサーバーインスタンスについては、停止しているか異常が発生していると判断し
て、グループから除外されます。
定期的に信号が送受信されるため、以下のような場合には各種定義をチューニングすることができます。また、このグループ管理サー
ビスを使用する必要がない場合にはハートビートを無効にすることで、信号の送受信を行わないように変更できます。
・ ネットワーク負荷が高いため、定期的な信号の送受信間隔を大きくしてサーバ負荷を軽減したい。
・ 頻繁にアクセスがなく、システムでリアルタイムに異常を検知する必要がないため、異常を検知するまでの時間は若干遅くても良
いので、サーバの負荷を軽減したい。
以下に各種定義項目のチューニング観点を説明します。各信号を送信する時にはマルチキャストポートに対して約3300バイトのデー
タを送信します。プロトコル最大試行/検証済みタイムアウト/pingタイムアウトは、値を小さくすると異常を検知するまでの時間を短くする
ことができますが、一時的な高負荷状態をサーバーインスタンスが停止しているか異常が発生していると判断する場合がありますの
で、特に理由がなければデフォルト値を使用することをお勧めします。
- 113 -
定義項目
チューニング観点
プロトコルタイムアウト
指定した間隔で約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コマンドを利用してセッションタイムアウト値を変更します。
－ 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サービスを再起動します。
- 114 -
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>
<param-value>-1</param-value>
</init-param>
3. Interstage Java EE DASサービスを起動します。
注意
アップロードファイルの最大サイズを増やす場合や無制限にする場合、以下に注意してください。
・ ファイルサイズの大きいアプリケーションの配備(再配備)は時間がかかります。
配備(再配備)処理中にInterstage Java EE DASサービスの停止やマシンの再起動を行わないでください。
・ 2Gバイトを超えるファイルは配備(再配備)できません。2Gバイト未満のファイルを指定して配備(再配備)を行ってください。
- 115 -
5.4.3 ポート番号
Interstage Java EE管理コンソールで使用するHTTPリスナーポートは、Interstage Java EE DASサービスの運用管理用HTTPリスナー
ポートと同一です。
HTTPリスナーポートのポート番号を変更する場合の手順を以下に示します。
1. ポート番号の変更
Interstage Java EE管理コンソールまたはasadminコマンドを利用してポート番号を変更します。
－ Interstage Java EE管理コンソールを利用する場合
以下の画面から「リスナーポート」の値を変更します。
[設定] > [server-config] > [HTTPサービス] > [HTTPリスナー] > [admin-listener]
－ asadminコマンドを利用する場合
asadminコマンドのsetサブコマンドによりポート番号を変更します。
変更方法については、「5.1 Interstage Java EE DASサービスのチューニング」の「運用管理用HTTPリスナーのポート番号を
変更する場合」を参照してください。
2. サービスの再起動
Interstage Java EE DASサービスを再起動します。
ijdasstopおよびijdasstartコマンドを実行して、Interstage Java EE DASサービスを再起動します。
5.4.4 SSL通信の利用
Interstage Java EE管理コンソールでSSL通信を行うための設定は、Interstage Java EE DASサービスの運用管理用HTTPリスナーのSSL
通信利用設定と同じです。
SSL通信を行うための設定を変更する場合の手順を以下に示します。
1. SSL通信利用設定の変更
Interstage Java EE管理コンソールまたはasadminコマンドを利用してSSL通信利用設定を変更します。
－ Interstage Java EE管理コンソールを利用する場合
以下の画面から「セキュリティー」の設定を変更します。
[設定] > [server-config] > [HTTPサービス] > [HTTPリスナー] > [admin-listener]
- SSL通信を行う場合
「セキュリティー」の「有効」のチェックボックスを選択します。
- SSL通信を行わない場合
「セキュリティー」の「有効」のチェックボックスの選択を解除します。
－ asadminコマンドを利用する場合
asadminコマンドのsetサブコマンドによりSSL通信利用設定を変更します。
変更方法については、「5.1 Interstage Java EE DASサービスのチューニング」の「運用管理用HTTPリスナーのSSL通信利用
設定を変更する場合」を参照してください。
2. サービスの再起動
Interstage Java EE DASサービスを再起動します。
ijdasstopおよびijdasstartコマンドを実行して、Interstage Java EE DASサービスを再起動します。
- 116 -
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コマンドを使用して変
更できます。詳細については、以下を参照してください。
・ Interstage Java EE管理コンソールヘルプ
・ 「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つに分類できます。
・ 同時処理数(初期スレッド数、スレッド数、スレッドの増分)
・ 接続数(WebサーバコネクタのWebコンテナへの最大接続数、最大保留カウント、キューサイズ)
Webコンテナの処理の流れの5.は同時処理数に関係しています。
5.は「初期スレッド数」、「スレッド数」、「スレッドの増分」で設定することが可能です。
Webコンテナの処理の流れの1.、2.、3.は接続数に関係しています。
1.は「WebサーバコネクタのWebコンテナへの最大接続数」で設定することが可能です。
2.は「最大保留カウント」で設定することが可能です。
3.は「キューサイズ」で設定することが可能です。
以下に、リクエストの流れを基に各設定項目の関係を示します。
- 117 -
同時処理数
同時処理数およびサーバーインスタンスを追加すると、Webアプリケーションの同時実行多重度を増やせます。
同時処理数を増やすと、1プロセスあたりの実行多重度を増やせますが、同時処理数が増えることによる負荷や資源の増加により効果
はみられない可能性があります。通常はデフォルト値以下で運用することを推奨しています。
アプリケーションから呼び出すEJBの「5.7.3 Enterprise Beanインスタンスのプーリング」と「5.7.2 Enterprise Beanインスタンスのキャッシン
グ」、JDBCのコネクション数にあわせてチューニングしてください。
同時処理数については、以下が設定できます。
・ 初期スレッド数
・ スレッド数
・ スレッドの増分
同時処理数は、Interstage Java EE管理コンソールの[設定] > [クラスタ名-config] または [server-config] > [HTTP サービス] > [要求処
理]タブ、およびasadminコマンドを使用して変更できます。詳細については、以下のマニュアルを参照してください。
・ Interstage Java EE管理コンソールヘルプ
・ 「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」
・ 「リファレンスマニュアル(コマンド編)」－「configs.config.http-serviceの定義項目」の
request-processing.thread-count(スレッド数)
request-processing.initial-thread-count(初期スレッド数)
request-processing.thread-increment(スレッドの増分)
接続数
接続数は、運用するシステムの要求の違いによって以下のように設定します。
・ Webコンテナの負荷が高く処理できないリクエストは、時間がかかってもかまわないので、正常に処理させたい場合
- 118 -
項目
設定値
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コンテナが同時に受け付けることができるリクエスト数を増やせます。運用中に高負荷な状態となった
場合に想定される、クライアントからの同時リクエスト数を指定しておくことを推奨します。
最大保留カウントは、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
によって有効となる範囲が決まっていますので、最大保留カウントに設定した値がすべて有効となるわけではありません。
- 119 -
Socketのbacklogの有効範囲については各OSのドキュメントを参照してください。
なお、Windows (R)の場合、200より大きな値を設定しても有効になりません。
Webコンテナのキューサイズ
本項目の値を増やすと、Webコンテナが受け付けたクライアントからのリクエストを、Webコンテナが処理できるようになるまでの間保
持する数を増やせます。
運用時に一時的に負荷が高くなり、Webコンテナの同時処理数を超えるリクエストを受け付けることが想定される場合は、Webコン
テナの同時処理数を抑えて、Webコンテナのキューサイズに大きな値を設定することで、サーバ全体のレスポンスの悪化を防ぐこと
ができます。
－ 設定ポイント1:
運用時に一時的に負荷が高くなり、クライアントからのリクエスト処理に失敗しかつ、サーバーログにWEB1505が出力されてい
る場合は、キューサイズを大きくしてください。
－ 設定ポイント2:
キューサイズを増やしてリクエストを処理することができるだけの十分に大きなキューを用意した場合、クライアントからのリクエ
ストに対するレスポンスに遅れが生じる可能性があります。Webサーバコネクタの送受信タイムアウト値を増やしてください。
キューサイズは、Interstage Java EE管理コンソールの[設定] > [クラスタ名-config] または [server-config] > [HTTPサービス] > [接
続プール]タブ、およびasadminコマンドを使用して変更できます。詳細については、以下のマニュアルを参照してください。
－ Interstage Java EE管理コンソールヘルプ
－ 「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」
－ 「リファレンスマニュアル(コマンド編)」－「configs.config.http-serviceの定義項目」の
connection-pool.queue-size-in-bytes
Webサーバコネクタの送受信タイムアウト
－ WebサーバとWebコンテナを同一マシン内で運用する場合
Interstage Java EE管理コンソールの[クラスタ] または[スタンドアロンインスタンス] > [クラスタ名] または[サーバーインスタンス
名] > [Webサーバコネクタ]タブ、およびasadminコマンドを使用して変更できます。詳細については、以下のマニュアルを参照
してください。
- Interstage Java EE管理コンソールヘルプ
- 「リファレンスマニュアル(コマンド編)」－「update-web-server-connector-configサブコマンド」の--sendreceivetimeoutオプショ
ン
－ WebサーバとWebコンテナをそれぞれ別のマシンで運用する場合
Webサーバを運用するマシン側で設定します。
Interstage管理コンソールからWebサーバコネクタの送受信タイムアウトで設定します。また、isj2eeadminコマンドでも設定できま
す。詳細については、以下のマニュアルを参照してください。
- Interstage管理コンソールのヘルプ
- 「リファレンスマニュアル(コマンド編)」の「isj2eeadmin」
キープアライブ
キープアライブに関する設定項目について、以下に説明します。
キープアライブの有効/無効および、1回のコネクションで処理可能なリクエスト数
本項目では、HTTPのキープアライブの有効/無効および、1回のコネクションで処理可能なリクエスト数を設定します。
"無効"を指定した場合は、1つのリクエストが完了するたびに接続を閉じて、次のリクエストに対して新しく接続を行います。
"有効"を指定した場合は、Webコンテナがレスポンスを返した後、次のリクエストが来るまでの間、HTTP接続を確立し、リクエストの
転送効率を向上させることができます。
初期値は、"無効"です。
IPCOMなどの負荷分散装置と連携する場合は、負荷分散装置のキープアライブ機能の設定と合わせる必要があります。詳細につ
いては、負荷分散装置のマニュアルを参照してください。
- 120 -
キープアライブの有効/無効および、1回のコネクションで処理可能なリクエスト数は、Interstage Java EE管理コンソールの[設定] >
[ ク ラ ス タ 名 -config] ま た は [server-config] > [HTTP サ ー ビ ス ] の [ 追 加 プ ロ パ テ ィ ] お よ び asadmin コ マ ン ド を 使 用 し
て、"maxKeepAliveRequests"プロパティで変更することができます。詳細については、以下のマニュアルを参照してください。
－ Interstage Java EE管理コンソールヘルプ
－ 「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」
－ 「リファレンスマニュアル(コマンド編)」－「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 EJBコンテナのチューニング
EJBコンテナをチューニングする時に、考慮するポイントについて説明します。
5.7.1 スレッドプーリング
クライアントからEnterprise JavaBeanに対して同時に要求が発行された場合、EJBコンテナは要求を別スレッドで実行して並列処理します。
スレッドの作成処理はレスポンス時間に影響するため、スレッドプールを活用してスレッドを再利用しています。
スレッドプーリングは以下のチューニングを行うことができます。
・ EJBアプリケーションの同時処理数制御
・ リクエストの優先順位付け
スレッドはEnterprise JavaBeanのアクセスパターンにより、制御が異なります。以下にEnterprise JavaBeanのアクセスパターンとスレッド
制御の関係を説明します。
Enterprise JavaBeanのアクセスパターンとスレッド制御の関係
以下にEnterprise JavaBeanのアクセスパターンを示します。
- 121 -
EJBコンテナがスレッド制御を行うアクセスパターン
以下の場合はEJBコンテナがスレッドプールを使用してスレッド制御します。
－ RMI-IIOPによるリモートアクセスによりEnterprise JavaBeanに対して要求が発行される場合
－ JMSメッセージが受信され、Message-driven Beanが実行される場合
－ リソースアダプタのメッセージが受信され、Message-driven Beanが実行される場合
呼出し元のスレッドで動作するアクセスパターン
以下のJava VM内の呼出しの場合は呼出し元のスレッドで動作します。
－ EJB間の呼出し
－ Servlet/JSPからのEJB呼出し
－ WebサービスからのEJB呼出し
－ JPA Entityに対する操作
HTTP通信によるアクセスの場合はスレッドのチューニングについては、「5.6 Webコンテナのチューニング」と「5.9 Webサービスの
チューニング」を参照してください。
リソースアダプタのスレッドで動作するアクセスパターン
リソースアダプタのメッセージを受信するMessage-driven Beanの場合、メッセージリスナーメソッドはリソースアダプタが作成したス
レッドで動作します。
EJBアプリケーションの同時処理数制御
IJServerクラスタプロセス起動時にスレッドプールの最小プールサイズのスレッドを作成しプールに格納します。
要求の処理開始前にプールを検索し、プールにスレッドがない場合、スレッドを作成して要求を実行します。
処理完了後、作成したスレッドは削除されることなくプールに返却されます。現在のスレッド数がスレッドプールの最大プールサイズと
なり、プールにスレッドがない状態で要求が配信された場合、スレッドがプールに戻るまで要求をキューに入れて待機します。
- 122 -
リクエストの優先順位付け
RMI-IIOPによるリモートアクセスが行われるEJBアプリケーションでは、EJBアプリケーションごとにスレッドプールを作成し最大プール
数を指定することにより、EJBアプリケーションごとに同時処理数を制御できます。
EJBアプリケーションに個別にスレッドプールを割り当てることによって、他のリモートアクセス対象のEJBアプリケーションよりも高い優
先度で実行できます。個別のスレッドプールに割り当てられたEJBアプリケーションは、他のEJBアプリケーションに対する要求がスレッ
ドプールでキューイングされていても独立したスレッドプールで実行できるため、優先的に実行できます。
スレッドプールの設定
以下にスレッドプールのチューニング項目について説明します。
チューニング項目
意味
効果
最小プールサイズ
スレッドプールの初期数および最小数です。
IJServerクラスタ起動時に作成するスレッド数です。
想定している同時に発行さ
れる要求数を指定するとレ
スポンスタイムを削減できま
す。
最大プールサイズ
スレッドプールの最大値です。
最大値のスレッドが動作した場合、要求が発行されて
もスレッドを作成せず、スレッドが空くまで、要求はキュー
に置かれます。
スレッドプールの最大値に
よりスレッドプールが使用す
るメモリやリソースを制御で
きます。
アイドルタイムアウト
プール内のスレッドがアイドル状態のままでいられる最
長時間(秒単位)です。
この期間を過ぎるとスレッドを破棄します。ただし、最小
値のスレッド数分はプーリングされ続けますので破棄
対象外となります。また、IJServerクラスタプロセスが停
止するとスレッドも削除されます。
不要になった過度のスレッ
ドを破棄することによりメモリ
やリソースの最適化ができ
ます。
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)
- 123 -
＋ 呼出し先IJServerクラスタのプロセス数 (注3)
注1) スレッドプールIDを定義していないリソースアダプタだけ。
注2) 想定されるスレッド多重度の合計。
注3) 他IJServerクラスタのEJBアプリケーションなどを呼び出した場合の、呼出し先IJServerクラスタのプロセス数。
スレッドプールの作成
スレッドプールは、Interstage Java EE管理コンソール、およびasadminコマンドを使用して作成できます。詳細は、以下のマニュアル
を参照してください。
－ Interstage Java EE管理コンソールヘルプ
－ 「リファレンスマニュアル（コマンド編）」の「create-threadpoolサブコマンド」
スレッドプールの設定値は、Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更できます。詳細は、以下の
マニュアルを参照してください。
－ Interstage Java EE管理コンソールヘルプ
－ 「リファレンスマニュアル（コマンド編）」の「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>タグ
5.7.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持続性のタイプ」によって、キャッシングのチューニング項目の動作が変わります。
以下の表にキャッシング機能を制御するチューニング項目を説明します。
- 124 -
チューニング項目
効果
最大キャッシュサイズ
同時にアクセスするクライアント数に設定することにより、メモリ
の使用量を削減できます。
キャッシュのサイズ変更量
要求のピークが終わって不要になったインスタンスを素早く破
棄することによりメモリ消費を低減できます。
本設定はSFSB持続性のタイプがfileのときのみ有効です。
キャッシュアイドルタイムアウト
クライアントがBeanに対してRemove要求を発行し忘れている場
合に、不要なBeanインスタンスが自動的に消去されるため、不
要なメモリの増加を防ぐことができます。
削除タイムアウト
長時間使用されていない不要なBeanインスタンスが消去される
ため、資源の最適化ができます。
本設定はSFSB持続性のタイプがfileのときのみ有効です。
選択内容の削除ポリシー
削除ポリシーをBeanの使用パターンに合わせることでSFSB持
続性のタイプがnoneのとき、使用頻度の低いBeanインスタンス
をキャッシュから削除できます。また、SFSB持続性のタイプが
fileのとき頻繁に使用されるBeanインスタンスのpassivateと
activate処理による性能劣化を縮小できます。
EJBコンテナがpassivateするインスタンスの保存場所は以下のチューニング項目で変更できます。
チューニング項目
セッション格納位置
効果
例えば容量にゆとりがある任意のディスクドライブを指定して資
源配置の最適化を図ったり、ファイルI/Oが速い任意のディスクド
ライブを指定することによりファイル化したBeanインスタンスの操
作速度を向上させることができます。
本設定はSFSB持続性のタイプがfileのときのみ有効です。
デフォルトの格納場所とそのディレクトリ配下の構成については、「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コマンドを使用して変更できます。詳細については、以下のマニュアルを参照してください。
・ Interstage Java EE管理コンソールヘルプ
・ 「リファレンスマニュアル(コマンド編)」－「setサブコマンド」の「configs.config.ejb-containerの定義項目」
注意
Interstage Java EE DASサービスではSFSB持続性のタイプは「none」固定となります。
SFSB持続性のタイプ「none」で運用する場合の注意事項
・ EJBコンテナはIJServerクラスタの停止時にキャッシュしている全Beanインスタンスを削除します。
SFSB持続性のタイプ「file」で運用する場合の注意事項
- 125 -
・ 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せずに終了します。
5.7.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タイマーによるコールバック処理の場合にも同様に、プールからインスタンスを取得しタイマーコールバックメソッドを実行し、実行
完了時にインスタンスをプールに戻します。
以下の表にプーリング機能を制御するチューニング項目を説明します。
チューニング項目
効果
初期および最小プールサイズ
インスタンスをあらかじめ生成しておくことにより、プールされている
インスタンスを利用してすぐに実行できるため処理性能が向上しま
す。
最大プールサイズ
プールの最大値によりメモリ使用量を制御できます。
プールサイズ変更量
クライアントからの要求数の急増によってメソッド実行可状態のイン
スタンスが足りなくなった場合でも、プールサイズの即時拡張により、
インスタンス生成処理によるレスポンス遅延が軽減されます。
プールアイドルタイムアウト
不要になった過度のインスタンスを破棄することによりメモリの最適
化ができます。
- 126 -
注) プールの監視は指定値の間隔で実施しますが、起動後に1回行った後はEJBアプリケーションの使用状況を確認し、使用されてい
ないBeanインスタンスはプールサイズを調整しません。
注意
Message-driven Beanはインスタンスごとにセッションを使用してメッセージを受信します。そのため、プールの最大値を2以上に設定す
るとメッセージ順序性が保証されません。
プール設定はEnterprise Beanごとに指定できます。定義詳細については、以下のマニュアルを参照してください。
・ 「Java EE運用ガイド」－「Interstage EJB application deployment descriptor (sun-ejb-jar.xml)」の<ejb><bean-pool>タグ
Enterprise Beanのキャッシュ設定を指定しない場合はIJServerクラスタの値が使用されます。この値は、Interstage Java EE管理コンソー
ル、およびasadminコマンドを使用して変更できます。詳細については、以下のマニュアルを参照してください。
・ Interstage Java EE管理コンソールヘルプ
・ 「リファレンスマニュアル(コマンド編)」－「setサブコマンド」の「configs.config.ejb-containerの定義項目」、または「configs.config.mdbcontainerの定義項目」
5.7.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.8 JPAのチューニング
JPAはOLTP系(データの検索が多く、更新が少ない)のJava EEアプリケーションによく使用されます。Interstage永続性プロバイダはデー
タベースで検索したデータをキャッシングすることにより性能を向上させることができます。
Interstage永続性プロバイダのチューニングオプションにはデータベースを検索したデータから作成するEntityインスタンスをキャッシュ
するオプションが用意されています。これに合わせてJDBCの接続プールまたはデータベースのチューニングも実施してください。
キャッシュは以下の2つが使用できます。
・ 永続性コンテキストキャッシュ
・ 永続性ユニットの共有キャッシュ
以下に各キャッシュについて説明します。
5.8.1 永続性コンテキストキャッシュ
エンティティマネージャを使用してEntityをデータベースから取得する場合、または作成したEntityを永続性コンテキストにマージする
場合、Entityインスタンスが永続性コンテキストキャッシュに格納されます。このキャッシュのライフサイクルは永続性コンテキストと同じ
です。
- 127 -
以下に永続性コンテキストキャッシュの特徴を説明します。
findメソッド
エンティティマネージャのfindメソッドでEntityを検索すると、まずは永続性コンテキストキャッシュから探します。
キャッシュにある場合は、データベースに問い合わせずにキャッシュされたインスタンスを返却します。キャッシュにない場合は、「5.8.2
永続性ユニットの共有キャッシュ」を探します。共有キャッシュにもない場合、SQL文を発行しデータベースに問い合わせします。検索
が成功した場合、Entityインスタンスを永続性コンテキストキャッシュに格納し、アプリケーションに返却します。
クエリメソッド
エンティティマネージャを使用してJPQLクエリメソッドを実行すると、SQL文を発行しデータベースから検索します。ただ、レコードを見
つけた場合、レコードと同じプライマリキーのEntityがすでに永続性コンテキストキャッシュに存在しているかどうか確認します。
存在している場合は、現在の永続性コンテキストで行った更新やEntity間のリレーション関係の整合性を保つため、キャッシュしたイン
スタンスを返却します。
存在していない場合は、永続性ユニットの共有キャッシュを探します。共有キャッシュにもない場合、SQL文を発行しデータベースに問
い合わせします。検索が成功した場合、Entityインスタンスを永続性コンテキストキャッシュに格納し、アプリケーションに返却します。
Entityインスタンスの更新、マージ、削除
管理されているEntityインスタンスの更新、削除、または非管理状態のEntityインスタンスの永続性コンテキストへのマージは永続性コ
ンテキストキャッシュに反映されます。
データベースのレコードとの不整合について
エンティティマネージャを使用し各操作を実行する際、同一トランザクションや別トランザクションにおいて、そのエンティティマネージャ
以外のアクセス方法でデータベースの同一レコードを更新すると、永続性コンテキスト内で管理されたEntityインスタンスとデータベー
スのレコード間で不整合が発生する可能性があります。
これを回避するためには、エンティティマネージャの各操作に対するフラッシュやEntityデータの最新化を必要に応じて明示的に実行
してください。
エンティティマネージャの各操作をフラッシュする方法は、JPA規約を参照してください。また、Entityデータを最新化する方法につい
ては以下に説明します。
Entityデータの最新化
Entityインスタンスの永続化フィールドの最新データをデータベースから取得するため、以下の方法があります。
エンティティマネージャのrefreshメソッドを実行
Entityインスタンスをエンティティマネージャのrefreshメソッドに指定し本メソッドを実行すると、SQL文が発行され、レコードの最新
データが取得されます。最新データがEntityインスタンスに反映され永続性コンテキストキャッシュも更新されます。
JPQLクエリメソッドにInterstage永続性プロバイダのクエリヒントを使用
JPQLクエリーにリフレッシュのヒントを指定しクエリメソッドを実行すると、永続性コンテキストキャッシュと共有キャッシュを検索せず
にデータベースに問い合わせます。成功した場合、レコードを取得してEntityインスタンスのコピーを作成して、コピーを共有キャッ
シュに格納し、もとのEntityインスタンスをアプリケーションに返却します。永続性コンテキストキャッシュにそのEntityがすでに存在
した場合、既存のオブジェクトが非管理状態になり、まだフラッシュしなかった修正がデータベースに更新されません。共有キャッ
シュにEntityがすでに存在した場合、既存のオブジェクトを新しいオブジェクトに上書きします。
注意
データの最新化の各機能における注意事項を以下に説明します。
・ エンティティマネージャのrefreshメソッドを実行する場合
－ コンテナ管理のエンティティマネージャを使用した場合、このメソッドをトランザクション中しか実行できないため、データ更新の
ない操作でもトランザクションを開始する必要があります。
－ refreshメソッドに指定するEntityインスタンスを取得した時にもSQL文を発行するので、データベースへ2回アクセスします。
- 128 -
・ Interstage永続性プロバイダのクエリヒントを使用する場合
－ 永続性コンテキストですでに行った更新やEntity間のリレーション関係の整合性を保てません。
－ Interstage永続性プロバイダの独自機能であるため、その他の永続性プロバイダで該当するヒントがない可能性があり、移植性
に影響があります。
リフレッシュ機能は以下のクエリヒントで指定します。
クエリヒント名
toplink.refresh
toplink.refresh.casca
de
値 (太字:省略値)
説明
true
キャッシュに問い合わせせずにデータベースを検索します。検
索したEntityのコピーを作成しコピーを共有キャッシュに格納し
ます。もとのEntityインスタンスをアプリケーションに返却しま
す。
false
データベースからの検索結果をキャッシュ内のEntityと比較し、
すでに存在した場合、キャッシュされたEntityインスタンスをア
プリケーションに返却します。
CascadeAllParts
検索したEntityをリフレッシュします。このEntityとリレーションが
持つEntityが検索結果に含まれている場合、そのEntityもリフ
レッシュします。
CascadeByMappin
g
検索した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.8.2 永続性ユニットの共有キャッシュ
永続性ユニットはEntityクラスごとに共有キャッシュを管理しています。このキャッシュはすべての永続性コンテキストから参照できます。
このキャッシュのライフサイクルは永続性ユニットと同じなので、エンティティマネージャファクトリの作成からクローズまで使用されます。
以下に永続性ユニットの共有キャッシュの特徴を説明します。
- 129 -
共有キャッシュの参照タイミング
共有キャッシュの参照タイミングについては、「5.8.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>
toplink.cache.type.d
efault
値 (太字:省略値)
・ Full
説明
特定のEntityに対応する共有キャッシュのタイプ
・ Weak
・ HardWeak
その他のEntityの共有キャッシュのタイプ
・ SoftWeak
toplink.cache.size.<
ENTITY>
toplink.cache.size.de
fault
0～
MAX_INTEGER
省略値:1000
特定のEntityに対応する共有キャッシュタイプによるサイズ
その他のEntityの共有キャッシュタイプによるサイズ
- 130 -
プロパティ名
toplink.cache.share
d.<ENTITY>
値 (太字:省略値)
・ true
説明
特定のEntityに対応する共有キャッシュを有効・無効にする
・ false
その他のEntityの共有キャッシュを有効・無効にする
toplink.cache.share
d.default
値は大文字と小文字を区別します。
プロパティの<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の
使用を検討してください。
例
共有キャッシュタイプの定義例
<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"
- 131 -
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.9 Webサービスのチューニング
Webサービスでは、Webコンテナの同時処理数や接続数などのチューニングが有効です。これらの設定については、「5.6 Webコンテ
ナのチューニング」を参照してください。
また、エンドポイントがStateless Session Beanの場合、EJBコンテナのインスタンスプールのチューニングも有効です。インスタンスプー
ルのチューニングについては「5.7.3 Enterprise Beanインスタンスのプーリング」を参照してください。
5.10 データベース連携環境のチューニング
物理的なデータベース接続はプール管理されてアプリケーションで共有されます。アプリケーションから接続の要求があった場合、ア
プリケーションサーバは、接続プールから接続を取得して、アプリケーションに返却します。また、アプリケーションが接続を解放した場
合、アプリケーションサーバは、その接続をプールに返却します。このJDBC接続プールに対して以下のチューニングができます。
・ プール内の接続数
・ 接続検証
・ トランザクション管理
・ 詳細属性
各項目のチューニングは、Interstage Java EE管理コンソールの[JDBC] > [接続プール]、およびasadminコマンドで設定できます。詳細
は、以下のマニュアルを参照してください。また、詳細属性の定義項目は、JDBC接続プールの作成後に値を更新してください。
・ Interstage Java EE管理コンソールヘルプ
・ 「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」
・ 「リファレンスマニュアル(コマンド編)」－「create-jdbc-connection-poolサブコマンド」
・ 「リファレンスマニュアル(コマンド編)」－「resources.jdbc-connection-poolの定義項目」
5.10.1 プール内の接続数
JDBC接続プールの接続数をチューニングするため、以下を設定できます。
プールサイズのスケールアップは、アプリケーションから接続要求を受けたときに必要に応じて実行されます。また、プールサイズのス
ケールダウンは一定時間の間隔で定期的に実行されます。
プールされた接続は、IJServerクラスタまたはInterstage Java EE DASサービスの停止時に削除されます。
・ 初期および最小プールサイズ
・ 最大プールサイズ
・ プールサイズ変更量
・ アイドルタイムアウト
・ 最大待ち時間
これらの項目のチューニングは、Interstage Java EE管理コンソールまたはasadminコマンドで設定できます。
- 132 -
・ Interstage Java EE管理コンソールの場合
以下の画面で、設定できます。
－ 「リソース」>「JDBC」>「接続プール」>「一般」
詳細はInterstage Java EE管理コンソールヘルプを参照してください。
・ asadminコマンドの場合
JDBC接続プールを作成する時は、「リファレンスマニュアル(コマンド編)」－「create-jdbc-connection-poolサブコマンド」を参照して
ください。
JDBC接続プールの項目を更新する時は、「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」と「resources.jdbc-connectionpoolの定義項目」を参照してください。
以下に、プールサイズのスケールダウン、およびスケールアップの動作について説明します。
プールの定期監視(プールサイズのスケールダウン)
アプリケーションサーバでは、接続プールの状態を定期的に監視し、プールのリサイズを行います。以下の契機でプール監視用のリ
サイザがスケジューリングされ、アイドルタイムアウトの間隔でリサイズタスクを実行します。
・ プールの初期化時(注1)
・ 「すべての障害で」を有効に設定し、接続障害が検出された時(注2)
注1)プールの初期化は、IJServerクラスタまたはInterstage Java EE DASサービスがアプリケーションから最初の接続要求を受けたとき
に実行されます。
注2)接続障害と判断される条件は、「5.10.2 接続検証」を参照してください。
プールのリサイズタスクでは、アイドルタイムアウトまたは接続検証に失敗するような不正な接続をすべてプールから取り除き、プール
サイズ変更量を超えない範囲でサイズをスケールダウンさせようとします。不正な接続の数によっては、プールサイズ変更量を超える
だけ削除されることがあります。削除の結果プールサイズの最小値を下回ってしまった場合には、最小値に達するまで接続を補完します。
具体的には、以下の手順で処理を実行します。ただし、説明のため以下の定義を使用します。
[プール内の接続数] = [使用されていない接続数] + [使用中の接続数]
[削除予定数] = [プールサイズ変更量] - [1.～2.の処理で削除した数]
[削除許容数] = [プール内の接続数] - [初期および最小プールサイズ]
1. アイドルタイムアウトが発生した接続を削除
接続のタイムスタンプから、アイドルタイムアウトが発生した接続を検出しプールから削除します。
2. 接続検証に失敗した接続を削除
検証に失敗した接続をプールから削除します。接続検証の詳細は、「5.10.2 接続検証」を参照してください。
3. 最大でも削除予定数だけの接続を削除
以下の条件を満たす場合、使用されていない接続を検索し、[削除予定数]を最大としてプールから削除します。条件を満たさな
い場合は削除されません。
0 < [削除予定数] <= [削除許容数]
4. プールサイズの修正
1.～3.の処理の結果、以下を満たした場合は、[初期および最小プールサイズ]に達するまで接続を作成します。
[プール内の接続数] < [初期および最小プールサイズ]
接続要求に応じたプールサイズのスケールアップ
アプリケーションからの接続要求の処理時、プール内の使用されていない接続の中で以下の2つの条件を満たす接続が存在しない場
合、プールサイズ変更量を超えない範囲でサイズをスケールアップさせます。
・ 接続のマッチングに成功
- 133 -
・ 接続検証に成功
スケールアップ時のプール内の動作は、以下です。次の2つの定義を説明の中で使用します。
[プール内の接続数] = [使用されていない接続数] + [使用中の接続数]
[生成許容数] = [最大プールサイズ] - [プール内の接続数]
条件
プール内の動作
[初期および最小プールサイズ]未満 (注1)
[初期および最小プールサイズ]へ
達するまで接続を生成します。
[初期および最小プールサイズ]以
上、[最大プールサイズ]未満
[プールサイズ変更量]だけ生成可
能な場合
[プールサイズ変更量]だけ接続を
生成します。
[プールサイズ変更量]だけ生成す
ると、[最大プールサイズ]を超えて
しまう場合
[生成許容数]だけ接続を生成しま
す。
接続は生成されません。(注2)
[最大プールサイズ]と一致
注1) 接続検証の失敗により、プール内の使用されていない接続がすべて削除された場合などに該当します。
注2) ただし、接続のマッチングに失敗した未使用の接続が存在する場合、最大でプールサイズ変更量分だけ接続を再作成します。
接続のマッチング
接続のマッチングとは、プール内の接続の認証情報が接続要求時の認証情報と一致しているかを検証する機能です。接続要求時の
認証情報の指定方法は、「Java EE運用ガイド」－「リソースアクセス時の認証情報」を参照してください。
5.10.2 接続検証
プールされた接続をアプリケーションに返却する前に、アプリケーションサーバは接続が有効か検証できます。この検証によって、デー
タベースがネットワーク障害かデータベース・サーバ障害により利用不可となった場合、その接続をプールから破棄し、再度プールか
ら接続を獲得して有効な接続を返却します。プールに有効な接続が存在しなかった場合、データベースから新たな接続を獲得するた
め、データベース接続を再確立できます。
接続検証が有効の場合には、以下が設定できます。
・ 検証方法
・ テーブル名
・ すべての障害で
これらの項目のチューニングは、Interstage Java EE管理コンソールまたはasadminコマンドで設定できます。
・ Interstage Java EE管理コンソールの場合
以下の画面で、設定できます。
－ 「リソース」>「JDBC」>「接続プール」>「一般」
詳細はInterstage Java EE管理コンソールヘルプを参照してください。
・ asadminコマンドの場合
JDBC接続プールを作成する時は、「リファレンスマニュアル(コマンド編)」－「create-jdbc-connection-poolサブコマンド」を参照して
ください。
JDBC接続プールの項目を更新する時は、「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」と「resources.jdbc-connectionpoolの定義項目」を参照してください。
また、接続検証が有効の場合には、アプリケーションサーバは以下の契機で接続検証を実効します。
- 134 -
接続検証の実行契機
A)プールの定期監視時の接続検証
アイドルタイムアウトの間隔で定期的に接続検証を実行します。
B)アプリケーションからの接続要求時の接続検証
接続を生成してからプールへ格納する前(B1)とプールから取得後にアプリケーションへ返却する前(B2)の2種類の契機で接続検
証が実行されます。
B1)接続生成時の接続検証
アプリケーションサーバはDBとの接続確立の直後、プールへ格納する前に事前に接続検証を実行します。
接続検証に失敗した場合、接続生成に失敗と判断し、アプリケーションへ例外を返却します。
B2)プール内から取得した接続に対する接続検証
プール内から取得した接続をアプリケーションへ返却する前に、接続検証を実行します。
プールサイズのスケールアップにより新規作成された接続のうちアプリケーションへ返却する接続に対しては、検証不要のため
接続検証をスキップします。プール初期化時に生成される接続は、プール内から取得した接続と見なし接続検証を実行しま
す。
- 「すべての障害で」が有効の時:
「すべての障害で」の処理で一時的にプール内の接続が0になるのを補うために新たな接続を生成します。もしこの時点で
再確立の処理が完了し未使用な接続があれば、置き換えて(破棄して)要求元へ接続を返却します。
- 「すべての障害で」が無効の時:
検証失敗の接続を削除し、プールから次の接続を取り出して再度接続検証を実施します。プール内の使用されていない
接続がすべて接続検証に失敗した場合の動作は、「接続要求に応じたプールサイズのスケールアップ」を参照してくださ
い。
注意
Interstage側のプーリング機能が無効の場合、接続を生成してからプールへ格納する前(B1) のタイミングのみで接続検証が実行され
ます。
接続障害と判断される条件
「すべての障害で」が有効の場合に接続障害と判断される条件は、以下です。
・ 接続検証の実行時にJDBCドライバから例外が返却された場合
注意
・ データベース接続を再確立できなかった場合には、例外が返却されます。
・ 自動的に再接続を行うことでデータベースで異常が発生しても業務継続ができるため、接続検証を有効にすることがお勧めです
が、アプリケーションでgetConnectionメソッドを実行して接続プールから接続を獲得する時にも検証を行うため、性能オーバーヘッ
ドが発生します。接続検証が不要な場合で、処理性能を向上させたい場合には必要に応じて接続検証を無効にしてください。
・ 接続検証を無効に設定した場合、検証方法およびテーブル名の指定も無効となります。
・ 接続生成時に実行される接続検証は、モニタロギングの採取対象外です。このため、「検証に失敗した物理接続数」は更新されま
せん。
5.10.3 トランザクション管理
JDBC接続プールのトランザクション管理では、以下を設定できます。詳細は、「Java EE運用ガイド」－「データベース連携アプリケー
ションの作成方法」を参照してください。
・ 非トランザクション接続
・ トランザクション開始後の接続のみ参加
- 135 -
・ トランザクション遮断
・ 遮断レベル
これらの項目のチューニングは、Interstage Java EE管理コンソールまたはasadminコマンドで設定できます。
・ Interstage Java EE管理コンソールの場合
以下の画面で、設定できます。
－ 「リソース」>「JDBC」>「接続プール」>「一般」
詳細はInterstage Java EE管理コンソールヘルプを参照してください。
・ asadminコマンドの場合
JDBC接続プールを作成する時は、「リファレンスマニュアル(コマンド編)」－「create-jdbc-connection-poolサブコマンド」を参照して
ください。
JDBC接続プールの項目を更新する時は、「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」と「resources.jdbc-connectionpoolの定義項目」を参照してください。
5.10.4 詳細属性
定義済みのJDBC接続プールをチューニングするため、以下を設定できます。
・ 文のタイムアウト
・ プーリング
・ リークタイムアウト
・ リーク再要求
・ 作成再試行回数
・ 再試行間隔
・ 監査ログへのアクセス情報出力
これらの項目のチューニングは、Interstage Java EE管理コンソールまたはasadminコマンドで設定できます。
・ Interstage Java EE管理コンソールの場合
以下の画面で、設定できます。
－ 「リソース」>「JDBC」>「接続プール」>「詳細」
詳細はInterstage Java EE管理コンソールヘルプを参照してください。
・ asadminコマンドの場合
「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」と「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のマニュアルを参照してください。
リークタイムアウトとリーク再要求に関する注意事項
- 136 -
リーク再要求が有効と設定された場合、接続リークが検出されると、自動的にその物理接続を破棄します。接続時にデータベースにア
クセス中、または、トランザクション中の場合、ユーザアプリケーションの実行に失敗する可能性があります。このようなことを避けるため
に、アプリケーションが発行するSQL文の実行時間や環境に応じて見積もった値を、利用するJDBC接続プールの「文のタイムアウト」
に設定してください。
SQL文の実行時間を制限することにより、リーク再要求で自動的に物理接続を破棄するとき、その接続がデータベースにアクセスして
いる可能性を低下させます。
なお、「リークタイムアウト」に十分に長い時間を設定することにより、検出された接続に確実にリークが発生した(つまり、接続がデータ
ベースアクセスに使われない)ことを保証します。また、JDBC接続を利用するときに、同一の接続を長時間利用しないように、利用完了
後すぐにクローズしてください。
プーリングに関する注意事項
Interstage側のプーリング機能が無効の場合、以下のチューニングはできません。
・ 初期および最小プールのサイズ
・ 最大プールのサイズ
・ プールサイズの変更量
・ アイドルタイムアウト
・ 最大待ち時間
・ すべての障害で
5.11 コネクタのチューニング
物理的なEISとの接続はプール管理されてアプリケーションで共有されます。アプリケーションから接続の要求があった場合、アプリケー
ションサーバは、接続プールから接続を取得して、アプリケーションに返却します。また、アプリケーションが接続を解放した場合、アプ
リケーションサーバは、その接続をプールに返却します。このコネクタ接続プールに対して以下のチューニングができます。
・ プール内の接続数
・ 接続検証
・ トランザクション管理
・ シャットダウンタイムアウト
各項目のチューニングは、Interstage Java EE管理コンソールの[コネクタ] > [コネクタ接続プール]、およびasadminコマンドで設定でき
ます。詳細は、以下のマニュアルを参照してください。
・ Interstage Java EE管理コンソールヘルプ
・ 「リファレンスマニュアル(コマンド編)」－「定義項目参照/更新」
・ 「リファレンスマニュアル(コマンド編)」－「create-connector-connection-poolサブコマンド」
・ 「リファレンスマニュアル(コマンド編)」－「resources.connector-connection-poolの定義項目」
5.11.1 プール内の接続数
コネクタ接続プールの接続数をチューニングするため、以下を設定できます。
プールサイズのスケールアップは、アプリケーションから接続要求を受けたときに必要に応じて実行されます。また、プールサイズのス
ケールダウンは一定時間の間隔で定期的に実行されます。プールされた接続は、IJServerクラスタまたはInterstage Java EE DASサー
ビスの停止時に削除されます。
・ 初期および最小プールサイズ
・ 最大プールサイズ
・ プールサイズ変更量
・ アイドルタイムアウト
- 137 -
・ 最大待ち時間
以下に、プールサイズのスケールダウン、およびスケールアップの動作について説明します。
プールの定期監視(プールサイズのスケールダウン)
アプリケーションサーバでは、接続プールの状態を定期的に監視し、プールのリサイズを行います。以下の契機でプール監視用のリ
サイザがスケジューリングされ、アイドルタイムアウトの間隔でリサイズタスクを実行します。
・ プールの初期化時(注1)
・ 「すべての障害で」を有効に設定し、接続障害が検出された場合(注2)
注1)プールの初期化は、IJServerクラスタまたはInterstage Java EE DASサービスがアプリケーションから最初の接続要求を受けたとき
に実行されます。
注2)接続障害と判断される条件は、「5.10.2 接続検証」を参照してください。
プールのリサイズタスクでは、アイドルタイムアウトまたは接続検証に失敗するような不正な接続をすべてプールから取り除き、プール
サイズ変更量を超えない範囲でサイズをスケールダウンさせようとします。不正な接続の数によっては、プールサイズ変更量を超える
だけ削除されることがあります。削除の結果プールサイズの最小値を下回ってしまった場合には、最小値に達するまで接続を補完します。
具体的には、以下の手順で処理を実行します。ただし、説明のため以下の定義を使用します。
[プール内の接続数] = [使用されていない接続数] + [使用中の接続数]
[削除予定数] = [プールサイズ変更量] - [1.～2.の処理で削除した数]
[削除許容数] = [プール内の接続数] - [初期および最小プールサイズ]
1. アイドルタイムアウトが発生した接続を削除
接続のタイムスタンプから、アイドルタイムアウトが発生した接続を検出しプールから削除します。
2. 接続検証に失敗した接続を削除
検証に失敗した接続をプールから削除します。接続検証の詳細は、「5.10.2 接続検証」を参照してください。
3. 最大でも削除予定数だけの接続を削除
以下の条件を満たす場合、使用されていない接続を検索し、[削除予定数]を最大としてプールから削除します。条件を満たさな
い場合は削除されません。
0 < [削除予定数] <= [削除許容数]
4. プールサイズの修正
1.～3.の処理の結果、以下を満たした場合は、[初期および最小プールサイズ]に達するまで接続を作成します。
[プール内の接続数] < [初期および最小プールサイズ]
接続要求に応じたプールサイズのスケールアップ
アプリケーションからの接続要求の処理時、プール内の使用されていない接続の中で以下の2つの条件を満たす接続が存在しない場
合、プールサイズ変更量を超えない範囲でサイズをスケールアップさせます。
・ 接続のマッチングに成功
・ 接続検証に成功
スケールアップ時のプール内の動作は、以下です。次の2つの定義を説明の中で使用します。
[プール内の接続数] = [使用されていない接続数] + [使用中の接続数]
[生成許容数] = [最大プールサイズ] - [プール内の接続数]
条件
プール内の動作
[初期および最小プールサイズ]未満 (注1)
[初期および最小プールサイズ]へ
達するまで接続を生成します。
- 138 -
条件
[初期および最小プールサイズ]以
上、[最大プールサイズ]未満
プール内の動作
[プールサイズ変更量]だけ生成可
能な場合
[プールサイズ変更量]だけ接続を
生成します。
[プールサイズ変更量]だけ生成す
ると、[最大プールサイズ]を超えて
しまう場合
[生成許容数]だけ接続を生成しま
す。
接続は生成されません。(注2)
[最大プールサイズ]と一致
注1) 接続検証の失敗により、プール内の使用されていない接続がすべて削除された場合などに該当します。
注2) ただし、接続のマッチングに失敗した未使用の接続が存在する場合、最大でプールサイズ変更量分だけ接続を再作成します。
接続のマッチング
接続のマッチングとは、プール内の接続の認証情報が接続要求時の認証情報と一致しているかを検証する機能です。Java EE Connector
Architecture規約の「Connection Matching Contract」に該当します。接続のマッチングが成功、または失敗と判定される条件は以下で
す。また、接続要求時の認証情報の指定方法は、「Java EE運用ガイド」－「リソースアクセス時の認証情報」を参照してください。
・ マッチングに失敗：
javax.resource.spi.ManagedConnectionFactory イ ン タ フ ェ ー ス の matchManagedConnections() メ ソ ッ ド の 返 却 値 が null 、 ま た は
ResourceExceptionが返却される場合
・ マッチングに成功：
javax.resource.spi.ManagedConnectionFactoryインタフェースのmatchManagedConnections()メソッドの返却値がManagedConnection
オブジェクトの場合
5.11.2 接続検証
プールされた接続をアプリケーションに返却する前に、アプリケーションサーバは接続が有効か検証できます。この検証によって、EIS
がネットワーク障害かEIS自身の障害により利用不可となった場合、その接続をプールから破棄し、再度プールから接続を獲得して有
効な接続を返却します。プールに有効な接続が存在しなかった場合、EISから新たな接続を獲得するため、接続を再確立できます。
接続検証には、以下が設定できます。
・ 接続検証
・ すべての障害で
接続検証の成功/失敗について
接続検証が有効の場合、以下の処理により判定します。
・ 検証成功
－ javax.resource.spi.ValidatingManagedConnectionFactoryインタフェースを実装していない時
－ ValidatingManagedConnectionFactoryインタフェースのgetInvalidConnections()メソッドの返却値がnull、サイズ0のSetオブジェ
クト、またはjavax.resource.ResourceExceptionを返却する時
・ 検証失敗
－ ValidatingManagedConnectionFactoryインタフェースのgetInvalidConnections()メソッドの返却値が0より大きなサイズのSetオブ
ジェクトを返却する時
－ 接続検証の実行前に、すでに対象となる接続で障害が検出されているとき
接続検証の実行契機
A)プールの定期監視時の接続検証
アイドルタイムアウトの間隔で定期的に接続検証を実行します。接続検証に失敗した場合の動作は、「プールの定期監視(プール
サイズのスケールダウン)」を参照してください。
- 139 -
B)アプリケーションからの接続要求時の接続検証
プール内から取得した接続をアプリケーションへ返却する前に、接続検証を実行します。プールサイズのスケールアップにより新規
作成された接続のうちアプリケーションへ返却する接続に対しては、検証不要のため接続検証をスキップします。また、プール初期
化時に生成される接続は、プール内から取得した接続と見なし接続検証を実行します。接続検証に失敗した場合は、「すべての
障害で」が有効かどうかで動作が変わります。
－ 「すべての障害で」が有効の時:
「すべての障害で」の処理で一時的にプール内の接続が0になるのを補うために新たな接続を生成します。もしこの時点で再
確立の処理が完了し未使用な接続があれば、置き換えて(破棄して)要求元へ接続を返却します。
－ 「すべての障害で」が無効の時:
検証失敗の接続を削除し、プールから次の接続を取り出して再度接続検証を実施します。プール内の使用されていない接続
がすべて接続検証に失敗した場合の動作は、「接続要求に応じたプールサイズのスケールアップ」を参照してください。
接続障害と判断される条件
「すべての障害で」が有効の場合に接続障害と判断される条件は、以下です。
・ javax.resource.spi.ManagedConnectionインタフェースのcleanup()メソッドの実行時に例外が発生した場合
・ javax.resource.spi.ConnectionEventListenerインタフェースのconnectionErrorOccurred()メソッドをリソースアダプタから呼び出した場
合
javax.resource.spi.ConnectionEventListener の 実 装 は 、 ア プ リ ケ ー シ ョ ン サ ー バ か ら javax.resource.spi.ManagedConnection の
addConnectionEventListener()メソッドが呼び出されたときに渡されます。「すべての障害で」を有効にする場合、EISとの接続障害に対
する通知処理を実装してください。
注意
・ 接続を再確立できなかった場合には、例外が返却されます。
・ 接続の検証には若干の性能オーバーヘッドが発生します。
5.11.3 トランザクション管理
コネクタ接続プールのトランザクション管理では、以下を設定できます。詳細は、「Java EE運用ガイド」－「アウトバウンド・リソースアダプ
タのトランザクション制御」を参照してください。
・ トランザクションサポート
5.11.4 シャットダウンタイムアウト
コネクタサービスで以下を設定できます。
・ シャットダウンタイムアウト
リソースアダプタクラスを実装したアプリケーションを運用する場合、アプリケーションサーバーは、リソースアダプタの停止処理である
endpointDeactivation()メソッドおよびstop()メソッドの完了を指定した時間だけ待ち合わせます。
指定した時間内に停止処理が完了しない場合、アプリケーションサーバーはその後のアプリケーションの非活性化処理を継続します。
endpointDeactivation()メソッドやstop()メソッドからの復帰が遅延する可能性のあるアプリケーションの運用に有効です。
リソースアダプタの停止処理は、リソースアダプタ単位に生成される停止用スレッドにより並列に処理されます。シャットダウンタイムアウ
トは、Interstage Java EE DASサービスやIJServerクラスタの単位に設定でき、設定したターゲットに配備された全リソースアダプタに対
して適用されます。
以下の方法で設定してください。
1. ツリービューから「設定」を選択し、設定名をクリックします。
2. 「コネクタサービス」を選択します。
3. シャットダウンタイムアウト(秒)を入力し「保存」をクリックします。
4. IJServerクラスタ、またはInterstage Java EE DASサービスを再起動します。
- 140 -
同様の操作は、asadminコマンドのsetサブコマンドからも行うことができます。詳細は、「リファレンスマニュアル(コマンド編)」－「configs
の定義項目」を参照してください。
注意
リソースアダプタの停止処理はendpointDeactivation()メソッド、stop()メソッドの順番に実行されます。endpointDeactivation()メソッドから
の復帰がシャットダウンタイムアウトで指定した時間以内に完了せず、エンドポイントの回収処理がstop()メソッドの呼び出し直前に未完
了だった場合、再度endpointDeactivation()メソッドを呼び出してからstop()を呼び出します。
5.12 トランザクションサービスのチューニング
トランザクションサービスのチューニングについて、以下に説明します。
各定義項目の詳細は、「Java EE運用ガイド」－「トランザクションサービスの定義項目」を参照してください。
トランザクションサービスの時間監視機能の設定値について
トランザクションサービスの時間監視機能には以下の3種類の機能があります。
機能名
説明
トランザクションタイムアウト
トランザクションが完了するまでの時間を監視します。
再試行タイムアウト
グローバルトランザクション使用時に使用できます。
トランザクションが複数のサーバにわたっている場合、トラン
ザクション情報の問い合わせに失敗したサーバに対して再
接続を試みる時間を設定します。
XAResourceに設定するトランザクションタイムアウ
ト
グローバルトランザクション使用時に使用できます。
グローバルトランザクションで利用するXAResourceに対して
setTransactionTimeoutメソッドを使用してタイムアウト値を設
定します。
上記の監視機能を併用する場合、時間の設定は以下のように設定してください。
・ T(x)＞T(t)＞T(r)
T(x)：XAResourceに設定するトランザクションタイムアウト
T(t)：トランザクションタイムアウト
T(r)：再試行タイムアウト
キーポイント処理
キーポイント処理とは、トランザクションログファイルを圧縮する処理のことです。トランザクションサービスの定義でキーポイント処理を
実行するトランザクション数の間隔を指定できます。
キーポイント処理の実行頻度の大小は、トランザクションのログファイルサイズとパフォーマンスに対して以下のように影響します。設定
値のキーポイント処理への影響度合いは、トランザクションの処理内容に依存します。
・ 大きくした場合
－ ログファイルサイズ：大きくなる
－ パフォーマンス：向上する
・ 小さくした合
－ ログファイルサイズ：小さくなる
－ パフォーマンス：劣化する
ログファイルサイズは以下の式で見積もりできます。
・ キーポイント間隔の設定値 × 0.0005Mバイト ＋ 0.15Mバイト
- 141 -
5.13 ORBのチューニング
ORBのチューニングについて説明します。
5.13.1 ORB
Java EEは、異なるマシンに配置されているオブジェクトや別プロセスのオブジェクト間でリクエストを呼び出す場合、ORBを介してIIOP
通信できます。
ORBの設定について以下に説明します。
IJServerクラスタの場合、以下に示すORBの設定項目を変更できます。
ORB設定
デフォルト値
意味
効果
総接続数
1024
IIOP通信の最大同時接続数を指定しま
す。 (注1)(注2)
総接続数を超えて同時に通信することは
できません。 (注3)
最大同時接続数を指定することによっ
て、コネクション接続で使用するメモリや
リソースを制御します。
最大メッセージ分割
サイズ
（byte単位）
1024
IIOPメッセージの最大フラグメントサイズ
を設定します。 (注4)(注5) (注6)(注7)
IIOPメッセージのエンコード処理を最大
フラグメントサイズで行います。全データ
をまとめてエンコードするのに比べて使
用するJavaヒープ領域を圧縮できます。
アプリケーションクライアントコンテナまたはスタンドアロンクライアントの場合、以下に示すORBの設定項目を変更できます。
ORB設定
最大メッセージ分割
サイズ
（byte単位）
デフォルト値
4096
意味
効果
IIOPメッセージの最大フラグメントサイズ
を設定します。(注4)(注5)(注6)(注7)
IIOPメッセージのエンコード処理を最大
フラグメントサイズで行います。全データ
をまとめてエンコードするのに比べて使
用するJavaヒープ領域を圧縮できます。
注1) 100未満の値を設定しても、接続数が100以上にならないと接続の回収は行われません。
注2) 確立済みの接続が存在する場合、その接続を使用して通信します。例えばあるプロセスがマルチスレッドでリクエストを呼び出し
た場合、呼出し先が単一プロセスならば接続は1つだけ使用されます。
注3) 接続数がこの値を超えるとアイドル状態の接続の回収(コネクション切断)が行われます。使用中の接続数が総接続数まで到達し
ている状態で、新規接続を行おうとすると、新規接続のコネクション自身が回収されます。
注4) 最大メッセージ分割サイズはデータ送信時の設定であり、クライアントからのリクエスト送信時と、サーバーからのリプライ送信時に
有効な機能になります。
例えば、エンコードされた通信データが70000byteで、最大メッセージ分割サイズが30000byteの場合、図のように分割して、IIOP通信
が開始されます。
- 142 -
送信された通信データは、受信側の受信バッファに格納された後、先頭データから順に業務データにデコードされ、ユーザアプリケー
ションに渡されます。
注5) 1024byteより小さな値は設定しないでください。最大メッセージ分割サイズが1024byteより小さい場合、想定される最大クライアン
ト多重度の２倍のスレッドが必要になります。このため、サーバー側で必要なスレッド数が見積もり数を超過してしまう可能性があります。
なお、スレッド数の見積もりについては、「5.7.1 スレッドプーリング」を参照してください。
注6) 256000以上の値を設定する場合、接続先の最大受信バッファサイズを本設定値より大きい値とする必要があります。最大受信
バッファサイズについては、「5.13.2 通信データサイズに関する注意事項」を参照してください。
注7) 設定値は、Java VM上でのヒープ使用量に影響します。
最大メッセージ分割サイズにより、IIOP通信時に獲得するバッファ領域のサイズが変動しますので、最大メッセージ分割サイズを変更
する際は、実際に送受信される業務データとは別に、最大メッセージ分割サイズの設定によるヒープ使用量を考慮して、Java VMの
ヒープ領域サイズを見積もってください。
以下の計算式のうち、大きいほうの結果が必要なヒープ使用量になります。
・ IJServerクラスタ起動時に必要なヒープ使用量
IJServerクラスタを起動するためのIIOP通信では、以下のヒープ使用量が必要です。
IJServerクラスタ起動時のヒープ使用量＝最大メッセージ分割サイズ×3
・ アプリケーション実行時に必要なヒープ使用量
アプリケーションを実行するためのIIOP通信では、以下のヒープ使用量が必要です。
クライアント側で必要なヒープ使用量＝（最大メッセージ分割サイズ＋最大受信バッファサイズ）×最大同時リクエスト送信数
サーバー側で必要なヒープ使用量＝（最大メッセージ分割サイズ＋最大受信バッファサイズ）×想定される最大クライアント同時
接続数
最大同時リクエスト送信数：クライアントプロセスの同時実行スレッド数に相当します。
想定される最大クライアント同時接続数：デフォルトスレッドプールの最大プールサイズに相当します。
- 143 -
ORB設定は、以下の方法で設定します。
総接続数
Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更・参照できます。詳細については、以下のマニュアルを参照
してください。
・ Interstage Java EE管理コンソールヘルプ
・ リファレンスマニュアル（コマンド編）の「configs.config.iiop-serviceの定義項目」のorb.max-connections(総接続数)
設定変更時は、IJServerクラスタを再起動する必要があります。
最大メッセージ分割サイズ
・ IJServerクラスタの場合
Interstage Java EE管理コンソール、およびasadminコマンドを使用して変更・参照できます。詳細については、以下のマニュアルを
参照してください。
－ Interstage Java EE管理コンソールヘルプ
－ リファレンスマニュアル（コマンド編）「configs.config.iiop-serviceの定義項目」の orb.message-fragment-size(最大メッセージ分
割サイズ)
設定変更時は、IJServerクラスタを再起動する必要があります。
・ アプリケーションクライアントコンテナに設定する場合
環境変数VMARGSに以下の値を設定します。
-Dcom.sun.corba.ee.giop.ORBFragmentSize=設定値
詳細については、以下のマニュアルを参照してください。
－ 「Java EE運用ガイド」－「Java EEアプリケーションクライアントの環境設定」
・ スタンドアロンクライアントの場合
Java VMオプションに以下の値を設定します。
-Dcom.sun.corba.ee.giop.ORBFragmentSize=設定値
5.13.2 通信データサイズに関する注意事項
最大受信バッファサイズの拡張について
最大メッセージ分割サイズの拡張や、非フラグメントモード使用時、接続先の送信データサイズが256000byteを超える場合がないか確
認してください。
接続先の送信データサイズが256000byteを超える場合、最大受信バッファサイズを拡張する必要があります。
最大受信バッファサイズの設定は、Java VMオプションで指定します。
最大受信バッファサイズはデータ受信時の設定であり、クライアントからのリクエスト受信時と、サーバーからのリプライ受信時に有効な
機能になります。
プロパティ名
com.sun.corba.ee.transport.ORBMaximumReadByteBufferSize
設定値
byte
値の範囲
256000～2147483647
- 144 -
デフォルト値
256000
設定方法
－ スタンドアロンクライアントの場合
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=設定値
詳細については、以下のマニュアルを参照してください。
- Interstage Java EE管理コンソールヘルプ
- リファレンスマニュアル（コマンド編）の「configs.config.java-configの定義項目」のjava-config.jvm-options（JVMオプション）
設定変更時は、IJServerクラスタを再起動する必要があります。
接続先から受信したデータは、受信バッファに格納されます。受信バッファのサイズは、受信するデータサイズにより、初期値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.14 予兆監視機能から警告が通知された場合の対処
予兆監視機能が提供する警告メッセージ(ISJEE_OM3204)には、以下の2つの種類があります。事象の種類は、警告メッセージの可変
情報である詳細メッセージで通知します。
- 145 -
・ 予兆監視警告メッセージ(Javaヒープ)
Java VMのメモリ割当てプール(注)およびPermanent世代領域を監視して、Javaヒープ不足の危険性を警告メッセージで通知しま
す。
・ 予兆監視警告メッセージ(ガーベジコレクション)
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.14.1 予兆監視警告メッセージ(Javaヒープ)
Java VMのメモリ割当てプールおよびPermanent世代領域を監視して、Javaヒープ不足の危険性を警告メッセージ(ISJEE_OM3204)で
通知します。
JavaヒープおよびPermanent世代領域の問題を通知する警告メッセージには、3種類の詳細メッセージがあります。この他の詳細メッ
セージは、「5.14.2 予兆監視警告メッセージ(ガーベジコレクション)」を参照してください。
詳細メッセージは、以下の発生条件で出力されます。
なお、詳細メッセージに含まれる時刻情報のフォーマットは「年/月/日 時:分:秒.ミリ秒」となります。
詳細メッセージ
警告の意味
発生条件
There are possibilities of
OutOfMemoryError because of the
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 of
OutOfMemoryError because of the
lack of the Perm region: TIME={0}
SIZE={1}
TIME: 発生時刻
SIZE: Permanent世代領域への追
加量の目安(バイト単位)(注)
Permanent世代領域不足のため、
OutOfMemoryErrorが発生する危
険性があります。
Permanent世代領域の使用量が
90%より大きい場合。
- 146 -
詳細メッセージ
警告の意味
発生条件
OutOfMemoryError warning is
occurred because the Perm region 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.14.2 予兆監視警告メッセージ(ガーベジコレクション)
Java VMのガーベジコレクション処理の影響で業務レスポンス低下が発生する可能性を検出し、警告メッセージ(ISJEE_OM3204)で通
知します。
Java VMのガーベジコレクションの影響を通知する警告メッセージには、5種類の詳細メッセージがあります。この他の詳細メッセージ
は、「5.14.1 予兆監視警告メッセージ(Javaヒープ)」を参照してください。
・ ガーベジコレクション処理時間に関する警告メッセージ(1種類)
・ ガーベジコレクション間隔に関する警告メッセージ(4種類)
警告メッセージは、ガーベジコレクション処理による業務レスポンス低下の危険性を通知するもので、Java VMの動作異常を示すもの
ではありません。また、警告が出力された状態で業務を継続したときに、Javaアプリケーションの実行に支障が発生すると一概に言え
ませんが、警告メッセージが出力されない状態にすることにより、安定稼動するシステムを構築できます。
- 147 -
ガーベジコレクション処理時間に関する警告メッセージ
詳細メッセージは、以下の発生条件で出力されます。
なお、詳細メッセージに含まれる時刻情報のフォーマットは「年/月/日 時:分:秒.ミリ秒」となります。
詳細メッセージ
警告の意味
発生条件
It takes long time to do the garbage
collections many times: TIME={0}
AVERAGE={1}
TIME: 発生時刻
AVERAGE: 過去3回のFull GCの
平均時間(ミリ秒単位)
Full GCに長い時間かかる状態が
続いています。
過去3回のFull GC時間の平均値
が5秒より長い場合。
ガーベジコレクション処理中は、メッセージに記載されたFull GCの平均時間の間、アプリケーションが停止する場合があります。メッ
セージが出力された場合、レスポンス低下などの問題が発生する可能性があります。
予兆監視警告メッセージ(ガーベジコレクション処理時間)の原因と対処
ガーベジコレクション処理時間に関する警告メッセージが出力される原因は、以下が考えられます。
・ 物理メモリの枯渇など、システムのリソースが不足している。
・ CPU負荷の高い別のアプリケーションが同時に動作しているなど、メッセージの対象となったJavaプロセスの実行が阻害されてい
る。
・ Javaヒープのサイズ指定が大きすぎて、ガーベジコレクション処理に時間を要している。
アプリケーションのレスポンスに問題がある場合は、これらの要因を確認してください。
Javaヒープサイズの指定を小さくするチューニングは、十分な検証が必要です。JavaアプリケーションがJavaヒープを多く消費するプロ
グラムの場合、Javaヒープサイズの指定を小さくするとOufOfMemoryErrorが発生することも考えられます。
ガーベジコレクション間隔に関する警告メッセージ
詳細メッセージは、以下の発生条件で出力されます。いずれも、ガーベジコレクションが短い間隔で連続して発生した場合に発生しま
す。頻繁なガーベジコレクション処理の実行は、アプリケーションのレスポンス低下などの問題が発生する可能性があります。
なお、詳細メッセージに含まれる時刻情報のフォーマットは「年/月/日 時:分:秒.ミリ秒」となります。
詳細メッセージ
警告の意味
発生条件 (注)
Inefficient garbage collections are
run with the short intervals:
TIME={0} WEIGHT={1}
TIME: 発生時刻
WEIGHT: Full GC直前の旧世代
の使用率(%単位)
非効率なFull GCが短い間隔で発
生しています。
過去3回のFull GC間隔時間が20
秒より短い場合、かつ、Full GC直
前のOld世代領域の使用率が65%
よりも小さい場合。
The garbage collections are run
with the short intervals because of
the lack of the memory: TIME={0}
SIZE={1}
TIME: 発生時刻
SIZE: Javaヒープ領域への追加量
の目安(バイト単位)(注2)
Javaヒープ不足のため、Full GCが
短い間隔で発生しています。
過去3回のFull GC間隔時間が20
秒より短い場合、かつ、Full GC直
後のJavaヒープ使用率が65%より
大きい場合。
System.gc() are run with the short
intervals: TIME={0}
INTERVAL={1}
TIME: 発生時刻
INTERVAL:
java.lang.System.gc()メソッドや
java.lang.Runtime.gc()メソッドのイ
ンターバル時間(ミリ秒単位)
java.lang.System.gc()メソッドや
java.lang.Runtime.gc()メソッドが短
い間隔で発生しています。
過去3回のFull GC間隔時間が20
秒より短い場合、かつ、
java.lang.System.gc()メソッドや
java.lang.Runtime.gc()メソッドに
よって発生したFull GCの頻度が高
い場合。
- 148 -
詳細メッセージ
警告の意味
発生条件 (注)
The garbage collections are run
with the short intervals: TIME={0}
INTERVAL={1}
TIME: 発生時刻
INTERVAL: Full GCのインターバ
ル時間(ミリ秒単位)
Full GCが短い間隔で発生してい
ます。
過去3回の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()メソッドの実行箇所を特定することができます。詳細は、以下のマニュアルを参照してください。
「 Interstage Application Server/Interstage Web Server チ ュ ー ニ ン グ ガ イ ド 」 > 「 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」のメッセージが出力されます。
5.15 Interstage Java EE DASサービスのヒープ領域サイズとアドレス空
間
ヒープ領域サイズ
作成したIJServerクラスタ、サーバーインスタンスの数が多い場合や、配備済みアプリケーションの数が多い場合、メモリ不足により
Interstage Java EE DASサービスの起動失敗やプロセスダウンが発生することがあります。
- 149 -
メモリ不足が発生している場合は、Interstage Java EE DASサービスのヒープ領域サイズをデフォルトの512MBから増やしてください。-targetオプションには server を指定します。
設定例
asadmin delete-jvm-options --target server \-Xmx512m
asadmin create-jvm-options --target server \-Xmx1024m
asadmin delete-jvm-options --target server \\-Xmx512m
asadmin 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バイト)
Interstage Java EE DASサービスが起動しない場合の対処方法
IJServerクラスタの数が多く、Interstage Java EE DASサービスが起動しない場合は、下記手順に従いdomain.xmlを編集してください。
domain.xmlの格納先
[Java EE共通ディレクトリ]\domains\interstage\config\domain.xml
- 150 -
[Java EE共通ディレクトリ]/domains/interstage/config/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の格納先
[Java EE共通ディレクトリ]\domains\interstage\config\domain.xml
[Java EE共通ディレクトリ]/domains/interstage/config/domain.xml
workers2.propertiesの格納先
C:\Interstage\F3FMjs5\conf\jk2\[Webサーバ名]\workers2.properties
/opt/FJSVjs5/conf/jk2/[Webサーバ名]/workers2.properties
IJServerクラスタの削除手順
1. Interstage Java EE Node Agentサービスを停止してください。通常停止を実施できない場合には、プロセスを強制停止してくださ
い。
2. Interstage Java EE DASサービスを停止してください。通常停止を実施できない場合には、プロセスを強制停止してください。
3. Webサーバを停止してください。 (注1)
4. Interstage管理コンソールを停止してください。 (注2)
- 151 -
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セクションを削除します。
[lb: ${IJServerクラスタ名}]
～
worker=http:${IJServerクラスタのIPアドレス}_${サーバーインスタンスのポート番号}
～
createdby=javaee
－ uriセクションの削除
groupプロパティに削除対象のIJServerクラスタ名が設定されているuriセクションをすべて削除します。
- 152 -
[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.16 時間監視機能の相関関係
アプリケーションからの要求でネットワーク通信が発生する以下の機能について応答時間に影響する時間監視機能と、その各時間監
視機能の相関関係を説明します。
応答時間に影響する時間監視機能以外の、不当に残存したオブジェクトを解放する無通信時間を監視する機能（コネクションプーリ
ング機能など）については、各機能説明を参照してください。
・ HTTP通信
・ IIOP通信
・ トランザクションとデータベースアクセス
時間監視機能により異常を検出するまでの時間をタイムアウト時間と呼び、タイムアウト時間を超過したことにより異常を検知することを
タイムアウトと呼びます。
タイムアウトによる異常を検出して呼び出し元で処理を中断するか再実行するかなどの判断を行うため、タイムアウト時間は呼び出し元
に近いほど大きな値に設定するのが一般的です。
相関関係の図において実線は処理の流れを表します、点線は時間監視機能の監視間隔を表します。
緑色の部分がアプリケーションの処理部分です。
- 153 -
HTTP通信
相関関係
※1 HTTPリスナー/Webコンテナに接続されてからリクエストの処理が開始するまでの待機時間です。詳細は以下を参照してください。
・ 「5.6 Webコンテナのチューニング」
・ 「5.18.3 性能情報の分析」
時間監視項目
監視対
象となる
時間
(a)
時間監視機能
説明
Webサーバコネクタの送受信タイムアウト
WebサーバコネクタがHTTPリスナー/Webコンテ
ナとの間でデータパケットを送受信するときの待
機時間を監視します。
<設定方法>
以下の項目でタイムアウト時間を設定します。
「5.6 Webコンテナのチューニング」
・ Webサーバコネクタの送受信タイムアウト
その際、以下の関係を満たすように設定してください。
(a) ＞ (b) ＋ (c) ＋ 図中※1
(b)
HTTPリスナーのタイムアウト
注)
本項目はWebサーバ(Webサーバコネクタ)を使
用する運用の場合のみWebサーバコネクタによ
り監視されます。
その際、Webサーバコネクタは相関関係図の「ク
ライアント」に相当します。
HTTPリスナー/Webコンテナがクライアントから
のデータパケットを受信するときの待機時間を
監視します。
<設定方法>
以下の項目でタイムアウト時間を設定します。
・ 「Java EE運用ガイド」－「HTTPサービスの定義項目」
－ 項目名：タイムアウト時間
－ プロパティ名： connectionUploadTimeout
- 154 -
監視対
象となる
時間
(c)
時間監視機能
説明
アプリケーション最大処理時間
ユーザアプリケーションの呼び出しからレスポン
ス送信までの処理時間を監視します。
監視対象の時間にはリクエストのメッセージボ
ディの読み込み時間も含まれます。
<設定方法>
以下の項目でタイムアウト時間を設定します。
・ 「Java EE運用ガイド」－「プロセス制御の定義項目」
－ 項目名：アプリケーション最大処理時間
ポイント
以下の現象が頻繁に発生する場合、対処方法を行うことで回避できる可能性があります。
回避できない場合は、サーバの処理能力を超えている可能性があります。
サーバの増設または、より性能の良いサーバへのリプレースを検討してください。
－ 現象：WebサーバコネクタのログにIJServer12035、IJServer12044が出力される
対処方法：(a)の設定値を大きくする
－ 現象：イベントログ/システムログにISJEE_OM1005、またはISJEE_OM1020が出力される
対処方法：(c)の設定値を大きくする
注意
以下の条件に該当する場合、プロセスが強制停止します。
－ (b) ＞ (c) に設定した、かつ
－ プロセス制御の定義項目 [アプリケーション最大処理時間超過時の制御]を"true"に設定した、かつ
－ 相関関係図における“リクエストのメッセージボディの送信”が(ｃ)の設定値を超えても完了しなかった場合
- 155 -
IIOP通信
相関関係
時間監視項目
時間監視間隔
時間監視機能
(a)
IIOP接続の待機時間監視機能
(b)
IIOP通信ソケットの送受信待機時間監視機能
(c)
IIOP通信時のサーバメソッド復帰時間監視機能
(d)
アプリケーションの最大処理時間監視機能
(e)
IIOP通信クライアントの無通信監視機能
- 156 -
トランザクションとデータベースアクセス
相関関係
時間監視項目
時間監視間隔
時間監視機能
(a)
EJBコンテナのトランザクション完了時間監視機能
(b)
トランザクションサービスのトランザクションタイムアウト
(c)
JDBC接続プールの最大待ち時間
(d)
JDBC接続プールの文のタイムアウト
5.17 モニタリング情報の監視
Interstage Java EE管理コンソールにて、運用中のサーバーインスタンスの稼動情報を参照できます。これにより、ボトルネックを検出し
たり、性能チューニングの効果を確認することができます。
稼働情報には、以下の情報が出力されます。各項目の意味については、項目と合わせて表示される説明を参照してください。
- 157 -
表示項目
説明
ランタイム
Java VMの情報などプロセスの情報が表示されます。
アプリケーション
サーバーインスタンスに配備された各アプリケーションの情
報が表示されます。
リソース
サーバーインスタンスに有効になっている各リソースの情報
が表示されます。
トランザクション
サーバーインスタンスで動作している各トランザクションの情
報が表示されます。
監視を有効にするには、監視サービスの設定で各項目に対して「LOW」もしくは「HIGH」を設定します。
Java VMの情報として表示されるUpTime（開始時間）とHeapSize（ヒープサイズ）の情報はデフォルトで表示されます。
「LOW」より「HIGH」を指定することで多くの情報を表示することができますが、表示項目が多いと若干の性能影響があります。このた
め、必要な監視情報のみ有効にしてください。
モニタロギング機能を使用することで、表示される情報をログに出力することもできます。モニタロギング機能については、「5.18 モニタ
ロギング」を参照してください。
5.17.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.18 モニタロギング
IJServerクラスタの性能情報をロギングする機能が提供されています。この機能を利用することで、JavaVMやJDBCデータソースなどの
性能情報を定期的に採取し、結果をログファイルへ出力することができます。ログファイルはCSV形式のファイルに出力されるため、容
易にExcelなどで読み込んで性能情報を分析することができ、統計情報の蓄積にも役立ちます。
IJServerクラスタのモニタロギングは以下の図に示すようにasadminコマンドを使用します。
asadminコマンドのsetサブコマンド、またはInterstage Java EE管理コンソールによりIJServerクラスタのモニタロギングを有効に設定する
と、Interstage Java EE DASサービスを経由してIJServerクラスタの各サーバーインスタンスへ定義変更イベントが通知されます。
サーバーインスタンスのプロセスでは、指定された時間間隔で性能情報をCSV形式のファイルに出力します。
なお、モニタロギングが無効に設定された場合、以降の性能情報の出力は行われません。
- 158 -
設計方法
IJServerクラスタ運用中に継続してモニタロギング機能を使用してログを採取することにより、業務運用中の性能情報の記録が残るた
め、問題発生時の原因究明が確実かつ簡単になります。
しかし、ログ採取タイミングではログ情報をファイルに出力するためにJava VMのヒープメモリ使用量やCPU使用率が若干増加します。
このため、大量の情報を頻繁にログファイルに出力すると性能に影響が発生する可能性があります。テスト運用中にモニタロギング機
能を評価し、運用に影響がないログ採取間隔で採取してください。
5.18.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
- 159 -
ポイント
・ モニタロギングによる性能情報の出力は、対象の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クラスタを起動します。
3. 性能情報の分析
出力された情報をMicrosoft(R) Excelなどで分析します。
4. IJServerクラスタの停止
Interstage Java EE管理コンソール、またはasadminコマンドのstop-clusterサブコマンドでIJServerクラスタを停止します。
5. 2.～4.を繰り返します。
- 160 -
注意
Interstage Java EE DASサービスのメモリについて
モニタロギングを利用するために、IJServerクラスタやInterstage Java EE DASサービスの監視サービスの定義を有効にすると、サーバー
インスタンス数、配備済みのアプリケーション数に応じてInterstage Java EE DASサービスのメモリが使用されます。
監視サービスを有効に設定した場合は、Interstage Java EE DASサービスでメモリ不足が発生していないことを確認してください。メモ
リ不足が発生した場合は、「5.15 Interstage Java EE DASサービスのヒープ領域サイズとアドレス空間」を参照して対処を行ってくださ
い。
5.18.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
トランザクション情報ログファイル
monitor-transaction.log
JMS/コネクタ接続プール情報ログファイル
monitor-connectorpool.log
- 161 -
ローテーション後のファイル名
出力されたログファイルは一定間隔でローテーションされます。ローテーション後のログファイルは、以下のようにローテーションした日
時情報を付加してバックアップされます。ログファイル名の末尾に、日時を示す文字列が追加されます。また、ログファイル名と日時文
字列の間はハイフン（「_」）で区切られます。
ファイル名：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. バックアップされているファイルのファイル数がログファイルの世代数以上となっている場合、ファイルの更新日時が古いファイル
を削除します。バックアップされたファイルのファイル数が世代数となるまで削除します。
ファイルのアクセス権
出力されるファイルの所有者はIJServerクラスタの起動ユーザとなり、ファイルの権限は「644」となります。
出力ディレクトリ
モニタロギングのログファイルは、IJServerクラスタのログ出力ディレクトリに出力されます。
IJServerクラスタのログ出力ディレクトリについては、「Java EE運用ガイド」－「IJServerクラスタのファイル構成」を参照してください。
- 162 -
5.18.3 性能情報の分析
ログファイルに採取した性能情報の分析方法について説明します。
出力情報
モニタ情報ログファイルは、以下のようにCSV形式(カンマ区切りで並べた形式)で出力されます。
D1,D2,D3,D4,D5,・・・
性能情報の項目内容
IJServer(J2EE)におけるモニタロギング機能では、データ採取区間内での集計データ(データ採取時間帯での最大値など)を採取して
いました。
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)で表示します。
mm
分を2桁の数字(00～59)で表示します。
ss
秒を2桁の数字(00～59)で表示します。
SSS
ミリ秒を3桁の数字(000～999)で表示します。
例
24/06/2006 01:00:00.200
性能情報中の「ミリ秒」単位は、以下の値が「h:mm:ss.SSS」のフォーマットで出力されます。
h
時を可変桁の数字(0～)で表示します。値が0の場合は「0」と表示します。
mm
分を2桁の数字(00～59)で表示します。
ss
秒を2桁の数字(00～59)で表示します。
SSS
ミリ秒を3桁の数字(000～999)で表示します。
例
0:00:00.200
性能情報として出力される項目について説明します。各表の項番に書かれているD1、D2、・・・は、CSV形式で出力されるD1、D2、・・・
に対応しています。
なお、先頭の出力項目は、必ず当該レコードの性能情報を採取した日時となります。
性能情報を出力するには、asadminコマンドのsetサブコマンドでconfigs.config.monitoring-serviceの定義項目に、出力する情報の監視
レベルを指定する必要があります。各表の監視レベルは、指定した監視レベルによって出力される情報です。監視レベルがHIGHの
項目(薄い緑色の行)は、指定された監視レベルがHIGHの場合だけ出力される項目です。それ以外は指定された監視レベルにかか
わらず出力される項目です。
性能情報一覧
1) Java VM情報
2) HTTP接続キュー情報
- 163 -
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ヒープサイズの上限値(単位:バイト) (注1)
D7
Java VMヒープサイズの最小値(単位:バイト)
D8
Java VMヒープサイズの最大値(単位:バイト) (注1)
D9
Java VMヒープサイズの現在値(単位:バイト)
D10
Perm領域の上限値(単位:バイト)
D11
Perm領域の最小使用量(単位:バイト)
D12
Perm領域の最大使用量(単位:バイト)
D13
Perm領域の現在使用量(単位:バイト)
D14
ガーベジコレクション発生回数 (注2)
D15
ガーベジコレクション処理トータル時間(単位: ミリ秒) (注
2)
注1)：Java VMヒープサイズの上限値は動的に増減するため、Java VMヒープサイズの上限値をJava VMヒープサイズの最大値が上回
る場合があります。
注2)：ガーベジコレクション情報に対して以下の制限事項があります。
JDK/JRE 5.0において、ガーベジコレクション制御としてCMS付きパラレルGC、FJGCまたはシリアルGCを使用する場合、ガーベジコレ
クション発生回数およびガーベジコレクション処理トータル時間は正しくありません。
2) HTTP接続キュー情報
HTTPの接続キューの性能情報です。
- 164 -
項番
項目の内容
採取条件
D1
当該レコードの性能情報を採取した日時
D2
インスタンス名
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リスナーの性能情報です。
項番
項目の内容
採取条件
D1
当該レコードの性能情報を採取した日時
D2
インスタンス名
D3
プロセスID
D4
各要求プロセッサが受信したバイトの累計値(単位:バイ
ト)
D5
各要求プロセッサが送信したバイトの累計値(単位:バイ
ト)
D6
使用しません
D7
使用しません
D8
使用しません
D9
使用しません
D10
使用しません
D11
使用しません
D12
使用しません
D13
使用しません
D14
使用しません
D15
使用しません
- 165 -
項番
項目の内容
採取条件
D16
使用しません
D17
使用しません
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への接続の性能情報です。
項番
項目の内容
採取条件
D1
当該レコードの性能情報を採取した日時
D2
インスタンス名
D3
プロセスID
D4
ORBへの接続のうち、アイドル状態の接続の合計数
D5
ORBへの接続のうち、使用中の接続の合計数
D6
ORBへの接続の下限数
D7
ORBへの接続の上限数
D8
ORBへの接続の最小数
D9
ORBへの接続の最大数
D10
ORBへの接続の合計数
5) スレッドプール情報
EJBコンテナのスレッドプール(※)に対する性能情報です。スレッドプールごとに情報を出力します。
スレッドプール追加時、モニタ情報を有効にするにはIJServerクラスタの再起動が必要です。
- 166 -
※：主にEJBコンテナがスレッド制御を行うアクセスパターンで呼出しが行われた場合に使用されます。
EJBコンテナのスレッドプールについての詳細については「5.7.1 スレッドプーリング」を参照してください。
項番
項目の内容
採取条件
D1
当該レコードの性能情報を採取した日時
D2
インスタンス名
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ごとに情報を出力します。
・ 指定したIJServerクラスタにユーザがStateless Session Beanを配備していない場合でも、システムが利用するアプリケーションであ
る「MEjbApp」の情報が出力されます。
・ HotDeployしたアプリケーションの情報は、次回の採取タイミングから反映されます。
・ 初期化に失敗したアプリケーションの情報は出力されません。
項番
項目の内容
D1
当該レコードの性能情報を採取した日時
D2
インスタンス名
D3
プロセスID
採取条件
- 167 -
項番
項目の内容
D4
Application名
D5
EJBモジュール名
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がひとつも配備されていない場合は情報が出力されません。
・ HotDeployしたアプリケーションの情報は、次回の採取タイミングから反映されます。
・ 初期化に失敗したアプリケーションの情報は出力されません。
項番
項目の内容
採取条件
D1
当該レコードの性能情報を採取した日時
D2
インスタンス名
D3
プロセスID
D4
Application名
D5
EJBモジュール名
D6
Stateful Session Bean名
D7
Passivateされたインスタンス数の最小値
D8
Passivateされたインスタンス数の最大値
D9
Passivateされたインスタンス数
D10
キャッシュ内のアイドル状態となっているBeanインスタ
ンスの最小数
D11
キャッシュ内のアイドル状態となっているBeanインスタ
ンスの最大数
D12
キャッシュ内のアイドル状態となっているBeanインスタ
ンスの現在数
D13
EJBのcreateメソッドが呼び出された回数
D14
EJBのremoveメソッドが呼び出された回数
8) Message-driven Bean情報
Message-driven Beanの性能情報です。Beanごとに情報を出力します。
・ 指定したIJServerクラスタにMessage-driven Beanがひとつも配備されていない場合は情報が出力されません。
・ HotDeployしたアプリケーションの情報は、次回の採取タイミングから反映されます。
・ 初期化に失敗したアプリケーションの情報は出力されません。
項番
D1
項目の内容
採取条件
当該レコードの性能情報を採取した日時
- 168 -
項番
項目の内容
採取条件
D2
インスタンス名
D3
プロセスID
D4
Application名
D5
EJBモジュール名
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がひとつも配備されていない場合は情報が出力されません。
・ HotDeployしたアプリケーションの情報は、次回の採取タイミングから反映されます。
・ 初期化に失敗したアプリケーションの情報は出力されません。
項番
項目の内容
採取条件
D1
当該レコードの性能情報を採取した日時
D2
インスタンス名
D3
プロセスID
D4
Application名
D5
EJBモジュール名
D6
Entity Bean名
D7
プール内のインスタンスの最小数
D8
プール内のインスタンスの最大数
D9
プール内のインスタンスの現在数
D10
キャッシュ内のアイドル状態となっているBeanインスタ
ンスの最小数
D11
キャッシュ内のアイドル状態となっているBeanインスタ
ンスの最大数
D12
キャッシュ内のアイドル状態となっているBeanインスタ
ンスの現在数
注) 以下のシステムが利用するアプリケーションの性能情報が出力されます。
__ejb_container_timer_app
10) JDBC接続プール情報
JDBC接続プールの性能情報です。接続プールごとに情報を出力します。
指定したIJServerクラスタに関連付けられたJDBCリソースがひとつもない場合は情報が出力されません。なお、関連付けを行った後は
情報が出力されます。
プーリングが無効の場合には一部の情報が出力されません。この場合、"プーリングが無効の場合"の欄が「－」の項目には必ず0が出
力されます。
背景色が薄い緑色の行は、監視レベルがHIGHの項目です。
- 169 -
項番
項目の内容
プーリングが無
効の場合
D1
当該レコードの性能情報を採取した日時
○
D2
インスタンス名
○
D3
プロセスID
○
D4
JDBC接続プール名
○
D5
接続要求の平均待機時間(単位:ミリ秒) (注1)
○
D6
接続要求の最短待機時間(単位:ミリ秒) (注1)
○
D7
接続要求の最長待機時間(単位:ミリ秒) (注1)
○
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)
○
- 170 -
接続のマッチングに失敗した時
項番
項目の内容
プーリングが無
効の場合
採取条件
D23
待機しているキュー内の接続要求の数
－
プール内の接続数が最大値に達し、全接続が使
用中の時 (注3)
D24
リークが発生した接続の数(注1)
○
接続リーク発生時
注1)：この項目は、監視レベルをHIGHに設定した場合のみ出力されます。
注2)：この物理接続は、JDBCドライバ側から取得した接続です。通常、JDBCドライバ側から取得した接続は物理接続となります。JDBC
ドライバ側のプーリング機能を利用する場合、実際の物理接続は、JDBCドライバ側でキャッシュされるため、JDBCドライバ側から取得
した接続は実際の物理接続ではない場合もあります。
注3)：プーリングが無効のときに、接続プールから取得する接続は最大プールサイズの制限がありません。そのため、プーリングが無
効の場合、プール内の接続数は最大値に達しません。
11) トランザクション情報
トランザクションの性能情報です。
項番
項目の内容
D1
当該レコードの性能情報を採取した日時
D2
インスタンス名
D3
プロセスID
D4
ロールバックされたトランザクションの数
D5
コミットされたトランザクションの数
D6
アクティブなトランザクションの数
採取条件
12) JMS/コネクタ接続プール情報
JMS接続ファクトリ、またはコネクタ接続プールの性能情報です。プールごとに情報を出力します。
コネクタ接続プールの場合、指定したIJServerクラスタに関連付けられたコネクタリソースがひとつもない場合は情報が出力されませ
ん。なお、関連付けを行った後は情報が出力されます。
背景色が薄い緑色の行は、監視レベルがHIGHの項目です。
項番
項目の内容
採取条件
D1
当該レコードの性能情報を採取した日時
D2
インスタンス名
D3
プロセスID
D4
コネクタ接続プール名
D5
接続要求の平均待機時間(単位:ミリ秒) (注)
D6
接続要求の最短待機時間(単位:ミリ秒) (注)
D7
接続要求の最長待機時間(単位:ミリ秒) (注)
D8
最近受け付けた接続要求の待機時間(単位:ミリ秒) (注)
D9
プールから獲得した論理接続数 (注)
D10
作成された物理接続数
D11
破棄された物理接続数
D12
検証に失敗した物理接続数 (注)
アイドルタイムアウトにより接続が破棄
された時
・ 接続検証の有効時、かつ接続検
証に失敗した時
- 171 -
項番
項目の内容
採取条件
・ 接続検証の有効時、かつ「すべて
の障害で」の有効時、かつ接続障
害と判断された時
D13
使用されていない物理接続の最小数
D14
使用されていない物理接続の最大数
D15
使用されていない物理接続の現在数
D16
認証情報のマッチングに失敗した物理接続数 (注)
D17
プールに戻された論理接続数 (注)
D18
認証情報のマッチングに成功した物理接続数 (注)
接続のマッチングに成功した時
D19
タイムアウトになった物理接続数 (注)
接続要求のタイムアウト発生時(最大
待ち時間 > 0)
D20
使用中の物理接続の最小数
D21
使用中の物理接続の最大数
D22
使用中の物理接続の現在数
D23
待機しているキュー内の接続要求の数
D24
採取対象外の項目です。 (注)
接続のマッチングに失敗した時
プール内の接続数が最大値に達し、
全接続が使用中の時
注)：この項目は、監視レベルをHIGHに設定した場合のみ出力されます。
5.19 プロファイラ設定
プロファイラ設定により、プロファイラツール用の設定を管理できます。
必要に応じてプロファイラの有効/無効を切り替えることができるため、普段はプロファイラを無効にしておき、性能問題の解析が必要と
なった際、プロファイラを有効にして分析を行うといった運用が可能です。
定義項目の詳細については、「Java EE運用ガイド」－「Java VMの定義項目」を参照してください。
なお、プロファイラツールと組み合わせた運用については、Interstage Application Serverの技術情報サイト(http://software.fujitsu.com/
jp/technical/interstage/apserver/)でも情報を公開しています。
5.19.1 プロファイラ設定の運用方法
プロファイラ設定の基本運用の流れは、以下のとおりです。
- 172 -
プロファイラ設定の作成
プロファイラ設定の作成は、Interstage Java EE管理コンソール、またはasadminコマンドにより行います。
操作方法の詳細については、以下を参照してください。
－ Interstage Java EE管理コンソールヘルプ
－ 「リファレンスマニュアル(コマンド編)」－「create-profilerサブコマンド」
プロファイラ設定の削除
プロファイラ設定の削除は、Interstage Java EE管理コンソール、またはasadminコマンドにより行います。
操作方法の詳細については、以下を参照してください。
－ Interstage Java EE管理コンソールヘルプ
－ 「リファレンスマニュアル(コマンド編)」－「delete-profilerサブコマンド」
プロファイラ設定配下のJVMオプションの作成
プロファイラ設定配下のJVMオプションの作成は、Interstage Java EE管理コンソール、またはasadminコマンドにより行います。
操作方法の詳細については、以下を参照してください。
－ Interstage Java EE管理コンソールヘルプ
－ 「リファレンスマニュアル(コマンド編)」－「create-jvm-optionsサブコマンド」
プロファイラ設定配下のJVMオプションの削除
プロファイラ設定配下のJVMオプションの削除は、Interstage Java EE管理コンソール、またはasadminコマンドにより行います。
操作方法の詳細については、以下を参照してください。
－ Interstage Java EE管理コンソールヘルプ
－ 「リファレンスマニュアル(コマンド編)」－「delete-jvm-optionsサブコマンド」
- 173 -
第6章 J2EEのチューニング
J2EEのチューニングについては、「J2EE ユーザーズガイド(旧版互換)」を参照してください。
- 174 -
第7章 業務構成管理機能のチューニング
業務構成管理機能が管理するリポジトリの設定値をチューニングすることで、最適な状態での運用を行うことが可能となります。ここで
は、業務構成管理機能が管理するリポジトリのチューニングについて説明します。
7.1 リポジトリのチューニング
リポジトリのチューニングについては、以下のマニュアルを参照してください。
・ “運用ガイド(基本編)”の“業務構成管理機能”
- 175 -
第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 5.0、6のドキュメントは、それぞれ次のURLにあります。
・ JDK 5.0: http://java.sun.com/j2se/1.5.0/ja/docs/ja/index.html
・ JDK 6 : http://java.sun.com/javase/ja/6/docs/ja/index.html
上記のドキュメントは、オンラインマニュアルCDの次の箇所にも格納しています。
・ JDK 5.0: \ApplicationServer\javadocs\jdk5-jdkdocs.zip
・ JDK 6 : \ApplicationServer\javadocs\jdk6-jdkdocs.zip
Java VisualVMのドキュメントは、オンラインマニュアルCDに含まれていません。
Java VisualVMに関しては、以下のURLを参照してください。
http://java.sun.com/javase/ja/6/docs/ja/technotes/guides/visualvm/index.html
なお、Java VisualVMは、JDK 6から搭載しているツールです。
また、javaコマンドおよびJava VMのオプションには、チューニングに関するオプションがあります。本章では、これらのオプションを随
所で紹介します。
各オプションの詳細は、次を参照してください。なお、本マニュアル内で具体的に説明していないJava VMのチューニングに関する
オプションは、富士通版Java VMではサポートしておりません。
・ javaコマンドのオプション
JDKドキュメントの「JDKツールとユーティリティ」の「java」
・ Java HotSpot VM Options
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
■Java プラットフォーム移行ガイド
JDK 1.3で開発されたJavaプログラムを、JDK 5.0に移行する際の非互換や問題点については、「Java プラットフォーム移行ガイド (バー
ジョン 1.3 から 5.0 へ)」を参照してください。
このガイドは、オンラインマニュアルCDの次の箇所に格納しています。
・ \ApplicationServer\JavaplatformMigration\jm_white_paper_r6a-jp.pdf
- 176 -
JDK5.0からJDK6への移行については、以下のURLを参照してください。
・ http://www.oracle.com/technetwork/java/javase/adoptionguide-137484.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 HotSpot
Client VM
アプリケーション起動時間を短縮し、メモリ消費を抑制するように設計されたクライ
アント環境向けのJava VMです。
富士通版Java HotSpot Client VMでは、Oracle CorporationのJava VMであるJava
HotSpot Client VMをベースに、富士通独自技術によるトラブルシューティングに関
する機能強化などを追加実装しています。
そのため、ベースとしたJava HotSpot Client VMと機能的な互換性を基本的にもっ
ています。
追加実装された機能項目については、“8.1.3 FJVM”を参照してください。
Java HotSpot
Server 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 5.0、6では、エルゴノミクス機能によるJava VMの自動選択機能（マシンのCPU数や物理メモリ量などに応じて、使
用するJava VMを自動的に選択する機能）は無効になっています。
■Java VM関係の資料
Java VMの詳細は、JDKドキュメンテーションの次を参照してください。
・ JDK 5.0の場合: [J2SEの概要] > [Java 仮想マシン] および [新機能と拡張機能] > [仮想マシン]
・ JDK 6の場合 : [Java SE 6 概要] > [Java 仮想マシン] および
http://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/index.html
他にも、Java VMに関連する資料があります。
- 177 -
・ The Java Virtual Machine Specification (Java VM仕様書)
http://java.sun.com/docs/books/jvms/
・ Java HotSpot VM Options
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
・ Tuning Garbage Collection with the 5.0 Java Virtual Machine
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
8.1.3 FJVM
本章におけるJava VMに関する情報は、デフォルトのJava VMである「富士通版Java HotSpot Server VM(=FJVM)」を中心に説明し
ています。なお、特に断り書きの無い限り、それらの情報は「富士通版Java HotSpot Client VM(=Java HotSpot Client VM)」に対して
も、そのまま適用されます。
FJVMにおいて提供される「富士通独自技術により強化された機能および固有機能」は以下のとおりです。
FJVM固有機能を除き、Java HotSpot Client VMも同様です。
・ New世代領域サイズ自動調整機能付きGC（FJGC）(注)
・ 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に共通する内容を説明します。
■仮想メモリ
OSは、物理メモリ(RAM)だけでなくスワップファイルを活用することにより、多くのメモリ領域を使用することができます。このテクノロ
ジーを仮想メモリといいます。仮想メモリの容量は、RAMとスワップファイルのサイズの合計になります。
図1 OSが利用可能なメモリ容量
- 178 -
ただし、ハードディスクへのアクセスは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ビットモードに変更して実行する場合、ポインタを扱うために必要となる
メモリ量の単位が、４バイトから８バイトになります（OSによっては、整数を扱う際に必要となるメモリ量の単位も異なります）。そのため、
同じソースから作られたプログラムの場合であっても、64ビットOS上で64ビットモードのプログラムを使ってアプリケーションを動作させ
る場合は、32ビットOSまたは64ビットOS上で32ビットモードのプログラムを使ってアプリケーションを動作させる場合よりも、より大きなメ
モリ量が必要となります。
64ビットモード時のCデータ型モデル
- 179 -
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つの方法を用いて実行します。
・ インタプリタによるバイトコードの実行
・ 動的コンパイルにより、バイトコードを機械命令に翻訳してから実行
あるクラスファイル中の同じJavaメソッドを実行する場合であっても、Java VMによる実行方法が異なる場合は、実行時に使用され
るスタックの大きさが異なります。
なお、クラスファイルの実行方法については、“8.3 動的コンパイル”を参照してください。
- 180 -
ユーザ空間のメモリ不足によるスレッド生成エラー
スタックは、プロセス内のユーザ空間から割り当てられます。
そして、ユーザ空間のメモリ不足によりスタックなどを割り当てることができなった場合には、スレッド生成処理でエラーが発生します。
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”オプションで指
定することができます。
・ Permanent世代領域
Permanent世代領域は、Javaのクラス、メソッドや定数など、永続的に参照される静的オブジェクトを管理する領域です。
Permanent世代領域に存在する不要となったオブジェクトは、FullGC処理によって回収されます。
なお、Permanent世代領域の大きさの初期値および最大値は、それぞれ、“-XX:PermSize”オプションおよび“-XX:MaxPermSize”
オプションで指定することができます。
- 181 -
ユーザ空間
Javaヒープは、Javaプロセスのユーザ空間内に割り当てられます。
また指定された最大値までJavaヒープが利用できる環境にするため、Java VM起動時に、メモリ割り当てプールおよびPermanent世
代領域を、各最大値の大きさで連続領域としてリザーブします（同一プロセス内の他の処理から使用できないようにします）。
このため、Javaヒープの最大値を大きく設定すると、その分だけスタックなど他の処理に割り当てられるメモリ領域が減少します。
別な言い方をすれば、ユーザ空間内で使用できるメモリ量の上限から、Javaアプリケーション自身、Java VM、そしてネイティブモジュー
ル(OSを含む)が使用するメモリ量などを差し引いた値が、Javaヒープとして使用できる上限となります。
なおJava VM起動時に指定されたJavaヒープの大きさが利用できない場合、Java VMは以下のメッセージを出力し、Javaプロセスを
終了させます。
Error occurred during initialization of VM
Could 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 VM
mmap failure
Javaアプリケーション実行中の場合:
制御名: mmap failed: errno=エラー情報, 制御情報....
(上記メッセージに続いて、java.lang.OutOfMemoryErrorメッセージが出力される場合があります。)
制御名 : メモリ不足が発生した際のJava VMの制御名
エラー情報：メモリ不足が発生した際のJava VMのエラー情報
制御情報 : メモリ不足が発生した際のJava VMの制御情報
ユーザ空間が不足している場合は、Javaヒープを小さくするチューニングを行ってください。
仮想メモリが不足している場合は、他の不要なプロセスを終了して仮想メモリに余裕を持たせるか、物理メモリ(RAM)またはスワップ
ファイルを拡張して仮想メモリを増やすようにチューニングを行ってください。
ユーザ空間
Java VMは、OSの仮想メモリ資源を効率的に利用するために、起動時にJavaヒープの各領域の初期値を割り当て、各領域の最大値
まで段階的に拡大する制御方法を用いています。
具体的には、Javaプロセスの起動時はメモリ割り当てプールおよびPermanent世代領域の各初期値のサイズを割り当てます。その
後、FullGC処理の結果、各領域が不足した場合、各領域の最大値まで、段階的に拡大していきます（GC処理としてパラレルGCを使
用している場合は、メモリ割り当てプールの大きさが、初期値よりも小さくなる場合があります）。
なお、各領域を拡大していく過程で、OS側で物理メモリの資源をディスクにスワップする処理が発生する場合があります。このスワッ
プ処理により、各領域を拡大するFullGC処理に時間がかかる場合があります。FullGC処理中のスワップ処理発生による時間遅延が
問題になる場合は、Javaヒープの各領域に対する初期値と最大値は同じ値に指定してください（GC処理としてパラレルGCを使用して
いる場合は、メモリ割り当てプールの最小使用量保証機能を有効にすることが必要となる場合があります）。
パラレルGCについては、“8.2.4 New世代領域用制御処理並列化機能付きGC（パラレルGC）”を参照してください。
- 182 -
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:+UseFJGC
-XX:+UseParallelGC
-XX:UseFJcmsGC
【ガーベジコレクション処理のチューニング用オプション】
パラレルGC用：
-XX:ParallelGCThreads
-XX:+UseAdaptiveSizePolicyMinHeapSizeLimit
-XX:-UseAdaptiveSizePolicyMinHeapSizeLimit
-XX:+AutomaticallyJavaHeapSizeSetting
-XX:GCTimeLimit
-XX:GCHeapFreeLimit
-XX:+UseGCTimeLimit (JDK/JRE 5.0の場合)
-XX:+UseGCOverheadLimit (JDK/JRE 6の場合)
CMS付きパラレルGC用：
-XX:ParallelGCThreads
-XX:ConcGCThreads (JDK/JRE 6の場合)
共通：
-XX:-UseCompressedOops (64ビットモード版JDK/JRE 6の場合)
【チューニングの際に使用するログ出力などのデバッグ用オプション】
- 183 -
ガーベジコレクションのログ出力用：
-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++等を使用した)ネイティブプログラムを、Java Native Interface(JNI)
経由で利用してはいけません。実現しようとしている機能が、Javaにより記述できないか設計段階で十分に検討を行ってください。やむ
をえず利用する場合でも、JNIの利用は最小限にし、十分な確認とデバッグを実施してください。
JNIを利用する場合の前提スキルとして、以下は必須です。
・ C/C++によるマルチスレッドプログラミングの経験がある
・ トラブル発生時、自分でデバッグできる
ファイナライズ処理を期待したリソース管理は、行わないでください。JNI関連で、もっともトラブルが多いのは、ネイティブプログラム側
で確保したメモリの後処理漏れです。例えば、次のようなプログラミングをしてはいけません。
------- Java --------------class A {
native long nativeAlloc();
native void nativeFree(long a);
long address;
A() {
address = nativeAlloc();
}
public void finalize() {
nativeFree(address);
}
}
------- Java --------------------- C -----------------JNIEXPORT jlong JNICALL Java_A_nativeAlloc(JNIEnv *env, jobject o)
{
return (jlong)malloc(10);
- 184 -
}
JNIEXPORT void JNICALL Java_A_nativeFree(JNIEnv *env, jobject o, jlong p)
{
free((void*)p);
}
------- C -------------------
エラー処理は、必ず行ってください。ネイティブプログラム側でJNI関数呼び出しをしたとき、色々なケースでJavaレベルのエラーにな
ることがあります。このエラーに対する後処理をネイティブプログラム側で行わないと、例外がスローされている状態のままになり、それ
以降のJNI関数の呼び出しに失敗し、アプリケーションが正しく動作しません。
なお「JNI関数」とは、以下のJNI仕様書に記述されている関数のことです。
http://download.oracle.com/javase/1.5.0/docs/guide/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制御方法の違いにより、以下の
4種類があります。
・ 標準GC（シリアルGC）
・ New世代領域サイズ自動調整機能付きGC（FJGC）
・ New世代領域用制御処理並列化機能付きGC（パラレルGC）
・ コンカレント・マーク・スイープGC付きパラレルGC（CMS付きパラレルGC）
なお、JDK/JREのバージョン、実行モード、Java VMの種類により、サポートされるGCの種類が異なります。また、Java VMの種類によ
り、デフォルトで動作するGCが異なります。
“表8.2 サポートされるGCの種類”に、サポートされるGCの種類とデフォルトのGCを示します。
表8.2 サポートされるGCの種類
JDK/JREのバージョン
JDK/JREの実行モード
Java VMの種類
シリアルGC
JDK/JRE 5.0
32ビットモード
JDK/JRE 6
64ビットモード
32ビットモード
64ビットモード
Client VM
FJVM
FJVM ※
Client VM
FJVM
FJVM ※
◎
○
○
◎
○
○
○
FJGC
パラレルGC
○
◎
◎
○
◎
◎
CMS付きパラレルGC
□
□
□
□
□
□
- 185 -
○：サポートされるGC
◎：サポートされるGC、かつデフォルトのGC
□：Interstage Application Server Enterprise EditionでだけサポートされるGC
※実行モードが64ビットモードのClient VMは提供していません。
GCは、デフォルトのGCの使用を推奨します。
通常、デフォルトのGCを変更する必要はありません。
■New世代領域の使われ方
FJGC以外のGC処理におけるNewGC処理では、New世代領域を「eden space」、「from space」および「to space」の3つの内部領域に
細分割し、当該領域上において、一般に世代別GC制御と言われる制御方法を用いて、Javaアプリケーションが生成要求したオブジェ
クトを管理・制御しています。
このうち、「from space」および「to space」は、Java VMがNewGC処理を行う際の作業域的な役割を持つ領域となっています。そのた
め、「from space」および「to space」の各領域が占める大きさのうち、Javaアプリケーションからのオブジェクト生成要求のために使用され
る大きさは、その領域の一部分だけとなります。
そのため、FJGC以外のGC処理を使用している場合は、ガーベジコレクションのログ出力などの出力データにおいて、メモリ割り当て
プールやNew世代領域に空きがあるように見える場合であっても、実際には空きがない場合があります（空きがあるように見える場合で
あっても、その差は、NewGC処理用の作業域的な役割で使用済となっている場合があります）。
■ガーベジコレクション処理の実行抑止
“表8.3 ガーベジコレクション処理の実行が抑止される機能”に示す機能を使用するJavaアプリケーションを実行すると、Javaヒープ内に
存在する全オブジェクトの移動が禁止されるクリティカルセクションと呼ばれる状態が、当該機能の利用状況に応じて発生します。
クリティカルセクション状態発生時は、オブジェクトの移動が禁止されるため、オブジェクト移動が必須となるGC処理の実行が抑止さ
れる状態となります。
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
- 186 -
- 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
■JVMPIとJVMTI
次の場合、Java Virtual Machine Profiling Interface(JVMPI)をサポートしていません。
・ JDK/JRE 5.0を使用し、GC処理としてパラレルGCまたはCMS付きパラレルGCが選択されている場合
・ JDK/JRE 6を使用している場合
JVMPI相当の機能を使用する場合には、JDK/JRE 5.0から導入されたJava Virtual Machine Tool Interface(JVMTI)を使用してくださ
い。
JDK/JRE 5.0でJVMPI機能は推奨されていません。やむを得ず使用する場合は、GC処理としてシリアルGCを使用してください。
■RMI処理の分散GC
JavaのRMI処理では、クライアントで不要となった参照に対するサーバ側のオブジェクトを破棄するため、Distributed GC(分散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 JDK/JRE 5.0、6のFJVMでシリアルGCを有効にする場合に指定するオプション
-XX:+UseSerialGC
図2はシリアルGC使用時に利用可能となる「Javaヒープのチューニング用オプション」です。
図2 Javaヒープチューニング用オプション（シリアルGC使用時）
- 187 -
-Xms
-Xmx
-XX:NewSize
-XX:MaxNewSize
-XX:NewRatio
-XX:SurvivorRatio
-XX:TargetSurvivorRatio
-XX:PermSize
-XX:MaxPermSize
8.2.3 New世代領域サイズ自動調整機能付きGC（FJGC）
New世代領域用GC制御に対し、富士通独自技術による「New世代領域サイズ自動調整機能(以降、自動調整機能と略する)」を追加
して構成されたGC処理です。富士通独自技術によるGC制御を用いていることから、このGCをFJGCと呼ぶ場合もあります。
本機能は、実行モードが32ビットモードのJDK/JRE 5.0に搭載されたFJVMにだけ提供されており、図1のオプションを指定した場合
に、このGC処理が実行されます。
図1 JDK/JRE 5.0のFJVMでNew世代領域サイズ自動調整機能を有効にするオプション
-XX:+UseFJGC
図2はFJGC使用時に利用可能となる「Javaヒープのチューニング用オプション」です。
なお、FJGC使用時かつNew世代領域サイズ自動調整機能が有効な場合は、JavaヒープのNew世代領域およびOld世代領域の大き
さに関する値が自動的に調整および最適化されるため、New世代領域の大きさやNew世代領域とOld世代領域の大きさのバランスを
チューニングするためのオプションは使用できません。
図2 Javaヒープチューニング用オプション（FJGC使用時）
-Xms
-Xmx
-XX:NewSize (注)
-XX:MaxNewSize (注)
-XX:NewRatio (注)
-XX:PermSize
-XX:MaxPermSize
注) New世代領域の大きさや、New世代領域とOld世代領域の大きさのバランスをチューニングするためのオプションです。
図4で示す範囲よりも大きな値を“-Xmx”オプションで指定し、自動調整機能が停止した場合にだけ、このオプションへの指定値は有
効となります。
New世代領域サイズ自動調整機能未提供のJava VM
次のJava VMには、New世代領域サイズ自動調整機能を提供していません。
・ Java HotSpot Client VM
・ 実行モードが64ビットモードのJDK/JRE 5.0に搭載されたFJVM
・ JDK/JRE 6のFJVM
Java HotSpot Client VMに図1のオプションを指定した場合は、図3のエラーメッセージが標準エラー出力へ出力され、Javaプロセスの
起動に失敗します。
FJVMに図1のオプションを指定した場合は、図3のワーニングメッセージが標準エラー出力へ出力され、オプションの指定は無効にな
ります。
図3 -XX:+UseFJGCを指定した際に出力されるメッセージ
【Java HotSpot Client VMの場合】
- 188 -
Unrecognized VM option '+UseFJGC'
【実行モードが64ビットモードのFJVMの場合】
warning: -XX:+UseFJGC is not supported in Java HotSpot 64-Bit Server VM.
【実行モードが32ビットモードでJDK/JRE 6のFJVMの場合】
warning: -XX:+UseFJGC is not supported in Java HotSpot Server VM.
■New世代領域サイズ自動調整機能
自動調整機能は、Javaアプリケーションの実行状況(オブジェクト生成要求および解放タイミングの状態変動)などの情報から、Javaヒー
プのNew世代領域の大きさに関する値を自動的に調整および最適化する機能です。
自動調整機能は、“メモリ割り当てプールの最大サイズ”が図4に示す値の範囲内である場合に有効となります。(“メモリ割り当てプー
ルの最大サイズ”は、“-Xmx”オプションで指定できます。)
“メモリ割り当てプールの最大サイズ”が図4で示す範囲よりも大きな値である場合は、FJVM起動時に図5のメッセージが標準出力へ
出力され、自動調整機能は停止状態となります。
自動調整機能が停止状態となった場合は、New世代領域の大きさに対する自動調整処理は行なわれず、シリアルGCによるGC制御
と同じ処理方法で、New世代領域の大きさが制御されるようになります。ただし、その場合に使用できるJavaヒープチューニング用オプ
ションは、図2で示すオプションだけになります。
図4 自動調整機能が有効となるメモリ割り当てプールの最大サイズ
JDK/JRE 5.0: 700MB以下
JDK/JRE 5.0: 2250MB以下
JDK/JRE 5.0: 1500MB以下
図5 自動調整機能停止時に出力されるメッセージ
Heap too large for dynamic eden: using static eden
JDK/JRE 5.0のFJVMで自動調整機能を有効にしている場合で、かつ以下のような場合には、自動調整機能を有効にするオプション
を削除し、FJGC以外のGCを使用してください。
・ Javaヒープに対するチューニングを手動で行いたい場合:
Java HotSpot Server VMを使用する場合と同じように、Javaヒープチューニング用オプションを用いてJavaヒープに対するチューニ
ングを行いたい場合には、FJGC以外のGCを使用してください。
・ ネイティブモジュールで使用するメモリ量をある程度確保する必要がある場合:
自動調整機能が有効な場合、当該機能が使用する作業域（“-Xmx”オプションで指定した値の2/3の大きさ）をユーザ空間から確
保（リザーブ処理だけの確保）しています。
そのため、“-Xmx”オプションで図4に示す範囲内でかつその上限値近くの値を指定した場合、自動調整機能が使用する作業域
確保のため、ネイティブモジュールから使用できるスタックやヒープなどのメモリ量が非常に少なくなっています。
図4に示す範囲の上限値近くの値のメモリ割り当てプールの大きさを確保し、かつネイティブモジュールで使用するスタックやヒー
プなどのセグメントに対するメモリ量もある程度確保する必要がある場合には、FJGC以外のGCを使用してください。
・ Javaプロセスのユーザ空間から連続域の状態で確保できるメモリ量が小さいシステムの場合:
自動調整機能が有効な場合、メモリ割り当てプールと自動調整機能用の作業域を連続域としてユーザ空間から確保しています。
また、ユーザ空間から連続域として確保できる最大メモリ量は、システムごとに異なります。
そのため、“-Xmx”オプションで指定したメモリ割り当てプールの大きさが図4に示す値の範囲内であっても、Javaプロセスのユー
ザ空間から、メモリ割り当てプールと自動調整機能用の作業域が連続域として確保できない場合には(Javaプロセスのユーザ空間
から、連続域の状態で確保できるメモリ量が小さいシステムの場合には)、FJVMは以下のメッセージを出力して、Javaアプリケーショ
- 189 -
ンの実行を中止します。
その場合は、より小さな値を“-Xmx”オプションで指定するか、FJGC以外のGCを使用してください。
Error occurred during initialization of VM
Could not reserve enough space for object heap
・ GC処理実行抑止によりjava.lang.OutOfMemoryErrorが発生した場合:
自動調整機能では、Javaヒープ域におけるNew世代領域とOld世代領域の比率をJavaアプリケーションからのオブジェクト生成要
求および解放タイミングの状態変動により動的に変更します。
そしてNew世代領域とOld世代領域を管理するメモリ割り当てプールの大きさには上限があるため、ある時点においてNew世代
領域のサイズを調整・最適化した結果、New世代領域が大きくなった場合は、Old世代領域のサイズは小さくなります（逆にNew世
代領域が小さくなった場合は、Old世代領域のサイズは大きくなります）。
そのため自動調整機能が有効な場合、以下の条件に合致するJavaアプリケーションを実行すると、Old世代領域が小さくなって
いる時とJavaアプリケーションによりGC処理の実行が抑止されている時が重なるタイミングが多くなることがあり、結果的にGC処理
実行抑止によるjava.lang.OutOfMemoryErrorの発生が、自動調整機能を無効とした場合よりも多くなることがあります。
－ 寿命の短いオブジェクトを多用するJavaアプリケーション。かつ、
－ GC処理の実行が抑止される機能を多用するJavaアプリケーション。
GC処理実行抑止によるjava.lang.OutOfMemoryErrorの発生傾向が強い場合は、FJGC以外のGCを使用してください。
なおGC処理の実行が抑止される機能については“表8.3 ガーベジコレクション処理の実行が抑止される機能”を参照してくださ
い。
8.2.4 New世代領域用制御処理並列化機能付きGC（パラレルGC）
New世代領域用GC制御に対し、「当該処理を並列化して実行する機能」を追加して構成されたGC処理です。New世代領域用のGC
制御を並列化して実行することから、このGCをパラレルGCと呼ぶ場合もあります。
図1のオプションは、パラレルGCによるGC制御を有効にするオプションです。
JDK/JRE 5.0、6のFJVMの場合は、デフォルトでこのGC処理が実行されます。
図1 JDK/JRE 5.0、6でパラレルGCを有効にする場合に指定するオプション
-XX:+UseParallelGC
図2はパラレルGC使用時に利用可能となる「Javaヒープのチューニング用オプション」です。
なお、パラレル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処理用スレッドの
- 190 -
数を指定することにより、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 5.0、6の機能であるエルゴノミクス機能によるメモリ割り当てプールの初期値(-Xms)および最大
値(-Xmx)の省略値自動調整機能（マシンの物理メモリ量などに応じて、-Xmsおよび-Xmxの各オプションに対する省略値を自動的に
決定する機能）を無効にしています。
JDK/JRE 5.0、6のFJVMで、エルゴノミクス機能によるメモリ割り当てプールの省略値自動調整機能を有効にする場合は、図4のオプ
ションを指定してください。
ただし、このオプション指定は、システムのメモリ資源不足の要因となる場合があるため、システム内に複数のJavaプロセスを起動、実
行する場合には使用しないでください。
図4 JDK/JRE 5.0、6でメモリ割り当てプールの省略値自動調整機能を有効にするオプション
-XX:+AutomaticallyJavaHeapSizeSetting
メモリ領域不足事象の検出機能
FJVMのパラレルGCでは、JDK/JRE 5.0、6の機能であるエルゴノミクス機能によるメモリ領域不足事象の検出機能（図5の各オプショ
ン指定値による条件が同時に成立した場合に、メモリ領域不足事象（java.lang.OutOfMemoryError）として検出する機能）を無効にし
ています。
JDK/JRE 5.0、6のFJVMでエルゴノミクス機能によるメモリ領域不足事象検出機能を有効にする場合は、図6のオプション（使用する
JDK/JREの違いにより異なるため注意が必要です）を指定してください。
ただし、このオプション指定で検出されるメモリ領域不足事象は、Javaヒープの使用量だけではなく、メモリ領域不足事象検出用オプ
ションで指定された値、およびガーベジコレクション処理の動作状況から得られた統計情報などを元に決定されるため、Javaヒープの
使用量が不足していない状態であっても、 メモリ領域不足事象が検出される場合がありますので注意してください。
図5 メモリ領域不足事象検出条件
-XX:GCTimeLimit=GC処理に要する時間の上限値 (デフォルトは98)
Javaアプリケーションの合計処理時間に対して、GC処理に要した時間の上限値をパーセント単位(%)で
指定します。
指定された上限値を超えた場合、検出条件の一方が成立します。
-XX:GCHeapFreeLimit=GC処理後のJavaヒープ量の空きスペースの下限値 (デフォルトは2)
メモリ割り当てプールの最大値に対する、GC処理後のJavaヒープ量の空きスペースの下限値をパーセン
ト単位(%)で指定します。
指定された下限値を下回った場合、検出条件の一方が成立します。
- 191 -
図6 JDK/JRE 5.0、6でメモリ領域不足事象検出を有効にするオプション
【JDK/JRE 5.0の場合】
-XX:+UseGCTimeLimit
【JDK/JRE 6の場合】
-XX:+UseGCOverheadLimit
パラレルGC処理のエルゴノミクス機能およびメモリ割り当てプールの最小使用量保証機能
FJVMでパラレルGCを使用した場合、JDK/JRE 5.0、6の機能であるパラレルGC処理のエルゴノミクス機能（メモリ割り当てプール内
の各世代領域サイズの動的変更機能）により、Javaアプリケーションの実行状況や負荷／GC処理に掛かる時間などの情報から、GC
処理としての最適動作状態になるように、メモリ割り当てプール内の各世代領域サイズが自動的に調整・変更および最適化されます。
その際、メモリ割り当てプールの使用量が-Xmsオプションで指定した値（メモリ割り当てプールの初期値）よりも小さくなることあります
（-Xmsオプションで指定した値よりも下回るメモリ割り当てプールの使用量で、GC処理としての最適動作状態になることがあります）。
パラレルGCを使用してJavaアプリケーションを実行する際、メモリ割り当てプールの使用量についての操作を行なう場合は、以下の
オプションを指定してください。
メモリ割り当てプールの最小使用量保証機能を操作するオプション
【-Xmsオプションで指定した値よりもメモリ割り当てプールの使用量を小さくしない場合】
-XX:+UseAdaptiveSizePolicyMinHeapSizeLimit
パラレルGC処理のエルゴノミクス機能動作時、-Xmsオプション指定値によるメモリ割り当てプールの最小使用量保証機能を有効に
します。
Javaアプリケーション実行時に使用されるメモリ割り当てプールの大きさは，「-Xmsオプション指定値」から「-Xmxオプション指定値」
の範囲で変動します。
（-Xmsオプション指定値と-Xmxオプション指定値が等しい場合、使用中となるメモリ割り当てプールの大きさは変動しません。）
この状態は、JDK/JRE 6でパラレルGCを使用する場合のデフォルト状態です。
【-Xmsオプションで指定した値よりもメモリ割り当てプールの使用量を小さくして良い場合】
-XX:-UseAdaptiveSizePolicyMinHeapSizeLimit
パラレルGC処理のエルゴノミクス機能動作時、-Xmsオプション指定値によるメモリ割り当てプールの最小使用量保証機能を無効に
します。
Javaアプリケーション実行時に使用されるメモリ割り当てプールの大きさは，「Java VMとしての下限値」から「-Xmxオプション指定値」
の範囲で変動します。
（-Xmsオプション指定値と-Xmxオプション指定値が等しい場合であっても、使用中となるメモリ割り当てプールの大きさは変動しま
す。）
なお、Javaアプリケーションの実行時に使用されるメモリ割り当てプールの大きさが-Xmsオプション指定値よりも小さくなった場合、Full
GCの発生間隔が、Javaプロセス起動時近辺における発生間隔よりも短くなってしまう場合があります。しかし、パラレルGC処理のエル
ゴノミクス機能は、GC処理に掛かる時間情報も考慮した上で、GC処理としての最適動作状態となるように調整しています(メモリ割り当
てプールを縮小しても、Full GCに掛かる時間が少ない状態の場合に最適動作状態としています)。そのため、メモリ割り当てプールの
縮小によりFull GCの発生間隔が短くなった場合でも、Javaアプリケーション実行時の性能に対する影響はほとんどありません。
この状態は、JDK/JRE 5.0でパラレルGCを使用する場合のデフォルト状態です。
なおメモリ割り当てプールの最小使用量保証機能の有効／無効に関わらず、Javaプロセス起動時に使用されるメモリ割り当てプール
の大きさは、-Xmsオプションで指定された値となります。
- 192 -
8.2.5 コンカレント・マーク・スイープ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 5.0、6にだけ提供しています。
・ Interstage Application Server Enterprise Edition
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アプリケーション動作と並行して増加させることができるため、Full GCの発生を抑えることができます。これにより、Java
アプリケーションはFull GCにより停止される影響を受けにくくなり、応答性能平準化の改善が期待できます。
なおCMS-GC動作中は、NewGC処理/Full GC処理の実行開始が遅延する場合があります。そして遅延期間中は、Javaアプリケーショ
ンとしての動作も停止します。そのため、ガーベジコレクション処理の結果ログ内のNewGC処理/Full GC処理に対して出力されたGC
処理実行時間よりも長い間、Javaアプリケーションとしての動作が停止している場合があります。
図1 JDK/JRE 5.0、6でCMS付きパラレルGCを有効に場合に指定するオプション
-XX:UseFJcmsGC=タイプ
タイプとして以下の値が指定できます
[CMS-GCによる不要オブジェクトの回収対象を「Old世代領域内」とする場合]
type0
type1
type2
[CMS-GCによる不要オブジェクトの回収対象を「Old世代領域内およびPermanent世代領域内」とする場
合]
type0p
type1p
type2p
CMS-GCによる不要オブジェクトの回収対象を、Old世代領域内だけでなくPermanent世代領域内にまで拡大した場合、CMS-GCとし
ての処理対象域が増加することになるため、CMS-GC完了までの実行時間増加に繋がり易くなります。
その結果、実行するアプリケーションや実行環境によっては、CMS-GCによる回収処理が間に合わなくなり、FullGCの発生に繋がる
場合もありえます。
そのため、回収対象が「Old世代領域内」で正常動作していた環境において、回収対象を「Old世代領域内およびPermanent世代領
域内」にまで拡大する場合は、再度のチューニング作業が必要となります．
-XX:UseFJcmsGC=type0またはtype0pが指定された場合
- 193 -
図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
-XX:UseFJcmsGC=type1またはtype1pが指定された場合
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が発生しやすくなってしまうので注意が必要です。
図3は-XX:UseFJcmsGC=type1およびtype1p指定時に利用可能となる「Javaヒープのチューニング用オプション」です。
図3 Javaヒープチューニング用オプション（-XX:UseFJcmsGC=type1およびtype1p指定時）
-Xms
-Xmx
-XX:NewSize
-XX:MaxNewSize
-XX:PermSize
-XX:MaxPermSize
-XX:UseFJcmsGC=type2またはtype2pが指定された場合
CMS-GCでのオブジェクト回収を重視した調整が成されたCMS付きパラレルGCを使用する場合に指定します。
実行されるアプリケーションの特徴が「大半のオブジェクトが、何回かのGCを経てから回収される(長期間常駐せず、ある程度の短期
間で回収される)オブジェクト」である場合に、CMS-GCによる応答性能平準化の改善効果が得やすい調整になっています。
Javaヒープのチューニングを行なう場合は、まず-Xms/-Xmxおよび-XX:PermSize/-XX:MaxPermSizeの各オプションにより、メモリ割り
当てプールおよびPermanent世代領域の大きさを調整します。そして必要に応じて、-XX:NewSize/-XX:MaxNewSizeの各オプション
でNew世代領域の大きさを調整します。
なおNew世代領域サイズとして、メモリ割り当てプール最大サイズ未満の値を指定できます。ただしNew世代領域サイズを大きくしす
ぎると、Full GCが発生しやすくなってしまうので注意が必要です。
図4は-XX:UseFJcmsGC=type2およびtype2p指定時に利用可能となる「Javaヒープのチューニング用オプション」です。
図4 Javaヒープチューニング用オプション（-XX:UseFJcmsGC=type2およびtype2p指定時）
-Xms
-Xmx
-XX:NewSize
-XX:MaxNewSize
-XX:PermSize
-XX:MaxPermSize
- 194 -
JDK/JRE 5.0のJVMTI
JDK/JRE 5.0を使用し、GC処理としてCMS付きパラレルGCが選択されている場合、Java Virtual Machine Tool Interface(JVMTI)で、
以下の権限を必要とする機能は使用できません。
・ can_tag_objects
・ can_generate_object_free_events
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処理用スレッド数
CMS付きパラレルGCを使用した場合は、以下のCMS-GC処理用スレッドがJavaプロセス内に作成されます。そのため、CMS-GC処
理用スレッドの数分だけ、スタック域などのスレッド用のメモリ領域が必要となります。
・ CMSスレッド (必ず1つ作成されます)
・ コンカレント・マーク処理専用スレッド (JDK/JRE 6の場合に作成できます)
JDK/JRE 5.0の場合は、CMS-GC処理用スレッドとしてCMSスレッドだけが作成されます。
JDK/JRE 6の場合は、CMSスレッドの他、CMS-GC処理の中のコンカレント・マーク処理を複数スレッドで並列化して実行するために、
コンカレント・マーク処理専用スレッドを追加で作成することができます。
そのためJDK/JRE 6の場合は、図6のオプションでCMS-GC処理用スレッドの数を指定することにより、CMS-GC処理用スレッドの数を
調整することができます(JDK/JRE 5.0の場合は、図6のオプションを指定できません)。
なお一般的に、CPU数以上の数のCMS-GC処理用スレッドを作成しても、CMS-GC処理における性能向上にはつながりません。
図6 CMS付きパラレルGCで使用するCMS-GC処理用スレッドの数を指定するオプション
【JDK/JRE 6の場合】
-XX:ConcGCThreads=CMS-GC処理用スレッドの数
コンカレント・マーク処理専用スレッドの数を指定します。
最小値は「2」です．
オプションの指定がない場合、または「1」が指定された場合は、CMSスレッドだけ生成されます。
「0」が指定された場合は、自動的に以下の値が設定されます。
（実行するハードウェアに搭載しているCPU数の1/4(端数切り上げ)をAとした場合）
- Aが1の場合 = 0(CMSスレッドだけ生成されます)
- 195 -
- Aが2以上7以下の場合 = A
- Aが8以上の場合 = 8
なお指定値および自動設定値いずれの場合も、「-XX:ParallelGCThreads」の値よりも大きい場合は、「XX:ParallelGCThreads」の値となります。
8.2.6 オブジェクト参照の圧縮機能
Javaアプリケーションを64ビットモードのJDK/JRE上で動作させる場合、通常のC/C++アプリケーションの場合と同様、実行モード上の
制約から、Javaヒープに格納されるオブジェクト参照（ポインタ情報）で必要となる領域は「64ビット表現/8バイト域」が管理単位となりま
す。
そのため64ビットモードのJDK/JRE上でJavaアプリケーションを動作させる場合、32ビットモードのJDK/JRE上で動作させる場合に対
して、1.5～2倍のJavaヒープ量が必要となります。
しかし64ビットモードで実行されるJDK/JRE 6搭載の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搭載のFJVMの場合は、デフォルト状態でオブジェクト参照圧縮機能が有効になっています。
そのため、Javaアプリケーションとしての実行性能が問題となった場合は、図1のオプションを指定することで、FJVMのオブジェクト参
照圧縮機能を無効にすることができます。
図1 64ビットモードで実行されるFJVMのオブジェクト参照圧縮機能を無効にするオプション
-XX:-UseCompressedOops
注) 64ビットモードで実行されるJDK/JRE 6の場合に指定できます。
8.2.7 ガーベジコレクションのログ出力
ガーベジコレクション(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ログもあります。
- 196 -
[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.7.1 ガーベジコレクション処理の結
果ログ出力機能の強化”を参照してください。
New世代領域の使われ方
FJGC以外のGC処理におけるNewGC処理では、New世代領域を「eden space」、「from space」および「to space」の3つの内部領域に
細分割し、当該領域上において、一般に世代別GC制御と言われる制御方法を用いて、Javaアプリケーションが生成要求したオブジェ
クトを管理・制御しています。
このうち、「from space」および「to space」は、Java VMがNewGC処理を行う際の作業域的な役割を持つ領域となっています。そのた
め、「from space」および「to space」の各領域が占める大きさのうち、Javaアプリケーションからのオブジェクト生成要求のために使用され
る大きさは、その領域の一部分だけとなります。
そのため、FJGC以外のGC処理を使用している場合は、ガーベジコレクションのログ出力において、メモリ割り当てプールやNew世代
領域に空きがあるように見える場合であっても、実際には空きがない場合があります（空きがあるように見える場合であっても、その差
は、NewGC処理用の作業域的な役割で使用済となっている場合があります）。
ログ出力量の増加
本オプションの指定により、ログ出力が増大します。
本オプションを指定する場合は、ログ出力量についての注意が必要です。
クラスのアンロード情報
Javaアプリケーションがクラスのアンローディング処理を行なっていた場合には、FullGC処理中に該当するクラスのアンロード情報”
[Unloading class アンロードされたクラス名]”が出力の途中に挿入される場合があります．
ガーベジコレクション処理の結果ログに対するクラスのアンロード情報出力を抑止する場合は、図4のオプションを指定してください。
図4 GC処理の結果ログに対するクラスのアンロード情報出力を抑止するオプション
-XX:-ClassUnloadingInfo
GC処理結果ログの格納先ファイルの指定
図5のオプションを指定すると、GC処理の結果ログおよびクラスのインスタンス情報を、標準出力ではなく、指定したファイルへ出力先
を切り換えることができます。
なお、Interstage Application Server配下でJavaアプリケーションを実行する際に図5のオプションを指定した場合、以下の問題が発生
します。
・ 図5のオプションによるファイル出力処理には、ログローテーションなどの世代管理機能はありません。何らかの理由でJavaプロセ
スが自動的に再起動した場合、格納先として同じファイルが用いられることになるため、再起動後のGC処理の結果ログで再起動
前の結果ログが上書きされ、ログ情報として使えなくなります。
- 197 -
・ Javaアプリケーションを複数のプロセスで多重動作させる場合、同一のオプション定義で複数のプロセスが動作します。そのため、
複数のプロセスから同じファイルに対してGC処理の結果ログを書き込むことになり、ログ情報として使えなくなります。
・ Interstage Application Server配下でJavaアプリケーションを実行する際のログの出力先は、Interstage Application Serverとしての制
御により、出力先ファイルが管理されています。図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処理の結果ログは、指定された格納先ファイルではなく、従来通り、標準出力へ出力されます。
8.2.7.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処理の種別を以下の名称で示します。
・ GC
New世代領域を対象とするGC処理(NewGC処理またはマイナーGC処理)における結果情報です。
- 198 -
・ Full GC
Javaヒープ域全体(メモリ割り当てプール(New世代領域、Old世代領域)およびPermanent世代領域)を対象とするGC処理(FullGC
処理)における結果情報です。
・ Full GC*
使用されているGC処理がシリアルGC、FJGCまたはCMS付きパラレルGCの場合で、かつ、直前に実行されたNewGC処理では十
分な空き領域が確保できず、そのNewGC処理に続けて実行されたFullGC処理における結果情報です("Full GC"の後に"*"の付
く表示になります)。
なおこの名称は“-verbose:gc”オプションだけを指定した場合には出力されません(単に"Full GC"として出力されます)。
・ CMS initial-mark
Old世代領域を対象とするCMS-GC処理のうち、initialマーク処理における結果情報です。
CMS-GCでは、不要オブジェクトを検出するために行なう処理(initialマーク処理)を実行する際、極わずかな時間だけJavaアプリ
ケーションを停止させます。
注)不要オブジェクトの検出処理だけであるため、GC処理開始前後での各世代領域におけるオブジェクト量に変化はありません。
・ CMS remark
Old世代領域を対象とするCMS-GC処理のうち、finalマーク処理における結果情報です。
CMS-GCでは、不要オブジェクトを検出するために行なう処理(finalマーク処理)を実行する際、極わずかな時間だけJavaアプリケー
ションを停止させます。
注)不要オブジェクトの検出処理だけであるため、GC処理開始前後での各世代領域におけるオブジェクト量に変化はありません。
$3: New世代領域の識別名
New世代領域の識別名を示します。
使用されているGC処理の違いにより、以下の識別名が出力されます。
・ DefNew: シリアルGCの場合
・ SplitEden: FJGCの場合
・ 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世代領域の識別名を示します。
使用されているGC処理の違いにより、以下の識別名が出力されます。
・ Tenured: シリアルGCの場合
・ Tenured: FJGCの場合
・ PSOldGen: パラレルGCの場合
・ CMS: CMS付きパラレルGCの場合
$8: GC処理前のオブジェクト量(Old世代領域)
GC処理実行前のOld世代領域に存在したオブジェクトの総量(バイト)です。
$9: GC処理後のオブジェクト量(Old世代領域)
- 199 -
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世代領域の識別名です。
使用されているGC処理の違いにより、以下の識別名が出力されます。
・ Perm: シリアルGCの場合
・ Perm: FJGCの場合
・ PSPermGen: パラレルGCの場合
・ CMS Perm: CMS付きパラレルGCの場合
$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
図3の各要素について、以下で説明します。
$1: CMS-GC処理の実行開始時間(ログ出力時の時間)
- 200 -
CMS-GC処理の実行開始時間(ログ出力時の時間)を示します。
ログ出力時の時間のフォーマットは、ログ出力における「8.5.7 ログ出力における時間情報のフォーマット指定機能」により指定できます。
デフォルトは、「Java VMが起動されてからの経過時間(秒)」です。
図4 GC処理の結果ログとして出力される情報の拡張形式(FullGC発生によるCMS-GCの終了要求)
$1: CMS stop-req
図4の各要素について、以下で説明します。
$1: CMS-GC処理の終了要求時点(ログ出力時の時間)
Full GC要求発生時にCMS-GC処理が実行中であった場合、CMS-GC処理の終了要求時点(ログ出力時の時間)を示します。
ログ出力時の時間のフォーマットは、ログ出力における「8.5.7 ログ出力における時間情報のフォーマット指定機能」により指定できます。
デフォルトは、「Java VMが起動されてからの経過時間(秒)」です。
注)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
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
図5の各要素について、以下で説明します。
$1: CMS-GC処理の実行終了時間(ログ出力時の時間)
CMS-GC処理の実行終了時間(ログ出力時の時間)を示します。
ログ出力時の時間のフォーマットは、ログ出力における「8.5.7 ログ出力における時間情報のフォーマット指定機能」により指定できます。
デフォルトは、「Java VMが起動されてからの経過時間(秒)」です。
$2: 終了コード
CMS-GC処理の実行結果に対する終了コードを示します。
終了コードの違いにより、情報の出力形式パターンが異なります。
終了コードの種類および意味は以下のとおりです。
・ 00: CMS-GC処理が終了しました。
Old世代領域内またはOld世代領域内およびPermanent世代領域内で検出済の不要オブジェクトは回収しました。
パターン1の出力形式で情報が出力されます。
・ 10: Javaヒープ不足によるFull GC要求があったため、実行中のCMS-GC処理を終了しました。
Old世代領域内またはOld世代領域内およびPermanent世代領域内で検出済の不要オブジェクトは回収しました。
パターン1の出力形式で情報が出力されます。
- 201 -
・ 20: java.lang.System.gc()などの外部要因によるFull GC要求があったため、実行中のCMS-GC処理を終了しました。
Old世代領域内またはOld世代領域内およびPermanent世代領域内で検出済の不要オブジェクトは回収しました。
パターン1の出力形式で情報が出力されます。
・ 11: Javaヒープ不足によるFull GC要求があったため、実行中のCMS-GC処理を終了しました。
Old世代領域内またはOld世代領域内およびPermanent世代領域内の不要オブジェクトは回収していません。
パターン2の出力形式で情報が出力されます。
・ 21: java.lang.System.gc()などの外部要因によるFull GC要求があったため、実行中のCMS-GC処理を終了しました。
Old世代領域内またはOld世代領域内およびPermanent世代領域内の不要オブジェクトを回収していません。
パターン2の出力形式で情報が出力されます。
$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による不要オブジェクトの
回収処理前に、Javaアプリケーションの実行によりPermanent世代領域にオブジェクトが割り当てられたことを示します。
$7: CMS-GC処理後のオブジェクト量(Permanent世代領域)
CMS-GC処理実行後のPermanent世代領域に存在するオブジェクトの総量(バイト)です。
$8: Permanent世代領域の大きさ
Permanent世代領域の大きさ(バイト)です。
$9: CMS-GC処理実行時間
CMS-GC処理実行に要した時間(秒)です(CMS-GC開始からの経過時間です)。
有効なGC処理
このオプション指定により出力形式が拡張されるのは、使用するGC処理が以下の場合です。
・ シリアルGC(JDK/JRE 5.0、6)
・ FJGC（JDK/JRE 5.0）
・ パラレルGC (JDK/JRE 5.0、6)
・ CMS付きパラレルGC (JDK/JRE 5.0、6)
ログ出力量の増加
本オプションの指定により、ログ出力が増大します。
本オプションを指定する場合は、ログ出力量についての注意が必要です。
- 202 -
■ ログの見方
図6から図8に、GC処理の結果ログとして出力される情報の拡張形式の出力例を示します。
図6 GC処理の結果ログとして出力される情報の拡張形式の出力例
1.495: [Full GC*, [SplitEden : 384K->0K(704K)], [Tenured : 47835K->32752K(47872K)] 48219K->32752K(48576K), [Perm :
4081K->4081K(16384K)], 0.6623532 secs]
この出力情報から、以下のことが分かります。
・ Java VMが起動されてから1.495秒後にFullGC処理が実行された。
・ 使用されているGC処理はFJGCである。
・ GC処理後のNew世代領域の大きさは704KBである。
・ GC処理により、New世代領域に存在するオブジェクト量は384KBから0KBになった。
（不要オブジェクトが削除され、また必要に応じてOld世代領域へ生存オブジェクトが移動した）
・ GC処理後のOld世代領域の大きさは47872KBである。
・ GC処理により、Old世代領域に存在するオブジェクト量は47835KBから32752KBになった。
（不要オブジェクトが削除され、また必要に応じてNew世代領域から生存オブジェクトが移動してきた）
・ GC処理後のメモリ割り当てプールの大きさは48576KBである。
・ GC処理により、メモリ割り当てプールに存在するオブジェクト総量は48219KBから32752KBになった。
（不要オブジェクトが削除された）
・ GC処理後のPermanent世代領域の大きさは16384KBである。
・ GC処理により、Permanent世代領域に存在するオブジェクト量は変化していない。
・ GC処理に要した時間は0.6623532秒である。
図7 GC処理の結果ログとして出力される情報の拡張形式の出力例(CMS付きパラレルGCの場合-1)
150.207: CMS start
150.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)
- 203 -
137.803: CMS start
137.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-req
142.501: CMS stop(11), 4.6984060 secs
142.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が解釈／実行できる命令
「バイトコード」へ変換し、事前にプラットフォーム非依存の実行バイナリである「クラスファイル」を作成する必要があります。
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メソッドを決定しています。プロファイリング処理によりある程度の情
- 204 -
報量が得られるまで、すなわちJava VM起動直後はインタプリタ実行だけですが、次第にインタプリタ実行と動的コンパイル結果による
機械命令実行との混合動作になります。
FJVMでは、動的コンパイルに関する以下の機能を富士通版独自機能として実装しています。
なお、いずれの機能もFJVM固有機能です。
・ コンパイラ異常発生時の自動リカバリ機能
・ 長時間コンパイル処理の検出機能
・ 動的コンパイル発生状況のログ出力機能
8.3.1 コンパイラ異常発生時の自動リカバリ機能
Java VMはJavaアプリケーションとして実行されるJavaメソッドに対して必要に応じて自動的にコンパイル処理を行いますが、コンパイ
ル処理を行っている際にコンパイラ内で何らかの異常が発生すると、当該Javaメソッドに対するコンパイル処理だけでなくJava VMとし
ての動作も異常状態として停止させてしまう場合があります。
FJVMでは、コンパイラ内で何らかの異常が発生した場合に自動的にリカバリ処理を行い、Java VMとしての動作を継続させる機能
を「コンパイラ異常発生時の自動リカバリ機能」として実装しています。
コンパイラ異常発生時の自動リカバリ機能はFJVM固有機能です。
なお、本機能によるリカバリ処理が行なわれた際にコンパイル対象となっていたJavaメソッドは、以降、コンパイル処理の対象とはなり
ません。当該Javaメソッドについてはコンパイルされず、インタプリタモードのままJavaアプリケーションとしての実行が継続されます。
また、本機能はFJVMの内部処理として動作する機能であるため、コンパイラ内で何らかの異常が発生してもリカバリ処理が正常に
行われた場合には、外部に対する通知などは何も行いません。リカバリ処理が正常に行われた場合でもコンパイラ内で何らかの異常
が発生したことを情報として受け取る場合には、図1のオプションを指定してください。
図1のオプションを指定した場合、リカバリ処理の情報が図2の形式で標準出力に出力されます。
図1 リカバリ処理実施後に通知を受け取るオプション
-XX:+PrintCompilerRecoveryMessage
図2 リカバリ処理実施後に通知される情報
【JDK/JRE 5.0または6場合】
CompilerRecovery: Information:The compilation was canceled for method method_name
Reason for the cancellation: reason [code:c, addr:xxxxxxxx]
method_name:
コンパイル処理で異常が発生した際にコンパイル対象となっていたJavaメソッドの
名前。
reason:
コンパイル処理で発生した異常の原因情報。原因情報として以下の項目がありま
す。
・ assert:
コンパイル処理で内部処理矛盾を検出した
・ error:
コンパイル処理で何らかの誤りを検出した
・ stack overflow:
コンパイル処理でスタックオーバーフローを検出した
c:
異常コード。
- 205 -
xxxxxxxx:
コンパイル処理で異常が発生した際のアドレス。
8.3.2 長時間コンパイル処理の検出機能
Java VMはJavaアプリケーションとして実行されるJavaメソッドに対して必要に応じて自動的にコンパイル処理を行い、通常は極短時
間でその処理を完了します。
しかし、コンパイル処理自身や同じJavaプロセス内で動作させている他の処理の障害などによりCPU資源が占有され続けてしまうと、
数分を経過してもコンパイル処理が終了しない場合が考えられます。このような状態が継続すると、システム全体に対して悪影響を与
える可能性が考えられます。
このため、FJVMでは、各Javaメソッドのコンパイル処理に要している時間を監視し、コンパイル処理で必要と考えられる程度の時間
を経過してもコンパイル処理が終了していない場合には、Javaプロセス内の処理で何らかの問題が発生していると判断し、当該Javaプ
ロセスを強制的に終了させる機能を「長時間コンパイル処理の検出機能」として実装しています。
コンパイラ異常発生時の自動リカバリ機能はFJVM固有機能です。
本機能は、図1のオプションでコンパイル処理に対する監視時間(コンパイル処理に要する時間の上限値)を指定した場合に有効とな
ります。ただし、オプション値として「0」を指定した場合には、本機能は有効となりません。
図1のオプションで指定された時間を超過してもコンパイル処理が終了していない場合、本機能はJavaプロセス内の処理で何からの
問題が発生していると判断し、当該Javaプロセスを強制的に終了させます。
図1 長時間コンパイル処理の検出機能を有効にするオプション
-XX:CompileTimeout=<nn>
<nn>には、本機能による異常有無の判断条件とされるコンパイル処理に要する時間の上限値(単位:秒)を指定します。デフォルト値
は「0」であり、本機能は無効となっています。
なお、本機能による時間監視の最小単位は30秒であるため、その単位での時間誤差があります。
なお、本機能によってJavaプロセスを強制終了する場合、FJVMは図2のメッセージを標準出力に出力してから終了します。また、本
機能によるJavaプロセスの強制終了時にはコアダンプも出力されます。
図2 長時間コンパイル処理の検出機能によるJavaプロセス強制終了時の出力メッセージ
CompilerRecovery: Information: CompilerRecovery got the VM aborted
because 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資源が占有されていないか。
- 206 -
・ “-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 from compiling
method method_name.
nnnnnnnn: コンパイラスレッドの内部識別子
method_name: 本機能によるチェックで検出された際にコンパイル対象となっていたJavaメソッドの名前
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使用状況を出力するオプション
- 207 -
-XX:+PrintCompilationCPUTime
図2 コンパイラスレッドのCPU使用状況および動的コンパイル結果情報を出力するオプション
-XX:+FJPrintCompilation
図3 コンパイラスレッドのCPU使用状況の出力形式
$1: [$2: cpu=$3ms elapsed=$4ms $5]
図3の各要素について、以下で説明します。
$1: ログ出力時の時間
ログ出力時の時間を示します。
ログ出力時の時間のフォーマットは、ログ出力における「8.5.7 ログ出力における時間情報のフォーマット指定機能」により指定できます。
デフォルトは、「Java VMが起動されてからの経過時間(秒)」です。
$2: コンパイラスレッド名
情報の出力対象となるコンパイラスレッドの名前を「CompilerThread数字」の形式で示します。
$3: CPU時間
$2のコンパイラスレッドが、20個のJavaメソッドのコンパイルを行うのに使用したCPU時間(ミリ秒)を示します。
$4: 経過時間
$2のコンパイラスレッドが、20個のJavaメソッドのコンパイルを行うまでに経過した時間(ミリ秒)を示します。
$5: 通し番号
コンパイラスレッドごとの本情報の出力数を、通し番号で示します。
通し番号×20」の値が、そのコンパイラスレッドでコンパイルしたJavaメソッドの累計数になります。
図4 動的コンパイル結果情報の出力形式
$1: $2 $3 ($4 bytes)
図4の各要素について、以下で説明します。
$1: Javaメソッドのコンパイル要求発生時間(ログ出力時の時間)
Javaメソッドのコンパイル要求が発生した時間(ログ出力時の時間)を示します。
ログ出力時の時間のフォーマットは、ログ出力における「8.5.7 ログ出力における時間情報のフォーマット指定機能」により指定できます。
デフォルトは、「Java VMが起動されてからの経過時間(秒)」です。
$2: 通し番号
コンパイル要求の数(コンパイル要求が発生したJavaメソッドの数)を通し番号で示します。
通し番号の後ろに「%」がない場合は、コンパイル対象のJavaメソッド全体をコンパイルする要求です。
通し番号の後ろに「%」がある場合は、コンパイル対象のJavaメソッドを部分的にコンパイルする要求です。
通し番号の後ろに「%」がない場合とある場合は、別の通し番号になります。
$3: Javaメソッド名
コンパイル要求が発生したJavaメソッドの名前を示します。
Javaメソッドを部分的にコンパイルする要求の場合($2に「%」の表示が含まれる場合)、Javaメソッド名の後に、Javaメソッド(バイトコード)
のどの部分からコンパイルの対象になっているかを示す情報「(@ 数字)」が付加されます。
$4: Javaメソッドのバイト数
コンパイル対象となったJavaメソッドの大きさ(バイトコード・サイズ)をバイト数で示します。
図5 -XX:+PrintCompilationCPUTime指定時の出力例
- 208 -
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指定時の出力例
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ヒープに関するオプション
オプション
-Xms
オプションの機能
メモリ割り当てプールの初期値を指定します。
たとえば、メモリ割り当てプールの初期値を128MBに設定する場
合、”-Xms128m”と指定します。
- 209 -
オプション
オプションの機能
本オプションのデフォルト値は“表8.5 メモリ割り当てプールのデフォ
ルトのサイズ”のとおりです。
なお、指定値が1MB未満の場合、または-XX:NewSizeオプションの
値(デフォルト値を含む)よりも小さな値の場合、初期化エラーとなり、
Javaプロセスは終了します。
-Xmx
メモリ割り当てプールの最大値を指定します。
たとえば、メモリ割り当てプールの最大値を256MBに設定する場
合、”-Xmx256m”と指定します。
(実際に使用される値は、ページサイズなどのシステム情報を元に、
Java VMによる制御が最適となるように調整された値「調整値」となる
ため、指定された値と若干異なる場合があります。)
本オプションのデフォルト値は“表8.5 メモリ割り当てプールのデフォ
ルトのサイズ”のとおりです。
なお、指定値(または調整値)が、-Xmsオプションで指定された値よ
りも小さな値の場合、初期化エラーとなり、Javaプロセスは終了しま
す。
-XX:NewSize (注1)
New世代領域のヒープサイズを指定します。
たとえば、New世代領域のヒープサイズを128MBに設定する場合、”XX:NewSize=128m”と指定します。
本オプションの指定が有効な場合のデフォルト値は以下のとおりで
す。
・ type0またはtype0pのCMS付きパラレルGCを使用している場合
は、メモリ割り当てプールの初期値の1/8です。
・ type1またはtype1pのCMS付きパラレルGCを使用している場合
は、メモリ割り当てプールの初期値の1/3です。
・ type2またはtype2pのCMS付きパラレルGCを使用している場合
は、メモリ割り当てプールの初期値の1/16です。
・ 上記以外の場合のデフォルト値は“表8.7 Javaヒープに関するオ
プション(-XX:NewSize/-XX:NewRatio)のデフォルト値”のとおり
です。
なお、指定値がJava VMとしての下限値未満の場合、初期化エラー
となり、Javaプロセスは終了します。そのため、本オプションを指定す
る場合は、1MB以上の値を指定してください。
-XX:MaxNewSize (注1)
New世代領域の最大ヒープサイズを設定します。
たとえば、New世代領域の最大ヒープサイズを128MBに設定する場
合、”-XX:MaxNewSize=128m”と指定します。
本オプションの指定が有効な場合のデフォルト値は以下のとおりで
す。
・ type0またはtype0pのCMS付きパラレルGCを使用している場合
は、メモリ割り当てプールの最大値の1/8です。
・ type1またはtype1pのCMS付きパラレルGCを使用している場合
は、メモリ割り当てプールの最大値の1/3です。
・ type2またはtype2pのCMS付きパラレルGCを使用している場合
は、メモリ割り当てプールの最大値の1/16です。
・ 上記以外の場合、デフォルト値はありません(本オプションの値
を用いてNew世代領域の最大ヒープサイズは決定されません)。
なお、指定値が、-XX:NewSizeオプションで指定された値よりも小さ
な値の場合は、-XX:NewSizeオプションで指定された値となります。
- 210 -
オプション
オプションの機能
-XX:NewRatio (注1)(注4)
New世代領域とOld世代領域のサイズ比率を指定します。
たとえば、New世代領域とOld世代領域のサイズ比率を2とする場
合、”-XX:NewRatio=2”と指定します。
本オプションの指定が有効な場合のデフォルト値は“表8.7 Javaヒー
プに関するオプション(-XX:NewSize/-XX:NewRatio)のデフォルト
値”のとおりです。
-XX:SurvivorRatio (注1)(注2)
(注5)
New世代領域を構成するEden領域とSurvivor領域のサイズ比率を
指定します。
たとえば、Eden領域とSurvivor領域のサイズ比率を8とする場合、”XX:SurvivorRatio=8”と指定します。
本オプションの指定が有効な場合のデフォルト値は以下のとおりで
す。
・ Solaris版JDK/JRE 5.0でシリアルGCを使用している場合のデフォ
ルト値は32です。
・ 上記以外の場合のデフォルト値は8です。
-XX:TargetSurvivorRatio (注1)
(注2)(注5)
ガーベジコレクション(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) FJGCを使用する場合、このオプションへの指定値は無効となります。
なお、New世代領域サイズ自動調整機能が停止状態の場合は、-XX:NewSize、-XX:MaxNewSize、-XX:NewRatioの各オプション
への指定値は有効となります。
注2) パラレルGCを使用する場合、このオプションへの指定値は無効となります。
注3) サイズを指定するオプションでは単位として次の文字を指定できます。
KB（キロバイト）を指定する場合:”k”または”K”
MB（メガバイト）を指定する場合:”m”または”M”
注4) CMS付きパラレルGCを使用する場合、このオプションへの指定値は無効となります。
注5) CMS付きパラレルGCを使用する場合、かつ-XX:UseFJcmsGC=type0またはtype0p指定でない場合、このオプションへの指定値
は無効となります。
- 211 -
表8.5 メモリ割り当てプールのデフォルトのサイズ
JDK/JREの
バージョン
JDK/JRE 5.0
OS
Windows
JDK/JREの実行
モード
32ビットモード
Linux for x86
Linux for Intel64
Solaris
32ビットモード
Windows
Server(R) x64
Editions
64ビットモード
Linux for Intel64
JDK/JRE 6
Windows
32ビットモード
Linux for x86
Linux for Intel64
Solaris
32ビットモード
Windows
Server(R) x64
Editions
64ビットモード
Linux for Intel64
GC処理
初期値
シリアルGC
FJCG
2.0MB
パラレルGC
(注1)
5.375MB
CMS付きパ
ラレルGC
(注2)
シリアルGC
FJCG
3.5MB
パラレルGC
(注1)
5.375MB
CMS付きパ
ラレルGC
(注2)
シリアルGC
4.3125MB
パラレルGC
(注1)
5.75MB
CMS付きパ
ラレルGC
(注2)
シリアルGC
5.0MB
パラレルGC
(注1)
8.0MB
CMS付きパ
ラレルGC
(注2)
シリアルGC
6.125MB
パラレルGC
(注1)
8.0MB
CMS付きパ
ラレルGC
(注2)
シリアルGC
7.75MB
パラレルGC
(注1)
9.1875MB
CMS付きパ
ラレルGC
(注2)
最大値
64MB
84MB
64MB
84MB
注1) デフォルトで使用されるGC処理です。
注2) メモリ割り当てプールの最大値が64MB未満の場合は、メモリ割り当てプールの最大値と等しくなります。メモリ割り当てプールの
最大値が64MB以上の場合は、64MBとなります。
表8.6 Permanent世代領域のデフォルトのサイズ
JDK/JREの
バージョン
JDK/JRE 5.0
OS
Windows
Linux for x86
Linux for
Intel64
JDK/JREの実行
モード
32ビットモード
Java VM
初期値
Java
HotSpot
Client VM
8MB
FJVM (注1)
16MB
- 212 -
最大値
64MB
JDK/JREの
バージョン
Java VM
初期値
64ビットモード
FJVM (注1)
20.75MB
84MB
32ビットモード
Java
HotSpot
Client VM
12MB
64MB
FJVM (注1)
16MB
FJVM (注1)
20.75MB
JDK/JREの実行
モード
OS
最大値
Solaris
Windows
Server(R) x64
Editions
Linux for
Intel64
JDK/JRE 6
Windows
Solaris
Linux for x86
Linux for
Intel64
Windows
Server(R) x64
Editions
64ビットモード
84MB
Linux for
Intel64
注1) デフォルトで使用されるJava VMです。
表8.7 Javaヒープに関するオプション(-XX:NewSize/-XX:NewRatio)のデフォルト値
JDK/JREの
バージョン
JDK/JRE 5.0
OS
Windows
JDK/JREの実行モード
32ビットモード
Java VM
Java HotSpot Client VM
-XX:NewSize
-XX:NewRatio
640KB
12
FJVM (注1)
Linux for x86
8
Linux for Intel64
Solaris
32ビットモード
Java HotSpot Client VM
2176KB
FJVM (注1)
Windows Server(R) x64
Editions
8
2
64ビットモード
FJVM (注1)
2624KB
2
32ビットモード
Java HotSpot Client VM
1024KB
12
Linux for Intel64
JDK/JRE 6
Windows
FJVM (注1)
Linux for x86
8
Linux for Intel64
Solaris
32ビットモード
Java HotSpot Client VM
2176KB
FJVM (注1)
Windows Server(R) x64
Editions
64ビットモード
Linux for Intel64
注1) デフォルトで使用されるJava VMです。
■チューニングの方針
Javaヒープをチューニングする際、次の方針があります。
- 213 -
FJVM (注1)
8
2
2624KB
2
1. FullGCを実行したにもかかわらず、メモリ不足が発生する場合、GCのログを採取し、メモリ割り当てプールまたはPermanent世
代領域のいずれかの領域が不足しているかどうかを確認します。
2. FullGCはコストがかかります。このため、メモリ不足が発生しなくても、Javaアプリケーションがハングアップしたかのように一時的
に無反応になる場合、FullGCの影響を受けている場合があります。GCのログを採取し、Javaヒープが必要以上に大きなサイズ
になっていれば、Javaヒープのサイズを縮小する方針でチューニングします。
3. 効率的なNew GCに対して、FullGCはコストがかかります。このため、New世代領域とOld世代領域のサイズのバランスを考慮
する必要があります。なお、GC処理としてパラレルGCまたはFJGCを使用する場合は、JavaヒープのNew世代領域およびOld世
代領域の大きさに関する値が自動的に調整および最適化されるため、通常はこのバランスを考慮する必要はありません。
4. 仮想メモリに余裕がある場合は、Javaプロセスを複数起動して、プロセス多重度を上げる方法を検討します。プロセス多重度を
上げることにより、プロセスごとのユーザ空間を有効に使うことが可能になります。ただし、メモリのスワッピングによるスローダウン
に注意する必要があります。
■チューニングの影響範囲
メモリ割り当てプールの大きさ(-Xmxオプションの指定値)や、New世代領域とOld世代領域の大きさのバランスを変更した場合の影
響範囲を、次に示します。
・ メモリ割り当てプールの大きさを縮小した場合、GCが頻発することがあります。
・ メモリ割り当てプールの大きさを拡張した場合、FullGCに時間がかかることがあります。
・ メモリ割り当てプールの大きさを拡張した場合、その分ユーザ空間や仮想メモリが少なくなるため、スタックやネイティブモジュール
の動作に必要な領域を確保できず、メモリ不足になることがあります。
・ New世代領域の大きさがメモリ割り当てプールの大きさの半分となるようなチューニングを行った場合、一般的に、FullGCが発生
しやすくなる傾向があります。なお、Javaアプリケーション実行時のオブジェクト生成／解放などの特性に依存しますので、どのア
プリケーションの場合でもFullGCが発生しやすいというわけではありません。
overcommit memory機能が有効な場合の注意事項
「overcommit memory機能」が有効な場合、Linuxは、Javaヒープの各領域の最大値に相当する仮想メモリ資源を、Java VMの起動時
に、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”と指定
します。
なお、mainメソッドが実行されるスレッドはJava VMの起動前に作成されたスレッドである(Java APIで作成されたスレッドではない)た
め、“-Xss”オプションによるスタックサイズの指定は効果がありません。
- 214 -
またJDK/JRE内で実行されるJavaメソッドを自動的にコンパイルする専用スレッド(コンパイラスレッド)のスタックサイズは、“XX:CompilerThreadStackSize”オプションで指定することができます。
通常、コンパイラスレッドのスタックサイズを指定する必要はありません。
“-XX:CompilerThreadStackSize”オプションは、キロバイト(Kバイト)単位でコンパイラスレッドのスタックサイズ指定します。例えば、ス
タックサイズを1024KBに設定する場合、”-XX:CompilerThreadStackSize=1024”と指定します。
Java APIで生成したスレッドおよびコンパイラスレッドのデフォルトのスタックサイズを、“表8.8 Java APIで生成したスレッドおよびコン
パイラスレッドのデフォルトのスタックサイズ”に示します。
表8.8 Java APIで生成したスレッドおよびコンパイラスレッドのデフォルトのスタックサイズ
JDK/JREの実行
モード
Java APIで生成した コンパイラスレッ コンパイラスレッド
(FJVM)
ド (Client VM)(注
スレッド(注1)
1)
Windows
32ビットモード
256KB
256KB
2048KB
Linux for x86
32ビットモード
512KB
512KB
2048KB
64ビットモード
1024KB
Windows
32ビットモード
320KB
320KB
2048KB
Linux for x86
32ビットモード
320KB
512KB
2048KB
Solaris
32ビットモード
512KB
512KB
2048KB
Windows Server(R) x64 Editions
64ビットモード
1024KB
JDK/JRE
のバージョ
ン
JDK/JRE
5.0
OS
Linux for Intel64
Solaris
Windows Server(R) x64 Editions
－(注2)
4096KB
Linux for Intel64
JDK/JRE
6
Linux for Intel64
－(注2)
4096KB
Linux for Intel64
注1) Windows版JDK/JREにおけるスタックサイズは、java.exeなどWindows版JDK/JREが提供するJDKツールを用いた場合の値です。
JNIを用いて独自にJava VMを起動しているWindowsアプリケーションの場合は、Java VMを起動したプログラムのメインスレッドに対す
るスタックサイズと同じ値になります。
注2) 実行モードが64ビットモードのJDK/JREでは、Java HotSpot Client VMは搭載していません。
注3) スタック領域の実際の管理はOSが行います。そのためスタック領域に関する管理方法/動作仕様については、JDK/JREを実行す
る各OSの仕様に依存します。
■チューニングの影響範囲
スタックのサイズを変更した場合の影響範囲を、次に示します。
・ スタックのサイズを縮小した場合、スタックオーバーフローが発生することがあります。
・ スタックのサイズを拡張した場合、その分ユーザ空間や仮想メモリが少なくなるため、Javaヒープやネイティブモジュールの動作に
必要な領域を確保できず、メモリ不足になることがあります。
8.4.3 暖機運転
本項では、Javaアプリケーション実行において、動的コンパイルから受ける影響の確認方法、およびその対応方法である暖機運転に
ついて説明します。
■チューニング方法
“8.3 動的コンパイル”で説明したように、Javaアプリケーションの実行は、Java VM起動直後はインタプリタ実行だけで行われ、次第に
インタプリタ実行と動的コンパイル結果による機械命令実行との混合動作になります。また動的コンパイルにより翻訳された機械命令
の内容も、Javaアプリケーションの実行が進むにつれて、次第にJavaアプリケーションの実行状況に合った翻訳結果に最適化されま
- 215 -
す。つまりJavaアプリケーションの実行には、以下の動的コンパイルによるオーバーヘッドや最適化状態の推移があるため、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)の状況になります。
なお、動的コンパイル結果情報(-XX:+FJPrintCompilationオプション指定時の出力結果)から、(b)の始まりを調べるには、システムログ
などから(a)の完了時刻を調べ、その時刻以降に発生した動的コンパイルを対象に調査を行います。
- 216 -
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)
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)
- 217 -
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の出力を格納するファイルなど）に出力されま
す。
■スタックトレースの出力方法
Javaでスローされた例外をcatch節でキャッチし、例外のprintStackTraceメソッドを実行することにより、スタックトレースを出力することが
できます。
java.lang.Throwable.printStackTrace()でスタックトレースを出力する方法を、図1に示します。
図1 printStackTraceメソッドでスタックトレースを出力する方法
try {
SampleBMPSessionRemote bmpSessionRemote = bmpSessionHome.create();
} catch(Exception e) {
- 218 -
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)
6: at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
:
■読み方
図1のスタックトレースは、6行目から上方向に読むと、次の流れで例外が発生したことがわかります。
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()を実行し、
が
agency.attestation.AttestationServlet.doGet()を実行し、
AttestationServlet.java
の
161
行
目
で、
が
、
AttestationServlet.java
agency.attestation.CheckLoginInfo.doCheck()を実行した結果、
の
96
行
目
で、
3. agency.attestation.AttestationServlet.doPost()
、
4. agency.attestation.AttestationServlet.doGet()
5. agency.attestation.CheckLoginInfo.doCheck()内のCheckLoginInfo.javaの150行目で、java.lang.NullPointerExceptionという例外
が発生した
- 219 -
■解析方法
図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)
7: at javax.servlet.http.HttpServlet.service(HttpServlet.java:696)
8: at javax.servlet.http.HttpServlet.service(HttpServlet.java:809)
:
:
■解析方法
図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()に渡しているリソースファイ
ル名に誤りがないかどうかを確認します。
b. リソースファイルが、所定のディレクトリ構成内に存在するか
a)のリソースファイル名が正しい場合、所定のディレクトリ構成(/sample/)に、次のいずれかのリソースファイルがあるかどう
かを確認します。
- SampleResource_ja_JP.properties
- SampleResource_ja_JP.class
- SampleResource_ja.properties
- SampleResource_ja.class
- SampleResource.properties
- SampleResource.class
- 220 -
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) {
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)
- 221 -
at Test.parentMethod(Test.java:17)
... 2 more
HiLevelExceptionに続いて、“Caused by:”以降に、原因となるLowLevelExceptionのスタックトレースが出力されています。最終行の
“... 2 more”は、“Caused by:”の直前の2行が続きのスタックトレースであることを示しています。
つまり、図3のように解釈することができます。
図3 原因となる例外の解釈
Caused
at
at
at
at
by: LowLevelException: LowLevel
Test.childMethod(Test.java:24)
Test.parentMethod(Test.java:17)
Test.<init>(Test.java:9)
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 5.0、6のFJVMの場合
・ java.lang.NullPointerException
・ java.lang.ArithmeticException
・ java.lang.ArrayIndexOutOfBoundsException
・ java.lang.ArrayStoreException
・ java.lang.ClassCastException
動 的 コ ン パ イ ル 処 理 に よ り 例 外 発 生 時 の ス タ ッ ク ト レ ー ス 出 力 処 理 が 省 略 さ れ な い よ う に す る 場 合 は 、 “ -XX:OmitStackTraceInFastThrow”オプションを指定します。
ただし該当する例外の発生頻度が高い場合に当該オプションを指定し、例外発生時のスタックトレース出力を行なった場合は、Java
アプリケーションの実行性能が低下する場合があります。
当該オプションを指定する場合は、性能検証を行った上で使用するか、開発作業において例外が発生している場所を特定したい場
合においてだけ使用してください。
“-XX:-OmitStackTraceInFastThrow”オプションはFJVM固有機能です。
8.5.3 スレッドダンプ
スレッドダンプには、Javaプロセスの各スレッドの情報(スタックトレース形式)が含まれているため、ハングアップやデッドロックなどの動
作具合を調査することができます。
スレッドダンプの出力先は、標準出力です。スレッドダンプが出力される契機および出力先を、“表8.9 スレッドダンプの出力契機と出
力先”に示します。
- 222 -
表8.9 スレッドダンプの出力契機と出力先
プログラムの種類
出力契機
出力先
J2EEアプリケーション
一定の条件を満たした場合、コンテナの機能により自動
的に採取される場合と利用者の任意のタイミングで手動
による採取があります。
標準出力、
JavaVMの出力を
ロギングしている
ファイル
自動採取：
アプリケーションがタイムアウトまたは無応答になった場合
手動採取：
“スレッドダンプツール”で採取することができます。スレッ
ドダンプツールの詳細は、“トラブルシューティング集”の
“スレッドダンプツール”を参照してください。
kill -QUIT [プロセスID]でJava VMに対してQUITシグナ
ルを送り採取することができます。
J2EE以外のJavaプロ
グラム
利用者の任意のタイミングで手動で採取することができま
す。
コマンドプロンプトからJavaプログラムを起動した場合：
以下、いずれかの方法で採取できます。
１）[Ctrl]+[Break]キー押下
２）“スレッドダンプツール”
コマンドプロンプト以外からJavaプログラムを起動した場
合：
“スレッドダンプツール”で採取します。
スレッドダンプツールの詳細は、“トラブルシューティング
集”の“スレッドダンプツール”を参照してください。
ターミナルからJavaプログラムを起動した場合：
以下、いずれかの方法で採取できます。
１）[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プ
- 223 -
コンソール(標準出
力)
プログラムの種類
出力契機
出力先
ロセスの場合は、“-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:
}
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()終了");
- 224 -
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]
at Thread2.method(DeadlockSample.java:51)
- waiting to lock <0x10030ca0> (a Thread2)
at Thread1.run(DeadlockSample.java:25)
- 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)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x0096da70 nid=0x5e4 in Object.wait() [1812f000..1812fd64]
at java.lang.Object.wait(Native Method)
- 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:
- 225 -
===================================================
"Thread2":
at Thread1.method(DeadlockSample.java:31)
- waiting to lock <0x1002ffe8> (a Thread1)
at Thread2.run(DeadlockSample.java:45)
- locked <0x10030ca0> (a Thread2)
"Thread1":
at Thread2.method(DeadlockSample.java:51)
- waiting to lock <0x10030ca0> (a Thread2)
at Thread1.run(DeadlockSample.java:25)
- locked <0x1002ffe8> (a Thread1)
Found 1 deadlock.
■解析方法
スレッドダンプの各スレッドの情報は、スタックトレース形式です。
Thread1とThread2の両方のスタックトレースには、“locked”と“waiting to lock”があります。また、スレッドダンプの下の方にも、“deadlock”
の文字列があり、デットロックが発生していることが確認できます。
このように、スレッドダンプで全スレッドの動作状況を確認するにより、Javaプロセスがハングアップしているか、あるいは、デッドロック
状態かを確認することができます。特に、短い間隔で複数のスレッドダンプを採取し、スレッドに動きがなければ、ハングアップの可能
性があります。
スレッドダンプの詳細は、“トラブルシューティング集”も参照してください。
オブジェクトをロックしているスレッドがスレッドダンプ上に出ない
通常スレッドダンプ上のあるスレッドで次のように表示される場合があります。
- waiting to lock <オブジェクトID> (a クラス名)
このような場合、別のスレッドがそのオブジェクトIDのロックを持っていて、そのスレッドのトレース上のどこかで次の表示がされていま
す。
- locked <オブジェクトID> (a クラス名)
しかし、スレッドダンプを表示するタイミングによっては“- locked <オブジェクトID> (a クラス名)”の表示がどのスレッドにも現われず、“waiting to lock <オブジェクトID> (a クラス名)”だけ表示される場合があります。
以下のプログラムを例とします。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class NoLockOwner extends Thread
{
static Object lock = new Object();
public static void main(String[] arg)
{
new NoLockOwner().start();
new NoLockOwner().start();
}
public void run()
{
while (true) {
synchronized (lock) {
dumb();
}
}
}
void dumb()
{
- 226 -
22
23
24
25
26
27
int n = 0;
for (int i = 0 ; i < 1000 ; ++i)
n += i;
}
}
(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)
at NoLockOwner.run(NoLockOwner.java:15)
- locked <0x800> (a java.lang.Object)
(1)先頭フレームでオブジェクトをロックしている場合は“- locked”ではなく、“- waiting to lock”と表示されることがあります。
"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.run(NoLockOwner.java:14)
- waiting to lock <0x800> (a java.lang.Object)
この場合、スレッドの状態を見て、runnableであれば、ロック待ちではなく、ロック取得後同じフレームを実行中の状態であると考えま
す。
Thread-0、Thread-1ともに、“- waiting to lock <0x800> (a java.lang.Object)”と表示されているので、どちらもロック待ちのように見えま
す。
しかし、Thread-0の状態は、runnbleなので、ロック待ち状態ではありません。
(2) “- waiting to lock”と表示されるのは、ロック待ちの状態だけではなく、ロック獲得処理の最中でもそのように表示されます。
"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 waiting for monitor entry [0x5000..0x6000]
at NoLockOwner.run(NoLockOwner.java:14)
- waiting to lock <0x800> (a java.lang.Object)
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) ロックを開放した直後の状態
"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.run(NoLockOwner.java:16)
Thraed-0がちょうどロックを開放した直後の状態です。
この状態も長く続くとはなく、短時間で(0)または(1)に移行します。
スレッドダンプからアプリケーションの状態を判断する場合、ひとつのスレッドダンプから状態を判断することは困難です。
- 227 -
適切な判断をするためには、複数回のスレッドダンプを総合的に見ることが必要です。
スレッドダンプ中に表示されるsynchronizedメソッドの行番号について
次のようなプログラムを考えます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class SyncMethod extends Thread
{
static volatile int k;
public static void main(String[] arg)
{
new SyncMethod().start();
}
public void run()
{
while (true) {
dumb();
}
}
synchronized void dumb()
{
/*
meaningless comments
*/
int i = 0;
for ( ; i < 10 ; ++i)
k += i;
}
}
このようなプログラムのスレッドダンプを取ると以下のように出力されることがあります。
"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
2
3
4
5
6
7
8
9
10
11
12
13
class NoNotify extends Thread
{
static Object o = new Object();
public static void main(String[] arg)
{
new NoNotify().start();
new NoNotify().start();
}
public void run()
{
try {
- 228 -
14
15
16
17
18
19
20
synchronized (o) {
o.wait();
}
} catch (Exception e) {}
}
}
このプログラムには誤りがあります。
このプログラムでは誰もnotifyするスレッドがないため、どちらのスレッドも永久に起こされることはありません。
このプログラムのスレッドダンプを採取すると次のように示される場所があります。
"Thread-1" prio=1 tid=0x800 nid=0x6 in Object.wait() [1000..2000]
at java.lang.Object.wait(Native Method)
- waiting on <0x200> (a java.lang.Object)
at java.lang.Object.wait(Object.java:429)
at NoNotify.run(NoNotify.java:15)
- locked <0x200> (a java.lang.Object)
"Thread-0" prio=1 tid=0x900 nid=0x7 in Object.wait() [3000..4000]
at java.lang.Object.wait(Native Method)
- waiting on <0x200> (a java.lang.Object)
at java.lang.Object.wait(Object.java:429)
at NoNotify.run(NoNotify.java:15)
- locked <0x200> (a java.lang.Object)
このスレッドダンプから分かることは、複数のスレッドがロックを獲得しているのではなく、どのスレッドもロックを獲得していないということ
です。
Thread-0、Thraed-1ともに、同じオブジェクト“ID<0x200>”のオブジェクトをロックしているように見えます。
しかし“- locked”と表示されているスレッドが、現在のロックオーナであることは意味しません。（“- locked”の正確な意味するところは、
そのフレームにおいてロックしたということに過ぎません。）
先頭フレームでは、“- waiting on”と表示されています。
これは、ロックが解放されたら起こされる可能性のある“- waiting to lock”とは異なり、ロックが解放されても自動的に起こされることを意
味しません。
Javaヒープ領域に関する情報の出力
JDK/JRE 6の場合は、スレッドダンプの出力と合わせて、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世代領域」に関する情報です。
・ CMS付きパラレルGC使用時:
「par new generation」が「New世代領域」、「concurrent mark-sweep generation」が「Old世代領域」、「concurrent-mark-sweep perm
gen」が「Permanent世代領域」に関する情報です。
なお「Old世代領域」および「Permanent世代領域」における「object space」についての情報は出力されません。
出力例：
- 229 -
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
図2の各要素について、以下で説明します。
$1: 順位
クラスのインスタンス情報は、各クラスのインスタンスの合計サイズが大きい順に、ソートされて出力されます。
$2: クラスのインスタンス数
$3: クラスのインスタンスの合計サイズ
$4: クラス名
$5: $2の値の合計
$5: $3の値の合計
クラスのインスタンス情報出力機能では、不要なインスタンスを排除した後の情報を採取・出力します。そのため、事前処理としてFullGC
を実行します。クラスのインスタンス情報出力の過度の使用は、FullGCの多発となるので注意してください。
- 230 -
クラスのインスタンス情報出力に先立って行われるはずの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()実行時におけるスタックトレース出力機能による出力例
【JDK/JRE 5.0の場合】
"main" prio=5 tid=0x0002d0a8 nid=0x1 runnable [ffbee000..ffbeee7c]
at java.lang.Runtime.gc(Native Method)
at java.lang.System.gc(System.java:737)
at SystemGC.main(SystemGC.java:8)
"main" prio=5 tid=0x0002d0a8 nid=0x1 runnable [ffbee000..ffbeee7c]
at java.lang.Runtime.gc(Native Method)
at SystemGC.foo(SystemGC.java:4)
at SystemGC.main(SystemGC.java:10)
【JDK/JRE 6の場合】
"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]
java.lang.Thread.State: RUNNABLE
at java.lang.Runtime.gc(Native Method)
at SystemGC.foo(SystemGC.java:4)
at SystemGC.main(SystemGC.java:10)
- 231 -
図2の出力例の場合、SystemGC.mainからjava.lang.System.gc()が実行され、SystemGC.fooからjava.lang.Runtime.gc()が実行された
ことを確認することができます。
JDK/JRE 6からスタックトレース情報にスレッドの状態を表す情報（トレース情報の前の行）が表示されるようになりました。
図中の例では「java.lang.Thread.State: RUNNABLE」となっていますが、"RUNNABLE"の部分が、"NEW"、"TIMED_WAITING
(sleeping)"、"WAITING (on object monitor)"、"TIMED_WAITING (on object monitor)"、"WAITING (parking)"、"TIMED_WAITING
(parking)"、"BLOCKED (on object monitor)"、"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()が実行されたかどうかを確認可能にするための機能を、「Java VM終了時
における状態情報のメッセージ出力機能」として実装しています。
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終了時における状態情報のメッセージ出力機能による出力例
【JDK/JRE 5.0の場合】
Thread dump at JVM_Halt(status code=1234):
"main" prio=5 tid=0x00286240 nid=0x394 runnable [6f000..6fc10]
at java.lang.Shutdown.halt(Native Method)
at java.lang.Shutdown.exit(Shutdown.java:211)
- locked <0x16b66d48> (a java.lang.Class)
at java.lang.Runtime.exit(Runtime.java:90)
at java.lang.System.exit(System.java:715)
at JVM_Halt.main(JVM_Halt.java:5)
#### JavaVM terminated: Java HotSpot(TM) Server VM
- 232 -
(1.5.0_FUJITSU_MODIFIED-B** mixed mode), [pid=21388] TimeMillis=1169451586436
Time=Mon Jan 22 16:39:46 2007
【JDK/JRE 6の場合】
Thread dump at JVM_Halt(status code=1234):
"main" prio=3 tid=0x00030000 nid=0x2 runnable [0xfe5ff000..0xfe5ffd80]
java.lang.Thread.State: RUNNABLE
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
(11.3.02_FUJITSU_MODIFIED-B** mixed mode), [pid=29500] TimeMillis=1243580170483
Time=Fri May 29 15:56:10 2009
図2の出力例の場合、JVM_Halt.main()がSystem.exit()を実行し、その結果としてJavaプロセスが終了したことを確認することができま
す。
JDK/JRE 6からスタックトレース情報にスレッドの状態を表す情報（トレース情報の前の行）が表示されるようになりました。
図中の例では「java.lang.Thread.State: RUNNABLE」となっていますが、"RUNNABLE"の部分が、"NEW"、"TIMED_WAITING
(sleeping)"、"WAITING (on object monitor)"、"TIMED_WAITING (on object monitor)"、"WAITING (parking)"、"TIMED_WAITING
(parking)"、"BLOCKED (on object monitor)"、"TERMINATED"、"UNKNOWN"などの表示の場合があります。
この情報はJava VM終了時における状態の判定には使用しません。
8.5.7 ログ出力における時間情報のフォーマット指定機能
以下のオプションで出力されるログに含まれる「ログ出力時の時間」情報のフォーマットを、図1のオプションで指定することができま
す。
図1のオプションによる指定がない場合、ログ出力時の時間は「Java VMが起動されてからの経過時間(秒)」(「-XX:FJverboseTime=type1」
が指定された場合の形式)で出力されます。
・ ガーベジコレクションのログ出力
-verbosegc -XX:+UseFJverbose
・ 動的コンパイル発生状況のログ出力機能
-XX:+PrintCompilationCPUTime
-XX:+FJPrintCompilation
図1 ログ出力における時間情報のフォーマットを指定するオプション
-XX:FJverboseTime=タイプ
タイプとして以下の値が指定できます
type1
type2
type3
-XX:FJverboseTime=type1が指定された場合
ログ出力時の時間を、「Java VMが起動されてからの経過時間(秒)」で示します。
例) 0.165:
- 233 -
-XX:FJverboseTime=type2が指定された場合
ログ出力時の時間を、「日時(iso8601フォーマット)」で示します。
例) 2010-10-01T13:37:36.881+0900:
-XX:FJverboseTime=type3が指定された場合
ログ出力時の時間を、「日時(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ログを活用することができます。
■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:」から始まる情報です。
- 234 -
6. 発生時間
「Local Time =」から始まる情報です。
■調査手順
まず、図1の1～3の情報で異常終了した関数を特定し、実行しているJavaアプリケーションから呼び出す関数かどうかを確認します。
ただし、図1の2の異常終了した関数名として出力される名前は、異常終了したアドレスに一番近いシンボル名情報であるため、実際
に異常終了した関数とは別の名前が出力されている場合がありますので注意してください。
そして、実行しているJavaアプリケーションが使用する関数の場合には、当該関数使用に際して何らかの問題がないか確認します。
実行しているJavaアプリケーションで使用していない関数の場合には、図1の4のスタックトレースを調査します。
スタックトレース情報の最初のメソッドがネイティブメソッドだった場合（メソッド名の後ろに「(Native Method)」が付加されている場合）は
JNI処理に関係した問題である可能性が高いため、スタックトレース情報で出力された処理のJNI処理に関わる制御で何らかの問題が
ないか確認します。
また異常終了した関数を含むライブラリ名が利用者作成のライブラリである場合は、利用者側作成のライブラリ内の問題である可能
性が高いため、当該ライブラリ内の処理および当該ライブラリを呼び出す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の例外番号が出力されている場合には、スタックオーバーフローが原因と考えられます。
なお、ワトソン博士の説明は、“8.5.9.1 クラッシュダンプ”を参照してください。
図3 スタックオーバーフローを示す例外番号
c00000fd (スタックオーバーフロー)
8.5.8.2 異常終了時のシグナルハンドラ情報
Java VMの実行制御で必要となる“表8.10 Java VMの制御で必要となるシグナル”の各シグナルに対するシグナルハンドラ情報が確
認できます。
表8.10 Java VMの制御で必要となるシグナル
Solaris版Java VM
SIGSEGV
SIGPIPE
SIGBUS
Linux版Java VM
SIGSEGV
SIGPIPE
SIGBUS
- 235 -
Solaris版Java VM
Linux版Java VM
SIGILL
SIGFPE
INTERRUPT_SIGNAL (デフォルトはSIGUSR1)
ASYNC_SIGNAL (デフォルトはSIGUSR2)
SIGQUIT (注1)
SIGINT (注1)
SIGHUP (注1)
SIGTERM (注1)
SIGXFSZ (注3)
SIGILL
SIGFPE
INTERRUPT_SIGNAL (デフォルトはSIGUSR1)
(注2)
SR_SIGNUM (デフォルトはSIGUSR2)
SIGQUIT (注1)
SIGINT (注1)
SIGHUP (注1)
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以外の処理で登録されていた場合、Java VMは正常に
動作しません。この場合、当該シグナルハンドラを登録しないようにアプリケーションを修正してください。
8.5.8.3 異常終了時のJavaヒープに関する情報
異常終了時のJavaヒープの使用状況が確認できます。
Javaヒープのサイズによる異常終了の場合、異常終了時にどのJavaヒープの枯渇により異常終了が発生したのかが確認できます。
8.5.8.4 出力例と調査例
ここでは、Solaris版JDK/JRE 5.0での出力例を元に説明します。
-------------------------------------------------------------------------------#### Java VM: Java HotSpot(TM) Server VM (1.5.0_FUJITSU_MODIFIED-B**[*****] mixed mode)
>>>> Logging process start. [pid=27758] Time=Fri Jan 12 20:37:57 2007
(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/jdk5/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)
- 236 -
- 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)
at
com.appli.ap.formula.ejb.session.FJAFSF6801_AFSF6801RemoteImpl.doExecuteOrdinarily(FJAFSF6801_AFSF6801RemoteImpl.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_Tie.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/jdk5/bin/java
0xff370000 /usr/lib/libthread.so.1
0xff3fa000 /usr/lib/libdl.so.1
～～～～～～～
略
～～～～～～～
0xbef70000 /lib/libgen.so.1
0xbd6b0000 /lib/libextpiswu.so
0xbef50000 /opt/FJSVawjbk/jdk5/jre/lib/sparc/libioser12.so
Local Time = Fri Jan 12 20:37:57 2007
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
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_FUJITSU_MODIFIED-B** mixed mode)
～～～～～～～
略
～～～～～～～
(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)
SIGFPE :signal handler=0xfe1ec0a0 (in VM)
- 237 -
INTERRUPT_SIGNAL :signal handler=0xfe4ff010 (in VM +)
ASYNC_SIGNAL :signal handler=0xfe1ec0a0 (in VM)
(3)異常終了時のJavaヒープ領域に関する情報
異常終了時のJavaヒープ領域に関する情報が確認できます。
JDK/JRE 5.0、6の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」についての情報は出力さ
れません。
FJGC使用時(JDK/JRE 5.0の場合のみ):
「split eden generation」が「New世代領域」、
「tenured generation」が「Old世代領域」、
「compacting perm gen」が「Permanent世代領域」
に関する情報です。
シリアル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 15488K, used 14480K [0xf62b0000, 0xf76e0000, 0xf7800000]
eden space 15232K, 94% used [0xf62b0000,0xf70cc180,0xf7190000]
from space 256K, 12% used [0xf7660000,0xf7668000,0xf76a0000]
to
space 192K, 0% used [0xf76b0000,0xf76b0000,0xf76e0000]
PSOldGen
total 1408K, used 156K [0xf3800000, 0xf3960000, 0xf62b0000]
object space 1408K, 11% used [0xf3800000,0xf3827198,0xf3960000]
PSPermGen
total 16384K, used 2173K [0xef800000, 0xf0800000, 0xf3800000]
object space 16384K, 13% used [0xef800000,0xefa1f698,0xf0800000]
(-Xms=5504K, -Xmx=65536K, -XX:PermSize=16384K, -XX:MaxPermSize=65536K)
- 238 -
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を設定してください。
WERの設定例
- 239 -
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
・ http://support.microsoft.com/kb/837018/en-us
・ http://support.microsoft.com/kb/841176/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を起動させる場合
sh(bash)で"ulimit -c unlimited"コマンド実行後、Interstageを起動させます。ワークユニット起動ユーザがInterstage起動ユーザと違う場
合は、ワークユニット起動前に"ulimit -c unlimited"コマンドを実行してから、ワークユニットを起動させます。
・ RCプロシジャでOS起動時に自動的にInterstageが起動するように設定されている場合
以下の方法を実施することで、OS再起動後にcoreが出力されるようになります。
- 240 -
/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の処理部分を見直してください。
■メッセージの説明
JNI received a class argument that is not a class
[異常例]
char buf[1];
(*env)->AllocObject(env, (jclass)buf); //jclass型の第2引数に違う型を指定
- 241 -
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引数に数値を指定
[注意事項]
instance変数かどうかのチェック時のみに出力されるメッセージです。
Non-static field ID passed to JNI
[異常例]
jclass cls = (*env)->GetObjectClass(env, obj);
(*env)->GetStaticIntField(env, cls, -1); //jfiedlID型第2引数に数値を指定
- 242 -
[注意事項]
次の場合は、“-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でなければならない
Using JNIEnv in the wrong thread
[解説]
実行しているスレッドのためのものではないJNIEnvを使用したためのエラーです。
Java VMは、JNIインタフェースポインタ(JNIEnv)が参照する領域を、スレッド固有のデータ領域に割り当てることがあります。この
ため、JNIインタフェースポインタは、カレントスレッドに対してのみ有効です。ネイティブメソッドは、JNIインタフェースポインタを別の
スレッドに渡すといった使い方はできません。
JNI call made with exception pending
[解説]
- 243 -
ネイティブプログラムで何らかの例外が発生後、その例外を処理せずに引き続きJNI関数を実行したためのエラーです。
ネイティブプログラムでJNI関数を呼び出した後は、その都度ExceptionOccurredを使用して例外の発生状況をチェックし、必要に
応じて、例外のクリア、または、例外を上位メソッドへスローしてください。
8.6 異常発生時の原因振り分け
本項では、異常が発生したときに、原因を振り分ける方法を説明します。
8.6.1 java.lang.OutOfMemoryErrorがスローされた場合
本節では、OutOfMemoryErrorがスローされた場合、考えられる原因とその対処方法を説明します。
なお、OutOfMemoryErrorがスローされた場合に出力されるメッセージ情報については、“8.6.1.1 メモリ領域不足事象発生時のメッ
セージ出力機能の強化”も参照してください。
■想定される原因(メモリリーク)
VMがガーベジコレクションを繰り返しても、時間の経緯とともにメモリ消費量が増大していく場合、プログラム中メモリリークを起こして
いる可能性があります。
メモリリークの結果、Javaのヒープ不足が発生しOutOfMemoryErrorがスローされる場合があります。
この場合、ガーベジコレクションのログを採取して、Javaヒープの消費状況を確認してください。ガーベジコレクションのログを採取す
る方法は、“8.2.7 ガーベジコレクションのログ出力”を参照してください。
■想定される原因(Javaヒープ不足)
通常、OutOfMemoryErrorは、Javaヒープ不足が原因でスローされます。
ガーベジコレクションのログを採取して、Javaヒープの消費状況を確認してください。
Javaヒープの空き容量がないことが確認されたら、Javaヒープをチューニングしてください。
ガーベジコレクションのログを採取する方法は、“8.2.7 ガーベジコレクションのログ出力”を参照してください。
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の制御名(該当情報がある場合にだけ表示)
ユーザ空間が不足している場合は、Javaヒープまたはスタックのサイズを小さくするなどのチューニングを行ってください。
スタックのサイズをチューニングする方法は、“8.4.2 スタックのチューニング”を参照してください。
Javaヒープのチューニング方法は、“8.4.1 Javaヒープのチューニング”を参照してください。
なお、仮想メモリに余裕がある場合は、Javaプロセスを複数起動して、プロセス多重度を上げる方法もあります。J2EEアプリケーション
またはJavaEEアプリケーションの場合、J2EEまたはJavaEEのチューニングを行ってください。J2EEまたはJavaEEのチューニング方法の
詳細は、それぞれのマニュアルを参照してください。
- 244 -
■想定される原因(仮想メモリ不足)
仮想メモリが不足してスレッドが生成できない場合、次の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の発生が緩和できる場
合があります。
ガーベジコレクションのログを採取する方法は、“8.2.7 ガーベジコレクションのログ出力”を参照してください。
Javaヒープのチューニング方法は、“8.4.1 Javaヒープのチューニング”を参照してください。
GC処理の実行抑止により、クリティカルセクション状態でOutOfMemoryErrorがスローされたかどうかは、“メモリ領域不足事象発生
時のメッセージ出力機能の強化”で出力されるメッセージを参照して判断してください。
また、EXTP4435メッセージまたはISJEE_OM1018メッセージが出力されている場合は、IJServerのコンテナ情報ログ(info.log)および
IJServerクラスタのJava VMログ(jvm.log)に出力される「Java VMのヒープ域不足の詳細情報」を参照して判断してください。
8.6.1.1 メモリ領域不足事象発生時のメッセージ出力機能の強化
FJVMでは、メモリ領域不足事象発生時に出力されるメッセージ情報の強化を行なっています。
これによりFJVMでは、メモリ領域不足事象が発生した場合に、java.lang.OutOfMemoryErrorの例外メッセージ情報に加え、不足した
領域の種別情報を図1の形式で出力します。
図1 メモリ領域不足事象が発生した場合に出力される不足した領域の種別情報
The memory was exhausted area_name
Java heap size / max Java heap size = heap_size / max_heap_size
Java perm size / max Java perm size = perm_size / max_perm_size
area_name:
メモリ領域不足事象が発生した領域の名前や領域不足となったオブジェクトの要
求サイズ（不足領域情報）を表示します。
不足領域情報としては以下の項目があります。
- 245 -
・ on Java heap space. : requested <NNNN> bytes
NNNNバイトのオブジェクト生成要求において、メモリ割り当てプール(New世
代領域またはOld世代領域)に対してメモリ領域不足事象が発生した場合です。
なお、JDK/JRE 5.0、6のエルゴノミクス機能によるメモリ領域不足事象の検出
機能が有効な場合で、かつ当該機能によりメモリ領域不足事象を検出した場
合、この項目になる場合があります。
・ on Java heap space. : requested <NNNN> bytes (in critical section)
意味は「on Java heap space. : requested <NNNN> bytes」と同じですが、メモ
リ領域不足事象発生時、クリティカルセクション状態でGC処理の実行が抑止
されていたことを示しています。
・ on Java perm space. : requested <NNNN> bytes
NNNNバイトのオブジェクト生成要求において、Permanent世代領域に対して
メモリ領域不足事象が発生した場合です。
なお、JDK/JRE 5.0、6のエルゴノミクス機能によるメモリ領域不足事象の検出
機能が有効な場合で、かつ当該機能によりメモリ領域不足事象を検出した場
合、この項目になる場合があります。
・ 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アプリケーション実行時における配列生成式の評価の段階で、配
列オブジェクトの長さ（配列要素の数）から、当該配列オブジェクトを割り当て
るための領域が十分でないと評価された場合（配列の長さ（配列要素の数）が
大きすぎ、配列オブジェクトとしての大きさが２ギガバイト程度もしくはそれ以上
の大きさになる配列の定義がある場合）。
またはクラスのロード処理でメモリ不足が発生した場合。
なお、JDK/JRE 6のエルゴノミクス機能によるメモリ領域不足事象の検出機能
が有効な場合で、かつ当該機能によりメモリ領域不足事象を検出した場合、こ
の項目になる場合があります。
heap_size:
メモリ領域不足事象が発生した際に使用中となっているメモリ割り当てプールのサ
イズ(単位:byte)。
max_heap_size:
利用可能なメモリ割り当てプールの最大サイズ(単位:byte)。
perm_size:
メモリ領域不足事象が発生した際に使用中となっているPermanent世代領域のサ
イズ(単位:byte)。
max_perm_size:
利用可能なPermanent世代領域の最大サイズ(単位:byte)。
メモリ領域不足事象が発生した際に出力される各領域の使用中サイズ(heap_size、perm_size)には、メモリ領域不足の原因となったオ
ブジェクトの大きさは含まれません。
そのため巨大サイズのオブジェクト生成要求などによりメモリ領域不足事象が発生した場合には、「最大サイズ」と「使用中サイズ」の
差が大きい場合（空き領域がたくさんあるように見える場合）がありますので注意してください。
- 246 -
FJGC以外のGC処理におけるNewGC処理では、New世代領域を「eden space」、「from space」および「to space」の3つの内部領域に
細分割し、当該領域上において、一般に世代別GC制御と言われる制御方法を用いて、Javaアプリケーションが生成要求したオブジェ
クトを管理・制御しています。
このうち、「from space」および「to space」は、Java VMがNewGC処理を行う際の作業域的な役割を持つ領域となっています。そのた
め、「from space」および「to space」の各領域が占める大きさのうち、Javaアプリケーションからのオブジェクト生成要求のために使用され
る大きさは、その領域の一部分だけとなります。
そのため、FJGC以外のGC処理を使用している場合は、出力データにおいて、メモリ割り当てプールやNew世代領域に空きがあるよ
うに見える場合であっても、実際には空きがない場合がありますので注意してください（空きがあるように見える場合であっても、その差
は、NewGC処理用の作業域的な役割で使用済となっている場合があります）。
メモリ割り当てプールに対してメモリ領域不足事象が発生した場合に出力されるheap_sizeの値は、New世代領域での使用中サイズと
Old世代領域での使用中サイズの合計値です。
New世代領域とOld世代領域は別々のオブジェクト格納域として管理・制御されますから、max_heap_sizeとheap_sizeの差の大きさが、
そのまま生成要求できるオブジェクトの最大サイズにはなりませんので注意してください。
図2 メモリ領域不足事象が発生した場合に出力されるメッセージ出力例
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
The 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ヒープをチューニングしてください。
Javaヒープのチューニング方法は、“8.4.1 Javaヒープのチューニング”を参照してください。
・ EXTP4435メッセージ
・ ISJEE_OM1018メッセージ
各メッセージの内容については、“メッセージ集”を参照してください。
なお、IJServerのコンテナ情報ログ(info.log)およびIJServerクラスタのJava VMログ(jvm.log)に出力される「Java VMのヒープ域不足の
詳細情報」の出力形式は、図1のとおりです。
図1 Java VMのヒープ域不足の詳細情報の出力形式
-----------------------------------------------------------------OutOfMemory Log
-----------------------------------------------------------------pid=process_id
heap_type=heap_type_code
heap_size=heap_size
- 247 -
max_heap_size=max_heap_size
perm_size=perm_size
max_perm_size=max_perm_size
requested_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 heap
requested_sizeバイトのオブジェクト生成要求において、メモリ割り当てプー
ル(New世代領域またはOld世代領域)に対してメモリ領域不足事象が発
生した場合です。
この項目のときのheap_type_codeは「1」になります。
なお、JDK/JRE 5.0、6のエルゴノミクス機能によるメモリ領域不足事象の検
出機能が有効な場合で、かつ当該機能によりメモリ領域不足事象を検出
した場合、この項目になる場合があります。
・ Java heap in critical section
意味は「Java heap」と同じですが、メモリ領域不足事象発生時、クリティカ
ルセクション状態でGC処理の実行が抑止されていたことを示しています。
・ Java Perm
requested_sizeバイトのオブジェクト生成要求において、Permanent世代領
域に対してメモリ領域不足事象が発生した場合です。
この項目のときのheap_type_codeは「2」になります。
なお、JDK/JRE 5.0、6のエルゴノミクス機能によるメモリ領域不足事象の検
出機能が有効な場合で、かつ当該機能によりメモリ領域不足事象を検出
した場合、この項目になる場合があります。
・ Java Perm space in critical section
意味は「Java Perm」と同じですが、メモリ領域不足事象発生時、クリティカ
ルセクション状態でGC処理の実行が抑止されていたことを示しています。
・ C heap 制御情報
スタックやヒープなど、Javaヒープ以外の領域に対してメモリ領域不足事象
が発生した場合（requested_sizeバイトのメモリ割り当て要求が失敗した場
合）です。
この項目のときのheap_type_codeは「0」になります。
なお、現象発生時の要求サイズが不明な場合のrequested_sizeは「0」に
なります。
また、次行に制御情報(メモリが確保できなかったJava VM制御の情報)が
出力される場合があります。
- 248 -
・ unknown space
Javaアプリケーション実行時における配列生成式の評価の段階で、配列
オブジェクトの長さ（配列要素の数）から、当該配列オブジェクトを割り当て
るための領域が十分でないと評価された場合（配列の長さ（配列要素の
数）が大きすぎ、配列オブジェクトとしての大きさが２ギガバイト程度もしく
はそれ以上の大きさになる配列の定義がある場合）。
またはクラスのロード処理でメモリ不足が発生した場合。
なお、JDK/JRE 6のエルゴノミクス機能によるメモリ領域不足事象の検出機
能が有効な場合で、かつ当該機能によりメモリ領域不足事象を検出した
場合、この項目になる場合があります。
この項目のときのheap_type_codeは「-1」になります。
なお、この項目の場合のrequested_sizeは「0」になります。
stack_trace:
メモリ領域不足事象が発生したスレッドがJavaアプリケーションを実行している
スレッドだった場合は、当該スレッドのスタックトレースが出力されます。それ以
外のスレッドの場合、またはリソース不足によりスタック情報が取り出せない場
合は、スタックトレースは出力されません。
メモリ領域不足事象が発生した際に出力される各領域の使用中サイズ(heap_size、perm_size)には、メモリ領域不足の原因となったオ
ブジェクトの大きさは含まれません。
そのため巨大サイズのオブジェクト生成要求などによりメモリ領域不足事象が発生した場合には、「最大サイズ」と「使用中サイズ」の
差が大きい場合（空き領域がたくさんあるように見える場合）がありますので注意してください。
FJGC以外のGC処理におけるNewGC処理では、New世代領域を「eden space」、「from space」および「to space」の3つの内部領域に
細分割し、当該領域上において、一般に世代別GC制御と言われる制御方法を用いて、Javaアプリケーションが生成要求したオブジェ
クトを管理・制御しています。
このうち、「from space」および「to space」は、Java VMがNewGC処理を行う際の作業域的な役割を持つ領域となっています。そのた
め、「from space」および「to space」の各領域が占める大きさのうち、Javaアプリケーションからのオブジェクト生成要求のために使用され
る大きさは、その領域の一部分だけとなります。
そのため、FJGC以外のGC処理を使用している場合は、出力データにおいて、メモリ割り当てプールやNew世代領域に空きがあるよ
うに見える場合であっても、実際には空きがない場合がありますので注意してください（空きがあるように見える場合であっても、その差
は、NewGC処理用の作業域的な役割で使用済となっている場合があります）。
メモリ割り当てプールに対してメモリ領域不足事象が発生した場合に出力されるheap_sizeの値は、New世代領域での使用中サイズと
Old世代領域での使用中サイズの合計値です。
New世代領域とOld世代領域は別々のオブジェクト格納域として管理・制御されますから、max_heap_sizeとheap_sizeの差の大きさが、
そのまま生成要求できるオブジェクトの最大サイズにはなりませんので注意してください。
図2 Java VMのヒープ域不足の詳細情報の出力例
【JDK/JRE 5.0の場合】
-------------------------------------------------------------------------------OutOfMemory Log
-------------------------------------------------------------------------------pid=4636
heap_type=1
heap_size=136816
- 249 -
max_heap_size=4194304
perm_size=1811104
max_perm_size=67108864
requested_size=40000016
-------------------------------------------------------------------------------VM is terminated by occurred OutOfMemoryError on Java heap.
"main" prio=6 tid=0x00036840 nid=0x254 runnable [0x0007f000..0x0007fbf8]
at test.<init>(test.java:10)
at test.main(test.java:5)
【JDK/JRE 6の場合】
-------------------------------------------------------------------------------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]
java.lang.Thread.State: RUNNABLE
at test.<init>(test.java:10)
at test.main(test.java:5)
JDK/JRE 6からスタックトレース情報にスレッドの状態を表す情報（トレース情報の前の行）が表示されるようになりました。
図中の例では「java.lang.Thread.State: RUNNABLE」となっていますが、"RUNNABLE"の部分が、"NEW"、"TIMED_WAITING
(sleeping)"、"WAITING (on object monitor)"、"TIMED_WAITING (on object monitor)"、"WAITING (parking)"、"TIMED_WAITING
(parking)"、"BLOCKED (on object monitor)"、"TERMINATED"、"UNKNOWN"などの表示の場合があります。
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ログ”を参照してください。
スタックオーバーフロー発生の原因が、Java APIで生成されたスレッドに対するスタックのサイズにある場合は、“8.4.2 スタックのチュー
ニング”を参照して、Java APIで生成されるスレッドに対するスタックのサイズをチューニングしてください。
- 250 -
検出対象となるスレッド
本機能でスタックオーバーフローの検出対象となるスレッドは、原則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ログにおいて、以下の情報が出力されている場合が、上記状態に相当
します。
siginfo:si_signo=10, si_errno=12, si_code=3, si_addr=16進数
異常終了時の情報として上記情報が出力された場合は、不要なプロセスを終了して仮想メモリに余裕を持たせるか、物理メモリ(RAM)
またはスワップファイルを拡張して仮想メモリを増やすようにチューニングを行ってください。
8.6.5 プロセスが消滅(異常終了)した場合
本節では、何の痕跡も残さずに突然プロセスが消滅した場合に、考えられる原因とその対処方法を説明します。
■想定される原因(スタックオーバーフロー)
FJVMには、スタックオーバーフロー検出時にメッセージを出力する機能を備えています。FJVMログを分析することにより、スタック
オーバーフローが発生したかどうかを確認することができます。FJVMログの分析方法は、“8.6.3.1 スタックオーバーフロー検出時のメッ
セージ出力機能”を参照してください。
- 251 -
スタックオーバーフローが発生したことを確認できた場合、該当するスタックのサイズをチューニングしてください。スタックのチューニ
ング方法は、“8.4.2 スタックのチューニング”を参照してください。
通常、スタックオーバーフローが発生した場合、java.lang.StackOverflowErrorがスローされ、ワトソン博士が検知してユーザダンプお
よびワトソンログを出力します。
しかし、OSが高負荷状態になったり、スタックオーバーフロー発生時のスタック残量が少なかったりすると、OSからFJVMにもワトソン
博士にも制御が渡らないまま、痕跡を残さずにプロセスが消滅することがあります。
したがって、プロセスが消滅した原因が不明な場合は、スタックのサイズを拡張して、現象が改善できるかどうかを確認してください。
スタックのサイズを拡張しても改善できない場合は、別の原因を調査してください。
なお、ワトソン博士の説明は、“8.5.9.1 クラッシュダンプ”を参照してください。
■想定される原因(長時間コンパイル処理の検出機能による終了)
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つとして、次のいずれかが考えられ
ます。
・ java.lang.Runtime.exit()を予想外の箇所で実行した
・ java.lang.Runtime.halt()を予想外の箇所で実行した
・ java.lang.System.exit()を予想外の箇所で実行した
FJVMを使用している場合は、“8.5.6 Java VM終了時における状態情報のメッセージ出力機能”を参照して、対処してください。
■想定される原因(Windows Server(R) 2003の問題)
- 252 -
Windows Server(R) 2003の初期版においては、ユーザダンプが出力されない問題をはじめとして、その他にもJavaの実行動作に影
響を及ぼす問題などがあります。
たとえば、次のような問題があります。
・ http://support.microsoft.com/kb/836080/en-us
・ http://support.microsoft.com/kb/837018/en-us
・ http://support.microsoft.com/kb/841176/en-us
Windows Server(R) 2003を使用する場合は、Service Pack 1以降またはHotfixを適用してください。
8.6.6 ハングアップ(フリーズ)した場合
本節では、Javaプロセスが残っているにもかかわらず、プログラムが無応答になった場合、考えられる原因とその対処方法を説明しま
す。
■想定される原因(デッドロック)
デッドロックが発生した場合、そのスレッドが停止されます。
ハングアップしたときに、スレッドダンプを採取して、デッドロックがないかどうかを確認してください。
スレッドダンプの採取方法および解析方法の詳細は、“8.5.3 スレッドダンプ”を参照してください。
■想定される原因(ガーベジコレクション)
ガーベジコレクションが発生すると、ガーベジコレクションが終了するまでの間、Javaアプリケーションのすべてのスレッドが停止されます。
これにより、Javaアプリケーションがハングアップしたかのように見える場合があります。
ガーベジコレクションのログを採取して、ガーベジコレクションが動作したタイミングを照合してください。ガーベジコレクションが原因で
無応答のような現象になる場合は、Javaヒープをチューニングして、ガーベジコレクションの動作具合を改善してください。
ガーベジコレクションのログを採取する方法は、“8.2.7 ガーベジコレクションのログ出力”を参照してください。
Javaヒープのチューニング方法は、“8.4.1 Javaヒープのチューニング”を参照してください。
■想定される原因(JNI処理の異常)
JNI経由でJava以外の言語で開発したネイティブモジュールと連携する際、JNIの使用方法を誤ると、ハングアップの原因となります。
このようなときは、“-Xcheck:jni”オプションを指定して、JNI処理でメッセージが出力されないかどうかを確認してください。“-Xcheck:jni”
オプションの詳細は、“8.5.10 JNI処理異常時のメッセージ出力”を参照してください。
JNI処理に誤りがなくても、JNIモジュールで異常終了またハングアップが発生すると、Javaアプリケーションがハングアップする場合が
あります。たとえば、スレッドアンセーフな関数を使用している場合は、注意が必要です。
スレッドアンセーフな関数の例
次の関数を使用したときに、ハングした事例があります。
・ vfork
8.6.7 スローダウンが発生した場合
本節では、Javaアプリケーションの動きが遅くなる現象(スローダウン)が発生した場合に、考えられる原因とその対処方法を説明しま
す。
■想定される原因(ガーベジコレクション)
ガーベジコレクションが発生すると、ガーベジコレクションが終了するまでの間、Javaアプリケーションのすべてのスレッドが停止されま
す。このため、Javaアプリケーションのレスポンス(応答)が遅くなる場合があります。
- 253 -
ガーベジコレクションのログを採取して、ガーベジコレクションが動作したタイミングとスローダウンが発生したタイミングを照合してくだ
さい。ガーベジコレクションが原因でスローダウンになる場合は、Javaヒープをチューニングして、ガーベジコレクションの動作具合を改
善してください。
ガーベジコレクションのログを採取する方法は、“8.2.7 ガーベジコレクションのログ出力”を参照してください。
Javaヒープのチューニング方法は、“8.4.1 Javaヒープのチューニング”を参照してください。
スローダウンの事例
同じソフトウェアとJavaアプリケーションが動作している複数のWebサーバのうち、一部のサーバだけがスローダウンしたという事例が
あります。この原因は、マシンに搭載されている物理メモリ(RAM)の容量の違いでした。
物理メモリ(RAM)が少ないマシンの場合、ガーベジコレクションの実行に伴い、ディスクのスワッピングが発生し、スローダウンすること
があります。
8.7 Javaツール機能
本製品では、Javaプログラムのチューニングやトラブルシューティングに有用なツールを提供しています。ツールには、次の3つがあり
ます。
・ メソッドのトレースを出力するメソッドトレース機能
・ Javaヒープ使用量を出力するjheap
・ スレッドダンプを出力するスレッドダンプツール(Windows(R)のみ)
ツール本体は、次に格納してあります。
・ JDK 5.0使用時: [Interstageインストールフォルダ]\jdk5\tools
・ JRE 5.0使用時: [Interstageインストールフォルダ]\jre5\tools
・ JDK 6使用時 : [Interstageインストールフォルダ]\jdk6\tools
・ JRE 6使用時 : [Interstageインストールフォルダ]\jre6\tools
以下の“$DIR”はインストール時に指定する相対ディレクトリ名です。“$DIR”のシステム推奨名は“opt”です。
・ JDK 5.0使用時: /$DIR/FJSVawjbk/jdk5/tools
・ JRE 5.0使用時: /$DIR/FJSVawjbk/jre5/tools
・ JDK 6使用時 : /$DIR/FJSVawjbk/jdk6/tools
・ JRE 6使用時 : /$DIR/FJSVawjbk/jre6/tools
各ツールの詳細は、“トラブルシューティング集”の“Javaツール機能”を参照してください。
- 254 -
第9章 データベース連携サービスのチューニング
Interstageのシステム構成に応じて、データベース連携サービスで提供するパラメタをチューニングする必要があります。
ここでは、データベース連携サービスのiniファイル内のパラメタについて説明します。
9.1 データベース連携サービスのiniファイル設定情報
データベース連携サービスのiniファイルには、以下の表に示すパラメタを設定します。
システムチューニングを行ってデータベース連携サービスを使用する場合は、iniファイルを変更します。iniファイルを変更しない場
合、データベース連携サービスは、初期値で動作します。
iniファイルは、インストール時に、以下に格納されます。設定例については、“9.2 iniファイルの設定例”を参照してください。
■ファイル名
C:\Interstage\ots\etc\ots.ini
注）本製品のインストールパスがデフォルトの場合のパスです。
■パラメタ一覧
タイプ
共用メモリ
セマフォ
メッセージ
キュー
Windows(R)
固有パラメタ
パラメタ
意味
初期値
最小値
最大値
チューニン
グ
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
－
msgemuwait
メッセージキューwaitプロセス数 (注2)
64
64
16777215
○
insmax
内部プロセス間通信メッセージ長
32768
32768
16777215
－
msgwait
内部プロセス間通信待ち合わせ数 (注
2)
64
64
16777215
○
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
－
○：チューニング可能です。
－：基本的には、初期値から変更しないでください。
- 255 -
注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
#
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 セマフォ資源
データベース連携サービスを使用する場合、同期制御／排他制御のため、セマフォ資源を使用します。
セマフォ資源は、以下の算出式で見積ります。
- 256 -
セマフォ資源
意味
種類
必要数
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：リソース定義ファイルの合計
- 257 -
付録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において提供)
config
inithost/initial_hosts
・ 上記以外のファイルは、CORBAサービスの動作環境としてカスタマイズできません。エディタなどで編集しないでください。
・ 上記のファイル内に日本語は記載できません。
・ システムの異常停止などに起因して動作環境ファイルなどの資源が破壊されると、CORBAサービスが正常に起動できない場合が
あります。
正常に起動できない、かつ以下のメッセージが発生する場合は、資源が破壊されている可能性があるので、環境の再構築を行う
か、バックアップした資源を復元してCORBAサービスの再起動を行う必要があります。
メッセージ番号:od10400, od10402, od10404, od10406, od10504, od10509, od10510
万が一のため、運用環境を構築したら資源のバックアップを行うことを推奨します。
- 258 -
バックアップについては、“運用ガイド(基本編)”の“メンテナンス(資源のバックアップ/他サーバへの資源移行/ホスト情報の変更)”
で説明されています。
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
◆パラメタ:
以下の動作環境について、パラメタ設定値を変更することができます。
・ ホスト情報に関する動作環境
・ ネットワーク環境に関する動作環境
・ アプリケーション資源に関する動作環境
・ タイムアウト監視に関する動作環境
・ セキュリティ機能に関する動作環境
・ コード変換機能に関する動作環境
- 259 -
・ 保守機能に関する動作環境
・ 旧バーションの互換に関する動作環境
・ パラメタ値を変更した場合、次回のCORBAサービス起動時より有効となります。
・ configファイル内に日本語は記載できません。
・ 下表に記載していないパラメタは初期値を変更しないでください。
・ 備考欄に“必須パラメタ”と記載されているパラメタは省略することはできません。(Solaris版および Linux版には必須パラメタはあり
ません)
・ 数値を指定するパラメタ(period_receive_timeout等)に数値以外の文字列(“abc”など)を指定した場合、“0”が設定されたものとして
扱われます。
◆ホスト情報に関する動作環境
パラメタ名
初期値
意味
備考
省略値
指定範囲
IIOP_hostname
－
－
－
IIOP_port
8002
－
－
マシンにIPアドレス(またはホスト名)が複数設定されている場合
に、CORBAサーバアプリケーションで使用するIPアドレスを限
定した運用を行う場合に設定します。
IPアドレス(またはホスト名)を設定すると、サーバアプリケーショ
ンのオブジェクトリファレンスの生成時には、ここで設定したIP
アドレスが組み込まれ、クライアントからの接続時に使用されま
す。また、CORBAサービスは指定されたIPアドレスのみでバイ
ンドを行います。
本パラメタが省略された場合はすべてのIPアドレスに対してバ
インドが行われます。ただし、IPv4/IPv6のどちらの(または両方
の)IPアドレスをバインドするかどうかはIP-versionパラメタの設
定に依存します。
サーバ機能
のみ有効。
(注1) (注2)
(注3)
CORBAサービスが使用するポート番号。
Windowsの場合、省略できません。
Solaris、Linuxの場合、初期値(8002)以外を指定するときは必
ず指定してください。
(注4)
注1)
Interstage Web Serverでは指定不可。
注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アドレスで定義されているホスト名を設定した場合も同
- 260 -
様に他ホストからのリクエストが受け付けられなくなります。
LinuxではOSインストール直後の状態では自ホスト名に対するIPアドレスが127.0.0.1に設定されており、自ホスト名をIIOP_hostname
に設定すると他ホストからの接続を受け付けることができなくなります。
注4)
Windowsの場合、必須パラメタです。
Solaris、Linuxの場合、この値が無効になると/etc/servicesの設定値が有効になります。
◆ネットワーク環境に関する動作環境
パラメタ名
初期値
意味
備考
省略値
指定範囲
con_accept
all
all
all, localhost
IP-version
v4-dual
v4-dual
v4, v4-dual,
v6
・ all:
すべてのマシンからの接続を受け付けます。
・ localhost:
クライアントからの接続受付を自ホストに制限する場合に
指定します。自ホストからの接続のみを受け付け、他ホス
トからの接続を受け付けません。
システムセキュリティなどの理由で、他ホストからの接続要
求を許可しない場合に指定してください。
運用する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”が設定されます。
read_interval_timeout
30
30
0～
100000000
write_interval_timeout
30
ソケットに対する読み込みの待機時間。
この時間を超えても読み込みできない状態が持続する場合、
アプリケーションにシステム例外(COMM_FAILURE)が通知
されます。
この値が実際の時間(秒)となります。0を設定した場合、時間
監視をしません。
このパラメタによる監視は電文の受信処理が始まってから開
始されます。例えば、リプライの受信待ちの状態においてパ
ケットが1つも届かなければread_interval_timeoutによる監視
は行いません。この場合はperiod_receive_timeoutによる監視
が行われます。パケットが1つでも届くと電文の受信処理を開
始するためread_interval_timeoutによる監視が行われます。
ソケットに対する書き込みの待機時間。
この時間を超えて書き込みできない状態が持続する場合、ア
- 261 -
サーバ機能
のみ有効。
(注)
パラメタ名
初期値
意味
備考
省略値
指定範囲
30
0～
100000000
tcp_nodelay
no
no
yes, no
プリケーションにシステム例外(COMM_FAILURE)が通知さ
れます。
この値が実際の時間(秒)となります。0を設定した場合、時間
監視をしません。
このパラメタによる監視は電文の送信処理が始まってから開
始されます。
TCP_NODELAY機能を有効にするか無効にするかを設定し
ます。
・ yes: 電文送信時においてNagleアルゴリズムを無効にしま
す。
・ no : Nagleアルゴリズムは有効となります。
Nagleアルゴリズムが有効の場合、送信データのバッファリン
グを行うためネットワーク使用効率が上がります。Nagleアルゴ
リズムを無効にした場合、送信データのバッファリングを行わ
ないためネットワーク使用効率が下がり通信全体の性能が下
がる可能性がありますが、データの送受信に発生するタイム
ラグが減少し、応答性能が向上する場合があります。
注)
Interstage Web Serverでは初期値から変更しないでください。
◆アプリケーション資源に関する動作環境(プロセス/スレッド多重度、使用コネクション数など)
これらのパラメタに実際に指定可能な値はOSの資源によって制限されます。
パラメタ名
初期値
意味
備考
サーバアプリケーションのリクエスト実行用スレッド(または
プロセス)の最大数。
サーバ機能
のみ有効。
(注1) (注3)
(注4)
クライアントアプリケーションが使用するサーバホストへの
コネクションの最大値。
ポイント参照
省略値
指定範囲
max_exec_instance
512 (注8)
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
1～500000
- 262 -
サーバ機能
のみ有効。
(注2) (注4)
(注11)
(注12)
ポイント参照
パラメタ名
初期値
意味
備考
max_IIOP_resp_conの自動拡張の最大値。
0またはmax_IIOP_resp_con以上の値を指定してください。
0を指定すると以下の値が設定されます。
サーバ機能
のみ有効。
(注1) (注4)
(注6) (注11)
(注12)
省略値
指定範囲
limit_of_max_IIOP_resp_con
0 (意味参
照)
0 (意味参
照)
max_IIOP_resp_con × 1.3 (小数部分切り捨て)
0～1000000
max_IIOP_resp_con_extend_number
0 (意味参
照)
0 (意味参
照)
max_IIOP_resp_conの自動拡張の拡張数。
0を指定すると以下の値が設定されます。
(limit_of_max_IIOP_resp_con － max_IIOP_resp_con)
÷ max_IIOP_resp_con (小数部分切り上げ)
サーバ機能
のみ有効。
(注1) (注6)
(注7) (注11)
(注12)
0～1000000
max_IIOP_resp_requests
サーバホストにおいて同時に受信できるリクエスト数の最
大値。
サーバ機能
のみ有効。
(注2) (注4)
(注10)
0 (意味参
照)
max_IIOP_resp_requestsの自動拡張の最大値。
0またはmax_IIOP_resp_requests以上の値を指定してくだ
さい。
0を指定すると以下の値が設定されます。
サーバ機能
のみ有効。
(注1) (注4)
(注6) (注10)
0～1000000
max_IIOP_resp_requests × 1.3 (小数部分切り捨て)
0 (意味参
照)
max_IIOP_resp_requestsの自動拡張の拡張数。
0を指定すると以下の値が設定されます。
128 (注8)
128
1～500000
limit_of_max_IIOP_resp_requests
max_IIOP_resp_requests_extend_number
0 (意味参
照)
0 (意味参
照)
max_processes
サーバ機能
のみ有効。
(注1) (注6)
(注7)
0～1000000
(limit_of_max_IIOP_resp_requests －
max_IIOP_resp_requests) ÷ max_IIOP_resp_requests (小
数部分切り上げ)
20 (注8)
最大プロセス数。(起動クライアント ＋ サーバ数)
サーバ機能
のみ有効。
(注4) (注5)
インプリメンテーションリポジトリの最大登録数。
サーバ機能
のみ有効。
(注2)
CORBAサービスのキュー制御で使用するデフォルトバッ
ファのバッファ数を指定します。
ワークユニット運用されているCORBAアプリケーションで
ワークユニット定義の“Buffer Number:通信バッファ数”を
指定しているCORBAアプリケーションを除く、CORBAサー
ビスの通信で使用します。
サーバマシン上で同時に処理される最大リクエスト数を指
定してください。
0を指定すると、以下の値が設定されます。
サーバ機能
のみ有効。
(注2) (注4)
16
1～1000000
max_impl_rep_entries
512
256
100～
1000000
number_of_common_buffer
0 (意味参
照)
0 (意味参
照)
0～500000
(注10)
max_IIOP_resp_requests × 0.2 (小数部分切り捨て)
limit_of_number_of_common_buffer
0 (意味参
照)
number_of_common_bufferの自動拡張の最大値。
0またはnumber_of_common_buffer以上の値を指定してく
- 263 -
サーバ機能
のみ有効。
パラメタ名
初期値
意味
備考
省略値
指定範囲
number_of_common_buffer_extend_number
0 (意味参
照)
ださい。
0を指定すると以下の値が設定されます。
0～1000000
(注10)
limit_of_max_IIOP_resp_requests
0 (意味参
照)
number_of_common_bufferの自動拡張の拡張数。
0を指定すると以下の値が設定されます。
0 (意味参
照)
(limit_of_number_of_common_buffer －
number_of_common_buffer) ÷
number_of_common_buffer (小数部分切り上げ)
0～1000000
max_bind_instances
0 (意味参
照)
CORBAサービスに登録可能な「サーバプロセスとオブジェ
クトのバインド関係」の数。
0を指定すると以下の値が設定されます。
0 (意味参
照)
(注1) (注4)
(注6)
サーバ機能
のみ有効。
(注1) (注6)
(注7)
サーバ機能
のみ有効。
(注2) (注4)
(注9)
1024 × max_processes
( 計算結果が65535を超えた場合は65535 )
0～1000000
注1)
Interstage Web Serverでは指定不可。
注2)
Interstage Web Serverでは初期値から変更しないでください。
注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に対応した接続クライアント数
注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分割で必要に応じて拡
- 264 -
張を行います。
以下に例を示します。
--------------------------------------------------------------------max_IIOP_resp_con = 100
limit_of_max_IIOP_resp_con = 140
max_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 = 100
limit_of_max_IIOP_resp_con = 300
max_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では初期値に変更はありません。
Interstage Application Server Enterprise Edition/Standard-J Editionで標準インストール・カスタムインストール・GUIインストーラを使
用したインストールを行った場合(pkgaddコマンドによるインストールを行わない場合)。
Interstage Application Server Enterprise Editionの拡張システムおよびInterstage Web Serverでは初期値に変更はありません。
Interstage Application Server Enterprise Edition/Standard-J Editionで標準インストール・カスタムインストール・GUIインストーラを使
用したインストールを行った場合(rpmコマンドによるインストールを行わない場合)。
Interstage Web Serverでは初期値に変更はありません。
初期値は以下のように変更されています。
パラメタ名
初期値
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の設定可能な値はSolaris 9ではシステムパラメタのsemvmx値、
- 265 -
Solaris 10以降では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" ま た は 、 "(limit_of_max_IIOP_resp_con
max_IIOP_resp_con_extend_numberの計算値"は、OSの仕様により最大値が以下に制限されます。
-
max_IIOP_resp_con)/
－ 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つのサーバアプリケーションに複数のリクエストが同時に発行されても、コネクション数は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:
- 266 -
クライアントアプリケーションが動作しているホスト上で、クライアントアプリケーション(プロセス単位)からサーバアプリケーション(ホスト
単位)へのコネクション数の最大値を指定します。
・ 設定値の目安(インタフェースリポジトリ動作時):
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
ポイント: 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から変更の必要はありません。
- 267 -
max_IIOP_resp_requests:
CORBAサーバアプリケーションが同時に受信できるリクエスト数の最大値を指定します。
それぞれのクライアントマシンから発行されたリクエストがサーバマシンに到達し、CORBAサーバアプリケーションで同時に処理され
る数になるので、個々のクライアントマシンから同時に発行されるリクエストの合計値を見積もる必要があります。
下 の 図 で は そ れ ぞ れ の ク ラ イ ア ン ト マ シ ン か ら 発 行 さ れ た リ ク エ ス ト が 同 時 に 9 個 サ ー バ マ シ ン に 到 達 し て い る の で、
max_IIOP_resp_requestsには9以上を設定する必要があります。
◆タイムアウト監視に関する動作環境
パラメタ名
初期値
意味
備考
省略値
指定範囲
period_client_idle_con_timeout
96 (480秒)
96 (480秒)
0～20000000
period_idle_con_timeout
120 (600秒)
クライアントにおける、無通信状態(サーバへのリクエスト送信な
し)の監視時間(リクエスト返信完了後のコネクション維持時間)。
この時間を超えてもサーバへのリクエスト送信がない場合、サー
バとのコネクションの切断を行います。(注3)
この値に5を乗じた値が実際の時間(秒)となります。0を設定す
ると無通信監視を行いません。
サーバにおける、無通信状態(クライアントからのリクエスト送信
なし)の監視時間(リクエスト返信完了後のコネクション維持時間)。
- 268 -
サーバ機能
のみ有効。
(注1) (注4)
パラメタ名
初期値
意味
備考
省略値
指定範囲
1 (5秒)
0～20000000
period_receive_timeout
72 (360秒)
72 (360秒)
0～20000000
period_server_timeout
120 (600秒)
(注2)
120 (600秒)
1～20000000
この時間を超えてもクライアントからのリクエスト送信がない場
合、クライアントとのコネクションを切断し、リクエスト処理に使用
したメモリ資源を解放します。
この値に5を乗じた値が実際の時間(秒)となります。0を設定す
ると無通信監視を行いません。
クライアントにおける、リクエスト送信から返信までの待機時間。
この時間を超えてもサーバからの返信がない場合、クライアン
トにタイムアウトが通知されます。
この値に5を乗じた値が実際の時間(秒)となります。
Persistentタイプ以外のサーバアプリケーションとその他のアプ
リケーションで意味が異なります。
Persistentタイプ以外のサーバアプリケーションにおいてはアプ
リケーション起動からCORBA_ORB_initメソッド完了までの監
視時間となります。この時間以内にCORBA_ORB_initメソッド
が完了しないとクライアントにシステム例外(NO_IMPLEMENT)
が通知されます。
クライアントアプリケーションとPersistentタイプのサーバアプリ
ケーションにおいてはCORBA_ORB_initメソッド発行から
CORBA_ORB_initメソッド完了までの監視時間となります。
この値に5を乗じた値が実際の時間(秒)となります(0は指定で
きません)。
サーバ機能
のみ有効。
(注1)
注1)
Interstage Web Serverでは初期値から変更しないでください。
注2)
初期値より減少させた場合は、インタフェースリポジトリの起動に失敗することがあります。
注3)
次回リクエスト送信時にサーバとのコネクションの再接続を行います。
なお、クライアントアプリケーションがプロセスモードの場合は、時間超過のタイミングではコネクション切断は行わず、次回リクエスト送
信時にサーバとのコネクションの切断・再接続を行います。
注4)
サーバ側の無通信監視時間超過によるコネクション切断のタイミングでクライアントがリクエストを発行すると、クライアントに通信異常
が通知される場合があります。この問題を回避するためには、クライアント側のperiod_client_idle_con_timeoutにサーバ側の
period_idle_con_timeoutよりも小さな値を設定してください。
タイムアウト時間は、連携するアプリケーションに適用されるタイムアウト時間を考慮して設定する必要があります。詳細は“OLTPサー
バ運用ガイド”(Interstage Application Server Enterprise Editionで提供)の“CORBAアプリケーション運用時のタイマ監視”を参照してく
ださい。
◆セキュリティ機能に関する動作環境(アプリケーション間通信)
パラメタ名
初期値
意味
備考
省略値
指定範囲
http_proxy
proxy_host
HTTPプロキシサーバのホスト名。
- 269 -
(注1) (注2)
パラメタ名
初期値
意味
備考
省略値
指定範囲
null
(値は設定さ
れません)
－
http_proxy_port
8080
HTTPプロキシサーバのポート番号。
(注1) (注2)
HTTPプロキシサーバの使用を指定。
(注1) (注2)
0
－
http_proxy_use
no
UNO_IIOP_ssl_use
UNO_IIOP_ssl_port
no
・ yes:使用する
yes, no
・ no :使用しない
no
SSL連携の有効/無効を選択。
no
・ yes:有効
yes, no
・ no :無効
4433
4433
(注3)
SSL連携で使用するポート番号。
UNO_IIOP_ssl_useが“yes”の場合に有効です。
－
注1)
Interstage Web Serverでは初期値から変更しないでください。
注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サービス資源)
パラメタ名
初期値
意味
備考
CORBAサービス資源のセキュリティ強化機能の有効/無効を指
定。“yes”を指定すると、CORBAアプリケーションはiss_groupの
グループに属するユーザ(またはroot)のみが起動可能となりま
す。
(注1) (注2)
CORBAサービス資源のセキュリティ強化機能有効時
（iss_use=yes指定）のアプリケーション動作のグループIDを指定
します。
(注1) (注2)
(注3) (注4)
省略値
指定範囲
iss_use
no
no
yes, no
iss_group
root(0)
root(0)
－
注1)
インストール時のセキュリティ設定として“強化セキュリティモード”を選択した場合、初期値は以下のように変更されています。
- 270 -
パラメタ名
初期値
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”を参
照)。
◆コード変換機能に関する動作環境
パラメタ名
初期値
意味
備考
省略値
指定範囲
undefined_char_conversion
single
single
single, multi,
fail
未定義文字をコード変換した場合の動作を設定します。
(注2)
・ single: デフォルト
すべての未定義文字は半角のアンダースコアに変換します。
(注1)
・ multi
半角の未定義文字は半角のアンダースコアに変換し、全角の
未定義文字は全角のアンダースコアに変換します。
・ fail
未定義文字の変換を行うとアプリケーションにシステム例外
DATA_CONVERSIONを通知します。
注1)
文字コードがUNICODEまたはUTF8の場合は、“multi”を指定した場合と同様に全角の未定義文字は全角のアンダースコアに変換
します。
注2)
クライアントおよびサーバの両方で設定してください。コード変換機能の詳細については“OLTPサーバ運用ガイド”の“コード変換”を
参照してください。
◆保守機能に関する動作環境
パラメタ名
初期値
意味
備考
省略値
指定範囲
access_log_policy
start
(初期値を推奨)
start
CORBAサービス起動時のアクセスログの採取/非採取の状
態。
・ start: 起動時からログ採取する
- 271 -
サーバ機能の
み有効
(注1)
パラメタ名
初期値
意味
備考
省略値
指定範囲
start, standby
access_log_size
3000000
・ standby: ログ採取しない
アクセスログファイルの最大サイズ。(バイト単位)
サーバ機能の
み有効
(注1)
アクセスログ採取レベルのキーワードを連結して指定。
(区切り文字はコロン(“:”)、空白は指定不可)
“all”を指定すると、すべての採取レベルを指定したものとみ
なされます。
サーバ機能の
み有効
(注1) (注2)
3000000
1～2147483647
(longの最大値)
access_log_level
send_stex:
recv_stex:
send_userex:
recv_userex:
close_resp_info
send_stex:
recv_stex:
send_userex:
recv_userex:
close_resp_info
－
error_log_policy
start
(初期値を推奨)
start
CORBAサービス起動時のエラーログの採取/非採取の状態。 (注1)
・ start: 起動時からログ採取する
・ standby: ログ採取しない
start, standby
error_log_size
3000000
エラーログファイルの最大サイズ。(バイト単位)
(注1)
CORBAサービス起動時のインフォメーションログの採取/非採
取の状態。
(注1)
3000000
1～2147483647
(longの最大値)
info_log_policy
info_log_size
start
(初期値を推奨)
start
・ start: 起動時からログ採取する
start, standby
・ standby: ログ採取しない
3000000
インフォメーションログファイルの最大サイズ。(バイト単位)
(注1)
内部ログの採取を指定。
(注3)
3000000
1～2147483647
(longの最大値)
logging
log_file_size
no
no
・ yes: 採取する
yes, no
・ no : 採取しない
10000000
-1
内部ログのファイルサイズの上限値。(バイト単位)
“logging = yes”とする場合、本パラメタは省略しないでくださ
い。
(注3)
CORBAサービス起動時のプロセスログの採取/非採取の状
態。
(注1)
4096～
2147483647
(longの最大値)
process_log_policy
start
(初期値を推奨)
- 272 -
パラメタ名
初期値
意味
備考
省略値
指定範囲
process_log_size
start
・ start: 起動時からログ採取する
start, standby
・ standby: ログ採取しない
3000000
プロセスログファイルの最大サイズ。(バイト単位)
(注1)
ログファイルの出力先を絶対パスで指定します。本パラメタで
指定したパスには、以下のログファイルが出力されます。
(注1) (注3) (注
4)
3000000
1～2147483647
(longの最大値)
log_file_path
－
－
－
・ アクセスログ
・ エラーログ
・ インフォメーションログ
・ プロセスログ
・ 内部ログ
本パラメタで指定したパスが存在しなかった場合、CORBA
サービスの起動に失敗します。
128バイトより長いパスは指定できません。128バイトより長いパ
スを指定した場合、無効となります。
また、空白および“=”を含むパスは指定できません。空白また
は“=”を含むパスを指定した場合、その直前までが有効となり
ます。
“\”と“/”は区別されず、共にフォルダの区切りとして使用され
ます。
snap_size
40000
スナップショットサイズの上限値。(バイト単位)
サーバ機能の
み有効
スナップショットの採取を指定。
サーバ機能の
み有効
40000
1024～
2147483647
(longの最大値)
(注5)
snap_use
trace_file_synch_level
yes
yes
・ yes: 採取する
yes, no
・ no : 採取しない
stop
stop
－
トレースファイルへの出力タイミングを指定。複数指定可能(セ
パレータは“&”)。
・ none:odformtraceコマンド実行時のみ出力。
・ exit:アプリケーション正常終了時、終了したアプリケーショ
ンのトレース情報を出力。
・ vanish:アプリケーション異常終了時、終了したアプリケー
ションのトレース情報を出力。
・ stop:CORBAサービス終了時、すべてのアプリケーション
のトレース情報を出力。
- 273 -
サーバ機能の
み有効
パラメタ名
初期値
意味
備考
省略値
指定範囲
・ loop: メ モ リ 上 に 採 取 さ れ た ト レ ー ス 情 報 の サ イ ズ が
trace_size_per_processを超えた場合に出力。
trace_size_per_process
プロセスごとのトレース情報サイズの最大値(バイト単位)。
10000
10000
サーバ機能の
み有効
1024～100000000
(注5)
trace_size_of_daemon
0
0
0, 1024～
100000000
trace_use
yes
(初期値を推奨)
yes
CORBAサービスのデーモンプロセスに対するトレース情報サ
イズの最大値(バイト単位)。
0を指定すると、“trace_size_per_process × 32”が設定されま
す。
なお、計算結果が100000000を超えた場合は100000000が設
定されます。
trace_size_per_processよりも小さな値を設定した場合は、
trace_size_per_processの値に補正されます。
トレース情報の採取を指定
サーバ機能の
み有効
・ yes: 採取する
・ no : 採取しない
yes, no
注1)
アクセスログ・プロセスログ・エラーログ・インフォメーションログは、“log_file_path”で指定したパスに採取されます。“log_file_path”を
指定しなかった場合は、以下のパスに採取されます。
また、ディスク領域として、以下のログファイルサイズの合計分が必要となります。
ログファイル格納パス
C:\Interstage\ODWIN\var 配下 (インストールパスはデフォルト)
/var/opt/FSUNod 配下 (インストールパスはデフォルト)
/var/opt/FJSVod 配下
ログファイル名とファイルサイズ
ログ名
ログファイル名
ログファイルサイズ
アクセスログ
accesslog
accesslog.old
access_log_size×2
プロセスログ
(サーバ用ライブラリ(ODSV.DLL,
libOM.so)をリンクしている場合)
proclog
proclog.old
process_log_size×2
プロセスログ
(クライアント用ライブラリ(ODWIN.DLL)を
リンクしている場合)
proclogcl
proclogcl.old
process_log_size×2
エラーログ
(サーバ用ライブラリ(ODSV.DLL,
libOM.so)をリンクしている場合)
errlog
errlog.old
error_log_size×2
- 274 -
ログ名
ログファイル名
ログファイルサイズ
エラーログ
(クライアント用ライブラリ(ODWIN.DLL)を
リンクしている場合)
errlogcl
errlogcl.old
error_log_size×2
インフォメーションログ
(サーバ用ライブラリ(ODSV.DLL,
libOM.so)をリンクしている場合)
infolog
infolog.old
info_log_size×2
インフォメーションログ
(クライアント用ライブラリ(ODWIN.DLL)を
リンクしている場合)
infologcl
infologcl.old
info_log_size×2
以下のログファイルを採取するためには、ログファイル格納パスに、管理者権限グループに対する書き込みのアクセス許可が必
要です。
－ アクセスログ
－ プロセスログ(サーバ用ライブラリをリンクしている場合)
－ エラーログ(サーバ用ライブラリをリンクしている場合)
－ インフォメーションログ(サーバ用ライブラリをリンクしている場合)
また、以下のログファイルを採取するためには、ログファイル格納パスに、クライアントアプリケーションを実行するユーザが所属し
ているグループに対する書き込みのアクセス許可が必要です。
－ プロセスログ(クライアント用ライブラリをリンクしている場合)
－ エラーログ(クライアント用ライブラリをリンクしている場合)
－ インフォメーションログ(クライアント用ライブラリをリンクしている場合)
上記のアクセス許可がない場合はログファイルの出力に失敗しますが、この際、特にエラーメッセージなどが表示されない場合が
あります。このため、ログファイルを採取する際には、運用前にログファイル格納パスのアクセス許可が正しく設定されているか確認
してください。
注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)
- 275 -
パス: /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では、初期値より大きい値は指定しないでください。
◆旧バーションの互換に関する動作環境
パラメタ名
初期値
意味
備考
省略値
指定範囲
msg_output_compatible
no
no
od10301,
od10605,
od10924,
od10925,
od10926,
od10941,
od11101,
od60003, no
以下のメッセージの出力有無を指定します。システムログに以下
のメッセージを出力する場合は、メッセージ番号を指定します。複
数指定する場合は、アンパサンド(&)で区切って指定します。以下
のメッセージを出力しない場合は、“no”を指定します。
・ od10301
・ od10605
・ od10924
・ od10925
・ od10926
・ od10941
・ od11101
・ od60003
A.2 gwconfig
■概要
gwconfigファイルは、HTTPトンネリング使用時に、Webサーバで起動されるHTTP-IIOPゲートウェイの動作環境を定義するファイルです。
CORBAサービスのタイムアウト監視に関連する項目を修正した場合に、同様の項目について定義を修正する必要があります。
なお、初期値から変更しない場合、gwconfigファイルは必要ありません。
■ファイル名
C:\Interstage\ODWIN\etc\gwconfig (インストールパスはデフォルト)
/etc/opt/FSUNod/gwconfig (インストールパスはデフォルト)
- 276 -
/etc/opt/FJSVod/gwconfig
■ファイル内情報
gwconfigファイルは、以下の形式で値を設定します。
◆形式:
パラメタ名 = 設定値
半角のシャープ(#)を行の先頭に指定した場合は、その行はコメントとして扱われます。また、空行は解析時に無視されます。
# コメント
◆記述例:
timeout_response=60
◆パラメタ:
設定値を変更することのできるパラメタを下表に示します。
パラメタ名
初期値
意味
指定範囲
timeout_response
360
0～
100000000
timeout_session
180
0～
214748364
7
timeout_connection
60
0～
214748364
7
logmode
5
1～5
リクエストの返信待ち時間
HTTP-IIOPゲートウェイにおける、リクエスト送信から返信までの待機時間(秒)。
この時間内にサーバメソッドから返信されないと、クライアントにタイムアウトが通知
されます。クライアント側で、CORBAサービスのperiod_receive_timeout(クライアン
ト側のリクエスト送信から返信までの待機時間。configファイルで定義)を変更した
場合、このパラメタは、period_receive_timeout値以下になるよう変更する必要があ
ります。0を指定するとタイムアウトを行いません。
セション保持時間(クライアント間無通信監視時間)
HTTP-IIOPゲートウェイにおける、クライアントの管理単位の保持時間(秒)。
サーバからの返信待ちがない状態で、この時間内にクライアントから新たなリクエス
ト送信がない場合には、クライアントの管理情報は破棄されます。0を指定するとタ
イムアウトを行いません。
コネクション保持時間(サーバ間無通信監視時間)
HTTP-IIOPゲートウェイにおける、無通信状態の監視時間。
サーバからの返信待ちがない状態で、この時間内にクライアントから新たなリクエス
ト送信がない場合には、サーバとのコネクションを切断します。0を指定するとタイム
アウトを行いません。
HTTP-IIOPゲートウェイの内部ログ採取の有無 (注)
以下から指定します。
・ 5:内部ログ情報を採取しません。
・ 3:リクエストデータおよびエラー発生時の情報を採取します。
・ 2:“3”で採取する情報に加えて、リプライデータおよび内部処理の情報を採取
します。
・ 1:“2”で採取する情報に加えて、トレース情報を採取します。
max_log_file_size
1048576
ログファイルサイズ(バイト単位)
- 277 -
パラメタ名
初期値
意味
指定範囲
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) (*は英数字)
/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組まで指定できます。
サービスの問い合わせは定義順に行われ、参照するサービスが存在しない場合は次行に定義されているホストに問い合わせを行います。
なお、ネーミングサービス・インタフェースリポジトリをローカルホスト上で動作させる場合は、ホスト名・ポート番号の設定は必要ありま
せん。
- 278 -
■ファイル名
C:\Interstage\ODWIN\etc\inithost (インストールパスはデフォルト)
Solarisサーバ:
/etc/opt/FSUNod/initial_hosts (インストールパスはデフォルト)
Windows(R)クライアント:
C:\Interstage\ODWIN\etc\inithost (インストールパスはデフォルト)
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
- 279 -
[自ホスト側]
/etc/hostsまたはNIS+など
[サーバ側]
サーバ側のホスト名定義
注2)
ホスト名に自ホストのホスト名やIPアドレスは指定しないでください。自ホスト名を指定した場合、サービスの問い合わせがループする
場合があります。
・ 定義情報の変更について
定義情報を変更した場合、次回の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 (インストールパスはデフォルト)
- 280 -
/etc/opt/FSUNod/queue_policy (インストールパスはデフォルト)
/etc/opt/FJSVod/queue_policy
■ファイル内情報
queue_policyには、[QUEUEGROUP]セクション、[QUEUE]セクション、[GUARANTY]セクションに分かれています。[QUEUEGROUP]
セクションおよび[QUEUE]セクションは、odsetqueコマンドで更新します。
[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以上の値
- 281 -
・ 定義情報を変更した場合、次回のCORBAサービス起動時より有効となります。
・ odsetqueコマンドで登録した際、[GUARANTY]にはキュー情報が追加されません。キューの上限値を設定する場合、新たに定義
を追加する必要があります。
A.5 nsconfig
■概要
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
◆パラメタ:
設定値を変更することのできるパラメタを下表に示します。なお、指定が必須となるパラメタはありません。
- 282 -
パラメタ名
初期値
意味
指定範囲
file_sync
yes
yes, no
ネーミングサービスのデータベースへの更新処理でファイルの同期書き込みを行
うかを設定します。
・ yes: ファイルの同期書き込みを行う。
・ no : ファイルの同期書き込みを行わない。
初期創成などの大量データの更新時に、このパラメタをnoにすることにより処理を
高速化することができます。ネーミングサービスの運用中には、信頼性を向上させ
るため、本パラメタはyesにしてください。
trace_level
update
update, all
メソッド実行の自動トレースを採取するトレースレベルを指定します。
・ update: 更新ログだけを採取する。
・ all: すべてのトレースを採取する。
bl_how_many
65536
0～65536
ogl_how_many
256(初期
値を推奨)
128～256
ext_intf
yes
yes, no
NamingContext::list, BindingIterator::next_nで返されるバインディング数の最大値
を指定します。
ロードバランスオブジェクトグループのリストの最大値を指定します。
注) ネーミングサービスでは、ロードバランスオブジェクトグループのリストを作成す
る際、本パラメタの設定値によりメモリを獲得します。使用するメモリ容量に影響が
発生するため、メモリ容量を考慮して必要最小限の値を設定してください。
ネーミングサービスの拡張機能を使用するかを指定します。
・ yes: ネーミングサービスの拡張機能を使用する。
・ no : ネーミングサービスの拡張機能を使用しない。
noを指定すると、ネーミングコンテキスト拡張インタフェース(NamingContextExtイ
ンタフェース)を使用できません。V2.X以前のクライアントアプリケーションを動作さ
せる場合は、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
- 283 -
■概要
irconfigファイルは、インタフェースリポジトリのバックアップやログ情報などの動作環境を設定するファイルです。
■ファイル名
C:\Interstage\ODWIN\etc\irconfig (インストールパスはデフォルト)
/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 =
◆パラメタ:
設定値を変更することのできるパラメタを下表に示します。なお、指定が必須となるパラメタはありません。
パラメタ名
初期値
意味
指定範囲
auto backup
no
yes, no
インタフェースリポジトリ起動時に自動的にバックアップを行うかを指定します。
・ yes: 自動的にバックアップを行う。
・ no : 自動的にバックアップを行わない。
注）バックアップは、インタフェースリポジトリ起動時に1回だけ行います。
auto backup
path
auto
recovery
－
－
no
yes, no
バックアップデータの格納場所を指定します。auto backup=yesと指定した場合、必
ずパスを指定する必要があります。パスを指定しないとバックアップは行われません。
注）格納場所には、作成したデータベースサイズ以上の空き領域が必要です。
トランザクション処理中のシステムダウンなどによりデータベースの異常を検出した
場合に、バックアップデータを元に自動的にリカバリを行うかを指定します。
- 284 -
パラメタ名
初期値
意味
指定範囲
・ yes: 自動的にリカバリを行う。
・ no : 自動的にリカバリを行わない。
注）本機能を使用する場合は“auto backup=yes”と指定し、auto backup pathを指定
する必要があります。
ir_timeout
1800(秒)
0～
100000000(秒)
no
yes, no
iss_use
IDLコンパイル(IDLc)およびインタフェース情報移入(odimportir)において、インタ
フェースリポジトリへのリクエストの復帰までの待機時間を指定します。0を指定す
ると、リクエスト復帰までの待機時間は監視されません。
資源保護機能の有効/無効を指定します。
・ yes: 資源保護機能を有効とする。
・ no : 資源保護機能を無効とする。
“yes”を指定すると、インタフェースリポジトリはデータベース管理者(デフォルト：
root)のみが運用可能となります。
注）インストール時のセキュリティ設定として“強化セキュリティモード”を選択した場
合、初期値は“yes”になります。
logging
no
yes, no
トラブル発生時にログ情報を採取するかを指定します。
・ yes : ログ情報を採取する。
・ no : ログ情報を採取しない。
採取したログは、irlogdumpコマンドによりファイルに出力できます。通常は、初期
値(no)で運用します。
logging
memory size
512(KB)
logfile path
－
1～4096(KB)
－
－
select cache
obj
－
sync
no
yes, no
ログ情報を格納する共用メモリのサイズを指定します。logging=noとした場合、この
値は意味を持ちません。
“logging=yes”とした場合、irlogdumpコマンドにより出力されるログ情報の格納ディ
レクトリをフルパスで指定します。パスを指定しない場合は、CORBAサービスの動
作ディレクトリと同一のディレクトリに格納されます(“A.1 config”参照)。
“logging=no”と指定した場合、この値は意味を持ちません。
インタフェースリポジトリ起動時にキャッシュ対象とするオブジェクトを指定します。
キャッシュ対象オブジェクトは、テキストファイル内にキャッシュ対象オブジェクトの
リポジトリIDを記述し、そのファイル名をフルパスで指定します。
ファイル名が指定されない場合は、全登録オブジェクトがキャッシュ対象となります。
ファイルの作成例および注意事項については、以下のキャッシュ対象オブジェク
トの指定方法を参照してください。
同期モードを指定します。
yes:同期モードを指定します。
no:同期モードを指定しません。
“no”を指定すると、データベースへの書き込みと同期しないモードで動作するた
め、インタフェースリポジトリ更新処理のスループットが向上します。ただし、更新中
のシステムダウンなどで発生するデータベース破壊を認識できない場合があります。
“yes”を指定すると、トランザクション単位での書き込みを保証するため、同期モー
ドで動作します。信頼性が要求されるシステムを構築する場合に設定します(デー
タベース破壊の認識可)。
同期モードを指定した場合、指定しない場合に比べて更新処理のスループットは
低下します。このとき、クライアントへのサーバメソッドの復帰時間が長くなるため、
タイムアウトが発生する可能性があります。これを防ぐには、“A.1 config”の
period_receive_timeout値をチューニングしてください。
- 285 -
◆キャッシュ対象オブジェクトの指定方法
インタフェースリポジトリ起動時、キャッシュ対象オブジェクトを限定することにより、インタフェースリポジトリに大量のオブジェクトが登
録されている場合の起動性能を改善することができます。
ただし、キャッシュ対象オブジェクトを指定した場合は、キャッシュ対象としないオブジェクトに対する参照性能は低下するため、運用
に関しては注意が必要です。
また、キャッシュ対象オブジェクトを指定してインタフェースリポジトリを起動した場合は、以後、インタフェースリポジトリに対する登録/
更新(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）で実行
する必要があります。
- 286 -
付録B コンポーネントトランザクションサービスの環境定義
本定義は以下の製品でだけサポートしています。
・ Interstage Application Server Enterprise Edition
コンポーネントトランザクションサービスの環境定義ファイルについて説明します。本定義ファイルは、以下に格納されます。
格納パス
C:\Interstage\etc\sysdef
/var/opt/FSUNtd/etc/sysdef
/var/opt/FJSVtd/etc/sysdef
本定義ファイルは、コンポーネントトランザクションサービスが停止している時に、変更可能です。
コンポーネントトランザクションサービスの環境定義の記述形式と制御文について説明します。
備考
万一のため、運用環境を構築したら資源のバックアップを行うことを推奨します。
バックアップについては、“運用ガイド(基本編)”の“メンテナンス(資源のバックアップ/他サーバへの資源移行/ホスト情報の変更)”を
参照してください。
B.1 記述形式
通常ファイル記述形式は、以下の構文により構成されます。なお、通常ファイルの記述形式に誤りがあった場合、構文エラーとなりま
す。構文エラー時には、そのファイルに記述されているすべての内容が無効となります。
・ ステートメント
・ セクション
・ コメント行
・ 空行
B.1.1 ステートメント
ステートメントとは、情報を設定するための行であり、以下の形式で記述します。
キーワード: 設定内容(\n)
ステートメントは、キーワード、“:”(コロン)、および設定内容から構成されています。
ステートメントの記述規則を以下に示します。
・ ステートメントを省略する場合、対象ステートメントを削除するか、設定内容だけ省略します。
・ ステートメントを記述している行にコメントは記述できません。
ステートメントを構成する情報の詳細を以下に説明します。
■キーワード
固有のキーワードを設定します。キーワードには、以下の規則があります。
・ キーワードは対象行の先頭の英数字から“:”(コロン)の直前までを意味します。
・ キーワードには英数字で始まる英数字とスペースで構成されている文字列を指定できます。
- 287 -
・ キーワード中に指定されている英字の大文字/小文字の区別はしません。
・ キーワード中にスペースを含むことができます。
・ キーワード中に連続したスペースが指定された場合、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)
- 288 -
# キーワードと設定内容が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)
また、登録されていないセクション名を指定した場合も構文エラーとなります。
- 289 -
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:
インタフェース情報チェック機能使用の
有無
[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:
インタフェース情報チェック機能使用の
有無
IP version:
使用するネットワークのバージョン
[SYSTEM ENVIRONMENT]
- 290 -
System Scale:
システムの規模
Using Session Information Management Object:
SMOの使用の有無
Name of Session Information Management Object:
SMOのオブジェクト名
Number of Communication Buffer:
トランザクションアプリケーションの通信
バッファ数
Using Interface Check:
インタフェース情報チェック機能使用の
有無
◆設定内容
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回の通信データ長×同時接続クライアント数を計算し、その値をもとに通信バッファ数を見積もってください。
通信バッファは、十分なサイズを用意してください。
なお、システムスケールにより、以下の省略値が設定されます。
- 291 -
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ステートメントはペアで指定します。
- 292 -
・ 複数のDPCF通信パスに対して負荷抑制を行う場合には、複数の[WRAPPER]セクションにPSYS NameステートメントとNumber of
Maximum Sessionステートメントをペアで指定します。
・ Number of Maximum Sessionステートメントに指定する値は、IDCMネットワーク定義で指定した優先会話コネクション数以下の値
を指定してください。優先会話コネクション数より大きな値を指定した場合、負荷抑制されないことがあります。
IDCMネットワーク定義の詳細は、以下を参照してください。
IDCMヘルプ
IDCM使用手引書
- 293 -
付録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 (注)
- 294 -
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 (注)
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\JDK5\bin\java.exe....(Windows(R)の場合)
PATH=/opt/FJSVawjbk/jdk5/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のバージョン
- 295 -
キー
意味
JTS_VERSION
JTSのバージョン
JAVA_VERSION
JDK/JREのバージョン
PATH
JDK/JREのパス
TRACE_MODE
トレースの出力形式
TRACE_LEVEL
トレースの出力レベル
◆キー詳細
OBSERVE_CYCLE_TIME:監視周期の指定
OTSシステムが監視を実施する周期（秒単位）を指定します。以下の点に注意して設定してください。
－ 本値に小さい値を設定すると、頻繁に監視が行われるため、システムのパフォーマンスが低下します。
－ 本値に大きい値を設定すると、監視の間隔が長くなるため、異常の検出が遅くなります。
指定可能な範囲は、1～60です。省略値は、5です。
TRAN_TIME_OUT:トランザクションタイムアウト検出時間の指定
データベース連携サービスがトランザクションタイムアウト（beginからcommitまで）を検出する時間（秒単位）を指定します。アプリ
ケーションにおいてset_timeoutメソッドでタイムアウト時間を設定した場合は、アプリケーションの設定が有効となります。
指定可能な範囲は、1～2147483647です。省略値は、300です。
2PC_TIME_OUT:フェーズ間タイムアウト検出時間の指定
OTSシステムがトランザクションの2PC（2フェーズコミット）で、リソース管理プログラムにおいて1フェーズと2フェーズ間のタイムアウ
トを検出する時間（秒単位）を指定します。
指定可能な範囲は、1～2147483647です。省略値は、60です。
注意
CORBA サ ー ビ ス の ク ラ イ ア ン ト 側 の 無 通 信 監 視 時 間 （ CORBA サ ー ビ ス の 動 作 環 境 フ ァ イ ル の パ ラ メ タ
“period_client_idle_con_timeout”の設定値×5）が“0”ではない場合、本値にはこの値よりも小さい値を設定してください。
COM_RETRY_TIME:トランザクション処理エラー時のリトライ間隔指定
トランザクション処理で通信異常などのエラーが発生した場合に、その通信をリトライする間隔（秒単位）を指定します。
指定可能な範囲は、1～600です。省略値は、2です。
COM_RETRY_MAX:トランザクション処理リトライ上限回数の指定
トランザクション処理で通信異常などのエラーが発生した場合に、その通信をリトライする上限回数を指定します。
指定可能な範囲は、1～2147483647です。省略値は、3です。
RECOVER_RETRY_TIME:OTSシステムリカバリ処理リトライ間隔指定
OTSシステムのリカバリ処理で通信異常などのエラーが発生した場合に、その通信をリトライする間隔（秒単位）を指定します。
指定可能な範囲は、1～600です。省略値は、30です。
- 296 -
RECOVER_RETRY_MAX:OTSシステムリカバリ処理リトライ上限回数の指定
OTSシステムのリカバリ処理で通信異常などのエラーが発生した場合に、その通信をリトライする上限回数を指定します。
指定可能な範囲は、1～2147483647です。省略値は、60です。
RESOURCE_TRANMAX:1リソース管理プログラムのトランザクションの最大多重度
1リソース管理プログラムのトランザクションの最大多重度を指定します。
指定可能な範囲は、1～2147483647です。省略値は、5です。
ポイント
OTSシステムのスレッド多重度と1リソース管理プログラムのトランザクションの最大多重度は、以下の関係を保つように設定してくだ
さい。
OTSシステムのスレッド多重度 ＝＜ 1リソース管理プログラムのトランザクションの最大多重度
OTS_TRACE_SIZE:OTSシステムのトレースログサイズ指定
OTSシステムのトレースログサイズ（Kバイト単位）を指定します。
指定可能な範囲は、128～2147483647です。省略値は、4096（Kバイト）です。
RESOURCE_TRACE_SIZE:リソース管理プログラムのトレースログサイズ指定
リソース管理プログラムのトレースログサイズ（Kバイト単位）を指定します。
指定可能な範囲は、128～2147483647です。省略値は、4096（Kバイト）です。
RECOVERY_TRACE_SIZE:リカバリプロセスのトレースログサイズ指定
リカバリプロセスのトレースログサイズ（Kバイト単位）を指定します。
指定可能な範囲は、128～2147483647です。省略値は、4096（Kバイト）です。
OBSERVE_TRACE_SIZE:監視プロセスのトレースログサイズ指定
監視プロセスのトレースログサイズ（Kバイト単位）を指定します。
指定可能な範囲は、128～2147483647です。省略値は、4096です。
DATABASE_RETRY_TIME:データベースシステムアクセスのリトライ間隔指定
OTSシステムでのデータベースシステムへのアクセス時に、メモリ資源不足などのリトライ可能なエラーが発生した場合のリトライ間
隔（秒単位）を指定します。
指定可能な範囲は、1～600です。省略値は、5です。
DATABASE_RETRY_MAX:データベースシステムアクセスのリトライ上限回数指定
OTSシステムでのデータベースシステムへのアクセス時に、メモリ資源不足などのリトライ可能なエラーが発生した場合にリトライす
る上限回数を指定します。
指定可能な範囲は、1～2147483647です。省略値は、5です。
MEM_RETRY_TIME:OTSシステム処理中のエラーでのリトライ間隔指定
OTSシステムの処理中に、メモリ資源不足などのリトライ可能なエラーが発生した場合のリトライ間隔（秒単位）を指定します。
指定可能な範囲は、1～600です。省略値は、5です。
- 297 -
MEM_RETRY_MAX:OTSシステム処理中のエラーでのリトライ上限回数指定
OTSシステムの処理中に、メモリ資源不足などのリトライ可能なエラーが発生した場合にリトライする上限回数を指定します。
指定可能な範囲は、1～2147483647です。省略値は、5です。
RSCSTOP_CHECK_COUNT:通常停止からのトランザクション待合せ回数指定
トランザクション処理中にリソース管理プログラムを通常停止し、トランザクション完了をOBSERVE_CYCLE_TIMEの監視同期に合
わせた待合せ回数を指定します。
OBSERVE_CYCLE_TIME × RSCSTOP_CHECK_COUNT秒間、トランザクションの完了を待ち合わせ、時間内に完了しない場
合は、リソース管理プログラムの停止を通常停止から強制停止に切り替えます。
指定可能な範囲は、1～2147483647です。省略値は、100です。
OTS_VERSION:OTSのバージョン
OTSのバージョンを指定します。通常、変更しないでください。
省略値は、5です。
JTS_VERSION:JTSのバージョン
JTSのバージョンです。通常、変更しないでください。
省略値は、5です。
JAVA_VERSION:JDK/JREのバージョン
JTS用リソース管理プログラムが利用するJavaのバージョンです。14を指定します。
省略値は、14です。
PATH:JDK/JREのパス
JTS用リソース管理プログラムが利用するjavaコマンドへのパスをフルパスで指定します。java実行体を含めるパスを指定してください。
初期値は、JDK/JRE 5.0のバージョンに対応したパスです。通常、変更しないでください。
注意
－ JTS用のリソース管理プログラムを利用する場合は、必ず指定してください。
－ Interstage Application Serverに同梱されているJDK/JREのパスを指定してください。
TRACE_MODE:トレースの出力形式
JTSを利用した環境で出力されるトレースの出力形式を、以下から選択して指定します。
－ 異常発生時に、OTSのインストールパス/var配下にトレースファイルを出力する場合：“1”
注）通常、“1”を選択してください。
－ システムの状態に関係なく、常時、OTSのインストールパス/var配下にトレースファイルを出力する場合：“2”
注）常時出力されるため、ファイルサイズに注意してください。
－ トレースファイルを出力しない場合：“3”
TRACE_LEVEL:トレースの出力レベル
JTSを利用した環境で出力されるトレースのモードを、“1”から“5”までの数値で指定します。数値が大きいほど、詳細なトレース情
報を出力します。
通常運用時は、“1”が指定されます。パフォーマンスに影響があるため、通常、変更しないでください。
- 298 -
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”に相当します。
“RMP”を設定する場合、リソース管理プログラムを正しく動作させるために、OTSシステムが動作するホストのネーミングサービスを参
照する必要があります。以下のどちらかの方法でセットアップを行ってください。
・ “RMP”を設定すると同時に、OTSシステムが動作しているホストの“HOST”／“PORT”／“LOCALE”を指定してセットアップを行
います。この場合、ネーミングサービスはOTSシステムではなく、“RMP”を設定したホストのネーミングサービスが利用されます。
“RMP”を設定したホストとOTSシステムが動作するホストのネーミングサービスをそれぞれ独立させて運用させることが可能となり
ます。
- 299 -
・ 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
2
107MB
3
9656MB
終了
107MB
9656MB
10.7GB
サイズ タイプ
107MB
プライマリ
9550MB プライマリ
1078MB プライマリ
ファイルシステム
ext3
(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
- 300 -
フラグ
boot
lvm
lvm
:
番号
1
2
8
開始
1049kB
211MB
:
77.5GB
終了
211MB
32.4GB
サイズ
210MB
32.2GB
タイプ
primary
primary
78.5GB
974MB
logical
ファイルシステム
ext4
ext4
フラグ
boot
(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です。
設定可能な範囲は、1～1024です。
Interstage動作環境定義ファイルの“OTS maximum Transaction”に相当します。
C.2.4 PARTICIPATE: 1トランザクションに参加するリソース数
1トランザクションに参加するリソースの最大数を指定します。
MODEに“SYS”を設定した場合に有効となります。
設定可能な範囲は、2～32です。省略値は、4です。
Interstage動作環境定義ファイルの“OTS Participate”に相当します。
- 301 -
C.2.5 OTS_FACT_THR_CONC: OTSシステムのスレッド多重度
OTS シ ス テ ム の ス レ ッ ド 多 重 数 を 指 定 し ま す 。 指 定 し た 数 だ け 、 begin/commit/rollback な ど の Current イ ン タ フ ェ ー ス 、 お よ び
UserTransactionインタフェースを同時に動作させることが可能となります。
MODEに“SYS”を設定した場合に有効となります。
設定可能な範囲は、1～31です。省略値は、5です。
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: リカバリプロセスのスレッド多重度
リカバリプログラムのスレッド多重数を指定します。指定した数だけ、リカバリ処理を同時に動作させることが可能となります。
MODEに“SYS”を設定した場合に有効となります。
設定可能な範囲は、1～2147483647です。省略値は、2です。
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が設定されます。
ポイント
リソース管理プログラムの多重度は、トランザクション処理性能を最大限に引き出すようにチューニングされているため、省略値から変
更する必要はありません。
変更する場合は、OTSシステムのスレッド多重度とリソース管理プログラムの多重度の関係を以下のように設定してください。
OTSシステムのスレッド多重度 ＝＜ リソース管理プログラムの多重度(注)
注）JTS用リソース管理プログラムにおける多重度は、以下の算出式で見積もってください。
JTS用のリソース管理プログラムのプロセス多重度（JTS_RMP_PROC_CONC） ×
JTS用のリソース管理プログラムのスレッド多重度（JTS_RMP_THR_CONC）
- 302 -
C.2.8 JTS_RMP_THR_CONC: JTS用のリソース管理プログラムのスレッド多重度
JTS用のリソース管理プログラムのスレッド多重度を指定します。
設定可能な値は、1～2147483647です。省略値は、16です。
通常、変更する必要はありません。
Interstage動作環境定義ファイルの“OTS JTS's RMP Multiple degree of Thread”に相当します。
ポイント
リソース管理プログラムの多重度は、トランザクション処理性能を最大限に引き出すようにチューニングされているため、省略値から変
更する必要はありません。
変更する場合は、OTSシステムのスレッド多重度とリソース管理プログラムの多重度の関係を以下のように設定してください。
OTSシステムのスレッド多重度 ＝＜ リソース管理プログラムの多重度(注)
注）JTS用リソース管理プログラムにおける多重度は、以下の算出式で見積もってください。
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”を設定した場合に有効となります。
設定可能な範囲は、1024～65535です。
本ステートメントは、省略可能です。設定する場合は、HOSTを同時に設定する必要があります。
本ステートメントの利用方法については、MODEを参照してください。
Interstage動作環境定義ファイルの“OTS Port”に相当します。
注意
isinitコマンドに“type3”を指定してInterstageを初期化した場合は、使用しないでください。
C.3 RMPプロパティ
■概要
JTS用リソース管理プログラムに対するプロパティファイルです。
RMPプロパティは、Javaのプロパティリストの形式で、その他のキーを設定することもできます。設定されたキーと値は、JTS用リソース
管理プログラムが動作するJavaVMのシステムプロパティに反映されます。
- 303 -
■ファイル名
RMPプロパティファイルは、インストール時に、以下に格納されます。
C:\Interstage\ots\etc\RMP.properties
/opt/FSUNots/etc/RMP.properties
/opt/FJSVots/etc/RMP.properties
注意
本製品のインストールパスがデフォルトの場合のパスです。
■ファイル内情報
◆形式:
パラメタ名=設定値
◆パラメタ
RecoveryTarget: リカバリ対象
JTS用のリソース管理プログラムの起動時にリカバリを行う対象をリソース定義名で指定します。リカバリ対象が設定されていない場合、
リカバリ対象が複数の場合は、空白で区切って指定してください。
ポイント
RecoveryTargetを省略した場合でも、登録済みリソースに対してリカバリ処理を行います。
例
リカバリ対象が3つの場合
RecoveryTarget=Oracle_resource1 Oracle_resource2 Oracle_resource3
JavaPath: Javaコマンドへのパス
必要な場合に、記述を追加します。通常、指定しないでください。指定した場合、動作の保証はできません。
JavaCommandOption: Javaコマンドに受け渡すオプション
必要な場合に、記述を追加します。通常、指定しないでください。指定した場合、動作の保証はできません。
- 304 -
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 リソース定義ファイル
■概要
OTS／JTSが連携するリソース（データベース、リソースアダプタなど）に接続するための情報を定義するファイルです。otssetrscコマン
ドを利用して、リソース単位に登録します。
■ファイル内情報
◆形式:
キー名=設定値
◆設定例
OTS用リソース定義ファイル
# 環境変数
ENVIRON ORACLE_SID=orac
ENVIRON ORACLE_HOME=/opt/oracle.............(Solaris/Linuxの場合)
- 305 -
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で大文字／小文字が異なりますが、同じ意味を持ちます。
◆キー一覧
意味
キー(JTS)
キー(OTS)
ENVIRON
－
環境変数の設定
NAME
name
リソース定義名
RMNAME
－
リソースマネージャ名
OPENINFO
－
オープン文字列
CLOSEINFO
－
クローズ文字列
THREADS
－
スレッドモード
OTS_RMP_PROC_CONC
－
OTS用のリソース管理プログラムの多重度
RSCTYPE
rscType
リソース定義ファイルの種類
－
type
リソースの種類
－
lookupName
リソースの検索名
－
initialContextFactory
initialContextFactory名
－
providerURL
プロバイダURL
USER
－
ユーザ名
－
user
ユーザ名
－
password
パスワード
GROUP
－
グループ名
－
logfileDir
リソースのログファイル格納ディレクトリ
- 306 -
◆キー詳細
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”
－
MQDの場合：“XA_MQD”
OPENINFO: オープン文字列(OTS)
open_dataに、データベースのベンダが公開する、データベースをオープンする場合に必要なopen文字列を、256文字以内の文字
列で指定します。
指定する内容については、各データベースのマニュアルを参照してください。
注意
－ OPENINFOに指定するユーザ名は、各データベースに対するアクセス権限がないと、リソース管理プログラムの起動に失敗し
ます。必要な権限については、各データベースのマニュアルを参照してください。
－
プロセスモード／スレッドモードのタイプが、リソース管理プログラム作成時と動作時（リソース定義ファイル内のスレッド指定）と
で異なる場合、リソース管理プログラムの起動が誤動作する可能性があります。必ずタイプをあわせて運用してください。
- 307 -
CLOSEINFO: クローズ文字列(OTS)
close_dataに、データベースのベンダが公開する、データベースをクローズする場合に必要なclose文字列を、256文字以内の文字
列で指定します。
指定する内容については、各データベースのマニュアルを参照してください。
THREADS: スレッドモード(OTS)
リソース管理プログラムのモードを以下から選択して指定します。
－ プロセスモードの場合：“FALSE”（省略時）
－ スレッドモードの場合：“TRUE”
OTS_RMP_PROC_CONC: OTS用のリソース管理プログラムの多重度(OTS)
OTS用のリソース管理プログラムの多重数を指定します。通常、変更する必要はありません。
指定可能な範囲は、1～31です。省略値は、5です。
最大値を超えた場合は、警告メッセージ“ots9017”を出力し、31を自動的に設定します。
注意
リソース管理プログラムの多重度は、トランザクション処理性能を最大限に引き出すようにチューニングされているため、省略値から
変更する必要はありません。
変更する場合は、OTSシステムのスレッド多重度とリソース管理プログラムの多重度の関係を以下のように設定してください。
OTSシステムのスレッド多重度 ＝＜ リソース管理プログラムの多重度
RSCTYPE、rscType: リソース定義ファイルの種類(OTS、JTS)
リソース定義ファイルの種別を以下から選択して指定します。
－ OTSを利用する場合：“OTS”（省略時）
－ 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を利用してデータベースと接続する場合は、必ず指定してください。
- 308 -
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”と同時に指定する必要があります。
強化セキュリティモードの場合、本設定は無効となり、強化セキュリティモード設定時に指定したグループ名が有効となります。
logfileDir: リソースのログファイル格納ディレクトリ(JTS)
接続したリソースのトラブルを調査する場合は、トレースログを採取するディレクトリを指定してください。ディレクトリ名の最後に、セ
パレータを付加しないでください。
通常、指定しません。
C.5 OTSシステム用業務システム情報定義ファイル
■概要
トランザクションサービスがSystemwalker Resource Coordinatorと連携して動的ダウンリカバリを実現するためのOTSシステム用業務シ
ステム情報定義ファイルです。
■ファイル内情報
◆形式:
キー名=設定値
◆パラメタ
factory_quemode: トランザクション処理閉塞の動作(OTS、JTS)
トランザクションサービスのトランザクション処理閉塞の動作を、以下から選択して指定します。
－ トランザクション開始処理を受け付けず、トランザクション開始要求をエラーとする場合：“que”
- 309 -
－ トランザクション開始処理を受け付け、トランザクション処理を待ち状態とする場合：“dsp”
C.6 アプリケーション用業務システム情報定義ファイル
■概要
トランザクションサービスがSystemwalker Resource Coordinatorと連携して動的ダウンリカバリを実現するためのアプリケーション用業務
システム情報定義ファイルです。
■ファイル内情報
◆形式:
キー名=設定値
◆パラメタ
resource: リソース管理プログラムの情報(OTS)
対象となる業務で使用しているリソース管理プログラムのフルパスとリソース定義名を、カンマ(,)で区切って指定します。
注意
－ リソース管理プログラムのフルパスは、必ずダブルクォーテーション("")で囲んでください。
－ 複数指定する場合は、複数行で指定してください。
workUnit: ワークユニットの情報(OTS、JTS)
対象となる業務のワークユニット名を指定します。
ポイント
複数指定する場合は、カンマ(,)で区切ります。複数行で指定することもできます。
- 310 -
付録D イベントサービスの環境定義
イベントサービスの動作環境ファイル、およびイベントチャネル・サプライヤ・コンシューマ総数の見積もり方法について説明します。
イベントサービスの動作環境ファイルは、以下に格納されます。
格納パス
C:\Interstage\eswin\etc (インストールパスはデフォルト)
/etc/opt/FJSVes (インストールパスはデフォルト)
/etc/opt/FJSVes
ファイル
traceconfig
上記以外のファイルは、イベントサービスの動作環境としてカスタマイズできません。エディタなどで編集しないでください。
本ファイルは以下の製品で使用することができます。
・ Interstage Application Server Enterprise Edition
・ Interstage Application Server Standard-J Edition
D.1 traceconfig
■概要
traceconfigファイルは、イベントサービスのトレース動作環境に関する定義が格納されたファイルです。
■ファイル名
C:\Interstage\eswin\etc\traceconfig (インストールパスはデフォルト)
/etc/opt/FJSVes/traceconfig (インストールパスはデフォルト)
/etc/opt/FJSVes/traceconfig
■ファイル内情報
traceconfigファイルは、以下の形式で値を設定します。
- 311 -
◆形式:
パラメタ名 = 設定値
◆パラメタ:
以下の動作環境について、パラメタ設定値を変更することができます。
パラメタ値を変更した場合、次回のイベントサービス起動時より有効となります。
パラメタ名
初期値
意味
省略値
指定範囲
trace_size
1024
512
トレース情報の採取に使用するバッファのサイズをキロバイト単位
で指定します。 (注1)
512～102400
trace_file_number
50
採取するトレース情報ファイルの最大数を指定します。トレース情
報ファイルの数が指定値を超えた場合は、古いトレース情報ファイ
ルに上書きします。
10
50
10
50～1000
10～1000
trace_auto
yes
トレース情報の自動採取を有効にするかを指定します。
yes
・ yes: トレース情報の自動採取を有効とする。 (注2)
yes, no
・ no : トレース情報の自動採取を無効とする。
process
trace_buffer
内部トレースを採取する単位を指定します。
process
・ process: プロセス単位で内部トレースを採取する。
process, system
・ system: イベントサービス単位で内部トレースを採取する。
注1)
トレース情報の出力サイズはチャネル数、コンシューマ数、サプライヤ数、および通信頻度によって異なります。起動処理系、通信処
理系、および停止処理系で使用するトレース情報のバッファサイズを以下に記載します。
- 312 -
プロセス単位で内部トレースを採取する(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)場合
－ イベントサービスのデーモンプロセスのログ情報
/var/opt/FJSVes/ESLOGDUMPDAEMONXXX
－ イベントファクトリプロセスのログ情報
/var/opt/FJSVes/ESLOGDUMPFACTORYXXX
- 313 -
－ 静的イベントチャネルプロセスのログ情報
/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
- 314 -
付録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”です。
- 315 -
ポイント
クライアントから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)の構成図を以下に示します。
- 316 -
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ディレクティブで指定した値で動作します。
本値を大きくすることにより同時アクセス可能な数は多くなりますが、メモリ資源や一時ファイルなどの消費に伴いシステム全体の性能
が劣化する可能性があります。
クライアントの同時接続数の初期値は“50”、省略値は“256”です。
なお、この設定値を超過するクライアントの接続要求があった場合は、リクエスト処理待ちキューに保存されます。リクエスト処理待ち
キュー数は、ListenBacklogディレクティブで設定します。
ServerLimit 通信プロセスの上限数
MaxClientsディレクティブに設定するクライアントの同時接続数の上限値を設定します。1から20000までを指定できます。1より小さな値
を指定した場合は、1で動作します。20000より大きな値を指定した場合は、20000で動作します。
本ディレクティブは、MaxClientsディレクティブに256よりも大きな値に設定する必要がある場合にだけ使用してください。
通信プロセスの上限数の初期値は、ありません。省略値は“256”です。
ListenBacklog リクエスト処理待ちキューの最大数
ThreadsPerChildディレクティブで設定したクライアントの同時接続数よりも多くの接続要求があった場合に、本ディレクティブの設定値
がオペレーティングシステム内にキューイングされる数の最大値となります。最大数には、1から200までを指定できます。
リクエスト処理待ちキューの最大数の省略値は、“200”です。
- 317 -
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
- 318 -
付録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
- 319 -
F.2 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)
想定する同時アクセス最大数500ユーザを、5台の認証サーバにて負荷分散するシステムにおける認証サーバ1台あたりのチュー
ニング
Interstage HTTP Server
ThreadsPerChild＝100＋α(注1)
Timeout＝600(注2)
Interstage HTTP Server
MaxClients＝100＋α(注1)
Timeout＝600(注2)
注1) システムを安定稼動させるため、αには10～100までの値を設定してください。
注2) 接続しているネットワークのトラフィックが増大し、接続が頻繁に中断される場合には、本時間を増やしてください。
F.3 1台のサーバにリポジトリサーバと認証サーバを構築する場合のチュー
ニング
1台のサーバに、リポジトリサーバと認証サーバを構築する場合のチューニングについて説明します。
- 320 -
■Webサーバ(Interstage HTTP Server)のチューニング
リポジトリサーバ、および認証サーバのチューニングは、Webサーバ(Interstage HTTP Server)の環境定義を変更することにより行います。
詳細については、“付録E Interstage HTTP Serverの環境定義”を参照してください。
クライアントの同時接続数
以下のディレクティブに、想定する同時アクセス最大数×2以上を設定します。(初期値:50)
ThreadsPerChild
MaxClients
クライアント送受信タイムアウト時間
Timeoutにクライアントとの間でデータパケットを送受信するときに待機する最長の時間(秒)を指定します。(初期値:600)
◆チューニングの例
想定する同時アクセス最大数が256ユーザのシステムの場合
Interstage HTTP Server
ThreadsPerChild＝256×2＋α(注1)
Timeout＝600(注2)
Interstage HTTP Server
MaxClients＝256×2＋α(注1)
Timeout＝600(注2)
注1) システムを安定稼動させるため、αには10～100までの値を設定してください。
注2) 接続しているネットワークのトラフィックが増大し、接続が頻繁に中断される場合には、本時間を増やしてください。
■TCP/IPパラメタのチューニング
セション管理の運用を行う場合は、リポジトリサーバ(更新系)のマシンのTCP/IPパラメタのチューニングを行います。(注)
詳細については、“3.4 TCP/IPパラメタのチューニング”を参照してください。
注) リポジトリサーバ(更新系)への同時アクセス最大数が増大し、セション管理サーバとの通信に失敗し、以下のメッセージが出力さ
れる場合があります。この場合には、TCP/IPパラメタのチューニングを行ってください。
・ sso00114
・ sso00119
F.4 業務サーバを構築する場合のチューニング
業務サーバを構築する場合のチューニングについて説明します。
キャッシュサイズ、キャッシュ数、および使用するWebサーバのチューニングを行ってください。
■キャッシュサイズ、キャッシュ数のチューニング
セションの管理を行う運用の場合、認証した利用者の認証情報を業務サーバでキャッシュすることで認可性能を向上させることがで
きます。キャッシュを効果的に行うためにはシステムの同時利用者数、および利用者の認証情報サイズに応じて、キャッシュサイズ、
キャッシュ数を適切に設定する必要があります。
- 321 -
キャッシュサイズ、キャッシュ数の設定については、業務サーバのInterstage管理コンソールを使用して、[システム] > [セキュリティ] >
[シングル・サインオン] > [業務システム] > [業務システム名] > [環境設定] > [詳細設定[表示]]をクリックし、以下より行います。
・ [認証情報のキャッシュ]の[キャッシュサイズ]
・ [認証情報のキャッシュ]の[キャッシュ数]
キャッシュサイズ
認証情報のサイズを以下の計算式で見積り、Kバイト単位で設定します。
認証情報サイズ = (150 + DNの文字列長
+ ユーザIDの文字列長
+ 認証方式の文字列長
+ ロールサイズ(注1)
+ 拡張ユーザ情報サイズ(注2) ) × 1.4バイト
注1)設定するロール名の文字列長の総和 + 10×ロール数
注2)設定する属性名の文字列長の総和 + 属性値の文字列長の総和 + 10×拡張ユーザ情報数
キャッシュ数
認証情報のキャッシュは、利用者の最終アクセス時からアイドル監視時間が経過するまで保持します。アイドル監視時間内で想
定する同時アクセス最大数 + α(注)を設定してください。
注)1人の利用者が、アイドル監視時間内にサインオン、サインオフを繰り返した場合でも、キャッシュ数を消費するため、想定する
同時アクセス最大数よりも少し大きめの値を設定してください。
設定したキャッシュサイズ、キャッシュ数を超える利用があった場合も継続して利用可能ですが、システムのログにsso03062、もしくは
sso03063のメッセージが出力されます。
認可性能が低下する可能性があるため、メッセージに従い対処してください。
◆チューニングの例
利用者の情報が以下の場合を例に説明します。
項目
文
字
列
長
値
DN
55
cn=Fujitsu Tarou,ou=User,ou=interstage,o=fujitsu,dc=com
ユーザID
5
tarou
認証方式
19
basicAuthOrCertAuth
ロール名
5
Admin
ロール名
6
Leader
拡張ユーザ情報(属性名)
4
mail
拡張ユーザ情報(属性値)
20
[email protected]
拡張ユーザ情報(属性名)
14
employeeNumber
拡張ユーザ情報(属性値)
6
100001
ロールサイズ
2つのロールが設定されるため、以下のようになります。
(Admin(5文字) + Leader(6文字)) + 10×ロール数(2個) = 31
- 322 -
拡張ユーザ情報サイズ
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バイトを設定します。
■Webサーバ(Interstage HTTP Server)のチューニング
詳細については、“付録E Interstage HTTP Serverの環境定義”を参照してください。
クライアントの同時接続数
以下のディレクティブに、想定する同時アクセス最大数以上を設定します。(初期値:50)
ThreadsPerChild
MaxClients
クライアント送受信タイムアウト時間
Timeoutにクライアントとの間でデータパケットを送受信するときに待機する最長の時間(秒)を指定します。(初期値:600)
■Microsoft(R) Internet Information Servicesのチューニング
Microsoft(R) Internet Information Servicesのチューニングについては、“Microsoft(R) Internet Information Services”のプロパティ情
報に以下の定義を設定することによりチューニングを行います。
最大接続数
最大接続数フィールドに想定する同時アクセス数以上を設定します。(default:1,000)
- 323 -
付録G マルチサーバ管理の環境定義
マルチサーバ管理の環境定義ファイルのチューニングについて説明します。
G.1 マルチサーバ管理定義ファイル
■概要
マルチサーバ管理定義ファイルは、マルチサーバ管理の動作環境に関する定義が格納されたファイルです。
■ファイル名
%IS_HOME%\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.inser
vergroup
サーバグループに所属する管
理対象サーバの上限
100
1～
INT_MAX
(注)
注) マルチサーバ管理定義ファイルに記述された値が範囲内に納まっていない場合、デフォルト値で動作します。
タグ名:ijserver
属性名
deploy.path
内容
配備対象アーカイブファイルの
一時格納ディレクトリ
デフォルト値
値の範囲
－
%IS_HOME%\jmx\var\ssv_ijs
/etc/opt/FJSVisjmx/var/ssv_ijs
- 324 -
付録H Portable-ORBの環境設定
Portable-ORBの動作環境ファイルは、porbeditenvコマンドを使用して設定します。Portable-ORBを使用する場合は、porbeditenvコマ
ンドを使用して以下の環境設定を行ってください。
・ 動作環境情報
・ ホスト情報
・ セキュリティ
・ ネットワーク環境
porbeditenvコマンドの詳細については、“リファレンスマニュアル(コマンド編)”の“porbeditenv”を参照してください。Portable-ORBの
動作環境ファイルの詳細については、“アプリケーション作成ガイド(CORBAサービス編)”の“Portable-ORB動作環境ファイルの指定”
を参照してください。
また、運用環境を構築した場合は、万が一に備えて、資源のバックアップを行うことを推奨します。資源のバックアップについては、
“運用ガイド（基本編）”の“メンテナンス(資源のバックアップ/他サーバへの資源移行/ホスト情報の変更)”を参照してください。
- 325 -
付録I
Webサーバ(Sun Java System Web Server)の環境定
義
Webサーバ(Sun Java System Web Server)の環境定義については、「J2EE ユーザーズガイド(旧版互換)」を参照してください。
- 326 -
索　引
Interstage ディレクトリサービスのシステム資源.......................85
Interstage ディレクトリサービスのシステム資源の設定............85
Interstage統合コマンドのシステム資源...................................92
Interstageの機能を使用するためのチューニング...................41
Interstageのチューニング.........................................................34
IPCキー値..............................................................................102
IPC資源のカスタマイズ..........................................................102
IPv6環境での運用...................................................................47
irconfig....................................................................................283
[数字]
1台のサーバに認証サーバを構築する場合のチューニング320
1台のサーバにリポジトリサーバと認証サーバを構築する場合の
チューニング...........................................................................320
1台のサーバにリポジトリサーバを構築する場合のチューニング
................................................................................................319
1トランザクションに参加するリソース数.................................301
[C]
CMS付きパラレルGC.............................................................193
config......................................................................................259
configファイル.........................................................................294
CORBAサービスのシステム環境の設定................................53
CORBAサービスのシステム資源............................................53
CORBAサービスの動作環境ファイル...................................258
CORBAワークユニットのチューニング..................................106
[J]
J2EE互換のシステム資源........................................................76
J2EEのチューニング..............................................................174
Java EE機能のチューニング..................................................108
Java EEのシステム資源の設定................................................98
java.lang.OutOfMemoryErrorがスローされた場合...............244
java.lang.StackOverflowErrorがスローされた場合...............250
Java Native Interface(JNI)......................................................184
Java VM..................................................................................177
Java VM終了時における状態情報のメッセージ出力機能. .232
Java VMのヒープ領域サイズ/Perm領域サイズ.....................112
Javaツール機能......................................................................254
Javaヒープとガーベジコレクション..........................................181
Javaヒープのチューニング.....................................................209
JDK/JREのチューニング........................................................176
JDK関連のドキュメント...........................................................176
JNI処理異常時のメッセージ出力..........................................241
JPAのチューニング................................................................127
■JDKドキュメント...................................................................176
JTS_RMP_PROC_CONC......................................................302
JTS_RMP_THR_CONC........................................................303
JTS用のリソース管理プログラムのスレッド多重度................303
JTS用のリソース管理プログラムのプロセス多重度...............302
[E]
EJBコンテナのチューニング..................................................121
Enterprise Beanインスタンスのキャッシング...........................124
Enterprise Beanインスタンスのプーリング..............................126
EXTP4435メッセージまたはISJEE_OM1018メッセージが出力さ
れた場合.................................................................................247
[F]
FJGC.......................................................................................188
FJVMログ...............................................................................234
FJVM......................................................................................178
FJVMでサポートされるガーベジコレクション処理................185
FJVMに対して指定可能なチューニング用オプション.........183
[G]
gwconfig.................................................................................276
[H]
HOST......................................................................................303
[L]
LOGFILE................................................................................300
[I]
IIOP_port................................................................................260
IJServerクラスタのチューニング.............................................112
IJServerまたはEJBサービスのシステム資源の設定...............76
IJServerワークユニットのチューニング..................................106
inithost/initial_hosts................................................................278
iniファイルの設定例...............................................................256
Interstage HTTP Server..........................................................315
Interstage HTTP Serverのシステム資源..................................76
Interstage HTTP Serverのシステム資源の設定......................76
Interstage Java EE DASサービスのチューニング.................108
Interstage Java EE DASサービスのヒープ領域サイズとアドレス
空間........................................................................................149
Interstage Java EE Node Agentサービスのチューニング......111
Interstage Java EE管理コンソールのチューニング...............114
Interstage管理コンソールのシステム資源...............................92
Interstage管理コンソールのシステム資源の設定...................92
Interstage シングル・サインオンの環境定義.........................319
Interstage シングル・サインオンのシステム資源......................80
Interstage シングル・サインオンのシステム資源の設定..........80
[M]
max_exec_instance.................................................................262
max_IIOP_resp_con...............................................................262
max_impl_rep_entries............................................................263
max_processes........................................................................263
MessageQueueDirectorのシステム資源...................................78
MessageQueueDirectorのシステム資源の設定.......................78
MODE....................................................................................299
MQ連携サービスを使用する場合...........................................20
[N]
New世代領域サイズ自動調整機能付きGC（FJGC）............188
New世代領域用制御処理並列化機能付きGC（パラレルGC）190
nsconfig..................................................................................282
number_of_common_buffer...................................................263
[O]
ORB........................................................................................142
ORBのチューニング...............................................................142
- 327 -
永続性ユニットの共有キャッシュ...........................................129
オブジェクト参照の圧縮機能.................................................196
OTS_FACT_THR_CONC.....................................................302
OTS_RECV_THR_CONC.....................................................302
OTSシステムが動作するホストのCORBAサービスのポート番号
................................................................................................303
OTSシステムが動作するホスト名...........................................303
OTSシステムのスレッド多重度..............................................302
OTSシステム用業務システム情報定義ファイル...................309
[か]
仮想メモリと仮想アドレス空間...............................................178
環境定義ファイルの制御文...................................................290
環境変数..................................................................................45
ガーベジコレクション処理の結果ログ出力機能の強化........198
ガーベジコレクションのログ出力...........................................196
ガーベジコレクション発生回数..............................................113
ガーベジコレクション(GC)......................................................185
記述形式................................................................................287
基礎知識................................................................................176
業務構成管理機能のチューニング.......................................175
業務サーバを構築する場合のチューニング........................321
共有メモリ...............................................................................100
共有メモリ量の見積もり方法..................................................100
空行........................................................................................290
クライアントアプリケーションを追加した場合...........................40
クライアント機能を使用する場合........................................20,32
クライアント、サーバ兼用アプリケーションを追加した場合....41
クライアントの同時接続数......................................................317
クラスのインスタンス情報出力機能.......................................230
クラッシュダンプ......................................................................239
クラッシュダンプ・コアダンプ..................................................239
グループ管理サービスの設定...............................................113
コアダンプ...............................................................................240
コネクタのチューニング..........................................................137
コメント行................................................................................290
コンカレント・マーク・スイープGC付きパラレルGC（CMS付きパ
ラレルGC）..............................................................................193
コンポーネントトランザクションサービスの環境定義.............287
コンポーネントトランザクションサービスのシステム環境の設定62
コンポーネントトランザクションサービスのシステム資源.........62
[P]
PARTICIPATE.......................................................................301
period_idle_con_timeout........................................................268
period_receive_timeout..........................................................269
period_server_timeout............................................................269
PORT......................................................................................303
Portable-ORBの環境設定.....................................................325
[Q]
queue_policy...........................................................................280
[R]
read_interval_timeout.............................................................261
RMPプロパティ.......................................................................303
[S]
SIGBUS発生により異常終了した場合..................................251
SSL通信の利用.....................................................................116
[SYSTEM ENVIRONMENT]セクション...............................290
[T]
TCP/IPパラメタのチューニング..............................................101
traceconfig..............................................................................311
TRANMAX............................................................................301
[W]
Webコンテナのチューニング.................................................117
Webサーバ(Sun Java System Web Server)の環境定義.......326
Webサーバコネクタのシステム資源........................................94
Webサービスのチューニング.................................................132
Windows(R)固有パラメタ.......................................................257
[WRAPPER]セクション..........................................................292
write_interval_timeout............................................................261
[さ]
最大トランザクション多重度...................................................301
サーバアプリケーションを追加した場合..................................40
サーバ機能運用時に必要なシステム資源.............................50
サーバ機能を使用する場合.................................................1,21
サーバマシン状態監視............................................................45
時間監視機能の相関関係....................................................153
システム.............................................................................99,100
システム構成情報の見積もり方法 (Linuxの場合)................100
システム構成情報の見積もり方法 (Solarisの場合)................99
システムのチューニング...........................................................50
システムログファイルのパス...................................................300
シャットダウンタイムアウト.......................................................140
出力例と調査例.....................................................................236
詳細属性................................................................................136
シリアルGC.............................................................................187
スタック....................................................................................180
スタックオーバーフロー検出時のメッセージ出力機能.........250
スタックトレース.......................................................................218
スタックトレースの解析方法.....................................219,220,221
スタックのチューニング..........................................................214
ステートメント..........................................................................287
スレッドダンプ.........................................................................222
[あ]
アップロードファイルの最大サイズのチューニング...............115
アプリケーション最大処理時間.............................................113
アプリケーション追加によるチューニング................................39
アプリケーション用業務システム情報定義ファイル..............310
異常終了箇所の情報............................................................234
異常終了時のJavaヒープに関する情報................................236
異常終了時のシグナルハンドラ情報....................................235
異常発生時の原因振り分け..................................................244
イベントサービス.......................................................................43
イベントサービスの環境定義.................................................311
イベントサービスのシステム環境の設定.................................71
イベントサービスのシステム資源.............................................71
イベントサービスの動作環境ファイル....................................311
サプライヤ・コンシューマ総数の見積もり方法......................314
運用時に必要なディスク容量....................................................1
永続性コンテキストキャッシュ................................................127
- 328 -
スレッドプーリング...................................................................121
スローダウンが発生した場合.................................................253
性能監視ツール使用時に必要なシステム資源......................99
性能情報の分析....................................................................163
セクション................................................................................289
セッションタイムアウト.............................................................114
接続検証.........................................................................134,139
セットアップ種別.....................................................................299
セットアップ情報ファイル.......................................................299
セマフォ資源..........................................................................256
想定するシステム形態.............................................................34
(Java EE)...................................................................................34
想定するシステム形態（マルチ言語サービス）.......................35
マルチサーバ管理定義ファイル............................................324
マルチサーバ管理の環境定義.............................................324
マルチサーバ管理を使用する場合...................................18,32
メモリ容量.................................................................................21
メモリ領域不足事象発生時のメッセージ出力機能の強化...245
モニタロギング.................................................................157,158
モニタロギングの操作手順....................................................159
モニタロギングのログファイル................................................161
[や]
ユーティリティワークユニットのチューニング.........................106
予兆監視機能から警告が通知された場合の対処...............145
予兆監視警告メッセージ(Javaヒープ)...................................146
予兆監視警告メッセージ(ガーベジコレクション)..................147
[た]
タイムアウト監視.....................................................................268
タイムアウト時間.....................................................................315
暖機運転................................................................................215
チューニング/デバッグ技法...................................................218
チューニング方法..............................................................39,209
(Java EE)...................................................................................39
チューニング方法(マルチ言語サービス)................................39
長時間コンパイル処理の検出機能.......................................206
通信データサイズに関する注意事項....................................144
定義ファイルの設定値.............................................................36
ディスク容量...............................................................................1
データベース連携環境のチューニング................................132
データベース連携サービス.....................................................42
データベース連携サービスのiniファイル設定情報..............255
データベース連携サービスの環境定義...............................294
データベース連携サービスのシステム環境の設定................67
データベース連携サービスのシステム資源............................67
データベース連携サービスのチューニング..........................255
同一Java VM内のリモートアクセスでデータコピーを防ぐ機能127
動的コンパイル.......................................................................204
動的コンパイル発生状況のログ出力機能............................207
トランザクションアプリケーションのチューニング...................106
トランザクション管理........................................................135,140
トランザクションサービスのチューニング...............................141
[ら]
ラッパーワークユニットのチューニング..................................106
リカバリプロセスのスレッド多重度..........................................302
リソース定義ファイル..............................................................305
リポジトリのチューニング........................................................175
例外発生時のスタックトレース出力.......................................222
ログ出力における時間情報のフォーマット指定機能...........233
ロードバランス...........................................................................43
[わ]
ワークユニット数、オブジェクト数、プロセス数のチューニング104
ワークユニットのチューニング................................................104
[は]
配備時のチューニング...........................................................117
パラレルGC............................................................................190
ハングアップ(フリーズ)した場合............................................253
必要資源....................................................................................1
標準GC（シリアルGC）............................................................187
複数プロセス運用..................................................................112
フレーム..................................................................................180
プロセスが消滅(異常終了)した場合.....................................251
プロセス強制停止時間のチューニング.................................105
プロファイラ設定.....................................................................172
プロファイラ設定の運用方法.................................................172
プール内の接続数..........................................................132,137
ホスト情報(IPアドレス/ホスト名)の変更方法............................49
ポート番号..............................................................................116
[ま]
マルチサーバ管理機能を使用する時に必要なシステム資源98
- 329 -