Cosminexus V11 アプリケーションサーバ システム設計ガイド

解説書

3021-3-J04-80

前書き

対象製品

マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の前書きの対象製品の説明を参照してください。

輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

AIXは，世界の多くの国で登録されたInternational Business Machines Corporationの商標です。

AMDは，Advanced Micro Devices, Inc.の商標です。

Intelは，Intel Corporation またはその子会社の商標です。

Linuxは，Linus Torvalds氏の米国およびその他の国における登録商標です。

Microsoft，SQL Server，Windows，Windows Server は，マイクロソフト 企業グループの商標です。

Oracle(R)，Java ，MySQL及びNetSuite は，Oracle，その子会社及び関連会社の米国及びその他の国における登録商標です。

Red Hat, and Red Hat Enterprise Linux are registered trademarks of Red Hat, Inc. in the United States and other countries. Linux(R) is the registered trademark of Linus Torvalds in the U.S. and other countries.

Red Hat，およびRed Hat Enterprise Linuxは，米国およびその他の国におけるRed Hat, Inc.の登録商標です。Linux(R)は，米国およびその他の国におけるLinus Torvalds氏の登録商標です。

UNIXは，The Open Groupの登録商標です。

その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

発行

2026年 1月 3021-3-J04-80

著作権

All Rights Reserved. Copyright (C) 2020, 2026, Hitachi, Ltd.

変更内容

変更内容(3021-3-J04-80) uCosminexus Application Server 11-70，uCosminexus Client 11-70，uCosminexus Developer 11-70，uCosminexus Service Architect 11-70，uCosminexus Service Platform 11-70

追加・変更内容

変更個所

JDK21サポートに関する記述を追加した。

2.1，7.20

単なる誤字・脱字などはお断りなく訂正しました。

はじめに

このマニュアルをお読みになる際の前提情報については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」のはじめにの説明を参照してください。

1　アプリケーションサーバのシステム設計の目的と流れ

この章では，アプリケーションサーバのシステム設計の目的と，検討する必要がある項目について説明します。また，アプリケーションサーバのシステム設計の流れについても説明します。

1.1　アプリケーションサーバのシステム設計の目的

アプリケーションサーバは，JavaやCORBAなどの業界標準に準拠したアプリケーションの実行環境である，アプリケーションサーバを構築する製品です。アプリケーションサーバは，業務システムの構築基盤として位置づけられます。

業務システムには，次のような要件が求められます。

信頼性と可用性の高いシステムの実現

業務システムを止めることなく安定稼働させるために，信頼性と可用性を確保したシステムであることが必要です。

セキュリティの確保

システムを管理または運用するユーザがシステムを構築・運用していく過程や，システムが提供するサービスをエンドユーザが利用していく過程で，システムにはセキュリティ上のさまざまな脅威が想定されます。脅威からシステムを守るには，システムを物理的に安全な構成に設計したり，作業者の運用ルールを定めたりするなどの対策を実施する必要があります。

優れた処理性能の実現

Webクライアントなどの多数のクライアントからの処理要求や，EJBクライアントなどの業務のバックシステムでのミッションクリティカルな処理要求などに，迅速かつ確実に対応するレスポンスが求められます。

これらの要件を満たすシステムを構築するためには，システム構築を始める前にシステムの目的や特徴を分析したり，システムで使用するリソースを見積もったりするなど，最適なシステム構成を検討する必要があります。また，システムの運用を開始する前に，セキュリティを確保するための手順を整備したり，実際に想定される運用時の状態で動作確認およびチューニングを実施したりする必要があります。

アプリケーションサーバのシステム設計は，これらの作業を通して，アプリケーションサーバ上で動作する業務システムを，最適な状態で運用できるようにすることを目的とします。このマニュアルでは，アプリケーションサーバのシステムを設計する場合に検討，考慮する必要がある項目として，次の項目について説明します。

システム構成の検討方法

セキュアなシステムの検討方法

パフォーマンスチューニングの実施方法

1.2　システム設計の流れ

アプリケーションサーバのシステム設計の流れについて説明します。

システム設計で考慮することは，そのシステムで実行するアプリケーションが，オンライン処理を実行するアプリケーション（J2EEアプリケーション）か，バッチ処理を実行するアプリケーション（バッチアプリケーション）かによって異なります。

それぞれのシステム設計の流れを示します。

1.2.1　オンライン処理を実行するアプリケーション（J2EEアプリケーション）の場合

システム設計は，次の図に示す流れで実行します。

図1‒1　システムの設計の流れ（J2EEアプリケーションを実行する場合）

注※

それぞれの参照先については，次の表に示した個所を参照してください。

システムの設計

参照先マニュアル

参照個所

システム設計の準備

このマニュアル

2章

システム構成の検討

3章

セキュアなシステムの検討

アプリケーションサーバ機能解説 セキュリティ管理機能編

4章

リソースの見積もり

このマニュアル

5章

システムの構築

アプリケーションサーバ システム構築・運用ガイド

パフォーマンスチューニング

このマニュアル

7章，8章

システムの運用開始

アプリケーションサーバ システム構築・運用ガイド

1.2.2　バッチ処理を実行するアプリケーション（バッチアプリケーション）の場合

システム設計は，次の図に示す流れで実行します。

図1‒2　システムの設計の流れ（バッチアプリケーションを実行する場合）

注※

それぞれの参照先については，次の表に示した個所を参照してください。

システムの設計

参照先マニュアル

参照個所

システム設計の準備

このマニュアル

2章

システム構成の検討

4章

リソースの見積もり

6章

システムの構築

アプリケーションサーバ システム構築・運用ガイド

4.6

パフォーマンスチューニング

このマニュアル

7章，9章

システムの運用開始

アプリケーションサーバ システム構築・運用ガイド

4.6.3

2　システム設計の準備

この章では，システム設計の準備として，システム設計を始める前に決めておくことについて説明します。

2.1　システム設計を始める前に決めておくこと

この節では，アプリケーションサーバのシステム設計を始める前に決めておくことについて説明します。

システム設計作業を始める前に，まず，次のことを明確にしてください。これらの検討結果を踏まえて，3章以降で説明するシステム構成の検討やパフォーマンスチューニングを実施します。

業務の種類を明確にする

システムで実現する業務の種類を明確にします。業務の種類によって，使用するアプリケーションの種類，構成，および必要なソフトウェアが決まります。

システムの目的に応じたアプリケーションの構成を決める

システムの目的に従って，使用する機能を検討した上で，動作させるアプリケーションの構成を明確にします。また，必要なソフトウェアを準備します。

運用方法を検討する

アプリケーションサーバのシステムでは，Management Serverという運用管理プロセスを使用して，複数のサーバプロセスを一括して運用します。

運用方法の検討では，アプリケーションサーバのシステムのほかに，アプリケーションサーバ以外のプログラムを含めたシステム全体を，どのように運用するかを検討します。

インストールするJDKを検討する

インストールするJDKのバージョンを検討します。

インストールするJDKによって，アプリケーションサーバで使用できる機能が異なります。目的に合わせて使用するJDKを決定してください。また，インストール時にも次の違いがあります。

JDK11およびJDK17の場合：旧バージョンからの更新インストールおよび新規インストールが可能

JDK21の場合：新規インストールだけが可能

機能の違いについては，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「10.3.3　アプリケーションサーバ 11-00，11-10，11-20，11-30，11-40，11-50，または11-60から，11-70までの仕様変更」を参照してください。

2.2　業務の種類を明確にする

システムでどのような業務を実現するのか，業務の種類を明確にします。

アプリケーションサーバのシステムでは，次の2種類の業務を実行できます。

オンライン業務

ネットワーク経由などで送信されるクライアントからのリクエストを処理する形式の業務です。

バッチ業務

定型的または定期的な作業をまとめて処理する形式の業務です。

業務の種類によって，実行するアプリケーションの形式や，アプリケーションを実行するサーバプロセスなどが異なります。業務の種類，アプリケーションの形式，およびアプリケーションを実行するサーバプロセスの対応を次の表に示します。

表2‒1　業務の種類，アプリケーションの形式，およびアプリケーションを実行するサーバプロセスの対応

業務の種類

アプリケーションの形式

アプリケーションを実行するサーバプロセス

オンライン業務

J2EEアプリケーション

J2EEサーバ

バッチ業務

バッチアプリケーション

バッチサーバ

ポイント

以降で実施するシステム設計の内容は，業務の種類によって異なります。業務の種類に応じて，必要なシステム設計を実施してください。業務の種類ごとに実行するシステム設計の内容と，このマニュアルでの参照先を次の表に示します。

表2‒2　業務の種類ごとに実行するシステム設計の内容とこのマニュアルでの参照先

システム設計の内容

業務の種類

オンライン業務

バッチ業務

システム設計の準備

アプリケーションの構成の決定

2.5

2.6

運用方法の検討

2.7

システム構成の検討

3章

4章

パフォーマンスチューニング

8章

9章

JavaVMのチューニング

7章，7.4，7.11

2.3　使用する機能を検討する（オンライン処理を実行する場合）

ここでは，J2EEアプリケーションを実行するアプリケーションサーバのプロセス構成とJ2EEサーバの構成について説明します。

2.3.1　プロセス構成

J2EEアプリケーションを実行するアプリケーションサーバは，次の図に示すプロセスで構成されます。

図2‒1　J2EEアプリケーションを実行するアプリケーションサーバを構成するプロセス

参考

なお，システムを構築する場合は，これらのプロセスをシステムの要件に合わせて，システム内の各マシンに一つまたは複数配置します。

それぞれのプロセスについて説明します。なお，図中の番号は，(1)〜(6)に対応します。

(1)　J2EEサーバ

J2EEサーバは，J2EEアプリケーションの実行基盤となるプロセスです。J2EEサーバは，J2EEアプリケーション，J2EEコンテナ，J2EEサービス，J2EEリソースなど，複数のプログラムモジュールで構成されます。また，J2EEコンテナは，提供する機能によって，EJBコンテナとWebコンテナに分けられます。J2EEサーバを構成するプログラムモジュールについては，「2.3.2　J2EEサーバの構成」で説明します。

(2)　Webサーバ

Webサーバは，Webブラウザからのリクエスト受信，およびWebブラウザへのデータ送信に関連する処理を実行するプロセスです。J2EEサーバ上で動作するJ2EEアプリケーションにWebブラウザからアクセスするシステムの場合に，Webサーバを使用する必要があります※。なお，Webブラウザからアクセスできるのは，J2EEアプリケーションに含まれるサーブレット，JSP，または静的コンテンツです。

アプリケーションサーバでは，Webサーバとして，HTTP ServerまたはMicrosoft IISを使用できます。HTTP Serverは，アプリケーションサーバの構成ソフトウェアの一つです。HTTP Serverの機能については，マニュアル「HTTP Server」を参照してください。

注※

Webサーバを経由しないでJ2EEサーバのNIO HTTPサーバとWebブラウザ間で直接リクエストを送受信する場合，Webサーバに相当するプロセスは不要です。詳細は，マニュアル「アプリケーションサーバ機能解説 基本・開発編(Webコンテナ)」の「7.　NIO HTTPサーバ」を参照してください。

(3)　CTM

CTMは，J2EEアプリケーション内のSession Beanに対するリクエストをスケジューリングするためのプロセス群です。CTMを使用することで，クライアントからのリクエストを適切に分散，スケジューリングできます。これによって，サーバの負荷を抑え，システムの可用性を高めて業務を滞りなく進めるようにできます。

CTMとしての機能は，CTMデーモン，CTMレギュレータ，CTMドメインマネジャなどの，複数のプロセスを使用して実現します。また，ネーミングサービスとして，CORBAネーミングサービスを使用します。

CTMの機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「3.　CTMによるリクエストのスケジューリングと負荷分散」を参照してください。

ポイント

CTMは，構成ソフトウェアにComponent Transaction Monitorを含む製品だけで利用できます。利用できる製品については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の「2.2　構成ソフトウェア」を参照してください。

(4)　PRFデーモン（パフォーマンストレーサ）

アプリケーションサーバは，リクエストを処理するときに，トレース情報をバッファに出力します。また，アプリケーションサーバだけでなく，トレースの対象を拡張して，アプリケーションでもトレース情報をバッファに出力できます。PRFデーモン（パフォーマンストレーサ）は，バッファに出力されたトレース情報をファイルに出力するためのI／Oプロセスです。

PRFデーモンが出力するトレース情報ファイルは，システムのボトルネックを検証したり，トラブルシュートの効率向上を図ったりするために役立ちます。

PRFデーモンの機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」を参照してください。

(5)　運用管理エージェント

運用管理者の代わりに，それぞれのホスト上の論理サーバを起動したり，設定ファイルを更新したりするエージェント機能を持つプロセスです。なお，論理サーバとは，Management Serverの運用管理の対象になる，サーバまたはクラスタです。

(6)　Management Server

運用管理ドメイン内の各ホストに配置した運用管理エージェントに指示を出して，運用管理ドメイン全体の運用管理を実行するためのプロセスです。

(7)　そのほかのプロセス

(1)〜(6)で示したプロセス以外に，機能に応じて使用するプロセスとして，次のプロセスがあります。

ユーザサーバ

ユーザサーバとは，ユーザが定義する任意のサービスやプロセスです。ユーザサーバは論理サーバ（論理ユーザサーバ）として定義できます。論理ユーザサーバとして定義することで，特定のサービスやプロセスがManagement Serverの管理対象となります。これによって，ほかの論理サーバと同様に，Management Serverで一括管理できるようになります。

2.3.2　J2EEサーバの構成

J2EEサーバとは，次に示す六つのプログラムモジュールを実行するJavaアプリケーションです。

J2EEアプリケーション（サーブレット，JSP，Enterprise Beanなど）

J2EEコンテナ

J2EEサービス

JNDI，JavaMail，JTA，JPA，RMI-IIOP，JDBC，ネーミング管理，トランザクション管理，セキュリティなど

J2EEリソース

JPAプロバイダ

コンテナ拡張ライブラリ

J2EEアプリケーションは，サーブレット，JSP，Enterprise Beanなどによって構成されています。J2EEアプリケーションは，業務の内容に応じて，ユーザが開発します。なお，J2EEアプリケーション以外のプログラムモジュールは，アプリケーションサーバで提供されているモジュールです。

J2EEサーバの構造を次の図に示します。

図2‒2　J2EEサーバの構造

以降の項で，J2EEサーバの各モジュールの概要を説明します。

2.3.3　J2EEアプリケーションとJ2EEコンポーネント

J2EEアプリケーションは，一つ以上のJ2EEコンポーネントで構成されています。ここでは，J2EEアプリケーションとJ2EEコンポーネントについて説明します。

(1)　J2EEアプリケーションとJ2EEコンポーネントの関係

J2EEアプリケーションは，サーブレット，JSP，Enterprise Beanなどのユーザアプリケーションプログラムで構成されています。J2EEアプリケーションは，J2EEコンテナ上で動作します。

J2EEアプリケーションを構成する，サーブレット，JSP，Enterprise BeanなどをJ2EEコンポーネントといいます。

J2EEアプリケーションとJ2EEコンポーネントの関係を次の図に示します。

図2‒3　J2EEアプリケーションとJ2EEコンポーネントとの関係

(2)　J2EEアプリケーションの構造

J2EEアプリケーションは，3層の構造になっています。J2EEアプリケーションの構造を次の図に示します。

図2‒4　J2EEアプリケーションの構造

J2EEアプリケーションの最小単位は，階層3のファイル（図中，点線で囲まれたファイル）です。階層3のファイルには，クラスファイルやJSPファイルなどがあります。

そして，階層3のファイルをパッケージしたものが階層2のファイルとなります。この図の場合，階層2のEJB-JARファイルは，階層3に属するEnterprise BeanとDD（ejb-jar.xml）をパッケージしたものとなります。

さらに，階層2のそれぞれのファイルをパッケージしたものが階層1のJ2EEアプリケーションとなります。

ここでは，階層1および階層2のパッケージファイルについて説明します。なお，図中の項番は次の説明の項番と対応しています。

参考

それぞれの階層でファイル形式，およびDDのDTDが規定されています。

DDとは，アプリケーションを運用環境に配置するときの定義情報を記述したファイルを指します。EJB-JARの場合，DDはejb-jar.xml，Webアプリケーションの場合，DDはweb.xml，J2EEアプリケーションの場合，DDはapplication.xmlとなります。

なお，Enterprise Beanでアノテーションを使用する場合，ejb-jar.xmlは不要です。

(a)　J2EEアプリケーション

J2EEアプリケーションは，複数の，EJB-JAR，Webアプリケーション，ライブラリJARと，一つのDD（application.xml）で構成されます。

J2EEサーバで実行できるJ2EEアプリケーションは，アーカイブ形式のJ2EEアプリケーション，および展開ディレクトリ形式のJ2EEアプリケーションです。

アーカイブ形式のJ2EEアプリケーション

EJBやサーブレットなどのアプリケーションの実体をJ2EEサーバの作業ディレクトリに持つJ2EEアプリケーションです。アーカイブ形式のJ2EEアプリケーションをJ2EEサーバ内にインポートしてクライアントから実行可能な状態にするためには，EAR形式またはZIP形式へのアセンブルと，デプロイが必要です。

展開ディレクトリ形式のJ2EEアプリケーション

EJBやサーブレットなどのアプリケーションの実体を，J2EEサーバの外部にある一定のルールに従ったファイル／ディレクトリに持つJ2EEアプリケーションです。展開ディレクトリ形式のJ2EEアプリケーションをJ2EEサーバ内にインポートしてクライアントから実行可能な状態にするためには，デプロイが必要です。

参考

アセンブルとは，単体では動作しないEJB-JARをアプリケーションの1構成要素として位置づけるための組み立て作業のことです。アセンブルでは，EJB-JARを1構成要素として取り込んだJ2EEアプリケーションを構築します。なお，J2EEアプリケーションの構成要素として，EJB-JARのほかにWARファイル，ライブラリJARを含むことがあります。

展開ディレクトリ形式のJ2EEアプリケーションの場合には，EAR形式またはZIP形式へのアセンブルは不要です。

デプロイとは，J2EEアプリケーションをクライアントから実行可能な状態にすることです。

(b)　EJB-JAR

EJB-JARは，EJB-JARファイル形式でパッケージ化されています。複数のEnterprise Beanと一つのDD（ejb-jar.xml）で構成されます。なお，Enterprise Beanでアノテーションを使用している場合は，DD（ejb-jar.xml）は不要です。

(c)　Webアプリケーション

Webアプリケーションは，WARファイル形式でパッケージ化されています。複数のサーブレット，JSP，HTMLと一つのDD（web.xml）で構成されます。

(d)　ライブラリJAR

ライブラリJARは，JARファイル形式でパッケージ化されたものです。複数の共通ライブラリから構成されています。共通ライブラリはJ2EEアプリケーション中のJ2EEコンポーネントが共通で使用できるライブラリです。J2EEアプリケーションのDD（application.xml）の<module>タグ以下に定義されているファイル以外で，拡張子が小文字（.jar）のJARファイルがライブラリJARとみなされます。

(3)　J2EEアプリケーションおよびJ2EEコンポーネントの開発

J2EEアプリケーションでアプリケーションサーバが提供する実行基盤としての機能を使用するためには，機能に応じたアプリケーションの実装が必要です。なお，アプリケーションサーバでは，J2EEアプリケーションおよびJ2EEコンポーネントを開発するための製品として，Developerを提供しています。

J2EEアプリケーションおよびJ2EEコンポーネントの開発方法については，マニュアル「アプリケーションサーバ アプリケーション開発ガイド」を参照してください。

2.3.4　J2EEコンテナ

J2EEコンテナとは，J2EEアプリケーションを実行するためのサーバ基盤です。J2EEコンテナは，EJBコンテナとWebコンテナで構成されています。

J2EEコンポーネントはWebコンテナおよびEJBコンテナで提供するAPIを利用して，J2EEコンテナ上で動作します。アプリケーションサーバで提供しているWebコンテナおよびEJBコンテナは，Java EE 6に対応しています。これによって，Java EEに準拠する，本格的な基幹業務アプリケーションを迅速かつ容易に構築できます。

(1)　Webコンテナ

Webコンテナは，サーブレットとJSPを実行するためのサーバ基盤です。Webクライアントからアクセスを受け取り，要求に応じたサービスを提供します。

Webコンテナでは，サーブレット，JSPのAPIを提供しています。

(2)　EJBコンテナ

EJBコンテナは，Enterprise Beanの実行を制御し，Enterprise Beanに各種のサービスを提供するサーバ基盤です。EJBコンテナでは，EJBのAPIを提供しています。

2.3.5　J2EEサービス

J2EEサービスでは，次に示す機能およびAPIを提供しています。

トランザクション管理，セキュリティ管理，およびネーミング管理の機能

JNDI，JDBC，JTA，JPA，RMI-IIOP，JavaMail，JMSなどのAPI

J2EEサービスは，J2EEコンテナの部品機能として利用され，J2EEコンポーネントである，サーブレット・JSP，およびEnterprise Beanに，機能およびAPIを提供します。J2EEサービスのAPIは，J2EEコンポーネントによって，直接，またはJ2EEコンテナ経由で利用されます。

J2EEサービスの位置づけを次の図に示します。

図2‒5　J2EEサービスの位置づけ

J2EEサービスでは，アプリケーションサーバの構成ソフトウェアの機能のほか，アプリケーションサーバ以外の製品の機能も使用します。J2EEサービスを実現する，ソフトウェア製品またはアプリケーションサーバの構成ソフトウェアを次の表に示します。

表2‒3　J2EEサービスを実現する，製品または構成ソフトウェア

分類

製品または構成ソフトウェア

サービス

ネーミング管理

Component Container※

TPBroker※

トランザクション管理

セキュリティ

Component Container※

API

JNDI

JTA

JPA

JavaMail

RMI-IIOP

TPBroker※

JDBC Standard Extension

HiRDB Type4 JDBC Driver

Oracle JDBC Thin Driver

SQL Server Driver for JDBC

JDBC

JMS

Reliable Messaging※

TP1/Message Queue - Access

注※　アプリケーションサーバの構成ソフトウェアです。

2.3.6　J2EEリソース

J2EEサーバはリソースとして，データベース，OpenTP1，SMTPサーバ，およびJavaBeansリソースを利用できます。J2EEリソースは，これらのリソースと接続するために使用します。

アプリケーションサーバで扱うJ2EEリソースには，外部リソースとの接続に利用するリソースアダプタ，およびメールコンフィグレーションがあります。また，このほかに，内部リソースとして利用できるJavaBeansリソースがあります。

リソースアダプタ

接続するリソースの種類に応じて，次のリソースアダプタがあります。

DB Connector

データベースとの接続に利用します。

DB Connector for Reliable MessagingおよびReliable Messaging

データベース上のキューとの接続に利用します。

TP1 Connector

OpenTP1のSPPとの接続に利用します。

TP1/Message Queue - Access

TP1/Message Queueとの接続に利用します。

そのほかのConnector 1.0またはConnector 1.5※に準拠したリソースアダプタ

任意のリソースとの接続に使用します。

メールコンフィグレーション

SMTPサーバとの接続に利用します。

JavaBeansリソース

内部のリソースとして利用できるリソースです。

J2EEリソースの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.　リソース接続とトランザクション管理」を参照してください。

注※　Outboundの通信モデルに対応したリソースアダプタを使用できます。詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定」を参照してください。

2.3.7　JPAプロバイダ

アプリケーションサーバで提供しているJPA実装をJPAプロバイダといいます。JPAプロバイダを利用することによって，アプリケーションサーバでJPAアプリケーションを実行できます。

JPAプロバイダについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「6.　JPA 2.2の利用」を参照してください。

2.3.8　コンテナ拡張ライブラリ

Enterprise Bean，サーブレット，JSPが利用する共通のライブラリをコンテナ拡張ライブラリといいます。このライブラリを利用することによって，Enterprise Bean，サーブレット，JSPからユーザ作成の共通のライブラリを呼び出せるようになります。

コンテナ拡張ライブラリについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「19.　コンテナ拡張ライブラリ」を参照してください。

2.4　使用する機能を検討する（バッチ処理を実行する場合）

ここでは，バッチアプリケーションを実行するアプリケーションサーバのプロセス構成と，バッチサーバの構成について説明します。

2.4.1　プロセス構成

バッチアプリケーションを実行するアプリケーションサーバは，次の図に示すプロセスで構成されます。

図2‒6　バッチアプリケーションを実行するアプリケーションサーバを構成するプロセス

参考

システムを構築する場合は，これらのプロセスをシステムの要件に合わせて，システム内の各マシンに一つまたは複数配置します。

それぞれのプロセスについて説明します。なお，図中の番号は，(1)〜(5)に対応します。

(1)　バッチサーバ

バッチサーバは，バッチアプリケーションの実行基盤となるプロセスです。バッチサーバは，バッチアプリケーション，バッチサービス，J2EEサービス，J2EEリソースなど，複数のプログラムモジュールで構成されます。バッチサーバを構成するプログラムモジュールについては，「2.4.2　バッチサーバの構成」で説明します。

(2)　CTM

CTMは，バッチアプリケーションの実行をスケジューリングするためのプロセス群です。CTMを使用することで，バッチアプリケーションの実行を適切に分散，スケジューリングできます。これによって，バッチサーバの数を意識することなく，複数のバッチアプリケーションを同時に実行できます。

CTMとしての機能は，CTMデーモン，CTMレギュレータ，CTMドメインマネジャなどの，複数のプロセスを使用して実現します。また，ネーミングサービスとして，CORBAネーミングサービスを使用します。

CTMの機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「3.　CTMによるリクエストのスケジューリングと負荷分散」を参照してください。

ポイント

CTMは，構成ソフトウェアにComponent Transaction Monitorを含む製品だけで利用できます。利用できる製品については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の「2.2　構成ソフトウェア」を参照してください。

(3)　PRFデーモン（パフォーマンストレーサ）

アプリケーションサーバは，トレース情報をバッファに出力します。また，トレースの対象を拡張して，アプリケーションでもトレース情報をバッファに出力できます。PRFデーモン（パフォーマンストレーサ）は，バッファに出力されたトレース情報をファイルに出力するためのI／Oプロセスです。PRFデーモンが出力するトレース情報ファイルは，システムのボトルネックを検証したり，トラブルシュートの効率向上を図ったりするために役立ちます。

PRFデーモンの機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」を参照してください。

(4)　運用管理エージェント

運用管理者の代わりに，それぞれのホスト上の論理サーバを起動したり，設定ファイルを更新したりするエージェント機能を持つプロセスです。なお，論理サーバとは，Management Serverの運用管理の対象になる，サーバまたはクラスタです。

(5)　Management Server

運用管理ドメイン内の各ホストに配置した運用管理エージェントに指示を出して，運用管理ドメイン全体の運用管理を実行するためのプロセスです。

参考

バッチ処理を実行する場合，(1)〜(5)で示したプロセス以外に，システムの目的に応じてユーザサーバというプロセスを使用できます。ユーザサーバとは，ユーザが定義する任意のサービスやプロセスです。ユーザサーバは論理サーバ（論理ユーザサーバ）として定義できます。論理ユーザサーバとして定義することで，特定のサービスやプロセスがManagement Serverの管理対象となります。これによって，ほかの論理サーバと同様に，Management Serverで一括管理できるようになります。

2.4.2　バッチサーバの構成

バッチサーバとは，次に示す五つのプログラムモジュールを実行するJavaアプリケーションです。

バッチアプリケーション

バッチサービス

J2EEサービス

JNDI，JTA，RMI-IIOP，JDBC，ネーミング管理，トランザクション管理など

J2EEリソース

コンテナ拡張ライブラリ

バッチアプリケーションとは，バッチ処理を実装したJavaアプリケーションです。バッチアプリケーションは，業務の内容に応じてユーザが開発します。なお，バッチアプリケーション以外のプログラムモジュールは，アプリケーションサーバで提供されているモジュールです。

バッチサーバの構造を次の図に示します。

図2‒7　バッチサーバの構造

バッチサーバでは次に示すJava EEおよびJ2EEの機能を使用できます。

JDBC 2.0コア/JDBC 2.0オプションパッケージ

JDBC 3.0※1

JDBC 4.0※1，※2

Connector 1.0（DB Connector）※3

JTA 1.0.1（ただし，localだけ）※4

注※1

接続に使用するJDBCドライバが，該当するバージョンの仕様で規定された機能をサポートしている必要があります。

注※2

接続できるドライバは，Oracle JDBC Thin Driverだけです。

注※3

トランザクションなし，またはローカルトランザクションのDB Connectorを使用できます。

注※4

リソースアダプタのDD（ra.xml）のtransaction-supportでLocalTransactionを指定し，ビジネスロジック中にリモートでJavaVMの呼び出しをしない場合に，ローカルトランザクションが利用できます。

また，バッチサーバから次のEJBを呼び出せます。ただし，EJBの呼び出し方法はリモート呼び出しとなります。ローカル呼び出しはできません。

EJB 2.0

EJB 2.1

EJB 3.0

以降の項で，バッチサーバの各モジュールの概要を説明します。

2.4.3　バッチアプリケーション

バッチアプリケーションとは，バッチ処理を実装したJavaアプリケーションです。バッチアプリケーションは，一つのバッチサーバにつき一つ実行できます。

バッチアプリケーションを開始するには，アプリケーションサーバで提供しているバッチ実行コマンドを使用します。バッチサーバでは，バッチ実行コマンドによるバッチアプリケーションの実行リクエストを受けて，バッチアプリケーションを開始します。JP1/AJSと連携すると，バッチ実行コマンドをJP1のジョブとして定義できるので，バッチアプリケーションの自動実行ができます。

また，バッチアプリケーションのスケジューリング機能を使用すると，バッチアプリケーションの実行リクエストはスケジュールキューによって制御され，自動的にバッチサーバへ振り分けられます。複数のバッチアプリケーションを同時に開始したい場合に，バッチアプリケーションのスケジューリング機能を使用すると，バッチサーバの数や，どのバッチサーバで実行するかを意識する必要がありません。なお，バッチアプリケーションのスケジューリング機能を使用しない場合には，バッチアプリケーションごとにバッチサーバを用意してください。

バッチアプリケーションの詳細については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「2.　バッチサーバによるアプリケーションの実行」を参照してください。

2.4.4　バッチサービス

バッチアプリケーションを実行するアプリケーションサーバでは，バッチサービスを提供しています。バッチサービスとは，バッチアプリケーションを実行するための機能です。バッチサービスでは，次の図に示す機能を提供しています。

図2‒8　バッチサービスで提供している機能

バッチアプリケーション実行機能

バッチアプリケーションを開始したり，強制停止したりするための機能を提供しています。

EJBアクセス機能

バッチアプリケーションからJ2EEサーバのEJBにアクセスするための機能を提供しています。EJBアクセス機能はJ2EEサービスを使用します。

リソース接続機能

バッチアプリケーションからデータベースに接続するための機能を提供しています。リソース接続機能は，J2EEサービスおよびJ2EEリソースを使用します。

GC制御機能

バッチアプリケーションでリソース排他をしているときに，GCの実行を制御するための機能を提供しています。

ネーミング管理機能

EJBまたはリソースを参照するときに，名前解決をするための機能を提供しています。ネーミング管理機能はJ2EEサービスを使用します。

バッチアプリケーションのスケジューリング機能

CTMを使用して，バッチアプリケーションの実行をスケジューリングするための機能を提供しています。

バッチサービスで提供するそれぞれの機能については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「2.3　バッチアプリケーション実行機能」を参照してください。

2.4.5　J2EEサービス

J2EEサービスでは，次に示す機能およびAPIを提供しています。

トランザクション管理，およびネーミング管理の機能

JNDI，JDBC，JTA，RMI-IIOPなどのAPI

J2EEサービスは，バッチアプリケーションからデータベースに接続したり，EJBを呼び出したりするときに利用されます。

J2EEサービスでは，アプリケーションサーバの構成ソフトウェアの機能のほか，アプリケーションサーバ以外の製品の機能も使用します。J2EEサービスを実現する，ソフトウェア製品またはアプリケーションサーバの構成ソフトウェアを次の表に示します。

表2‒4　J2EEサービスを実現する，製品または構成ソフトウェア

分類

製品または構成ソフトウェア

サービス

ネーミング管理

Component Container※

TPBroker※

トランザクション管理

API

JNDI

Component Container※

JTA

RMI-IIOP

TPBroker※

JDBC Standard Extension

HiRDB Type4 JDBC Driver

Oracle JDBC Thin Driver

SQL ServerのJDBCドライバ

JDBC

注※　アプリケーションサーバの構成ソフトウェアです。

2.4.6　J2EEリソース

J2EEリソースはリソースと接続するために使用します。バッチサーバではリソースとしてデータベースを利用できます。データベースに接続するには，アプリケーションサーバで扱うJ2EEリソースのうちリソースアダプタを使用します。

J2EEリソースの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.　リソース接続とトランザクション管理」を参照してください。

2.4.7　コンテナ拡張ライブラリ

アプリケーションが利用する共通のライブラリをコンテナ拡張ライブラリといいます。このライブラリを利用することによって，バッチアプリケーションからユーザ作成の共通のライブラリを呼び出せるようになります。

コンテナ拡張ライブラリについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「19.　コンテナ拡張ライブラリ」を参照してください。

2.5　システムの目的に応じたアプリケーションの構成を決める（オンライン処理を実行する業務の場合）

この節では，システムの目的に応じたアプリケーションの構成の検討について説明します。この節で説明するのは，J2EEアプリケーションの場合の構成です。また，必要となるソフトウェアについても説明します。

アプリケーションサーバで実現できるアプリケーションの機能については，次に示すマニュアルの機能の分類に関する説明を参照してください。

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 拡張編」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 互換編」の「1.1　機能の分類」

2.5.1　動作させるJ2EEアプリケーションの検討

システムで動作させるJ2EEアプリケーションについて検討します。

システムの目的に応じたアプリケーションの構成を明確にすることで，システム構成の基本的な部分が決まります。例えば，クライアントにWebブラウザを使用する場合には，アプリケーションはサーブレットやJSPで構成されるWebアプリケーションにして，Webブラウザからのリクエストを受け付けるようにします。また，必要に応じて，サーブレットやJSPからEnterprise Beanを呼び出すようなアプリケーションも考えられます。この場合は，システムはWebクライアントシステムにして，Webサーバの配置や，そこからアプリケーションサーバを呼び出す場合の連携方法を検討する必要があります。

また，業務システムの基幹部分を構成するシステムを構築する場合は，クライアントにEJBクライアントアプリケーションを使用する構成が考えられます。呼び出し先のEnterprise Beanの種類によっては，CTMを利用することも検討できます。

アプリケーションに含まれるコンポーネントの種類とシステム構成との関係については，「3.3　アプリケーションの構成を検討する」で詳しく説明します。そのほか，J2EEアプリケーションを実行する場合のシステム構成の検討方法については，「3.　システム構成の検討（J2EEアプリケーション実行基盤）」を参照してください。

システムの目的に応じて使用できる機能については，次に示すマニュアルのシステムの目的と機能の対応に関する説明を参照してください。

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 拡張編」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「1.2　システムの目的と機能の対応」

また，アプリケーション開発の手順については，マニュアル「アプリケーションサーバ アプリケーション開発ガイド」を参照してください。

2.5.2　使用するプロセスの検討と必要なソフトウェアの準備

アプリケーションサーバのシステムでは，使用するプロセスの種類とその配置によってシステム構成が決まります。

アプリケーションサーバのシステムはWebフロントシステムとバックシステムで構成されます。Webフロントシステムは，クライアントとしてWebブラウザを使用するシステムです。バックシステムは，クライアントとしてEJBクライアントを使用するシステムです。システムの分類については，「3.1.1　システムの目的と構成」で詳しく説明します。

ここでは，まず，システムの分類に応じて必要なプロセスとソフトウェアについて説明します。次に，使用する機能に応じて必要なプロセス，モジュールおよびソフトウェアについて説明します。なお，これらのプロセス，モジュール，ソフトウェアをどのようにシステムに配置するかについては，「3.　システム構成の検討（J2EEアプリケーション実行基盤）」で説明します。

(1)　システムの分類に応じて必要なプロセス

システムの分類に応じて必要なプロセスを次に示します。これらは，使用する機能に関係なく共通して必要なプロセスです。アプリケーションサーバによって提供されます。

Webフロントシステムの場合に必要なプロセス

Webフロントシステムの場合に必要なプロセスは次のとおりです。

Webサーバ※

J2EEサーバ

PRFデーモン

なお，アプリケーションサーバに含まれるWebサーバは，HTTP Serverです。クライアントには，Webブラウザを使用します。

注※

Webサーバを経由しないでJ2EEサーバのNIO HTTPサーバに直接アクセスする場合は，Webサーバのプロセスは不要です。

ポイント

Webサーバ選択の指針

Webクライアントシステムでは，Webクライアントからのリクエストを，次のどちらかのWebサーバを利用して処理できます。

リバースプロキシ機能を有効にしたWebサーバ

プロキシモジュールを組み込んだWebサーバと連携してリクエストを処理します。Webサーバが受信したリクエストは，プロキシモジュールを経由して，J2EEサーバのNIO HTTPサーバに送信されます。

NIO HTTPサーバ

Webコンテナ機能の一部として提供される，J2EEサーバのプロセス内で機能するHTTPサーバでリクエストを処理します。WebクライアントからのリクエストをJ2EEサーバで直接受信できます。

なお，アプリケーションサーバでは，リバースプロキシ機能を有効にしたWebサーバを利用することを推奨しています。また，デフォルトの設定で使用する場合は，リバースプロキシ機能を有効にしたWebサーバが利用されます。特に性能を重視したシステムを構築したい場合に，NIO HTTPサーバへの直接アクセスを検討してください。

それぞれのWebサーバの特徴を次の表に示します。Webサーバを選択する場合の指針にしてください。

表2‒5　Webサーバ選択の指針

比較項目

リバースプロキシ機能を有効にしたWebサーバ

NIO HTTPサーバ

Webサーバとして利用できる機能

○

HTTP Server（Apacheの機能をベースにしたWebサーバ）またはMicrosoft IISが提供する多様な機能を利用できます。

△

サーブレット，JSPまたはHTMLから構成されるWebアプリケーションへのアクセスを目的にした最小限の機能だけが提供されています。※1

構築，運用の容易性

○

構築時には，Webサーバの環境設定が必要です。運用時には，Webサーバの起動，停止が必要です。ただし，Smart Composer機能のコマンドで構築・運用できるため，煩雑な操作は不要です。

○

構築時のWebサーバの環境設定，および運用時のWebサーバの起動，停止の操作が不要です。

HTML，JPEGなどの静的コンテンツに対するアクセス性能

○

静的コンテンツをWebサーバ上に配置することによって，最適な性能を確保できます。

なお，Webコンテナ上に配置する場合は，リバースプロキシ経由のアクセスになるため，アクセス処理に時間が掛かります。

○

リバースプロキシを経由しないでアクセスできるため，最適な性能を確保できます。

サーブレット，JSPなどの動的コンテンツに対するアクセス性能

△

リバースプロキシを経由するためのアクセス処理に時間が掛かります。

○

リバースプロキシを経由しないでアクセスできるため，最適な性能を確保できます。

注意事項

インターネットに接続する場合には，セキュリティ上の観点から，DMZを確保する構成にして，リバースプロキシをフロントに配置することを推奨します。

また，リバースプロキシを配置しない場合は，リバースプロキシを組み込んだWebサーバをDMZに配置することで，同様の効果を得ることもできます。※2

インターネットに接続する場合には，セキュリティ上の観点からDMZを確保する構成にして，必ずリバースプロキシをフロントに配置してください。※2

（凡例）○：優れている。　△：優れていない。

注※1　NIO HTTPサーバで使用できる機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「7.2.2　NIO HTTPサーバで使用できる機能」を参照してください。

注※2　DMZへのWebサーバの配置については，マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「3.3　DMZへのリバースプロキシの配置を検討する」を参照してください。

バックシステムの場合に必要なプロセス

バックシステムの場合に必要なプロセスは次のとおりです。

J2EEサーバ

PRFデーモン

バックシステムのクライアントには，EJBクライアントを使用します。EJBクライアントとは，Enterprise Beanを呼び出す，Servlet，JSP，ほかのEnterprise Bean，EJBクライアントアプリケーション，またはほかの業務システムのことです。

EJBクライアントとしてEJBクライアントアプリケーションを使用するとき，Windowsの場合はクライアントマシンをClientを使用して構築することもできます。アプリケーションサーバまたはClientのどちらのソフトウェアを使用した場合も，必要に応じてPRFデーモンを起動できます。

参考

CTMを使用したシステムの場合，クライアントとしてTPBrokerやTPBroker Object Transaction Monitorのクライアントなど，EJBクライアント以外のクライアントも使用できます。

(2)　使用する機能に応じて必要なプロセスおよびモジュール

使用する機能に応じて必要なプロセスおよびモジュールについて説明します。アプリケーションサーバによって提供されるものと，アプリケーションサーバ以外のソフトウェアによって提供されるものがあります。

使用する機能ごとに必要なプロセスのうち，アプリケーションサーバによって提供されるものを次の表に示します。これらのプロセスは，アプリケーションサーバをインストールしたマシンで起動できます。

表2‒6　機能ごとに必要なプロセスまたはモジュール（アプリケーションサーバによって提供されるもの）

機能

必要なプロセス

サーバ間連携でCTMを利用する／CTMを利用して負荷を分散する

CTMデーモン

CTMレギュレータ

CTMドメインマネジャ

グローバルCORBAネーミングサービス

スマートエージェント

Management Serverを利用して運用管理する

Management Server

運用管理エージェント

CORBAネーミングサービスをアウトプロセスで起動する

CORBAネーミングサービス

使用する機能ごとに必要なプロセスおよびモジュールのうち，アプリケーションサーバ以外の製品が提供するプロセスおよびモジュールを，表2-7および表2-8に示します。

表2‒7　機能ごとに必要なモジュール（アプリケーションサーバ以外によって提供されるもの）と提供するソフトウェア

機能

モジュール

提供するソフトウェア

備考

データベース（HiRDB）と接続する

HiRDB Type4 JDBC Driver

HiRDB Server Version 10

HiRDB/Run Time Version 10

HiRDB/Developer's Kit Version 10

HiRDB Developer's Suite Version 10

HiRDB Server Version 9

HiRDB Server with Additional Function Version 9

HiRDB/Run Time Version 9

HiRDB/Developer's Kit Version 9

HiRDB Developer's Suite Version 9

JDBCドライバとしてHiRDB Type4 JDBC Driverを使用する場合に必要になります。

データベース（Oracle）と接続する

Oracle JDBC Thin Driver

Oracle JDBC Thin Driver

JDBCドライバとしてOracle JDBC Thin Driverを使用する場合に必要になります。

データベース（SQL Server）と接続する

SQL Server JDBC Driver

SQL Server JDBC Driver

JDBCドライバとしてSQL Server JDBC Driverを使用する場合に必要になります。

データベース（XDM/RD E2）と接続する

HiRDB Type4 JDBC Driver

HiRDB Server Version 10

HiRDB/Run Time Version 10

HiRDB/Developer's Kit Version 10

HiRDB Developer's Suite Version 10

JDBCドライバとしてHiRDB Type4 JDBC Driverを使用する場合に必要になります。

Message Queueサーバと接続する

TP1/Message Queue - Access

TP1/Message Queue - Access

−

OpenTP1のSPPと接続する

TP1 Connector

TP1 Connector

−

TP1/Client/J

TP1/Client/J

−

（凡例） −：該当しません。

注　モジュールは，J2EEサーバのプロセスに含まれて動作します。

表2‒8　機能ごとに必要なプロセス（アプリケーションサーバ以外によって提供されるもの）と提供するソフトウェア

機能

必要なプロセス

提供するソフトウェア

クラスタソフトウェアを使用して障害時に系を切り替える

Windows Server Failover Cluster

Windows Server Failover Cluster

HAモニタ

HAモニタ

2.6　システムの目的に応じたアプリケーションの構成を決める（バッチ処理を実行する業務の場合）

この節では，システムの目的に応じたアプリケーションの構成の検討について説明します。この節で説明するのは，バッチアプリケーションの場合の構成です。また，必要となるソフトウェアについても説明します。

アプリケーションサーバで実現できるアプリケーションの機能については，次に示すマニュアルの機能の分類に関する説明を参照してください。

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 拡張編」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「1.1　機能の分類」

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「1.1　機能の分類」

2.6.1　動作させるバッチアプリケーションの検討

システムで動作させるバッチアプリケーションについて検討します。バッチアプリケーションとは，バッチ処理として実行する，定型的・定期的な処理を実装したJavaアプリケーションのことです。

システム構成の基本的な部分は，バッチアプリケーションで実装した処理内容によって決まります。例えば，データベース上のデータを参照・更新するような処理を実装した場合は，トランザクションの管理方法や，リソースとの接続方法を検討する必要があります。また，ほかのJ2EEサーバ上の業務処理プログラム（Enterprise Bean）を呼び出す処理を実装した場合は，サーバ間の連携方法について，検討する必要があります。

バッチアプリケーションを実行する場合のシステム構成の検討方法については，「4.　システム構成の検討（バッチアプリケーション実行基盤）」を参照してください。

システムの目的に応じて使用できる機能については，次に示すマニュアルのシステムの目的と機能の対応に関する説明を参照してください。

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 拡張編」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「1.2　システムの目的と機能の対応」

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「1.2　システムの目的と機能の対応」

2.6.2　使用するプロセスの検討と必要なソフトウェアの準備

アプリケーションサーバのシステムでは，使用するプロセスの種類とその配置によってシステム構成が決まります。

ここでは，まず，必要なプロセスとソフトウェアについて説明します。次に，使用する機能に応じて必要なプロセス，モジュールおよびソフトウェアについて説明します。なお，これらのプロセス，モジュール，ソフトウェアをどのようにシステムに配置するかについては，「4.　システム構成の検討（バッチアプリケーション実行基盤）」で説明します。

(1)　必要なプロセス

必要なプロセスを次に示します。これらは，使用する機能に関係なく共通して必要なプロセスです。アプリケーションサーバによって提供されます。

バッチサーバ

PRFデーモン

(2)　使用する機能に応じて必要なプロセスおよびモジュール

使用する機能に応じて必要なプロセスおよびモジュールについて説明します。アプリケーションサーバによって提供されるものと，アプリケーションサーバ以外のソフトウェアによって提供されるものがあります。

使用する機能ごとに必要なプロセスのうち，アプリケーションサーバによって提供されるものを次の表に示します。これらのプロセスは，アプリケーションサーバをインストールしたマシンで起動できます。

表2‒9　機能ごとに必要なプロセスまたはモジュール（アプリケーションサーバによって提供されるもの）

機能

必要なプロセス

Management Serverを利用して運用管理する

Management Server

運用管理エージェント

CTMを利用してバッチアプリケーションの実行をスケジューリングする

CTMデーモン

CTMレギュレータ

CTMドメインマネジャ

グローバルCORBAネーミングサービス

スマートエージェント

使用する機能ごとに必要なプロセスおよびモジュールのうち，アプリケーションサーバ以外の製品が提供するプロセスおよびモジュールを，表2-10および表2-11に示します。

表2‒10　機能ごとに必要なモジュール（アプリケーションサーバ以外によって提供されるもの）と提供するソフトウェア

機能

モジュール

提供するソフトウェア

備考

データベース（HiRDB）と接続する

HiRDB Type4 JDBC Driver

HiRDB Server Version 10

HiRDB/Run Time Version 10

HiRDB/Developer's Kit Version 10

HiRDB Developer's Suite Version 10

HiRDB Server Version 9

HiRDB Server with Additional Function Version 9

HiRDB/Run Time Version 9

HiRDB/Developer's Kit Version 9

HiRDB Developer's Suite Version 9

JDBCドライバとしてHiRDB Type4 JDBC Driverを使用する場合に必要になります。

データベース（Oracle）と接続する

Oracle JDBC Thin Driver

Oracle JDBC Thin Driver

JDBCドライバとしてOracle JDBC Thin Driverを使用する場合に必要になります。

データベース（SQL Server）と接続する

SQL Server JDBC Driver

SQL Server JDBC Driver

JDBCドライバとしてSQL Server JDBC Driverを使用する場合に必要になります。

データベース（XDM/RD E2）と接続する

HiRDB Type4 JDBC Driver

HiRDB Server Version 10

HiRDB/Run Time Version 10

HiRDB/Developer's Kit Version 10

HiRDB Developer's Suite Version 10

JDBCドライバとしてHiRDB Type4 JDBC Driverを使用する場合に必要になります。

注　モジュールは，バッチサーバのプロセスに含まれて動作します。

表2‒11　機能ごとに必要なプロセス（アプリケーションサーバ以外によって提供されるもの）と提供するソフトウェア

機能

必要なプロセス

提供するソフトウェア

クラスタソフトウェアを使用して障害時に系を切り替える

Windows Server Failover Cluster

Windows Server Failover Cluster

HAモニタ

HAモニタ

2.7　運用方法を検討する

この節では，アプリケーションサーバのシステムの運用方法を検討するときに考慮することについて説明します。

アプリケーションサーバのシステムの運用では，Management Serverというプロセスを利用できます。Management Serverを利用すると，アプリケーションサーバのシステムを構成する複数のプロセスを論理サーバとして扱い，一括して運用できるようになります。

なお，業務システムは一般的に，アプリケーションサーバだけではなくほかのプログラムで構築されるシステムと組み合わせて構築されています。運用方法の検討では，アプリケーションサーバのシステムのほかに，これらのプログラムも合わせてシステム全体をどのように運用するかを検討する必要があります。

2.7.1　JP1と連携したシステムの運用

Management Serverを利用して運用している場合，統合システム運用管理用ミドルウェアJP1のプログラムと連携して，次のようなシステムの運用を実現できます。

JP1/IMと連携したシステム全体の集中監視

JP1/AJSと連携したシステム全体の自動運転

それぞれのプログラムとの連携によって実現できる機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」を参照してください。

なお，Management Serverを利用しないで運用している場合でも，JP1/AJSを利用したシステムの自動運転は実現できます。ただし，その場合，JP1/AJSのジョブとして，サーバ管理コマンドなどを一から定義する必要があります。

2.7.2　クラスタソフトウェアと連携したシステムの運用

クラスタソフトウェアと連携すると，障害発生時などに自動的に系切り替えができます。

また，J2EEサーバをクラスタ構成にしている場合，N個のJ2EEサーバに対して1個のリカバリ専用サーバを配置することで，障害発生時にトランザクションを解決してリソースを解放できます。ただし，この機能は，バッチサーバには該当しません。

アプリケーションサーバのシステムでは，OSごとに，次のクラスタソフトウェアを使用できます。

Windowsの場合

Windows Server Failover Cluster

AIXまたはLinuxの場合

HAモニタ

クラスタソフトウェアと連携するためには，システムをManagement Serverを利用して運用している必要があります。

クラスタソフトウェアと連携したシステムの運用をする場合のシステム構成については，「3.11　クラスタソフトウェアを使用した障害時の系切り替えを検討する」を参照してください。

3　システム構成の検討（J2EEアプリケーション実行基盤）

この章では，J2EEアプリケーション実行基盤を構築する場合のシステム構成について説明します。システムを設計する流れに沿って，それぞれの設計項目でのシステム構成の標準的なパターンを示します。また，それぞれのポイントで意識する必要があるコンポーネント，プロセスおよび処理の流れについて説明します。

バッチアプリケーション実行基盤のシステム構成を検討する場合は，「4.　システム構成の検討（バッチアプリケーション実行基盤）」を参照してください。

3.1　システム構成を検討するときに考慮すること

この節では，アプリケーションサーバを使用するシステムの構成を検討するときに考慮する必要があることについて説明します。

システム構成を検討する場合，J2EEアプリケーションで使用する機能に応じて，その機能を実現するために必要なプロセスを意識し，それぞれを各マシンに適切に配置することが必要です。このとき，アプリケーションサーバの要件である，信頼性，可用性なども十分に考慮する必要があります。

3.1.1　システムの目的と構成

アプリケーションサーバで構築するシステムは，目的とする業務および実行するJ2EEアプリケーションの要件と特徴に応じて，次の2種類のシステムに分類できます。

Webフロントシステム

バックシステム

Webフロントシステムは，Webベースのシステムの場合に，フロントエンドであるWebブラウザから送信されるリクエストを受け付けて，そのリクエストを処理するシステムです。このシステムでは，アプリケーションサーバ上のJ2EEサーバで，サーブレット，JSPおよびEnterprise Beanが動作します。

Webフロントシステムの背後で動作する，複数の業務システムに共通な業務サービスを実行するためのシステムが，バックシステムです。バックシステムにリクエストを送信するのは，次のようなコンポーネント，アプリケーションまたはシステムです。

Webフロントシステム上で動作しているサーブレット，JSPまたはEnterprise Bean

EJBクライアントマシンで動作しているEJBクライアントアプリケーション

ほかの業務システム

アプリケーションサーバのシステムは，目的や規模に応じて，Webフロントシステムとバックシステムを一つまたは複数組み合わせて構成されます。

Webフロントシステムとバックシステムの構成例を次の図に示します。

図3‒1　Webフロントシステムとバックシステムの構成例

アプリケーションサーバのシステム構成を検討する場合，まず，システムの基本構成として，システム全体をどのようなシステムの組み合わせで構成するかを検討します。次に，構成要素であるそれぞれのシステムの目的と，クライアントからアクセスされるポイントを明確にします。それから，信頼性，性能，拡張性などアプリケーションサーバに共通して求められる要件や，EISとの接続や負荷分散の実現などそのシステム独自の要件を満たすためにはどのようにソフトウェアやプロセスを配置するのがよいのかを検討し，最適なシステム構成を設計していきます。

3.1.2　システム構成の設計手順

システム構成は，次の流れで設計します。

図3‒2　システム構成を設計する流れ（J2EEアプリケーション実行基盤の場合）

(1)　アプリケーションの構成を検討する

各システム上で動作するアプリケーションで使用するコンポーネントの構成を明確にして，アプリケーションのどのコンポーネントをアクセスポイントにするかを決定します。詳細は，「3.3　アプリケーションの構成を検討する」を参照してください。

アクセスポイントとは，クライアントからリモートでアクセスされる場合に，アプリケーションのリクエスト受信窓口として動作するコンポーネントです。アクセスポイントになるコンポーネントの種類によって，実現できるシステム構成が決まります。

また，アプリケーションがデータベースなどのリソースに接続するかどうかを決めます。接続するリソースに対応して，使用するリソースアダプタが決まります。

なお，ここで検討したアクセスポイントになるコンポーネントの種類によって，それ以降のシステム構成の設計で検討が必要な項目が異なります。アクセスポイントになるコンポーネントの種類ごとに検討が必要な項目を，次の表に示します。

表3‒1　アクセスポイントになるコンポーネントの種類ごとに検討が必要な項目

設計項目

アクセスポイントになるコンポーネントの種類

参照先

Webフロントシステム

バックシステム

サーブレット

／JSP

Session Bean

／Entity Bean

CTMを使用する場合のStateless Session Bean

Message-

driven Bean

クライアントとサーバの構成

◎

◎

◎

−

3.4

サーバ間での連携方法

−

△

△

−

3.5

トランザクションの種類

◎

◎

◎

◎

3.6

ロードバランスクラスタによる負荷分散方式

△

△

△

−

3.7

サーバ間での非同期通信

−

−

−

◎

3.8

運用管理プロセスの配置

◎

◎

◎

◎

3.9

セッション情報を引き継ぐための構成

△

△

−

−

3.10

クラスタソフトウェアを使用した系切り替えを実現するための構成

△

△

△

△

3.11

ファイアウォールの配置

△

△

△

△

※2

DMZへのリバースプロキシの配置

　△※1

−

−

−

※3

性能解析トレースファイルを出力するプロセスの配置

◎

◎

◎

◎

3.12

アプリケーションサーバ以外の製品との連携

△

△

△

△

3.13

任意のプロセスの運用管理

△

△

△

△

3.14

（凡例）

◎：必ず検討する項目。

△：必要に応じて検討する項目。

−：検討する必要がない項目。

注※1　Webサーバを経由しないで直接NIO HTTPサーバを使用する場合は必ず検討してください。

注※2　マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「3.2　ファイアウォールを使用する構成を検討する」を参照してください。

注※3　マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「3.3　DMZへのリバースプロキシの配置を検討する」を参照してください。

(2)　クライアントとサーバの構成を検討する

アクセスポイントになるコンポーネントに応じて，クライアントとサーバの対応を明確にします。システムに配置したアプリケーションサーバは，その役割に応じて，クライアントとして機能したり，サーバとして機能したりします。

クライアントとサーバの構成の考え方を次の図に示します。

図3‒3　クライアントとサーバの構成の考え方

この構成の場合，APサーバ1はWebクライアントに対するサーバに当たり，アクセスポイントはサーブレット／JSPになります。また，APサーバ1はAPサーバ2に対してのクライアントになります。APサーバ2はAPサーバ1に対するサーバに当たり，アクセスポイントはEnterprise Beanになります。

詳細は，「3.4　クライアントとサーバの構成を検討する」を参照してください。

(3)　サーバ間での連携方法を検討する

サーバが複数ある場合に，サーバ間で連携するかどうか，連携する場合はどのように連携するかを検討します。サーバ間連携とは，クライアントから見て垂直に並んだ複数のサーバから，ほかのサーバ上にあるアクセスポイントのコンポーネントを呼び出して処理を実行する連携方法です。

サーバ間連携の考え方を次の図に示します。

図3‒4　サーバ間連携の考え方

この構成の場合，APサーバ1とAPサーバ2は，APサーバ3のクライアントになり，それぞれのサーブレット，JSPまたはMessage-driven Beanから，APサーバ3のSession Beanを呼び出します。

サーバ間連携と同時に，必要に応じて，アプリケーションを分割するなど，アプリケーションの形態も見直します。また，複数のシステム間で連携する場合も，それぞれのシステムに含まれるサーバ間の連携方法を検討する必要があります。

詳細は，「3.5　サーバ間での連携を検討する」を参照してください。

(4)　トランザクションの種類を検討する

データベースなどのリソースを使用するシステムの場合に，トランザクション管理の対象になるリソースの数に応じて，使用するトランザクションの種類を検討します。詳細は，「3.6　トランザクションの種類を検討する」を参照してください。

(5)　ロードバランスクラスタによる負荷分散方式を検討する

システムの可用性を高めるために，ロードバランスクラスタ構成によって負荷を分散するかどうか検討します。負荷を分散する場合は，アクセスポイントになるコンポーネントの種類に応じてどの方式で実現するかを検討します。詳細は，「3.7　ロードバランスクラスタによる負荷分散方式を検討する」を参照してください。

(6)　サーバ間の非同期通信をするための構成を検討する

Message-driven Beanを使用してアプリケーションサーバ間での非同期通信をする場合に，利用する製品に応じたシステムの構成を検討します。なお，Message-driven Beanによる負荷分散についても，あわせて検討します。詳細は，「3.8　サーバ間で非同期通信をする場合の構成を検討する」を参照してください。

(7)　運用管理プロセスの配置を検討する

運用管理プロセス（Management Server）を利用する場合に，管理対象にする範囲によって，Management Serverをどのサーバマシンに配置するかを検討します。詳細は，「3.9　運用管理プロセスの配置を検討する」を参照してください。

(8)　セッション情報の引き継ぎを検討する

Webフロントシステムで動作するJ2EEアプリケーションまたはJ2EEサーバに障害が発生した場合に，セッション情報をほかのJ2EEサーバに引き継ぐための構成について検討します。詳細は，「3.10　セッション情報の引き継ぎを検討する」を参照してください。

(9)　クラスタソフトウェアを使用した障害時の系切り替えまたはリソース解放を実現するための構成を検討する

一つのアプリケーションサーバに障害が発生した場合およびシステムを保守する場合を考慮して，クラスタソフトウェアによって系切り替えを実行して，システムの運用を続行させるための構成を検討します。このとき，実行系と待機系がそれぞれ相互に切り替え対象になる構成（相互スタンバイ構成）も検討できます。また，トランザクションサービスを使用している場合は，障害発生時にリソースを解放するためのリカバリサーバを利用するための構成も検討します。詳細は，「3.11　クラスタソフトウェアを使用した障害時の系切り替えを検討する」を参照してください。

(10)　ファイアウォールの配置を検討する

アプリケーションサーバおよびリソースのセキュリティを確保するための，ファイアウォールの配置について検討します。ファイアウォールは，アクセスポイントになるコンポーネントの前に配置して，アクセスポイントに対する不正なアクセスを防止します。ファイアウォールを配置するポイントは，アクセスポイントによって決まります。

基本的なファイアウォールの配置については，マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「3.2　ファイアウォールを使用する構成を検討する」を参照してください。

侵入検知システムも含めたセキュリティ構成の詳細については，マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「4.11.2　ファイアウォールと侵入検知システムを配置する」を参照してください。

(11)　DMZへのリバースプロキシの配置を検討する

インターネットと接続するシステムの場合などには，アプリケーションサーバおよびリソースのセキュリティを確保するために，DMZへのリバースプロキシの配置を検討します。詳細は，マニュアル「アプリケーションサーバ機能解説 セキュリティ管理機能編」の「3.3　DMZへのリバースプロキシの配置を検討する」を参照してください。

(12)　性能解析トレースファイルを出力するプロセスを配置する

性能解析に使用するプロセスであるPRFデーモン（パフォーマンストレーサ）の配置について検討します。詳細は，「3.12　性能解析トレースファイルを出力するプロセスを配置する」を参照してください。

(13)　アプリケーションサーバ以外の製品との連携を検討する

システムの集中監視，構成管理，自動運転などをしたい場合には，必要に応じてJP1などのアプリケーションサーバ以外の製品との連携を検討します。詳細は，「3.13　アプリケーションサーバ以外の製品との連携を検討する」を参照してください。

(14)　任意のプロセスを運用管理の対象にする

ユーザが定義する任意のプロセスをユーザサーバとしてManagement Serverによる運用管理の対象にしたい場合には，ユーザサーバの配置について検討します。詳細は，「3.14　任意のプロセスを運用管理の対象にする」を参照してください。

(15)　そのほかの構成を検討する

(14)までで検討した以外の構成について検討します。また，必要に応じて，旧バージョンのアプリケーションサーバで構築しているシステムとの互換性を持つシステム構成も検討します。

3.1.3　システム構成の考え方

ここでは，システム構成を検討するときの基本的な考え方について説明します。アプリケーションサーバで構築する実行環境は，複数のプロセスで構成されます。また，各プロセスには，提供する機能ごとに，複数のレイヤがあります。このレイヤを，機能レイヤといいます。

実行環境では，各機能レイヤをそれぞれ異なるサーバに配置できます。配置は，システムの規模や目的に応じて検討する必要があります。

機能レイヤの配置例を次の図に示します。

図3‒5　機能レイヤの配置例

ここでは，次の機能レイヤを実行環境に配置する場合の構成の考え方について説明します。

Webサーバ

Webコンテナ

CTM

EJBコンテナ

JCA

EIS

ネーミングサービス

運用管理サーバ

(1)　WebサーバとWebコンテナ（J2EEサーバ）の配置

Webサーバは，Webコンテナに対するHTTPリクエストのディスパッチ処理のほか，業務処理に含まれる静的コンテンツの処理を実行します。Webコンテナは，J2EEサーバの一部として動作して，サーブレットおよびJSPを実行するための基盤になる機能です。WebサーバとWebコンテナは同じホストまたは異なるホストに配置できます。なお，Webサーバを経由しないでJ2EEサーバのNIO HTTPサーバに直接アクセスする場合は，Webサーバは不要です。

これを踏まえた上で，次の説明を参照して，システム構成を決定してください。

「3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）」

「3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（NIO HTTPサーバに直接アクセスする場合）」

(2)　CTMとEJBコンテナ（J2EEサーバ）の配置

CTMは，OLTP技術を用いて，クライアントからのリクエストをスケジューリングする機能です。EJBコンテナは，J2EEサーバの一部として動作して，Enterprise Beanの実行および通信，トランザクション管理などのシステムレベルのサービスを提供するための基盤になる機能です。

CTMでは，EJBコンテナに対して送信されたIIOPリクエストのスケジュール処理と負荷分散処理を実行します。CTMはIIOPリクエストを処理するために特化された機能レイヤなので，EJBコンテナと別のホストに配置する必要はありません。IIOPリクエストの負荷分散は，CTM間のデータ転送で実現されます。ただし，CTMによる負荷分散の対象になるのは，Stateless Session Beanだけです。

CTMとEJBコンテナの関係は，1対多にして，それぞれロードバランスクラスタ構成にすることをお勧めします。これによって，スループットが向上します。また，拡張性と性能が高いシステムを構築できます。また，クラスタ構成にすれば障害発生時の部分縮退や部分回復ができるようになるので，信頼性と可用性も向上します。

これを踏まえた上で，次の説明を参照して，システム構成を決定してください。

「3.4.4　CTMを使用する場合にStateless Session Beanをアクセスポイントに使用する構成」

「3.7.4　CTMを利用した負荷分散（Stateless Session Beanの場合）」

(3)　JCAとEISの配置

JCAは，既存システムやデータベースなどのEISと接続するためのサポート機能を提供します。

EISに対して，JCAではコネクションプーリング処理をします。EISを一つのサーバで構築している場合，JCAとEISの関係は，多対1になります。EISを複数のサーバで構築している場合は，JCAとEISの関係は多対多になります。JCAでは，EISとの接続で障害が発生した場合に，自動回復する機能を持っているので，信頼性と可用性が確保されています。

(4)　ネーミングサービスの配置

ネーミングサービスは，名前からオブジェクトを利用できるようにするネーミング管理機能を提供します。ネーミングサービスは，TPBrokerによって提供されるサービスです。J2EEサーバのインプロセスで起動することをお勧めします。

インプロセスで起動することによって，アプリケーションサーバ内のプロセス数が削減できます。また，個別プロセスとしての起動処理や停止処理が不要になり，運用性が向上します。

(5)　運用管理プロセスの配置

Management Serverは，アプリケーションサーバ全体を運用管理するための機能を集約したサーバです。システムの運用管理，監視の対象範囲となるドメイン内に一つ配置します。

ここでは，J2EEサーバなどのほかのプロセスとは別のホストに配置した構成を使用して説明していますが，同じホストに配置した構成にすることもできます。

運用管理，監視の対象になるプロセスを配置したホストには，それぞれ運用管理エージェントを起動します。運用管理エージェントは，運用管理サーバからの指示を受けて，各ホストで操作を実行します。

運用管理者は，Smart Composer機能またはManagement Serverのコマンドを使用して，運用管理を実行します。これらのコマンドは，Management Serverを配置したホストで実行します。

参考

開発環境やテスト環境で運用管理を実行する場合には，必要に応じて次の機能も使用できます。

運用管理ポータル

WebブラウザからManagement Serverを配置したホストにアクセスして実行します。

なお，運用管理ポータルを使用する場合は，必要に応じて管理クライアントマシンを用意してください。

運用管理プロセスを配置した構成については，「3.9　運用管理プロセスの配置を検討する」を参照してください。

3.2　システム構成の説明について

3章では，システム構成を検討するための，さまざまなシステム構成パターンを示して，それぞれの特徴について説明します。この節では，システム構成の説明をお読みになる前に確認していただきたい，各システム構成パターンに共通する留意点について説明します。また，この章のシステム構成図で使用する図の凡例についてもあわせて説明します。これらをご確認の上，次節以降をお読みください。

参考

ここで説明する凡例は，「4.　システム構成の検討（バッチアプリケーション実行基盤）」およびマニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「4.11.2　ファイアウォールと侵入検知システムを配置する」にも当てはまります。

3.2.1　この章のシステム構成に共通する留意点

各システム構成に共通して，次のことに留意してください。

この章では，Application Serverを使用した場合のシステム構成について説明しています。必要に応じて，この章で使用している用語を，ご利用の製品に読み替えてください。

ご利用の製品とこの章で使用している製品の対応を次の表に示します。

表3‒2　ご利用の製品とこの章で使用している製品の対応

ご利用の製品

この章で記載している製品

Developer※

Application Server

Service Architect※

Service Platform

注※　テスト環境で使用している場合にだけ読み替えが必要です。

システム構成の例では，主に，アプリケーションサーバを役割ごとに1台ずつ配置した例を示していますが，実際の構成では，スケーラビリティと可用性を考慮して負荷分散機などを使用したクラスタ構成にすることをお勧めします。これによって，トラブルが発生した場合やサーバのメンテナンスが必要な場合に，サービスが完全に止まることを防げます。負荷分散をする構成については，「3.7　ロードバランスクラスタによる負荷分散方式を検討する」を参照してください。

この章では，Management Serverを利用して運用することにした場合の例を示しています。Management Serverを利用しないで運用する場合，次のプロセスは不要ですので，省略してお読みください。

Management Server

運用管理エージェント

運用管理に必要なプロセスだけを起動するマシンを運用管理サーバマシンといいます。なお，Management Serverを利用しないで運用する場合，運用管理サーバマシンは不要です。

アクセスポイントがサーブレット／JSPのとき，この章では主に，Webサーバ連携の場合の構成例を示しています。Webサーバを経由しないでJ2EEサーバのNIO HTTPサーバに直接アクセスする場合は，次のプロセスは不要ですので，省略してお読みください。

Webサーバ

PRFデーモンは，性能解析トレースファイルを出力するためのプロセスです。アプリケーションサーバには必ず配置し，EJBクライアントには必要に応じて配置します。PRFデーモンの配置についての考え方については，「3.12　性能解析トレースファイルを出力するプロセスを配置する」を参照してください。

3.2.2　システム構成図で使用する図の凡例

ここでは，3章および4章のシステム構成図で使用する凡例を示します。

図3‒6　システム構成図で使用する図の凡例

また，ホストを表す色は，Management Serverによって運用管理する場合のホストの分類を表しています。

図3‒7　システム構成図で使用する図の凡例（ホストの分類）

なお，ここで示した以外の凡例については，それぞれの図で示します。

3.3　アプリケーションの構成を検討する

この節では，アプリケーションの構成の検討方法について説明します。

アプリケーションは，構成するコンポーネントの種類によって分類できます。分類ごとに，クライアント側から見たアクセスポイントがあります。ここでは，アプリケーションを構成するコンポーネントの種類と，各アプリケーションでアクセスポイントになるコンポーネントについて説明します。また，接続するリソースの種類に応じたリソースアダプタの種類についても説明します。

3.3.1　アプリケーションの構成とアクセスポイント

ここでは，アプリケーションを構成するコンポーネントの種類と，それぞれの構成の場合のアクセスポイントについて説明します。

アプリケーションを構成するコンポーネントには，次の種類があります。

サーブレットとJSP

Session BeanとEntity Bean

Message-driven Bean

(1)　サーブレットとJSPで構成されるアプリケーション

サーブレットとJSPは，クライアントマシンのWebブラウザに表示するプレゼンテーションを，動的に生成するためのコンポーネントです。クライアントであるWebブラウザから，HTTPまたはHTTPSによってWebサーバ経由でアクセスされます。

サーブレットとJSPで構成されるアプリケーションの場合，クライアントから見たアクセスポイントになるコンポーネントは，フロントに配置されたサーブレットまたはJSPになります。

サーブレットとJSPで構成されるアプリケーションを次の図に示します。

図3‒8　サーブレットとJSPで構成されるアプリケーション

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

サーブレットまたはJSPからは，JavaBeansやJavaクラスなど，ほかのコンポーネントを呼び出せます。また，Session BeanやEntity Beanを呼び出すこともできます。この場合も，クライアントから見たアクセスポイントとなるコンポーネントは，フロントに配置したサーブレットまたはJSPになります。

図3‒9　サーブレットとJSPからほかのコンポーネントを呼び出す場合のアクセスポイント

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

このアプリケーションは，主にWebフロントシステムで動作します。

(2)　Session BeanとEntity Beanで構成されるアプリケーション

Session BeanとEntity Beanは，ビジネスロジックを実装するためのコンポーネントです。EJBクライアントから，RMI-IIOPによってアクセスされます。なお，EJBクライアントとは，Enterprise Beanを呼び出すコンポーネントの総称です。クライアントマシンで動作するEJBクライアントアプリケーション，ほかのJ2EEサーバで動作しているサーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanが該当します。

Session BeanとEntity Beanで構成されるアプリケーションの場合，アクセスポイントになるコンポーネントは，フロントに配置されたSession BeanまたはEntity Beanになります。

Session BeanとEntity Beanで構成されるアプリケーションを次の図に示します。

図3‒10　Session BeanとEntity Beanで構成されるアプリケーション

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

Session BeanまたはEntity Beanからは，JavaBeansやJavaクラスなど，ほかのコンポーネントを呼び出せます。また，ほかのSession BeanやEntity Beanを呼び出すこともできます。ただし，この場合も，クライアントから見たアクセスポイントとなるコンポーネントは，フロントに配置したSession BeanまたはEntity Beanになります。

図3‒11　Session BeanまたはEntity Beanからほかのコンポーネントを呼び出す場合のアクセスポイント

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

このアプリケーションは，主にバックシステムで動作します。

(3)　Message-driven Beanで構成されるアプリケーション

Message-driven Beanは，メッセージ駆動型のシステムでビジネスロジックを実装するためのコンポーネントです。次のどれかの方法でアクセスされます。

CJMSプロバイダ経由のアクセス

TP1/Message QueueおよびTP1/Message Queue - Access経由でのアクセス

データベース（HiRDBまたはOracle）およびReliable Messaging経由でのアクセス

TP1インバウンド連携でのアクセス

なお，Message-driven Beanをアクセスポイントとする構成の場合，リソースアダプタとして，次のどれかが必要です。

CJMSPリソースアダプタ※

TP1/Message Queue - Access

Reliable Messaging※

Reliable Messagingは，DB Connector for Reliable Messaging※と組み合わせて使用します。

TP1インバウンドアダプタ※

注※　アプリケーションサーバが提供するリソースアダプタです。

Message-driven Beanで構成されるアプリケーションの場合，アクセスポイントになるコンポーネントは，Message-driven Beanになります。

Message-driven Beanで構成されるアプリケーションを次の図に示します。

図3‒12　Message-driven Beanで構成されるアプリケーション（CJMSプロバイダ経由の場合）

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

図3‒13　Message-driven Beanで構成されるアプリケーション（TP1/Message Queue - Access経由の場合）

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

図3‒14　Message-driven Beanで構成されるアプリケーション（Reliable Messaging経由の場合）

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

図3‒15　Message-driven Beanで構成されるアプリケーション（TP1インバウンド連携の場合）

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

Message-driven Beanからは，JavaBeansやJavaクラスなど，ほかのコンポーネントを呼び出せます。また，Session BeanやEntity Beanを呼び出すこともできます。ただし，この場合も，クライアントから見たアクセスポイントとなるコンポーネントは，Message-driven Beanになります。例を示します。

図3‒16　Message-driven Beanからほかのコンポーネントを呼び出す場合のアクセスポイント（TP1/Message Queue - Access経由の場合）

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

図3‒17　Message-driven Beanからほかのコンポーネントを呼び出す場合のアクセスポイント（Reliable Messaging経由の場合）

注　これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

このアプリケーションは，主にバックシステムで動作します。

3.3.2　リソースの種類とリソースアダプタ

アプリケーションサーバのシステムでは，次のリソースと接続できます。

データベース（HiRDB，Oracle，SQL ServerまたはXDM/RD E2）

OpenTP1のTP1/Message Queue

OpenTP1のSPP

OpenTP1のSUP

CJMSプロバイダのCJMSPブローカー

メールコンフィグレーション

JavaBeansリソース

OpenTP1のSUPとは，Inboundで接続します。なお，メールコンフィグレーションまたはJavaBeansリソースを使用する場合，リソースアダプタは不要です。

ここでは，アプリケーションが接続するリソースの種類ごとに，使用するリソースアダプタについて説明します。

ポイント

アプリケーションサーバでは，Connector 1.0またはConnector 1.5仕様に準拠したリソースアダプタを利用できます。

ここで説明する以外のリソースアダプタについては，ご使用のリソースアダプタの説明をご確認ください。

(1)　データベースと接続するためのリソースアダプタ（JDBCインタフェースを使用する場合）

JDBCインタフェースを使用してデータベースと接続する場合，リソースアダプタとしてDB Connectorを使用します。DB Connectorを使用すると，サーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanから，JDBCインタフェースを使用してデータベースにアクセスできます。

なお，アプリケーションサーバがリソースアダプタを使用してアクセスできるデータベースは，HiRDB，Oracle，SQL ServerまたはXDM/RD E2です。リソースアダプタを使用してデータベースにアクセスする場合の構成を，データベースの種類ごとに図に示します。

HiRDBにアクセスする場合の構成

HiRDBに接続する場合，J2EEサーバと同じマシンに，HiRDB Type4 JDBC Driverが必要となります。

HiRDBにアクセスする場合の構成を次の図に示します。

図3‒18　リソースアダプタを使用してHiRDBにアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

Oracleにアクセスする場合の構成

Oracleに接続する場合，J2EEサーバと同じマシンに，Oracle JDBC Thin Driverが必要となります。

Oracleにアクセスする場合の構成を次の図に示します。

図3‒19　リソースアダプタを使用してOracleにアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

SQL Serverにアクセスする場合の構成

SQL Serverに接続する場合，J2EEサーバと同じマシンに，SQL ServerのJDBCドライバが必要となります。

SQL Serverにアクセスする場合の構成を次の図に示します。

図3‒20　リソースアダプタを使用してSQL Serverにアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

XDM/RD E2にアクセスする場合の構成

XDM/RD E2に接続する場合，J2EEサーバと同じマシンに，HiRDB Type4 JDBC Driverが必要となります。

XDM/RD E2にアクセスする場合の構成を次の図に示します。

図3‒21　リソースアダプタを使用してXDM/RD E2にアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

(2)　データベースと接続するためのリソースアダプタ（JMSインタフェースを使用する場合）

JMSインタフェースを使用してデータベースと接続する場合，リソースアダプタとしてDB Connector for Reliable Messagingを使用します。DB Connector for Reliable Messagingは，Reliable Messagingと連携するためのリソースアダプタです。Reliable Messagingを使用すると，サーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanから，JMSインタフェースを使用してデータベース上に実現したキューにアクセスできます。この場合，J2EEサーバ上では，Reliable Messagingのライブラリが動作して，キューのデータはデータベースに保存されます。なお，Reliable Messagingはアプリケーションサーバの構成ソフトウェアです。

Reliable Messagingを使用してデータベースにアクセスする場合の構成を，HiRDBにアクセスする場合と，Oracleにアクセスする場合に分けて，図に示します。

図3‒22　Reliable Messagingを使用してHiRDBにアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

図3‒23　Reliable Messagingを使用してOracleにアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

(3)　OpenTP1のTP1/Message Queueに接続するためのリソースアダプタ

OpenTP1のメッセージキューイング機能であるTP1/Message Queueと接続する場合，リソースアダプタとしてTP1/Message Queue - Accessを使用します。TP1/Message Queue - Accessを使用すると，サーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanから，JMSインタフェースを使用してTP1/Message Queueにアクセスできます。この場合，J2EEサーバと同じマシンに，TP1/Message Queue - Accessが必要となります。

リソースアダプタを使用してTP1/Message Queueにアクセスする場合の構成を，次の図に示します。

図3‒24　リソースアダプタを使用してTP1/Message Queueにアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

(4)　OpenTP1のSPPと接続するためのリソースアダプタ

OpenTP1のSPP（サービス提供プログラム：Service Providing Program）と接続する場合，リソースアダプタとしてTP1 ConnectorおよびTP1/Client/Jを使用します。TP1 ConnectorおよびTP1/Client/Jを使用すると，サーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanから，OpenTP1のSPPにアクセスできます。このとき，J2EEサーバと同じマシンに，TP1 ConnectorおよびTP1/Client/Jが必要となります。

リソースアダプタを使用してOpenTP1のSPPにアクセスする場合の構成を，次の図に示します。

図3‒25　リソースアダプタを使用してOpenTP1のSPPにアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

(5)　OpenTP1のSUPと接続するためのリソースアダプタ

TP1インバウンド連携機能を利用してOpenTP1のSUP（サービス利用プログラム：Service Using Program）と接続する場合，リソースアダプタとしてTP1インバウンドアダプタを使用します。TP1インバウンド連携機能を利用すると，OpenTP1のSUPから，J2EEサーバ上で動作するMessage-driven BeanにInboundでアクセスできます。このとき，J2EEサーバと同じマシンに，TP1インバウンドアダプタが必要となります。

リソースアダプタを使用してOpenTP1のSUPからInboundでアクセスする場合の構成を，次の図に示します。

図3‒26　リソースアダプタを使用してOpenTP1のSUPからInboundでアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

(6)　CJMSプロバイダのCJMSPブローカーと接続するためのリソースアダプタ

CJMSプロバイダのCJMSPブローカーと接続する場合，リソースアダプタとしてCJMSPリソースアダプタを使用します。CJMSPリソースアダプタを使用すると，サーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanから，JMSインタフェースを使用してCJMSPブローカーにアクセスできます。このとき，J2EEサーバと同じマシンに，CJMSPリソースアダプタが必要となります。

リソースアダプタを使用してCJMSPブローカーにアクセスする場合の構成を，次の図に示します。

図3‒27　リソースアダプタを使用してCJMSPブローカーにアクセスする場合の構成

注　凡例については，「3.2　システム構成の説明について」を参照してください。

3.4　クライアントとサーバの構成を検討する

この節では，クライアントとサーバの構成の種類と，それぞれの場合に各マシンに配置するプロセスについて説明します。また，それぞれの構成の特徴についても説明します。

クライアントとサーバの構成を検討するためには，処理を呼び出す側であるクライアントと呼び出される側であるサーバの対応を決めて，サーバ側で動作するアプリケーションのアクセスポイントを明確にする必要があります。

ここでは，次のコンポーネントをアクセスポイントとするクライアントとサーバの構成について説明します。なお，サーブレットとJSPをアクセスポイントにする構成については，Webサーバ連携の場合とWebサーバを経由しないでJ2EEサーバのNIO HTTPサーバに直接アクセスする場合に分けて説明します。

サーブレットとJSP

Session BeanとEntity Bean

CTMを使用する場合のStateless Session Bean

以降，アプリケーションサーバを配置したマシンをアプリケーションサーバマシン，クライアントとして使用するマシンをクライアントマシンといいます。

3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）

サーブレットとJSPがアクセスポイントになる，Webベースのシステム構成について説明します。この構成をWebクライアント構成といいます。Webフロントシステムで使用できる構成です。ここでは，Webサーバ連携の場合の構成について説明します。

また，この構成でインターネットに接続する場合，セキュリティの観点から，アプリケーションサーバと同じマシンに配置するWebサーバとは別に，DMZにリバースプロキシの機能を持つWebサーバを配置することをお勧めします。詳細は，マニュアル「アプリケーションサーバ機能解説 セキュリティ管理機能編」の「3.3　DMZへのリバースプロキシの配置を検討する」を参照してください。

(1)　システム構成の特徴

Webフロントシステムで，Webブラウザから送信されたリクエストをアプリケーションサーバで処理する場合に適用されるシステム構成です。

最も基本的なWebクライアント構成は，クライアントマシンと1台のアプリケーションサーバマシンによって構築できます。1台のアプリケーションサーバマシンで構築するWebクライアント構成の例を次の図に示します。

図3‒28　1台のアプリケーションサーバマシンで構築するWebクライアント構成の例（Webサーバ連携の場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

クライアントで使用するソフトウェアはWebブラウザだけです。なお，NIO HTTPサーバにアクセスする場合，次の点に留意してください。

NIO HTTPサーバでは，HTTPSはサポートされていません。このため，SSLを使用する場合には，プロキシサーバをフロントに配置してプロキシモジュールを組み込んだWebサーバのSSL機能を使用するか，またはSSLアクセラレータをフロントに配置してください。

リクエストの流れ

アクセスポイントであるサーブレットとJSPは，J2EEサーバ上で動作します。これらのコンポーネントは，WebブラウザからWebサーバ経由でアクセスされます。

(2)　それぞれのマシンに必要なプロセスとソフトウェア

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。なお，リソースと接続するために必要なプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。

必要なプロセスは次のとおりです。

Webサーバ

J2EEサーバ

運用管理エージェント

PRFデーモン

なお，Application Serverには，WebサーバであるHTTP Serverが含まれています。

(b)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（NIO HTTPサーバに直接アクセスする場合）

サーブレットとJSPがアクセスポイントになる，Webベースのシステム構成について説明します。ここでは，NIO HTTPサーバに直接アクセスする場合の構成について説明します。

なお，この構成でインターネットに接続する場合，セキュリティの観点から，DMZにリバースプロキシの機能を持つWebサーバを配置してください。詳細は，マニュアル「アプリケーションサーバ機能解説 セキュリティ管理機能編」の「3.3　DMZへのリバースプロキシの配置を検討する」を参照してください。

(1)　システム構成の特徴

Webフロントシステムで，Webブラウザから送信されたリクエストをアプリケーションサーバで処理する場合に適用されるシステム構成です。

最も基本的なWebクライアント構成は，クライアントマシンと1台のアプリケーションサーバマシンによって構築できます。NIO HTTPサーバに直接アクセスする場合，J2EEサーバのフロントにWebサーバを起動する必要がありません。J2EEサーバ上のHTTPサーバの機能を使用します。

NIO HTTPサーバに直接アクセスする場合のWebクライアント構成の例を次の図に示します。

図3‒29　1台のアプリケーションサーバマシンで構築するWebクライアント構成の例（NIO HTTPサーバに直接アクセスする場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

クライアントで使用するソフトウェアはWebブラウザだけです。

WebブラウザからWebサーバを経由しないで直接J2EEサーバにアクセスできるため，性能上のメリットがあります。また，Webサーバを起動する必要がないため，運用が簡易になります。

なお，NIO HTTPサーバに直接アクセスする場合，次の点に留意してください。

NIO HTTPサーバでは，Webサーバとして動作するための最小限の機能だけがサポートされています。このため，Webサーバのさまざまな機能を必要とする場合は，この構成は適していません。Webサーバと連携する構成を選択してください。NIO HTTPサーバで使用できる機能については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「7.　NIO HTTPサーバ」を参照してください。

NIO HTTPサーバでは，HTTPSはサポートされていません。このため，SSLを使用する場合には，プロキシサーバをフロントに配置してプロキシモジュールを組み込んだWebサーバのSSL機能を使用するか，または，SSLアクセラレータをフロントに配置してください。

インターネットに接続するシステムでは，セキュリティ上の観点から，必ずリバースプロキシをフロントに配置してください。リバースプロキシを配置する構成については，マニュアル「アプリケーションサーバ機能解説 セキュリティ管理機能編」の「3.3　DMZへのリバースプロキシの配置を検討する」を参照してください。

リクエストの流れ

アクセスポイントであるサーブレットとJSPは，J2EEサーバ上で動作します。これらのコンポーネントは，Webブラウザから直接アクセスされます。

(2)　それぞれのマシンに必要なプロセスとソフトウェア

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。なお，リソースと接続するために必要なプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。

必要なプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.4.3　Session BeanとEntity Beanをアクセスポイントに使用する構成

Session BeanとEntity Beanがアクセスポイントになり，クライアントでEJBクライアントアプリケーションを動作させるシステム構成について説明します。この構成を，EJBクライアント構成といいます。

(1)　システム構成の特徴

最も基本的なEJBクライアント構成は，クライアントマシンと1台のアプリケーションサーバマシンによって構築できます。

1台のアプリケーションサーバマシンで構築するEJBクライアント構成の例を次の図に示します。

図3‒30　1台のアプリケーションサーバマシンで構築するEJBクライアント構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

Windowsの場合は，Clientを使用してクライアントマシンの環境を構築できます。

リクエストの流れ

アクセスポイントであるSession BeanとEntity Beanは，J2EEサーバ上で動作します。

EJBクライアントアプリケーションからのリクエストは，RMI-IIOPによってアクセスポイントに送られ，Session BeanとEntity Beanを呼び出します。このとき，EJBクライアントアプリケーションは，J2EEサーバ内で動作しているネーミングサービスから名前を検索（ルックアップ）して，Session BeanとEntity Beanにアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースに接続するためのプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　EJBクライアントマシン

EJBクライアントマシンには，Application ServerまたはClient（Windowsの場合）をインストールする必要があります。

起動するプロセスは，EJBクライアントアプリケーションのプロセスです。

3.4.4　CTMを使用する場合にStateless Session Beanをアクセスポイントに使用する構成

CTMを使用する場合の，Stateless Session Beanをアクセスポイントとするシステム構成について説明します。

参考

ここでは，クライアントとしてEJBクライアントアプリケーションを使用するEJBクライアント構成の例を示します。このほか，CTMゲートウェイ機能を使用すると，EJBクライアント以外のクライアントアプリケーションからJ2EEサーバ上のEJBアプリケーションを直接呼び出す構成も実現できます。これらの構成については，「3.13.3　CTMゲートウェイ機能を利用してEJBクライアント以外からStateless Session Beanを呼び出す構成」を参照してください。

(1)　システム構成の特徴

EJBクライアント構成の一つです。アクセスポイントであるStateless Session Beanに対して，CTMによってスケジューリングされたリクエストが送信されます。

CTMを使用する場合のEJBクライアント構成の例を次の図に示します。

図3‒31　CTMを使用する場合のEJBクライアント構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

CTMによってリクエストをスケジューリングすることで，サービス閉塞を実行したり同時実行数を制御したりするシステム運用ができるようになります。

J2EEサーバを二つ以上起動することで，一つのJ2EEサーバにトラブルが発生した場合に，縮退運転をしてシステムの稼働を続けられます。

Windowsの場合は，Clientを使用してクライアントマシンの環境を構築できます。

リクエストの流れ

アクセスポイントであるStateless Session Beanは，J2EEサーバ上で動作します。

EJBクライアントアプリケーションからのリクエストは，CTM経由で送られ，Stateless Session Beanを呼び出します。このとき，EJBクライアントアプリケーションは，グローバルCORBAネーミングサービスから名前をルックアップして，Stateless Session Beanにアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースに接続するためのプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

グローバルCORBAネーミングサービス

CTMのプロセス群（CTMデーモンおよびCTMレギュレータ）

CTMドメインマネジャ

スマートエージェント

(b)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　EJBクライアントマシン

EJBクライアントマシンには，Application ServerまたはClient（Windowsの場合）をインストールする必要があります。

起動するプロセスはEJBクライアントアプリケーションのプロセスです。

3.5　サーバ間での連携を検討する

この節では，複数のアプリケーションサーバ上のJ2EEサーバで動作するアプリケーションを連携させる構成の種類と，それぞれの場合に各マシンに配置するプロセスについて説明します。また，それぞれの構成の特徴についても説明します。

なお，複数のアプリケーションサーバで構成するシステムの場合，呼び出し元になるアプリケーションが動作しているアプリケーションサーバをクライアント側のアプリケーションサーバ，呼び出されるアプリケーションが動作しているアプリケーションサーバをサーバ側のアプリケーションサーバといいます。

ここでは，次に示す2種類のサーバ間連携の構成について説明します。

Session BeanとEntity Beanを呼び出すサーバ間連携

CTM経由でStateless Session Beanを呼び出すサーバ間連携

3.5.1　Session BeanとEntity Beanを呼び出すサーバ間連携

ほかのアプリケーションサーバ上のJ2EEサーバからSession BeanまたはEntity Beanを呼び出す場合の構成について説明します。

(1)　システム構成の特徴

クライアント側のアプリケーションサーバから，サーバ側のアプリケーションサーバを呼び出す構成です。クライアント側のアプリケーションサーバでは，サーブレット，JSP，Entity Bean，Session BeanまたはMessage-driven Beanで構成されるアプリケーションが動作します。サーバ側のアクセスポイントになるコンポーネントは，Session BeanまたはEntity Beanです。クライアント側のアプリケーションからの呼び出しは，RMI-IIOPで実行されます。

Session BeanとEntity Beanを呼び出すサーバ間連携の構成の例を，次の図に示します。

図3‒32　Session BeanとEntity Beanを呼び出すサーバ間連携の構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

アプリケーション間連携で使用できる構成です。複数のクライアントアプリケーションから，サーバアプリケーションを呼び出す場合などに適用できます。

システム間連携の場合にも使用できます。すでに構築されたクライアント側システムとサーバ側システムをこのシステム構成にすることで，アプリケーションをシステム間で呼び出せます。

リクエストの流れ

サーバ側のアクセスポイントであるSession BeanまたはEntity Beanへのリクエストは，クライアント側のJ2EEサーバから送られます。

このとき，クライアント側では，サーバ側のアプリケーションサーバのJ2EEサーバ内でインプロセスで起動されているCORBAネーミングサービスから名前をルックアップして，Session BeanまたはEntity Beanにアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

Session BeanまたはEntity Beanを呼び出すサーバ間連携の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースと接続するために必要なプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　クライアント側のアプリケーションサーバマシン（サーブレット／JSPの実行環境）

サーブレットおよびJSPを動作させるクライアント側のアプリケーションサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Webサーバ

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　クライアント側のアプリケーションサーバマシン（Message-driven Beanの実行環境）

Message-driven Beanを動作させるクライアント側のアプリケーションサーバマシンには，Application Serverをインストールする必要があります。また，リソースアダプタとしてTP1/Message Queue - Accessを使用する場合は，TP1/Message Queue - Accessをインストールする必要があります。なお，Reliable Messagingを使用する場合は，アプリケーションサーバに含まれているため，個別にインストールする必要はありません。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(c)　サーバ側のアプリケーションサーバマシン

サーバ側のアプリケーションサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(d)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.5.2　CTM経由でStateless Session Beanを呼び出すサーバ間連携

CTMを使用する場合に，ほかのアプリケーションサーバ上のJ2EEサーバからCTM経由でStateless Session Beanを呼び出すときの構成について説明します。

(1)　システム構成の特徴

クライアント側のアプリケーションサーバから，CTM経由でサーバ側のアプリケーションサーバを呼び出す構成です。クライアント側のアプリケーションサーバでは，サーブレット，JSP，Entity Bean，Session BeanまたはMessage-driven Beanで構成されるアプリケーションが動作します。サーバ側のアクセスポイントになるコンポーネントは，Stateless Session Beanです。クライアント側のアプリケーションからの呼び出しは，RMI-IIOPで実行されます。

CTM経由でStateless Session Beanを呼び出すサーバ間連携の構成の例を次の図に示します。

図3‒33　Stateless Session Beanを呼び出すサーバ間連携の構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

アプリケーション間連携で使用できる構成です。複数のクライアントアプリケーションから，サーバアプリケーションを呼び出す場合などに適用できます。

システム間連携の場合にも使用できます。すでに構築されたクライアント側システムとサーバ側システムをこのシステム構成にすることで，アプリケーションをシステム間で呼び出せます。

リクエストの流れ

サーバ側のアクセスポイントであるStateless Session Beanへのリクエストは，クライアント側のJ2EEサーバからCTM経由で送られます。

このとき，クライアント側では，サーバ側のアプリケーションサーバのグローバルCORBAネーミングサービスから名前をルックアップして，CTM経由でStateless Session Beanにアクセスします。

CTMを経由したリクエストは，CTMによってJ2EEサーバ上で動作するStateless Session Beanに適切に振り分けられます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

CTM経由でStateless Session Beanを呼び出すサーバ間連携の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースと接続するために必要なプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　クライアント側のアプリケーションサーバマシン（サーブレット／JSPの実行環境）

サーブレットおよびJSPを動作させるクライアント側のアプリケーションサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Webサーバ

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　クライアント側のアプリケーションサーバマシン（Session Beanの実行環境）

Session Beanを動作させるクライアント側のアプリケーションサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(c)　サーバ側のアプリケーションサーバマシン

サーバ側のアプリケーションサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

グローバルCORBAネーミングサービス

CTMのプロセス群（CTMデーモンおよびCTMレギュレータ）

CTMドメインマネジャ

スマートエージェント

(d)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.6　トランザクションの種類を検討する

この節では，トランザクションの種類ごとのシステム構成について説明します。

トランザクションに参加するリソースが一つの場合は，ローカルトランザクションを使用します。トランザクションに参加するリソースが複数の場合は，グローバルトランザクションを使用します。また，サーバ間で連携する構成の場合に，それぞれのJ2EEサーバが異なるリソースに接続するときには，トランザクションコンテキストのプロパゲーションも使用できます。

なお，接続するリソースとリソースアダプタの対応については，「3.3.2　リソースの種類とリソースアダプタ」を参照してください。

参考

この節では，アプリケーションサーバによって開始されるトランザクションの種類ごとの構成について説明しますが，EJBクライアントアプリケーションでもトランザクションを開始できます。なお，EJBクライアントアプリケーションでトランザクションを開始する場合は，EJBクライアントマシンにApplication Serverが必要です。

3.6.1　ローカルトランザクションを使用する場合の構成

トランザクションに参加するリソースが一つの場合の構成について説明します。

(1)　システム構成の特徴

サーブレット，JSPおよびSession Beanで構成される一つのJ2EEアプリケーションから，リソースアダプタ経由で一つのリソースマネジャにアクセスする場合の構成です。アプリケーションからリソースマネジャへのアクセスで使用するトランザクションは，リソースマネジャ側で管理されます。トランザクションの種類はXAインタフェースを使用しない，ローカルトランザクションになります。

ローカルトランザクションを使用する場合の構成の例を，次の図に示します。

図3‒34　ローカルトランザクションを使用する場合の構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

アプリケーションから一つのリソースマネジャにアクセスします。2フェーズコミットは必要ありません。

アプリケーションからリソースアダプタ経由でリソースマネジャにアクセスする流れ

WebブラウザからWebサーバ経由でアクセスされたサーブレットおよびJSPは，同じアプリケーション内のSession Beanをローカルで呼び出します。Session Beanは，リソースアダプタを経由してリソースマネジャ（図の場合はHiRDB）にアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

ローカルトランザクションを使用する場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。

また，リソースマネジャと接続するために，次のソフトウェアが必要です。

接続するリソースマネジャ

必要なソフトウェア

HiRDB

HiRDB Run TimeまたはHiRDB Type4 JDBC Driver

Oracle

Oracle ClientまたはOracle JDBC Thin Driver

SQL Server

SQL ServerのJDBCドライバ

XDM/RD E2

HiRDB Run TimeまたはHiRDB Type4 JDBC Driver

TP1/Message Queue

TP1/Message Queue - Access

OpenTP1のSPP

TP1 Connector

TP1/Client/J

起動するプロセスは次のとおりです。

Webサーバ

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　リソースマネジャが動作するマシン

リソースマネジャが動作するマシンには，次に示すソフトウェアのどれかをインストールしてください。

HiRDB（HiRDBと接続する場合）

Oracle（Oracleと接続する場合）

SQL Server（SQL Serverと接続する場合）

XDM/RD E2（XDM/RD E2と接続する場合）

TP1/Message Queue（TP1/Message Queueと接続する場合）

TP1/Server Base（OpenTP1のSPPと接続する場合）

また，それぞれのリソースマネジャで必要なプロセスを起動してください。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.6.2　グローバルトランザクションを使用する場合の構成

トランザクションに参加するリソースが複数の場合の構成について説明します。

(1)　システム構成の特徴

Session Beanを構成要素とする一つのJ2EEアプリケーションから，リソースアダプタ経由で複数のリソースマネジャにアクセスする構成です。アプリケーションからリソースマネジャへのアクセスで使用するトランザクションは，J2EEサーバ側で管理します。トランザクションの種類は，XAインタフェースを使用するグローバルトランザクションになります。

グローバルトランザクションを使用する場合の構成の例を，次の図に示します。この例は，CTMを使用するシステムの場合の例です。

図3‒35　グローバルトランザクションを使用する場合の構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

アプリケーションから複数のリソースマネジャにアクセスします。2フェーズコミットが必要になります。

一つのリソースマネジャにアクセスするアプリケーションと，複数のリソースマネジャにアクセスするアプリケーションを混在させるシステムの場合も，この構成にする必要があります。

アプリケーションからリソースアダプタ経由でリソースマネジャにアクセスする流れ

EJBクライアントアプリケーションからアクセスされたStateless Session Beanは，リソースアダプタを経由してリソースマネジャにアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

グローバルトランザクションを使用する場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。

また，リソースマネジャと接続するために，次のソフトウェアをインストールする必要があります。

接続するリソースマネジャ

必要なソフトウェア

HiRDB

HiRDB Run TimeまたはHiRDB Type4 JDBC Driver

Oracle

Oracle ClientまたはOracle JDBC Thin Driver

TP1/Message Queue

TP1/Message Queue - Access

OpenTP1のSPP

TP1 Connector

TP1/Client/J

注　SQL ServerおよびXDM/RD E2はグローバルトランザクションでは使用できません。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

また，CTMを使用する構成の場合は，Application Serverをインストールして，上記のプロセスのほかに，グローバルCORBAネーミングサービス，CTMのプロセス群，CTMドメインマネジャおよびスマートエージェントも起動する必要があります。詳細は，「3.5.2　CTM経由でStateless Session Beanを呼び出すサーバ間連携」を参照してください。

(b)　リソースマネジャが動作するマシン

リソースマネジャが動作するマシンには，次に示すソフトウェアのどれかをインストールしてください。なお，SQL ServerおよびXDM/RD E2はグローバルトランザクションでは使用できません。

HiRDB（HiRDBと接続する場合）

Oracle（Oracleと接続する場合）

TP1/Message Queue（TP1/Message Queueと接続する場合）

TP1/Server Base（OpenTP1のSPPと接続する場合）

また，それぞれのリソースマネジャで必要なプロセスを起動してください。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　EJBクライアントマシン

EJBクライアントマシンには，Application ServerまたはClient（Windowsの場合）をインストールする必要があります。

起動するプロセスは，EJBクライアントアプリケーションのプロセスです。

3.6.3　トランザクションコンテキストのプロパゲーションを使用する場合の構成

サーバ間で連携する構成の場合に，それぞれのJ2EEサーバが異なるリソースに接続する構成について説明します。この構成では，トランザクションコンテキストのプロパゲーションを使用します。なお，この構成の場合，CTMは使用できません。

(1)　システム構成の特徴

複数のJ2EEアプリケーションでサーバ間連携をする構成です。ここでは，サーブレット，JSP，およびSession Beanで構成されるJ2EEアプリケーションと，Session Beanだけで構成されるJ2EEアプリケーションでサーバ間連携をする例について説明します。サーブレット，JSPおよびSession Beanで構成されるアプリケーションは，クライアント側のアプリケーションサーバで動作し，Session Beanで構成されるJ2EEアプリケーションは，サーバ側のアプリケーションサーバで動作します。

それぞれのJ2EEアプリケーションは，リソースアダプタ経由で異なるリソースマネジャにアクセスします。この場合，リソースマネジャへのアクセスで使用するトランザクションは，J2EEサーバ側で管理します。このときのトランザクションの種類は，XAインタフェースを使用するグローバルトランザクションになります。

なお，CTM経由でStateless Session Beanを呼び出す構成では，トランザクションコンテキストのプロパゲーションは使用できません。

トランザクションコンテキストのプロパゲーションを使用する場合の構成の例を次の図に示します。この例では，J2EEアプリケーションは，それぞれ，データベースとOpenTP1のSPPにアクセスします。

図3‒36　トランザクションコンテキストのプロパゲーションを使用する場合の構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

サーバ間連携をするアプリケーションから複数のリソースマネジャにアクセスする場合に適用できます。

サーバ間連携をする場合に，一つのリソースマネジャにアクセスするアプリケーションと，複数のリソースマネジャにアクセスするアプリケーションを混在させるシステムの場合は，この構成にする必要があります。

アプリケーションからリソースアダプタ経由でリソースマネジャにアクセスする流れ

WebブラウザからWebサーバ経由でアクセスされたサーブレットおよびJSPは，同じアプリケーション内のSession Beanをローカルで呼び出します。Session Beanは，トランザクションを開始して，データベースにアクセスしてから，サーバ側のアプリケーションサーバ上のJ2EEサーバで動作しているSession Beanを呼び出します。呼び出されたサーバ側のアプリケーションサーバ上のSession Beanは，OpenTP1のSPPにアクセスします。クライアント側のアプリケーションサーバ上のSession Beanは，サーバ側のSession Beanから制御が戻ると，トランザクションをコミットします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

トランザクションコンテキストのプロパゲーションを使用するときに必要なソフトウェアと起動するプロセスは，「3.6.2　グローバルトランザクションを使用する場合の構成」と同様です。ただし，コンテキストのトランザクションプロパゲーションを使用する場合，CTMは使用できません。

3.7　ロードバランスクラスタによる負荷分散方式を検討する

この節では，ロードバランスクラスタによって負荷を分散するための構成について説明します。

負荷分散は次の方法で実現します。アクセスポイントになるコンポーネントの種類によって，実現できるものが異なります。

負荷分散機を利用する（サーブレット／JSPの場合）

ネーミングサービスを利用する（Session Bean／Entity Beanの場合）

CTMを利用する（Stateless Session Beanの場合）

負荷分散機を利用する構成については，Webサーバ連携の場合とWebサーバを経由しないでJ2EEサーバのNIO HTTPサーバに直接アクセスする場合に分けて説明します。なお，アクセスポイントがMessage-driven Beanの場合の負荷分散については，「3.8.4　Message-driven Beanのインスタンスプールを利用した負荷分散（TP1/Message Queueを使用する場合）」を参照してください。

3.7.1　Webサーバ連携時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）

負荷分散機（レイヤ5スイッチ）によって負荷を分散する構成について説明します。この方法は，サーブレットまたはJSPがアクセスポイントの場合に使用できます。

ここでは，Webサーバと連携する場合について説明します。

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントが，サーブレットまたはJSPの場合に使用できる構成です。

負荷分散は，負荷分散機に対象となるアプリケーションサーバを登録することで実現できます。アプリケーションサーバを複数登録することで，クライアントからのアクセスによる負荷を分散できます。

負荷分散機を利用した負荷分散の構成の例を次の図に示します。

図3‒37　負荷分散機を利用した負荷分散の構成の例（Webサーバと連携する場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

サーブレットとJSPのスケーラビリティと可用性を確保できます。

特定のアプリケーションサーバでトラブルが発生した場合，またはメンテナンスが必要な場合に，負荷分散機から該当するアプリケーションサーバへのアクセスを停止することで，システムの縮退運転ができます。

リクエストの流れ

アクセスポイントであるJ2EEサーバ上のサーブレットとJSPへのリクエストは，Webブラウザから，負荷分散機およびWebサーバ経由で送られます。その際，負荷分散機では，Webブラウザからのアクセスを，それぞれのアプリケーションサーバ上で動作しているWebサーバに対して振り分けます。なお，負荷分散機では，HTTPセッションのスティッキー（Sticky）やアフィニティ（Afinity）の関連づけも制御します。

参考

HTTPSを使用する場合に，負荷分散機でのリクエストの振り分けにリクエストの中身（ヘッダなど）を使用するときは，負荷分散機のフロントにSSLアクセラレータを配置する必要があります。

Smart Composer機能を使用する場合は，負荷分散機を冗長化構成で配置することもできます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

負荷分散機を使用する場合にそれぞれのマシンに必要なソフトウェアと起動するプロセスは，サーブレットとJSPをアクセスポイントにする構成と同じです。「3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）」を参照してください。

3.7.2　NIO HTTPサーバ使用時の負荷分散機を利用した負荷分散（Webサーバを経由しない場合）

負荷分散機（レイヤ5スイッチ）によって負荷を分散する構成について説明します。この方法は，サーブレットまたはJSPがアクセスポイントの場合に使用できます。

ここでは，Webサーバを経由しないでJ2EEサーバのNIO HTTPサーバに直接アクセスする場合について説明します。

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントが，サーブレットまたはJSPの場合に使用できる構成です。

負荷分散は，負荷分散機に対象になるアプリケーションサーバを登録することで実現できます。アプリケーションサーバを複数登録することで，クライアントからのアクセスによる負荷を分散できます。

負荷分散機を利用した負荷分散の構成の例を次の図に示します。

図3‒38　負荷分散機を利用した負荷分散の構成の例（NIO HTTPサーバに直接アクセスする場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

サーブレットとJSPのスケーラビリティと可用性を確保できます。

特定のアプリケーションサーバでトラブルが発生した場合，またはメンテナンスが必要な場合に，負荷分散機から該当するアプリケーションサーバへのアクセスを停止することで，システムの縮退運転ができます。

WebブラウザからWebサーバを経由しないで直接J2EEサーバにアクセスできるため，性能上のメリットがあります。また，Webサーバを起動する必要がないため，運用が簡易になります。ただし，使用できる機能や構成について，留意する必要があります。また，インターネットに接続する場合は，必ずリバースプロキシを組み込んだWebサーバをフロントに配置してください。詳細は，「3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（NIO HTTPサーバに直接アクセスする場合）」を参照してください。

リクエストの流れ

アクセスポイントであるJ2EEサーバ上のサーブレットとJSPへのリクエストは，Webブラウザから，負荷分散機経由で送られます。その際，負荷分散機では，Webブラウザからのアクセスを，それぞれのアプリケーションサーバ上で動作しているJ2EEサーバに対して振り分けます。なお，負荷分散機では，HTTPセッションのスティッキー（Sticky）やアフィニティ（Afinity）の関連づけも制御します。

参考

HTTPSを使用する場合は，負荷分散機のフロントにSSLアクセラレータを配置する必要があります。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

負荷分散機を使用する場合にそれぞれのマシンに必要なソフトウェアと起動するプロセスは，サーブレットとJSPをアクセスポイントにする構成と同じです。「3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（NIO HTTPサーバに直接アクセスする場合）」を参照してください。

3.7.3　CORBAネーミングサービスを利用した負荷分散（Session BeanとEntity Beanの場合）

アクセスポイントになるコンポーネントがSession BeanまたはEntity Beanの場合に，J2EEサーバ内（インプロセス）のCORBAネーミングサービスのラウンドロビン検索機能を使用して負荷を分散する構成について説明します。

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントが，Session BeanまたはEntity Beanの場合に使用できる構成です。クライアントは，EJBクライアントアプリケーションです。EJBクライアントアプリケーションは，システムプロパティに登録した論理ネーミングサービスから，オブジェクトリファレンスをラウンドロビン方式でルックアップすることで，リクエストの振り分け先を分散します。ただし，それぞれのJ2EEサーバでは同じ名前（同じ別名）でSession BeanおよびEntity Beanを開始しておく必要があります。

なお，EJBクライアントアプリケーションは，ラウンドロビン方式でJ2EEサーバ内のネーミングサービスをルックアップしたあと再度ネーミングサービスをルックアップするまでの間は，同じJ2EEサーバにアクセスします。

Session BeanとEntity Beanを対象にした負荷分散の構成の例を次の図に示します。

図3‒39　Session BeanとEntity Beanを対象にした負荷分散の構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

Session BeanとEntity Beanのスケーラビリティと可用性を確保できます。

アプリケーションサーバを複数用意して，EJBクライアントからラウンドロビン方式でCORBAネーミングサービスを選択してアクセスすることで，負荷を分散できます。

特定のアプリケーションサーバでトラブルが発生した場合，またはメンテナンスが必要な場合，EJBクライアントアプリケーションでは，J2EEサーバの終了を検出したあと，該当するアプリケーションサーバにアクセスしません。このため，システムの縮退運転ができます。

リクエストの流れ

アクセスポイントであるJ2EEサーバ上のSession BeanとEntity Beanへのリクエストは，EJBクライアントアプリケーションから送られます。その際，EJBクライアントアプリケーションでは，J2EEサーバ内のネーミングサービスをラウンドロビン方式で選択して，オブジェクトリファレンスをルックアップします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

CORBAネーミングサービスを使用して負荷を分散する場合にそれぞれのマシンに必要なソフトウェアと起動するプロセスは，Session BeanとEntity Beanをアクセスポイントにする構成と同じです。「3.4.3　Session BeanとEntity Beanをアクセスポイントに使用する構成」を参照してください。

3.7.4　CTMを利用した負荷分散（Stateless Session Beanの場合）

アクセスポイントになるコンポーネントがStateless Session Beanの場合に，CTMによって負荷を分散する構成です。

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントがStateless Session Beanの場合に，CTMを使用して実現する構成です。ここでは，クライアントがEJBクライアントアプリケーションの場合について説明します。

EJBクライアントアプリケーションは，システムプロパティに登録したグローバルCORBAネーミングサービスからオブジェクトリファレンスをラウンドロビン方式でルックアップすることで，リクエストの振り分け先を分散します。ただし，それぞれのJ2EEサーバでは同じ名前（同じ別名）でStateless Session Beanを開始しておく必要があります。

Stateless Session Beanを対象にしたCTMによる負荷分散の構成の例を次の図に示します。

図3‒40　Stateless Session Beanを対象にしたCTMによる負荷分散の構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

Stateless Session Beanの負荷の均衡を実現して，高い可用性を確保できます。

EJBクライアントからのラウンドロビン方式によるグローバルCORBAネーミングサービスのルックアップと，CTMによるリクエストの振り分けによって，J2EEサーバ間の負荷均衡が実現できます。

Stateless Session Beanのスケールアウトが容易に実現できるので，アプリケーションサーバの稼働率を向上できます。

特定のJ2EEサーバにトラブルが発生した場合，CTMによってほかのJ2EEサーバにリクエストをスケジューリングすることで，システムの縮退運転ができます。また，EJBクライアントアプリケーションからは，トラブルを検知したJ2EEサーバにはアクセスされません。

リクエストの流れ

アクセスポイントであるJ2EEサーバ上のStateless Session Beanへのリクエストは，EJBクライアントからCTM経由で送られます。その際，EJBクライアントは，グローバルCORBAネーミングサービスからStateless Session BeanのEJBHomeオブジェクトリファレンスの名前をルックアップします。そのあと，リクエストはCTMによって，適切なアプリケーションサーバ上のJ2EEサーバに振り分けられます。

CTMを使用して負荷を分散する場合，グローバルCORBAネーミングサービスを独立したマシンに配置することもできます。このとき，グローバルCORBAネーミングサービスを配置したマシンを，統合ネーミングスケジューラサーバといいます。

統合ネーミングスケジューラサーバを配置したシステムの構成を次の図に示します。

図3‒41　Stateless Session Beanを対象にしたCTMによる負荷分散の構成の例（統合ネーミングスケジューラサーバを配置した場合）

凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

Stateless Session Beanの負荷の均衡を実現して，高い可用性を確保できます。

統合ネーミングスケジューラサーバのレプリカを作成して複数配置することで，ネーミングサービスの可用性を確保できます。

EJBクライアントからのラウンドロビン方式によるグローバルCORBAネーミングサービスのルックアップと，CTMによるリクエストの振り分けによって，J2EEサーバ間の負荷均衡が実現できます。

Stateless Session Beanのスケールアウトが容易に実現できるので，アプリケーションサーバの稼働率を向上できます。スケールアウト時に，EJBクライアントで定義したグローバルCORBAネーミングサービスのリストを変更する必要はありません。

特定のJ2EEサーバにトラブルが発生した場合，CTMによってほかのJ2EEサーバにリクエストをスケジューリングすることで，システムの縮退運転ができます。EJBクライアントアプリケーションからは，トラブルを検知したJ2EEサーバにはアクセスされません。

EJBクライアントは，統合ネーミングスケジューラサーバ上のグローバルCORBAネーミングサービスからStateless Session BeanのEJBHomeオブジェクトリファレンスの名前をルックアップします。そのあと，アプリケーションサーバのCTMデーモンに処理が振り分けられます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

CTMを使用して負荷を分散する場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

グローバルCORBAネーミングサービス

CTMのプロセス群（CTMデーモンおよびCTMレギュレータ）

CTMドメインマネジャ

スマートエージェント

(b)　統合ネーミングスケジューラサーバマシン

統合ネーミングスケジューラサーバを配置するシステム構成の場合，統合ネーミングスケジューラサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。J2EEサーバを起動する必要はありません。

グローバルCORBAネーミングサービス

CTMのプロセス群（CTMデーモン）

CTMドメインマネジャ

スマートエージェント

運用管理エージェント

PRFデーモン

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　EJBクライアントマシン

EJBクライアントマシンには，Application ServerまたはClient（Windowsの場合）をインストールする必要があります。

起動するプロセスはEJBクライアントアプリケーションのプロセスです。

3.8　サーバ間で非同期通信をする場合の構成を検討する

この節では，サーバ間でMessage-driven Beanを使用して非同期通信をする場合のシステム構成について説明します。アクセスポイントはMessage-driven Beanになります。

Message-driven Beanを使って非同期通信をするシステム構成としては，CJMSプロバイダを使用するシステム構成，TP1/Message Queueを使用するシステム構成，およびReliable Messagingを使用するシステム構成があります。JMSプロバイダとReliable Messagingは，アプリケーションサーバの構成ソフトウェアです。なお，Reliable Messagingを使用したシステムでは，Message-driven Beanのインスタンスプールを使用した負荷分散はできません。

3.8.1　Message-driven Beanをアクセスポイントに使用する場合の構成（CJMSプロバイダを使用する場合）

ここでは，CJMSプロバイダを使用してJ2EEサーバ上のMessage-driven Beanを呼び出す構成について説明します。

メッセージの送信側のアプリケーションサーバから，CJMSPブローカーを経由して受信側のアプリケーションサーバを呼び出す構成です。送信側のアプリケーションサーバでは，サーブレット，JSP，Entity Bean，Session BeanまたはMessage-driven Beanで構成されるアプリケーションが動作します。受信側のアクセスポイントになるコンポーネントは，Message-driven Beanです。

(1)　システム構成の特徴

最も基本的なメッセージ駆動型のシステムの一つです。

CJMSプロバイダを使用する場合のメッセージ駆動型のシステム構成の例を次の図に示します。

図3‒42　メッセージ駆動型のシステム構成の例（CJMSプロバイダを使用する場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

送信側のアプリケーションサーバでは，メッセージを送信するためにJMSインタフェースを使用するJ2EEクライアントアプリケーションとCJMSPリソースアダプタを使用します。

リクエストの流れ

アクセスポイントであるMessage-driven Beanは，受信側のアプリケーションサーバのJ2EEサーバ上で動作します。リソースアダプタであるCJMSPリソースアダプタのライブラリは，送信側のアプリケーションサーバのJ2EEサーバ，および受信側のアプリケーションサーバのJ2EEサーバ上で動作します。

送信側のアプリケーションサーバのJ2EEアプリケーションからのリクエスト（メッセージ）は，CJMSPブローカー経由で送られ，受信側のアプリケーションサーバ上のMessage-driven Beanを呼び出します。

なお，送信側のアプリケーションサーバ，受信側のアプリケーションサーバおよびCJMSPブローカーは，同じマシンに配置することもできます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン（送信側のアプリケーションサーバマシン）

アプリケーションサーバマシン（サーバ側のアプリケーションサーバマシン）には，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　アプリケーションサーバマシン（CJMSPブローカーを配置するマシン）

CJMSPブローカーを配置するマシンには，Application Serverをインストールする必要があります。

起動する必要があるプロセスは，CJMSPブローカーです。なお，CJMSPブローカーは，Management Serverによる運用管理の対象になりません。

(c)　アプリケーションサーバマシン（受信側のアプリケーションサーバマシン）

クライアントマシン（クライアント側のアプリケーションサーバマシン）には，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(d)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.8.2　Message-driven Beanをアクセスポイントに使用する場合の構成（TP1/Message Queueを使用する場合）

ここでは，クライアントとして，TP1/Message Queueが動作しているMessage Queueサーバを使用する場合の構成について説明します。

(1)　システム構成の特徴

最も基本的なメッセージ駆動型のシステムの一つです。

TP1/Message Queueを使用する場合のメッセージ駆動型のシステム構成の例を次の図に示します。

図3‒43　メッセージ駆動型のシステム構成の例（TP1/Message Queueを使用する場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

クライアントに，TP1/Message Queueにメッセージを送信するMessage QueueクライアントアプリケーションとTP1/Message Queueを使用します。なお，Message Queueクライアントアプリケーションとは，JMSインタフェースを使用するJ2EEアプリケーションです。

リクエストの流れ

アクセスポイントであるMessage-driven Beanは，サーバ側のアプリケーションサーバのJ2EEサーバ上で動作します。リソースアダプタであるTP1/Message Queue - Accessのライブラリは，サーバ側のアプリケーションサーバのJ2EEサーバ，およびクライアント側のアプリケーションサーバのJ2EEサーバ上で動作します。

クライアント側のアプリケーションサーバのJ2EEアプリケーションからのリクエスト（メッセージ）は，TP1/Message Queue経由で送られ，サーバ側のアプリケーションサーバ上のMessage-driven Beanを呼び出します。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースに接続するためのプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン（サーバ側のアプリケーションサーバマシン）

アプリケーションサーバマシン（サーバ側のアプリケーションサーバマシン）には，Application ServerおよびTP1/Message Queue - Accessをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　Message Queueサーバマシン

Message Queueサーバマシンには，TP1/Message Queueをインストールする必要があります。

起動する必要があるプロセスは，TP1/Message Queueのプロセスです。

(c)　アプリケーションサーバマシン（クライアント側のアプリケーションサーバマシン）

クライアントマシン（クライアント側のアプリケーションサーバマシン）には，Application ServerおよびTP1/Message Queue - Accessをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(d)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.8.3　Message-driven Beanをアクセスポイントに使用する場合の構成（Reliable Messagingを使用する場合）

ここでは，クライアントとして，Reliable Messagingと連携しているデータベース（HiRDBまたはOracle）を使用する場合の構成について説明します。

(1)　システム構成の特徴

最も基本的なメッセージ駆動型のシステムの一つです。

Reliable Messagingを使用する場合のメッセージ駆動型のシステム構成の例を次の図に示します。

図3‒44　メッセージ駆動型のシステム構成の例（Reliable Messagingを使用する場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

クライアントに，Reliable Messagingにメッセージを送信するReliable Messagingのクライアントアプリケーションとデータベースサーバを使用します。なお，Reliable Messagingクライアントアプリケーションとは，JMSインタフェースを使用するJ2EEアプリケーションです。

リクエストの流れ

アクセスポイントであるMessage-driven Beanは，サーバ側のアプリケーションサーバのJ2EEサーバ上で動作します。リソースアダプタであるReliable Messagingのライブラリは，サーバ側のアプリケーションサーバのJ2EEサーバ上，およびクライアント側のアプリケーションサーバのJ2EEサーバ上で動作します。

クライアント側のアプリケーションサーバのJ2EEアプリケーションからのリクエスト（メッセージ）はデータベース上に実現されたキュー経由で送られ，サーバ側のアプリケーションサーバ上のMessage-driven Beanを呼び出します。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースに接続するためのプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　サーバ側のアプリケーションサーバマシン

サーバ側のアプリケーションサーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　データベースサーバマシン

データベースサーバマシンには，HiRDBまたはOracleをインストールする必要があります。

起動する必要があるプロセスは，HiRDBまたはOracleのプロセスです。

(c)　クライアントマシン（クライアント側のアプリケーションサーバマシン）

クライアントマシン（クライアント側のアプリケーションサーバマシン）には，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(d)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.8.4　Message-driven Beanのインスタンスプールを利用した負荷分散（TP1/Message Queueを使用する場合）

アクセスポイントになるコンポーネントがMessage-driven Beanの場合に，J2EEサーバごとのMessage-driven Beanのインスタンスのプール数に応じて負荷を分散する構成について説明します。

なお，この構成によって負荷を分散できるのは，TP1/Message Queueを使用してMessage-driven Beanにアクセスする場合だけです。Reliable Messagingを使用してMessage-driven Beanにアクセスする場合は，Message-driven Beanのインスタンスプールを利用した負荷分散はできません。

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントがMessage-driven Beanである，メッセージ駆動型のシステムで使用できる構成です。Message QueueクライアントからのメッセージがMessage Queueサーバ上のTP1/Message Queueのキューに到着すると，J2EEサーバ上でプールされているMessage-driven Beanのインスタンス数に応じて，Message-driven Beanが呼び出されます。

Message-driven Beanを対象にした負荷分散の構成の例を次の図に示します。

図3‒45　Message-driven Beanを対象にした負荷分散の構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

Message-driven Beanの負荷分散を実現して，高い可用性を確保できます。

アプリケーションサーバを複数用意することで，アプリケーションサーバの負荷を分散できます。

サーバ側のアプリケーションサーバで障害が発生した場合やアプリケーションサーバのメンテナンスが必要な場合，TP1/Message Queueから該当するアプリケーションサーバ上のJ2EEサーバにはアクセスしません。このため，縮退運転ができます。

リクエストの流れ

アクセスポイントであるサーバ側のアプリケーションサーバのJ2EEサーバ上のMessage-driven Beanへのリクエスト（メッセージ）は，クライアント側のアプリケーションサーバのJ2EEサーバ上で動作するJ2EEアプリケーションから，TP1/Message Queue経由で送られます。TP1/Message Queueにメッセージが到着すると，サーバ側のアプリケーションサーバのJ2EEサーバ上のMessage-driven Beanが呼び出されます。その際，Message-driven Beanのインスタンスプールのプール数に応じて，リクエストが振り分けられます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

Message-driven Beanのインスタンスプールを使用して負荷を分散する場合に必要なソフトウェアと起動するプロセスは，Message-driven Beanをアクセスポイントにする構成と同じです。「3.8.2　Message-driven Beanをアクセスポイントに使用する場合の構成（TP1/Message Queueを使用する場合）」を参照してください。

3.9　運用管理プロセスの配置を検討する

この節では，運用管理に使用するプロセスである，Management Serverの配置について説明します。Management Serverは，複数のホスト上に構築されているアプリケーションサーバのシステム全体を一括管理，および一括運用するプロセスです。Management Serverを使用することで，各ホスト上のサーバの環境設定をまとめて実施したり，サーバを一括起動したりできます。また，システム全体の状態を把握できます。

ここでは，次の構成を説明します。

運用管理サーバにManagement Serverを配置する構成（運用管理サーバモデル）

マシン単位にManagement Serverを配置する構成（ホスト単位管理モデル）

コマンドを使用して運用する構成

なお，運用管理サーバモデルでManagement Serverを配置したマシンを，運用管理サーバといいます。

参考

Management Serverの機能を使用して，J2EEサーバ，またはバッチサーバの稼働情報を監視・収集する場合，運用監視エージェントというエージェントプログラムを使用します。監視対象にするホスト上で，監視対象にするJ2EEサーバ，またはバッチサーバに一つずつ含まれます。また，クラスタ構成の場合は，クラスタに含まれるJ2EEサーバに一つずつ含まれます。

業務用のサーバを配置したLANと管理用のサーバを配置したLANに分けている場合，運用管理サーバを管理用のサーバを配置したLANに置くこともできます。LANを分け，一つのマシンを複数のネットワークセグメントに接続する場合，環境設定に注意が必要です。詳細については，マニュアル「アプリケーションサーバ運用管理ポータル操作ガイド」の「付録D　一つのマシンを複数のネットワークセグメントに接続する場合の環境設定での注意」を参照してください。

3.9.1　運用管理サーバにManagement Serverを配置する構成

Management Serverを利用して運用する場合に，ドメイン内に一つ運用管理サーバを配置する構成について説明します。

(1)　システム構成の特徴

複数のアプリケーションサーバで構成されるシステムで，ドメイン内に運用管理サーバマシンを配置する構成です。Management Serverであらかじめ定義したドメイン（運用管理ドメイン）内の運用管理および監視が実現できます。運用管理サーバマシンのManagement Serverは，それぞれのアプリケーションサーバに配置した運用管理エージェントと協調して，運用管理操作を実行します。

運用管理サーバにManagement Serverを配置する構成の例を次の図に示します。なお，この例では，接続するリソースマネジャについては省略しています。

図3‒46　運用管理サーバにManagement Serverを配置する構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

システムの一括運用に適しています。

独立した運用管理サーバ用のマシンを用意することをお勧めします。ただし，システム内の一つのアプリケーションサーバ内にManagement Serverを配置することもできます。

(2)　それぞれのマシンで起動するプロセス

運用管理サーバにManagement Serverを配置する構成の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

ポイント

運用管理サーバマシンを用意できないときは，ドメイン内のどれかのアプリケーションサーバが運用管理サーバを兼ねるシステム構成にもできます。

この場合は，運用管理サーバにするアプリケーションサーバマシンに，Management Serverのプロセスを配置してください。

(b)　アプリケーションサーバマシン

運用管理サーバで運用管理するために，それぞれのアプリケーションサーバマシンで起動するプロセスは次のとおりです。

運用管理エージェント

これ以外にアプリケーションサーバマシンに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

3.9.2　マシン単位にManagement Serverを配置する構成

Management Serverを利用して運用する場合に，それぞれのアプリケーションサーバマシンにManagement Serverを配置する構成について説明します。

(1)　システム構成の特徴

複数のアプリケーションサーバで構成されるシステムで，Management Serverをそれぞれのアプリケーションサーバマシンに配置する構成です。アプリケーションサーバ単位の運用管理および監視が実行できます。Management Serverは，運用管理エージェントと協調して，運用管理操作を実行します。

マシン単位にManagement Serverを配置する構成の例を次の図に示します。なお，この例では，接続するリソースマネジャについては省略しています。

図3‒47　マシン単位にManagement Serverを配置する構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

アプリケーションサーバ単位の運用に適しています。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

マシン単位にManagement Serverを配置する構成の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

マシン単位の運用管理をするためにそれぞれのアプリケーションサーバマシンで起動するプロセスは次のとおりです。

Management Server

運用管理エージェント

これ以外にアプリケーションサーバマシンに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

3.9.3　コマンドで運用する場合の構成

Management Serverを利用しないで運用する場合の構成について説明します。

Management Serverを利用しない場合は，定義ファイルの編集や，サーバ管理コマンドの実行などによって，アプリケーションサーバを運用します。このとき，それぞれのアプリケーションサーバに，運用管理エージェントおよびManagement Serverは不要です。アプリケーションサーバ以外の運用支援ソフトウェアなどを使用してシステムを管理する場合に，この構成を検討してください。

3.10　セッション情報の引き継ぎを検討する

この節では，セッション情報の引き継ぎを実現するためのシステム構成について説明します。この構成は，J2EEサーバが負荷分散機によって冗長化されていることが前提です。

セッション情報を引き継ぐ構成を次に示します。

データベースを使用する構成（データベースセッションフェイルオーバ機能を使用する場合）

3.10.1　データベースを使用する構成（データベースセッションフェイルオーバ機能）

データベースを使用してセッション情報を引き継ぐ構成について説明します。

(1)　システム構成の特徴

セッション情報を格納するためのデータベースを用意します。業務情報を格納するために使用しているデータベースがある場合は，同じデータベースを使用できます。

データベースを使用してセッション情報を引き継ぐ場合の構成の例を次の図に示します。

図3‒48　データベースを使用してセッション情報を引き継ぐ構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

特定のJ2EEサーバでトラブルが発生した場合に，セッション情報をほかのJ2EEサーバに引き継げます。

データベースサーバにトラブルが発生した場合も，データベースに格納したセッション情報は残ります。データベースサーバ再起動後に利用できます。

リクエストの流れ

データベースでは，J2EEサーバ上のグローバルセッション情報が冗長化されて管理されています。

J2EEサーバがリクエストを受け付けてセッションが確立された時点で，データベースに格納されたグローバルセッション情報にロックが掛けられます。J2EEアプリケーションの処理が完了すると，J2EEサーバ上のグローバルセッション情報の内容に合わせてデータベースのグローバルセッション情報が更新されます。そのあとで，データベースのロックが解除されます。

J2EEサーバにトラブルが発生した場合は，データベースに格納したグローバルセッション情報が別なJ2EEサーバから取得され，セッション情報が引き継がれます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン

データベースセッションフェイルオーバ機能を使用する場合，データベースに接続するためのソフトウェアをインストールする必要があります。必要なソフトウェアを次の表に示します。

使用するデータベース

必要なソフトウェア

HiRDB

HiRDB Type4 JDBC Driver

Oracle

Oracle JDBC Thin Driver

これ以外に必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　データベースサーバマシン

データベースが動作するマシンには，次に示すソフトウェアのどちらかをインストールしてください。

HiRDB（HiRDBと接続する場合）

Oracle（Oracleと接続する場合）

また，それぞれのデータベースで必要なプロセスを起動してください。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.11　クラスタソフトウェアを使用した障害時の系切り替えを検討する

この節では，クラスタソフトウェアを使用した障害時の系切り替えを実現するためのシステム構成について説明します。

アプリケーションサーバのシステムでは，OSごとに，次のクラスタソフトウェアを使用できます。

Windowsの場合

Windows Server Failover Cluster

AIXまたはLinuxの場合

HAモニタ

アプリケーションサーバで構築するシステムでは，クラスタソフトウェアを使用して，次に示す構成を実現できます。なお，これらの構成は，Management Serverを利用して運用することが前提になります。

アプリケーションサーバの実行系と待機系を1:1にする構成

実行系のアプリケーションサーバマシン1台に対して待機系のアプリケーションサーバマシンを1台用意しておく構成です。実行系のアプリケーションサーバマシンにトラブルが発生してマシンが終了した場合，または運用管理エージェントが終了した場合に，クラスタソフトウェアによって待機系のアプリケーションサーバを起動して処理を切り替えます。トランザクションサービスを使用しない場合と使用する場合で，共有ディスク装置の要否が異なります。なお，Windows Server Failover Clusterを使用する場合は，トランザクションサービスを使用しない場合も，共有ディスク装置が必要です。

運用管理サーバの実行系と待機系を1:1にする構成

実行系の運用管理サーバマシン1台に対して待機系の運用管理サーバマシンを1台用意しておく構成です。実行系の運用管理サーバマシンにトラブルが発生してマシンが終了した場合，またはManagement Serverのプロセスが終了した場合に，クラスタソフトウェアによって待機系の運用管理サーバを起動して処理を切り替えます。

アプリケーションサーバの実行系と待機系を相互スタンバイにする構成

アプリケーションサーバの実行系と待機系を1：1にする構成の一つです。それぞれのアプリケーションサーバに同じ種類のJ2EEサーバを配置して，異なるJ2EEサーバを起動しておくことで，それぞれのアプリケーションサーバが実行系として動作しながらお互いの待機系として機能します。どちらか一方の系に障害が発生すると，もう一方の系に切り替えられます。これによって，少ない台数のアプリケーションサーバマシンで，むだの少ない運用が可能になります。

この構成では，それぞれのアプリケーションサーバマシンでManagement Serverを起動して，それぞれに異なる運用管理ドメインを管理します。

N台の実行系に対して1台の待機系を用意する構成（リカバリ専用サーバを使用する構成）

この構成は，J2EEサーバを冗長化した構成でグローバルトランザクションを使用する場合に，特定のJ2EEサーバにトラブルが発生したときにトランザクションを決着するためのシステム構成です。

N台のJ2EEサーバを冗長化するためには，負荷分散機などを使用します。

ホスト単位管理モデルの実行系と待機系をN：1にする構成

アプリケーションサーバマシン（ホスト）の実行系複数（1〜N台）と待機系1台を配置し，それぞれにManagement Serverおよび運用管理エージェントを配置するシステムです。実行系のアプリケーションサーバマシンに障害が発生したときに待機系のアプリケーションサーバマシンに系を切り替えて，業務を続行できます。

3.11.1　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）

アプリケーションサーバの実行系と待機系を1:1にする構成の場合に，トランザクションサービスを使用しないときの構成について説明します。

(1)　システム構成の特徴

ローカルトランザクションを使用する場合など，トランザクションサービスを使用しない場合のシステム構成です。

なお，ここでは，アプリケーションサーバを系切り替えする場合の構成を示します。運用管理サーバを系切り替えする場合の構成については，「3.11.3　運用管理サーバの実行系と待機系を1:1にする構成」を参照してください。

トランザクションサービスを使用しない場合の構成の例を次の図に示します。

図3‒49　クラスタソフトウェアを使用して実行系と待機系を1:1にする場合のシステム構成の例（トランザクションサービスを使用しない場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

実行系と待機系は1：1で構成します。

HAモニタを使用する場合は，共有ディスク装置は不要です。Windows Server Failover Clusterを使用する場合は，共有ディスク装置が必要です。図は，HAモニタの場合の構成です。

データベースがクラスタ構成になっている場合でも，アプリケーションサーバでは仮想アドレス（論理アドレス）だけを認識していれば，接続できます。

Management Serverをアプリケーションサーバと同じマシンに配置する場合については，「3.11.6　ホスト単位管理モデルの実行系と待機系をN：1にする構成」を参照してください。

リクエストの流れ

クライアントからは，実行系，待機系のアプリケーションサーバは，合わせて1台として認識されます。リクエストは，すべて実行系のアプリケーションサーバに送信されます。

系切り替えの流れ

実行系のアプリケーションサーバマシンに障害が発生すると，系切り替えが実行されます。系切り替えは，OS，または運用管理エージェントがダウンした場合に実行されます。なお，このほか，明示的に系切り替えを実行するコマンドを実行した場合や，これ以外にクラスタソフトウェアが系切り替えの対象にしている事象が発生した場合も，系切り替えが実行されます。

系切り替えが実行されると，待機系のアプリケーションサーバの運用管理エージェント，およびそれまで停止していたプロセスが起動されます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン（実行系）

クラスタソフトウェアを使用する場合に必ず起動するプロセスは次のとおりです。

運用管理エージェント

これ以外にアプリケーションサーバに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　アプリケーションサーバマシン（待機系）

待機系のアプリケーションサーバマシンにインストールするソフトウェアの構成は，実行系と一致させてください。ただし，系切り替えが発生するまで，プロセスは起動しません。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　クライアントマシン

クライアントマシンには，次のソフトウェアをインストールしてください。

Webクライアント構成の場合

Webブラウザ

EJBクライアント構成の場合

Client（Windowsの場合），Application Server

3.11.2　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用する場合）

アプリケーションサーバの実行系と待機系を1:1にする構成の場合に，トランザクションサービスを使用するときの構成について説明します。

(1)　システム構成の特徴

グローバルトランザクションを使用する場合など，トランザクションサービスを使用する場合のシステム構成です。この場合，共有ディスク装置が必要です。

なお，ここでは，アプリケーションサーバを系切り替えする場合の構成を示します。運用管理サーバを系切り替えする場合の構成については，「3.11.3　運用管理サーバの実行系と待機系を1:1にする構成」を参照してください。

トランザクションサービスを使用する場合の構成の例を次の図に示します。

図3‒50　クラスタソフトウェアを使用してアプリケーションサーバの実行系と待機系を1:1にする場合のシステム構成の例（トランザクションサービスを使用する場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

実行系と待機系は1：1で構成します。

共有ディスク装置が必要です。

データベースがクラスタ構成になっている場合でも，アプリケーションサーバでは仮想アドレス（論理アドレス）だけを認識していれば，接続できます。

Management Serverをアプリケーションサーバと同じマシンに配置する場合については，「3.11.3　運用管理サーバの実行系と待機系を1:1にする構成」を参照してください。

リクエストの流れ

クライアントからは，実行系，待機系のアプリケーションサーバは，合わせて1台として認識されます。リクエストは，すべて実行系のアプリケーションサーバに送信されます。

系切り替えの流れ

実行系のアプリケーションサーバマシンに障害が発生すると，系切り替えが実行されます。系切り替えは，OS，または運用管理エージェントがダウンした場合に実行されます。なお，このほか，明示的に系切り替えを実行するコマンドを実行した場合や，これ以外にクラスタソフトウェアが系切り替えの対象にしている事象が発生した場合も，系切り替えが実行されます。

系切り替えが実行されると，待機系のアプリケーションサーバの運用管理エージェント，およびそれまで停止していたプロセスが起動されます。なお，トランザクション情報については，共有ディスクに格納されていた情報が引き継がれます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスは，トランザクションサービスを利用しない場合と同じです。

3.11.3　運用管理サーバの実行系と待機系を1:1にする構成

運用管理サーバを系切り替えの対象にする場合の構成について説明します。運用管理サーバの実行系と待機系を1：1にします。

(1)　システム構成の特徴

運用管理サーバの実行系と待機系を1：1にする場合の構成の例を次に示します。

図3‒51　クラスタソフトウェアを使用して運用管理サーバの実行系と待機系を1:1にする場合のシステム構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

実行系と待機系は1：1で構成します。それぞれのマシンにManagement Serverを配置します。

Windows Server Failover Clusterを使用する場合は，共有ディスク装置が必要です。

系切り替えの流れ

実行系の運用管理サーバマシンに障害が発生すると，系切り替えが実行されます。系切り替えは，OS，またはManagement Serverがダウンした場合に実行されます。なお，このほか，明示的に系切り替えを実行するコマンドを実行した場合や，これ以外にクラスタソフトウェアが系切り替えの対象にしている事象が発生した場合も，系切り替えが実行されます。

系切り替えが実行されると，待機系の運用管理サーバのManagement Serverのプロセスが起動されます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　運用管理サーバマシン（実行系）

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　運用管理サーバマシン（待機系）

待機系のアプリケーションサーバマシンにインストールするソフトウェアの構成は，実行系と一致させてください。ただし，系切り替えが発生するまで，プロセスは起動しません。

(d)　クライアントマシン

クライアントマシンには，次のソフトウェアをインストールしてください。

Webクライアント構成の場合

Webブラウザ

EJBクライアント構成の場合

Client（Windowsの場合），Application Server

3.11.4　アプリケーションサーバの実行系と待機系を相互スタンバイにする構成

アプリケーションサーバの実行系と待機系を1：1にする構成で，それぞれのアプリケーションサーバを実行系として稼働させながら，お互いの待機系にする構成について説明します。この構成を，相互スタンバイ構成といいます。また，この構成で構築されたシステムを，相互系切り替えシステムといいます。

(1)　システム構成の特徴

この構成は，実行系のアプリケーションサーバマシン1台に対して待機系のアプリケーションサーバマシンを1台用意しておく構成の一つです。ただし，待機系のアプリケーションサーバを停止させておくのではなく，実行系とは異なるJ2EEサーバを動作させておきます。これを，相互スタンバイといいます。

それぞれのアプリケーションサーバに同じ種類のJ2EEサーバを配置して，異なるJ2EEサーバを起動しておくことで，それぞれのアプリケーションサーバが現用系として動作しながらお互いの予備系として機能します。どちらかのマシンに障害が発生した場合は，系が切り替えられ，もう片方のアプリケーションサーバマシンで両方のJ2EEサーバの処理が実行されるようになります。

この構成は，次のことが前提になります。

CORBAネーミングサービスはインプロセスで起動されていること

グローバルトランザクションを使用する場合，トランザクションのステータスファイルは共有ディスクに格納されていること

Management Serverを利用して運用していること

Management Serverは，アプリケーションサーバと同じマシンに，一つずつ配置して，両方のホストで起動します。それぞれのManagement Serverは，別の運用管理ドメインを管理します。それぞれの運用管理ドメインの範囲は，Management Serverが配置されているアプリケーションサーバマシン内です。

相互系切り替えシステムの構成の例を次の図に示します。この例は，トランザクションサービスを使用する例です。共有ディスクは，トランザクションサービスを使用する場合にだけ必要です。

図3‒52　相互系切り替えシステムの構成の例（トランザクションサービスを使用する場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

実行系と待機系は1：1で構成します。それぞれのマシンにManagement Serverを配置します。

一つの運用管理ドメイン（一つのマシン）内に，二つの仮想ホストを定義します。それぞれの仮想ホストを，実行系のアプリケーションサーバのホスト，待機系のアプリケーションサーバのホストとして，システムを構築します。

運用管理ドメイン内のそれぞれの仮想ホストは，一つの運用管理エージェントで起動・停止を制御されます。ただし，それぞれの仮想ホストには実際に運用に使用されるIPアドレスとは異なるIPアドレスが割り当てられているため，見かけ上異なるホスト上で動作しているように定義されています。

各アプリケーションサーバの運用に使用するIPアドレスは，クラスタソフトウェアによって動的に割り当てられるIPアドレスを使用します。Management Serverから運用管理エージェントに対するリクエストの送信には，系切り替えによって他系へ移動しないIPアドレスを使用します。

グローバルトランザクションを使用する場合は，共有ディスク装置が必要です。共有ディスクは，仮想ホストごとに必要です。

図の場合，仮想ホスト単位にLANを分けていますが，必須ではありません。

系切り替えの流れ

どちらかのアプリケーションサーバマシンに障害が発生すると，系切り替えが実行されます。系切り替えは，Management Server，運用管理エージェント，またはクラスタソフトウェアなどに障害が発生した場合に実行されます。なお，このほか，明示的に系切り替えを実行するコマンドを実行した場合や，これ以外にクラスタソフトウェアが系切り替えの対象にしている事象が発生した場合も，系切り替えが実行されます。

系切り替えが実行されると，待機系だった側のアプリケーションサーバマシンの運用管理エージェントによって，それまで停止していた論理サーバのプロセスが起動されます。

例えば，図の場合に，アプリケーションサーバ1に障害が発生した場合は，クラスタソフトウェアによってアプリケーションサーバ2への系切り替えが実行され，アプリケーションサーバ2の運用管理エージェントによって，アプリケーションサーバ2上のJ2EEサーバ1およびそれ以外の論理サーバのプロセスが起動されます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン（実行系1／待機系2）

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。

相互系切り替えシステムのアプリケーションサーバマシンで必ず起動するプロセスは次のとおりです。

運用管理エージェント

Management Server

これ以外にアプリケーションサーバに必要なソフトウェアおよびプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

なお，系切り替えの対象になるプロセスは，仮想ホスト1のプロセスだけを起動してください。

(b)　アプリケーションサーバマシン（待機系1／実行系2）

待機系のアプリケーションサーバマシンにインストールするソフトウェアおよびプロセスの構成は，実行系1／待機系2と一致させてください。

なお，系切り替えの対象になるプロセスは，仮想ホスト2のプロセスだけを起動してください。

(c)　クライアントマシン

クライアントマシンには，次のソフトウェアをインストールしてください。

Webクライアント構成の場合

Webブラウザ

EJBクライアント構成の場合

Client（Windowsの場合），Application Server

3.11.5　リカバリ専用サーバを使用する場合の構成（N:1リカバリシステム）

N台の実行系に対して1台の待機系（リカバリ専用サーバ）を用意する構成について説明します。この構成を，N:1リカバリシステムといいます。

(1)　システム構成の特徴

この構成は，J2EEサーバを冗長化した構成でグローバルトランザクションを使用する場合に，特定のJ2EEサーバにトラブルが発生したときにトランザクションを解決してリソースを解放するためのシステム構成です。N台のJ2EEサーバを冗長化するためには，負荷分散機などを使用します。

次のことが前提になります。

グローバルトランザクションを使用するシステムで利用されること

CORBAネーミングサービスはインプロセスで起動されていること

トランザクションのステータスファイルは共有ディスクに格納されていること

Management Serverを利用して運用していること

なお，N:1リカバリシステムで系切り替えの対象になるのは，アプリケーションサーバです。

また，N:1リカバリシステムを構成する場合，実行系で使用するリソースアダプタが，待機系にも必要です。ここでは，リソースアダプタの配置とシステム構成の関係について，次の3種類の構成を例として説明します。

N台の実行系マシンで，J2EEアプリケーションとリソースアダプタの構成がすべて同じ場合

N台の実行系マシンで，J2EEアプリケーションの構成は異なり，リソースアダプタはすべて同一の場合

N台の実行系マシンで，J2EEアプリケーションとリソースアダプタの構成がすべて異なる場合

次にそれぞれの構成の例を示します。

図3‒53　N:1リカバリシステムのシステム構成の例（N台の実行系マシンで，J2EEアプリケーションとリソースアダプタの構成がすべて同じ場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

図3‒54　N:1リカバリシステムのシステム構成の例（N台の実行系マシンで，J2EEアプリケーションの構成は異なり，リソースアダプタはすべて同一の場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

図3‒55　N:1リカバリシステムのシステム構成の例（N台の実行系マシンで，J2EEアプリケーションとリソースアダプタの構成がすべて異なる場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

実行系と待機系はN：1で構成します。

共有ディスク装置が必要です。共有ディスク装置には実行系の個数（N個）分のボリュームグループが必要です。

CORBAネーミングサービスはインプロセスで起動します。

待機系には，実行系と同じリソースアダプタが必要です。実行系のJ2EEサーバごとに異なるリソースアダプタがインポートされている場合，待機系のJ2EEサーバにはそれらすべてをインポートする必要があります。

なお，待機系のJ2EEサーバにJ2EEアプリケーションは不要です。

データベースがクラスタ構成になっている場合でも，アプリケーションサーバでは仮想アドレス（論理アドレス）だけを認識していれば，接続できます。

系切り替えの流れ

実行系のアプリケーションサーバで起動されているJ2EEサーバのうち，どれかのJ2EEサーバにトラブルが発生すると，クラスタソフトウェアによってリカバリ専用サーバのJ2EEサーバが起動され，トラブルが発生したJ2EEサーバが使用していたトランザクションが決着されます。そのあとで，トラブルが発生したJ2EEサーバマシンのクラスタソフトウェアと，それに対応する待機系のクラスタサービスが停止されます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン（実行系）

実行系のアプリケーションサーバマシンには，Application Serverをインストールする必要があります。

クラスタソフトウェアを使用する場合に必ず起動するプロセスは次のとおりです。

運用管理エージェント

これ以外にアプリケーションサーバに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　アプリケーションサーバマシン（待機系）

待機系のアプリケーションサーバマシンには，Application Serverをインストールする必要があります。

また，実行系のアプリケーションサーバマシン上のJ2EEサーバにインポートされているすべてのリソースアダプタをインポートしてください。

なお，待機系のアプリケーションサーバマシンは，コールドスタンバイの状態になります。

系切り替えが発生するまで，プロセスは起動しません。系切り替えが発生すると，J2EEサーバのプロセスが，リカバリモードで起動されます。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　クライアントマシン

クライアントマシンには，次のソフトウェアをインストールしてください。

Webクライアント構成の場合

Webブラウザ

EJBクライアント構成の場合

Client（Windowsの場合），Application Server

3.11.6　ホスト単位管理モデルの実行系と待機系をN：1にする構成

ホスト単位管理モデルを系切り替えの対象にする場合の構成について説明します。

(1)　システム構成の特徴

ホスト単位管理モデルをN：1で構成します。システム構成の例を次に示します。

図3‒56　クラスタソフトウェアを使用してホスト単位管理モデルを対象にした系切り替えシステムのシステム構成例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

アプリケーションサーバの実行系N台と待機系1台を配置し，それぞれにManagement Serverと運用管理エージェントを配置している構成です。

論理サーバは別々のホスト内に配置されているが，外部からは同じ論理サーバとして動作するのに対し，Management Serverは別々のホスト内で動作し，それぞれ運用管理ドメインを持ちます。一つの運用管理ドメイン内に一つの仮想ホストを定義し，それぞれを現用系アプリケーションサーバのホスト，予備系アプリケーションサーバのホストとして構築します。

各アプリケーションサーバの運用に使用するIPアドレスは，クラスタソフトウェアによって割り当てられる仮想IPアドレスを使用し，Management Server，運用管理エージェントのIPアドレスには実IPアドレスを使用します。

グローバルトランザクションを使用する場合は，共有ディスク装置が必要です。共有ディスクは，仮想ホストごとに必要です。

参考

仮想ホストとは，運用管理エージェントによってアプリケーションサーバの起動，停止を制御しますが，運用に使用するIPアドレスと同じIPアドレスを割り当て，見かけ上同じホストであるかのように定義したものです。

系切り替えの流れ

実行系のアプリケーションサーバマシンに障害が発生すると，系切り替えが実行されます。系切り替えは，Management Server，運用管理エージェント，またはクラスタソフトウェアなどに障害が発生した場合に実行されます。

系切り替えが実行されると，待機系のアプリケーションサーバマシンのクラスタソフトウェアによって運用管理エージェントとManagement Serverが起動されます。起動された運用管理エージェントによって，それまで停止していた論理サーバのプロセスが起動されます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン（実行系／待機系）

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。

ホスト単位管理モデルを対象とした系切り替えシステムのアプリケーションサーバマシンで必ず起動するプロセスは次のとおりです。

運用管理エージェント

Management Server

これ以外にアプリケーションサーバに必要なソフトウェアおよびプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　クライアントマシン

クライアントマシンには，次のソフトウェアをインストールしてください。

Webクライアント構成の場合

Webブラウザ

EJBクライアント構成の場合

Client（Windowsの場合），Application Server

3.12　性能解析トレースファイルを出力するプロセスを配置する

この節では，性能解析トレースファイルを出力するプログラムの配置について説明します。このプロセスは，アプリケーションサーバのシステムには必ず配置するプロセスです。アプリケーションサーバマシンには必ず配置してください。EJBクライアントマシンへの配置は任意です。

性能解析トレースファイルは，PRFデーモン（パフォーマンストレーサ）によって出力されます。

3.12.1　システム構成の特徴

PRFデーモンは，アプリケーションサーバおよびEJBクライアントアプリケーションを実行するマシンに配置します。

PRFデーモンを配置する例を次の図に示します。

図3‒57　PRFデーモンを配置する例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

システム性能を解析するためのトレースファイルを出力できます。

トレースファイルは，トラブルが発生した場合のエラー個所の特定に利用できます。

性能解析トレースを出力する仕組み

クライアントとサーバ間でリクエストを処理するときに，アプリケーションサーバまたはEJBクライアントアプリケーションの各機能レイヤは，性能解析情報をバッファに出力します。PRFデーモンは，アプリケーションサーバまたはEJBクライアントアプリケーションの各機能レイヤがバッファに出力したトレース情報を，各マシン内のファイルに出力します。ファイル出力されたトレース情報は，Management Serverを利用して収集できます。

3.12.2　それぞれのマシンに必要なソフトウェアと起動するプロセス

性能解析トレースファイルを出力するために起動するプロセスは次のとおりです。

PRFデーモン

これ以外にアプリケーションサーバに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

3.13　アプリケーションサーバ以外の製品との連携を検討する

この節では，アプリケーションサーバ以外の製品と連携する場合のシステム構成について説明します。

ここでは，次の構成について説明します。

JP1を使用して運用する場合の構成

運用管理プログラムとしてJP1を使用する場合の構成です。

TP1インバウンド連携機能を使用してOpenTP1のSUPからMessage-driven Beanを呼び出す場合の構成

TP1インバウンド連携機能を使用してOpenTP1のSUPからアプリケーションサーバ上のMessage-driven Beanを呼び出す場合の構成です。

CTMゲートウェイ機能を利用してEJBクライアント以外からStateless Session Beanを呼び出す構成

クライアントとしてTPBrokerクライアントまたはTPBroker OTMクライアントを使用する場合の構成です。

3.13.1　JP1を使用して運用する場合の構成

JP1を使用して運用する場合の運用管理プログラムの配置について説明します。

JP1/IMと連携する場合，またはカスタムジョブの定義やシナリオなどアプリケーションサーバが提供する機能を利用してJP1/AJSと連携する場合には，Management Serverを利用して運用していることが前提になります。「3.9.1　運用管理サーバにManagement Serverを配置する構成」または「3.9.2　マシン単位にManagement Serverを配置する構成」を参照してManagement Serverを利用するシステムの構成を決定した上で，JP1のプログラムを配置してください。JP1との連携で必要なプログラムについては，マニュアル「アプリケーションサーバ機能解説 運用／監視／連携編」の「12.　JP1と連携したシステムの運用」を参照してください。

なお，JP1/AJSを利用する場合に，アプリケーションサーバの機能を使用しないでジョブまたはシナリオの定義をするときには，Management Serverを利用しなくても連携できます。この場合は，「3.9.3　コマンドで運用する場合の構成」に示すシステムの構成を検討した上で，JP1のマニュアルを参照して，システム構成を決定してください。

3.13.2　TP1インバウンド連携機能を使用してOpenTP1のSUPからMessage-driven Beanを呼び出す場合の構成

TP1インバウンド連携機能を使用して，OpenTP1システムのSUPからJ2EEサーバ上のMessage-driven Beanを呼び出す構成について説明します。

(1)　システム構成の特徴

メッセージ駆動型のシステムの一つです。

TP1インバウンド連携機能を使用する場合のメッセージ駆動型のシステム構成の例を次の図に示します。

図3‒58　メッセージ駆動型のシステム構成の例（TP1インバウンド連携機能を使用する場合）

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

TP1/Server Base上で動作するSUPから送信されたリクエストをJ2EEサーバ上で動作するTP1インバウンドアダプタで受け付けて，処理を実行します。SUPからは，SPPを呼び出すときと同様の手順※で，J2EEサーバ上のMessage-driven Beanにアクセスできます。

注※

一部の手順は異なります。詳細は，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「4.　OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）」を参照してください。

リクエストの流れ

アクセスポイントであるMessage-driven Bean，およびリソースアダプタであるTP1インバウンドアダプタのライブラリは，アプリケーションサーバのJ2EEサーバ上で動作します。

OpenTP1システムのTP1/Server Base上で動作するSUPからからのリクエストをアプリケーションサーバ上のTP1インバウンドアダプタで受け付け，Message-driven Beanを呼び出します。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシン（サーバ側のアプリケーションサーバマシン）には，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　OpenTP1システム（TP1/Server Base）

OpenTP1システムには，TP1/Server Baseをインストールする必要があります。

起動する必要があるプロセスは，SUPの実行に必要なプロセスです。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.13.3　CTMゲートウェイ機能を利用してEJBクライアント以外からStateless Session Beanを呼び出す構成

CTMを使用するシステムの場合，EJBクライアントのほか，次に示すクライアントからアプリケーションサーバ上で動作するJ2EEアプリケーションを呼び出せます。

TPBrokerクライアント

TPBroker Version 5以降で開発されたクライアントアプリケーションです。

TPBroker OTMクライアント

TPBroker Object Transaction Monitorで開発されたクライアントアプリケーションです。

これらのクライアントからJ2EEサーバ上のアプリケーションを呼び出すためのクライアントアプリケーションの開発方法については，CTMのCORBA／OTMゲートウェイ機能についてのドキュメントを参照してください。

この構成では，TPBrokerクライアントまたはTPBroker OTMクライアントからJ2EEアプリケーションを呼び出すためのゲートウェイとしての機能を，CTMが提供します。

TPBrokerクライアントまたはTPBroker OTMクライアントからCTM経由でJ2EEアプリケーションを呼び出すシステム構成の例を次の図に示します。

図3‒59　TPBrokerクライアントまたはTPBroker OTMクライアントからCTM経由でJ2EEアプリケーションを呼び出す構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

TPBrokerクライアントまたはTPBroker OTMクライアントからのリクエストは，CTMが提供するプロセス群を経由して，J2EEサーバ上のJ2EEアプリケーションに渡されます。

なお，CTMのプロセス群のうち，リクエストを受け付けるプロセスは，TPBrokerクライアントの場合とTPBroker OTMクライアントの場合で異なります。TPBrokerクライアントの場合，CTMレギュレータプロセスによってリクエストが受け付けられます。TPBroker OTMクライアントの場合，OTMゲートウェイプロセスによってリクエストが受け付けられます。なお，CTMレギュレータプロセス，およびOTMゲートウェイプロセスは，CTMデーモンを起動するときに，同時に起動されるプロセスです。

3.14　任意のプロセスを運用管理の対象にする

この節では，ユーザが定義する任意のプロセスを，Management Serverによる運用管理の対象とするためのシステム構成について説明します。

Management Serverによる運用管理の対象とする任意のプロセスを，論理サーバとして定義したユーザサーバとして配置します。論理サーバとして定義したユーザサーバを論理ユーザサーバといいます。論理ユーザサーバとして定義しておくと，Smart Composer機能のコマンドを使用して，任意のプロセスを開始したり，停止したり，任意のプロセスのステータスを監視したりできるようになります。

3.14.1　システム構成の特徴

このシステム構成は，Management Serverで運用管理するシステムで，論理サーバとして定義したユーザサーバを配置する構成です。運用管理に使用するManagement Serverは，運用管理サーバに配置することも，マシン単位に配置することもできます。Management Serverの配置については，「3.9　運用管理プロセスの配置を検討する」を参照してください。

ユーザサーバを配置する構成の例を次の図に示します。この構成例では，アプリケーションサーバマシンでユーザ任意のプロセスを実行します。このユーザ任意のプロセスをManagement Serverの運用管理の対象とするために，論理ユーザサーバとして定義して，配置しています。

図3‒60　ユーザサーバを配置する構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

Management Serverを利用して任意のプロセスを運用管理できます。

3.14.2　それぞれのマシンで起動するプロセス

任意のプロセスをユーザサーバとして配置する構成の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(1)　アプリケーションサーバマシン

アプリケーションサーバマシンに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(2)　運用管理サーバマシン

運用管理サーバマシンには，Application Serverをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.15　アプリケーションサーバのプロセスが使用するTCP/UDPのポート番号

ここでは，アプリケーションサーバのプロセスが使用するTCP/UDPのポート番号について説明します。

デフォルト値が「（浮動）」のポートは，ポート番号を明示的に固定しない場合にアプリケーションサーバによって自動的に番号が付けられるポートです。

アプリケーションサーバが使用するTCP/UDPのポート番号の説明を次の表に示します。なお，ご使用のOSによっては，ネットワーク単位ではなくホスト単位でファイアウォールが設定されているものがあります。これらのファイアウォールでは，localhost（127.0.0.1）以外との通信は，同一ホスト内でもファイアウォールのフィルタリングの対象になる場合があります。この場合は，ホスト内でしか通信しないポートであっても，フィルタで通信を許可する設定にしてください。

表3‒3　アプリケーションサーバが使用するTCP/UDPのポート番号

項番

プロセス

説明

デフォルト値

(1)

J2EEサーバ

EJBコンテナのリクエスト受付ポート。

（浮動）

(2)

管理用通信ポート。

28008

(3)

トランザクションサービス使用時のトランザクションリカバリ処理通信ポート。

トランザクションサービス使用時に必要です。

20302

(4)

インプロセスで起動するネーミングサービスのリクエスト受付ポート。

900

(5)

HTTP通信/WebSocket通信のリクエスト受付ポート。

8008

(6)

RMIレジストリのリクエスト受付ポート。

23152

(7)

共有キューを使用して複数システム間でのアプリケーション連携をする場合のイベント受信用ポート。

20351

(8)

稼働情報取得時のリクエスト受付ポート。

23550

(9)

OpenTP1からのRPC要求を待ち受けるポート。

23700

(10)

OpenTP1からの同期点要求を待ち受けるポート。

23900

(11)

運用監視エージェント

運用監視エージェントの通信用ポート。

（浮動）

(12)

スマートエージェント

スマートエージェントの通信用ポート環境変数。

UDPによる双方向通信に必要です。

14000

(13)

ネーミングサービス

ネーミングサービスのリクエスト受付ポート引数（TPBrokerが利用）。

900

(14)

運用管理エージェント

運用管理エージェントがManagement Serverとの通信に使用するポート。

20295

(15)

サーバ通信エージェント

サーバ通信エージェントが仮想サーバマネージャとの通信に使用するポート。

20580

(16)

Management Server

Management Serverのhttpポート。

28080

(17)

Management Serverの終了要求ポート。

ホスト内通信に必要です。

28005

(18)

Management Serverの内部通信ポート。

ホスト内通信に必要です。

28009

(19)

Managerリモート管理機能への接続ポート。

28099

(20)

Managerリモート管理機能へのクライアント接続ポート。

（浮動）

(21)

HTTP Server

HTTP Serverのhttpポート。

80

(22)

HTTP Serverのhttpsポート。

443

(23)

サーバ管理コマンド

サーバ管理コマンドがJ2EEサーバと通信するポート。

（浮動）

(24)

CTMレギュレータ

CTMレギュレータがEJBクライアントからのリクエストを受け付けるポートの基底値。基底値＋プロセス数だけ使用します。

CTM使用時に必要です。

（浮動）

(25)

CTMデーモン

CTMデーモンがEJBクライアントからのリクエストを受け付けるポート。

CTM使用時に必要です。

（浮動）

(26)

CTMデーモンがほかのデーモンやJ2EEサーバなどと通信するポート。

CTM使用時に必要です。

20138

(27)

CTMドメインマネジャ

CTMドメインマネジャがほかのCTMドメインマネジャと通信するポート。

CTM使用時に，TCPおよびUDP通信（ブロードキャスト）をするために必要です。

20137

(28)

CJMSPブローカー

CJMSプロバイダのブローカーがリソースアダプタやコマンドからのリクエストを受け付けるためのポート。

7676

(29)

CJMSプロバイダのブローカーがリソースアダプタとコネクションを確立するためのポート。

（浮動）

(30)

CJMSプロバイダのブローカーがコマンドとコネクションを確立するためのポート。

（浮動）

(31)

Management Server

HCSC-Managerから利用されるManagement Serverの内部通信用ポート。

28900

アプリケーションサーバのプロセスが使用するTCP/UDPのポート番号について，次の図に示します。(x)は表の項番と対応しています。

図3‒61　アプリケーションサーバが使用するTCP/UDPのポート番号

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

ポート番号の指定個所を次の表に示します。表の項番は図中の項番と対応しています。

表3‒4　アプリケーションサーバが使用するTCP/UDPのポート番号の指定個所

項番

定義ファイル

設定対象

パラメタ名※1

(1)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

vbroker.se.iiop_tp.scm.iiop_tp.listener.port

(2)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.http.port

(3)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.distributedtx.recovery.port

(4)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.naming.port

(5)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.port

(6)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.rmi.naming.port

(7)

Connector属性ファイル

Reliable Messaging

<config-property>タグに指定するRMSHPort※2

(8)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.rmi.remote.listener.port

(9)

Connector属性ファイル

TP1インバウンドアダプタ

<config-property>タグに指定するscd_port※3

(10)

Connector属性ファイル

TP1インバウンドアダプタ

<config-property>タグに指定するtrn_port※3

(11)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

mngagent.connector.port

(12)

簡易構築定義ファイル

論理スマートエージェント（smart-agent）

smartagent.port

(13)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.naming.port

(14)

adminagent.properties

運用管理エージェント

adminagent.adapter.portキー

(15)

sinaviagent.properties※4

サーバ通信エージェント

sinaviagent.portキー

(16)

mserver.properties

Management Server

webserver.connector.http.portキー

(17)

mserver.properties

Management Server

webserver.shutdown.portキー

(18)

mserver.properties

Management Server

webserver.connector.ajp13.portキー

(19)

mserver.properties

Management Server

com.cosminexus.mngsvr.management.portキー

(20)

mserver.properties

Management Server

com.cosminexus.mngsvr.management.listen.portキー

(21)

簡易構築定義ファイル

論理Webサーバ

（web-server）

Listen

(22)

簡易構築定義ファイル

論理Webサーバ

（web-server）

Listen

(23)

usrconf.properties（サーバ管理コマンド用システムプロパティファイル）

サーバ管理コマンド

vbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

(24)

簡易構築定義ファイル

論理CTM（component-transaction-monitor）

ctm.RegOption

(25)

簡易構築定義ファイル

論理CTM（component-transaction-monitor）

ctm.EjbPort

(26)

簡易構築定義ファイル

論理CTM（component-transaction-monitor）

ctm.port

(27)

簡易構築定義ファイル

論理CTMドメインマネジャ（ctm-domain-manager）

cdm.port

(28)

config.properties

CJMSPブローカー

imq.portmapper.portキー

(29)

config.properties

CJMSPブローカー

imq.jms.tcp.portキー

(30)

config.properties

CJMSPブローカー

imq.admin.tcp.portキー

(31)

mserver.properties

Management Server

ejbserver.naming.portキー

（凡例）−：該当しない。

注※1　設定ファイルが簡易構築定義ファイルの場合は，<configuration>タグ内の<param-name>の指定値を指します。

注※2　RMSHPortは，リソースアダプタReliable Messagingのプロパティ定義で指定するコンフィグレーションプロパティです。RMSHPortについては，マニュアル「Reliable Messaging」の「6.　コンフィグレーションプロパティ」を参照してください。

注※3　scd_portおよびtrn_portは，リソースアダプタTP1インバウンドアダプタのプロパティ定義で指定するコンフィグレーションプロパティです。scd_portおよびtrn_portについては，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「4.12.2　リソースアダプタの設定」を参照してください。

注※4　サーバ通信エージェントの詳細については，サーバ通信エージェントのドキュメントを参照してください。

参考

運用管理ポータルまたはファイル編集によってアプリケーションサーバを構築している場合のTCP/UDPのポートの設定個所を次に示します。

表3‒5　運用管理ポータルまたはファイル編集によってアプリケーションサーバを構築している場合のTCP/UDPのポートの設定個所

項番

運用管理ポータルで構築している場合の設定個所

ファイル編集で構築している場合の設定個所

(1)

J2EEサーバの場合

［EJBコンテナの設定］画面の「オプション」の「通信ポート番号」

usrconf.propertiesのvbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

(2)

［J2EEサーバの基本設定］画面の「コンテナの設定」の「管理用サーバのポート番号」

usrconf.propertiesのejbserver.http.portキー

(3)

［トランザクションの設定］画面の「トランザクションに関する設定」の「JTAリカバリの固定ポート番号」

usrconf.propertiesのejbserver.distributedtx.recovery.portキー

(4)

J2EEサーバの場合

［ネーミングの設定］画面の「インプロセス選択時の設定」の「ポート番号」

usrconf.propertiesのejbserver.naming.portキー

(5)

［Webコンテナの設定］画面の「NIO HTTP」の「ポート番号」

usrconf.propertiesのebserver.connector.nio_http.portキー

(6)

J2EEサーバの場合

［通信の設定］画面の「RMIレジストリの設定」の「ポート番号」

usrconf.propertiesのejbserver.rmi.naming.portキー

(7)

Connector属性ファイルの<config-property>タグに指定するRMSHPort※1

Connector属性ファイルの<config-property>タグに指定するRMSHPort※1

(8)

J2EEサーバの場合

［通信の設定］画面の「RMIレジストリの設定」の「通信ポート番号」

usrconf.propertiesのejbserver.rmi.remote.listener.portキー

(9)

TP1インバウンドアダプタのConnector属性ファイルのリソースアダプタの<config-property>タグに指定するscd_port

TP1インバウンドアダプタのConnector属性ファイルのリソースアダプタの<config-property>タグに指定するscd_port

(10)

TP1インバウンドアダプタのConnector属性ファイルのリソースアダプタの<config-property>タグに指定するtrn_port

TP1インバウンドアダプタのConnector属性ファイルのリソースアダプタの<config-property>タグに指定するtrn_port

(11)

J2EEサーバの場合

［J2EEコンテナの設定］画面の「運用監視エージェントの設定」の「ポート番号」

mngagent.<実サーバ名>.propertiesのmngagent.connector.portキー

(12)

［スマートエージェントの設定］画面の「スマートエージェントに関する設定」の「監視ポート番号」

環境変数OSAGENT_PORT

(13)

CORBAネーミングサービスをインプロセスで起動する場合

［J2EEサーバの基本設定］画面の「利用するネーミングサービスの設定」の「インプロセス用のポート番号」

CORBAネーミングサービスをアウトプロセスで起動する場合

［ホスト内のサーバの設定］画面の「ネーミングサービスの設定」の「ネーミングサービスのポート番号」

CORBAネーミングサービスをインプロセスまたはアウトプロセスで自動起動する場合

usrconf.propertiesのejbserver.naming.portキー

CORBAネーミングサービスを手動起動する場合

nameservコマンドのコマンド引数に「-Dvbroker.se.iiop_tp.scm.iiop_tp.listener.port=<ポート番号>」を指定。

(14)

adminagent.propertiesのadminagent.adapter.portキー

adminagent.propertiesのadminagent.adapter.portキー

(15)

sinaviagent.propertiesのsinaviagent.portキー※2

sinaviagent.propertiesのsinaviagent.portキー

(16)

［ネットワークの設定］画面の「Management Server接続HTTPポート番号」

mserver.propertiesのwebserver.connector.http.portキー

(17)

［ネットワークの設定］画面の「Management Server終了要求受信ポート番号」

mserver.propertiesのwebserver.shutdown.portキー

(18)

mserver.propertiesのcom.cosminexus.mngsvr.management.portキー

mserver.propertiesのcom.cosminexus.mngsvr.management.portキー

(19)

mserver.propertiesのcom.cosminexus.mngsvr.management.listen.portキー

mserver.propertiesのcom.cosminexus.mngsvr.management.listen.portキー

(20)

［ホスト内のサーバの設定］画面の「J2EEサーバの設定」の「ポート番号」の「http」

httpsd.confのListenディレクティブまたはPortディレクティブ

(21)

［ホスト内のサーバの設定］画面の「J2EEサーバの設定」の「ポート番号」の「https」

httpsd.confのListenディレクティブまたはPortディレクティブ

(22)

usrconf.properties（サーバ管理コマンド用システムプロパティファイル）のvbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

usrconf.properties（サーバ管理コマンド用システムプロパティファイル）のvbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

(23)

［レギュレータの設定］画面の「CTMレギュレータの設定」の「設定ファイル」

ctmregltdコマンドまたはctmstartコマンドの引数-CTMEjbPort

(24)

［スケジューリングの設定］画面の「詳細設定」の「EJBリクエスト受信ポート番号」

ctmstartコマンドの引数-CTMEjbPort

(25)

［CTMの基本設定］画面の「基本設定」の「ポート番号」

ctmstartコマンドの引数-CTMPort

(26)

［CTMドメインマネジャの基本設定］画面の「ポート番号」

ctmdmstartコマンドの引数-CTMPort

(27)

config.propertiesのimq.portmapper.portキー

config.propertiesのimq.portmapper.portキー

(28)

config.propertiesのimq.jms.tcp.portキー

config.propertiesのimq.jms.tcp.portキー

(29)

config.propertiesのimq.admin.tcp.portキー

config.propertiesのimq.admin.tcp.portキー

(30)

vmx.propertiesのvmx.vcenterserver.agent.portキー

vmx.propertiesのvmx.vcenterserver.agent.portキー

(31)

mserver.propertiesのejbserver.naming.portキー

mserver.propertiesのejbserver.naming.portキー

注※1　RMSHPortは，リソースアダプタReliable Messagingのプロパティ定義で指定するコンフィグレーションプロパティです。RMSHPortについては，マニュアル「Reliable Messaging」の「6.　コンフィグレーションプロパティ」を参照してください。

注※2　サーバ通信エージェントの詳細については，サーバ通信エージェントのドキュメントを参照してください。

注意事項

サーバの待ち受けポートの注意事項（UNIXの場合）

UNIXの場合，次の条件がすべて重なるときは，待ち受けをしていないTCPポートに対して，接続に成功してしまうことがあります。

待ち受けをしていないポートに対して接続試行を実行する

接続対象が自ホストであり，かつ一時ポート番号の範囲（OSが動的に割り当てるポートの範囲）である

この現象が発生した場合，想定したプロセスとの通信ができないで，タイムアウトなどが発生します。この現象を回避するためには，サーバの待ち受けポートに一時ポート番号の範囲以外の値を指定してください。一時ポート番号の範囲は，次のファイルで確認できます。

AIXの場合

最小値（32768）：no -o tcp_ephemeral_low

最大値（65535）：no -o tcp_ephemeral_high

Linuxの場合

/proc/sys/net/ipv4/ip_local_port_range

なお，サーバの待ち受けポートの設定方法は，各OSのマニュアルを参照してください。

4　システム構成の検討（バッチアプリケーション実行基盤）

この章では，バッチアプリケーション実行基盤を構築する場合のシステム構成の検討について説明します。システムを設計する流れに沿って，標準的なシステム構成のパターンを示します。また，意識する必要があるコンポーネント，プロセスおよび処理の流れについて説明します。

J2EEアプリケーション実行基盤のシステム構成を検討する場合は，「3.　システム構成の検討（J2EEアプリケーション実行基盤）」を参照してください。

4.1　システム構成を検討するときに考慮すること

この節では，バッチアプリケーション実行基盤としてアプリケーションサーバを使用する場合に，システム構成の検討で考慮することについて説明します。

4.1.1　システムの目的と構成

バッチアプリケーション実行基盤は，Javaアプリケーションとして実装されたバッチアプリケーションを実行するための環境です。バッチアプリケーションは，JSP，ServletおよびEnterprise BeanなどのJ2EEアプリケーションを利用しないJavaアプリケーションとして実装します。なお，バッチアプリケーションから，J2EEサーバ上のEnterprise Beanを呼び出すことはできます。

バッチアプリケーションは，バッチサーバ上で動作します。バッチアプリケーションがリソースと接続する場合に使用するリソースアダプタも，バッチサーバ上で動作します。

バッチアプリケーションは，バッチ実行コマンドによって実行されます。バッチ実行コマンドは，ユーザが直接実行するほか，JP1/AJSのジョブとして自動実行できます。

バッチアプリケーションを実行するシステムの構成例を次の図に示します。この図では，アプリケーションサーバ上で，バッチアプリケーションごとに二つのバッチサーバが動作しています。また，バッチアプリケーションは，JP1/AJSを使用して実行しています。

図4‒1　バッチアプリケーションを実行するシステムの構成例

このほか，バッチアプリケーションからJ2EEサーバ上のEnterprise Beanに接続する場合は，オンライン処理を実行するバックシステムに接続することもできます。バックシステムについては，「3.1.1　システムの目的と構成」を参照してください。

4.1.2　システム構成の設計手順

システム構成は，次の流れで設計します。

図4‒2　システム構成を設計する流れ（バッチアプリケーション実行基盤の場合）

(1)　アプリケーションの起動方式を検討する

バッチアプリケーションの起動方式を検討します。次の2種類から選択します。

バッチサーバ上で起動する

バッチサーバ上でJavaアプリケーションを起動する方式です。常駐型のJavaVMプロセスであるバッチサーバを使用することで，JavaVMの起動に掛かるオーバーヘッドを削減できます。また，CTMを利用すると，バッチサーバ上で動作するバッチアプリケーションの実行をスケジューリングできます。

また，バッチサーバ上で起動する場合，リソースアダプタとしてDB Connectorが使用できます。

cjclstartapコマンドを使用して個別に起動する

javaコマンドと同じようにJavaアプリケーションを起動する方式です。この方式の場合，バッチアプリケーションを実行するたびに，JavaVMの起動が必要です。

起動方式としてバッチサーバ上で起動することを選択した場合は，次の検討項目に進みます。なお，cjclstartapコマンドを使用することを選択した場合は，以降の検討項目は該当しません。

(2)　トランザクションの使用方法を検討する

リソースと接続する場合は，トランザクションの使用方法を検討します。次の2種類から選択します。

DB Connectorを使用する

アプリケーションサーバが提供するリソースアダプタであるDB Connectorを使用する方法です。DB Connectorの機能として，コネクションプーリングやステートメントプーリングが使用できます。また，フルガーベージコレクションの発生を制御する機能も使用できます。なお，バッチサーバで管理できるトランザクションは，ローカルトランザクションです。

JDBCドライバを直接使用する

JDBCドライバが提供するAPIを使用して，トランザクション管理に必要な処理を実装する方法です。

DB Connectorを使用する場合のリソースアダプタとリソースの構成については，「3.3.2　リソースの種類とリソースアダプタ」を参照してください。ただし，バッチサーバの場合，接続できるリソースはデータベースだけです。

(3)　セキュリティの設定を確認する

バッチサーバは，SecurityManagerによるセキュリティ保護を無効にして起動します。

(4)　性能解析トレースファイルを出力するプロセスを配置する

性能解析トレースファイルを出力するためのプロセスであるPRFデーモン（パフォーマンストレーサ）の配置を確認します。PRFデーモンは，バッチサーバごとに配置します。

(5)　運用管理および運用監視方法を決定する

運用管理および運用監視を実行するためのプロセスであるManagement Serverの配置を確認します。バッチアプリケーション実行基盤では，バッチサーバと同じマシンに配置します（ホスト単位管理モデルを使用します）。

(6)　JP1との連携を検討する

バッチアプリケーションの実行をJP1/AJSのジョブとして自動投入する場合は，JP1との連携方法を検討します。

(7)　そのほかの機能の使用を検討する

使用する機能に応じて，次の構成を検討してください。

サーバ間連携をする構成

バッチアプリケーションからJ2EEサーバ上のEnterprise Beanを呼び出す場合に検討します。「3.5　サーバ間での連携を検討する」を参照してください。

クラスタソフトウェアを使用した障害時の系切り替えをする構成

バッチサーバを系切り替えの対象にする場合に検討します。

次の説明を参照してください。

「3.11.1　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）」

「3.11.4　アプリケーションサーバの実行系と待機系を相互スタンバイにする構成」

参照先の記述のうち，「J2EEサーバ」は「バッチサーバ」に読み替えてください。

4.1.3　バッチアプリケーションを実行するシステムで使用するTCP/UDPのポートについての注意事項

バッチアプリケーションを実行するシステムで使用するTCP/UDPのポートについて，プロセスごとに説明します。バッチアプリケーションを実行するシステムで使用するTCP/UDPのポートを次の表に示します。

表4‒1　バッチアプリケーションを実行するシステムのプロセスが使用するTCP/UDPのポート

項番※1

プロセス

説明

(1)

バッチサーバ

EJBコンテナのリクエスト受付ポート。

(2)

管理用通信ポート。

(3)

Webサーバ（リダイレクタ）からのリクエスト受付ポート。

(5)

インプロセスで起動するネーミングサービスのリクエスト受付ポート。

(7)

RMIレジストリのリクエスト受付ポート。

(9)

稼働情報取得時のリクエスト受付ポート。

(13)

スマートエージェント※2

スマートエージェントの通信用ポート環境変数。

UDPによる双方向通信に必要です。

(25)

CTMレギュレータ※2

CTMレギュレータがEJBクライアントからのリクエストを受け付けるポートの基底値。基底値＋プロセス数だけ使用します。

CTM使用時に必要です。

(26)

CTMデーモン※2

CTMデーモンがEJBクライアントからのリクエストを受け付けるポート。

CTM使用時に必要です。

(27)

CTMデーモンがほかのデーモンやJ2EEサーバなどと通信するポート。

CTM使用時に必要です。

(28)

CTMドメインマネジャ※2

CTMドメインマネジャがほかのCTMドメインマネジャと通信するポート。

CTM使用時に，TCPおよびUDP通信（ブロードキャスト）をするために必要です。

注　スマートエージェントを使用する指定をした場合，スマートエージェントと通信するために，この表で示した以外の複数のポートが使用されます。スマートエージェントの詳細については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) プログラマーズリファレンス」を参照してください。

注※1　「3.15　アプリケーションサーバのプロセスが使用するTCP/UDPのポート番号」の「表3-3　アプリケーションサーバが使用するTCP/UDPのポート番号」の項番と対応しています。

注※2　バッチアプリケーションのスケジューリング機能を使用する場合に，必要なプロセスです。

次の場合は，使用するポートが重複しないように設定してください。

一つのマシンでJ2EEサーバとバッチサーバを同時に使用する場合

一つのマシンで複数のバッチサーバを同時に使用する場合

各プロセスが使用するTCP/UDPのポートの詳細については，「3.15　アプリケーションサーバのプロセスが使用するTCP/UDPのポート番号」を参照してください。

注意事項

サーバの待ち受けポートの注意事項（UNIXの場合）

UNIXの場合，次の条件がすべて重なるときは，待ち受けをしていないTCPポートに対して，接続に成功してしまうことがあります。

待ち受けをしていないポートに対して接続試行を実行する

接続対象が自ホストであり，かつ一時ポート番号の範囲（OSが動的に割り当てるポートの範囲）である

この現象が発生した場合，想定したプロセスとの通信ができないで，タイムアウトなどが発生します。この現象を回避するためには，サーバの待ち受けポートに一時ポート番号の範囲以外の値を指定してください。一時ポート番号の範囲は，次のファイルで確認できます。

AIXの場合

最小値（32768）：no -o tcp_ephemeral_low

最大値（65535）：no -o tcp_ephemeral_high

Linuxの場合

/proc/sys/net/ipv4/ip_local_port_range

なお，サーバの待ち受けポートの設定方法は，各OSのマニュアルを参照してください。

4.2　バッチサーバを使用する場合のシステム構成

この節では，バッチサーバを使用する場合のシステム構成について説明します。バッチサーバを使用するシステムは，バッチアプリケーションのスケジューリング機能を使用するかどうかによって，構成が異なります。

4.2.1　バッチアプリケーションのスケジューリング機能を使用しないシステムのシステム構成

バッチサーバを使用する場合に，バッチアプリケーションのスケジューリング機能を使用しないときのシステムの構成について説明します。

(1)　システム構成の特徴

バッチサーバを使用する構成の一つで，CTMを使用しないシステム構成です。この場合，アプリケーションサーバにはバッチサーバを配置します。バッチサーバは，Smart Composer機能のWebシステム（j2ee-tier）として構築，運用します。バッチアプリケーションの実行には，バッチ実行コマンドを使用します。バッチ実行コマンドは，JP1/AJSにジョブとして定義して実行できます。

バッチサーバを配置するシステム構成の例を次の図に示します。この例では，バッチアプリケーションはJP1/AJSから実行します。また，バッチアプリケーションからリソースアダプタを使用してHiRDBにアクセスします。

図4‒3　バッチサーバを配置するシステム構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

リソースとの接続にDB Connectorが使用できます。また，Batch Job Execution ServerまたはJP1/Advanced Shellとの連携もできます。

処理の流れ

バッチアプリケーションの実行は，JP1/AJSのジョブとして定義しておきます。JP1/AJSのジョブとして実行されたバッチアプリケーションは，バッチサーバ上のDB Connectorを経由してHiRDBにアクセスします。

(2)　それぞれのマシンに必要なプロセスとソフトウェア

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。なお，開発環境の場合は，Developerをインストールする必要があります。

さらに，JP1/AJSによってバッチアプリケーションを実行する場合や，Batch Job Execution ServerまたはJP1/Advanced Shellと連携したジョブの制御をする場合は，次の製品もインストールする必要があります。

JP1/AJSと連携する場合に必要な製品

JP1/Base

JP1/AJS - Agent

JP1/AJS - Manager

JP1/AJS - View

Batch Job Execution Serverと連携する場合に必要な製品

Batch Job Execution Server

JP1/AJSと連携する場合に必要な製品

JP1/Advanced Shellと連携する場合に必要な製品

JP1/Advanced Shell

JP1/AJSと連携する場合に必要な製品（JP1/AJS経由でJP1/Advanced Shellを実行する場合）

起動するプロセスは次のとおりです。

バッチサーバ

PRFデーモン

Management Server

運用管理エージェント

JP1/BaseとJP1/AJSのプロセス（JP1/AJSと連携する場合）

Batch Job Execution Serverのプロセス（Batch Job Execution Serverと連携する場合）

JP1/Advanced Shellのプロセス（JP1/Advanced Shellと連携する場合）

また，データベースと接続する場合は，使用するデータベースと接続するためのソフトウェアが必要です。データベースに接続するために必要な製品については，「3.6.1　ローカルトランザクションを使用する場合の構成」を参照してください。ただし，バッチサーバで使用できるリソースは，次に示すデータベースだけです。

HiRDB

Oracle

SQL Server

XDM/RD E2

(b)　管理サーバマシンおよび管理クライアントマシン

管理サーバマシンおよび管理クライアントマシンは，JP1/AJSと連携する場合に必要です。インストールする製品および起動するプロセスについては，マニュアル「JP1/Automatic Job Management System 設計ガイド」を参照してください。

(c)　データベースサーバマシン

データベースサーバマシンに必要な製品については，「3.6.1　ローカルトランザクションを使用する場合の構成」のリソースマネジャが動作するマシンの説明を参照してください。ただし，バッチサーバで使用できるリソースは，次に示すデータベースだけです。

HiRDB

Oracle

SQL Server

XDM/RD E2

4.2.2　バッチアプリケーションのスケジューリング機能を使用するシステムのシステム構成

バッチサーバを使用する場合に，バッチアプリケーションのスケジューリング機能を使用するときのシステムの構成について説明します。

(1)　システム構成の特徴

バッチサーバを使用する構成の一つで，CTMを使用するシステム構成です。この場合，アプリケーションサーバにはバッチサーバとCTMを配置します。バッチサーバとCTMは，Smart Composer機能のWebシステム（ctm-tier）として構築，運用します。バッチアプリケーションの実行には，バッチ実行コマンドを使用します。JP1/AJSのジョブ，または直接コマンドから実行されたバッチアプリケーションの実行は，CTMによってスケジューリングされ，バッチサーバに振り分けられます。

CTMを使用するシステム構成の例を次の図に示します。この例では，バッチサーバを2台配置し，CTMを使用してバッチアプリケーションの実行リクエストをスケジューリングします。バッチ実行コマンドはJP1/AJSのジョブから実行します。

図4‒4　CTMを使用するシステム構成の例

これ以外の凡例については，「3.2　システム構成の説明について」を参照してください。

特徴

CTMによってバッチアプリケーションの実行リクエストをスケジューリングすることで，複数のバッチ実行コマンドを同時に実行できます。また，バッチ実行コマンドでバッチサーバを指定する必要がありません。このため，バッチ実行コマンドをJP1/AJSのジョブで定義している場合でも，ジョブの定義を変更することなく，バッチサーバの同時実行数を変更できます。

なお，このシステム構成でも，Batch Job Execution ServerまたはJP1/Advanced Shellと連携できます。

処理の流れ

JP1/AJSのジョブ，または直接バッチ実行コマンドから実行されたバッチアプリケーションは，CTMのスケジュールキューにバッチアプリケーションの実行リクエストとして登録されます。スケジュールキュー内のバッチアプリケーションの実行リクエストは，CTMによって適切なバッチサーバに振り分けられます。なお，振り分け先のバッチサーバがない場合，バッチアプリケーションの実行リクエストはスケジュールキュー内に滞留（待機）します。

(2)　それぞれのマシンに必要なプロセスとソフトウェア

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Serverをインストールする必要があります。なお，開発環境の場合は，Developerをインストールする必要があります。

さらに，JP1/AJSによってバッチアプリケーションを実行する場合や，Batch Job Execution ServerまたはJP1/Advanced Shellと連携したジョブの制御をする場合は，次の製品もインストールする必要があります。

JP1/AJSと連携する場合に必要な製品

JP1/Base

JP1/AJS - Agent

JP1/AJS - Manager

JP1/AJS - View

Batch Job Execution Serverと連携する場合に必要な製品

Batch Job Execution Server

JP1/AJSと連携する場合に必要な製品

JP1/Advanced Shellと連携する場合に必要な製品

JP1/Advanced Shell

JP1/AJSと連携する場合に必要な製品（JP1/AJS経由でJP1/Advanced Shellを実行する場合）

起動するプロセスは次のとおりです。

バッチサーバ

PRFデーモン

グローバルCORBAネーミングサービス

CTMのプロセス群（CTMデーモンおよびCTMレギュレータ）

CTMドメインマネジャ

スマートエージェント

Management Server

運用管理エージェント

JP1/BaseとJP1/AJSのプロセス（JP1/AJSと連携する場合）

Batch Job Execution Serverのプロセス（Batch Job Execution Serverと連携する場合）

JP1/Advanced Shellのプロセス（JP1/Advanced Shellと連携する場合）

また，データベースと接続する場合は，使用するデータベースと接続するためのソフトウェアが必要です。データベースに接続するために必要な製品については，「3.6.1　ローカルトランザクションを使用する場合の構成」を参照してください。ただし，バッチサーバで使用できるリソースは，次に示すデータベースだけです。

HiRDB

Oracle

SQL Server

XDM/RD E2

(b)　管理サーバマシンおよび管理クライアントマシン

管理サーバマシンおよび管理クライアントマシンは，JP1/AJSと連携する場合に必要です。インストールする製品および起動するプロセスについては，マニュアル「JP1/Automatic Job Management System 設計ガイド」を参照してください。

(c)　データベースサーバマシン

データベースサーバマシンに必要な製品については，「3.6.1　ローカルトランザクションを使用する場合の構成」のリソースマネジャが動作するマシンの説明を参照してください。ただし，バッチサーバで使用できるリソースは，次に示すデータベースだけです。

HiRDB

Oracle

SQL Server

XDM/RD E2

5　使用するリソースの見積もり（J2EEアプリケーション実行基盤）

この章では，J2EEアプリケーションを実行するシステムで使用するリソース，および仮想メモリ使用量の見積もり方法について説明します。システムを動作させるために必要なディスクおよびメモリの容量を算出するときの参考にしてください。

ファイルディスクリプタ数を設定する場合は，同一のホスト上で動作するプロセスの最大数を指定する必要があります。

バッチアプリケーション実行基盤の使用リソースおよび仮想メモリ所要量の見積もりについては，「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」を参照してください。

5.1　システム構成ごとに使用するリソース

システムが動作するためには，OSやデータベースなどのホスティング環境の設定が必要な場合があります。システムが必要とするリソースは，システムの構成ごとに異なるため，ここではシステム構成ごとに使用するリソースと，リソースの所要量の見積もりについて説明します。システム構成ごとに使用するリソースと，リソースの見積もりの参照先を次の表に示します。

表5‒1　システム構成ごとに使用するリソースと見積もりの参照先

システム構成ごとに使用するリソース

参照先

WebサーバとJ2EEサーバを同じマシンに配置する場合の使用リソース

5.1.1

WebサーバとJ2EEサーバを別のマシンに配置する場合の使用リソース

5.1.2

データベースの使用リソース

5.1.3

運用管理サーバの使用リソース

5.1.4

CTMを使用する場合の使用リソース

5.1.5

また，プロセスごとに使用するリソースの見積もりについては，「5.2　プロセスごとに使用するリソース」を参照してください。

プロセスごとに使用するメモリの見積もりについては，「5.3　プロセスごとに使用するメモリの見積もり」を参照してください。ディスク占有量については，アプリケーションサーバのリリースノートを参照してください。

ポイント

Windowsシステムの場合は，この節で説明する内容のうち，「5.1.3　データベースの使用リソース」だけを参照してください。

システムで利用できるプロセス数，共用メモリ，ファイルディスクリプタ数，およびWindowsシステムやプロセスで利用できるスレッド数に，特に制限はありません。

5.1.1　WebサーバとJ2EEサーバを同じマシンに配置する場合の使用リソース

WebサーバとJ2EEサーバを同じマシンに配置する場合の使用リソースの見積もりについて，OSごとに説明します。

なお，使用リソースの見積もりの各表にある，「オプション設定ファイル例」については，使用しているOSのバージョン，およびカーネルのバージョンごとに異なります。使用しているOSのマニュアルを参照して，表中の見積もり式を基に見積もった値を設定してください。使用しているOSで該当するカーネルパラメタが設定できない場合には，設定は不要です。

(1)　AIXの場合

AIXの場合の，使用リソースの見積もりについて，次の表に示します。

表5‒2　使用リソースの見積もり（AIXの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

−

PrfTraceBufferSize※1×1,024＋18,496＋リクエスト最大同時処理数※2×14×1,024

−

プロセス数

−

リクエスト最大同時処理数※2×2＋5

−

スレッド数

−

リクエスト最大同時処理数※2×2＋41＋J2EEサーバのスレッド数※3

−

ファイルディスクリプタ数

nofiles

J2EEサーバのファイルディスクリプタ数※3＋76＋リクエスト最大同時処理数※2×4

/etc/security/limits

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

Webサーバで同時に処理できるリクエストの最大数を指します。

注※3

J2EEサーバのスレッド数とファイルディスクリプタ数については，「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照して算出してください。

(2)　Linuxの場合

Linuxの場合の，使用リソースの見積もりについて，次の表に示します。

表5‒3　使用リソースの見積もり（Linuxの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

SHMMAX

PrfTraceBufferSize※1×1,024＋18,496＋リクエスト最大同時処理数※2×14×1,024

/proc/sys/kernel/shmmax

プロセス数

threads-max※3

リクエスト最大同時処理数※2×2＋5

/proc/sys/kernel/threads-max

スレッド数

threads-max※3

リクエスト最大同時処理数※2×2＋41＋J2EEサーバのスレッド数※4

−

ファイルディスクリプタ数

fs.file-max

J2EEサーバのファイルディスクリプタ数※4＋76＋リクエスト最大同時処理数※2×4

/proc/sys/fs/file-max

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

Webサーバで同時に処理できるリクエストの最大数を指します。

注※3

threads-maxパラメタには，プロセス数とスレッド数の合計を指定してください。

注※4

J2EEサーバのスレッド数とファイルディスクリプタ数については，「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照して算出してください。

5.1.2　WebサーバとJ2EEサーバを別のマシンに配置する場合の使用リソース

WebサーバとJ2EEサーバを別のマシンに配置する場合の使用リソースの見積もりについて，OSごとに説明します。WebサーバとJ2EEサーバを別マシンに配置する場合は，Webサーバマシンとアプリケーションサーバマシンのそれぞれで使用するリソースを見積もります。

なお，使用リソースの見積もりの各表にある，「オプション設定ファイル例」については，使用しているOSのバージョン，およびカーネルのバージョンごとに異なります。使用しているOSのマニュアルを参照して，表中の見積もり式を基に見積もった値を設定してください。使用しているOSで該当するカーネルパラメタが設定できない場合には，設定は不要です。

(1)　AIXの場合

AIXの場合の，Webサーバマシンおよびアプリケーションサーバマシンの使用リソースの見積もりについて説明します。

(a)　Webサーバマシンの使用リソースの見積もり

Webサーバマシンの使用リソースの見積もりについて，次の表に示します。

表5‒4　Webサーバマシンの使用リソースの見積もり（AIXの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

−

PrfTraceBufferSize※1×1,024＋18,496＋リクエスト最大同時処理数※2×14×1,024

−

プロセス数

−

リクエスト最大同時処理数※2×2＋4

−

スレッド数

−

リクエスト最大同時処理数※2×2＋35

−

ファイルディスクリプタ数

nofiles

リクエスト最大同時処理数※2×4＋75

/etc/security/limits

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

Webサーバで同時に処理できるリクエストの最大数を指します。

(b)　アプリケーションサーバマシンの使用リソースの見積もり

アプリケーションサーバマシンの使用リソースの見積もりについて，次の表に示します。

表5‒5　アプリケーションサーバマシンの使用リソースの見積もり（AIXの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

−

PrfTraceBufferSize※1×1,024＋18,496

−

プロセス数

−

4

−

スレッド数

−

J2EEサーバのスレッド数※2＋34

−

ファイルディスクリプタ数

nofiles

J2EEサーバのファイルディスクリプタ数※2＋43

/etc/security/limits

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

J2EEサーバのスレッド数とファイルディスクリプタ数については，「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照して算出してください。

(2)　Linuxの場合

Linuxの場合の，Webサーバマシンおよびアプリケーションサーバマシンの使用リソースの見積もりについて説明します。

(a)　Webサーバマシンの使用リソースの見積もり

Webサーバマシンの使用リソースの見積もりについて，次の表に示します。

表5‒6　Webサーバマシンの使用リソースの見積もり（Linuxの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

SHMMAX

PrfTraceBufferSize※1×1,024＋18,496＋リクエスト最大同時処理数※2×14×1,024

/proc/sys/kernel/shmmax

プロセス数

threads-max※3

リクエスト最大同時処理数※2×2＋4

/proc/sys/kernel/threads-max

スレッド数

threads-max※3

リクエスト最大同時処理数※2×2＋35

−

ファイルディスクリプタ数

fs.file-max

リクエスト最大同時処理数※2×4＋75

/proc/sys/fs/file-max

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

Webサーバで同時に処理できるリクエストの最大数を指します。

注※3

threads-maxパラメタには，プロセス数とスレッド数の合計を指定してください。

(b)　アプリケーションサーバマシンの使用リソースの見積もり

アプリケーションサーバマシンの使用リソースの見積もりについて，次の表に示します。

表5‒7　アプリケーションサーバマシンの使用リソースの見積もり（Linuxの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

SHMMAX

PrfTraceBufferSize※1×1,024＋18,496

/proc/sys/kernel/shmmax

プロセス数

threads-max※2

4

/proc/sys/kernel/threads-max

スレッド数

threads-max※2

J2EEサーバのスレッド数※3＋34

−

ファイルディスクリプタ数

fs.file-max

J2EEサーバのファイルディスクリプタ数※3＋43

/proc/sys/fs/file-max

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

threads-maxパラメタには，プロセス数とスレッド数の合計を指定してください。

注※3

J2EEサーバのスレッド数とファイルディスクリプタ数については，「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照して算出してください。

5.1.3　データベースの使用リソース

DBMSの使用リソースの見積もりについて説明します。

プロセスごとに使用するメモリの見積もりについては，「5.3　プロセスごとに使用するメモリの見積もり」を参照してください。また，ディスク占有量については，Application ServerまたはDeveloperのリリースノートを参照してください。

DBMSの使用リソースの見積もりについて，次の表に示します。

表5‒8　DBMSの使用リソースの見積もり

DBMS

使用リソース

所要量

HiRDB

最大同時接続数(pd_max_users)

Oracle

最大同時接続数(SESSIONS)

注※1

nは，システム内のJ2EEサーバにデプロイするリソースアダプタの総和です。

注※2

Connector属性ファイルのMaxPoolSizeパラメタの値を指定します。

注※3

次に示す条件に当てはまる場合に，×2を行ってください。

トランザクションサポートレベルにXATransactionを使用する。

アプリケーションサーバが管理するトランザクション内でコネクション※を使ってデータベースにアクセスする。

2.のトランザクションが決着する前に，トランザクション外でコネクション※を使ってデータベースにアクセスする。

注※　このコネクションは1.のDB Connectorから取得したコネクションで，かつ同一コネクションです。

注※4

トランザクションサポートレベルにXATransactionを指定しているリソースアダプタの場合に，＋1を行ってください。

注※5

＋αの最大値は，使用するDB Connectorのコネクションプールの最大値の合計値になります。

この＋αの値は，一時的にコネクションプールの最大値をオーバーするおそれのあるコネクションを指します。詳細を次に示します。

コネクションの障害検知機能を使用する場合

コネクションの障害検知機能を使用する場合，コネクションプールから取り除いた未使用のコネクションは，コネクションプール内のコネクション数としてカウントされません。そのため，コネクションプール内のコネクションとコネクションプールから取り除いた未使用のコネクションの総和が，コネクションプールのコネクション数の最大値を一時的に超えることがあります。

cjclearpoolコマンドを使用する場合

通常モードの場合，コネクションプールから取り除いた使用中のコネクションは，コネクション数としてカウントされません。そのため，コネクションプール内のコネクションとコネクションプールから取り除いた使用中のコネクションの総和がコネクションプールの最大値を超えることがあります。

5.1.4　運用管理サーバの使用リソース

運用管理サーバの使用リソースの見積もりについて，OSごとに説明します。

なお，使用リソースの見積もりの各表にある，「オプション設定ファイル例」については，使用しているOSのバージョン，およびカーネルのバージョンごとに異なります。使用しているOSのマニュアルを参照して，表中の見積もり式を基に見積もった値を設定してください。使用しているOSで該当するカーネルパラメタが設定できない場合には，設定は不要です。

(1)　AIXの場合

運用管理サーバの使用リソースの見積もりについて，次の表に示します。

表5‒9　運用管理サーバの使用リソースの見積もり（AIXの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

プロセス数

−

5＋A※

−

スレッド数

−

101＋論理サーバ数×4＋A※

−

ファイルディスクリプタ数

nofiles

218＋論理サーバ数×3

/etc/security/limits

（凡例）−：該当しません。

注※

Aは同時に実行するManagementアクション数です。Managementイベント発生時，Managementアクションを実行する場合だけ，次の値を加算します。

各J2EEサーバのManagementイベント発行用プロパティファイルのmanager.mevent.send.maxキーの指定値の合計

(2)　Linuxの場合

運用管理サーバの使用リソースの見積もりについて，次の表に示します。

表5‒10　運用管理サーバの使用リソースの見積もり（Linuxの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

プロセス数

threads-max※1

5＋A※2

/proc/sys/kernel/threads-max

スレッド数

threads-max※1

101＋論理サーバ数×4＋A※2

−

ファイルディスクリプタ数

fs.files-max

218＋論理サーバ数×3

/proc/sys/fs/file-max

（凡例）−：該当しません。

注※1

threads-maxパラメタには，プロセス数とスレッド数の合計を指定してください。

注※2

Aは同時に実行するManagementアクション数です。Managementイベント発生時，Managementアクションを実行する場合だけ，次の値を加算します。

各J2EEサーバのManagementイベント発行用プロパティファイルのmanager.mevent.send.maxキーの指定値の合計

5.1.5　CTMを使用する場合の使用リソース

CTMを使用する場合の，使用リソースの見積もりについて，OSごとに説明します。

なお，使用リソースの見積もりの各表にある，「オプション設定ファイル例」については，使用しているOSのバージョン，およびカーネルのバージョンごとに異なります。使用しているOSのマニュアルを参照して，表中の見積もり式を基に見積もった値を設定してください。使用しているOSで該当するカーネルパラメタが設定できない場合には，設定は不要です。

(1)　AIXの場合

CTMを使用する場合の，使用リソースの見積もりについて次の表に示します。

表5‒11　CTM使用時の使用リソースの見積もり（AIXの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

−

PrfTraceBufferSize※1×1,024＋18,496＋CTMドメインマネジャの共用メモリ※2＋CTMデーモンの共用メモリ※2

−

プロセス数

−

7＋J2EEサーバ数※3

−

スレッド数

−

72＋(J2EEサーバのスレッド数※4＋7)×J2EEサーバ数※3＋CTMデーモンで必要とするスレッド数※5

−

ファイルディスクリプタ数

nofiles

88＋(J2EEサーバのファイルディスクリプタ数※4＋6)×J2EEサーバ数※3＋CTMデーモンで必要とするファイルディスクリプタ数※5

/etc/security/limits

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

値については，「5.1.5(1)(a)　共用メモリ用ファイルサイズの計算式」を参照して算出してください。

注※3

簡易構築定義ファイルの<j2ee-server-count>タグの指定値を指します。

注※4

J2EEサーバのスレッド数とファイルディスクリプタ数については，「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照して算出してください。

注※5

CTMデーモンで必要とするスレッド数とファイルディスクリプタ数については，「5.1.5(1)(b)　CTMデーモンで必要とするスレッド数とファイルディスクリプタ数の計算式」を参照して算出してください。

(a)　共用メモリ用ファイルサイズの計算式

共用メモリ用ファイルサイズを算出するには，CTMドメインマネジャの共用メモリおよびCTMデーモンの共用メモリを算出する必要があります。それぞれの計算式について次に示します。

なお，計算式中の可変値には，次の値を使用してください。「ctm.」で始まるパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.14　論理CTMで指定できるパラメタ」を参照してください。

計算式に使用する値

-CTMMaxCTM：64

-CTMQueueCount：ctm.QueueCount

-CTMClientConnectCount：256

-CTMServerConnectCount：ctm.ServerConnectCount

-CTMEntryCount：-CTMClientConnectCount＋-CTMServerConnectCount

-CTMServerCacheSize：ctm.ServerCacheSize

-CTMQueueRegistCount：ctm.QueueRegistCount

-CTMDispatchParallelCount：ctm.DispatchParallelCount

CTMドメインマネジャの共用メモリ用ファイルサイズの計算式

CTMドメインマネジャの共用メモリ用ファイルサイズの計算式を次に示します。

共用メモリ用ファイルサイズ（単位：バイト） =

1,018,320＋（2,362×-CTMMaxCTM指定値）

CTMデーモンの共用メモリ用ファイルサイズの計算式

CTMデーモンの場合は，CTMデーモン単位で固定長の共用メモリ用ファイルと可変長の共用メモリ用ファイルを確保する必要があります。それぞれの計算式を次に示します。

固定長の共用メモリ用ファイルサイズ（単位：バイト） =

551,840＋（1,208×-CTMQueueCount指定値）

可変長の共用メモリ用ファイルサイズ（単位：バイト） =

1,027,008

＋（928×-CTMClientConnectCount指定値）

＋（256×-CTMServerConnectCount指定値）

＋（512×-CTMEntryCount指定値）

＋（1,024×-CTMServerCacheSize指定値）

＋（512×-CTMQueueCount指定値）

＋（544×-CTMQueueCount指定値×-CTMQueueRegistCount指定値）

＋（512×-CTMDispatchParallelCount指定値）

(b)　CTMデーモンで必要とするスレッド数とファイルディスクリプタ数の計算式

スレッド数およびファイルディスクリプタ数を算出するには，CTMデーモンで必要とするスレッド数とファイルディスクリプタ数を算出する必要があります。それぞれの計算式について次に示します。

CTMデーモンで必要とするスレッド数の計算式

最大値 =

（A×4＋B×3＋C×2＋D×E＋F＋G＋32） / 0.8

（凡例）

A：-CTMMaxCTM値（ctmdが属するctmdmdで指定された値）

B：-CTMClientConnectCount値

C：-CTMServerConnectCount値

D：-CTMQueueCount値

E：-CTMQueueRegistCount値

F：-CTMDispatchParallelCount値

G：Createを発行するEJBクライアントの総数

CTMデーモンで必要とするファイルディスクリプタ数の計算式

最大値 =

（A×2＋B×4＋C×2＋D×E＋F×EJBのインタフェース数＋G＋100） / 0.8

（凡例）

A：-CTMMaxCTM値（ctmdが属するctmdmdで指定された値）

B：-CTMClientConnectCount値

C：-CTMServerConnectCount値

D：-CTMQueueCount値

E：-CTMQueueRegistCount値

F：-CTMDispatchParallelCount値

G：Createを発行するEJBクライアントの総数

(2)　Linuxの場合

CTMを使用する場合の，使用リソースの見積もりについて，次の表に示します。

表5‒12　CTM使用時の使用リソースの見積もり（Linuxの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

SHMMAX

PrfTraceBufferSize※1×1,024＋18,496＋CTMドメインマネジャの共用メモリ※2＋CTMデーモンの共用メモリ※2

/proc/sys/kernel/shmmax

プロセス数

threads-max※6

pid_max※6

7＋J2EEサーバ数※3

/proc/sys/kernel/threads-max

/proc/sys/kernel/pid_max

スレッド数

threads-max※6

pid_max※6

72＋(J2EEサーバのスレッド数※4＋7)×J2EEサーバ数※3＋CTMデーモンで必要とするスレッド数※5＋CTMレギュレータで必要とするスレッド数※7

/proc/sys/kernel/threads-max

/proc/sys/kernel/pid_max

ファイルディスクリプタ数

fs.file-max

88＋(J2EEサーバのファイルディスクリプタ数※4＋6)×J2EEサーバ数※3＋CTMデーモンで必要とするファイルディスクリプタ数※5

/proc/sys/fs/file-max

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

値については，「5.1.5(1)(a)　共用メモリ用ファイルサイズの計算式」を参照して算出してください。

注※3

簡易構築定義ファイルの<j2ee-server-count>タグの指定値を指します。

注※4

J2EEサーバのスレッド数とファイルディスクリプタ数については，「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照して算出してください。

注※5

CTMデーモンで必要とするスレッド数とファイルディスクリプタ数については，「5.1.5(1)(b)　CTMデーモンで必要とするスレッド数とファイルディスクリプタ数の計算式」を参照して算出してください。

注※6

threads-maxパラメタおよびpid_maxパラメタには，プロセス数とスレッド数の合計以上を指定してください。

注※7

CTMレギュレータで必要とするスレッド数については，「12+(EJBクライアントの総数×2)/0.8)」を使用して算出してください。

EJBクライアントの総数の最大値はctmregltdの-CTMClientConnectCount値の合計になります。

5.2　プロセスごとに使用するリソース

この節では，アプリケーションサーバの各プロセスで使用するリソースの所要量の見積もりについて説明します。

運用管理サーバの使用するリソースについては，「5.1.4　運用管理サーバの使用リソース」を参照してください。

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

ここでは，J2EEサーバプロセスのスレッド数とファイルディスクリプタ数の見積もりについて説明します。

(1)　スレッド数

スレッド数の計算式を次に示します。(a)と(b)の合計が，J2EEサーバが使用するスレッド数です。

(a)　基本のスレッド数

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

J2EEサーバの場合

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

バッチサーバの場合

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

（凡例）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ManagedExecutorServiceの最大スレッド数

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

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

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

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

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

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

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

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

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

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

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

設定項目

設定する値

説明

A

0

Entity Beanを使用していないため，0を設定します。

B

0

Message-Driven Beanを使用していないため，0を設定します。

C

1

リモート呼び出しは行われていません。また，EJBがWebアプリケーションからのローカル呼び出しの場合，EJB実行でのスレッドは生成されません。

D

4+1

Cと同様にEJBクライアントに関する値は0になります。

E

48+24

−

F

72

1リクエストが1トランザクションとした場合，最大同時リクエスト数であるMaxClientの値を設定します。

G

(48+24)×2

−

H

2

−

I

0

グローバルトランザクションは使用していないため，0を設定します。

J

2

−

K

0

展開ディレクトリ形式ではないため，0を設定します。

L

0

TP1インバウンドアダプタを使用していないため，0を設定します。

M

0

非同期Session Beanを使用していないため，0を設定します。

N

0

非同期Session Beanを使用していないため，0を設定します。

O

0

専用スレッドによる応答電文受信を設定していないため，0を設定します。

P

0

コネクションのクローズの抑止を設定していないため，0を設定します。

Q

100

−

R

0

Java Batchを使用していないため，0を設定します。

S

0

Concurrency Utilities for Java EEを使用していないため，0を設定します。

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

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

最大スレッド数 = A＋B＋C

（凡例）

A：G1GCで使用するスレッド数（a＋b＋2）※

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

C：ZGCで使用するスレッド数（a＋b＋5）※

注※

凡例は次のとおりです。

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

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

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

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

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

(2)　ファイルディスクリプタ数

ファイルディスクリプタ数の計算式を次に示します。

J2EEサーバの場合

最大ファイルディスクリプタ数 = （153＋A＋B×3＋C＋D＋E＋F×2＋G＋H＋I＋J＋K） / 0.8

（凡例）

A：データベースコネクションの数

B：EJBクライアントのプロセス数

C：J2EEサーバに接続するコネクション数の総和

D：次の式で算出したTP1インバウンドアダプタが使用するファイルディスクリプタ数（TP1インバウンド連携機能を使用する場合だけ加算する。なお，先頭で加算している固定値は，TP1インバウンド連携機能の内部のファイルディスクリプタ数）

8＋TP1インバウンドアダプタのプロパティmax_connectionsに指定した値

＋TP1インバウンドアダプタのプロパティtrn_max_connectionsに指定した値

＋各MDB（サービス）のMessage-driven Bean属性ファイルの<pooled-instance><maximum>に指定した値の総和×2

＋TP1インバウンドアダプタのプロパティrpc_max_thread_countに指定したスレッド数×2

＋TP1インバウンドアダプタのプロパティtrn_max_thread_countに指定したスレッド数×2

E：J2EEアプリケーションに含むJARファイルの数

F：リソースアダプタ数

G：usrconf.cfgのadd.class.pathキーに指定したJARファイルの数

H：WebアプリケーションのWEB-INF/libに含むJARファイルの数

I：NIO HTTPサーバの最大スレッド数

J：Java Batchの最大スレッド数

K：Concurrency Utilities for Java EEの最大スレッド数

(3)　CORBAネーミングサービス（インプロセス起動時）のスレッド数の見積もり

CORBAネーミングサービスをJ2EEサーバ起動時にインプロセスで起動させる場合に，J2EEサーバ上で生成されるCORBAネーミングサービスのスレッド数の見積もりについて説明します。

インプロセスで起動する場合のCORBAネーミングサービスのスレッド数は，次のように見積もります。

合計スレッド数 = 初期化時に生成されるスレッド数＋ワーカスレッド数

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

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

(b)　ワーカスレッド数

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.2　運用管理エージェントが使用するリソースの見積もり

運用管理エージェントが使用するリソースの見積もりについてOSごとに説明します。

(1)　Windowsの場合

Windowsを使用する場合のスレッド数の計算式を次に示します。

スレッド数の計算式

使用スレッド数 = 30＋7×論理サーバの数※

注※　論理CTMは論理サーバの数を2で計算してください。

（凡例）

30：運用管理エージェント本体が使用するスレッド数

7：論理サーバ一つ当たりの運用管理エージェントが使用するスレッド数

論理サーバのステータスが稼働になったあとのスレッド数の計算式を次に示します。

平時のスレッド数の計算式

使用スレッド数 = 30＋5×論理サーバの数※

注※　論理CTMは論理サーバの数を2で計算してください。

（凡例）

30：運用管理エージェント本体が使用するスレッド数

5：論理サーバ一つ当たりの運用管理エージェントが使用するスレッド数

(2)　UNIXの場合

UNIXを使用する場合のスレッド数とファイルディスクリプタ数の計算式について説明します。

(a)　スレッド数

スレッド数の計算式を次に示します。

スレッド数の計算式

使用スレッド数 = 30＋5×論理サーバの数※

注※　論理CTMは論理サーバの数を2で計算してください。

（凡例）

30：運用管理エージェント本体が使用するスレッド数

5：論理サーバ一つ当たりの運用管理エージェントが使用するスレッド数

論理サーバのステータスが稼働になったあとのスレッド数の計算式を次に示します。

平時のスレッド数の計算式

使用スレッド数 = 30＋5×論理サーバの数※

注※　論理CTMは論理サーバの数を2で計算してください。

（凡例）

30：運用管理エージェント本体が使用するスレッド数

5：論理サーバ一つ当たりの運用管理エージェントが使用するスレッド数

(b)　ファイルディスクリプタ数

ファイルディスクリプタ数の計算式を次に示します。

ファイルディスクリプタ数の計算式

使用ファイルディスクリプタ数 = 20＋論理サーバを構成するプロセスの数×6

（凡例）

20：運用管理エージェント本体が使用するファイルディスクリプタ数

6：論理サーバを構成する1プロセス当たりで運用管理エージェントが使用するファイルディスクリプタ数

論理サーバのステータスが稼働になったあとのファイルディスクリプタ数の計算式を次に示します。

平時のファイルディスクリプタ数の計算式

使用ファイルディスクリプタ数 = 20＋論理サーバを構成するプロセスの数×3

（凡例）

20：運用管理エージェント本体が使用するファイルディスクリプタ数

3：論理サーバを構成する1プロセス当たりで運用管理エージェントが使用するファイルディスクリプタ数

5.2.3　パフォーマンストレーサが使用するリソースの見積もり

パフォーマンストレーサが使用するリソースの見積もりについて，OSごとに説明します。

(1)　Windowsの場合

Windowsを使用する場合の，パフォーマンストレーサが使用するリソースの見積もりについて説明します。

(a)　共用メモリ用ファイルサイズ

パフォーマンストレーサが使用する共用メモリ用ファイルサイズ（単位：バイト）は，PRFデーモンごとに算出します。計算式を次に示します。

PRFデーモンごとの共用メモリの計算式

共用メモリ用ファイルサイズ = -PrfTraceBufferSize指定値×1,024＋18,496

(b)　%PRFSPOOL%のディスク占有量

%PRFSPOOL%のディスク占有量の計算式を次に示します。

%PRFSPOOL%のディスク占有量の計算式

ディスク占有量 = 2.0MB

＋｛（-PrfTraceBufferSize指定値＋20KB）×5

＋-PrfTraceFileSize指定値×-PrfTraceCount指定値×r｝×n

＋224KB×(256＋m)

＋224KB×（64＋p）

（凡例）

n：PRFデーモンの数

m：起動中のパフォーマンストレース出力プロセス数と正常終了しなかったパフォーマンストレース出力プロセス数

パフォーマンストレーサでは，パフォーマンストレース出力プロセスごとに，保守情報として内部トレースをファイルに出力します。このファイルはプロセス起動時に作成されますが，プロセスが正常終了しない場合はファイルが残ります。ファイルの削除処理はPRFデーモン起動時，およびPRFデーモン起動後24時間ごとに実施しますが，256ファイルは削除されないで残ります。このため，最大ファイル数は「256＋24時間のうちに実行するパフォーマンストレース出力プロセス数」になります。

p：起動中の性能解析トレースで使用するコマンド，デーモンのプロセス数

パフォーマンストレーサでは，性能解析トレースで使用するコマンド，およびデーモンごとに，保守情報として内部トレースをファイルに出力します。このファイルはプロセス起動時に作成されます。PRFデーモン起動時，およびPRFデーモン起動後24時間ごとにファイル削除処理を実施しますが，64ファイルは削除されないで残ります。このため，最大ファイル数は「64＋24時間のうちに実行する性能解析トレースで使用するコマンド，およびデーモンのプロセス数」になります。

r：バックアップ係数

PRFトレースのバックアップ分を算出する値です。cprfstartコマンドの起動オプションに-PrfNoBackUp 0を指定する場合2, それ以外の場合1になります。

上記のディスク容量は目安です。このため，十分な余裕を持って，%PRFSPOOL%を作成してください。

(2)　AIXの場合

AIXを使用する場合，パフォーマンストレーサを使用するために，次の値を考慮してカーネルパラメタを設定する必要があります。正しく設定できていない場合には，パフォーマンストレーサのプロセスが起動できなかったり，動作中にリソース不足で異常終了になったりするおそれがあります。なお，カーネルパラメタの設定については，使用しているOSのマニュアルを参照してください。

(a)　共用メモリ用ファイルサイズ

パフォーマンストレーサが使用する共用メモリ用ファイルサイズ（単位：バイト）は，PRFデーモンごとに算出します。計算式を次に示します。

PRFデーモンごとの共用メモリの計算式

共用メモリ用ファイルサイズ = -PrfTraceBufferSize指定値×1,024＋18,496

共用メモリ用ファイルサイズは，環境変数EXTSHMで設定します。計算式で算出した値以上に共用メモリが割り当てられるように設定してください。

(b)　ファイルディスクリプタ数

ファイルディスクリプタ数は，/etc/security/limitsファイルの「nofiles」で設定します。PRFデーモン起動時に使用するファイルディスクリプタの数は，32以上に設定してください。

(c)　$PRFSPOOLのディスク占有量

$PRFSPOOLのディスク占有量の計算式を次に示します。

$PRFSPOOLのディスク占有量の計算式

ディスク占有量 = 2.0MB

＋｛（-PrfTraceBufferSize指定値＋20KB）×5

＋-PrfTraceFileSize指定値×-PrfTraceCount指定値×r｝×n

＋224KB×(256＋m)

＋224KB×（64＋p）

（凡例）

n：PRFデーモンの数

m：起動中のパフォーマンストレース出力プロセス数と正常終了しなかったパフォーマンストレース出力プロセス数

パフォーマンストレーサでは，パフォーマンストレース出力プロセスごとに，保守情報として内部トレースをファイルに出力します。このファイルはプロセス起動時に作成されますが，プロセスが正常終了しない場合はファイルが残ります。ファイルの削除処理はPRFデーモン起動時，およびPRFデーモン起動後24時間ごとに実施しますが，256ファイルは削除されないで残ります。このため，最大ファイル数は「256＋24時間のうちに実行するパフォーマンストレース出力プロセス数」になります。

p：起動中の性能解析トレースで使用するコマンド，デーモンのプロセス数

パフォーマンストレーサでは，性能解析トレースで使用するコマンド，およびデーモンごとに，保守情報として内部トレースをファイルに出力します。このファイルはプロセス起動時に作成されます。PRFデーモン起動時，およびPRFデーモン起動後24時間ごとにファイル削除処理を実施しますが，64ファイルは削除されないで残ります。このため，最大ファイル数は「64＋24時間のうちに実行する性能解析トレースで使用するコマンド，およびデーモンのプロセス数」になります。

r：バックアップ係数

PRFトレースのバックアップ分を算出する値です。cprfstartコマンドの起動オプションに-PrfNoBackUp 0を指定する場合2, それ以外の場合1になります。

上記のディスク容量は目安です。このため，十分な余裕を持って，$PRFSPOOLを作成してください。

(3)　Linuxの場合

Linuxを使用する場合，パフォーマンストレーサを使用するために，次の値を考慮してカーネルパラメタを設定する必要があります。正しく設定できていない場合には，パフォーマンストレーサのプロセスが起動できなかったり，動作中にリソース不足で異常終了になったりするおそれがあります。なお，カーネルパラメタの設定については，使用しているOSのマニュアルを参照してください。

(a)　共用メモリ用ファイルサイズ

パフォーマンストレーサが使用する共用メモリ用ファイルサイズ（単位：バイト）は，PRFデーモンごとに算出します。計算式を次に示します。

PRFデーモンごとの共用メモリの計算式

共用メモリ用ファイルサイズ = -PrfTraceBufferSize指定値×1,024＋18,496

共用メモリ用ファイルサイズは，/etc/sysctl.confファイルの「kernel.shmmax」で設定します。計算式で算出した値以上に共用メモリが割り当てられるように設定してください。

(b)　ファイルディスクリプタ数

ファイルディスクリプタ数は，/etc/security/limits.confファイルの「nofiles」で設定します。PRFデーモン起動時に使用するファイルディスクリプタの数は，32以上に設定してください。

(c)　$PRFSPOOLのディスク占有量

$PRFSPOOLのディスク占有量の計算式については，AIXの場合と同じです。AIXの計算式を参照してください。

5.2.4　CTMが使用するリソースの見積もり

CTMが使用するリソースの見積もりについて，OSごとに説明します。なお，バッチアプリケーションの実行環境ではCTMは使用できません。

(1)　Windowsの場合

Windowsを使用する場合にCTMが使用するリソースの見積もりについて説明します。

(a)　共用メモリ用ファイルサイズ

CTMで使用する共用メモリ用ファイルサイズ（単位：バイト）の計算式について説明します。CTMデーモンの場合は，複数の共用メモリを確保する必要があります。CTMデーモン単位で固定長の共用メモリファイルと，可変長の共用メモリファイルがあります。それぞれのファイルサイズの計算式を次に示します。

CTMドメインマネジャの共用メモリ用ファイルサイズの計算式

共用メモリ用ファイルサイズ = 1,018,320＋（2,362×-CTMMaxCTM指定値）

CTMデーモンの共用メモリ用ファイルサイズの計算式

CTMデーモンの場合は，CTMデーモン単位で固定長の共用メモリ用ファイルと可変長の共用メモリ用ファイルを確保する必要があります。

固定長の共用メモリ用ファイルサイズ =

551,840＋（1,208×-CTMQueueCount指定値）

可変長の共用メモリ用ファイルサイズ =

1,027,008

＋（928×-CTMClientConnectCount指定値）

＋（256×-CTMServerConnectCount指定値）

＋（512×-CTMEntryCount指定値）

＋（1,024×-CTMServerCacheSize指定値）

＋（512×-CTMQueueCount指定値）

＋（544×-CTMQueueCount指定値×-CTMQueueRegistCount指定値）

＋（512×-CTMDispatchParallelCount指定値）

(b)　稼働統計情報ファイルサイズ

稼働統計情報ファイルサイズ（単位：バイト）の計算式を次に示します。

オンライン開始から終了までに必要な稼働統計情報ファイルサイズの計算式

ファイルサイズ = A＋B

（凡例）

A：（オンライン開始から終了までに実行されるリクエストの数）×（1リクエストで出力される情報量）

B：（オンライン開始から終了までの時間（分） ／ ctmstsstart -CTMIntervalに指定した取得間隔）×（1回に出力されるCTMノード単位，キュー単位統計情報量）

1リクエストで出力される情報量と，1回に出力されるCTMノード単位，キュー単位統計情報量の計算式を次に示します。

1リクエストで出力される情報量の計算式

情報量 = （↑（80＋A＋B＋C＋D＋63） / 64↑×64）×3

（凡例）

A：リクエストを実行するアプリケーションを管理しているCTMドメイン名のドメイン長

B：リクエストを実行するアプリケーションを管理しているCTMデーモンのCTM識別子の長さ

C：キュー名称の長さ

D：オペレーション名称の長さ

1回に出力されるCTMノード単位，キュー単位統計情報量の計算式

統計情報量 = ↑（2,144＋344×キュー数＋63） / 64↑×64

(c)　%CTMSPOOL%のディスク占有量

%CTMSPOOL%のディスク占有量の計算式を次に示します。

%CTMSPOOL%のディスク占有量の計算式

ディスク占有量 = 7.0MB

＋（18.5MB＋1.0MB×-CTMLogFileSize指定値×-CTMLogFileCount指定値）×n

＋（1KB＋0.5KB×k）×（m＋l）

＋1KB×m×j

＋224KB×p

＋1,120KB×（64＋q）

＋CTMドメインマネジャの共有メモリ用ファイルサイズ×5

＋CTMデーモンの共有メモリ用ファイルサイズ×5×n

＋CTMドメインマネジャのcoreサイズ

＋CTMデーモンのcoreサイズ×n

＋CTMレギュレータのcoreサイズ×3×m

＋OTMゲートウェイのcoreサイズ×3×l

＋（-CTMStatsFileSize指定値×-CTMStatsFileCount指定値）×n

（凡例）

j：EJBの総数

k：CTMレギュレータおよびOTMゲートウェイに接続できるクライアント数（-CTMClientConnectCountオプション指定値）

l：OTMゲートウェイの総数

m：CTMレギュレータの総数

n：CTMデーモンの数

p：起動中のユーザアプリケーションのプロセス数と正常終了しなかったユーザアプリケーションのプロセス数

CTMでは，ユーザアプリケーションごとに，保守情報として内部トレースをファイルに出力します。このファイルはプロセス起動時に作成されますが，プロセスが正常終了しない場合はファイルが残ります。ファイルの削除処理はCTMドメインマネジャ起動時，およびCTMドメインマネジャ起動後24時間ごとに実施しますが，256ファイルは削除されないで残ります。このため，最大ファイル数は「256＋起動中プロセス数」になります。

q：起動中のシステム系プロセス数

CTMでは，プロセスごとに，保守情報として内部トレースをファイルに出力します。このファイルはプロセス起動時に作成されます。CTMドメインマネジャ起動時，およびCTMドメインマネジャ起動後24時間ごとにファイル削除処理を実施しますが，64ファイルは削除されないで残ります。このため，最大ファイル数は「64＋起動中プロセス数」になります。

上記のディスク容量は目安です。このため，十分な余裕を持って，%CTMSPOOL%を作成してください。

(2)　AIXの場合

AIXを使用する場合，CTMを使用するために，次の値を考慮してカーネルパラメタを設定する必要があります。正しく設定できていない場合には，CTMのプロセスが起動できなかったり，動作中にリソース不足で異常終了になったりするおそれがあります。なお，カーネルパラメタの設定については，使用しているOSのマニュアルを参照してください。

(a)　共用メモリ用ファイルサイズ

共用メモリ用ファイルサイズは，環境変数EXTSHMで設定します。計算式で算出した値以上に共用メモリが割り当てられるように設定してください。なお，計算式については，Windowsの場合と同じです。Windowsの計算式を参照してください。

(b)　稼働統計情報ファイルサイズ

稼働統計情報ファイルサイズの計算式については，Windowsの場合と同じです。Windowsの計算式を参照してください。

(c)　ファイルディスクリプタ数

CTMデーモンでは，起動時のオプションを基に，次の計算式で示すように，プロセスで使用できるファイルディスクリプタの数を増加させます。OSの設定値が，計算式で設定したCTMデーモンで必要とするファイルディスクリプタの最大値に満たない場合には，プロセス起動でエラー終了します。計算式を基に/etc/security/limits.confファイルの「nofiles」を変更してください。

CTMデーモンで必要とするファイルディスクリプタ数の最大値の計算式

最大値 = （A×2＋B×4＋C×2＋D×E＋F×EJB数＋G＋100） / 0.8

（凡例）

A：-CTMMaxCTM値（ctmdが属するctmdmdで指定された値）

B：-CTMClientConnectCount値

C：-CTMServerConnectCount値

D：-CTMQueueCount値

E：-CTMQueueRegistCount値

F：-CTMDispatchParallelCount値

G：Createを発行するEJBクライアントの総数

(d)　$CTMSPOOLのディスク占有量

$CTMSPOOLのディスク占有量の計算式を次に示します。

$CTMSPOOLのディスク占有量の計算式

ディスク占有量 = 7.0MB

＋（18.5MB＋1.0MB×-CTMLogFileSize指定値×-CTMLogFileCount指定値）×n

＋（1KB＋0.5KB×k）×（m＋l）

＋1KB×m×j

＋224KB×p

＋1,120KB×（64＋q）

＋CTMドメインマネジャの共有メモリ用ファイルサイズ×5

＋CTMデーモンの共有メモリ用ファイルサイズ×5×n

＋CTMドメインマネジャのcoreサイズ

＋CTMデーモンのcoreサイズ×n

＋CTMレギュレータのcoreサイズ×3×m

＋OTMゲートウェイのcoreサイズ×3×l

＋（-CTMStatsFileSize指定値×-CTMStatsFileCount指定値）×n

（凡例）

j：EJBの総数

k：CTMレギュレータおよびOTMゲートウェイに接続できるクライアント数（-CTMClientConnectCountオプション指定値）

l：OTMゲートウェイの総数

m：CTMレギュレータの総数

n：CTMデーモンの数

p：起動中のユーザアプリケーションのプロセス数と正常終了しなかったユーザアプリケーションのプロセス数

CTMでは，ユーザアプリケーションごとに，保守情報として内部トレースをファイルに出力します。このファイルはプロセス起動時に作成されますが，プロセスが正常終了しない場合はファイルが残ります。ファイルの削除処理はCTMドメインマネジャ起動時，およびCTMドメインマネジャ起動後24時間ごとに実施しますが，256ファイルは削除されないで残ります。このため，最大ファイル数は「256＋起動中プロセス数」になります。

q：起動中のシステム系プロセス数

CTMでは，プロセスごとに，保守情報として内部トレースをファイルに出力します。このファイルはプロセス起動時に作成されます。CTMドメインマネジャ起動時，およびCTMドメインマネジャ起動後24時間ごとにファイル削除処理を実施しますが，64ファイルは削除されないで残ります。このため，最大ファイル数は「64＋起動中プロセス数」になります。

上記のディスク容量は目安です。このため，十分な余裕を持って，$CTMSPOOLを作成してください。

(3)　Linuxの場合

Linuxを使用する場合，CTMを使用するために，次の値を考慮してカーネルパラメタを設定する必要があります。正しく設定できていない場合には，CTMのプロセスが起動できなかったり，動作中にリソース不足で異常終了になったりするおそれがあります。なお，カーネルパラメタの設定については，使用しているOSのマニュアルを参照してください。

(a)　共用メモリ用ファイルサイズ

共用メモリ用ファイルサイズは，/etc/sysctl.confファイルの「kernel.shmmax」で設定します。計算式で算出した値以上に共用メモリが割り当てられるように設定してください。なお，計算式については，Windowsの場合と同じです。Windowsの計算式を参照してください。

(b)　稼働統計情報ファイルサイズ

稼働統計情報ファイルサイズの計算式については，Windowsの場合と同じです。Windowsの計算式を参照してください。

(c)　ファイルディスクリプタ数

ファイルディスクリプタ数は，/etc/security/limits.confファイルの「nofiles」で設定します。計算式を基に「nofiles」を変更してください。なお，計算式については，AIXの場合と同じです。AIXの計算式を参照してください。

(d)　$CTMSPOOLのディスク占有量

$CTMSPOOLのディスク占有量の計算式については，AIXの場合と同じです。AIXの計算式を参照してください。

5.2.5　cjclstartapプロセスの見積もり

cjclstartapプロセスのスレッド数の見積もりを次に示します。

明示管理ヒープ機能を使用する場合

Javaアプリケーションで生成するスレッド数＋30

明示管理ヒープ機能を使用しない場合

Javaアプリケーションで生成するスレッド数＋22

G1GCを使用する場合

Javaアプリケーションで生成するスレッド数＋22＋G1GCで使用するスレッド数

G1GCで使用するスレッド数については，「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照してください。

ZGCを使用する場合

Javaアプリケーションで生成するスレッド数＋22＋ZGCで使用するスレッド数

ZGCで使用するスレッド数については，「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照してください。

5.3　プロセスごとに使用するメモリの見積もり

この節では，アプリケーションサーバの各プロセスで使用するメモリの使用量の見積もりについて説明します。

5.3.1　J2EEサーバが使用する仮想メモリの使用量の見積もり

ここでは，仮想メモリの使用量の見積もり方法について説明します。なお，仮想メモリの使用量の計算式に使用しているJavaVM起動時のオプションの詳細については，「7.2.6　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」を参照してください。

また，ここで説明する内容のほか，明示管理ヒープ機能で使用するメモリサイズの見積もりが必要です。明示管理ヒープ機能で使用するメモリサイズの見積もりについては，「7.11　Explicitヒープのチューニング」を参照してください。

(1)　仮想メモリの使用量の計算式

仮想メモリの使用量（単位：メガバイト）の計算式を次に示します。

J2EEサーバの仮想メモリの使用量 = A＋B＋C＋（D＋22）×E＋F＋G

（凡例）

A：Javaヒープサイズ

初期値は，JavaVM起動時のオプション-Xmsに指定した値です。この値は，J2EEサーバ起動中に，最大でJavaVM起動時のオプション-Xmxに指定した値まで拡張されます。なお，ZGCを使用する場合は，仮想メモリを多く必要とします。ZGCを使用する場合は，この値は-Xmxに指定した値の48倍としてください。これは物理メモリの実際の使用サイズには影響しません。詳細については「7.20　ZGC使用時の注意事項（JDK17以降の場合）」を参照してください。

B：Metaspace領域サイズ

初期値は，JavaVMが割り当てた値です。この値は，J2EEサーバ起動中に，最大でJavaVM起動時のオプション-XX:MaxMetaspaceSizeに指定した値まで拡張されます。

監査ログを使用する場合

監査ログを使用する場合は，値に1メガバイトを加えてください。

C：ネイティブプログラム使用領域サイズ

OSごとに使用する値が異なります。ネイティブプログラム使用領域サイズのOSごとの値について，次の表に示します。

表5‒14　ネイティブプログラム使用領域サイズの値一覧

OS種別

使用領域の値

（単位：メガバイト）

Windows

700

Linux

600

監査ログを使用する場合

監査ログを使用する場合は，OSごとのネイティブプログラム使用領域サイズの値に，監査ログで使用する値を加える必要があります。監査ログで使用する値を算出するには，auditlog.raslog.message.filesizeキー，およびauditlog.raslog.exception.filesizeキーを使用します。これらのキーは，auditlog.properties（監査ログ定義ファイル）で指定するキーです。これらのキーの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「11.2.1　監査ログ定義ファイル」を参照してください。

監査ログで使用する値（単位：メガバイト）の計算式を次に示します。

監査ログで使用する値 =

8＋（auditlog.raslog.message.filesizeの指定値 / 1,024²）※＋（auditlog.raslog.exception.filesizeの指定値 / 1,024²）※

注※　指定値の単位はバイトです。仮想メモリの使用量の値の単位はメガバイトであるため，1,024²で割る必要があります。

D：J2EEサーバのスレッド数

J2EEサーバが使用するスレッド数です。J2EEサーバが使用するスレッド数については，「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照してください。

E：スタック領域サイズ

JavaVM起動時のオプション-Xssに指定した値です。

F：Explicitヒープサイズ

明示管理ヒープ機能で使用されるExplicitヒープのサイズです。この値は，J2EEサーバ起動中に最大で-XX:HitachiExplicitHeapMaxSizeに指定した値まで拡張されます。

G：コードキャッシュ領域の最大サイズ

JavaVM起動時のオプション-XX:ReservedCodeCacheSizeに指定した値です。

(2)　仮想メモリの使用量を計算する場合の注意事項

ネイティブプログラム使用領域サイズの値は変動します。値が変動するのは次のような場合です。

ORBのトレースサイズを変更した場合

JDBCドライバの使用領域サイズの値を変更した場合

使用する製品のネイティブライブラリ使用領域サイズの値を変更した場合

このような場合，製品ごとのメモリ使用量をネイティブプログラム使用領域サイズの値に加えてください。製品ごとのメモリ使用量は，使用する製品のドキュメントに従って算出してください。

J2EEサーバの標準構成で使用する仮想メモリの使用量は，使用するソフトウェア製品の影響で，見積もり値よりも大きくなる場合があります。その場合の増加分については，仮想メモリの使用量の値に加えてください。増加分のメモリ使用量は，使用するソフトウェア製品のドキュメントに従い，製品ごとのメモリ使用量を算出してください。

Linuxの場合，メモリのスワップファイルが不足すると，システムがスローダウンします。仮想メモリの上限値を，実メモリサイズ分指定することをお勧めします。

5.3.2　CTMのデーモンプロセスが使用するメモリの使用量の見積もり

CTMのデーモンプロセスの見積もり式を次に示します。

最大メモリ所要量 ＝A＋{B＋E＋(2×D)}×C＋F×G＋(D−1)×16メガバイト

（凡例）

A：基本メモリ量（128メガバイト）

B：CTMデーモンのキューに滞留する最大リクエスト数※1

C：最大リクエスト電文サイズ※2

D：-CTMClientConnectCount値※3

E：-CTMDispatchParallelCount値※4

F：CTMデーモンで必要とするスレッド数の最大値。見積もり式を示します。

　F ＝(a×4＋D×3＋b×2＋c×d＋E＋e＋32) / 0.8

（凡例）

a：-CTMMaxCTM値（ctmdが属するctmdmdで指定された値）※6

b：-CTMServerConnectCount値※7

c：-CTMQueueCount値※8

d：-CTMQueueRegistCount値※9

e：Createを発行するEJBクライアントの総数

G：スレッドスタックサイズ※5

注※1

最大リクエスト数はキュー長（キューが複数ある場合は，各キュー長の合計値）になります。

注※2

メモリサイズに余裕を持たせるため，キューに溜まるリクエストがすべて最大のサイズの場合を想定しますが，現実的な値としては，リクエスト電文サイズの平均値を指定することをお勧めします。

注※3

メモリサイズに余裕を持たせるため，CTMデーモンに接続できる最大数の場合を想定しますが，現実的な値としては，CTMデーモンに接続するCTMレギュレータとOTMゲートウェイの数を指定することをお勧めします。

注※4

メモリサイズに余裕を持たせるため，CTMデーモンに登録できる最大の同時実行数の場合を想定しますが，現実的な値としては，属性ファイルの<parallel-count>タグの値（キューが複数ある場合は，各キューの同時実行数の合計値）になります。

注※5

OSごとに使用する値が異なります。スレッドスタックサイズのOSごとのデフォルト値について，次に示します。

なお，スレッドスタックサイズについては，使用しているOSのマニュアルを参照してください。

Windows：1メガバイト

AIX：0.1メガバイト（96キロバイト）

Linux：10メガバイト

注※6

メモリサイズに余裕を持たせるため，CTMデーモンが最大数の場合を想定しますが，現実的な値としては，CTMドメイン内で管理するCTMデーモンの総数-1を指定することをお勧めします。

注※7

メモリサイズに余裕を持たせるため，CTMデーモンに接続できる最大数の場合を想定しますが，現実的な値としては，CTMデーモンに接続するJ2EEサーバの数を指定することをお勧めします。

注※8

メモリサイズに余裕を持たせるため，CTMデーモンに登録できる最大数の場合を想定しますが，現実的な値としては，CTMデーモンに登録するスケジュールキュー数を指定することをお勧めします。

注※9

メモリサイズに余裕を持たせるため，同じスケジュールキューを共有できる最大数の場合を想定しますが，現実的な値としては，同じスケジュールキューを共有するJ2EEアプリケーション数を指定することをお勧めします。

ポイント

CTMデーモンがリクエストを送受信する際，一時的に最大で業務電文サイズの3〜5倍程度のメモリを使用することがあります。ここで示した見積もり式では，この増分は基本サイズの128メガバイトに余裕値として含まれています。

しかし，業務電文サイズが10メガバイトや20メガバイトといった，非常に長大電文で，かつ同時実行数（パラレルカウントの合計値）が大きい場合，処理が重なりこの余裕値を超えてしまうことがあります。このような場合に，正確に最大メモリ使用量を見積もろうとすると，現実的な値ではなくなるため，概算値はここで示した見積もり式で算出した上で，実際に業務を動作させてメモリ使用量の推移を計測することをお勧めします。

6　使用するリソースの見積もり（バッチアプリケーション実行基盤）

この章では，バッチアプリケーションを実行するシステムで使用するリソース，および仮想メモリ使用量の見積もり方法について説明します。システムを動作させるために必要なディスクおよびメモリの容量を算出するときの参考にしてください。

J2EEアプリケーション実行基盤の使用リソースおよび仮想メモリ所要量の見積もりについては，「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」を参照してください。

6.1　システム構成ごとに使用するリソース

システムが動作するためには，OSやデータベースなどのホスティング環境の設定が必要な場合があります。システムが必要とするリソースは，システムの構成ごとに異なるため，ここではシステム構成ごとに使用するリソースと，リソースの所要量の見積もりについて説明します。システム構成ごとに使用するリソースと，リソースの見積もりの参照先を次の表に示します。

表6‒1　システム構成ごとに使用するリソースと見積もりの参照先

システム構成ごとに使用するリソース

参照先

バッチサーバを配置する場合の使用リソース

6.1.1

データベースの使用リソース

6.1.2

CTMを使用する場合の使用リソース

6.1.3

6.1.1　バッチサーバを配置する場合の使用リソース

バッチサーバを配置する場合の使用リソースの見積もりについて，OSごとに説明します。バッチサーバを配置する場合，バッチサーバを配置するマシンで使用するリソースを見積もります。

なお，使用リソースの見積もりの各表にある，「オプション設定ファイル例」については，使用しているOSのバージョン，およびカーネルのバージョンごとに異なります。使用しているOSのマニュアルを参照して，表中の見積もり式を基に見積もった値を設定してください。使用しているOSで該当するカーネルパラメタが設定できない場合には，設定は不要です。

また，プロセスごとに使用するリソースの見積もりについては，「6.2　プロセスごとに使用するリソース」を参照してください。

なお，仮想メモリ所要量については，「6.3　仮想メモリの使用量の見積もり」を参照してください。また，ディスク占有量については，アプリケーションサーバのリリースノートを参照してください。

(1)　AIXの場合

AIXの場合の，アプリケーションサーバマシンの使用リソースの見積もりについて次の表に示します。

表6‒2　アプリケーションサーバマシンの使用リソースの見積もり（AIXの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

サービスユニット※1

共用メモリ

−

PrfTraceBufferSize※2×1,024＋18,496

−

プロセス数

−

4

−

スレッド数

−

バッチサーバのスレッド数※3＋34

−

ファイルディスクリプタ数

nofiles

バッチサーバのファイルディスクリプタ数※3＋43

/etc/security/limits

Management Server

プロセス数

−

5

−

スレッド数

−

56

−

ファイルディスクリプタ数

nofiles

43＋バッチサーバ数

/etc/security/limits

（凡例）−：該当しません。

注※1

サービスユニットとは，次のまとまりを指します。

バッチサーバ + パフォーマンストレーサ

注※2

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※3

バッチサーバのスレッド数とファイルディスクリプタ数については，「6.2.1　バッチサーバが使用するリソースの見積もり」を参照して算出してください。

(2)　Linuxの場合

Linuxの場合の，アプリケーションサーバマシンの使用リソースの見積もりについて次の表に示します。

表6‒3　アプリケーションサーバマシンの使用リソースの見積もり（Linuxの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

サービスユニット※1

共用メモリ

SHMMAX

PrfTraceBufferSize※2×1,024＋18,496

/proc/sys/kernel/shmmax

プロセス数

threads-max※3

4

/proc/sys/kernel/threads-max

スレッド数

threads-max※3

バッチサーバのスレッド数※4＋34

−

ファイルディスクリプタ数

fs.file-max

バッチサーバのファイルディスクリプタ数※4＋43

/proc/sys/fs/file-max

Management Server

プロセス数

threads-max※3

5

/proc/sys/kernel/threads-max

スレッド数

threads-max※3

56

−

ファイルディスクリプタ数

fs.files-max

43＋バッチサーバ数

/proc/sys/fs/file-max

（凡例）−：該当しません。

注※1

サービスユニットとは，次のまとまりを指します。

バッチサーバ + パフォーマンストレーサ

注※2

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※3

threads-maxパラメタには，プロセス数とスレッド数の合計を指定してください。

注※4

バッチサーバのスレッド数とファイルディスクリプタ数については，「6.2.1　バッチサーバが使用するリソースの見積もり」を参照して算出してください。

6.1.2　データベースの使用リソース

DBMSの使用リソースの見積もりについて説明します。

仮想メモリ所要量については，「6.3　仮想メモリの使用量の見積もり」を参照してください。また，ディスク占有量については，Application ServerまたはDeveloperのリリースノートを参照してください。

DBMSの使用リソースの見積もりについて，次の表に示します。

表6‒4　DBMSの使用リソースの見積もり

DBMS

使用リソース

所要量

HiRDB

最大同時接続数(pd_max_users)

Oracle

最大同時接続数(SESSIONS)

注※1

nは，システム内のバッチサーバにデプロイするリソースアダプタの総和です。

注※2

Connector属性ファイルのMaxPoolSizeパラメタの値を指定します。

注※3

次に示す条件にすべて当てはまる場合に，×2を行ってください。

トランザクションサポートレベルにXATransactionを使用する。

アプリケーションサーバが管理するトランザクション内でコネクション※を使ってデータベースにアクセスする。

2.のトランザクションが決着する前に，トランザクション外でコネクション※を使ってデータベースにアクセスする。

注※　このコネクションは1.のDB Connectorから取得したコネクションで，かつ同一コネクションです。

注※4

トランザクションサポートレベルにXATransactionを指定しているリソースアダプタの場合に，＋1を行ってください。

注※5

＋αの最大値は，使用するDB Connectorのコネクションプールの最大値の合計値になります。

この＋αの値は，一時的にコネクションプールの最大値をオーバーするおそれのあるコネクションを指します。詳細を次に示します。

コネクションの障害検知機能を使用する場合

コネクションの障害検知機能を使用する場合，コネクションプールから取り除いた未使用のコネクションは，コネクションプール内のコネクション数としてカウントされません。そのため，コネクションプール内のコネクションとコネクションプールから取り除いた未使用のコネクションの総和が，コネクションプールのコネクション数の最大値を一時的に超えることがあります。

cjclearpoolコマンドを使用する場合

通常モードの場合，コネクションプールから取り除いた使用中のコネクションは，コネクション数としてカウントされません。そのため，コネクションプール内のコネクションとコネクションプールから取り除いた使用中のコネクションの総和がコネクションプールの最大値を超えることがあります。

6.1.3　CTMを使用する場合の使用リソース

CTM（バッチアプリケーションのスケジューリング機能）を使用する場合の，使用リソースの見積もりについて，OSごとに説明します。

なお，使用リソースの見積もりの各表にある，「オプション設定ファイル例」については，使用しているOSのバージョン，およびカーネルのバージョンごとに異なります。使用しているOSのマニュアルを参照して，表中の見積もり式を基に見積もった値を設定してください。使用しているOSで該当するカーネルパラメタが設定できない場合には，設定は不要です。

(1)　AIXの場合

CTMを使用する場合の，使用リソースの見積もりについて次の表に示します。

表6‒5　CTM使用時の使用リソースの見積もり（AIXの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

−

PrfTraceBufferSize※1×1,024＋18,496＋CTMドメインマネジャの共用メモリ※2＋CTMデーモンの共用メモリ※2

−

プロセス数

−

7＋バッチサーバ数※3

−

スレッド数

−

72＋(バッチサーバのスレッド数※4＋7)×バッチサーバ数※3＋CTMデーモンで必要とするスレッド数※5

−

ファイルディスクリプタ数

nofiles

88＋(バッチサーバのファイルディスクリプタ数※4＋6)×バッチサーバ数※3＋CTMデーモンで必要とするファイルディスクリプタ数※5

/etc/security/limits

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

値については，「6.1.3(1)(a)　共用メモリ用ファイルサイズの計算式」を参照して算出してください。

注※3

簡易構築定義ファイルの<j2ee-server-count>タグの指定値を指します。

注※4

バッチサーバのスレッド数とファイルディスクリプタ数については，「6.2.1　バッチサーバが使用するリソースの見積もり」を参照して算出してください。

注※5

CTMデーモンで必要とするスレッド数とファイルディスクリプタ数については，「6.1.3(1)(b)　CTMデーモンで必要とするスレッド数とファイルディスクリプタ数の計算式」を参照して算出してください。

(a)　共用メモリ用ファイルサイズの計算式

共用メモリ用ファイルサイズを算出するには，CTMドメインマネジャの共用メモリおよびCTMデーモンの共用メモリを算出する必要があります。それぞれの計算式について次に示します。

なお，計算式中の可変値には，次の値を使用してください。「ctm.」で始まるパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

計算式に使用する値

-CTMMaxCTM：64

-CTMQueueCount：ctm.QueueCount

-CTMClientConnectCount：256

-CTMServerConnectCount：ctm.ServerConnectCount

-CTMEntryCount：-CTMClientConnectCount＋-CTMServerConnectCount

-CTMServerCacheSize：ctm.ServerCacheSize

-CTMQueueRegistCount：ctm.QueueRegistCount

-CTMDispatchParallelCount：ctm.DispatchParallelCount

CTMドメインマネジャの共用メモリ用ファイルサイズの計算式

CTMドメインマネジャの共用メモリ用ファイルサイズの計算式を次に示します。

共用メモリ用ファイルサイズ（単位：バイト） =

1,018,320＋（2,362 × -CTMMaxCTM指定値）

CTMデーモンの共用メモリ用ファイルサイズの計算式

CTMデーモンの場合は，CTMデーモン単位で固定長の共用メモリ用ファイルと可変長の共用メモリ用ファイルを確保する必要があります。それぞれの計算式を次に示します。

固定長の共用メモリ用ファイルサイズ（単位：バイト） =

551,840 ＋ （1,208 × -CTMQueueCount指定値）

可変長の共用メモリ用ファイルサイズ（単位：バイト） =

1,027,008

＋（928 × -CTMClientConnectCount指定値）

＋（256 × -CTMServerConnectCount指定値）

＋（512 × -CTMEntryCount指定値）

＋（1,024 ×-CTMServerCacheSize指定値）

＋（512 × -CTMQueueCount指定値）

＋（544 × -CTMQueueCount指定値 × -CTMQueueRegistCount指定値）

＋（512 × -CTMDispatchParallelCount指定値）

(b)　CTMデーモンで必要とするスレッド数とファイルディスクリプタ数の計算式

スレッド数およびファイルディスクリプタ数を算出するには，CTMデーモンで必要とするスレッド数とファイルディスクリプタ数を算出する必要があります。それぞれの計算式について次に示します。

CTMデーモンで必要とするスレッド数の計算式

最大値 =

（A×4＋B×3＋C×2＋D×E＋F＋G＋32） / 0.8

（凡例）

A：-CTMMaxCTM値（ctmdが属するctmdmdで指定された値）

B：-CTMClientConnectCount値

C：-CTMServerConnectCount値

D：-CTMQueueCount値

E：-CTMQueueRegistCount値

F：-CTMDispatchParallelCount値

G：Createを発行するEJBクライアントの総数

CTMデーモンで必要とするファイルディスクリプタ数の計算式

最大値 =

（A×2＋B×4＋C×2＋D×E＋F×EJBのインタフェース数＋G＋100） / 0.8

（凡例）

A：-CTMMaxCTM値（ctmdが属するctmdmdで指定された値）

B：-CTMClientConnectCount値

C：-CTMServerConnectCount値

D：-CTMQueueCount値

E：-CTMQueueRegistCount値

F：-CTMDispatchParallelCount値

G：Createを発行するEJBクライアントの総数

(2)　Linuxの場合

CTMを使用する場合の，使用リソースの見積もりについて，次の表に示します。

表6‒6　CTM使用時の使用リソースの見積もり（Linuxの場合）

システムリソース

パラメタ

所要量

オプション設定ファイル例

共用メモリ

SHMMAX

PrfTraceBufferSize※1×1,024＋18,496＋CTMドメインマネジャの共用メモリ※2＋CTMデーモンの共用メモリ※2

/proc/sys/kernel/shmmax

プロセス数

threads-max※6

pid_max※6

7＋バッチサーバ数※3

/proc/sys/kernel/threads-max

/proc/sys/kernel/pid_max

スレッド数

threads-max※6

pid_max※6

72＋(バッチサーバのスレッド数※4＋7)×バッチサーバ数※3＋CTMデーモンで必要とするスレッド数※5＋CTMレギュレータで必要とするスレッド数※7

/proc/sys/kernel/threads-max

/proc/sys/kernel/pid_max

ファイルディスクリプタ数

fs.file-max

88＋(バッチサーバのファイルディスクリプタ数※4＋6)×バッチサーバ数※3＋CTMデーモンで必要とするファイルディスクリプタ数※5

/proc/sys/fs/file-max

（凡例）−：該当しません。

注※1

パフォーマンストレーサのバッファメモリサイズを512キロバイト〜102,400キロバイトの範囲で指定します。PrfTraceBufferSizeについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.12　論理パフォーマンストレーサで指定できるパラメタ」を参照してください。

注※2

値については，「6.1.3(1)(a)　共用メモリ用ファイルサイズの計算式」を参照して算出してください。

注※3

簡易構築定義ファイルの<j2ee-server-count>タグの指定値を指します。

注※4

バッチサーバのスレッド数とファイルディスクリプタ数については，「6.2.1　バッチサーバが使用するリソースの見積もり」を参照して算出してください。

注※5

CTMデーモンで必要とするスレッド数とファイルディスクリプタ数については，「6.1.3(1)(b)　CTMデーモンで必要とするスレッド数とファイルディスクリプタ数の計算式」を参照して算出してください。

注※6

threads-maxパラメタおよびpid_maxパラメタには，プロセス数とスレッド数の合計以上を指定してください。

注※7

CTMレギュレータで必要とするスレッド数については，「12+(EJBクライアントの総数×2)/0.8)」を使用して算出してください。

EJBクライアントの総数の最大値はctmregltdの-CTMClientConnectCount値の合計になります。

6.2　プロセスごとに使用するリソース

この節では，アプリケーションサーバの各プロセスで使用するリソースの所要量の見積もりについて説明します。

6.2.1　バッチサーバが使用するリソースの見積もり

ここでは，バッチサーバのスレッド数とファイルディスクリプタ数の見積もり方法について説明します。アプリケーションサーバを動作させるために必要なディスクおよびメモリの容量を算出するときの参考にしてください。

(1)　スレッド数

スレッド数の計算式を次に示します。(a)と(b)の合計が，バッチサーバが使用するスレッド数です。

(a)　基本のスレッド数

最大スレッド数 = 68＋A＋B＋C＋D＋E＋F＋G＋H＋I

（凡例）

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

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

CORBAネーミングサービスのスレッド数の見積もりについては，「5.2.1(3)　CORBAネーミングサービス（インプロセス起動時）のスレッド数の見積もり」を参照してください。

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

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

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

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

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

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

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

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

G：管理用サーバへの同時接続クライアント数（ただし，管理用サーバへの同時接続クライアント数が5以下の場合は5，100以上の場合は100を指定する）

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

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

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

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

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

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

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

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

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

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

最大スレッド数 = A＋B＋C

（凡例）

A：G1GCで使用するスレッド数（a＋b＋2）※

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

C：ZGCで使用するスレッド数（a＋b＋5）※

注※

凡例は次のとおりです。

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

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

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

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

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

(2)　ファイルディスクリプタ数

ファイルディスクリプタ数の計算式を次に示します。

最大ファイルディスクリプタ数 = （149＋A＋B×2＋C） / 0.8

（凡例）

A：データベースコネクションの数

B：リソースアダプタ数

C：usrconf.cfgのadd.class.pathキーに指定したJARファイルの数

6.2.2　運用管理エージェントが使用するリソースの見積もり

運用管理エージェントが使用するリソースの見積もりについては，J2EEアプリケーション実行基盤の場合と同じため，「5.2.2　運用管理エージェントが使用するリソースの見積もり」を参照してください。

6.2.3　パフォーマンストレーサが使用するリソースの見積もり

パフォーマンストレーサが使用するリソースの見積もりについては，J2EEアプリケーション実行基盤の場合と同じため，「5.2.3　パフォーマンストレーサが使用するリソースの見積もり」を参照してください。

6.2.4　CTMが使用するリソースの見積もり

CTMが使用するリソースの見積もりについては，J2EEアプリケーション実行基盤の場合と同じため，「5.2.4　CTMが使用するリソースの見積もり」を参照してください。

6.3　仮想メモリの使用量の見積もり

ここでは，仮想メモリの使用量の見積もり方法について説明します。なお，仮想メモリの使用量の計算式に使用しているJavaVM起動時のオプションの詳細については，「7.2.6　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」を参照してください。

また，明示管理ヒープ機能を使用する場合は，ここで説明する内容のほか，明示管理ヒープ機能で使用するメモリサイズの見積もりが必要です。明示管理ヒープ機能で使用するメモリサイズの見積もりについては，「7.11　Explicitヒープのチューニング」を参照してください。

6.3.1　仮想メモリの使用量の計算式

仮想メモリの使用量（単位：メガバイト）の計算式を次に示します。

バッチサーバの仮想メモリの使用量 = A＋B＋C＋（D＋22）×E＋F＋G

（凡例）

A：Javaヒープサイズ

初期値は，JavaVM起動時のオプション-Xmsに指定した値です。この値は，J2EEサーバ起動中に，最大でJavaVM起動時のオプション-Xmxに指定した値まで拡張されます。なお，ZGCを使用する場合は，仮想メモリを多く必要とします。ZGCを使用する場合は，この値は-Xmxに指定した値の48倍としてください。これは物理メモリの実際の使用サイズには影響しません。詳細については「7.20　ZGC使用時の注意事項（JDK17以降の場合）」を参照してください。

B：Metaspace領域サイズ

初期値は，JavaVMが割り当てた値です。この値は，J2EEサーバ起動中に，最大でJavaVM起動時のオプション-XX:MaxMetaspaceSizeに指定した値まで拡張されます。

監査ログを使用する場合

監査ログを使用する場合は，値に1メガバイトを加算してください。

C：ネイティブプログラム使用領域サイズ

OSごとに使用する値が異なります。ネイティブプログラム使用領域サイズのOSごとの値について，次の表に示します。

これに加えて，一時的に使用領域サイズが大きくなるケースがあります。「6.3.2　仮想メモリの使用量を計算する場合の注意事項」を参照してください。

表6‒7　ネイティブプログラム使用領域サイズの値一覧

OS種別

使用領域の値

（単位：メガバイト）

Windows

300

AIX

400

Linux

600

監査ログを使用する場合

監査ログを使用する場合は，OSごとのネイティブプログラム使用領域サイズの値に，監査ログで使用する値を加算する必要があります。監査ログで使用する値を算出するには，auditlog.raslog.message.filesizeキー，およびauditlog.raslog.exception.filesizeキーを使用します。これらのキーは，auditlog.properties（監査ログ定義ファイル）で指定するキーです。これらのキーの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「11.2.1　監査ログ定義ファイル」を参照してください。

監査ログで使用する値（単位：メガバイト）の計算式を次に示します。

監査ログで使用する値 =

8＋（auditlog.raslog.message.filesizeの指定値 / 1,024²）※＋（auditlog.raslog.exception.filesizeの指定値 / 1,024²）※

注※　指定値の単位はバイトです。仮想メモリの使用量の値の単位はメガバイトであるため，1,024²で割る必要があります。

D：バッチサーバのスレッド数

バッチサーバが使用するスレッド数です。バッチサーバが使用するスレッド数については，「6.2.1　バッチサーバが使用するリソースの見積もり」を参照してください。

E：スタック領域サイズ

JavaVM起動時のオプション-Xssに指定した値です。

F：Explicitヒープサイズ

明示管理ヒープ機能で使用されるExplicitヒープのサイズです。この値は，J2EEサーバ起動中に最大で-XX:HitachiExplicitHeapMaxSizeに指定した値まで拡張されます。なお，デフォルトではExplicitヒープは無効になります。

G：コードキャッシュ領域の最大サイズ

JavaVM起動時のオプション-XX:ReservedCodeCacheSizeに指定した値です。

6.3.2　仮想メモリの使用量を計算する場合の注意事項

ネイティブプログラム使用領域サイズの値は変動します。値が変動するのは次のような場合です。

ORBのトレースサイズを変更した場合

JDBCドライバの使用領域サイズの値を変更した場合

使用する製品のネイティブライブラリ使用領域サイズの値を変更した場合

このような場合，製品ごとのメモリ使用量をネイティブプログラム使用領域サイズの値に加算してください。製品ごとのメモリ使用量は，使用する製品のドキュメントに従って算出してください。

上記のネイティブプログラムの使用に加えて，JavaVMが実施するJITコンパイル処理（Javaプログラムをネイティブコードに変換する処理）で，まれに数GBのCヒープメモリを一時的に使用するケースがあります。

バッチサーバの標準構成で使用する仮想メモリの使用量は，使用するソフトウェア製品の影響で，見積もり値よりも大きくなる場合があります。その場合の増加分については，仮想メモリの使用量の値に加算してください。増加分のメモリ使用量は，使用するソフトウェア製品のドキュメントに従い，製品ごとのメモリ使用量を算出してください。

Linuxの場合，メモリのスワップファイルが不足すると，システムがスローダウンします。仮想メモリの上限値を，実メモリサイズ分指定することをお勧めします。

7　JavaVMのメモリチューニング

システムの処理性能を高めるには，基盤となるJavaVM自体のチューニングを適切に実施する必要があります。製品のJavaVM（以降，JavaVMと呼びます）では，2種類のメモリ空間を管理しています。

この章では，GCとJavaVMでのメモリ管理，およびJavaヒープとExplicitヒープのチューニングについて説明します。

7.1　GCとJavaVMのメモリ管理の概要

JavaVMのチューニングの目的は，システムの処理性能の向上です。特に，GCの仕組みを踏まえ，適切なメモリ管理ができるようにチューニングすることで，システムの処理性能が向上します。GCの挙動はメモリ管理方式によって変わるため，システムの要件に合わせて適切なメモリ管理方式を選択してください。アプリケーションサーバでは次のメモリ管理方式を選択できます。

表7‒1　各メモリ管理方式の特徴

項番

メモリ管理方式

特徴

1

SerialGC

スループットを重視するシステムに適している。

スループットが高い。

GCには長い時間かかるGC(FullGC)と短い時間で終わるGC(CopyGC)がある。GCの時間を制御できない。

メモリサイズのチューニングをすることで，FullGCの発生を抑止できる。

2

SerialGCと明示管理ヒープ機能の組み合わせ※1

セッションを使用した一般的なWebフロントシステムに適している。

スループットが高い。

GCには長い時間かかるGC(FullGC)と短い時間で終わるGC(CopyGC)がある。GCの時間を制御できない。

セッションを利用したシステムでは，メモリサイズのチューニングに加えて，セッションをExplicitヒープで管理することでFullGCを抑止できる。

3

G1GC

大規模なメモリを使用するシステムやレスポンスを重視するシステムに適している。

項番1や項番2の方式と比較してスループットが低い。

GCには長い時間かかるGC(FullGC)と短い時間で終わるGC(YoungGC，MixedGC)がある。YoungGCとMixedGCのGCの時間を制御できる。

メモリサイズのチューニングに加え，GCを行うスレッド数を増やすことで，FullGCの発生を抑止できる。

4

ZGC※2

低レイテンシを重視するシステムに適している。一部を除き，GC処理をアプリケーションの実行と並行で行うため，アプリケーションの停止時間が非常に短い。これは数テラバイトの非常に大きなヒープを使用するようなシステムでも同様である。

項番1，3の方式と比較してスループットが低い。

項番1，3の方式のように複数の種類のGCで構成されていないため，ZGCサイクルと呼ばれる一連の処理が毎回繰り返される。

メモリサイズの単純なチューニングだけで低レイテンシを実現できる。

注※1

JDK11以前の場合にだけ選択できます。

注※2

JDK17以降の場合にだけ選択できます。

SerialGCについては「7.2　SerialGCの仕組み」〜「7.10　拡張verbosegc情報を使用したFullGCの要因の分析方法」を，明示管理ヒープ機能については「7.11　Explicitヒープのチューニング」〜「7.14　明示管理ヒープ機能適用時に発生しやすい問題とその解決方法」を，G1GCについては「7.15　G1GCの仕組み」〜「7.16　G1GCのチューニング」を，ZGCについては「7.17　ZGCの仕組み（JDK17以降の場合）」〜「7.20　ZGC使用時の注意事項（JDK17以降の場合）」を参照してください。

7.2　SerialGCの仕組み

ここでは，SerialGCの仕組みについて説明します。

7.2.1　SerialGCの概要

GCは，プログラムが使用し終わったメモリ領域を自動的に回収して，ほかのプログラムが利用できるようにするための技術です。

GCの実行中は，プログラムの処理が停止します。このため，GCを適切に実行できるかどうかが，システムの処理性能に大きく影響します。

プログラムの中でnewによって作成されたJavaオブジェクトは，JavaVMが管理するメモリ領域に格納されます。Javaオブジェクトが作成されてから不要になるまでの期間を，Javaオブジェクトの寿命といいます。

Javaオブジェクトには，寿命の短いオブジェクトと寿命の長いオブジェクトがあります。サーバサイドで動作するJavaアプリケーションの場合，リクエストやレスポンス，トランザクション管理などで，多くのJavaオブジェクトが作成されます。これらのJavaオブジェクトは，その処理が終わると不要になる，寿命が短いオブジェクトです。一方，アプリケーションの動作中使用され続けるJavaオブジェクトは，寿命が長いオブジェクトです。

効果的なGCを実行するためには，寿命の短いオブジェクトに対してGCを実行して，効率良くメモリ領域を回収することが必要です。また，繰り返し使用される寿命の長いオブジェクトに対する不要なGCを抑止することが，システムの処理性能の低下防止につながります。これを実現するのが，世代別GCです。

世代別GCでは，Javaオブジェクトを，寿命が短いオブジェクトが格納されるNew領域と，寿命が長いオブジェクトが格納されるTenured領域に分けて管理します。New領域はさらに，newによって作成されたばかりのオブジェクトが格納されるEden領域と，1回以上のGCの対象になり，回収されなかったオブジェクトが格納されるSurvivor領域に分けられます。New領域内で一定回数以上のGCの対象になったJavaオブジェクトは，長期間必要なJavaオブジェクトと判断され，Tenured領域に移動します。

世代別GCで管理するメモリ空間とJavaオブジェクトの概要を次の図に示します。

図7‒1　世代別GCで管理するメモリ空間とJavaオブジェクトの概要

SerialGCの世代別GCで実行されるGCには，次の2種類があります。

CopyGC

Eden領域とSurvivor領域を対象にしたGCです。Javaオブジェクトの作成によって，Eden領域を使い切ると発生します。

注意事項

アプリケーションサーバでは，SerialGCとG1GC（UseG1GC）が選択できます。ほかのParallelGC，ConcurrentGC，IncrementalGCは使用できません。

FullGC

Tenured領域も含む，JavaVM固有領域全体を対象にしたGCです。Tenured領域を一定サイズまで使うと発生します。

一般的に，CopyGCの方が，FullGCよりも短い時間で処理できます。

次に，GCの処理について，あるJavaオブジェクト（オブジェクトA）を例にして説明します。

Eden領域で実行される処理

オブジェクトAの作成後，1回目のCopyGCが実行された時点で使用されていない場合，オブジェクトAは破棄されます。

1回目のCopyGCが実行された時点で使用されていた場合，オブジェクトAはEden領域からSurvivor領域に移動します。

Survivor領域で実行される処理

Survivor領域に移動したオブジェクトAは，その後何回かCopyGCが実行されると，Survivor領域からTenured領域に移動します。移動する回数のしきい値は，JavaVMオプションやJavaヒープの利用状況によって異なります。図7-1では，しきい値をn回としています。

Survivor領域への移動後，n回目未満のCopyGCが実行された時点でオブジェクトAが使用されていなかった場合，オブジェクトAはそのCopyGCで破棄されます。

Tenured領域で実行される処理

オブジェクトAがTenured領域に移動した場合，その後のCopyGCでオブジェクトAが破棄されることはありません。CopyGCは，Eden領域とSurvivor領域だけを対象としているためです。

このようにしてオブジェクトが移動することで，Tenured領域の使用サイズは増加します。Tenured領域を一定サイズまで使うと，FullGCが発生します。

JavaVMのチューニングでは，JavaVMオプションでそれぞれのメモリ空間のサイズや割合を適切に設定することで，不要なオブジェクトがTenured領域に移動することを抑止します。これによって，FullGCが頻発することを防ぎます。

7.2.2　オブジェクトの寿命と年齢の関係

オブジェクトがCopyGCの対象になった回数をオブジェクトの年齢といいます。

オブジェクトの寿命と年齢の関係を次の図に示します。

図7‒2　オブジェクトの寿命と年齢の関係

アプリケーションが開始して初期化処理が完了したあとで，何度かのCopyGCが実行されると，長期間必要になる寿命の長いオブジェクトはTenured領域に移動します。このため，アプリケーションの開始後しばらくすると，Javaヒープの状態は安定し，作成されるJavaオブジェクトとしては，寿命が短いオブジェクトが多くなります。特に，New領域のチューニングが適切にできている場合，Javaヒープが安定したあとの大半のオブジェクトは，1回目のCopyGCで回収される，寿命が短いオブジェクトになります。

7.2.3　CopyGCの仕組み

JavaVMでは，CopyGCの対象になるNew領域のメモリ空間を，Eden領域，Survivor領域に分けて管理します。さらに，Survivor領域は，From空間とTo空間に分けられます。From空間とTo空間は，同じメモリサイズです。

New領域の構成を次の図に示します。

図7‒3　New領域の構成

Eden領域は，newによって作成されたオブジェクトが最初に格納される領域です。プログラムでnewが実行されると，Eden領域のメモリが確保されます。

Eden領域がいっぱいになると，CopyGCが実行されます。CopyGCでは，次の処理が実行されます。

Eden領域およびSurvivor領域のFrom空間にあるJavaオブジェクトのうち，使用中のJavaオブジェクトが，Survivor領域のTo空間にコピーされます。使用されていないJavaオブジェクトは破棄されます。

Survivor領域のTo空間とFrom空間が入れ替わります。

この結果，Eden領域とTo空間は空になり，使用中のオブジェクトはFrom空間に存在することになります。

CopyGC実行時に発生するオブジェクトの移動を次の図に示します。

図7‒4　CopyGC実行時に発生するオブジェクトの移動

このようにして，使用中のオブジェクトは，CopyGCが発生するたびに，From空間とTo空間を行ったり来たりします。ただし，寿命の長いオブジェクトを行き来させ続けると，コピー処理の負荷などが問題になります。これを防ぐために，From空間とTo空間でJavaオブジェクトを入れ替える回数にしきい値を設定して，年齢がしきい値に達したJavaオブジェクトはTenured領域に移動させるようにします。

7.2.4　オブジェクトの退避

年齢がしきい値に達していないJavaオブジェクトがTenured領域に移動することを，退避といいます。退避は，CopyGC実行時にEden領域およびFrom空間で使用中のオブジェクトが多くなり，移動先であるTo空間のメモリサイズが不足する場合に発生します。この場合，To空間に移動できなかったオブジェクトが，Tenured領域に移動します。

図7‒5　オブジェクトの退避

オブジェクトの退避が発生した場合，Tenured領域に本来格納されないはずの寿命の短いオブジェクトが格納されます。これが繰り返されると，CopyGCで回収されるはずのオブジェクトがメモリ空間に残っていくため，Javaヒープのメモリ使用量が増加していき，最終的にはFullGCが発生します。

オブジェクトの退避が発生した場合のメモリ使用量の変化について，次の図に示します。

図7‒6　オブジェクトの退避が発生した場合のメモリ使用量の変化

FullGCでは，システムが数秒から数十秒停止することがあります。

したがって，メモリ空間の構成とメモリサイズを検討するときには，オブジェクトの退避が発生しないように，Eden領域とSurvivor領域のバランスを検討する必要があります。

7.2.5　GC対象外の領域（明示管理ヒープ機能を使用したExplicitヒープ領域の利用）

JavaVMでは，Eden領域，Survivor領域，およびTenured領域以外の領域としてExplicitヒープという領域を利用できます。Explicitヒープ領域はGC対象外の領域です。

Explicitヒープ領域に格納するオブジェクトは，自動配置設定ファイル，および明示管理ヒープ機能APIを使って指定します。指定されたオブジェクトは，Survivor領域からTenured領域へ移動する際にExplicitヒープ領域へ移動します。CopyGCで回収の対象にならない長寿命オブジェクトを指定することで，Tenured領域のメモリ使用量を少なくし，FullGCの発生を抑止します。また，明示管理ヒープ機能の自動配置設定ファイルや，明示管理ヒープ機能APIを使って，指定したオブジェクトをExplicitヒープ領域に生成することもできます。

明示管理ヒープ機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「7.　明示管理ヒープ機能を使用したFullGCの抑止」を参照してください。

7.2.6　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション

ここでは，SerialGC使用時のJavaVMで使用するメモリ空間の構成と，JavaVMオプションについて説明します。

JavaVMでは，JavaVM固有領域とOS固有領域という，2種類のメモリ空間を使用します。

JavaVMで使用するメモリ空間の構成を次の図に示します。なお，図中の番号は，表7-2の項番と対応しています。

図7‒7　JavaVMで使用するメモリ空間の構成

それぞれの領域について説明します。なお，Eden領域，Survivor領域，およびTenured領域を合わせた領域を，Javaヒープといいます。

Eden領域

newによって作成されたJavaオブジェクトが最初に格納される領域です。

Survivor領域

New領域に格納されていたJavaオブジェクトのうち，CopyGC実行時に破棄されなかったJavaオブジェクトが格納される領域です。Survivor領域は，From空間とTo空間で構成されます。From空間とTo空間のサイズは同じです。

Tenured領域

長期間必要であると判断されたJavaオブジェクトが格納される領域です。Survivor領域で指定回数を超えてCopyGCの実行対象となり，破棄されなかったJavaオブジェクトが，この領域に移動されます。

Metaspace領域

ロードされたclassなどの情報が格納される領域です。

ただし，圧縮オブジェクトポインタ機能が有効な場合，Metaspace領域内にCompressed Class Spaceという領域が作成されます。この領域に，Javaヒープ内のオブジェクトから参照されるクラス情報が配置されます。そして，それ以外のメソッド情報などがCompressed Class Space以外のMetaspace領域に配置されます。圧縮オブジェクトポインタ機能については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「9.18　圧縮オブジェクトポインタ機能」を参照してください。

Explicitヒープ領域

FullGCの対象外になるJavaオブジェクトが格納される領域です。Explicitヒープ領域はJavaVM独自のメモリ空間で，明示管理ヒープ機能を利用する場合だけ確保されます。

Cヒープ領域

JavaVM自身が使用する領域です。JNIで呼び出されたネイティブライブラリでも使用されます。

参考

Cヒープ領域の最大サイズについて（AIXの場合）

AIXの場合，JNIを使用してJavaVMを起動するプログラムを実行するときは，次のどれかの方法でCヒープ領域の最大サイズを設定してください。どれも設定していない場合は，シェルのdatasizeリソースのデフォルト値がCヒープ領域の最大サイズとなります。

シェルでdatasizeリソースの値にCヒープ領域のサイズを指定してから，プログラムを実行してください。

csh（Cシェル）の場合：limit datasize <Cヒープ領域のサイズ>

sh（標準シェル）およびkshの場合：ulimit -d <Cヒープ領域のサイズ>

プログラム生成時のリンケージオプションに，「-bmaxdata:<Cヒープ領域のサイズ>」を指定してください。

環境変数LDR_CNTRLでMAXDATA値を指定してから，プログラムを実行してください。

csh（Cシェル）の場合：setenv LDR_CNTRL MAXDATA=<Cヒープ領域のサイズ>

sh（標準シェル）およびkshの場合：export LDR_CNTRL=MAXDATA=<Cヒープ領域のサイズ>

setrlimit()システムコールを使用して，Cヒープ領域のサイズを設定する処理をプログラム内で実装してください。

例えば，次のような領域があります。

コードキャッシュ領域

JITコンパイルによって生成されたJITコンパイルコードが格納される領域です。

JavaVMは，呼び出し回数やループ回数が多いJavaメソッドをJITコンパイルして実行することで，処理の高速化を行います。

参考

コードキャッシュ領域の最大サイズについて

コードキャッシュ領域の最大サイズは，ReservedCodeCacheSizeオプションに指定します。

ReservedCodeCacheSizeオプションには，デフォルト値以上の値を指定してください。デフォルト値については，マニュアル「アプリケーションサーバ リファレンス定義編(サーバ定義)」の「14.4　Application Serverで指定できるJava HotSpot VMのオプションのデフォルト値」を参照してください。

また，コードキャッシュ領域が枯渇していた場合，または枯渇するおそれがある場合は，コードキャッシュ領域の拡張を検討してください。

コードキャッシュ領域を拡張する場合は，次の点に注意してください。

JITコンパイルコードのサイズは計算で見積もることができません。そのため，Javaアプリケーション実行環境でコードキャッシュ領域の使用量を実測し，システムが使用するコードキャッシュ領域（最大2メガバイト）の使用量を考慮した上で，コードキャッシュ領域の最大サイズを見積もってください。

仮想メモリの使用量の見積もりについては，「5.3　プロセスごとに使用するメモリの見積もり」または「6.3　仮想メモリの使用量の見積もり」を参照してください。

スタック領域

Javaスレッドのスタック領域です。

参考

メインスレッドのスタック領域サイズについて

メインスレッドのスタック領域サイズを変更する場合は，-Xssに指定した値以上の値を設定してください。-Xssオプションでは，メインスレッドのスタック領域サイズは変更できません。J2EEサーバ起動時のJ2EEアプリケーションの自動開始処理はメインスレッドで行うため，自動開始に失敗する場合があります。この場合，J2EEアプリケーションの自動開始を行わないように，-nostartappオプションを指定してJ2EEサーバを起動後，手動でJ2EEアプリケーションを起動するか，Managementアクションを使用してJ2EEアプリケーションを起動してください。

それぞれの領域のサイズや割合などを指定するJavaVMオプションを次の表に示します。なお，表の項番は，図7-7と対応しています。

表7‒2　JavaVMメモリ空間のサイズや割合などを指定するJavaVMオプション

項番

オプション名

オプションの意味

1

-Xmx<size>

Javaヒープの最大サイズを設定します。

2

-Xms<size>

Javaヒープの初期サイズを設定します。

3

-XX:MaxMetaspaceSize=<size>

Metaspace領域の最大サイズを設定します。

4

-XX:MetaspaceSize=<size>

Metaspace領域の初期サイズを設定します。

5

-Xmn<size>

New領域の初期値および最大値を設定します。

6

-XX:[+|-]HitachiAutoExplicitMemory

自動配置機能を使用する場合に，JavaVMを起動したタイミングでExplicitメモリブロックで使用するメモリを確保します。※

7

-XX:HitachiExplicitHeapMaxSize=<size>

Explicitヒープ領域サイズの最大サイズを設定します。※

8

-Xss<size>

１スタック領域の最大サイズを設定します。

9

-XX:ReservedCodeCacheSize=<size>

JavaVMが使用する領域のうち，コードキャッシュ領域の最大サイズを設定します。

10

-XX:NewRatio=<value>

New領域に対するTenured領域の割合を設定します。

<value>が2の場合は，New領域とTenured領域の割合が，1:2になります。

11

-XX:SurvivorRatio=<value>

Survivor領域のFrom空間とTo空間に対するEden領域の割合を設定します。

<value>に8を設定した場合は，Eden領域，From空間，To空間の割合が，8:1:1になります。

12

-XX:TargetSurvivorRatio=<value>

CopyGC実行後のSurvivor領域内でJavaオブジェクトが占める割合の目標値を設定します。

13

-XX:MaxTenuringThreshold=<value>

CopyGC実行時に，From空間とTo空間でJavaオブジェクトを入れ替える回数の最大値を設定します。

設定した回数を超えて入れ替え対象になったJavaオブジェクトは，Tenured領域に移動されます。

注　<size>の単位はバイトです。

注※　明示管理ヒープ機能を使用するための前提オプションが有効になっている必要があります。詳細は「7.11　Explicitヒープのチューニング」を参照してください。

参考

JavaVMオプションの設定の仕方

JavaVMオプションは，次の個所に設定します。

表7‒3　JavaVMオプションを設定する個所

対象

設定方法

設定個所

J2EEサーバ

Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

add.jvm.arg

バッチサーバ

Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

add.jvm.arg

EJBクライアントアプリケーション

ファイル編集

定義ファイル

usrconf.cfg※

パラメタ名

add.jvm.argキー

注※　cjclstartapコマンドを使用して開始する場合に有効になるファイルです。

ポイント

それぞれのオプションのデフォルト値は，OSによって異なります。オプションのデフォルト値については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.4　Application Serverで指定できるJava HotSpot VMのオプションのデフォルト値」を参照してください。

注意事項

Javaヒープ領域，Metaspace領域，Compressed Class Space，Cヒープ領域のどれかが不足するとOutOfMemoryが発生し，メモリ不足が解消されないかぎり正常に稼働できない状態が長く続くことになります。

これに対して，OutOfMemory発生時のシステムへの影響を小さくするために，次のオプションを使用できます。

-XX:+HitachiOutOfMemoryAbort（OutOfMemory発生時強制終了機能）

-XX:+HitachiOutOfMemoryHandling（OutOfMemoryハンドリング機能）

OutOfMemory発生時強制終了機能は，Javaヒープ不足やMetaspace領域不足，Compressed Class Space不足などが原因でOutOfMemoryが発生した場合に，J2EEサーバを強制終了するための機能です。Javaヒープ領域，Metaspace領域，Compressed Class Space，Cヒープ領域のメモリ不足によってOutOfMemoryが発生したときに，J2EEサーバを強制終了して，J2EEサーバを自動再起動します。これによって，J2EEサーバを正常に稼働できる状態に早期に回復できます。

OutOfMemoryハンドリング機能は，OutOfMemory発生時強制終了機能を前提とする機能です。OutOfMemory発生時強制終了機能を使用している場合でも，特定の条件に合致するときに限ってJ2EEサーバの実行を継続したい場合に使用します。

リクエスト処理でオブジェクトを大量に確保しようとした場合，巨大なオブジェクトを確保しようとした場合などにJavaヒープ不足が原因のOutOfMemoryが発生したときに，J2EEサーバの実行を継続するようにしたいときには，OutOfMemoryハンドリング機能を使用してください。

オプションの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「-XX:[+|-]HitachiOutOfMemoryAbort（強制終了オプション）」および「-XX:[+|-]HitachiOutOfMemoryHandling（OutOfMemoryハンドリングオプション）」を参照してください。

Metaspace領域の特殊なチューニングの考え方

Metaspace領域の特性を活用したチューニングについて記載します。JDK7までのPermanent領域はオプションで設定した値のメモリを必ず使用していましたが，Metaspace領域はオプションに設定された値のメモリを必ず使用するわけではありません。実際には，実行に必要なサイズのメモリしか使用しません。

(a) Metaspace領域のOutOfMemoryErrorの発生リスクを下げる

見積もり時に想定していなかったMetaspace領域の使用量の増加によって，OutOfMemoryErrorが発生するリスクを下げるためには，見積もり値にバッファを持たせた値を-XX:MaxMetaspaceSizeと-XX:CompressedClassSpaceSizeに設定してください。Metaspace領域の使用量がこの値を超えるまではMetaspace領域のOutOfMemoryErrorは発生しません。

(b) Metaspace領域に起因するFullGCの発生リスクを下げる

見積もり時に想定していなかったMetaspace領域の使用量の増加によって，Metaspace領域に起因するFullGCが発生するリスクを下げるためには，見積もり値にバッファを持たせた値を-XX:MetaspaceSize，-XX:MaxMetaspaceSize，-XX:CompressedClassSpaceSizeに設定してください。Metaspace領域の使用量がこの値を超えるまではMetaspace領域に起因するFullGCは発生しません。

7.2.7　GCの発生とメモリ空間の関係

GCは，メモリ空間の使用状況に応じて発生します。ここでは，GCが発生するタイミングについて説明します。

注意事項

RMIを使ってリモートオブジェクトの登録や参照をすると，定期的にGCが発生することがあります。GCが発生するタイミングは，次のどちらかのプロパティにミリ秒単位で指定できます。デフォルトは3600000ミリ秒（1時間）です。

sun.rmi.dgc.client.gcIntervalプロパティ

sun.rmi.dgc.server.gcIntervalプロパティ

GCが発生するタイミングを変更する場合は，どちらかのプロパティにミリ秒単位で任意の値を指定してください。なお，指定できる値の範囲は，1〜Long.MAX_VALUE-1です。詳細は，該当ページ（http://download.oracle.com/javase/6/docs/technotes/guides/rmi/sunrmiproperties.html）を参照してください。

(1)　CopyGCが発生するタイミング

CopyGCは，次のタイミングで発生します。

Eden領域へのアロケーションで空き領域が不足した場合

jheapprofコマンドに-copygcオプションを指定して実行した場合

(2)　FullGCが発生するタイミング

FullGCは，次のタイミングで発生します。

New領域（Eden領域とSurvivor領域の合計）で使用しているメモリサイズがTenured領域の最大値に対する未使用メモリサイズを上回っている状態の時に，Eden領域へのアロケーションで空き領域が不足した場合

注意事項

上記のタイミングで必ずFullGCが発生するわけではありません。この状況になった場合，JavaVMは，次の値を基にFullGCを発生させるかを決定しています。

過去に発生したCopyGCでNew領域からTenured領域に移動したオブジェクト量に対して，そのCopyGCが発生した時点によって重みを付けて算出した平均値

CopyGCの実施の結果，New領域（Eden領域とSurvivor領域の合計）からTenured領域へのオブジェクトの移動に失敗した場合

New領域とTenured領域のそれぞれの未使用メモリサイズを上回るメモリサイズ（Javaオブジェクトのサイズ）のアロケーション要求があった場合

CopyGCの実施の結果，次のどちらかの状態になった場合

確保済みTenured領域の未使用メモリサイズが10,000バイトを下回った場合

CopyGC実施時のTenured領域へのオブジェクトの移動によって，確保済みTenured領域の拡張が発生した場合

java.lang.System.gc()メソッドが実行された場合

Metaspace領域にアロケーションしたいメモリサイズが確保済みMetaspace領域の未使用メモリサイズを上回る場合

javagcコマンドを実行した場合

jheapprofコマンドを実行した場合

JavaVMのチューニングでは，主に1.と3.の発生を抑えることを検討します。

参考

FullGCが発生した場合の要因は，拡張verbosegc情報を使用して確認できます。FullGC発生時に要因を確認する方法については，「7.10　拡張verbosegc情報を使用したFullGCの要因の分析方法」を参照してください。

7.3　FullGC発生を抑止するためのチューニングの概要

この節では，SerialGC使用時にFullGCの発生を抑止するためのJavaヒープ，およびExplicitヒープのチューニングの考え方，およびチューニング手順について説明します。

Javaヒープ，およびExplicitヒープのチューニング方法の詳細は7.4〜7.14で説明します。

参考

CopyGCの違いによって，チューニング方法が変わることはありません。

7.3.1　チューニングの考え方

一般的に，CopyGCの方が，FullGCよりも短い時間で処理できます。

New領域へのCopyGCの実施によって適切にメモリを回収して，Javaヒープ全体を対象とするFullGCの発生をできるだけ抑止することが，システムの停止回数の削減や，処理性能向上につながります。これを実現するためには，JavaVMオプションでそれぞれのメモリ空間のサイズや割合を適切に設定することが必要です。

また，Tenured領域に配置されるオブジェクトの一部を，明示管理ヒープ機能で管理するExplicitヒープに配置することも，FullGCの発生抑止に効果的です。Explicitヒープは，自動配置設定ファイルや明示管理ヒープAPIを使ってアプリケーションから利用でき，J2EEサーバからも利用されます。明示管理ヒープ機能のデフォルトの設定では，自動解放機能が有効になっています。自動解放機能が有効の場合，JavaVMは，Explicitヒープ領域のメモリを自動的に回収します。Explicitヒープの利用のしかたによっては，自動解放処理が長時間終了しないことがあります。このため，長時間終了しない自動解放処理が発生しないように，明示管理ヒープ機能の適切な利用や，Explicitヒープのメモリサイズの適切なチューニングを実施する必要があります。なお，自動解放処理については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.7　自動解放機能が有効な場合のExplicitメモリブロックの解放」を参照してください。

これらを踏まえ，JavaVMのチューニングは，次の2点を目的として実施します。

FullGCをできるだけ発生させないこと

FullGCの頻発を抑止した上で，不要なCopyGCを発生させないこと

理想的なメモリ使用量と経過時間の関係を次の図に示します。

図7‒8　理想的なメモリ使用量と経過時間の関係

この図の場合は，寿命の短いオブジェクトはすべてCopyGCによって回収できていて，オブジェクトの昇格や退避が発生しません。このため，CopyGC実行後のメモリサイズが一定です。これによって，FullGCが発生しない，安定した状態での運用を実現できます。

JavaVMのチューニングでは，この状態を理想として，JavaVMの使用するメモリ空間の各領域で使用するメモリサイズを見積もってチューニングします。

ポイント

チューニングの目安

図7-8では，FullGCを一度も発生させない理想的な例を示しましたが，現実的にはFullGCが1回発生する間にCopyGCが10〜20回程度発生することを目安にして，チューニングを実施してください。

7.3.2　チューニング手順

FullGCの発生を抑止するためのJavaヒープ，およびExplicitヒープのチューニング手順について説明します。

なお，手順(1)は必ず実施します。手順(2)〜(4)は明示管理ヒープ機能を利用してExplicitヒープを使う場合に，手順(1)のあとに続けて実施します。手順(5)以降については，それぞれの手順の説明を確認の上，必要に応じて実施してください。

Javaヒープ，およびExplicitヒープのチューニング手順を次の図に示します。

図7‒9　JavaヒープおよびExplicitヒープのチューニング手順

(1)　Javaヒープのチューニング

JavaヒープのチューニングによってFullGCを抑止する方法を検討します。Javaヒープのチューニングについては，「7.4　Javaヒープのチューニング」を参照してください。

なお，Explicitヒープ領域を利用しない場合は，Javaヒープのチューニングをした段階でJ2EEサーバのテストを実施してください。Javaヒープのメモリを適切に見積もってもFullGCが頻発する場合は，Survivor領域があふれているなど，チューニングに問題がないか確認してください。再度Javaヒープのチューニングを見直しても問題が発生する場合は，明示管理ヒープ機能を使用したExplicitヒープの利用を検討してください。Explicitヒープを利用する場合は，手順(2)に進んでください。

(2)　Explicitヒープのチューニング

明示管理ヒープ機能を使用してExplicitヒープ領域を利用する場合に，Explicitヒープ領域のメモリを見積もります。Explicitヒープのチューニングについては，「7.11　Explicitヒープのチューニング」を参照してください。

JDK11以前で動作するJ2EEサーバの場合，明示管理ヒープ機能はデフォルトで使用する設定になっています。また，HTTPセッションに関するオブジェクトといったTenured領域のメモリサイズ増加の要因となるオブジェクトが，Explicitヒープに配置されるように設定されています。このため，J2EEサーバが配置するオブジェクトに必要なExplicitヒープのメモリサイズを必ず見積もってください。明示管理ヒープ機能は，Explicitヒープのメモリサイズを適切に見積もった上で使用しないと，効果が出ません。

(3)　稼働情報による見積もり結果の確認

明示管理ヒープ機能を使用する場合に，手順(1)および手順(2)でJavaVMのメモリを適切に見積もったあと，J2EEサーバのテストを実施します。テストで得た稼働情報を収集してExplicitヒープの使用状況を確認します。稼働情報を基にしたExplicitヒープの見積もりについては「7.11.4　稼働情報による見積もり」を参照してください。

参考

J2EEサーバのテストを実施し，FullGCの発生回数が削減できない場合は，次の内容を確認してください。

Survivor領域があふれているなど，Javaヒープのチューニングに問題がないか

手順(1)で見積もった値が適切かを見直します。

Explicitヒープがあふれていないか

手順(2)で見積もった値が適切かを見直します。

Webアプリケーションの構成が適切か

Webアプリケーションの構成（アプリケーション内のAPIの使用方法など）によっては，HTTPセッションに関するオブジェクトに対して，明示管理ヒープ機能の効果が出ない場合があります。詳細は，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.14　明示管理ヒープ機能使用時の注意事項」を参照してください。

JavaヒープおよびExplicitヒープのメモリサイズを見積もりし直しても，明示管理ヒープ機能の効果が出ないような場合に，自動解放処理が長時間化しているようなときは，「付録A　HTTPセッションで利用するExplicitヒープの効率的な利用」を参考にして，アプリケーションの設計を見直してください。Explicitヒープの効率的な利用として，HTTPセッションに関するオブジェクトに対して明示管理ヒープ機能を効率良く適用するためには，アプリケーションの設計でどのような点を考慮すればよいかや，そのためのログの確認方法について説明しています。

これらを確認しても問題が解決しない場合に，手順(4)に進んでください。

(4)　Tenured領域のメモリサイズが増加するかどうかの確認

アプリケーションを開始して，Tenured領域のメモリサイズを調査します。調査には，手順(3)で取得した稼働情報，または拡張verbosegc情報で取得した情報を使用します。拡張verbosegc情報の取得については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「5.7.2　拡張verbosegc情報の取得」を参照してください。

(5)　Tenured領域のメモリサイズ増加の要因となるオブジェクトのExplicitヒープへの配置

手順(3)と(4)で，FullGCの頻発とTenured領域のメモリサイズ増加が確認され，FullGCの抑止が必要となった場合は，Tenured領域のメモリサイズ増加の要因となっているオブジェクトをExplicitヒープに配置することを検討してください。ここで検討対象とするオブジェクトは，「J2EEサーバがデフォルトでExplicitヒープに配置するオブジェクト」ではなく，それ以外の「Javaアプリケーション上で作成しているオブジェクト」です。このオブジェクトをJavaヒープではなくExplicitヒープに配置することで，FullGCの発生回数の削減が期待できます。Tenured領域のメモリサイズ増加の要因となるオブジェクトを特定する方法については，「7.13.2　Tenured領域利用済みサイズの増加原因が不明な場合」を参照してください。

Tenured領域のメモリサイズ増加の要因となるオブジェクトをExplicitヒープに配置する方法には，次の2種類があります。

明示管理ヒープ機能APIの利用

明示管理ヒープ機能の自動配置機能の利用

明示管理ヒープ機能APIの利用方法については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「7.12　明示管理ヒープ機能APIを使ったJavaプログラムの実装」を，明示管理ヒープ機能の自動配置機能の利用方法については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「7.13.2　自動配置設定ファイルを使った明示管理ヒープ機能の使用」を参照してください。

これらの機能を利用してExplicitヒープに新たなオブジェクトを配置すると，Explicitヒープのメモリサイズが増加します。このため，再度，Explicitヒープのメモリサイズの見直しが必要になります。手順(6)に進んでください。

(6)　Explicitヒープ全体のメモリサイズの見直し

手順(5)で修正したアプリケーションを動作させて，J2EEサーバとアプリケーションが使用するExplicitヒープ全体のメモリサイズを見直します。見直し方法については，「7.12　アプリケーションで明示管理ヒープ機能を使用する場合のメモリサイズの見積もり」を参照してください。

ポイント

明示管理ヒープ機能によってFullGCの発生抑止の効果を得るためには，Explicitヒープからオブジェクトがあふれないようにする必要があります。次の点を確認してください。

Webアプリケーション内でセッションの破棄（invalidateメソッド呼び出し）および適切なセッションタイムアウトを設定していること。

適切なメモリサイズのExplicitヒープ領域をJavaヒープ領域とは別に確保できること。

Explicitヒープあふれが発生した場合の確認と対処については，「7.14.3　Explicitヒープあふれが発生した場合の確認と対処」を参照してください。

以降では，Javaヒープのチューニング，およびExplicitヒープのチューニングについて説明します。なお，これ以外の注意事項については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.　明示管理ヒープ機能を使用したFullGCの抑止」を参照してください。

7.4　Javaヒープのチューニング

ここでは，SerialGC使用時のJavaヒープのチューニングについて説明します。

7.4.1　Javaヒープのメモリサイズの見積もり

JavaVMのチューニングでは，JavaVM固有領域の各領域のメモリサイズを適切に見積もる必要があります。

見積もりのポイントになるメモリサイズは次のとおりです。

Javaヒープ全体のメモリサイズ

Tenured領域のメモリサイズ

Survivor領域のメモリサイズ

Eden領域のメモリサイズ

このほか，Metaspace領域も，必要に応じて見積もります。

CopyGC後の生存オブジェクトのサイズがSurvivor領域のサイズよりも大きい場合，Survivor領域があふれ，1度のCopyGCの実行でTenured領域に昇格するオブジェクトが発生します。また，Survivor領域のサイズが小さい場合に，Survivor領域の使用率が上がってくると，本来短寿命（CopyGC間隔以下，またはCopyGC間隔の1〜2倍程度の寿命）のJavaオブジェクトが，数回のCopyGCの実行でTenured領域に昇格してしまいます。

ポイント

次に示す問題が確認できた場合は，Survivor領域の不足が原因でFullGCが発生しています。なお，拡張verbosegc情報とは，J2EEサーバ起動時にオプションを設定しておくと，GC発生時にJavaVMログファイルに出力される情報です。

Tenured領域の増加要因が短寿命オブジェクトであると特定された場合

拡張verbosegc情報で，CopyGC時のSurvivor領域あふれが確認できた場合

-XX:+HitachiVerboseGCPrintTenuringDistribution指定時に出力される拡張verbosegc情報で，オブジェクトの昇格年齢が常に１であることが観測できた場合

これらの問題を回避するためには，-XX:SurvivorRatioオプションの設定値を小さくして，Eden領域とSurvivor領域の割合を最適化する必要があります。

このことを考慮し，見積もりでは，まず，Tenured領域のメモリサイズとNew領域のメモリサイズを算出して，それらを基にJavaヒープ全体のメモリサイズを算出します。

メモリサイズを見積もる順序を次の図に示します。図中の番号の順番で見積もりを実施します。

図7‒10　メモリサイズを見積もる順序

見積もり手順を示します。なお，番号は図中の番号と対応しています。

Tenured領域で使用するメモリサイズを見積もります。

見積もり方法については，「7.5　Javaヒープ内のTenured領域のメモリサイズの見積もり」を参照してください。

Survivor領域で使用するメモリサイズを見積もります。

見積もり方法については，「7.6.1　Javaヒープ内のSurvivor領域のメモリサイズの見積もり」を参照してください。

Eden領域で使用するメモリサイズを見積もります。

見積もり方法については，「7.6.2　Javaヒープ内のEden領域のメモリサイズの見積もり」を参照してください。

2.と3.の合計として，New領域全体のメモリサイズを算出します。

一定期間存在するオブジェクトの扱いを検討して，必要なメモリサイズをTenured領域またはNew領域のメモリサイズに追加します。

検討方法については，「7.7　Javaヒープ内に一定期間存在するオブジェクトの扱いの検討」を参照してください。

1.，4.および5.の合計として，Javaヒープ全体のメモリサイズを算出します。

必要に応じてMetaspace領域のメモリサイズを見積もります。

見積もり方法については，「7.9　Javaヒープ内のMetaspace領域のメモリサイズの見積もり」を参照してください。

7.4.2　Javaヒープのメモリサイズの設定方法

見積もったメモリサイズは，「7.2.6　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」で説明したオプションで指定します。それぞれの領域のメモリサイズの設定方法を次に示します。

Javaヒープ全体のメモリサイズ

-Xmx<size>オプションで最大サイズを指定して，-Xms<size>オプションで初期サイズを指定します。

Tenured領域のメモリサイズ

-XX:NewRatio=<value>オプションで，Javaヒープ全体に対する，Tenured領域とNew領域の分割比を指定します。例えば，「-XX:NewRatio=5」とした場合には，-Xmx<size>オプションで指定したメモリサイズが，次のように分割されます。

New領域のメモリサイズ：Tenured領域のメモリサイズ = 1：5

Survivor領域のメモリサイズとEden領域のメモリサイズ

-XX:SurvivorRatio=<value>オプションで，New領域全体に対する，Survivor領域とEden領域の分割比を指定します。なお，分割比は，Survivor領域のFrom空間およびTo空間に対してEden領域を何倍確保するかの数値で指定します。例えば，「-XX:SurvivorRatio=2」とした場合には，-XX:NewRatio=<value>オプションで決まったNew領域のメモリサイズが，次のように分割されます。

Eden領域のメモリサイズ：From空間のメモリサイズ：To空間のメモリサイズ = 2：1：1

Metaspace領域のメモリサイズ

-XX:MaxMetaspaceSize=<size>オプションで最大サイズを指定して，-XX:MetaspaceSize=<size>オプションで初期サイズを指定します。

7.4.3　Javaヒープのメモリサイズの使用状況の確認方法

それぞれのメモリサイズは，アプリケーションを実際に動作させて，メモリ使用量を測定しながらチューニングしていきます。アプリケーションサーバでは，usrconf.cfgファイルに-XX:+HitachiVerboseGCオプションを指定してJ2EEサーバを起動することで，GC実行時の各領域の詳細なメモリサイズを拡張verbosegc情報として出力できます。この出力内容を基にチューニングを実施してください。

拡張verbosegc情報として出力できる主な内容を次に示します。

GCの発生日時

GC種別

GC情報※1

GC経過時間

Eden情報※1

Survivor情報※1

Tenured情報※1

Metaspace領域情報※1

GC要因内容※２

注※1

GC前後の使用領域長および領域サイズが出力されます。

注※2

-XX:+HitachiVerboseGCPrintCauseオプションが指定されている場合に出力されます。

拡張verbosegc情報の出力例とFullGCの要因分析方法については，「7.10　拡張verbosegc情報を使用したFullGCの要因の分析方法」を参照してください。また，オプションについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

なお，アプリケーションサーバでは，javagcコマンドを使用して，任意のタイミングでFullGCを発生させることもできます。この場合，-vオプションを指定することで，拡張verbosegc情報と同じ内容を出力できます。javagcコマンドの詳細については，マニュアル「アプリケーションサーバリファレンス コマンド編」の「javagc（GCの強制発生）」を参照してください。

7.5　Javaヒープ内のTenured領域のメモリサイズの見積もり

この節では，SerialGC使用時のTenured領域のメモリサイズの見積もりについて説明します。

Tenured領域のメモリサイズは，次のように見積もります。

Tenured領域のメモリサイズ
=アプリケーションで必要なメモリサイズ+New領域のメモリサイズ

ここでは，アプリケーションで必要なメモリサイズの算出方法について説明します。

また，見積もったメモリサイズにNew領域のメモリサイズを追加する理由についても説明します。

7.5.1　アプリケーションで必要なメモリサイズの算出

Tenured領域のメモリサイズは，アプリケーションが最低限必要とするメモリサイズから見積もります。必要なメモリサイズが確保できない場合，OutOfMemoryErrorが発生してJavaVMが停止します。

アプリケーションが必要とするメモリサイズは，FullGC実行時の拡張verbosegc情報で，FullGC実行後に使用しているメモリサイズを確認することで判断できます。これは，FullGC実行後にJavaヒープ全体から不要なオブジェクトをすべて削除した状態のメモリサイズが，アプリケーションが必要とするメモリサイズに近いと考えられるためです。

FullGC実行時の拡張verbosegc情報の出力例を次に示します。

…
[VGC]<Wed May 11 23:12:05 2005>[Full GC 31780K->30780K(32704K), 0.2070500secs][DefNew::Eden: 3440K->1602K(3456K)][DefNew::Survivor:58K->0K(64K)][Tenured: 28282K->29178K(29184K)][Metaspace:3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

「Full GC」に続いて出力されている情報のうち，GCの実行後の情報「->30780K」を確認します。ここでは，FullGC実行後に，30,780キロバイトのメモリサイズを必要としていることがわかります。

何回分かのFullGCの拡張verbosegc情報を集め，GC実行後の領域長がいちばん大きい情報を，アプリケーションが必要とするメモリサイズであると判断してください。

7.5.2　Javaヒープ内のNew領域のメモリサイズを追加する理由

Tenured領域のメモリサイズには，アプリケーションが最低限必要とするメモリサイズに，New領域分のメモリサイズを追加することをお勧めします。これは，Tenured領域の未使用メモリサイズがNew領域の使用メモリサイズを下回ることによって，FullGCが頻発するのを防ぐためです。

通常，Eden領域がいっぱいになると，CopyGCが発生します。このとき，Eden領域とSurvivor領域のFrom空間に存在する使用中のJavaオブジェクトが，Survivor領域のTo空間に移動しようとします。このとき，Tenured領域の未使用領域がEden領域とSurvivor領域で使用中のメモリサイズよりも小さいと，New領域のすべてのJavaオブジェクトが昇格した場合に，JavaオブジェクトをTenured領域に移動できなくなります。そこでJavaVMは，FullGCを発生させ，Tenured領域の未使用メモリサイズを増やそうとします。

これを防ぐために，Tenured領域には，アプリケーションが必要とするメモリサイズに加えて，New領域分のメモリサイズを追加してください。

考え方を次の図に示します。

図7‒11　New領域のメモリサイズを追加する理由の考え方

オブジェクトが昇格できないおそれがあるためFullGCが発生する例

Tenured領域のメモリの空き領域（アプリケーションで必要なメモリ領域以外の領域）がNew領域のメモリサイズよりも小さいため，Eden領域およびFrom空間からの移動オブジェクトが多い場合，オブジェクトの昇格に対応できないおそれがあります。この場合，FullGCが発生します。

オブジェクトが確実に昇格できる例

Tenured領域のメモリの空き領域（アプリケーションで必要なメモリ領域以外の領域）がNew領域と同じサイズ分確保してあるため，Eden領域およびFrom空間からの移動オブジェクトが多い場合も，オブジェクトの昇格に対応できます。

なお，New領域のメモリサイズの見積もりについては，「7.6　Javaヒープ内のNew領域のメモリサイズの見積もり」で説明します。

ポイント

拡張verbosegc情報などで確認したときに，CopyGCが発生しないでFullGCが頻発している場合，New領域からの退避オブジェクトに対してTenured領域のメモリサイズが小さいことが考えられます。New領域のサイズを増やした場合などにこの状態になることがあります。必要に応じて，Tenured領域のメモリサイズを見直してください。また，New領域内のEden領域とSurvivor領域の関係もあわせて見直してください。

7.6　Javaヒープ内のNew領域のメモリサイズの見積もり

この節では，SerialGC使用時のNew領域のメモリサイズの見積もりについて説明します。

New領域のメモリサイズは，次のように見積もります。

New領域のメモリサイズ
=Survivor領域のメモリサイズ+Eden領域のメモリサイズ

ここでは，Survivor領域およびEden領域のメモリサイズを見積もる方法について説明します。

7.6.1　Javaヒープ内のSurvivor領域のメモリサイズの見積もり

Survivor領域のメモリサイズは，実際にアプリケーションを動作させて，Survivor領域の使用状況を確認しながらチューニングしていきます。

チューニングの流れを次に示します。

アプリケーションでのリクエスト／レスポンス処理に使用するメモリサイズを見積もり，それをSurvivor領域のメモリサイズに指定して，アプリケーションを実行します。

このとき，チューニングで使用する情報を出力するために，-XX:+HitachiVerboseGCPrintTenuringDistributionオプションを指定してJ2EEサーバを起動します。

Survivor領域に割り当てられているメモリサイズと，アプリケーション実行時に実際に使用されているメモリ使用量から，メモリ使用率を確認します。

メモリ使用率が100%に近い場合，CopyGC実行時にNew領域およびSurvivor領域のFrom空間の使用中のオブジェクトがTo空間に入り切らなくなり，オブジェクトの退避が発生します。この場合は，Survivor領域を増やすことを検討してください。

Survivor領域のオブジェクトの年齢分布を確認します。

Survivor領域のメモリサイズを増やしたり，昇格するためのしきい値を上げたりすることで，オブジェクトが昇格するのが遅くなります。寿命の長いオブジェクトをSurvivor領域に格納し続けるのは，性能を低下させる要因になります。

逆に，Survivor領域のメモリサイズを減らしたり，昇格するためのしきい値を下げたりすることで，オブジェクトが昇格するのが早くなります。ただし，寿命の短いオブジェクトが昇格するのは，FullGCの発生頻度を増やす要因になります。

Survivor領域のメモリサイズと昇格のしきい値は，この二つのバランスを取るように検討してください。

それぞれのチューニング作業について説明します。

(1)　リクエスト／レスポンス処理に使用するメモリサイズの見積もり

Survivor領域は，寿命の短いオブジェクトを格納する領域です。サーバサイドで動作するアプリケーションの場合，リクエストやレスポンスを処理するために使われている，寿命の短いオブジェクトを格納する領域と考えることができます。このため，Survivor領域のメモリサイズの見積もりでは，ある時点で存在する寿命が短いオブジェクトの最大サイズ，つまり，ある時点でのリクエストやレスポンスの処理に使用するメモリの最大サイズを考えます。例えば，ステートレスなサーブレットで構成されたアプリケーションの場合，Survivor領域のメモリサイズを，「一つのリクエスト処理で使用する最大メモリサイズ×リクエストの同時実行数」と考えることができます。

(2)　メモリ使用率の確認

「7.6.1(1)　リクエスト／レスポンス処理に使用するメモリサイズの見積もり」で見積もった値をSurvivor領域のメモリサイズとして設定して，アプリケーションを実行します。実行時に使用されるメモリ使用量から，Survivor領域に割り当てたメモリサイズに対するメモリ使用率を確認します。

参考

Survivor領域のメモリサイズは，直接は指定できません。

Survivor領域のメモリサイズを指定する場合は，まず，-XmxオプションでJavaヒープの最大サイズを指定して，-XX:NewRatio=<value>によってJavaヒープのメモリサイズをNew領域とTenured領域で分ける割合を指定した上で，-XX:SurvivorRatio=<value>オプションによって，New領域に対するSurvivor領域の割合を指定する必要があります。

メモリ使用率は，拡張verbosegc情報で確認できます。

CopyGC実行時の拡張verbosegc情報の出力例を次に示します。

…
[VGC]<Wed May 11 23:12:05 2005>[GC 27340K->27340K(32704K), 0.0432900 secs][DefNew::Eden: 3440K->0K(3456K)][DefNew::Survivor: 58K->64K(64K)][Tenured: 23841K->27282K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

「DefNew::Survivor: 58K->64K(64K)」は，「GC実行前のメモリサイズ->GC実行後のメモリサイズ（割り当てられているメモリサイズ）」を意味します。この場合，64キロバイトのSurvivor領域中64キロバイトがすでに使用されていて，使用率は100%になります。これは，CopyGCで，To空間のメモリサイズが不足し，Javaオブジェクトの退避が行われたことを示しています。退避では，Tenured領域に本来格納されないはずの寿命の短いオブジェクトが格納され，FullGCの発生頻度を増やす要因になります。このような場合は，Survivor領域のメモリサイズを増やすことを検討してください。新しいSurvivor領域のメモリサイズは次のように見積もります。

新しいSurvivor領域のメモリサイズ
=現在のSurvivor領域のメモリサイズ+退避されたJavaオブジェクトの合計サイズ

「退避されたJavaオブジェクトの合計サイズ」は，GC実行後のTenured領域メモリの増加サイズで近似できます。この例では，「Tenured: 23841K->27282K(29184K)」が，Tenured領域メモリの増加サイズを示していて，27,282キロバイト-23,841キロバイト=3,441キロバイトとなります。

また，Survivor領域のメモリサイズを増加させると，Javaオブジェクトの昇格のしきい値が上がり，昇格しにくくなります。詳細については，「7.6.1(3)　オブジェクトの年齢分布の確認と見積もり」を参照してください。その結果，CopyGCで回収されないJavaオブジェクトが増えることがあるため，-XX:TargetSurvivorRatio=<value>を次のように見積もり，設定してください。

新しい-XX:TargetSurvivorRatio=<value>
=現在の-XX:TargetSurvivorRatio=<value>×(現在のSurvivor領域のメモリサイズ/新しいSurvivor領域のメモリサイズ)

(3)　オブジェクトの年齢分布の確認と見積もり

Survivor領域のオブジェクトの年齢分布を確認し，寿命の長いオブジェクトが存在し続けていないか，または寿命の短いオブジェクトが昇格していないかを確認します。オブジェクトの年齢分布は，-XX:+HitachiVerboseGCPrintTenuringDistributionオプションの出力結果で確認できます。

J2EEサーバ起動時にusrconf.cfgに-XX:+HitachiVerboseGCPrintTenuringDistributionオプションを指定すると，Survivor領域の使用状況がCopyGC発生のタイミングでJavaVMログファイルに出力されます。出力例を次に示します。

[PTD]<Wed May 28 11:45:23 2008>[Desired survivor:5467547 bytes][New  threshold:3][MaxTenuringThreshold:31][age1:1357527][age2:1539661]

「New threshold:」に続けて出力されているのが，次のCopyGCで昇格するJavaオブジェクトの最低の年齢です。例の場合は，次回のCopyGCで，年齢が3歳以上のJavaオブジェクトが昇格します。「age<数値>:」に続けて出力されているのが，Survivor領域で1歳からその年齢までのJavaオブジェクトが使用しているメモリサイズの累計です。例の場合は，1歳のJavaオブジェクトのメモリサイズが1,357,527バイト，1歳と2歳のJavaオブジェクトのメモリサイズの累計が1,539,661バイトであることを示しています。また，累計から逆算することで，2歳のJavaオブジェクトのメモリサイズが182,134(1,539,661-1,357,527)バイトであることがわかります。一般的に，Survivor領域のオブジェクトの年齢分布は次に示すグラフのようになります。

図7‒12　Survivor領域のオブジェクトの年齢分布

グラフの「サイズ」は，ある「年齢」のJavaオブジェクトの合計のサイズです。また，「累計サイズ」は，ある「年齢」までのJavaオブジェクトの合計のサイズです。

このグラフでは，Survivor領域のJavaオブジェクトが占めるサイズが，年齢が上がるに連れて減少しています。また，１歳年齢が上がったときに減少するサイズは年齢が若いほど大きくなります。このことから，次のことがわかります。

若い年齢のJavaオブジェクトほど，Survivor領域中に占めるサイズが大きい

若い年齢のJavaオブジェクトほど，GCで回収されやすい

この例では，6歳以上のJavaオブジェクトはほとんどCopyGCで回収されていません。そのため，Javaオブジェクトの昇格のしきい値が7歳以上の場合，回収される可能性が低いJavaオブジェクトに対してCopyGCを行うことになり，性能を低下させる要因になります。逆に，Javaオブジェクトの昇格のしきい値が2歳以下の場合，CopyGCで回収される可能性の高いオブジェクトが昇格することになり，FullGCの発生が増す要因になります。この例では，昇格のしきい値を5〜6歳程度とするのが，バランスの取れたしきい値となります。

グラフの傾きはシステムによって異なるため，Survivor領域のオブジェクトの年齢分布を確認し，システムごとの最適な昇格年齢を決定することが重要です。

参考

Javaオブジェクトの昇格のしきい値は，CopyGCごとに動的に変更され，-XX:MaxTenuringThreshold=<value>オプションと，Survivor領域のメモリサイズおよび-XX:TargetSurvivorRatio=<value>オプションに設定した値を基に決まります。-XX:MaxTenuringThreshold=<value>は，昇格のしきい値の最大の年齢です。Javaオブジェクトの年齢がこの値を超えると，必ず昇格します。-XX:TargetSurvivorRatio=<value>は，Survivor領域のメモリ使用率の目標値です。JavaVMは，Survivor領域のメモリ使用率が，できるだけこの値に近くなるように，昇格のしきい値を決定します。具体的には，CopyGCが終了した時の1歳からn歳までのJavaオブジェクトの累計サイズが，目標の使用率となるnを探し，次のCopyGCの昇格のしきい値をnにします。-XX:TargetSurvivorRatio=<value>のデフォルト値は50%です。Survivor領域のメモリ使用率が大きいほどSurvivor領域を有効に利用できますが，Survivor領域の空きに余裕がなくなるため，オブジェクトの退避が発生しやすくなります。

7.6.2　Javaヒープ内のEden領域のメモリサイズの見積もり

Eden領域のメモリサイズは，CopyGCを発生させる間隔に影響します。Eden領域のメモリサイズを大きく取ると，CopyGCの発生間隔が長くなります。なお，CopyGCに掛かる時間は，使用中のオブジェクトの個数に影響され，Eden領域のメモリサイズにはあまり影響されません。このため，CopyGCが頻発しないように，Eden領域のメモリサイズを十分に確保することが，性能向上には効果的です。

7.7　Javaヒープ内に一定期間存在するオブジェクトの扱いの検討

これまでの説明は，オブジェクトの寿命に応じて，それぞれの領域に次のように格納することを前提としてきました。

アプリケーションの動作に必要な寿命の長いオブジェクトは，Tenured領域に格納する。

リクエスト処理やレスポンス処理などの寿命の短いオブジェクトは，New領域に格納する。

しかし，寿命が中間的な一定期間使用されるオブジェクトがあります。このようなオブジェクトは，寿命は長くありませんが，何回かのCopyGCの対象になります。

メモリサイズの見積もりでは，これらのオブジェクトを，New領域，Tenured領域のどちらかに格納することを前提として，見積もりをする必要があります。

ここでは，それぞれの特徴を示します。アプリケーションの種類や目的に応じて，どちらかのメモリサイズを増加させるように見積もりをしてください。

7.7.1　Javaヒープ内のNew領域に格納する方法

一定期間存在するオブジェクトをNew領域で管理する方法です。New領域のメモリサイズに，これらの一定期間存在するオブジェクト分のメモリサイズを追加して見積もります。

New領域サイズを大きくしてオブジェクトのTenured領域への移動を抑止することによって，FullGCの発生も抑止できます。ただし，CopyGC実行時にNew領域内にある使用中のオブジェクトの数が増えるため，New領域内でのコピー処理に時間が掛かり，1回当たりのCopyGC実行時間は長くなります。CopyGCの実行時間がFullGC実行時間よりも長くなるような場合は，メモリサイズの再見積もりが必要です。また，メモリ空間のサイズ設定によっては，本来CopyGCで回収されるはずの寿命の短いオブジェクトが使用する領域が不足して，Tenured領域への退避が発生するおそれがあります。この場合は，最終的にはFullGCが発生してしまいます。

なお，一定期間存在するオブジェクトをNew領域で管理できているかどうかは，拡張verbosegc情報で確認できます。実際にアプリケーションを動作させて，出力された拡張verbosegc情報で，CopyGC発生後のTenured領域のメモリサイズが大幅に増えていないことを確認してください。

New領域での管理に失敗している場合，システムの処理性能が大幅に低下していることがあります。また，New領域で管理できるオブジェクトの最大の年齢には限界があります（限界はプラットフォームやバージョンによって異なります。詳細は，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「14.4　Application Serverで指定できるJava HotSpot VMのオプションのデフォルト値」の-XX:MaxTenuringThreshold=<value>を参照してください）。New領域で管理できていないことがわかった場合は，一定期間存在するオブジェクトは，Tenured領域に格納して管理することを検討してください。Tenured領域で管理する方法については，「7.7.2　Javaヒープ内のTenured領域に格納する方法」を参照してください。

7.7.2　Javaヒープ内のTenured領域に格納する方法

New領域で管理するオブジェクトの最大の年齢は，-XX:MaxTenuringThreshold=<value>オプションで指定できます。例えば，「-XX:MaxTenuringThreshold=2」を指定しておけば，3回目のCopyGCの対象になったオブジェクトは，すべてTenured領域に移動します。

この方法を使用すると，CopyGCの対象になるオブジェクトが少なくなり，実行時間が短縮できます。ただし，多くのオブジェクトがTenured領域に移動するため，Tenured領域がいっぱいになった段階でFullGCが定期的に発生します。システムを安定して動作させるためには，システムに掛かる負荷が低いときなどに，FullGCを強制的に発生させてください。FullGCを強制的に発生させるには，次の方法があります。

プログラム内でSystem.gc()メソッドを呼び出す

javagcコマンドを実行する

javagcコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「javagc（GCの強制発生）」を参照してください。

7.7.3　Explicitヒープに格納する方法

チューニングではありませんが，Javaプログラムを変更することで，一定期間存在するオブジェクトをExplicitヒープに格納して管理する方法があります。ExplicitヒープはGCの対象とならない領域です。Explicitヒープを利用することで，オブジェクトがTenured領域に移動することを防ぎ，FullGCの発生を抑えることができます。また，自動配置設定ファイルを利用することで，Explicitヒープに直接オブジェクトを配置することもできます。詳細は，「7.11　Explicitヒープのチューニング」を参照してください。アプリケーションサーバでは，HTTPセッションに関連するオブジェクトをExplicitヒープで管理しています。

7.8　Javaヒープの最大サイズ／初期サイズの決定

Tenured領域およびNew領域の見積もりができたら，それらを基にJavaヒープの最大サイズと初期サイズを決定します。

Javaヒープの最大サイズは，次のように決定します。

Javaヒープの最大サイズ
=Tenured領域のメモリサイズ+New領域のメモリサイズ

Javaヒープのメモリサイズを設定する場合，まず，-Xmxオプションに，拡張領域のサイズも含む，Javaヒープ領域の最大サイズを指定します。次に，-Xmsオプションに，Javaヒープ領域の初期サイズを指定します。なお，-Xmsオプションに指定するサイズは，-Xmxオプションに指定したサイズよりも小さくする必要があります。

JavaVMは，起動時に，-Xmsオプションで指定された分のメモリ領域をJavaヒープ領域として確保します。その後，アプリケーション実行中に-Xmsオプションで指定した以上のメモリ領域が必要になった場合に，-Xmxオプションで指定したサイズになるまで，ヒープ領域を追加して割り当てていきます。逆に，アプリケーションの中で不要なメモリ領域が発生した場合は，-Xmsオプションで指定したサイズまで，Javaヒープ領域として確保している領域を減らしていきます。

なお，システムの安定稼働のためには，-Xmxオプションと-Xmsオプションには同じ値を指定することをお勧めします。

7.9　Javaヒープ内のMetaspace領域のメモリサイズの見積もり

この節では，SerialGC使用時のMetaspace領域のメモリサイズの見積もりについて説明します。Metaspace領域は，ロードされたclassなどが格納される領域です。

Metaspace領域のメモリサイズは，「7.2.6　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」で示したとおり，-Xmxオプションで指定したメモリサイズ（Javaヒープ）とは別に確保されます。

デフォルト値については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.4　Application Serverで指定できるJava HotSpot VMのオプションのデフォルト値」を参照してください。

次に，Metaspace領域の使用量の見積もり方法を示します。

Metaspace領域の使用量の見積もり方法

Metaspace領域でのメモリ使用量は，大体，J2EEサーバにロードされるクラスファイルの合計サイズになります。アプリケーションサーバの場合，次に示すクラスファイルのサイズの総和から見積もることができます。

WEB-INF/classes以下のすべてのクラスファイル

WEB-INF/lib以下のJARファイルに含まれる，すべてのクラスファイル

JSPコンパイル結果として生成された，すべてのクラスファイル

EJB-JARに含まれるすべてのクラスファイル

コンテナ拡張ライブラリ，ライブラリJAR，参照ライブラリを利用している場合に追加するJARファイルに含まれる，すべてのクラスファイル

コンテナが作成するクラスファイル

アプリケーション開始後のMetaspace領域−アプリケーション登録前のMetaspace領域。実際にJ2EEサーバを起動し，Metaspace領域を確認して算出してください。

アプリケーションサーバ提供のクラスファイル（システムクラスファイル）

システムクラスファイルの総和は約160メガバイトになります。

JDK提供のクラスファイル

JDK提供のクラスファイルの総和は約110メガバイトになります。

リフレクション処理が生成する動的クラス

リフレクション処理では処理の高速化のため，呼び出し用のクラスを動的に生成します。

このクラスが占めるサイズについてはサーバ起動から十分な時間経過するまでの間に増加したMetaspace利用サイズを目安として実測で求めてください。

Metaspace領域のメモリサイズは，-XX:MaxMetaspaceSize=<size>オプション，および-XX:MetaspaceSize=<size>オプションで指定します。これらのオプションのデフォルト値については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「14.4　Application Serverで指定できるJava HotSpot VMのオプションのデフォルト値」を参照してください。

なお，アプリケーションのインポート時に一時的にMetaspace領域の使用量が増加する場合があります。

参考

開発環境でのソフト参照によるMetaspace領域の圧迫の解消方法

ソフト参照の影響によって，アプリケーションをアンデプロイしたときにMetaspace領域の解放が遅延することがあります。このため，開発環境などでアプリケーションのデプロイおよびアンデプロイを繰り返した場合，Metaspace領域の解放遅延が原因で，Metaspace領域が圧迫されることがあります。ソフト参照によるMetaspace領域の圧迫は，次のオプションを指定すると解消できます。

-XX:SoftRefLRUPolicyMSPerMB=0

-XX:SoftRefLRUPolicyMSPerMBオプションに0を指定すると，すべてのソフト参照が無効になります。ソフト参照は，性能向上のためのキャッシュとして使用されることが多いため，このオプションの指定によってアプリケーションの性能が劣化するおそれがあります。このため，このオプションは，開発環境でMetaspace領域が圧迫された場合にだけ指定してください。

7.10　拡張verbosegc情報を使用したFullGCの要因の分析方法

この節では，SerialGC使用時の拡張verbosegc情報を使用したFullGCの要因の分析方法について説明します。拡張verbosegc情報は，JavaVMオプションである-XX:+HitachiVerboseGCオプションを指定することによって出力できるJavaVMのログ情報です。チューニングに役立つ情報のほか，障害要因の分析にも役立つ情報が出力されます。

チューニング実行時に拡張verbosegc情報を参照することで，次の情報を確認できます。

GC実行前と実行後の各領域の使用メモリサイズ

GCが発生した要因

また，-XX:+HitachiVerboseGCとほかのJavaVMオプションを組み合わせることによって，さらに詳細な情報が出力できます。-XX:+HitachiVerboseGCオプション，およびそのほかのJavaVM拡張オプションの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「14.2　JavaVM拡張オプションの詳細」を参照してください。

7.10.1　拡張verbosegc情報の出力形式の概要

拡張verbosegc情報は，CopyGCが発生した場合と，FullGCが発生した場合に出力されます。

CopyGCが発生すると，GCの種類として「GC」と出力されます。また，FullGCが発生すると，GCの種類として「Full GC」と出力されます。種類に続いて，それぞれの領域の「＜GC前の領域長＞->＜GC後の領域長＞（＜確保済み領域サイズ＞）」が出力されます。

以降に，FullGCが発生した場合の拡張verbosegc情報の出力例を示します。拡張verbosegc情報には，ほかにもGCの発生要因やGCスレッドのCPU時間も出力されます。

拡張verbosegc情報の出力形式の詳細，およびそれぞれのオプションの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.　JavaVM起動オプション」を参照してください。

7.10.2　FullGC発生時の拡張verbosegc情報の出力例

ここでは，FullGCの発生時の拡張verbosegc情報の出力例を示します。

(1)　New領域（Eden領域とSurvivor領域の合計）で使用しているメモリサイズがTenured領域の最大値に対する未使用メモリサイズを上回った場合

拡張verbosegc情報の出力例を次に示します。背景色付きの太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Wed May 11 23:12:05 2005>[GC 27340K->27340K(32704K), 0.0432900 secs][DefNew::Eden: 3440K->0K(3456K)][DefNew::Survivor: 58K->58K(64K)][Tenured: 23841K->27282K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
[VGC]<Wed May 11 23:12:05 2005>[Full GC 30780K->30780K(32704K), 0.2070500 secs][DefNew::Eden: 3440K->1602K(3456K)][DefNew::Survivor: 58K->0K(64K)][Tenured: 27282K->29178K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

New領域で使用しているメモリサイズ（3440K+58K=3498K）が，Tenured領域の最大値に対する未使用メモリサイズ（29184K-27282K=1902K）を上回りました。

FullGCの要因は，オブジェクトの割り付け失敗です。

(2)　CopyGCの実施の結果，New領域（Eden領域とSurvivor領域の合計）からTenured領域へのオブジェクトの移動に失敗した場合

拡張verbosegc情報の出力例を次に示します。背景色付きの太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Thu Oct 20 11:04:42 2011>[GC 26418K->26418K (29696K), 0.0000000 secs][DefNew::Eden:8188K->8188K(8192K)][DefNew::Survivor: 1021K->1021K(1024K)][Tenured:17208K->17208K (20480K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0000000 secs][Sys: 0.0000000 secs][IM: 877K, 1104K, 0K][TC: 9][DOE: 0K, 0]
[VGC]<Thu Oct 20 11:04:42 2011>[Full GC 26418K->6450K(29696K), 0.0156250 secs][DefNew::Eden:8188K->0K(8192K)][DefNew::Survivor:1021K->0K(1024K)][Tenured:17208K->6450K(20480K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:PromotionFail][User: 0.0156250 secs][Sys: 0.0000000 secs][IM: 925K, 1104K, 0K][TC: 9][DOE: 0K, 0]

この出力例からは，次のことがわかります。

FullGCの要因は，CopyGCによる，New領域からTenured領域へのオブジェクトの移動の失敗です。

(3)　アロケーションしたいメモリサイズ（newで作成するJavaオブジェクトのサイズ）がTenured領域の未使用メモリサイズを上回る場合

拡張verbosegc情報の出力例を次に示します。背景色付きの太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Wed May 11 23:53:18 2005>[GC 28499K->28490K(32704K), 0.0540590 secs][DefNew::Eden: 808K->0K(3456K)][DefNew::Survivor: 64K->62K(64K)][Tenured: 27626K->28428K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
[VGC]<Wed May 11 23:53:18 2005>[Full GC 28490K->8959K(32704K), 0.1510380 secs][DefNew::Eden: 0K->0K(3456K)][DefNew::Survivor: 62K->0K(64K)][Tenured: 28428K->8959K(29184K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

Tenured領域の未使用メモリサイズ（29184K-28428K=756K）を上回るメモリサイズのJavaオブジェクトを，newで作成しようとしました。

FullGCの要因は，オブジェクトの割り付け失敗です。

(4)　CopyGC実施の結果，確保済みTenured領域の未使用メモリサイズが10,000バイトを下回った場合

拡張verbosegc情報の出力例を次に示します。背景色付きの太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Fri May 25 15:21:33 2007>[GC 15436K->15416K(19840K), 0.0111825 secs][DefNew::Eden: 4413K->0K(4416K)][DefNew::Survivor: 512K->509K(512K)][Tenured: 10511K->14906K(14912K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0000000 secs][Sys: 0.0000000 secs]
[VGC]<Fri May 25 15:21:33 2007>[Full GC 15416K->8622K(19840K), 0.0284614 secs][DefNew::Eden: 0K->0K(4416K)][DefNew::Survivor: 509K->0K(512K)][Tenured: 14906K->8622K(14912K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0312500 secs][Sys: 0.0000000 secs]
…

この出力例からは，次のことがわかります。

1行目のCopyGCでNew領域からTenured領域にオブジェクトが移動したことによって，Tenured領域の使用済みメモリサイズが10,511キロバイトから14,906キロバイトに増加しました。これによって，確保済みTenured領域の未使用メモリサイズが14,912キロバイト-14,906キロバイト=6キロバイトとなり，10,000バイト（約10キロバイト）を下回りました。

1行目のCopyGCの原因は，オブジェクトの割り付け失敗です。1行目のCopyGCと2行目のFullGCは，Javaプログラムに制御が戻る前に連続して発生します。

(5)　CopyGC実施時のTenured領域へのオブジェクトの移動によって，確保済みTenured領域の拡張が発生した場合

拡張verbosegc情報の出力例を次に示します。背景色付きの太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Fri May 25 15:42:00 2007>[GC 12745K->10151K(15872K), 0.0048346 secs][DefNew::Eden: 4416K->0K(4416K)][DefNew::Survivor: 137K->512K(512K)][Tenured: 8192K->9639K(10944K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0000000 secs]
[VGC]<Fri May 25 15:42:00 2007>[GC 14563K->14536K(19072K), 0.0104957 secs][DefNew::Eden: 4412K->0K(4416K)][DefNew::Survivor: 512K->510K(512K)][Tenured: 9639K->14026K(14144K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0000000 secs]
[VGC]<Fri May 25 15:42:00 2007>[Full GC 14536K->8610K(19072K), 0.0287254 secs][DefNew::Eden: 0K->0K(4416K)][DefNew::Survivor: 510K->0K(512K)][Tenured: 14026K->8610K(14144K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][User: 0.0312500 secs][Sys: 0.0000000 secs]
…

この出力例からは，次のことがわかります。

2行目のCopyGCでNew領域からTenured領域へのオブジェクトが移動したことによって，Tenured領域が最低でも14,026キロバイト以上必要になりました。このため，確保済みTenured領域サイズが10,944キロバイトから14,144キロバイトに拡張されました。

2行目のCopyGCの原因は，オブジェクトの割り付け失敗です。2行目のCopyGCと3行目のFullGCは，Javaプログラムに制御が戻る前に連続して発生します。

(6)　アプリケーション内でjava.lang.System.gc()メソッドが実行された場合

拡張verbosegc情報の出力例を次に示します。背景色付きの太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 20:36:29 2005>[Full GC 330K->150K(3520K), 0.0387690 secs][DefNew::Eden: 330K->0K(2048K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 0K->150K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:System.gc][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

FullGCの要因は，J2EEアプリケーション内またはバッチアプリケーション内でのjava.lang.System.gc()メソッド呼び出しです。

(7)　Metaspace領域にアロケーションしたいメモリサイズが確保済みMetaspace領域の未使用メモリサイズを上回る場合

拡張verbosegc情報の出力例を次に示します。背景色付きの太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Wed Jan 07 01:56:13 2015>[Full GC 11273K->6037K(15872K), 0. 0060004 secs][DefNew::Eden: 442K->0K(4416K)][DefNew::Survivor: 512K->0K(512K)][Tenured: 10319K->6037K(10944K)][Metaspace: 22811K(24520K, 24576K)->22811K(24520K, 24576K)][class space: 10758K(10988K, 11008K)->10758K(10988K, 11008K)][cause:MetaspaceAllocFail][User: 0.0312002 secs][Sys: 0.0000000 secs]
…

この出力例からは，次のことがわかります。

Metaspace領域にアロケーションしようとしたメモリサイズが，確保済みMetaspace領域の未使用メモリサイズ（24576K-22811K=1765K）を上回りました。

FullGCの要因は，Metaspaceヒープの割り付け失敗です。

(8)　javagcコマンドを実行した場合の出力例

拡張verbosegc情報の出力例を次に示します。背景色付きの太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 21:46:50 2005>[Full GC 369K->189K(3520K), 0.0403010 secs][DefNew::Eden: 369K->0K(2048K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 0K->189K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:JavaGC Command][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

FullGCの要因は，javagcコマンド実行です。

(9)　jheapprofコマンドを実行した場合の出力例

拡張verbosegc情報の出力例を次に示します。背景色付きの太字の部分がFullGC発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 21:46:50 2005>[Full GC 369K->189K(3520K), 0.0403010 secs][DefNew::Eden: 369K->0K(2048K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 0K->189K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:JHeapProf Command][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

FullGCの要因は，jheapprofコマンド実行です。

7.11　Explicitヒープのチューニング

ここでは，Explicitヒープのチューニングについて説明します。

7.11.1　Explicitヒープのメモリサイズの見積もり（J2EEサーバが使用するメモリサイズの見積もり）

Explicitヒープをチューニングする前提として，明示管理ヒープ機能を使用するための設定が必要です。明示管理ヒープ機能は，JavaVMの起動オプションとして-XX:+HitachiUseExplicitMemoryが指定されている場合に有効になります。JDK11以前で動作するJ2EEサーバの場合，明示管理ヒープ機能はデフォルトで使用される設定になっています。また，Tenured領域のメモリサイズ増加の要因となるオブジェクトがExplicitヒープに配置されるように設定されています。このため，J2EEサーバが配置するオブジェクトに必要なExplicitヒープのメモリサイズを必ず見積もってください。

明示管理ヒープ機能は，Explicitヒープのメモリサイズを適切に見積もった上で使用しないと，効果が出ません。

J2EEサーバでは，Tenured領域のメモリサイズ増加の要因になる，HTTPセッションに関するオブジェクトをExplicitヒープに配置します。

Explicitヒープのメモリサイズを見積もった結果，HTTPセッションに関するオブジェクトが利用するExplicitヒープのメモリサイズが極端に大きい場合は，「付録A　HTTPセッションで利用するExplicitヒープの効率的な利用」を参考にして，アプリケーションの設計を見直してください。

7.11.2　HTTPセッションに関するオブジェクトで利用するメモリサイズ

ここでは，HTTPセッションに関するオブジェクトで利用するメモリサイズの見積もりについて説明します。

注意事項

なお，HTTPセッションで利用するExplicitヒープの省メモリ化機能を使用する場合，この手順での見積もりはできません。HTTPセッションで利用するExplicitヒープの省メモリ化機能を使用する場合は，「7.11.4　稼働情報による見積もり」で示す手順でメモリサイズを見積もってください。

HTTPセッションに関するオブジェクトで利用するExplicitヒープのメモリサイズは，次の式で見積もります。

HTTPセッションに関するオブジェクトで利用するExplicitヒープのメモリサイズ
= HTTPセッションで利用するExplicitヒープのメモリサイズ
 + Webコンテナ内部で利用するExplicitヒープ領域のメモリサイズ

HTTPセッションで利用するExplicitヒープのメモリサイズは，次の式で見積もります。

HTTPセッションで利用するExplicitヒープのメモリサイズ
= 1セッションで使用するメモリサイズ※1×システムで必要なセッション数

HTTPセッションのために，Webコンテナ内部で利用するExplicitヒープ領域のメモリサイズは，次の式で見積もります。

Webコンテナ内部で利用するExplicitヒープ領域のメモリサイズ
= HTTPセッション管理用オブジェクトのサイズ※2×（Webアプリケーションの数※3 + 2）

注※1

1セッションで使用するメモリサイズは，Explicitメモリブロック1個のサイズに相当します。Explicitメモリブロック1個のサイズは，実際にアプリケーションを動作させて，Explicitヒープの使用状況を確認しながら見積もります。なお，Explicitメモリブロックの最小サイズは，明示管理ヒープ機能の自動配置機能の使用の有無によって異なります。明示管理ヒープ機能の自動配置機能の使用の有無によるExplicitメモリブロックの最小サイズを次に示します。

表7‒4　明示管理ヒープ機能の自動配置機能の使用の有無によるExplicitメモリブロックの最小サイズ

項番

明示管理ヒープ機能の自動配置機能使用の有無

Explicitメモリブロックの最小サイズ

1

○

16キロバイト

2

×

64キロバイト

（凡例）

○：明示管理ヒープ機能の自動配置機能を使用する。

×：明示管理ヒープ機能の自動配置機能を使用しない。

なお，Explicitメモリブロックは64キロバイト単位で拡張されます。そのため，実際は「Explicitメモリブロック1個のサイズ≧1セッションで使用するメモリサイズ」となります。また，明示管理ヒープ機能の自動配置機能を使用する場合は，さらに16キロバイトを加算して見積もってください。

注※2

HTTPセッション管理用オブジェクトのサイズは「表7-4　明示管理ヒープ機能の自動配置機能の使用の有無によるExplicitメモリブロックの最小サイズ」に示すExplicitメモリブロックの最小サイズです。

注※3

「Webアプリケーションの数」は，開始しているWebアプリケーションの個数を表します。

(1)　見積もり手順

見積もり手順を示します。

HTTPセッションを作成するアプリケーションを開始して，セッション破棄（ログアウトなど）の直前まで処理を実行します。

javagcコマンドを実行して，FullGCを発生させます。

明示管理ヒープ機能のイベントログに出力されたFullGC実行後の情報を確認します。

明示管理ヒープ機能のイベントログは，JavaVMの起動オプションである-XX:HitachiExplicitMemoryJavaLogオプションで指定したファイルまたはディレクトリに出力されます。デフォルトの出力先は，次のとおりです。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥server¥public¥ejb¥<J2EEサーバ名>¥logs¥ehjavalog[n].log

UNIXの場合

/opt/Cosminexus/CC/server/public/ejb/<J2EEサーバ名>/logs/ehjavalog[n].log

ここでは，一連の業務で必要なExplicitヒープの利用サイズとExplicitメモリブロックの個数を確認します。

メモリサイズ算出時には，イベントログの出力項目のうち，次の項目を確認します。

Explicitヒープの確保済みサイズ

Explicitメモリブロックの個数

明示管理ヒープ機能のイベントログの内容については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「5.11　明示管理ヒープ機能のイベントログ」を参照してください。これらの項目は，GC発生時に出力される，Explicitヒープ利用状況に含まれます。

手順3.で確認した内容を基に，Explicitメモリブロック1個のサイズを算出します。

次の式で算出できます。

Explicitメモリブロック１個のサイズ
=Explicitヒープの確保済みサイズ／Explicitメモリブロックの個数

Explicitメモリブロック1個のサイズは，1セッションで使用するメモリサイズに相当します。

手順4.で算出した値に，業務で必要になるセッション数を掛け，HTTPセッションで使用するExplicitヒープの合計メモリサイズを算出します。

(2)　見積もり例

ここでは，明示管理ヒープ機能のイベントログの出力例を基に，見積もり例を示します。明示管理ヒープ機能のイベントログの出力例を次に示します。

明示管理ヒープ機能のイベントログの出力例

[ENS]<Thu Oct 21 14:55:50 2007>[EH: 12672K->12800K(12800K/65536K)][E/F/D: 200/0/0][cause:GC][CF: 0]

この例では，Explicitヒープの確保済みサイズは12,800キロバイト，Explicitメモリブロックの個数は200個と出力されています。この値を「7.11.2(1)　見積もり手順」の手順4.で示した式に当てはめると，次のようになります。

Explicitメモリブロックサイズの見積もり例

Explicitメモリブロック1個のサイズ
=Explicitヒープの確保済みサイズ（12,800キロバイト）/Explicitメモリブロックの個数（200）
=64キロバイト

これに業務で想定するセッション数を掛けた値が，HTTPセッションで使用するExplicitヒープの合計メモリサイズになります。

7.11.3　明示管理ヒープ機能利用によるメモリサイズの見積もりへの影響

アプリケーションサーバの機能の中には，その機能を使用するかどうかでExplicitヒープ領域のメモリサイズに影響が出るものがあります。機能利用の有無による見積もりへの影響について表に示します。

表7‒5　機能利用の有無による見積もりへの影響

項番

機能

機能利用の有無によるExplicitヒープ領域の違い

見積もりへの影響

1

明示管理ヒープの自動解放機能（-XX:+HitachiExplicitMemoryAutoReclaimオプション）

有効な場合

Explicitヒープ領域の中で「JavaヒープのSurvivor領域のサイズ×2」の領域をJavaVMが使用します。

無効な場合

JavaVMはExplicitヒープ領域を使用しません。

機能が有効な場合の最終的なExplicitヒープ領域の見積もりサイズは，稼働情報から算出した見積もりサイズに「JavaヒープのSurvivor領域のサイズ×2」を加算した値となります。

2

明示管理ヒープ機能の自動配置機能（-XX:+HitachiAutoExplicitMemoryオプション）

有効な場合

Explicitメモリブロックの最小サイズが16キロバイトになります。

無効な場合

Explicitメモリブロックの最小サイズが64キロバイトになります。

また，見積もりには影響しませんが，機能の有効・無効によってExplicitヒープ領域の確保方法が変わります。

有効な場合

プロセス起動時に-XX:HitachiExplicitHeapMaxSizeオプションで指定したサイズのメモリを確保します。

無効な場合

Explicitメモリブロック取得時に，必要なだけのメモリサイズを確保します。

機能の有効・無効によって，稼働情報に出力されるExplicitヒープサイズに関する情報が異なります。

7.11.4　稼働情報による見積もり

J2EEサーバのテストを実施する場合，または運用開始後のJ2EEサーバによる実際のExplicitヒープ使用状況は，稼働情報で確認できます。ここでは，稼働情報による確認手順について説明します。

稼働情報の出力内容，出力するための設定，および稼働情報ファイルの出力先については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「3.3　稼働情報ファイルの出力機能」を参照してください。

(1)　稼働情報を使用した見積もりの考え方

稼働情報を使用した見積もりでは，システムに必要なExplicitヒープ領域のメモリサイズは次のようになります。

HTTPセッションで使用するExplicitヒープ領域のメモリサイズ

1.の領域を除いた，内部（コンテナ）で使用するExplicitヒープ領域のメモリサイズ

アプリケーションおよびJavaVMで使用するExplicitヒープ領域のメモリサイズ

JavaVMがExplicitメモリブロックを管理するために使用するExplicitヒープ領域のメモリサイズ（JavaヒープのSurvivor領域のサイズ×2）

1.〜3.のメモリサイズは，稼働情報で確認できます。4.は，明示管理ヒープの自動解放機能が有効な場合に，「JavaヒープのSurvivor領域のサイズ×2」のメモリサイズを使用します。

1.〜3.で示す各Explicitヒープ領域を使用するものの例を表で示します。なお，1.〜3.は表中の項番1〜3に対応しています。

表7‒6　Explicitヒープ領域を使用するものの具体例

項番

Explicitヒープ領域

Explicitヒープ領域を使用するものの具体例

1

HTTPセッションで使用するExplicitヒープ領域

HTTPセッション

2

コンテナで使用するExplicitヒープ領域

HTTPセッション管理用オブジェクト

3

アプリケーションおよびJavaVMで使用するExplicitヒープ領域

アプリケーション

JavaVM

(2)　見積もりに使用する稼働情報取得時の注意

見積もりに使用する稼働情報は，本番環境，または本番環境と同等の環境で取得してください。

次に示す項目が本番環境と異なる場合は，稼働情報を使って適切なメモリサイズを見積もることはできません。

各定義ファイルに設定するプロパティ，およびオプションに指定する値

サーバに登録されているWebアプリケーションの数

業務アプリケーションが処理するデータのサイズ

一定時間内に処理するデータの数

また，見積もりのために稼働情報を取得する場合，Explicitヒープ領域を使い切った状態にならないようExplicitヒープ領域サイズの最大値を設定するオプションを指定してください。

Explicitヒープ領域の最大サイズが不十分な状態で稼働情報を取得した場合，Explicitヒープ領域を使い切った状態になるおそれがあります。Explicitヒープ領域を使い切った状態で取得した稼働情報では，適切な見積もりはできません。Explicitヒープ領域を使い切った状態かどうかは，稼働情報のEHeapSize.HighWaterMarkの値が，Explicitヒープ領域の最大サイズの値と同じ値になっているかどうかで確認できます。稼働情報のEHeapSize.HighWaterMarkの値とExplicitヒープ領域の最大サイズの値が同じだった場合，Explicitヒープ領域を使い切っている状態となります。

(3)　見積もり方法

稼働情報を基にした見積もり方法を次に示します。

(a)　HTTPセッションで利用するExplicitヒープ領域のメモリサイズ

HTTPセッションで利用するメモリサイズは，「7.11.2　HTTPセッションに関するオブジェクトで利用するメモリサイズ」で示したHTTPセッションで利用するExplicitヒープのメモリサイズの式で求めます。このとき，式に含まれる「1セッションで使用するメモリサイズ」を稼働情報で確認できます。

1セッションで使用するメモリサイズは，稼働情報に出力された「Explicitメモリブロックの最大サイズ」に該当します。「Explicitメモリブロックの最大サイズ」には，稼働情報収集間隔の間に解放されたExplicitメモリブロックのうち，最大のものの利用済みサイズが出力されます。そのため，Explicitヒープを見積もる際は，64キロバイト単位で切り上げて見積もってください。さらに，明示管理ヒープ機能の自動配置機能を使用する場合は，16キロバイトを加算して見積もってください。

また，見積もりをする際は，次に示す値を参考にしてください。なお，システムで必要なセッション数は，「Explicitメモリブロックの個数」に該当します。

HTTPセッションで取得したExplicitメモリブロックの最大サイズ（HTTPSessionEMemoryBlockMaxSize.HighWaterMarkの値）

HTTPセッションで取得したExplicitメモリブロックの個数（HTTPSessionEMemoryBlockCount.HighWaterMarkの値）

(b)　コンテナで利用するExplicitヒープ領域のメモリサイズ

コンテナで使用するExplicitヒープ領域のメモリサイズは，稼働情報の「コンテナで利用するExplicitヒープサイズ」が該当します。見積もりに使用する稼働情報は取得した値の中で最大値（ContainerEHeapSize.HighWaterMarkの値）を使用してください。

(c)　アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズ

アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズは，稼働情報の「アプリケーションで利用するExplicitヒープサイズ」の値が該当します。見積もりに使用する稼働情報は取得した値の中で最大値（ApplicationEHeapSize.HighWaterMark）を使用してください。

(4)　稼働情報の確認手順

稼働情報の確認手順について説明します。ここでは，(3)による稼働情報の見積もり式を例に説明します。なお，稼働情報ファイルの出力内容については，マニュアル「アプリケーションサーバ機能解説 運用／監視／連携編」の「3.3　稼働情報ファイルの出力機能」を参照してください。

見積もり式

必要なExplicitヒープ領域のメモリサイズ
＝(HTTPSessionEMemoryBlockMaxSize.HighWaterMarkを64キロバイト単位に切り上げた値
×HTTPSessionEMemoryBlockCount.HighWaterMark)
＋ContainerEHeapSize.HighWaterMark
＋ApplicationEHeapSize.HighWaterMark
＋JavaヒープのSurvivor領域のサイズ
×2(明示管理ヒープ自動解放機能が有効な場合だけ)

それぞれの値の確認方法について説明します。

(a)　HTTPセッションで利用するExplicitヒープ領域のメモリサイズ

HTTPセッションで利用するExplicitヒープ領域のメモリサイズは，JavaVMの稼働情報ファイルに出力されるHTTPSessionEMemoryBlockMaxSize.HighWaterMark，およびHTTPSessionEMemoryBlockCount.HighWaterMarkの値を使って確認します。

HTTPセッションで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例を次の図に示します。

図7‒13　HTTPセッションで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例

HTTPSessionEMemoryBlockMaxSize.HighWaterMarkの最大値は，図中1.で示している11:00:31に取得した410472バイト（400.85キロバイト）です。

この値を64キロバイト単位に切り上げると，448キロバイトとなります。HTTPSessionEMemoryBlockCount.HighWaterMarkの最大値は図中2.で示している11:04:31に取得した57です。

これら二つの値を掛け合わせた値が，HTTPセッションで利用するExplicitヒープ領域のメモリサイズとなります。

(b)　コンテナで利用するExplicitヒープ領域のメモリサイズ

コンテナで利用するExplicitヒープ領域のメモリサイズは，JavaVMの稼働情報ファイルに出力されるContainerEHeapSize.HighWaterMarkの値を使って確認します。

コンテナで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例を次の図に示します。

図7‒14　コンテナで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例

ContainerEHeapSize.HighWaterMarkの最大値は図中1.で示している10:50:31以降に取得している6815744バイト（6656キロバイト）です。

これがコンテナで利用するExplicitヒープ領域のメモリサイズとなります。

(c)　アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズ

アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズはJavaVMの稼働情報ファイルに出力されるApplicationEHeapSize.HighWaterMarkの値を使って確認します。

アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例を次の図に示します。

図7‒15　アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例

ApplicationEHeapSize.HighWaterMarkの最大値は図中1.で示している10:53:31に取得した2424832バイト（2368キロバイト）です。

(d)　必要なExplicitヒープ領域のメモリサイズ

(a)〜(c)で示した稼働情報から求められる，必要なExplicitヒープ領域のメモリサイズは次のようになります。

448(キロバイト)× 57 ＋ 6656(キロバイト) ＋ 2368(キロバイト)
＝ 34560(キロバイト)≒ 34メガバイト

明示管理ヒープの自動解放機能が有効な場合，「JavaヒープのSurvivor領域のサイズ×2」を加算した値が，最終的なExplicitヒープ領域の見積もりサイズとなります。

7.12　アプリケーションで明示管理ヒープ機能を使用する場合のメモリサイズの見積もり

ユーザが作成したアプリケーションにTenured領域のメモリサイズ増加の要因になっているオブジェクトがある場合，該当するオブジェクトをExplicitヒープに配置できます。ここでは，アプリケーションで明示管理ヒープ機能を使用する場合のメモリサイズの見積もりについて説明します。

ポイント

この節の説明は，J2EEサーバを含めた，JavaVM上で動作するすべてのJavaアプリケーションに該当します。ただし，J2EEサーバで使用するExplicitヒープだけを使用する場合，必ず読む必要はありません。必要に応じて参照してください。

7.12.1　アプリケーションで明示管理ヒープ機能を使用するかどうかの検討

Javaヒープのチューニングおよび「7.11.1　Explicitヒープのメモリサイズの見積もり（J2EEサーバが使用するメモリサイズの見積もり）」の手順を実施してもFullGCが頻発する場合は，アプリケーションでの明示管理ヒープ機能の使用を検討します。

まず，FullGCの発生要因となっているオブジェクトを調査します。特定のオブジェクトをExplicitヒープに配置することでFullGC発生を抑止できる場合は，明示管理ヒープ機能を適用します。

ただし，Explicitヒープに配置するオブジェクトは，ライフサイクルが既知であることが必要です。オブジェクトの生成のタイミングおよびオブジェクトが不要になるタイミングがJavaプログラム上で明確な場合に，適用を検討してください。

明示管理ヒープ機能を適用するためには，自動配置設定ファイル，または明示管理ヒープ機能APIを使用します。明示管理ヒープ機能を使用したFullGCの抑止については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.　明示管理ヒープ機能を使用したFullGCの抑止」を参照してください。

7.12.2　見積もりの考え方

アプリケーションが利用するExplicitヒープのメモリサイズは，運用開始前に見積もります。実際にアプリケーションを動作させた上で，明示管理ヒープ機能のイベントログを確認して見積もります。見積もり方法については，「7.12.3　アプリケーションが使用するメモリサイズ」を参照してください。

アプリケーション開発中および運用開始後にExplicitヒープの使用状況などを調査する場合は，JavaVMログファイルやJava APIを使用します。開発中や運用開始後の調査の手順については，「7.14　明示管理ヒープ機能適用時に発生しやすい問題とその解決方法」を参照してください。

参考

メモリサイズの見積もりに利用できる情報は，稼働情報にも出力されます。稼働情報を利用したメモリサイズのチューニングについては「7.11.4　稼働情報による見積もり」を参照してください。

なお，ここでは稼働情報に出力される項目と，スレッドダンプに出力される項目の対応についても説明します。

7.12.3　アプリケーションが使用するメモリサイズ

運用を開始する前に，アプリケーションが使用するExplicitヒープのメモリサイズを見積もり，-XX:HitachiExplicitHeapMaxSizeオプションに設定します。

メモリサイズは，実際に明示管理ヒープ機能を実装したアプリケーションを動作させてテストを実行し，出力されたログを確認して見積もります。見積もった値を，本番で使用する実行環境の-XX:HitachiExplicitHeapMaxSizeオプションに設定します。

ここでは，テストを実行する環境に応じた2種類の見積もり方法について説明します。

どちらの方法でテストを実行する場合も，次のことが前提になります。

見積もりの前提

Explicitヒープの最大サイズを十分に大きく設定してテストを実行してください。

-XX:HitachiExplicitMemoryLogLevelオプションには「none」以外を設定してください。

見積もりで使用するイベントログの出力項目については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「5.11　明示管理ヒープ機能のイベントログ」を参照してください。

(1)　本番環境と同等の環境でテストを実行できる場合

本番環境と同等の環境でテストを実行できる場合，イベントログに出力されたExplicitヒープの確保済みメモリサイズの最大値をExplicitヒープのメモリサイズとします。

確認手順を示します。

テスト用の環境でアプリケーションを一とおり実行します。

アプリケーション実行中にGCが発生した時に，明示管理ヒープ機能のイベントログが出力されます。

出力されたイベントログのすべてのレコード（行）のうち，Explicitヒープの確保済みメモリサイズ（<EH_TOTAL>）が最大の値を確認します。

この値を，Explicitヒープのメモリサイズとしてください。ただし，明示管理ヒープの自動解放機能が有効な場合は，この値に「Survivor領域サイズ × 2」を加算した値を，Explicitヒープのメモリサイズとしてください。

(2)　本番環境よりも小さなスケールの環境でテストを実行する場合

本番環境よりも小さなスケールの環境でテストを実行する場合，本番環境で必要なメモリサイズは次の式で見積もります。

本番環境でのExplicitヒープサイズ
= (Explicitヒープの最大サイズ)/(Explicitメモリブロックの数) × 本番環境でのExplicitメモリブロック数
+ Survivor領域サイズ × 2※

注※

明示管理ヒープの自動解放機能が有効な場合に「Survivor領域サイズ × 2」を加算します。

テスト用の環境でアプリケーションを一とおり実行します。

アプリケーション実行中にGCが発生した時に，明示管理ヒープ機能のイベントログが出力されます。

出力されたイベントログのすべてのレコード（行）のうち，Explicitヒープの確保済みメモリサイズ（<EH_TOTAL>）が最大の値を確認します。また，同じレコードに出力されている有効なExplicitメモリブロックの数（<AC_NUM>と<DA_NUM>の合計）を確認します。

2.で確認した<EH_TOTAL>の値を（<AC_NUM>+<DA_NUM>）で割ります。

Explicitメモリブロック一つ当たりのおおよそのサイズを算出できます。

3.で算出した値に，本番環境で予測される最大のExplicitメモリブロック数を掛けます。

注

この方法は，開発環境と本番環境でのExplicitメモリブロックの一つ当たりのサイズが同じであり，数だけが異なる場合に適用できます。

また，Explicitヒープを複数の用途に利用している場合，用途ごと（見積もり対象の用途以外のExplicitメモリブロックを利用しない状態）で確認する必要があります。

ポイント

スレッドダンプに出力される項目，および稼働情報に出力される項目の対応を次の表に示します。

表7‒7　スレッドダンプおよび稼働情報の出力項目の対応

スレッドダンプの出力項目

稼働情報の出力項目

出力内容

<EH_TOTAL>

EHeapSize

Explicitヒープの確保済みメモリサイズ

<AC_NUM> + <DA_NUM>

EMemoryBlockCount

同じレコードに出力されている有効なExplicitメモリブロックの数

7.13　明示管理ヒープ機能の自動配置機能を使用したExplicitヒープの利用の検討

ここでは，明示管理ヒープ機能の自動配置機能を使用したExplicitヒープの利用の検討について説明します。

明示管理ヒープ機能を使用してExplicitヒープ領域を利用する際，自動配置機能を使用することで，明示管理ヒープ機能を容易に使用できます。また，次に示すような場合は，自動配置機能を使用することをお勧めします。

7.13.1　アプリケーション内にTenured領域の増加原因のオブジェクトがある場合

アプリケーション内にTenured領域の増加原因のオブジェクトがある場合，自動配置設定ファイルを使用してオブジェクトをExplicitヒープに配置することをお勧めします。オブジェクトの配置を検討した方がよいJavaプログラムの例を次に示します。

01:package abcd.efg;
02:import java.util.HashMap;
03:// KVStorageのインスタンスは，長期間生存し続ける
04:class KVStorage {
05:  HashMap _map = new HashMap();
06:
07:  public void store(MyKey k,MyData d) {
08:    // ...前処理...
09:    _map.put(k,d);
10:    // ...後処理...
11:  }
12:
13:  public MyData load(MyKey k) {
14:    // ...前処理...
15:    MyData d = map.get(k);
16:    // ...後処理...
17:    return d;
18:  }
19:}

この設定例の場合，KVStorageがインスタンスフィールドに保持しているHashMapクラスがTenured領域のメモリサイズ増加の要因となる長寿命オブジェクトとなります。このオブジェクトの生成先をExplicitヒープへ変更する場合，次の例のように自動配置設定ファイルを指定します。

# 生成個所（メソッド名やクラス名）, 生成するクラス名 の対で記載。
abcd.efg.KVStorage.<init>, java.util.HashMap

この例のように自動配置設定ファイルを指定することで，Javaプログラムの例の5行目のHashMapインスタンス（_map）の生成先がJavaヒープからExplicitヒープに変更されます。また，storeメソッドで_mapに格納したMyKeyのインスタンス，およびMyDataのインスタンスも，順次Explicitヒープに移動されます。これらのインスタンスは，不要となった時点でJavaVMによって自動的に解放されます。

7.13.2　Tenured領域利用済みサイズの増加原因が不明な場合

Survivor領域のチューニングを実施しても，Tenured領域利用済みサイズが増加し，それによるFullGCの発生間隔がシステムの要件を満たせない場合，Tenured領域利用済みサイズの増加原因となるオブジェクトをExplicitヒープへ生成します。Explicitヒープへオブジェクトを生成するには，明示管理ヒープの自動配置設定ファイルを設定します。

Tenured領域利用済みサイズの増加原因となるオブジェクトを調査する方法，および自動配置設定ファイルの設定方法について説明します。

(1)　Tenured領域利用済みサイズ増加の調査

実行中のアプリケーションに対して，jheapprofコマンドに-garbageオプションを指定し，Tenured領域内不要オブジェクト統計機能を実行します。

Tenured領域内不要オブジェクト統計機能の出力例を次に示します。これによって，Tenured領域利用済みサイズ増加の原因となっているオブジェクト（Tenured増加要因の基点オブジェクト）のクラス名のリストがスレッドダンプログファイルに出力されます。

Garbage Profile Root Object Information
-----------------------------------
*, java.util.HashMap # 35234568
*, java.util.WeakHashMap # 4321000

この出力例では，Tenured領域利用済みサイズの増加原因として，java.util.HashMapのオブジェクトが35,234,568バイト，またjava.util.WeakHashMapのオブジェクトが4,321,000バイトであることがわかります。Tenured領域内不要オブジェクト統計機能の詳細については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「9.8　Tenured領域内不要オブジェクト統計機能」を参照してください。

(2)　自動配置設定ファイルへの記載

Tenured領域内不要オブジェクト統計機能の出力例のリスト部分（後半2行）を，自動配置設定ファイルへ入力します。自動配置設定ファイルの設定例を示します。

*, java.util.HashMap # 35234568
*, java.util.WeakHashMap # 4321000

この場合，プログラム中のすべてのjava.util.HashMapオブジェクト，およびjava.util.WeakHashMapオブジェクトはExplicitヒープに生成されます。

また，これらのオブジェクトに格納したオブジェクトも順次Explicitヒープに移動します。しかし，Explicitヒープへのオブジェクトの生成は，Javaヒープへのオブジェクトの生成よりも実行時にオーバーヘッドが掛かります。このため，オブジェクトの生成個所を絞り込むことで，実行時のオーバーヘッドを削減できます。

自動配置設定ファイルでは，「*」は「JavaVM上で動作するすべてのクラス」を意味します。この設定例の場合，すべてのクラスでのjava.util.HashMapおよびjava.util.WeakHashMapのオブジェクトの生成先がExplicitヒープになります。これによって，実際にはTenured利用済みサイズ増加の原因ではないオブジェクトの生成先もExplicitヒープとなり，オーバーヘッドが増加するおそれがあります。

「*」を指定したことによって，アプリケーションのスループットが要件を満たせなくなった場合は，Tenured領域利用済みサイズ増加の原因となっているオブジェクトの生成個所を絞り込むことを検討してください。

システム運用者とアプリケーション開発者が異なる場合は，アプリケーション開発者への調査の依頼が必要です。アプリケーションの詳細な調査が困難な場合でも，自動配置設定ファイルでは生成個所を「すべてのクラス」，「特定のパッケージ」，「特定のクラス」，および「特定のメソッド」の4段階の粒度でオブジェクトの生成個所を指定できます。そのため，調査可能な範囲で絞り込みを実施して，自動配置設定ファイルを指定することによって，スループットが向上する場合もあります。

例えば，生成個所が「com.abc.defg」パッケージ下の場合，自動配置設定ファイルの設定例を次のように変更することによって，「すべてのパッケージのすべてのクラス」から，「com.abc.defgパッケージおよびサブパッケージのすべてのクラス」まで絞り込みができます。

com.abc.defg.*, java.util.HashMap # 35234568
com.abc.defg.*, java.util.WeakHashMap # 4321000

自動配置設定ファイルの指定方法の詳細については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「7.13.2　自動配置設定ファイルを使った明示管理ヒープ機能の使用」を参照してください。

(3)　Tenured領域内不要オブジェクト統計機能によるアプリケーションの調査

自動配置設定ファイルの内容を基に，アプリケーションを調査する場合に，Tenured領域内不要オブジェクト統計機能を利用します。

jheapprofコマンドに-garbageオプションを指定し，Tenured領域内不要オブジェクト統計機能を実行することで，Tenured増加要因の基点オブジェクトリスト，およびTenured領域内不要オブジェクトの統計情報を拡張スレッドダンプに出力します。拡張スレッドダンプの出力例を次に示します。

Garbage Profile
---------------
________________Size__Instances__Class________________
            35234568      10648 java.util.HashMap
             5678900      10668 [Ljava.util.HashMap$Entry;
             4456788       7436 java.util.HashMap$Entry
             4321000        200 java.util.WeakHashMap
             1234568        190 [Ljava.util.WeakHashMap$Entry
1456788       9524 java.lang.String
1256788       6424 com.abc.defg.MyData;
：

Tenured領域内不要オブジェクト統計機能では，Tenured増加要因の基点オブジェクトリストには出力されない，java.util.HashMapやjava.util.WeakHashMapに格納されているオブジェクトも出力されます。また，各オブジェクトのインスタンス数も出力されます。

さらに，このログを複数回取得して，クラス別統計情報解析機能（jheapprofanalyzerコマンド）の入力ファイルとすることで，各オブジェクトサイズ，およびインスタンス数の時間の変化を調査できます。

これらの情報を基に，アプリケーションを調査してオブジェクト生成個所の絞り込みをします。Tenured領域内不要オブジェクト統計機能の詳細については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「9.8　Tenured領域内不要オブジェクト統計機能」を参照してください。クラス別統計情報解析機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「9.10　クラス別統計情報解析機能」を参照してください。

7.14　明示管理ヒープ機能適用時に発生しやすい問題とその解決方法

Explicitヒープのメモリサイズや，明示管理ヒープ機能の利用のしかた，Javaアプリケーションの設計方法，実行環境の設定などによっては，次の表に示す現象が発生することがあります。

表7‒8　明示管理ヒープ機能適用時に発生する現象と対処方法の参照先

項番

発生する現象

対処方法の参照先

1

Explicitヒープに空きがなく，Explicitメモリブロックへのオブジェクトの生成に失敗する。

7.14.3

2

Explicitメモリブロックの生成に失敗する。

7.14.4

3

明示管理ヒープ機能を利用してもFullGCが頻発する。

7.14.5

4

Explicitメモリブロックの自動解放処理に長時間掛かっている。

7.14.6

これらの現象が発生しているかどうかは，明示管理ヒープ機能のイベントログから調査できます。調査方法については，「7.14.1　Explicitヒープのある時点での利用状況（スナップショット）の調査」，および「7.14.2　利用状況の推移の調査」を参照してください。なお，明示管理ヒープ機能のイベントログの内容については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「5.11　明示管理ヒープ機能のイベントログ」を参照してください。なお，ここで説明する出力例では，見やすさのために改行した個所に¥を入れています。実際の出力内容に改行は入りません。

7.14.1　Explicitヒープのある時点での利用状況（スナップショット）の調査

Explicitヒープのある時点での利用状況（スナップショット）を調査する方法には，スレッドダンプを確認する方法と，Java APIで情報を取得する方法があります。

スレッドダンプを確認する方法

cjdumpsvコマンドを実行すると，任意のタイミングでスレッドダンプを出力できます。スレッドダンプには，Explicitヒープおよび各Explicitメモリブロックの利用状況が出力されます。

出力例を次に示します。

Explicit Heap Status
--------------------
 max 65536K, total 21376K, used 20480K, garbage 1234K (31.2% used/max, 95.8% used/total, 6.0% garbage/used), 1 spaces exist
 Explicit Memories(0x12345678)
  "EJBMgrData" eid=1(0x02f25610)/R, total 21376K, used 20480K, garbage 1234K (95.8% used/total, 6.0% garbage/used, 0 blocks) Enable

背景色付きの太字の部分が，Explicitヒープおよび個別のExplicitメモリブロックの利用状況です。

この例の場合，Explicitヒープの最大サイズは65,536キロバイト，確保済みExplicitヒープサイズは21,376キロバイトです。また，「EJBMgrData」という名称のExplicitメモリブロックのメモリ確保済みサイズは21,376キロバイト，利用済みサイズは20,480キロバイトであることがわかります。

Java APIで情報を取得する方法

JavaVMのJava APIを使用して，ExplicitヒープおよびExplicitメモリブロックの利用状況を取得できます。次に示すAPIを使用してアプリケーションを実装することで，任意の処理のタイミングで情報を取得できます。

Explicitヒープの利用状況を取得するメソッド

JP.co.Hitachi.soft.jvm.MemoryArea.ExplicitMemory.getMemoryUsage()

Explicitメモリブロック利用状況を取得するメソッド

JP.co.Hitachi.soft.jvm.MemoryArea.ExplicitMemory.freeMemory()

JP.co.Hitachi.soft.jvm.MemoryArea.ExplicitMemory.totalMemory()

JP.co.Hitachi.soft.jvm.MemoryArea.ExplicitMemory.usedMemory()

7.14.2　利用状況の推移の調査

Explicitヒープの利用状況の推移を調査する方法には，明示管理ヒープ機能のイベントログを確認する方法と，Java APIで情報を取得する方法があります。Java APIを使用する方法については，「7.14.1　Explicitヒープのある時点での利用状況（スナップショット）の調査」で示したAPIを使用します。

ここでは，明示管理ヒープ機能のイベントログを使用した調査方法について説明します。

(1)　Explicitヒープの利用状況の推移

JavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「normal」を指定します。これによって，次のタイミングでExplicitヒープの利用状況が出力されます。

GC発生時（定期的）

Explicitメモリブロックの明示解放処理時

Explicitメモリブロックの自動解放処理時

また，JavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「verbose」を指定すると，「normal」で出力されるタイミングに加えて，次のタイミングでExplicitヒープの利用状況が出力されるようになります。

ExplicitMemory.newInstanceメソッドなどによるExplicitメモリブロックへのオブジェクト生成時

出力例を次に示します。

[ENS]<Thu Oct 21 14:55:50 2007>[EH: 12672K->12800K(12800K/65536K)][E/F/D: 200/0/0][cause:GC][CF: 0]
[ENS]<Thu Oct 21 14:55:50 2007>[EH: 12800K->12800K(12800K/65536K), 0.1124626 secs][E/F/D: 200/0/0]¥
[DefNew::Eden: 0K->0K(243600K)][DefNew::Survivor: 0K->0K(17400K)][Tenured: 103400K->103400K(556800K)]¥
[target:584K/0K/584K][cause:Migrate]

背景色付きの太字で示した「EH:」で始まる部分が，Explicitヒープの利用状況を示します。ログに出力された内容のうち，Explicitヒープの利用状況を示す行には，必ず背景色付きの太字に該当する情報が含まれます。この値をグラフなどに記してプロットすることによって，利用状況の推移を確認できます。

この例の場合，「cause:」で始まる部分に示すとおり，一つ目の[ENS]で始まる行はCopyGC（GC）発生時に出力されたログであり，二つ目の[ENS]で始まる行はExplicitメモリブロックの自動解放処理（Migrate）時に出力されたログであることがわかります。1行目のログでは，CopyGC発生前のExplicitヒープの利用済みサイズは12,672キロバイト，発生後のExplicitヒープの利用済みサイズは12,800キロバイトであることがわかります。2行目のログでは，Explicitヒープの利用済みサイズは12,800キロバイト，Explicitメモリブロックの自動解放処理に0.1124626秒掛かったことがわかります。

なお，利用状況を示すログの先頭は，[ENS]または[EVS]で開始されます。この文字列でイベントログをフィルタリングすると，利用状況を確認しやすくなります。

(2)　Explicitメモリブロックごとの利用状況の推移

JavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「verbose」を指定します。これによって，次のタイミングでサイズ変化のあったExplicitメモリブロックの利用状況が出力されます。

Explicitメモリブロックへのオブジェクト移動時

Explicitメモリブロックへのオブジェクト生成時

出力例を示します。

[ENS]<Thu Oct 21 14:55:50 2007>[EH: 11422K->12800K(12800K/65536K)][E/F/D: 200/0/0][cause:GC][CF: 0]
[EVS]["REM2" eid=2/R: 0K->88K(128K)]["REM3" eid=3/R: 30K->230K(256K)]["REM6" eid=6/R: 30K->200K(256K)]¥
["Session1" eid=8/R: 30K->250K(256K)]["Session2" eid=10/R: 30K->250K(256K)]
[EVS]["Session3" eid=12/R: 30K->510K(512K)]

背景色付きの太字で示した部分が，「"REM2"」という名称の一つのExplicitメモリブロックについての利用状況を示します。

また，-XX:HitachiExplicitMemoryLogLevelオプションに「verbose」を指定した場合，Explicitメモリブロックの解放時に，解放したExplicitメモリブロックの情報が出力されます。出力例を示します。

[ENS]<Tue Jul 24 01:23:51 2007>[EH: 12800K->11776K(11776K/65536K), 0.1129602 secs][E/F/D: 523/0/0]¥
[DefNew::Eden: 0K->0K(243600K)][DefNew::Survivor: 12K->0K(17400K)][Tenured: 103400K->103400K(556800K)][cause:Reclaim]
[EVS]["REM2" eid=2/R: 320K]["BEM3" eid=5/B: 320K]["BEM1" eid=7/B: 384K]

背景色付きの太字で示した部分が，解放された「"REM2"」という名称のExplicitメモリブロックの情報を示しています。「320K」は，解放されたメモリのサイズ（確保済みだったExplicitメモリブロックのサイズ）です。

これらの値をグラフなどに記してプロットすることによって，Explicitメモリブロックごとの利用状況の推移を確認できます。なお，個々のExplicitメモリブロックのサイズは，解放するまで単調増加します。

7.14.3　Explicitヒープあふれが発生した場合の確認と対処

Explicitヒープあふれが発生した場合の確認と対処について説明します。

Explicitヒープあふれとは，次の状態を示します。

Explicitヒープを最大サイズまで使い切った状態

Explicitメモリブロック拡張時にOSからのメモリ確保に失敗する状態

Explicitヒープあふれが発生すると，発生後に領域を拡張しようとしたExplicitメモリブロックのサブ状態が，「Enable」から「Disable」に変わります。「Disable」になったExplicitメモリブロックには，オブジェクトを配置できません。

Explicitヒープあふれが発生しているかどうかは，明示管理ヒープ機能のイベントログまたはスレッドダンプの内容から調査できます。また，Java APIで取得した情報で確認することもできます。

Explicitヒープあふれが発生した場合は，次の対処を実施してください。

Explicitヒープあふれが発生した場合の対処

Explicitヒープの最大サイズを増やす。

-XX:HitachiExplicitHeapMaxSizeオプションの指定を変更します。

Explicitヒープの最大サイズに達していない状態であふれた場合は，OSからのメモリ確保可能サイズを増やす。

アプリケーションサーバが利用できるメモリサイズを増やしてください。

Explicitヒープを大量に消費している原因を取り除く。

ここでは，Explicitヒープあふれが発生しているかどうかの確認方法について説明します。

(1)　明示管理ヒープ機能のイベントログの調査

明示管理ヒープ機能のイベントログで調査をするためには，あらかじめJavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「normal」を指定しておく必要があります。これによって，GCが発生するごとに，明示管理ヒープ機能のイベントログにExplicitメモリブロックの利用状況が出力されるようになります。

出力例を示します。

[ENS]<Thu Oct 21 14:55:50 2007>[EH: 12672K->12800K(12800K/65536K)][E/F/D: 200/0/0][cause:GC][CF: 0]

背景色付きの太字で示した部分が，Explicitメモリブロックの数を示しています。「E」および「D」は，Explicitメモリブロックのサブ状態である「Enable」および「Disable」を表します。「Disable」のExplicitメモリブロックがある場合は，Explicitヒープあふれが発生しています。この例の場合は，「Enable」のExplicitメモリブロックが200個あり，「Disable」のExplicitメモリブロックはないことがわかります。なお，「Disable」のExplicitメモリブロックがある場合は，Explicitヒープ最大サイズとの関係を確認してください。Explicitヒープ最大サイズまでに余裕があるときには，OSからのメモリ確保に失敗していることが考えられます。

また，JavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「verbose」を指定した場合，Explicitメモリブロックのサブ状態が「Disable」になった要因も出力されます。

出力例を示します。

[EVO]<Tue Jul 24 01:23:51 2007>[alloc failed(Disable)][EH: 32760K(0K)/32768K/65536K][E/F/D: 321/0/1][cause:GC]¥
["BasicExplicitMemory-3" eid=3/B: 128K(0K)/128K][Thread: 0x00035a60]
[EVO][Thread: 0x00035a60] at ExplicitMemory.newInstance0(Native Method)
[EVO][Thread: 0x00035a60] at BasicExplicitMemory.newInstance(Unknown Source)
[EVO][Thread: 0x00035a60] at AllocTest.test(AllocTest.java:64)
[EVO][Thread: 0x00035a60] at java.lang.Thread.run(Thread.java:2312)

この例は，Explicitヒープあふれが発生した場合の例です。

背景色付きの太字で示した部分のうち，[alloc failed(Disable)]が，Explicitメモリブロックのサブ状態が「Disable」になった要因を示します。["BasicExplicitMemory-3" eid=3/B: 128K(0K)/128K]は，「Disable」になったExplicitメモリブロックの情報を示します。また，[EVO][Thread: 0x00035a60]で始まる行は，イベントが発生した時のスタックトレースを表しています。ただし，GCによるオブジェクトの移動でExplicitヒープあふれが発生した場合，スタックトレースは出力されません。

(2)　スレッドダンプで出力されたログファイルからの調査

cjdumpsvコマンドなどを使用してスレッドダンプを出力することによって，各Explicitメモリブロックのサブ状態を出力できます。

出力例を次に示します。

Explicit Heap Status
--------------------
 max 65536K, total 21888K, used 20992K, garbage 1288K (32.0% used/max, 95.9% used/total, 6.1% garbage/used), 2 spaces exist

 Explicit Memories(0x12345678)

  "EJBMgrData" eid=1(0x02f25610)/R, total 21376K, used 20480K, garbage 1234K (95.8% used/total, 6.0% garbage/used, 0 blocks) Enable

  "ExplicitMemory-4" eid=4(0x02f45800)/B, total 512K, used 512K, garbage 54K (100.0% used/total, 10.5% garbage/used, 0 blocks) Disable

背景色付きの太字で示した部分が，それぞれのExplicitメモリブロックのサブ状態を表しています。

(3)　JavaのAPIからの調査

次に示すメソッドを使用して，Explicitメモリブロックのサブ状態を調査できます。

JP.co.Hitachi.soft.jvm.MemoryArea.ExplicitMemory.isActive()

JP.co.Hitachi.soft.jvm.MemoryArea.ExplicitMemory.isReclaimed()

これらのメソッド両方の戻り値がfalseの場合，そのExplicitメモリブロックのサブ状態はDisableと判断できます。

7.14.4　Explicitメモリブロックの初期化が失敗した場合の確認と対処

Explicitメモリブロックの初期化が失敗した場合の確認と対処について説明します。

Explicitメモリブロックの数が最大になると，それ以上Explicitメモリブロックを初期化できなくなります。

この場合は，Explicitメモリブロックの数を減らしてください。

ここでは，Explicitメモリブロックの初期化が失敗しているかどうかの確認方法について説明します。

(1)　明示管理ヒープ機能イベントログからの調査

明示管理ヒープ機能イベントログで調査をするためには，あらかじめJavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「normal」を指定しておく必要があります。これによって，GCが発生するごとに，Explicitメモリブロックの初期化に失敗した回数が明示管理ヒープ機能イベントログに出力されるようになります

出力例を示します。

[ENS]<Thu Oct 21 14:55:50 2007>[EH: 12672K->12800K(12800K/65536K)][E/F/D: 200/0/0][cause:GC][CF: 0]

背景色付きの太字で示した部分が，前回の出力から今回の出力までの間にExplicitメモリブロックの初期化に失敗した回数です。この例の場合は，「0」です。初期化失敗が発生していない，問題のない状態です。

また，JavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「verbose」を指定した場合，Explicitメモリブロックの初期化失敗イベントについての情報も出力されます。

出力例を示します。

[EVO]<Tue Jul 24 01:23:51 2007>[Creation failed][EH: 32760K(0K)/32768K/65536K][E/F/D: 65535/0/0][Thread: 0x00035a60]
[EVO][Thread: 0x00035a60] at ExplicitMemory.registerExplicitMemory(Native Method)
[EVO][Thread: 0x00035a60] at BasicExplicitMemory.<init>(Unknown Source)
[EVO][Thread: 0x00035a60] at AllocTest.test(AllocTest.java:64)
[EVO][Thread: 0x00035a60] at java.lang.Thread.run(Thread.java:2312)

背景色付きの太字で示した部分で，Explicitメモリブロック初期化に失敗したことが確認できます。また，[EVO][Thread: 0x00035a60]で始まる行は，イベントが発生した時のスタックトレースを示しています。

さらに，JavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「debug」を指定した場合，初期化に失敗したイベント以外のExplicitメモリブロック初期化イベントの詳細情報が出力されます。Explicitメモリブロック数が一定以上になると，初期化は失敗します。このため，初期化に失敗する前の初期化イベントの情報が，調査に役立つことがあります。

出力例を次に示します。

[EVO]<Tue Jul 24 01:23:51 2007>[Created]["BasicExplicitMemory-2" eid=2(0x1234568)/B][Thread: 0x00035a60]
[EDO][Thread: 0x00035a60] at ExplicitMemory.registerExplicitMemory(Native Method)
[EDO][Thread: 0x00035a60] at BasicExplicitMemory.<init>(Unknown Source)
[EDO][Thread: 0x00035a60] at AllocTest.test(AllocTest.java:64)
[EVO][Thread: 0x00035a60] at java.lang.Thread.run(Thread.java:2312)

背景色付きの太字で示した部分で，Explicitメモリブロック初期化イベントであることが確認できます。また，[EDO][Thread: 0x00035a60]で始まる行は，イベントが発生した時のスタックトレースを示しています。

(2)　スレッドダンプで出力されたログファイルからの調査

スレッドダンプで出力された情報からは，Explicitメモリブロック初期化失敗の直接要因は確認できませんが，Explicitメモリブロックの個数は調べられます。

出力例を次に示します。

Explicit Heap Status
--------------------
 max 65536K, total 21888K, used 20992K, garbage 1288K (32.0% used/max, 95.9% used/total, 6.1% garbage/used), 2 spaces exist

 Explicit Memories(0x12345678)

  "EJBMgrData" eid=1(0x02f25610)/R, total 21376K, used 20480K, garbage 1234K (95.8% used/total, 6.0% garbage/used, 0 blocks) Enable

  "ExplicitMemory-4" eid=4(0x02f45800)/B, total 512K, used 512K, garbage 54K (100.0% used/total, 10.5% garbage/used, 0 blocks) Disable

背景色付きの太字で示した部分がExplicitメモリブロックの個数を示しています。

(3)　JavaのAPIからの調査

次に示すメソッドを使用して，Explicitメモリブロックの個数を調査できます。

JP.co.Hitachi.soft.jvm.ExplicitMemory.countExplicitMemories()

ただし，このAPIでは，Explicitメモリブロック初期化失敗の直接の要因は確認できません。

7.14.5　Explicitメモリブロック明示解放処理時にJavaヒープへのオブジェクト移動が発生した場合の確認と対処

Explicitメモリブロック明示解放処理時に，解放対象のExplicitヒープ内のオブジェクトに対する参照があると，参照されているオブジェクトおよびそのオブジェクトから直接または間接的に参照されているオブジェクトがJavaヒープに移動します。オブジェクトは，Tenured領域に優先的に移動されます。このため，移動が多いとTenured領域の利用済みサイズが増加して，FullGC発生の要因となってしまいます。

Javaヒープへの移動が発生したかどうかは，JavaVMログファイルの拡張verbosegc情報または明示管理ヒープイベントログで調査できます。

(1)　拡張verbosegc情報を使用した確認

明示管理ヒープ機能を利用しない場合，Tenured領域の利用済みサイズの増加は，CopyGCだけで発生します。このため，N回目のCopyGC終了後のTenured領域利用済みサイズは，N+1回目のCopyGC開始前のTenured領域利用済みサイズと一致します。

これに対して，ExplicitヒープからJavaヒープへのオブジェクトの移動が発生した場合は，Explicitヒープ解放時にTenured領域の利用済みサイズが増加します。この差分から，Explicitメモリブロック明示解放処理時にオブジェクトの移動が発生したことが確認できます。

N回目のCopyGC終了後のExplicitメモリブロック明示解放処理時にJavaヒープに移動したオブジェクトのサイズは，次の式で算出できます。

ExplicitヒープからJavaヒープに移動したオブジェクトのサイズ
=N+1回目のCopy GC前のTenured領域利用済みサイズ
 -N回目のCopy GC後のTenured領域利用済みサイズ

(2)　明示管理ヒープのイベントログを使用した確認

JavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「none」以外を指定した場合，Explicitメモリブロックの明示解放処理についてのログが出力されます。このログでは，Explicitメモリブロック明示解放処理時のTenured領域利用済みサイズの増加を直接確認できます。

出力例を次に示します。

[ENS]<Tue Jul 24 01:23:51 2007>[EH: 12800K->11776K(11776K/65536K), 0.1129602 secs][E/F/D: 523/0/0]¥
[DefNew::Eden: 0K->0K(243600K)][DefNew::Survivor: 0K->0K(17400K)][Tenured: 103400K->103464K(556800K)][cause:Reclaim]

背景色付きの太字で示した部分のうち，[cause:Reclaim]は，Explicitメモリブロック明示解放処理時に出力された情報であることを示します。また，[DefNew::Eden: 0K->0K(243600K)][DefNew::Survivor: 0K->0K(17400K)][Tenured: 103400K->103464K(556800K)]の部分は，Explicitメモリブロック明示解放処理時のJavaヒープの変化を示しています。この例の場合は，Tenured領域のメモリサイズが103,400キロバイトから103,464キロバイトに，64キロバイト分増えています。このことから，Explicitメモリブロックの明示解放処理で，64キロバイトのオブジェクトがJavaヒープに移動していることがわかります。

また，JavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「verbose」を指定した場合，解放されたExplicitメモリブロックについての情報も出力されます。これによって，どのExplicitメモリブロックの解放でTenured領域利用済みサイズが増加したかを確認できます。

出力例を次に示します。

[ENS]<Tue Jul 24 01:23:51 2007>[EH: 12800K->11776K(11776K/65536K), 0.1129602 secs][E/F/D: 523/0/0]¥
[DefNew::Eden: 0K->0K(243600K)][DefNew::Survivor: 0K->0K(17400K)][Tenured: 103400K->103464K(556800K)][cause:Reclaim]
[EVS]["REM2" eid=2/R: 320K]["BEM3" eid=5/B: 320K]["BEM1" eid=7/B: 384K]

背景色付きの太字で示した部分が，解放されたExplicitメモリブロックを示しています。出力内容から，Javaヒープに移動した64キロバイトのオブジェクトが，「REM2」「BEM3」「BEM1」のどれかのExplicitメモリブロックから移動したことがわかります。

さらに，JavaVMの-XX:HitachiExplicitMemoryLogLevelオプションに「debug」を指定した場合，明示解放処理をしたときに解放対象Explicitヒープ内のオブジェクトを参照していたオブジェクトが確認できます。

出力例を次に示します。

[EDO][eid=3: Reference to ClassZ(0x1234680), total 64K]
[EDO]   ClassU(0x1233468)(Tenured)

[eid=3: Reference to ClassZ(0x1234680), total 64K]の部分から，次のことがわかります。

Javaヒープへ移動したオブジェクトは"ClassZ"のインスタンスである。

"ClassZ"のインスタンスから参照されていることによってJavaヒープに移動したオブジェクトの合計サイズは64キロバイトである。

また，「ClassU(0x1233468)(Tenured)」の部分から，"ClassZ"のインスタンスを参照しているオブジェクトが"ClassU"のインスタンスであることがわかります。

これらの情報を基に，Explicitメモリブロック明示解放処理時にそのExplicitメモリブロック内のオブジェクトへの参照をなくすように，Javaプログラムを修正してください。

7.14.6　Explicitメモリブロックの自動解放処理が長時間化した場合の確認と対処

Explicitメモリブロックの自動解放処理が長時間化した場合の確認と対処について説明します。

Explicitメモリブロックの自動解放処理は，GCと同じタイミングで発生し，自動解放処理中はJ2EEサーバの処理が停止します。このため，自動解放処理が長時間化すると，システム上問題となることがあります。

巨大なサイズを持つExplicitメモリブロック（以降，巨大ブロックといいます）が生成されると，自動解放処理に長時間掛かるようになります。巨大ブロックは，アプリケーションの停止まで使用されるオブジェクトなど，FullGCでも回収されないオブジェクトがExplicitヒープに配置されると生成されることがあります。このため，Explicitヒープに配置しないほうがよいオブジェクトはJavaヒープに配置するようにして，巨大ブロックの生成を防止する必要があります。巨大ブロックが生成されて自動解放処理が長時間化してしまう現象については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.10.2　自動解放処理に掛かる時間を短縮する仕組み」，および「付録B.1　Explicitメモリブロックの自動解放処理への影響」を参照してください。

巨大ブロックが生成されているかどうかは，スレッドダンプの内容から調査できます。

巨大ブロックが生成されている場合は，次に示す対処手順に従って，巨大ブロックの要因となるオブジェクトをJavaヒープに配置するように設定してください。

対処手順

Explicitメモリブロックへのオブジェクト移動制御機能の適用

明示管理ヒープ機能適用除外クラス指定機能の適用

巨大ブロックの要因となるオブジェクトの特定とそのオブジェクトのExplicitヒープへの移動防止

Javaヒープ領域およびExplicitヒープ領域の再チューニング

ここでは，巨大ブロックが生成されているかどうかの確認方法と，対処方法について説明します。

(1)　巨大ブロックが生成されているがどうかの確認

eheapprofコマンドを実行して，スレッドダンプに出力されたExplicitヒープ情報を確認します。

出力例を次に示します。

  "NULL" eid=1(0x1000000000123456)/B, total 112K, used 55K, garbage 0K (49.2% used/total, 0.0% garbage/used, 0 blocks) Enable
  "NULL" eid=2(0x1000000000223456)/A, total 153744K, used 144766K, garbage 0K (94.2% used/total, 0.0% garbage/used, 0 blocks) Enable
  "ReferenceExplicitMemory-2" eid=3(0x1000000000323456)/R, total 112K, used 55K, garbage 0K (49.3% used/total, 0.0% garbage/used, 0 blocks) Enable

注

Explicitメモリブロックの名称の"NULL"は，一度自動解放処理を実施したExplicitメモリブロックであることを示します。

背景色付きの太字で示した「total」の部分がExplicitヒープの確保済みメモリサイズを示します。

この例の場合，各Explicitメモリブロックの「total」に示すメモリサイズは，eid=2のExplicitメモリブロックは153,744キロバイトであり，eid=1やeid=3のExplicitメモリブロックの112キロバイトに比べて，極端に大きなサイズになっています。このことから，巨大ブロックが生成され，それがeid=2のExplicitメモリブロックであることがわかります。

(2)　Explicitメモリブロックへのオブジェクト移動制御機能の適用

明示管理ヒープ機能のイベントログでExplicitヒープの利用状況の推移を調査します。Explicitヒープの利用状況の推移の調査方法については，「7.14.2　利用状況の推移の調査」を参照してください。

出力例を次に示します。

[ENS]<Thu Oct 21 14:55:50 2007>[EH: 12672K->172032K(172032K/196608K)][E/F/D: 200/0/0][cause:Full GC][CF: 0]
[ENS]<Thu Oct 21 14:55:50 2007>[EH: 172032K->172032K(172032K/196608K), 0.1124626 secs][E/F/D: 200/0/0]¥
[DefNew::Eden: 0K->0K(243600K)][DefNew::Survivor: 0K->0K(17400K)][Tenured: 103400K->103400K(556800K)]¥
[target:584K/0K/584K][cause:Migrate]

背景色付きの太字で示した「EH:」で始まる部分が，Explicitヒープの利用状況を示します。

この例の場合，「cause:」で始まる部分に示すとおり，1行目はFullGC発生時に出力されたログで，その直後にある2行目はExplicitメモリブロックの自動解放処理（Migrate）時に出力されたログです。このことから，FullGCの直後に自動解放処理が発生したことがわかります。1行目のログの「EH:」で始まる部分から，FullGC発生前のExplicitヒープの利用済みサイズは12,672キロバイト，発生後のExplicitヒープの利用済みサイズは172,032キロバイトであり，Explicitヒープの使用サイズが大幅に増加していることがわかります。なお，このような現象（Explicitヒープの使用サイズの大幅な増加）が発生していない場合は，手順(3)に進んでください。

この例のように，FullGC発生時にExplicitヒープの使用サイズが大幅に増加している場合は，-XX:ExplicitMemoryFullGCPolicyオプションに1を指定して，Explicitメモリブロックへのオブジェクト移動制御機能を適用してください。この機能を適用すると，FullGC発生時に参照関係に基づくオブジェクトをExplicitメモリブロックへ移動しなくなります。Explicitメモリブロックへのオブジェクト移動制御機能については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.10　Explicitメモリブロックの自動解放処理に掛かる時間の短縮」を参照してください。

この機能を適用して，巨大ブロックの生成を防止できるようになった場合は手順(5)に，巨大ブロックがまだ生成されている場合は手順(3)に進んでください。

(3)　明示管理ヒープ機能適用除外クラス指定機能の適用

次の現象が発生している場合は，-XX:+ExplicitMemoryUseExcludeClassオプションを指定して，明示管理ヒープ機能適用除外クラス指定機能を適用してください。

自動解放処理直前に実施されたFullGCのExplicitヒープの利用状況で，Explicitヒープの使用サイズに大幅な増加が見られない

Explicitメモリブロックへのオブジェクト移動制御機能を適用（手順(2)を実施）しても，巨大ブロックが生成されている

明示管理ヒープ機能適用除外クラス指定機能を適用すると，特定のクラスのオブジェクトをExplicitヒープへ移動させなくなります。特定のクラスのオブジェクトとは，システムで提供している明示管理ヒープ機能適用除外設定ファイル（sysexmemexcludeclass.cfg）に記述されているクラスのオブジェクトのことです。明示管理ヒープ機能適用除外クラス指定機能については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.10　Explicitメモリブロックの自動解放処理に掛かる時間の短縮」を参照してください。

この機能を適用して，巨大ブロックの生成を防止できるようになった場合は手順(5)に，巨大ブロックがまだ生成されている場合は手順(4)に進んでください。

(4)　巨大ブロックの要因となるオブジェクトの特定とそのオブジェクトのExplicitヒープへの移動防止

手順(3)で明示管理ヒープ機能適用除外クラス指定機能を適用しても，巨大ブロックがまだ生成されている場合は，次に示すオブジェクトがExplicitヒープに移動されて，巨大ブロックが生成されていることがあります。これらのオブジェクトのうち生存し続けるオブジェクトは，Explicitメモリブロックの自動解放処理で回収されません。

Javaアプリケーション内のユーザ作成クラスのオブジェクト

使用しているフレームワークによって自動的に作成されるオブジェクト

このため，これらの一定期間で回収されないオブジェクトをExplicitヒープに配置しても明示管理ヒープ機能の効果がないため，Javaヒープ（Tenured領域）に配置する方が適切です。これらのオブジェクトのうち，巨大ブロックの要因となっているオブジェクトを特定し，Explicitヒープへ移動しないようにします。

巨大ブロックの要因となるオブジェクトを特定する場合，オブジェクト解放率情報を調査します。オブジェクト解放率情報は，Explicitメモリブロックの自動解放処理で解放されたオブジェクトの割合です。eheapprofコマンドに-freeratioオプションを指定して実行すると，スレッドダンプに出力されたExplicitヒープ情報にオブジェクト解放率情報が出力されます。

出力例を次に示します。

  "NULL" eid=1(0x1000000000123456)/B, total 112K, used 55K, garbage 0K (49.2% used/total, 0.0% garbage/used, 0 blocks) Enable
    deployed objects
    ________________Size__Instances__FreeRatio__Class________________
                   49256         10          0 [B
                    3680          4         20 package1.session.StandardManager
                   52936         14 total

  "NULL" eid=2(0x1000000000223456)/A, total 153744K, used 144766K, garbage 0K (94.2% used/total, 0.0% garbage/used, 0 blocks) Enable
    deployed objects
    ________________Size__Instances__FreeRatio__Class________________
                77862918     433523         10 [C
                52622946     441714         10 java.lang.String
                12838192      39462         35 [B
                    3680          4         20 package1.session.StandardManager
                     104          4          0 framework.ut.impl.performList
               143327840     914707 total

  "ReferenceExplicitMemory-2" eid=3(0x1000000000323456)/R, total 112K, used 55K, garbage 0K (49.3% used/total, 0.0% garbage/used, 0 blocks) Enable
    deployed objects
    ________________Size__Instances__FreeRatio__Class________________
                   49256          4          - [B
                    3416         10          - package3.ajp.RequestHandler
                      64          2          - java.lang.StringBuffer
                      64          1          - java.net.SocketInputStream
                      48          1          - [I
                      24          1          - [C
                   52872         19 total

注1

Explicitメモリブロックの名称の"NULL"は，一度自動解放処理を実施したExplicitメモリブロックであることを示します。

注2

クラス名の[BはByteクラスの配列型，[CはCharクラスの配列型，[IはIntegerクラスの配列型を示します。

背景色付きの太字で示した「total」の部分がExplicitヒープの確保済みメモリサイズを，「FreeRatio」の部分がオブジェクト解放率情報を示します。

この例の場合，Explicitメモリブロックは，eid=1，eid=2，eid=3の三つがあります。各Explicitメモリブロックの「FreeRatio」に示すオブジェクト解放率情報を見てみると，eid=3のExplicitメモリブロックのオブジェクト解放率情報は「-」で，自動解放処理が実行されなかったことがわかります。

まず，各Explicitメモリブロックの「total」に示すメモリサイズを見てみます。eid=2のExplicitメモリブロックは153,744キロバイトであり，eid=1やeid=3のExplicitメモリブロックの112キロバイトに比べて，極端に大きなサイズになっています。このことから，eid=2のExplicitメモリブロックが巨大ブロックであることがわかります。

次に，巨大ブロック（eid=2）内のオブジェクトのクラスごとに，オブジェクト解放率とExplicitメモリブロック内のサイズを見てみます。この例では，五つのオブジェクトがあり，そのオブジェクトのクラスにはJava SEが提供しているクラス（「[B」，「[C」，「java.lang.String」）も含まれています。ほとんどの場合，Java SEが提供しているクラスは，巨大ブロックの要因となるオブジェクトから参照されてExplicitメモリブロックへ移動します。このため，巨大ブロックの要因となるオブジェクトをExplicitメモリブロックへ移動しないようにすれば，Java SEが提供しているクラスのオブジェクトの移動も防止できます。また，Java SEが提供しているクラスを明示管理ヒープ機能適用除外クラス指定機能の対象にすると，影響範囲が広く，理想的なExplicitメモリブロック上に配置されたオブジェクトにも制約が生じます。そのため，Java SEが提供しているクラスは，明示管理ヒープ機能適用除外クラス指定機能の対象にしないでください（ただし，Java SEが提供しているクラスのオブジェクトすべてをJavaヒープに配置しても問題ない場合は除きます）。

Java SEが提供しているクラス以外のクラスには，「package1.session.StandardManager」と「framework.ut.impl.performList」があります。「package1.session.StandardManager」のオブジェクトはeid=1のExplicitメモリブロックでも使用されていますが，eid=1は巨大ブロックになっていません。このことから，このクラスのオブジェクトは巨大ブロックの要因とならないことがわかります。これによって，「framework.ut.impl.performList」のオブジェクトが，巨大ブロックの要因となるオブジェクトであると特定できます。

巨大ブロックの要因となるオブジェクトを特定したあと，明示管理ヒープ機能適用除外クラス指定機能で使用する設定ファイルに，そのオブジェクトのクラスを記述してください。設定ファイルへの記述方法については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.13.3　設定ファイルを使った明示管理ヒープ機能の適用対象の制御」を参照してください。

(5)　Javaヒープ領域およびExplicitヒープ領域の再チューニング

オブジェクト移動制御機能や，明示管理ヒープ機能適用除外クラス指定機能を適用すると，オブジェクトの配置される領域が変わり，JavaヒープおよびExplicitヒープのメモリサイズにも増減が発生します。このため，次の個所で説明している方法を参照して，再度，各領域のメモリサイズをチューニングしてください。

7.4　Javaヒープのチューニング

7.5　Javaヒープ内のTenured領域のメモリサイズの見積もり

7.6　Javaヒープ内のNew領域のメモリサイズの見積もり

7.7　Javaヒープ内に一定期間存在するオブジェクトの扱いの検討

7.8　Javaヒープの最大サイズ／初期サイズの決定

7.9　Javaヒープ内のMetaspace領域のメモリサイズの見積もり

7.10　拡張verbosegc情報を使用したFullGCの要因の分析方法

7.11　Explicitヒープのチューニング

7.12　アプリケーションで明示管理ヒープ機能を使用する場合のメモリサイズの見積もり

7.13　明示管理ヒープ機能の自動配置機能を使用したExplicitヒープの利用の検討

7.15　G1GCの仕組み

ここでは，G1GCの仕組みを説明します。

7.15.1　G1GCの概要

GCは，プログラムが使用し終わったメモリ領域を自動的に回収して，ほかのプログラムが利用できるようにするための技術です。

GCの実行中は，プログラムの処理が停止します。このため，GCを適切に実行できるかどうかが，システムの処理性能に大きく影響します。

プログラムの中でnewによって作成されたJavaオブジェクトは，JavaVMが管理するメモリ領域に格納されます。Javaオブジェクトが作成されてから不要になるまでの期間を，Javaオブジェクトの寿命といいます。

Javaオブジェクトには，寿命の短いオブジェクトと寿命の長いオブジェクトがあります。サーバサイドで動作するJavaアプリケーションの場合，リクエストやレスポンス，トランザクション管理などで，多くのJavaオブジェクトが作成されます。これらのJavaオブジェクトは，その処理が終わると不要になる，寿命が短いオブジェクトです。一方，アプリケーションの動作中使用され続けるJavaオブジェクトは，寿命が長いオブジェクトです。

効果的なGCを実行するためには，寿命の短いオブジェクトに対してGCを実行して，効率良くメモリ領域を回収することが必要です。また，繰り返し使用される寿命の長いオブジェクトに対する不要なGCを抑止することが，システムの処理性能の低下防止につながります。これを実現するのが，世代別GCです。

世代別GCでは，Javaオブジェクトを，寿命が短いオブジェクトが格納されるNew領域と，寿命が長いオブジェクトが格納されるTenured領域に分けて管理します。New領域はさらに，newによって作成されたばかりのオブジェクトが格納されるEden領域と，1回以上のGCの対象になり，回収されなかったオブジェクトが格納されるSurvivor領域に分けられます。New領域内で一定回数以上のGCの対象になったJavaオブジェクトは，長期間必要なJavaオブジェクトと判断され，Tenured領域に移動します。

世代別GCで管理するメモリ空間とJavaオブジェクトの概要を次の図に示します。

図7‒16　世代別GCで管理するメモリ空間とJavaオブジェクトの概要

G1GCの世代別GCで実行されるGCには，次の3種類があります。

YoungGC

Eden領域とSurvivor領域を対象にしたGCです。Javaオブジェクトの作成によって，Eden領域を使い切ると発生します。

注意

アプリケーションサーバでは，SerialGCとG1GC（UseG1GC）が選択できます。ほかのParallelGC，ConcurrentGC，IncrementalGCは使用できません。

MixedGC

Eden領域とSurvivor領域とTenured領域の一部を対象にしたGCです。Concurrent Markingと呼ばれるオブジェクトの解析処理に基づき発生します。Javaオブジェクトの作成によって，Eden領域を使い切ると発生します。

FullGC

Tenured領域も含む，JavaVM固有領域全体を対象にしたGCです。Tenured領域やMetaspace領域，Humongous領域を新たに確保できないと発生します。

一般的に，YoungGCとMixedGCの方が，FullGCよりも短い時間で処理できます。

次に，GCの処理について，あるJavaオブジェクト（オブジェクトA）を例にして説明します。

Eden領域で実行される処理

オブジェクトAの作成後，1回目のYoungGCまたはMixedGCが実行された時点で使用されていない場合，オブジェクトAは破棄されます。

1回目のYoungGCまたはMixedGCが実行された時点で使用されていた場合，オブジェクトAはEden領域からSurvivor領域に移動します。

Survivor領域で実行される処理

Survivor領域に移動したオブジェクトAは，その後何回かYoungGCまたはMixedGCが実行されると，Survivor領域からTenured領域に移動します。移動する回数のしきい値は，JavaVMオプションやJavaヒープの利用状況によって異なります。図7-16では，しきい値をn回としています。

Survivor領域への移動後，n回目未満のYoungGCまたはMixedGCが実行された時点でオブジェクトAが使用されていなかった場合，オブジェクトAはそのYoungGCまたはMixedGCで破棄されます。

Tenured領域で実行される処理

オブジェクトAがTenured領域に移動した場合，その後のYoungGCでオブジェクトAが破棄されることはありません。YoungGCは，Eden領域とSurvivor領域だけを対象としているためです。MixedGCが発生した場合は，Tenured領域内の一部のオブジェクトが破棄されます。

MixedGCで破棄されるオブジェクトの数よりも，Tenured領域に移動するオブジェクトの数が多い場合，Tenured領域の使用サイズは増加します。新たにTenured領域を確保できなくなると，FullGCが発生します。

JavaVMのチューニングでは，JavaVMオプションでそれぞれのメモリ空間のサイズや割合を適切に設定することで，不要なオブジェクトがTenured領域に移動することを抑止します。これによって，FullGCが頻発することを防ぎます。

7.15.2　オブジェクトの寿命と年齢の関係

オブジェクトがYoungGCまたはMixedGCの対象になった回数をオブジェクトの年齢といいます。

オブジェクトの寿命と年齢の関係を次の図に示します。

図7‒17　オブジェクトの寿命と年齢の関係

アプリケーションが開始して初期化処理が完了したあとで，何度かのYoungGCまたはMixedGCが実行されると，長期間必要になる寿命の長いオブジェクトはTenured領域に移動します。このため，アプリケーションの開始後しばらくすると，Javaヒープの状態は安定し，作成されるJavaオブジェクトとしては，寿命が短いオブジェクトが多くなります。特に，New領域のチューニングが適切にできている場合，Javaヒープが安定したあとの大半のオブジェクトは，1回目のYoungGCまたはMixedGCで回収される，寿命が短いオブジェクトになります。

7.15.3　New領域を対象としたGCの仕組み

JavaVMでは，YoungGCまたはMixedGCの対象になるNew領域のメモリ空間を，Eden領域，Survivor領域に分けて管理します。さらに，Survivor領域は，From空間とTo空間に分けられます。From空間とTo空間は，同じメモリサイズです。

New領域の構成を次の図に示します。

図7‒18　New領域の構成

Eden領域は，newによって作成されたオブジェクトが最初に格納される領域です。プログラムでnewが実行されると，Eden領域のメモリが確保されます。

Eden領域がいっぱいになると，YoungGCまたはMixedGCが実行され，次の処理が実行されます。

Eden領域およびSurvivor領域のFrom空間にあるJavaオブジェクトのうち，使用中のJavaオブジェクトが，Survivor領域のTo空間にコピーされます。使用されていないJavaオブジェクトは破棄されます。

Survivor領域のTo空間とFrom空間が入れ替わります。

この結果，Eden領域とTo空間は空になり，使用中のオブジェクトはFrom空間に存在することになります。

YoungGCまたはMixedGC実行時に発生するオブジェクトの移動を次の図に示します。

図7‒19　CopyGC実行時に発生するオブジェクトの移動

このようにして，使用中のオブジェクトは，YoungGCまたはMixedGCが発生するたびに，From空間とTo空間を行ったり来たりします。ただし，寿命の長いオブジェクトを行き来させ続けると，移動処理の負荷などが問題になります。これを防ぐために，From空間とTo空間でJavaオブジェクトを入れ替える回数にしきい値を設定して，年齢がしきい値に達したJavaオブジェクトはTenured領域に移動させるようにします。

7.15.4　オブジェクトの退避

年齢がしきい値に達していないJavaオブジェクトがTenured領域に移動することを，退避といいます。退避は，YoungGCまたはMixedGC実行時にEden領域およびFrom空間で使用中のオブジェクトが多くなり，移動先であるTo空間のメモリサイズが不足する場合に発生します。この場合，To空間に移動できなかったオブジェクトが，Tenured領域に移動します。

図7‒20　オブジェクトの退避

オブジェクトの退避が発生した場合，Tenured領域に本来格納されないはずの寿命の短いオブジェクトが格納されます。これが繰り返されると，YoungGCまたはMixedGCで回収されるはずのオブジェクトがメモリ空間に残っていくため，Javaヒープのメモリ使用量が増加していき，最終的にはFullGCが発生します。

オブジェクトの退避が発生した場合のメモリ使用量の変化について，次の図に示します。

図7‒21　オブジェクトの退避が発生した場合のメモリ使用量の変化

FullGCでは，システムが数秒から数十秒停止することがあります。

したがって，メモリ空間の構成とメモリサイズを検討するときには，オブジェクトの退避が発生しないように，Eden領域とSurvivor領域のバランスを検討する必要があります。

7.15.5　メモリ空間とリージョンの関係

G1GCで管理するJavaヒープ領域は，オブジェクトの寿命が短いオブジェクトが格納されるNew領域と，寿命が長いオブジェクトが格納されるTenured領域に分けて管理します。このうちNew領域はさらに2つの領域に分けて管理されており，作成されたばかりのオブジェクトが格納されるEden領域と，1回以上のGCの対象になり，回収されなかったオブジェクトが格納されるSurvivor領域に分けられます。New領域内で一定回数以上のGCの対象になったオブジェクトは，寿命が長いオブジェクトと判断され，Tenured領域に移動します。Survivor領域では使用中のオブジェクトと使用済みのオブジェクトが混在するFrom空間と，使用中のオブジェクトだけが存在するTo空間が必要なタイミングで動的に確保されます。タイミングの違いから，From空間とTo空間はどちらか一方だけが存在します。

アプリケーション実行中のG1GCで管理するメモリ空間の構成を次の図に示します。なお，Eden領域，Survivor領域，Tenured領域，Free領域を合わせた領域をJavaヒープ領域といいます。

図7‒22　アプリケーション実行中のG1GCで管理するメモリ空間の構成

G1GCでは，Tenured領域があらかじめ割り当てられていません。Tenured領域にオブジェクトを移動させる場合，Free領域のリージョンをTenured領域に割り当ててオブジェクトを移動します。また，G1GCではGC後にNew領域に対して拡張や縮小をします（以降，リサイズ）。リサイズでNew領域を拡張する場合は，Free領域のリージョンに割り当て，縮小する場合はNew領域のリージョンを回収し，Free領域に割り当てます。サイズの大きなオブジェクトを作成する場合は，Humongous領域にオブジェクトが格納されます。

各領域の用途を次に示します。

New領域

寿命が短いオブジェクトが格納される領域です。Eden領域とSurvivor領域から構成されます。GC後に次のGCに向けてリサイズされます。詳細については，「7.15.8　YoungGC」を参照してください。

Eden領域

作成されたオブジェクトが最初に格納される領域です。

Survivor領域

New領域に格納されていたオブジェクトのうち，GC実行時に回収されなかったオブジェクトが格納される領域です。Survivor領域はFrom空間とTo空間で構成されます。From空間とTo空間は同じサイズです。

Tenured領域

寿命が長いオブジェクトが格納される領域です。Survivor領域で指定回数を超えてGC実行対象になり，回収されなかったオブジェクトが移動します。

Humongous領域

Tenured領域の一部でサイズの大きなオブジェクトを格納する領域です。Humongous領域のオブジェクトは，FullGCまたはRemarkフェーズで回収されます。

Free領域

New領域やTenured領域に割り当てられていない領域です。Tenured領域のリージョンが足りなくなった場合やGC後のNew領域をリサイズする場合に，New領域やTenured領域に割り当てられます。

Metaspace領域

ロードされたclassなどの情報を格納する領域です。なお，Metaspace領域はリージョン単位で管理されていません。Metaspace領域のオブジェクトはFullGCでだけ回収されます。

「図7-22　アプリケーション実行中のG1GCで管理するメモリ空間の構成」はJavaヒープ領域の各領域を連続領域として表現していますが，実際には各領域は連続領域として確保されていません。G1GCではJavaヒープ領域をリージョンと呼ばれるブロック単位で管理しており，次の図のように領域が分散して確保されています。

図7‒23　実際のメモリ空間の構造

ここではそれぞれの領域のリージョンを領域名＋リージョンと表記します。例えば，Eden領域のリージョンをEdenリージョン，New領域のリージョンはNewリージョンと表記します。

7.15.6　リージョンの使われ方

オブジェクトが作成されると，最初にEdenリージョンに格納されます。1つのオブジェクトのサイズが，リージョンサイズの半分を越えている大きいオブジェクト※の場合は，1つのオブジェクトに対し，連続した複数のリージョンが割り当てられ格納されます。連続した複数のリージョンはFree領域から確保され，Humongous領域に割り当てられます。Humongous領域はFullGCでだけ回収の対象となるため，サイズの大きなオブジェクトが多数作成されるような場合には，G1GCは不向きとなります。詳細については，「7.16.3(1)　FullGCの発生を抑止する考え方」を参照してください。

また，1つのリージョンのサイズは，起動時にJavaヒープ領域の初期サイズの比率から求められ，起動中は固定です。1つのリージョンの最小サイズは1メガバイトであり，最大サイズは32メガバイトです。

注※

ここでいうサイズの大きな1つのオブジェクトとは，多数のインスタンスフィールドを持つオブジェクトや長大な配列を持つオブジェクトのことを指します。リージョンのサイズが1メガバイトの場合，512キロバイトを超えるようなオブジェクトを指し，例えば約13万個のint型のインスタンスフィールドを持つようなオブジェクトや約50万個の要素数のバイト配列を持つオブジェクトなどが当てはまります。

次にリージョンの使用から回収までの流れを示します。

図7‒24　リージョンの使われ方

上図はリージョンの使われ方を示した図です。図の1.〜4.の処理の詳細を次に示します。

オブジェクト作成時

オブジェクトが作成される場合，Edenリージョンにオブジェクトを格納します。サイズの大きなオブジェクトを作成する場合は，FreeリージョンをHumongousリージョンに割り当てオブジェクトを格納します。Edenリージョンに空き領域がなくなると，新しいEdenリージョンにオブジェクトを格納し，Humongousリージョンに空き領域がなくなると，新たにFreeリージョンからHumongousリージョンを割り当て，オブジェクトを格納します。

GC時の選択処理

GCの要件を満たすと，実行するGC方式の基準に従って，対象とするリージョンを選択します。

GC時のEvacuation

回収の対象となったリージョン内で使用中のオブジェクトは，ほかのリージョンにコピーされます。この処理をEvacuationといいます。Evacuation後のリージョンは，使用済みのオブジェクトとコピー済みである不要となったオブジェクトだけ格納されているため，リージョン単位で回収されます。

GC後

回収されたリージョンはFreeリージョンとなり，再利用されます。

7.15.7　G1GCで実行されるGC

G1GCの世代別GCで実行されるGCには，次の3種類があります。

YoungGC

New領域を対象とするGCです。YoungGCにはYoungGC(normal)とYoungGC中にマーキングをするYoungGC(initial-mark)があります。詳細については，「7.15.8　YoungGC」を参照してください。なお，単にYoungGCと表記した場合，YoungGC(normal)とYoungGC(initial-mark)の両方に当てはまる事項となります。また，YoungGC(normal)とYoungGC(initial-mark)を区別して表す場合は，“(normal)”と“(initial-mark)”を明記します。ただし，ログファイルのGC種別にはYoungGC(normal)はYoungGCという種別で出力します。YoungGCはJavaオブジェクトの作成によって，Eden領域を使い切ると発生します。

MixedGC

New領域とTenured領域を対象とするGCです。Tenuredリージョンは目標停止時間に併せて部分的な範囲を対象とします。詳細については，「7.15.10　MixedGC」を参照してください。MixedGCはYoungGC同様，Javaオブジェクトの作成によって，Eden領域を使い切ると発生しますが，Concurrent Markingと呼ばれるオブジェクトが使用中かどうかの解析処理の結果に基づいて発生します。詳細については，「7.15.9　Concurrent Marking（CM）」を参照してください。そのため，解析が十分にされていない場合や解析の結果MixedGCの効果が低いと予測される場合は，YoungGC(normal)が発生します。

FullGC

Tenured領域やMetaspace領域，Humondous領域を含む，JavaVM固有領域全体を対象にしたGCです。詳細については，「7.15.11　FullGC」を参照してください。Tenured領域やMetaspace領域，Humongous領域を確保できなかった場合に発生します。

それぞれのGCが対象とする領域をまとめると次の図となります。

図7‒25　各GCの対象範囲

また，JDK11以前の場合とJDK17以降の場合での各GCの状態遷移図を次の図に示します。

図7‒26　各GCの状態遷移図（JDK11以前の場合）

YoungGC(normal)実行後，CMが実行されておらず，Tenured領域の使用率がJavaヒープ領域の45%を超えた場合は，次のGCではYoungGC(initial-mark)を実行する状態に遷移します。

YoungGC(normal)実行後，CMが実行されておらず，Tenured領域の使用率がJavaヒープ領域の45%以下の場合は，次のGCもYoungGC(normal)を実行する状態のままです。

YoungGC(initial-mark)実行後，次のGCではYoungGC(normal)とCMを並行して実行する状態に遷移します。

CMが実行中の場合は，YoungGC(normal)を実行する状態のままです。

CM終了直後のYoungGC(normal)で予測回収率が10%を超えている場合，次のGCではMixedGCを実行する状態に遷移します。

予測回収率が10%以下の場合，次のGCもYoungGC(normal)を実行する状態のままです。

MixedGC実行後，予測回収率が10%を超えている場合，次のGCではMixedGCを実行する状態のままです。

MixedGC実行後，予測回収率が10%以下の場合，次のGCではYoungGC(normal)を実行する状態に遷移します。

図7‒27　各GCの状態遷移図（JDK17以降の場合）

YoungGC(normal)実行後，CMが実行されておらず，Tenured領域の使用率がJavaヒープ領域の45%を超えた場合は，次のGCではYoungGC(initial-mark)を実行する状態に遷移します。

YoungGC(normal)実行後，CMが実行されておらず，Tenured領域の使用率がJavaヒープ領域の45%以下の場合は，次のGCもYoungGC(normal)を実行する状態のままです。

YoungGC(initial-mark)実行後，次のGCではYoungGC(normal)とCMを並行して実行する状態に遷移します。

CMが実行中の場合は，YoungGC(normal)を実行する状態のままです。

CM終了直後のYoungGC(normal)で回収対象のTenured領域のリージョンが存在する場合，次のGCではMixedGCを実行する状態に遷移します。

回収対象のTenured領域のリージョンが存在しない場合，次のGCもYoungGC(normal)を実行する状態のままです。

MixedGC実行後，回収対象のTenured領域のリージョンが存在する場合，次のGCではMixedGCを実行する状態のままです。

MixedGC実行後，回収対象のTenured領域のリージョンが存在しない場合，次のGCではYoungGC(normal)を実行する状態に遷移します。

注

回収効率の悪いリージョンについて，Javaヒープサイズの10%分をあらかじめ除外して回収対象のTenured領域のリージョンを決定します。これによって，回収効率を高めています。

ただし，次の場合GCの状態によらず条件を満たすと対応するGCを実行します。

YoungGCまたは，MixedGCを実行しても空き領域を確保できなかった場合，FullGCを実行します。FullGC実行後はYoungGC(normal)を実行する状態に遷移します。

サイズの大きなオブジェクトを確保時，CMが実行されておらず，Tenured領域の使用サイズと確保するオブジェクトのサイズの合計がJavaヒープ領域の45%を超えた場合，YoungGC(initial-mark)を実行します。

次に，G1GCの処理の流れについて，Javaオブジェクトを例にして説明します。

図7‒28　G1GCの流れ

YoungGC

上図のようにNew領域に割り当てたリージョンに空きがなくなるとYoungGCが発生します。YoungGCでは使用中のオブジェクトはSurvivor領域に割り当てたリージョンに移動し，使用済みのオブジェクトはリージョンごと解放します。また，SerialGCのCopyGCと同様，YoungGC発生時に使用中のオブジェクトはSurvivor領域に割り当てたリージョン間を移動し続け，ある一定の回数を移動するとTenured領域に割り当てたリージョンに移動します。YoungGC後上図のようにGCにかかった時間から，次のGCにかかる時間を予測し，New領域のサイズを変更します。上図の場合は，予測した時間よりGCにかかる時間が長いため，New領域を縮小した場合の例です。

MixedGC

Tenured領域の使用率が増加すると，MixedGCが発生します。MixedGCではNew領域に割り当てたリージョンに加えて，目標停止時間内に収まる範囲で，一部のTenured領域に割り当てたリージョンをGCの対象とします。この一部のTenured領域に割り当てたリージョンは，アプリケーションと並行して実行しているオブジェクトが使用中かどうかの解析情報に基づき，解放されるサイズが大きいと予測されるリージョンから優先してGCの対象となります。そのため，オブジェクトの情報解析が十分にされていない場合や解析の結果MixedGCの効果が低い場合は，MixedGCは発生しません。

FullGC

Javaヒープ内のリージョンに空きがなくなり，MixedGCが発生しない場合，Javaヒープ全体を対象としてFullGCが発生します。

7.15.8　YoungGC

図7‒29　YoungGCの流れ

(1)　実行契機

YoungGC(normal)

Eden領域にオブジェクトを確保できなかった場合に発生します。また，サイズの大きなオブジェクトをHumongous領域に確保できなかった場合にも発生します。

YoungGC(initial-mark)

直前に実行されたYoungGC(normal)終了時に，Tenured領域の使用サイズがJavaヒープ領域の45%を超えていた場合，1.の実行契機を満たすとYoungGC(initial-mark)が実行されます。また，サイズの大きなオブジェクトを確保時，Tenured領域の使用サイズとオブジェクトの確保サイズの合計サイズがJavaヒープ領域の45%を超えた場合，YoungGC(initial-mark)が実行されます。

(2)　対象範囲

New領域

(3)　処理内容

YoungGCが発生するとシングルスレッドでリージョンの選択処理をし，その後マルチスレッドでEvacuationをします。

YoungGCのEvacuationではEden領域とFrom空間内の使用中のオブジェクトをTo空間またはTenured領域に移動し，Eden領域とFrom空間を回収します。移動や回収の仕組みはCopyGCの仕組みと同じです。CopyGCの詳細については，「7.2.3　CopyGCの仕組み」を参照してください。

YoungGCでは，これまでに発生したGCのGC停止時間の統計から予測をし，次回のGCの予測停止時間が目標停止時間内に収まるようにNew領域のサイズを変更します。

New領域は最小サイズと最大サイズが存在し，その範囲内でリサイズをします。New領域は全GCで対象となるため，GC停止時間はNew領域が最小サイズの場合にかかるGC停止時間より短くすることはできません。

CMが終了後のYoungGCでは，予測回収サイズがJavaヒープ領域の10%を超えていた場合，次回のGCをMixedGCにするか判定します。次回のGCにMixedGCが選択された場合，Tenuredリージョンを多く対象とするように予測してNew領域のサイズを変更します。

YoungGC(initial-mark)のEvacuationではEvacuation中にローカル変数や使用中のオブジェクトから直接参照されているオブジェクトにマーク付けをします。このマーキングの結果は，Concurrent Markingに利用されます。Concurrent Markingの処理の詳細については，「7.15.9　Concurrent Marking（CM）」を参照してください。

(4)　処理結果

Eden領域：オブジェクトが回収され，空になります。GC後リサイズされます。

Survivor領域：From空間のオブジェクトが回収され，空になります。GC後リサイズされます。

Tenured領域：長期間必要と判断されたオブジェクトがTenured領域に移動します。

Humongous領域：変化はありません。

Metaspace領域：変化はありません。

Free領域：GC後のリサイズによって，増減します。

(5)　アプリケーションの停止の有無

停止します。

(6)　ほかのGCとの関係

CM：YoungGC中に実行されません。

MixedGC：YoungGC中に実行されません。

FullGC：YoungGC中に実行要件を満たすと，YoungGCを中止して実行されます。

(7)　補足

関連オプション

Evacuationをするスレッド数は-XX:ParallelGCThreadsオプションで変更することができます。スレッド数を増やすとYoungGCにかかる時間が小さくなります。また，オプションを指定しない場合，スレッド数は-XX:ParallelGCThreadsオプションのデフォルト値が用いられます。-XX:ParallelGCThreadsオプションについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「14.5　Application Serverで指定できるJava HotSpot VMのオプション」の-XX:ParallelGCThreadsを参照してください。

確認方法

YoungGCの確認はログ上のGCの種別が“YoungGC”または“YoungGC(initial-mark)”であることから確認できます。また，New領域のリサイズはEden領域のサイズ変化とSurvivor領域のサイズ変化から確認できます。

[VG1]<Wed Jun 12 11:21:10 2013>[Young GC 899070K/899072K(1048576K)->501755K/501760K(1048576K), 0.0931560 secs][Status:-][G1GC::Eden: 389120K(389120K)->0K(397312K)][G1GC::Survivor: 41984K->41984K][G1GC::Tenured: 459776K->459776K][G1GC::Humongous: 2048K->2048K][G1GC::Free: 609536K->607232K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:G1EvacuationPause][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.2495800 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 171][CCI: 2301K, 49152K, 2304K]

上記のログの場合GC前のNew領域のサイズは389120K＋41984K＝431104Kであり，GC後のNew領域のサイズは397312K＋41984K＝439296Kであるため，New領域が拡張されたことが分かります。ログの記述内容や詳細に関しては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

7.15.9　Concurrent Marking（CM）

図7‒30　Concurrent Markingの流れ

(1)　実行契機

CMは大きく次の4つの処理から構成されます。それぞれの実行契機について示します。なお，1.〜4.の表記は上図の1.〜4.に対応しています。

Concurrent Root Region Scan：

YoungGC(initial-mark)終了後，実行されます。

Concurrent Mark：

1.の終了後，1.に続けて実行されます。

Remark：

2.の終了後，アプリケーションを停止できるタイミングで実行されます。

Cleanup：

3.の終了後，アプリケーションを停止できるタイミングで実行されます。

(2)　対象範囲

New領域，Tenured領域およびHumongous領域

(3)　処理内容

CMは大きく次の4つの処理から構成されます。それぞれの処理の詳細を示します。

Concurrent Root Region Scan：

ローカル変数や使用中のオブジェクトから直接参照されているSurvivor領域内のオブジェクトにマークを付ける処理です。マルチスレッドで実行されます。

Concurrent Mark：

YoungGC(initial-mark)のマーキングと1.のマーキングでマークを付けたオブジェクトが参照しているオブジェクトにマークを付ける処理です。マルチスレッドで実行されます。

Remark：

2.のマーキング中に参照関係が変化したオブジェクトのマークを付け直す処理です。マルチスレッドで実行されます。

Cleanup：

リージョンごとに使用中のオブジェクトの合計サイズを求める処理です。また，次のCMに備え，マークの初期化もします。マルチスレッドで実行されます。

(4)　処理結果

Eden領域：

使用中のオブジェクトに対応した領域にマークが付きます。

3.の処理でEdenリージョンが回収された場合，領域サイズが減少します。

Survivor領域：

使用中のオブジェクトに対応した領域にマークが付きます。

3.の処理でSurvivorリージョンが回収された場合，領域サイズが減少します。

Tenured領域：

使用中のオブジェクトに対応した領域にマークが付きます。

3.の処理でTenuredリージョンが回収された場合，領域サイズが減少します。

Humongous領域：

使用中のオブジェクトに対応した領域にマークが付きます。

3.の処理でHumongousリージョンが回収された場合，領域サイズが減少します。

Metaspace領域：

変化はありません。

Free領域：

使用中のオブジェクトが1つも存在しないリージョンを回収した場合,領域サイズが増加します。

(5)　アプリケーションの停止の有無

Concurrent Root Region Scan：

CMスレッドで，アプリケーションを停止しないで実行されます。

Concurrent Mark：

CMスレッドで，アプリケーションを停止しないで実行されます。

Remark：

VMスレッドで，アプリケーションを停止して実行されます。

Cleanup：

VMスレッドで，アプリケーションを停止して実行されます。

(6)　ほかのGCとの関係

注　CMの処理中はYoungGC(initial-mark)は発生しません。

Concurrent Root Region Scan：

YoungGC(normal)：実行されません。

MixedGC：実行されません。

FullGC：実行されません。

Concurrent Mark：

YoungGC(normal)：2.の処理中に実行された場合，2.の処理を中断します。YoungGC(normal)が終了すると，再開されます。

MixedGC：実行されません。

FullGC：2.の処理中に実行された場合，2.の処理を中止します。途中結果は破棄されます。

Remark：

YoungGC(normal)：実行されません。

MixedGC：実行されません。

FullGC：実行されません。

Cleanup：

YoungGC(normal)：実行されません。

MixedGC：実行されません。

FullGC：実行されません。

(7)　補足

関連オプション

CMをするスレッド数は-XX:ConcGCThreadsオプションで指定できます。CMをするスレッド数を増やすとスループットが低下します。-XX:ConcGCThreadsオプションを指定しなかった場合，スレッド数は-XX:ConcGCThreadsオプションのデフォルト値となります。詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「14.5　Application Serverで指定できるJava HotSpot VMのオプション」の-XX:ConcGCThreadsを参照してください。

確認方法

Concurrent Root Region Scan，Concurrent Markの確認はログの先頭に［VCM］の識別子が付いていることから確認できます。Concurrent Markのログのイメージを次に示します。

[VCM]<Wed Jul 31 11:45:23 2013>[Concurrent Mark Start][User: 0.0000000 secs][Sys: 0.0000000 secs]
[VCM]<Wed Jul 31 11:45:31 2013>[Concurrent Mark End][User: 0.0321549 secs][Sys: 0.0129454 secs]

VCMのログが複数行にわたるため，CMログは開始時にStart，終了時にEndが出力されます。複数行に渡る場合，CPU使用時間はEndのログにStartからEndまでの処理時間が出力され，Startのログは0が出力されます。ログの記述内容や詳細に関しては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

またRemark，Cleanupの処理は処理中にアプリケーションを停止するため，VG1ログに出力されます。Remark，Cleanupの処理はGCログのGC種別が“CM Remark”，“CM Cleanup”という出力から判断できます。

7.15.10　MixedGC

図7‒31　MixedGCの処理の流れ（JDK11以前の場合）

図7‒32　MixedGCの処理の流れ（JDK17以降の場合）

(1)　実行契機

JDK11以前の場合

予測回収サイズがJavaヒープ領域の10%を超えている場合，次のGCにMixedGCが予約されます。その判定はCM終了直後のYoungGC(normal)終了時，またはMixedGCの終了時にされます。

JDK17以降の場合

回収対象のTenured領域のリージョンが存在する場合，次のGCにMixedGCが予約されます。その判定はCM終了直後のYoungGC(normal)終了時，またはMixedGCの終了時にされます。

(2)　対象範囲

New領域とTenured領域の一部

(3)　処理内容

MixedGCが発生すると，シングルスレッドでリージョンの選択処理を，マルチスレッドでEvacuationを実行します。

MixedGCではNew領域をGC対象とし，予測停止時間が目標停止時間に収まる範囲でTenured領域を部分的にGC対象に追加します。

MixedGCのEvacuationでは，New領域に対してはYoungGCのEvacuationと同じ処理をします。詳細については，「7.15.8　YoungGC」を参照してください。

GC対象に追加したTenured領域に対しては，Tenuredリージョン内の使用中のオブジェクトを別のTenuredリージョンに詰め直します。

JDK11以前の場合，MixedGC後も予測回収サイズがJavaヒープ領域の10%を超えているときは継続してMixedGCが選択され，要件を満たしていないときは通常のYoungGCが実行されます。

JDK17以降の場合，MixedGC後も回収対象のTenured領域のリージョンが存在するときは継続してMixedGCが選択され，要件を満たしていないときは通常のYoungGCが実行されます。

(4)　処理結果

Eden領域：

オブジェクトが回収され，空になります。GC後リサイズされます。

Survivor領域：

From空間のオブジェクトが回収され，空になります。GC後リサイズされます。

Tenured領域：

長期間必要と判断されたオブジェクトがTenured領域に移動します。

GC対象に追加された領域のオブジェクトが回収されます。

Humongous領域：

変化はありません。

Metaspace領域：

変化はありません。

Free領域：

GC後のリサイズによって，増減します。

(5)　アプリケーションの停止の有無

停止します。

(6)　ほかのGCとの関係

CM：MixedGC中に実行されません。

YoungGC：MixedGC中に実行されません。

FullGC：MixedGC中に実行要件を満たすと，MixedGCを中止して実行されます。

(7)　補足

関連オプション

Evacuationをするスレッド数は-XX:ParallelGCThreadsオプションで変更することができます。スレッド数を増やすとMixedGCにかかる時間が小さくなります。また，オプションを指定しない場合，スレッド数はOSが認識しているCPU数が用いられます。-XX:ParallelGCThreadsオプションについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「14.5　Application Serverで指定できるJava HotSpot VMのオプション」の-XX:ParallelGCThreadsを参照してください。

確認方法（JDK11以前の場合）

MixedGCの確認はログのGCの種別の“Mixed GC”から確認できます。また，TargetTenuredの項目からMixedGCで選択されたTenured領域のサイズを確認できます。オブジェクトの予測回収サイズに関してはReclaimableの項目から確認できます。ログの記述内容や詳細に関しては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

[VG1]<Wed Jun 12 11:21:10 2013>[Mixed GC 899070K/899072K(1048576K)->501742K/501760K(1048576K), 0.0931560 secs][Status:-][G1GC::Eden: 389120K(389120K)->0K(397312K)][G1GC::Survivor: 41984K->41984K][G1GC::Tenured: 459776K->459776K][G1GC::Humongous: 2048K->2048K][G1GC::Free: 609536K->607232K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:G1EvacuationPause][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.2495800 secs][TargetTenured: 2048K][Reclaimable: 17703K(1.69%)][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 171][CCI: 2301K, 49152K, 2304K]

7.15.11　FullGC

図7‒33　FullGCの流れ

(1)　実行契機

Free領域がなくなり，Evacuationのコピー先が確保できなかった場合やHumongous領域が確保できなかった場合に実行されます。また，Metaspace領域の空き領域がなくなった場合やSystem.gc()が呼ばれた場合も実行されます。

(2)　対象範囲

New領域，Tenured領域，Humongous領域およびMetaspace領域

(3)　処理内容

FullGCはシングルスレッドでアプリケーションスレッドを停止して実行されます。

FullGCが発生すると目標停止時間に関係なく，GCが終了するまでアプリケーションを停止します。

FullGCの処理はSerialGCのFullGCと同じ処理です。FullGCを実行しても領域が確保できなかった場合は，OutOfMemoryが発生します。詳細については，「7.2　SerialGCの仕組み」を参照してください。

一般的に，YoungGCやMixedGCの方がFullGCに比べて短い時間で処理できます。

(4)　処理結果

Eden領域：オブジェクトが回収され，空になります。

Survivor領域：使用中のオブジェクトがTenured領域に移動し，空になります。

Tenured領域：使用中のオブジェクトが詰め直されます。

Humongous領域：使用中のオブジェクトが詰め直されます。

Metaspace領域：使用中のオブジェクトが詰め直されます。

Free領域：回収されたリージョンによって増加します。

(5)　アプリケーションの停止の有無

停止します。

(6)　ほかのGCとの関係

CM：FullGC中は実行されません。

YoungGC：FullGC中は実行されません。

MixedGC：FullGC中は実行されません。

(7)　補足

確認方法

FullGCの確認はログ上のGCの種別が“FullGC”であることから確認できます。また，FullGCではこれから実行するGCに対して予測をしないため，予測停止時間や予測回収サイズは0で表示されます。

[VG1]<Wed Jan 15 12:51:32 2014>[Full GC 130443K/131072K(131072K)->55462K/56320K(131072K), 2.3265610 secs][Status:-][G1GC::Eden: 0K(43008K)->0K(43008K)][G1GC::Survivor: 0K->0K][G1GC::Tenured: 131072K->56320K][G1GC::Humongous: 0K->0K][G1GC::Free: 0K->74752K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.0000000 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 2.1700000 secs][Sys: 0.0000000 secs][IM: 277185K, 261856K, 44544K][TC: 1168][DOE: 0K, 0][CCI: 5808K, 49152K, 5952K]

7.16　G1GCのチューニング

ここではG1GCのチューニング方法について記載します。チューニングはシステム構築時にし，システム要件を満たしていることを確認してから本番環境に適用してください。

Javaヒープ領域のサイズに関係するオプションの一覧を次の表に示します。なお，表の項番1〜8は図の番号と対応しています。

表7‒9　Javaヒープ領域内の各領域とMetaspace領域のサイズを指定するオプション

項番

オプション名

オプションの意味

1

-Xms<size>

Javaヒープの初期サイズを設定します。※1

2

-Xmx<size>

Javaヒープの最大サイズを設定します。※1

3

-XX:NewSize=<value>

New領域の最小サイズを設定します。※2

4

-XX:MaxNewSize=<value>

New領域の最大サイズを設定します。※2

5

-XX:NewRatio=<value>

New領域に対するTenured領域の割合を設定します。※2

New領域のサイズは次の式で求められます。

(New領域のサイズ)=(Javaヒープ領域のサイズ)/(NewRatio + 1)

6

-XX:SurvivorRatio=<value>

Survivor領域の最大で取ることができる領域サイズに対するNew領域の割合を設定します。

Survivor領域の最大で取ることができる領域サイズは次の式で求められます。

(Survivor領域のサイズ)※3=(New領域のサイズ)/SurvivorRatio

7

-XX:MetaspaceSize=<size>

Metaspace領域の初期サイズを設定します。※4

8

-XX:MaxMetaspaceSize=<size>

Metaspace領域の最大サイズを設定します。※4

注※1

-Xmsと-Xmxの値は同じ値を指定することを推奨します。

注※2

3〜5のオプションを指定した場合，New領域のリサイズが制限され，目標停止時間内にGC停止時間を抑えようとするG1GCのメリットを損なうため，G1GCでは指定しないことを推奨します。また，3〜5のオプションを指定しなかった場合，New領域の初期サイズはJavaヒープの初期サイズ×0.05のサイズが確保されます。また，Survivor領域のサイズは初期時点では0であるため，Eden領域の初期サイズはNew領域の初期サイズと等しくなります。

注※3

G1GCではFrom空間とTo空間が必要なタイミングで動的に確保されるため，両空間が同時に存在することはありません。したがって，Survivor領域のサイズはFrom空間またはTo空間と同じサイズになります。

注※4

-XX:MetaspaceSizeと-XX:MaxMetaspaceSizeの値は同じ値を指定することを推奨します。

図7‒34　Javaヒープ領域内の各領域とMetaspace領域のサイズとオプションの対象範囲

次にG1GCのチューニングに利用するオプションを次の表に示します。各オプションの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.5　Application Serverで指定できるJava HotSpot VMのオプション」の各オプションの説明を参照してください。

表7‒10　G1GCのチューニングオプション

項番

オプション名

デフォルト値

オプションの意味

1

-XX:MaxGCPauseMillis=<value>

200

目標停止時間[ms]

2

-XX:ParallelGCThreads=<value>

CPU数※

(OSが認識しているCPU数)

Evacuationの処理をするスレッド数

3

-XX:ConcGCThreads=<value>

(ParallelGCThreads + 2) / 4

CM処理をするスレッド数

注※

実行環境のCPU数によって計算式が異なります。

7.16.1　チューニングの流れ

次にチューニングの全体の流れを示します。

図7‒35　チューニングの全体の流れ

次から，それぞれのチューニングの詳細を記載します。

7.16.2　初期検証

図7‒36　初期検証の流れ

図7-34は初期検証の流れを表した図です。

G1GCを有効にしてシステムの検証をします。検証の結果，システム要件を満たしている場合でも，FullGCの発生傾向がないか確認をします。システム要件を満たしていない場合は，「7.16.3　FullGCの発生を抑止するチューニング」へ進んでください。

検証中にFullGCが発生していない場合でも，システムを長期間動かすことで，将来FullGCが発生する場合があります。そのため，FullGCの発生傾向がないか確認をします。

図7‒37　FullGCの発生傾向のイメージ

図7-35は検証中のGC後の使用量をグラフにしたイメージです。図7-35のようにMixedGCが発生していても，Javaヒープ使用量が長期的には単調増加している場合，FullGCの発生傾向があります。

システム要件を満たしている場合でも，FullGCの発生傾向があった場合，検証時間を延ばしFullGCを発生させ，FullGCが発生してもシステム要件が満たしているか確認をします。FullGCを発生させた結果，システム要件を満たさなくなった場合は，FullGCの発生を抑止するチューニングをします。また，検証時間を延ばすことができない場合は，FullGCが発生していなくても，FullGCの発生を抑止するチューニングをし，FullGCの発生傾向をなくしてください。FullGCの発生を抑止するチューニングについては，「7.16.3　FullGCの発生を抑止するチューニング」を参照してください。

7.16.3　FullGCの発生を抑止するチューニング

(1)　FullGCの発生を抑止する考え方

図7‒38　FullGCの発生を抑止するチューニングの流れ

FullGCはTenured領域の使用サイズが増加し続け，Freeリージョンが確保できなくなった場合実行されます。

次にFullGCの発生を抑止するチューニングのイメージを示します。

図7‒39　FullGCの発生を抑止するチューニングのイメージ

FullGCの発生を抑止するには，Tenured領域の使用サイズの増加を防ぐ必要があります。そのため，FullGCの発生を抑止するには次の2つの方法が考えられます。

Tenured領域へ移動するオブジェクト数を減らす

Tenured領域内で不要なオブジェクトを回収する

Survivor領域あふれが発生している場合は，1の方法で，発生していない場合は2の方法でチューニングしてください。1の方法の詳細については，「7.16.3(3)　Survivor領域のサイズチューニング」を，2の方法の詳細については，「7.16.3(4)　MixedGCで選択されるリージョンを増やすチューニング」を参照してください。チューニングをした場合，再度システムの検証をし，要件を満たしているか確認してください。

(2)　サイズの大きなオブジェクトが多数作成されている場合

1つのオブジェクトのサイズが大きいオブジェクトが多数作成される場合，連続した領域が確保できないで，FullGCが実行される場合があります。G1GCではメモリをリージョンで管理しているため，オブジェクトのサイズが大きいオブジェクトが多数作成されるシステムには不向きです。オブジェクトのサイズが大きいオブジェクトが多数作成されることによって，FullGCが発生している場合は，アプリケーションの改修をしてください。

サイズの大きなオブジェクトの確認はログのHumongousの項目から確認できます。

[VG1]<Wed Jan 15 12:51:32 2014>[Full GC 130443K/131072K(131072K)->55462K/56320K(131072K), 2.3265610 secs][Status:-][G1GC::Eden: 0K(43008K)->0K(43008K)][G1GC::Survivor: 0K->0K][G1GC::Tenured: 131072K->56320K][G1GC::Humongous: 1024K->0K][G1GC::Free: 0K->74752K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.0000000 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 2.1700000 secs][Sys: 0.0000000 secs][IM: 277185K, 261856K, 44544K][TC: 1168][DOE: 0K, 0][CCI: 5808K, 49152K, 5952K]

(3)　Survivor領域のサイズチューニング

Tenured領域へ移動するオブジェクト数を減らす方法は，Survivor領域にオブジェクトが存在する間に，オブジェクトを回収する方法です。Survivor領域の空き領域がなくなると，本来寿命の短いオブジェクトがSurvivor領域あふれによる退避でTenured領域に昇格します。そのため，Survivor領域を大きくすることで，寿命の短いオブジェクトをSurvivor領域で回収し，Tenured領域への移動量を減らします。

ログが次のように(to exhausted)が出力されている場合，Survivor領域あふれが発生しています。この場合Survivor領域を大きくするために，-Xmxオプションまたは-XX:SurvivorRatioオプションでチューニングをしてください。

[VG1]<Wed Jun 12 11:21:10 2013>[Young GC 899070K/899072K(1048576K)->501755K/501760K(1048576K), 0.0931560 secs][Status:to exhausted][G1GC::Eden: 389120K(389120K)->0K(397312K)][G1GC::Survivor: 41984K->41984K][G1GC::Tenured: 459776K->459776K][G1GC::Humongous: 2048K->2048K][G1GC::Free: 609536K->607232K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:G1EvacuationPause][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.2495800 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 171][CCI: 2301K, 49152K, 2304K]

チューニングに用いるオプション名とチューニング方法を次に示します。

-Xmxオプション

指定する値を大きくすることで，Javaヒープ領域のサイズが大きくなります。Javaヒープ領域全体のサイズが大きくなることで，Survivor領域のサイズも大きくなります。ただし，Javaヒープ領域の最大サイズを大きくすると，New領域がリサイズされる範囲の最小値と最大値が大きくなります。これによって最小停止時間が大きくなるため，チューニングをした後に再度システム要件を満たしているか検証してください。

-XX:SurvivorRatioオプション

指定する値を小さくすることで，New領域に対するSurvivor領域の最大で取ることができる領域サイズの割合を大きくします。ただし，この方法はEden領域がチューニング前に比べて小さくなるおそれがあるため，YoungGCやMixedGCが発生しやすくなる副作用があります。そのため，チューニングをした後に再度システム要件を満たしているか検証してください。

注意

Survivor領域を大きくする方法として-XX:NewRatioや-XX:NewSize，-XX:MaxNewSizeオプションを使ってNew領域のサイズを大きくする方法もあります。しかし，この場合GC後のNew領域のリサイズが制限されるため，New領域のサイズを変更するオプションの指定は推奨しません。

(4)　MixedGCで選択されるリージョンを増やすチューニング

MixedGCで対象とするリージョンを増やすには，1度のMixedGCの対象リージョンを増やす方法と，MixedGCの発生頻度を上げて対象リージョン延べ数を増やす方法があります。1度のMixedGCの対象リージョン数を増やす方法はレスポンスが低下し，対象リージョンの延べ数を増やす方法はスループットが低下します。システム要件にあわせてチューニング方法を選択してください。

-XX:MaxGCPauseMillisオプション

指定する値を大きくすることで，目標停止時間が大きくなります。MixedGCではNew領域とTenured領域の一部を対象としてGCをします。Tenured領域はNew領域を選択しても予測停止時間に対して目標停止時間に余裕がある場合に選択されます。そこで，目標停止時間を大きくすることで，1度のMixedGCで選択されるTenuredリージョンの数が増えます。ただし，この方法はGC停止時間が長くなるため，レスポンスが低下します。

-XX:ConcGCThreadsオプション

指定する値を大きくすることで，CMをするスレッド数が増えます。MixedGCが実行されるためには，CMが終了している必要があります。そのため，CMをするスレッド数を増やし，CMの終了間隔を短くします。これによってMixedGCの発生回数が増え，MixedGCで選択されるリージョンの延べ数が増えます。ただし，この方法では，アプリケーションスレッドと並行して処理をするスレッド数が増えるため，スループットが低下します。

また，CMスレッド数はEvacuationをするスレッド数より多い値を指定できません。そのため，-XX:ConcGCThreadsオプションと併せて，-XX:ParallelGCThreadsオプションの値も大きくする必要があります。

7.16.4　最悪レスポンス時間を短くするチューニング

図7‒40　最悪レスポンス時間を短くするチューニングの流れ

このチューニングは，GCによるアプリケーションの停止時間を短くすることで，最悪レスポンス時間を短くする方法です。そのため，レスポンス時間のうち，GCによるアプリケーションの停止時間が占める割合が大きい場合に有用です。GCによるアプリケーションの停止時間は，VG1ログのgc_timeの項目から取得できます。VG1ログの詳細については，マニュアル「アプリケーションサーバアプリケーションサーバ リファレンス 定義編(サーバ定義)」の「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

最悪レスポンス時間を短くするには，GCによるアプリケーションの停止時間を短くする必要があります。G1GCでは停止時間を指定することができるため，指定する値を小さくすることで最悪レスポンス時間を短くします。

-XX:MaxGCPauseMillisオプション

指定する値を小さくすることで，目標停止時間が短くなり，最悪レスポンス時間が短くなります。ただし，この方法ではGC回数が多くなりスループットが低下します。そのため，最悪レスポンス時間を短くするチューニングをした場合，再度システム要件を満たしているか検証してください。また，G1GCではどのGCでもNew領域をGCの対象とするため，New領域の回収にかかる時間以下にはGC時間を抑えられません。それ以上GC停止時間を短くできないGC停止時間を最小停止時間と呼びます。目標停止時間を短くしても最悪レスポンス時間が短くならない場合は，ログのGC停止時間を確認してください。

GC停止時間は次のログの背景色付き太字の部分から確認できます。

[VG1]<Wed Jun 12 11:21:10 2013>[Young GC 899070K/899072K(1048576K)->501755K/501760K(1048576K), 0.0931560 secs][Status:-][G1GC::Eden: 389120K(389120K)->0K(397312K)][G1GC::Survivor: 41984K->41984K][G1GC::Tenured: 459776K->459776K][G1GC::Humongous: 2048K->2048K][G1GC::Free: 609536K->607232K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:G1EvacuationPause][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.2495800 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 171][CCI: 2301K, 49152K, 2304K]

目標時間を短くしてもGCの停止時間が短くなっていない場合は，最小停止時間に達しています。また，目標時間を最小停止時間に近づけすぎると，目標停止時間を超えたときの超え幅が大きくなり，最悪レスポンス時間が長くなる場合があります。目標停止時間を短くしてもシステム要件を満たせない場合は，チューニングではシステム要件を満たせません。そのため，アプリケーションの改修を行ってください。

7.16.5　スループットを向上させるチューニング

図7‒41　スループットを向上させるチューニングの流れ

スループットを向上させるためには，GCの発生回数を減らす必要があります。YoungGCやMixedGCは割り当てられたEden領域を使い切ると発生します。そこで，New領域を大きくすることでEden領域を大きくし，GCの発生回数を減らします。New領域を大きくするためには，-Xmxオプションまたは-XX:GCMaxPauseMillisオプションを用いてチューニングをします。

-Xmxオプション

指定する値を大きくすることで，Javaヒープ領域の最大サイズを大きくします。Javaヒープ領域の最大サイズが大きくなることで，New領域も大きくなります。

-XX:MaxGCPauseMillisオプション

指定する値を大きくすることで，目標停止時間が長くなります。YoungGCでは目標停止時間内に収まる範囲で，できるだけ大きくNew領域を取るため，目標停止時間を長くすることで，New領域も大きくなります。

スループットを向上させるチューニングをしてもスループットが向上しない場合は，New領域のサイズがリサイズされる範囲の最大サイズに達していることが考えられます。ログのEden領域＋Survivor領域の値の変化からリサイズがされているか確認してください。ログの確認方法の詳細については，「7.15.8　YoungGC」を参照してください。なお，スループットを向上させるチューニングをするとレスポンスが低下する場合があるため，チューニング後は性能の再検証をする必要があります。

7.17　ZGCの仕組み（JDK17以降の場合）

ここでは，ZGCの仕組みについて説明します。

7.17.1　ZGCの概要

ZGCは，チューニングが簡単で，かつ停止時間が短いスケーラブルなGCです。そのため，低レイテンシが要求されるシステム，および大規模なメモリ環境のシステムに適しています。

7.17.2　ZGCの用語

「7.17　ZGCの仕組み（JDK17以降の場合）」〜「7.18　ZGCのチューニング（JDK17以降の場合）」で使用する用語を次の表に示します。

表7‒11　ZGCの用語

用語

説明

ページ

Javaヒープ領域のメモリ空間を分割するブロックです。ZGCでは，Javaヒープ領域のメモリ空間を3種類のページに分割して管理しています。

ページの回収

オブジェクトを含んだページをページごと削除し，メモリ空間を再利用できるようにすることです。

フォワーディングテーブル

使用中のオブジェクトを再配置するときに，使用中のオブジェクトの古いアドレスから新しいアドレスへのマッピング情報を書き込むテーブルです。

7.17.3　JavaVMで使用するメモリ空間の構成

アプリケーション実行中のZGCで管理するメモリ空間の構成を次の図に示します。

図7‒42　アプリケーション実行中のZGCで管理するメモリ空間の構成

各ページのサイズについて説明します。

Smallページ

サイズは2メガバイトです。

Mediumページ

サイズは，Javaヒープの最大サイズの3.125%です。ただし，値は2の累乗の数値になるように切り捨てられます。また，値の範囲は2メガバイト〜32メガバイトです。なお，Javaヒープの最大サイズは-Xmxオプションで設定できます。-Xmxオプションの詳細は，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「14.5　Application Serverで指定できるJava HotSpot VMのオプション」を参照してください。

Largeページ

サイズは，Mediumページのサイズの12.5%より大きな値です。なお，サイズはページごとに異なります。

次に，各領域について説明します。

Free領域

ページが割り当てられていない領域を指します。この領域から，ページの新規作成に必要な領域を割り当てます。また，回収されたページの領域はFree領域に追加されます。

Metaspace領域

ロードされたクラスなどの情報が格納される領域を指します。

7.17.4　ZGCサイクル

ZGCでは，ZGCサイクルと呼ばれる一連の処理を実行することでGC処理をします。

ZGCサイクルの概要を次の図に示します。

図7‒43　ZGCサイクルの概要

ZGCサイクルは，アプリケーションとGC処理を並行して実行するフェーズ（M/R，RP，EC，RE）と，アプリケーションを一時停止してGC処理を実行するフェーズ（STW1，STW2，STW3）で構成されます。

各フェーズで実行する処理の内容は，次のとおりです。

(1)　STW1

M/Rフェーズでオブジェクトの参照をたどるときの起点となるオブジェクトをマークします。

(2)　M/R（mark/remap）

通常の参照を処理します。Javaヒープ領域内のすべてのオブジェクトに対して，使用中か使用済みかを判別し，マーキングします。マーキングの結果を基に，ECフェーズで回収するページを選択します。また，前回のZGCサイクルで回収したページに含まれていた使用中のオブジェクトを，フォワーディングテーブルを経由せずに直接参照できるようマッピング処理をします。

(3)　STW2

アプリケーションの実行を一時停止し，M/Rフェーズですべてのオブジェクトがマーキングされたかどうかを確認します。マーキングされていないオブジェクトがある場合は，再びM/Rフェーズを開始します。

(4)　RP（reference processing）

M/Rフェーズでのマーキング結果を基に，弱参照，ソフト参照，およびファントム参照をたどって，オブジェクトが使用済みかどうかを判別します。

(5)　EC（evacuation candidates）

M/RおよびRPフェーズでマーキングしたオブジェクトの情報を基に，回収するページを選択します。また，回収するページにある使用中のオブジェクトについて，現在のアドレスから新しいアドレスへのマッピング情報をフォワーディングテーブルに書き込みます。

(6)　STW3

現在のサイクルが終了してから次のサイクルが開始するまでの間で，REフェーズで移動する使用中のオブジェクトを参照する場合に，フォワーディングテーブルを介して参照できるようマッピング処理をします。

(7)　RE（relocation）

使用中のオブジェクトを，Free領域から割り当てたページにコピーします。そのあと，使用済みのオブジェクトをページごと回収します。これによって，使用済みのオブジェクトの削除が完了します。

7.17.5　Javaヒープ領域のメモリ管理方法

オブジェクト作成からGC完了までの流れを次の図に示します。

図7‒44　オブジェクト作成からGC完了までの流れ

(1)　オブジェクト作成時

オブジェクトのサイズに応じて，Smallページ，MediumページまたはLargeページにオブジェクトが配置されます。

各ページに配置されるオブジェクトは次のとおりです。

SmallページおよびMediumページ

各ページのサイズの12.5%以下のオブジェクトが配置されます。

Largeページ

Mediumページのサイズの12.5%より大きなオブジェクトが配置されます。ただし，Largeページに配置できるオブジェクトは，1ページごとに1つだけです。

なお，すでにオブジェクトがあるページに新しいオブジェクトを配置できる場合は，そのページを優先してオブジェクトを配置します。

(2)　回収するページの選択

使用済みのオブジェクトの割合に応じて，回収するページを選択します。この割合は，-XX:ZFragmentationLimitオプションで設定できます。詳細は，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「14.5　Application Serverで指定できるJava HotSpot VMのオプション」を参照してください。

(3)　使用中のオブジェクトのコピーとページの回収

選択したページに含まれる使用中のオブジェクトのサイズに応じて，Free領域からページを割り振り，使用中のオブジェクトをコピーします。そのあと，ページを回収して，削除します。Free領域が不足してコピーできない場合は，InPlaceを使用します。

InPlaceとは，回収するページ内に使用中のオブジェクトをコピーする方法です。これによって，Free領域が不足している場合でも，OutOfMemoryにならないでGC処理を実行できます。

InPlaceの概要を次の図に示します。

図7‒45　InPlaceの概要

(4)　GC完了

回収されたページの領域は，Free領域に追加されて再利用されます。

7.17.6　ZGC独自のGC発生要因

GC発生要因のうち，ZGCを使用している場合にだけ適用される要因について説明します。

表7‒12　ZGC独自のGC発生要因

GC発生要因

説明

ZTimer

前回のGCから，-XX:ZCollectionInterval=<seconds>オプションで指定した時間が経過したため，GCが発生しました。

ZWarmup

ZWarmup以外の要因のGCが発生していないときに，ヒープ領域の使用率が10%，20%または30%を超えたため，GCが発生しました。

ZAllocationRate

最大割り当て率と空きメモリ量から，OutOfMemoryが発生するおそれがあると判断されたため，GCが発生しました。

ZAllocationStall

アプリケーションの実行に必要なJavaヒープ領域の空き容量が不足しているため，GCが発生しました。

ZProactive

GCでスループットが低下してもシステムの動作に大きな影響がない場合に，前もってGCが発生しました。

ZHighUsage

Javaヒープ領域の95%以上が使用されたため，GCが発生しました。

7.18　ZGCのチューニング（JDK17以降の場合）

ここでは，ZGCを使用するためのチューニング方法について説明します。

7.18.1　ZGCでのGCの考え方

ZGCを使用している場合，GCは「先行して，前もって，予防的に」実行する必要があります。

ZGCでは，多くのGC処理をアプリケーションと同時に実行しています。そのため，アプリケーションがオブジェクトを作成する速度よりも，GC処理でオブジェクトを削除する速度の方が遅い場合，Javaヒープを有効に使用できません。

7.18.2　チューニングの流れ

ZGCを使用している場合のチューニングでは，OutOfMemoryを抑制するためにJavaヒープ領域の最大サイズを設定します。Javaヒープ領域の最大サイズの設定以外の方法でOutOfMemoryを抑制する場合は，「7.18.3　GC停止時間およびスループットの改善方法」を参照してください。

(1)　Javaヒープ領域の最大サイズの設定

Javaヒープ領域の最大サイズを設定する手順は次のとおりです。

SerialGCを有効にして，最大の負荷を掛けた状態でアプリケーションを実行します。

拡張verbosegc情報から，FullGC発生後のJavaヒープ領域のサイズを確認します。

FullGC発生後の拡張verbosegc情報の出力例を次に示します。下線部分がFullGC発生後のJavaヒープ領域のサイズです。

…
[VGC]<Wed Dec 28 14:12:05 2022>[Full GC 31780K->30780K(32704K), 0.2070500secs][DefNew::Eden: 3440K->1602K(3456K)][DefNew::Survivor:58K->0K(64K)][Tenured: 28282K->29178K(29184K)][Metaspace:1269K->1269K(4096K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

FullGC発生後の拡張verbosegc情報を何度か収集します。

手順3.で収集したFullGC発生後のJavaヒープ領域のサイズのうち，最も大きな値を，アプリケーションの動作に必要なJavaヒープ領域の最小サイズとします。

Javaヒープ領域の最大サイズを設定します。

-Xmxオプションを設定します。GC実行中のオブジェクトを余裕を持って作成できるようにするため，Javaヒープ領域の最大サイズは，手順4.で確認した値の1.5倍〜2倍に設定することを推奨します。

なお，Javaヒープ領域の初期サイズ（-Xmsオプション）は，最大ヒープサイズと同じ値に設定することを推奨します。

(2)　OutOfMemoryの発生調査

ZGCを有効にして，システムの検証を行います。OutOfMemoryが発生しているかどうかを確認し，結果に応じて次の作業を実施してください。

OutOfMemoryが発生している場合

-Xmsオプションの値を大きくしたあと，再度「(1)　Javaヒープ領域の最大サイズの設定」の手順を実施します。

OutOfMemoryが発生していない場合

チューニングは完了です。停止時間をさらに短くしたい場合，またはスループットを改善したい場合は，「7.18.3　GC停止時間およびスループットの改善方法」を参照してください。

7.18.3　GC停止時間およびスループットの改善方法

Javaヒープ領域の最大サイズの調整以外にGC停止時間およびスループットを改善する方法について説明します。ただし，この項で説明する方法は，GC停止時間が短くなる代わりにメモリの消費量が増えるなどの悪影響があるため，お使いの環境に合わせて実施してください。

GC停止時間をより短くしたい場合

-XX:ParallelGCThreadsオプションの値を大きくします

GC停止時間が短くなる代わりに，メモリの消費量が増えます。

スループットをより向上させたい場合

-XX:ConcGCThreadsオプションの値を小さくします

スループットが向上する代わりに，OutOfMemoryが発生しやすくなります。

-XX:ParallelGCThreadsを大きくします

スループットが向上する代わりに，メモリの消費量が増えます。

7.18.4　OSのパラメタ設定（Linuxの場合）

ZGCでは多くのメモリマップ領域を使用するため，OSで定義されているプロセスごとのメモリマップ領域の上限を増やしてください。

手順は次のとおりです。

次の計算式に従って，ZGC使用時のJavaプロセスのメモリマップ領域の数を算出してください。

ZGC使用時のJavaプロセスのメモリマップ領域の数 = Javaヒープ領域の最大サイズ / 2メガバイト × 3 × 1.2

算出した値を，/proc/sys/vm/max_map_countに設定してください。

7.19　ZGC使用時の他機能への影響（JDK17以降の場合）

ここでは，ZGC使用時の他機能への影響について説明します。

7.19.1　使用が制限される機能

ZGCを使用している場合，次の機能を使用できません。

(1)　クラス別統計機能

この機能の詳細は，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「9.3　クラス別統計機能」を参照してください。

また，次に示すコマンドおよびオプションが無効になります。

jheapprofコマンド

ZGCを使用している場合にこのコマンドを指定すると，次のエラーメッセージを出力して，スレッドダンプを出力しません。

jheapprof: can't use jheapprof and zgc at the same time.

このコマンドの詳細は，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「jheapprof（クラス別統計情報付き拡張スレッドダンプの出力）」を参照してください。

-XX:+HitachiOutOfMemoryAbortThreadDumpWithJHeapProfオプション

このオプションの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編（サーバ定義）」の「-XX:[+|-]HitachiOutOfMemoryAbortThreadDumpWithJHeapProf（クラス別統計情報出力オプション）」を参照してください。

(2)　クラス別統計情報解析機能

この機能の詳細は，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「9.10　クラス別統計情報解析機能」を参照してください。

(3)　Survivor領域の年齢分布情報出力機能

この機能の詳細は，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「9.11　Survivor領域の年齢分布情報出力機能」を参照してください。

(4)　ローカル変数情報出力機能

この機能の詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編（サーバ定義）」の「-XX:[+|-]HitachiLocalsInThrowable（例外発生時のローカル変数情報収集オプション）」を参照してください。

また，次のオプションが無効になります。

-XX:+HitachiLocalsInStackTraceオプション

-XX:+HitachiLocalsSimpleFormatオプション

これらのオプションの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.2　JavaVM拡張オプションの詳細」を参照してください。

(5)　メモリ情報取得機能

この機能の詳細は，マニュアル「アプリケーションサーバ リファレンスAPI編」の「10.5　MemoryInfoクラス」を参照してください。

7.19.2　出力内容が変更される機能

ZGCを使用している場合，次の機能で出力される内容が変更されます。

(1)　日立拡張VerboseGC機能

ZGCを使用している場合，ZGC向けの日立拡張Javaログが出力されます。

ZGC使用している場合の日立拡張Javaログの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「-XX:[+|-]HitachiVerboseGC（拡張verbosegc情報出力オプション）」を参照してください。

(2)　日立拡張スレッドダンプ機能

ZGCを使用している場合，Javaヒープ領域の構成がSerialGCおよびG1GCの場合と異なります。そのため，日立拡張スレッドダンプに出力されるJavaヒープ情報の出力フォーマットが異なります。日立拡張スレッドダンプの出力フォーマットの詳細については，アニュアル「アプリケーションサーバ機能解説 保守／移行編」の「4.7　JavaVMのスレッドダンプ」を参照してください。

(3)　エラーリポートファイル

ZGCを使用している場合，Javaヒープ領域の構成がSerialGCおよびG1GCの場合と異なります。そのため，エラーリポートに出力されるJavaヒープ情報の出力フォーマットが異なります。エラーリポートファイルの出力フォーマットの詳細については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「5.8　JavaVMが出力するメッセージログ（標準出力およびエラーリポートファイル）」を参照してください。

7.20　ZGC使用時の注意事項（JDK17以降の場合）

ここでは，ZGCを使用する場合の注意事項について説明します。

外部から観測できるメモリ使用量

ZGCでは，複数の異なる範囲の仮想アドレス空間を1つの物理アドレス空間に割り当てているため，OSが提供するツールでメモリ使用量を確認したとき，実際の使用量よりも値が大きくなることがあります。

例えば，Windowsで取得できるワーキングセット，Linuxで使用できるtopコマンド，およびpsコマンドで取得できるRES，RSSでは，複数の仮想アドレス空間がカウントされるため，実際の約3倍のメモリ使用量が表示されることがあります。

ユーザダンプおよびコアダンプのサイズ

ZGCでは，複数の異なる範囲の仮想アドレス空間を1つの物理アドレス空間に割り当てているため，ほかのGCを使用する場合よりも，ユーザダンプおよびコアダンプのサイズが大きくなります。

JavaVMがプロセスダウンした場合に生成されるユーザダンプおよびコアダンプのサイズは，使用する仮想アドレス空間の使用量（物理アドレス空間が割り当てられている量）と同じのため，ユーザダンプおよびコアダンプのサイズは，Javaヒープ領域の最大サイズの約3倍になります。

必要な仮想アドレス空間のサイズ

ZGCを使用している場合，ほかのGCを使用している場合よりも多くの仮想アドレス空間が必要です。これは，複数の仮想アドレス空間を同一の物理メモリにマッピングするというZGCの仕組みによるものです。物理メモリの実際の使用サイズには影響しません。ZGCを使用している場合に必要な仮想アドレス空間のサイズは次のとおりです。

Javaヒープ領域の最大サイズが4テラバイト未満の場合

必要な仮想アドレス空間のサイズは，次の計算式で算出した値です。ただし，最大値は12テラバイトです。

ZGC使用時に必要な仮想アドレス空間 = Javaヒープ領域の最大サイズ × 48

Javaヒープ領域の最大サイズが4テラバイト以上，8テラバイト未満の場合

必要な仮想アドレス空間のサイズは，24テラバイトです。

Javaヒープ領域の最大サイズが8テラバイト以上，16テラバイト以下の場合

必要な仮想アドレス空間のサイズは，48テラバイトです。

世代別ZGC（JDK21以降の場合）

世代別にオブジェクト管理することでパフォーマンスを向上させる世代別ZGCは，使用できません。

8　パフォーマンスチューニング（J2EEアプリケーション実行基盤）

この章では，J2EEアプリケーションを実行するシステムのパフォーマンスをチューニングする方法について説明します。

パフォーマンスチューニングによって動作環境を最適化することで，システムの性能を最大限に生かせるようになります。

バッチアプリケーション実行基盤のパフォーマンスチューニングについて検討する場合は，「9.　パフォーマンスチューニング（バッチアプリケーション実行基盤）」を参照してください。

8.1　パフォーマンスチューニングで考慮すること

この節では，J2EEアプリケーション実行基盤のパフォーマンスチューニングで考慮することについて説明します。

8.1.1　パフォーマンスチューニングの観点

J2EEアプリケーション実行基盤のパフォーマンスチューニングは，次の観点で実施します。

同時実行数の最適化

Enterprise Beanの呼び出し方法の最適化

データベースアクセス方法の最適化

タイムアウトの設定

Webアプリケーションの動作の最適化

CTMの動作の最適化

そのほかの項目のチューニング

それぞれのポイントについて説明します。

(1)　同時実行数の最適化

同時実行数の最適化は，処理を多重化してCPUの処理能力を最大限に引き出して，システムのスループットを向上させることを目的とします。しかし，次のような場合，多重化しただけではスループットが向上しません。場合によっては，スループットが低下するおそれがあります。

入出力処理，排他処理などのボトルネックがある場合

最大スループットに到達している場合

CPUの利用率が飽和した状態で多重度以上の負荷を掛けた場合

実行待ちキューのサイズが不適切な場合

階層的な最大実行数の設定が不適切な場合

パフォーマンスチューニングでは，これらを考慮しながら適切なチューニングを実施して，同時実行数の最適化を図ります。

(2)　Enterprise Beanの呼び出し方法の最適化

Enterprise Beanの呼び出し方法の最適化は，同じJ2EEアプリケーションや同じJ2EEサーバ内のコンポーネントを呼び出すときに，ローカルインタフェースやリモートインタフェースのローカル呼び出し機能を利用することで，不要なネットワークアクセスを削減することを目的とします。

次の機能を利用することで，RMI-IIOP通信によって発生する不要なネットワークアクセスを削減できます。

ローカルインタフェースの利用

リモートインタフェースのローカル呼び出し機能の利用

また，引数や戻り値の渡し方を参照渡しにすることで，さらに処理性能を向上できる場合があります。パフォーマンスチューニングでは，アプリケーションやシステムの特徴によってこれらの機能を有効に活用して，処理性能の向上を図ります。

(3)　データベースアクセス方法の最適化

データベースアクセス方法の最適化は，処理に時間が掛かるコネクションやステートメントを事前に生成しておくことで，データベースアクセス時のオーバーヘッドを削減することを目的とします。

パフォーマンスチューニングでは，次に示す機能を有効に活用することで，データベースアクセス処理を最適化し，スループットを向上させます。

コネクションプーリング

ステートメントプーリング（PreparedStatementおよびCallableStatementのプーリング）

(4)　タイムアウトの設定

タイムアウトの設定は，システムのトラブル発生を検知して，リクエストの応答が返らなくなることを防ぎ，適宜リソースを解放することを目的とします。

設定できるタイムアウトには，次の種類があります。

Webフロントシステムのタイムアウト

バックシステムのタイムアウト

トランザクションのタイムアウト

データベースのタイムアウト

(5)　Webアプリケーションの動作の最適化

Webアプリケーションの動作の最適化は，コンテンツの配置方法の検討やキャッシュの利用によって不要なネットワークアクセスを削減して処理速度を速めたり，負荷分散によってシステムのスループットの向上を図ったりすることを目的とします。

(6)　CTMの動作の最適化

CTMの動作の最適化は，CTMで使用するプロセス間の通信間隔を最適化して通信負荷を軽減したり，トラブル発生時に迅速に検知して対処したりすることで，システムとしての性能を向上させることを目的とします。また，CTMによってリクエストの処理に優先順位を付けることで，重要なリクエストをすばやく処理するようにもチューニングできます。

(7)　そのほかの項目のチューニング

アプリケーションサーバでは，(1)〜(6)で説明した項目以外にも，チューニングできる項目があります。必要に応じてチューニングを実施してください。

8.1.2　チューニング手順

パフォーマンスチューニングは，システムのパフォーマンスを生かす最適な設定を見つける作業です。構築した環境で，実際に処理を実行したり，模擬的な負荷を掛けたりしながら，パラメタの調整やボトルネックの調査，解消によってパフォーマンスを向上させていきます。

パフォーマンスチューニングの手順の例として，ここでは，同時実行数のチューニング手順を示します。

図8‒1　パフォーマンスチューニングの手順（同時実行数をチューニングする場合）

チューニング作業では，まず，目標値を決定します。ここでは，CPU利用率などが該当します。

次に，各パラメタに初期値を設定した状態でのスループットを測定し，そのあとで模擬的な負荷を掛けながら各パラメタを調整して，目標値に近い最適な値を見つけていきます。模擬的な負荷は，専用のツールを使用して発生させます。

チューニングの際，CPUの利用率の測定には，OSに付属している監視ツールなどが利用できます。スループットの測定は，負荷発生ツールなどによって測定できます。また，稼働スレッド数など，アプリケーションサーバの稼働情報については，稼働情報収集機能などで確認できます。確認方法については，マニュアル「アプリケーションサーバ機能解説 運用／監視／連携編」の「3.　稼働情報の監視（稼働情報収集機能）」を参照してください。

スループットが目標値に達したところで，パフォーマンスチューニングは完了です。なお，CPU利用率が100%からかなり低い状態で飽和した場合は，システム上に入出力処理や排他処理などのボトルネックがあるおそれがあります。ボトルネックを調査し，対策してから，再度パフォーマンスチューニングを実行してください。アプリケーションサーバのシステムのボトルネックの調査には，性能解析トレースを利用できます。性能解析トレースの機能詳細，および性能解析トレースを利用して取得したトレースファイルの利用方法については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」を参照してください。

8.1.3　アプリケーションの種類ごとにチューニングできる項目

チューニング項目は，アプリケーションの種類によって異なります。アプリケーションに含まれるコンポーネントごとのチューニング項目について，次に示します。

表8‒1　サーブレットとJSPで構成されるアプリケーション（Webアプリケーション）のチューニング項目

チューニング項目

利用できる機能

参照先

Webコンテナのリクエスト処理スレッド数の最適化

Webコンテナのリクエスト処理スレッド数の制御

8.3.3

同時実行数の最適化

Webアプリケーションでの同時実行スレッド数制御（Webコンテナ単位，Webアプリケーション単位，またはURLグループ単位）

8.3.4

データベースアクセス方法の最適化

コネクションプーリング

8.5.1

ステートメントプーリング

8.5.2

タイムアウトの設定

Webフロントシステムでのタイムアウトの設定

8.6.2

J2EEアプリケーションのメソッド実行時間に対するタイムアウトの設定

8.6.7

Webアプリケーションの動作の最適化

静的コンテンツとWebアプリケーションの配置の切り分け

8.7.1

静的コンテンツのキャッシュ

8.7.2

表8‒2　Enterprise Beanで構成されるアプリケーションのチューニング項目

チューニング項目

利用できる機能

参照先

同時実行数の最適化

Stateless Session Beanのインスタンスプーリング

8.3.5

Stateful Session Beanのセッション制御

Message-driven Beanのインスタンスプーリング

CTMによる同時実行数制御※（CTMを使用している場合）

8.3.6

Enterprise Beanの呼び出し方法の最適化

ローカルインタフェースの使用

8.4.1

リモートインタフェースのローカル呼び出し最適化

8.4.2

リモートインタフェースの参照渡し

8.4.3

データベースアクセス方法の最適化

コネクションプーリング

8.5.1

ステートメントプーリング

8.5.2

タイムアウトの設定

バックシステムでのタイムアウトの設定

8.6.3

トランザクションタイムアウトの設定

8.6.4

データベースでのタイムアウトの設定

8.6.6

J2EEアプリケーションのメソッド実行時間に対するタイムアウトの設定

8.6.7

注※　Stateless Session Beanだけが対象です。

また，CTMを使用したシステムの場合に設定できる，CTMの動作のチューニング項目を次の表に示します。CTMは，アプリケーションがStateless Session Beanで構成されている場合に使用できます。

表8‒3　CTMの動作についてのチューニング項目

チューニング項目

利用できる機能

参照先

CTMの動作の最適化

CTMドメインマネジャおよびCTMデーモンの稼働状態を監視する間隔のチューニング

8.8.1

負荷状況監視間隔のチューニング

8.8.2

CTMデーモンのタイムアウト閉塞の設定

8.8.3

CTMで振り分けるリクエストの優先順位の設定

8.8.4

8.2　チューニングの方法

この節では，チューニングの方法について説明します。チューニングの方法は，設定対象の種類によって異なります。

8.2.1　J2EEサーバおよびWebサーバのチューニング

J2EEサーバおよびWebサーバのチューニングには，Smart Composer機能の簡易構築定義ファイルを使用します。簡易構築定義ファイルでは，<configuration>タグ下の<logical-server-type>に設定対象とする論理サーバの種類（J2EEサーバまたはWebサーバ）を指定して，<param>タグ下でパラメタ名とその値を設定します。簡易構築定義ファイルの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

Smart Composer機能を使用できない場合，Webサーバのチューニングはファイルを編集して定義します。詳細については，マニュアル「HTTP Server」を参照してください。

8.2.2　アプリケーションまたはリソースのチューニング

アプリケーションおよびリソースのチューニングをする場合は，サーバ管理コマンドを使用します。

サーバ管理コマンドを使用する場合は，属性ファイルを編集します。属性ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」を参照してください。

8.2.3　CTMの動作のチューニング

CTMのチューニングには，Smart Composer機能の簡易構築定義ファイルを使用します。簡易構築定義ファイルでは，<configuration>タグ下の<logical-server-type>に設定対象とする論理サーバの種類（CTMドメインマネジャまたはCTM）を指定して，<param>タグ下でパラメタ名とその値を設定します。

簡易構築定義ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

8.2.4　それ以外の項目のチューニング

このほか，チューニングで使用するパラメタには，APIで設定する項目や，データベースで設定する項目などがあります。これらの設定については，それぞれの節のチューニングパラメタの説明を参照してください。

8.3　同時実行数を最適化する

この節では，アプリケーションのリクエストの同時実行数を最適化するための考え方とチューニング方法について説明します。

8.3.1　同時実行数制御および実行待ちキュー制御の考え方

アプリケーションサーバのシステムでアプリケーションのスループットを向上させるためには，複数のリクエストを多重処理することが有効です。複数のスレッドで多重にリクエストを処理した方が，単一スレッドで一度に1リクエストずつ処理するのに比べて，多くの場合，スループットを向上させられます。

ただし，入出力処理，排他処理などにボトルネックがあったり，すでに最大スループットに到達していたりする場合は，多重化によるスループットの向上はできません。このため，同時実行数のチューニングは，次の点を確認しながら進めます。

入出力処理，排他処理などのボトルネックの排除

スレッドを多重化してもCPU利用率が少ないままでスループットが向上しない場合は，アプリケーションのデータベースアクセスなどの入出力処理や排他処理などにボトルネックがあるおそれがあります。この場合は，ボトルネックになっている処理を特定して，排除してからチューニングする必要があります。例えば，データベースアクセス方法をチューニングしたり，排他処理方法を変更したりして，入出力処理，排他処理などのボトルネックを取り除きます。

最大スループットの確認

リクエストの多重度を大きくしてスレッド数を増やしていくと，スレッド数の増加に伴ってCPUの空き時間が減少し，さらに増やしていくと，ほとんどCPUの空き時間がない状態になります。この状態になると，スレッドを増やしてもスループットは上がりません。

これは，CPUがボトルネックになっている状態であり，マシン単体の性能として，限界に達している状態です。つまり，この時点のスループットが，マシン単体でのアプリケーションの最大スループットになります。

これ以上のスループットを確保したい場合は，CPUやマシン数を増加させるなど，ハードウェアの増強が必要になります。

同時実行数制御によるスループットの維持

CPUの利用率が飽和した状態で，さらに多重度を大きくしてスレッドを増やした場合，実行可能な状態でCPUが割り当てられないスレッドが増えます。この状態では，スレッド間のロックが競合したり，スレッドのコンテキストスイッチが多発したりするので，スループットが低下するおそれがあります。

また，スレッド数を増やすと，アプリケーションサーバ内ではスレッド数に応じてメモリ使用量が増えます。つまり，スループット低下とメモリ使用量の増加を防ぐためには，スレッド数の増加を実行可能なスレッド数までに制限する必要があります。

同時実行数制御機能を適切に使用することで，最大同時実行数をチューニングして，リクエストの多重度を大きくした場合でも，最大同時実行数分以上のリクエストの実行を待たせることができます。この結果，一時的に過負荷状態が発生したり，負荷のピークの状態になったりしても，高いスループットを維持できます。

実行待ちキューサイズの調整

アプリケーションサーバに到着したリクエストが同時実行数の上限を超えたとき，リクエストをキューに登録することで，実行中のほかのリクエストの処理が終わるまでそのリクエストを待たせることができます。しかし，ほかのリクエストの処理が終わるまでリクエストを待たせておくためのキューのサイズ（実行待ちキューサイズ）に上限を設定している場合，実行待ちキューが上限に達したあとで到着したリクエストについては，実行待ちキューには登録されないでクライアントにエラーとして返却されます。このため，実行待ちキューに上限を設定する場合は，待たせるキューに必要な数を確保しておく必要があります。

実行待ちキューへのリクエストの登録とエラーの返却の考え方を，次の図に示します。

図8‒2　実行待ちキューへのリクエストの登録とエラーの返却

ポイント

リクエストを実行待ちキューで待たせるのは，一時的な過負荷状態の場合や負荷のピークの場合にエラーが発生するのを防ぐためです。エラーが返却されるのを避けるために実行待ちキューサイズをむやみに増やすのは，本質的な解決にはなりません。同時実行数を増やしたり，必要に応じてCPUやマシン数を増設したりするなどの対処をしてください。

また，クライアント側でタイムアウトを設定している場合は，リクエストが実行待ちキューに登録されてから実際に実行されるまでの時間が掛かり過ぎると，リクエストの実行前にタイムアウトが発生してエラーになるおそれがあります。

このため，実行待ちキューサイズは，最適なサイズに設定してください。

階層的なアプリケーションでの最大同時実行数のバランス

あるレイヤだけをチューニングして同時実行数を増やしても，システム全体の性能は向上しません。これは，システム全体としての性能は，性能が低いレイヤに制約されてしまうためです。

特定のレイヤだけを最適化したために無意味な設定を含んでしまった例を，次の図に示します。

図8‒3　特定のレイヤだけを最適化したために無意味な設定を含んでしまった例

また，同時実行数を増やすと，実際にはリクエストを処理していないアイドル状態の場合にも，メモリなどのリソースをむだに消費するおそれがあります。

このため，同時実行数を制御する場合には，システム全体を見渡して，適切な同時実行数をそれぞれのレイヤに設定するようにしてください。

8.3.2　最大同時実行数と実行待ちキューを求める手順

最大同時実行数および実行待ちキューサイズは，次の手順に従ってチューニングできます。

負荷発生ツールなどを利用して，リクエストの多重度を増やします。

このとき，サーバ側のCPU利用率が80%〜90%に達した場合は，手順2.に進みます。80%〜90%に達しない，低い状態でスループットが向上しなくなった場合は，入出力処理や排他処理などにボトルネックがあることが考えられます。この場合は，ボトルネックになっている処理を特定して，性能を改善します。

サーバ側のCPU利用率が80%〜90%に達した多重度を，最大同時実行数としてチューニングパラメタに設定します。

この状態でのスループットが，単体マシンの最大スループットになります。これ以上のスループットを求めたい場合は，ハードウェアの増強が必要です。

負荷発生ツールなどでさらに高い負荷を掛けて，最大スループットが維持できるかどうかを確認します。

維持できない場合は，最大スループット以上の負荷が掛からないように，チューニングパラメタを調整します。

実際のシステムでの一時的な過負荷状態，および負荷のピークの状態でのリクエスト数を見積もり，実行待ちキューサイズを決定します。

階層的な構造を持つアプリケーションでは，各レイヤでの同時実行数および実行待ちキューサイズのバランスが取れるよう，調整します。

8.3.3　リクエスト処理スレッド数を制御する

Webフロントシステムの場合，Webブラウザなどのクライアントからのリクエストは，アプリケーションサーバが作成するリクエスト処理スレッドによって処理されます。リクエスト処理スレッド数を適切に制御することで，処理性能の向上が図れます。

ここでは，アプリケーションサーバでのリクエスト処理スレッド数を制御する目的と，チューニングの指針について説明します。

なお，ここでは，J2EEサーバ上のWebコンテナが作成するリクエスト処理スレッド数のチューニングの方法について説明します。

参考

J2EEサーバの前段に置くリバースプロキシとしてHTTP Serverを使用している場合は，HTTP Serverの設定で同様のチューニングができます。詳細は，マニュアル「HTTP Server」を参照してください。

(1)　リクエスト処理スレッド数を制御する目的

リクエスト処理スレッド数をJ2EEサーバが動作しているホストの性能やクライアントからのアクセス状況に合わせてチューニングすることで，性能向上を図れます。

リクエスト処理スレッドの生成は，負荷が高い処理です。リクエスト処理スレッドをあらかじめ生成してプールしておくことで，Webブラウザなどのクライアントからのリクエスト処理要求時の負荷を軽くして，処理性能を高めることができます。

Webコンテナでは，J2EEサーバ起動時にリクエスト処理スレッドをまとめて生成してプールしておき，Webブラウザなどのクライアントからリクエスト処理要求があった場合にそれを利用するようにできます。これによって，リクエスト処理要求時の処理性能の向上を図れます。なお，プールしているスレッドの数を監視しておくことで，プールしているスレッド数が少なくなった場合はさらに追加生成して，プールに確保しておくこともできます。

ただし，使用しないスレッドを大量にプールしておくと，むだなリソースを消費します。このため，システムの処理内容に応じて，プールするリクエスト処理スレッド数を適切に制御し，場合によっては不要なスレッドを削除することが必要です。

リクエスト処理スレッドの制御では，これらを考慮して，パラメタに適切な値を設定してください。

(2)　設定の指針

リクエスト処理スレッド数の制御では，次のパラメタを使用してチューニングできます。

J2EEサーバ起動時に生成するリクエスト処理スレッドの数

Webクライアントとの接続数（リクエスト処理スレッド数）の上限数

接続数の上限を超えた場合のTCP/IPのListenキュー（バックログ）の最大値

リクエスト処理スレッド数の最大数

これらのパラメタを設定するときには，次の点に留意してください。

提供するサービスの内容によっては，J2EEサーバ起動直後から大量のリクエストを処理する必要があります。この場合は，J2EEサーバ起動時に生成するリクエスト処理スレッドの数に，大きな値を指定してください。

リクエスト処理スレッドの最大数を大きくしておくと，クライアントからのアクセスが急に増加した場合にも，処理性能を下げることなく迅速に対応できます。ただし，多くのスレッドをプールしておくと，多くのリソースが消費されます。このため，急な増加が予想されるアクセス数を見積もって，適切な数のスレッドがプールされるように，注意して設定してください。

一度作成したスレッドを削除しないでプールし続けたい場合は，リクエスト処理スレッドの最大数を，リクエスト処理スレッドの最小数と同じ値にしてください。

このほか，Webアプリケーションの同時実行スレッド数との関係についても留意してください。Webアプリケーションの同時実行スレッド数については，「8.3.4　Webアプリケーションの同時実行数を制御する」を参照してください。

8.3.4　Webアプリケーションの同時実行数を制御する

Webアプリケーションの同時実行数制御では，Webフロントシステムの場合に，WebサーバがWebブラウザなどのクライアントから受け付けたHTTPリクエストの処理を，同時に幾つのスレッドで実行するかを制御します。

(1)　同時実行スレッド数制御の違い

Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位の同時実行スレッド数制御の違いは次のとおりです。

Webコンテナ単位

Webコンテナ全体で同時にHTTPリクエストを処理するスレッド数を設定できます。

Webアプリケーション単位

Webコンテナ上で動作するWebアプリケーションごとに，同時にHTTPリクエストを処理するスレッド数を設定できます。

URLグループ単位

HTTPリクエストをWebアプリケーション内の特定の業務処理（業務ロジック）に対応するURLに振り分ける場合，振り分け先URLの処理ごとに，同時にHTTPリクエストを処理するスレッド数を設定できます。

Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位の同時実行スレッド数の関係を次の図に示します。

図8‒4　Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位の同時実行スレッド数の関係

Webアプリケーションに対するリクエストの実行は，Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位に設定した同時実行スレッド数に制限されます。Webコンテナ単位，Webアプリケーション単位およびURLグループ単位に設定した同時実行スレッド数を超えるリクエストは，それぞれの実行待ちキューに入ります。

(2)　選択の指針

同時実行スレッド数制御の単位を選択するときの指針について説明します。

なお，同時実行スレッド数を制御する機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.13　同時実行スレッド数の制御の概要」を参照してください。

Webアプリケーション単位の選択の指針

Webアプリケーション単位の同時実行数を制御することで，J2EEサーバがTCP接続要求だけではなく，Webアプリケーションの実行待ちキューを管理できるようになります。このため，J2EEサーバ上で実行するWebアプリケーションが一つだけの場合でも，Webアプリケーション単位の同時実行スレッド数を設定することをお勧めします。

Webアプリケーション単位での同時実行スレッド数の設定は，Webコンテナ単位で設定する場合に比べて，次のような利点があります。

Webアプリケーションごとの同時実行スレッド数に上限を設けることで，特定の業務に対応するWebアプリケーションへのリクエストが増大した場合に，そのWebアプリケーションがWebコンテナ全体の処理能力を占有しないようにできます。これによって，ほかの業務も滞りなく実行できます。

CPUやI／O処理に掛かる負荷が異なる複数のWebアプリケーションがWebコンテナ上にある場合，それぞれの条件に適した同時実行スレッド数が設定できます。

Webアプリケーションごとにリクエストの実行待ちキューサイズが設定できるので，Webアプリケーションの特徴に応じた実行待ちキュー管理ができます。また，Webアプリケーション単位の実行待ちキュー以上のリクエストが送信された場合には，クライアントにHTTPレスポンスコードで通知できます。

なお，Webアプリケーション単位の同時実行スレッド数は，稼働中のJ2EEサーバでも動的に変更できます。稼働中のJ2EEサーバで実行するWebアプリケーションの同時実行スレッド数の動的変更の手順については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(Webコンテナ)」の「2.17.2　同時実行スレッド数の動的変更の流れ」を参照してください。

URLグループ単位の選択の指針

Webアプリケーション単位で同時実行スレッド数を制御している場合に，さらに業務ロジック単位で同時実行スレッド数の制御をしたいときには，URLグループ単位で同時実行スレッド数を制御します。

Webアプリケーションが次のような業務ロジックを含む場合，URLグループ単位の設定を検討してください。

ほかの処理に影響を受けないで優先して実行したい業務ロジック

ほかの処理に比べて処理時間が掛かる，またはCPUやI／Oの負荷が大きい業務ロジック

URLグループ単位での同時実行スレッド数の設定は，Webアプリケーション単位だけの設定に比べて，次のような利点があります。

重要度が高い業務ロジック（URLグループ）には，確実に実行するためのスレッド数を割り当てられます。これによって，ほかの業務ロジックに対するリクエスト数が増大した場合も，Webアプリケーション全体の同時実行スレッド数をその業務ロジックに占有されないで，重要度が高い業務ロジックを実行できます。

処理時間が掛かる業務ロジック（URLグループ）の同時実行数に上限を設けることで，特定の業務ロジックによってWebアプリケーション全体の同時実行数が占有されないように制御できます。

Webアプリケーション内にCPUやI／Oの負荷が異なる複数の業務ロジック（URLグループ）がある場合は，業務ロジックに応じた同時実行数が設定できます。

Webアプリケーション内の業務ロジック（URLグループ）ごとにリクエストの待ち行列長（実行待ちキューのキューサイズ）が設定できるので，業務ロジックの特徴に応じた実行待ちキューを管理できます。また，このURLグループ単位の実行待ちキューがあふれた場合，クライアントにHTTPレスポンスコード503（Service Temporarily Unavailable）を通知できます。

8.3.5　Enterprise Beanの同時実行数を制御する

ここでは，Enterprise Beanの同時実行数を制御する方法について，Enterprise Beanの種類ごとに説明します。なお，インスタンスプーリングおよびセッション制御によるEnterprise Beanの同時実行数制御は，EJBコンテナの機能を利用して実現します。EJBコンテナの機能の詳細は，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.　EJBコンテナ」を参照してください。

(1)　Enterprise Beanの同時実行数制御で使用できる機能の種類

Enterprise Beanの同時実行数を制御する場合，EJBコンテナの機能である，次の2種類の機能を利用できます。

インスタンスプーリング

Enterprise Beanのインスタンスを事前に作成しておくことで，クライアントからリクエストが送信されたときにすぐ処理を実行できるようにする機能です。プールするインスタンス数の上限値を設定することで，上限値以上のリクエストの実行を待たせることができます。これによって，同時実行数が制御できます。

参考

運用時にCTMの同時実行数を動的に変更する場合は，上限値は無制限に設定してください。

セッション制御

セッション内で，同時に生成できるセッション（インスタンス）数を制限する機能です。

なお，Enterprise Beanの種類ごとに使用できる機能が異なります。

Enterprise Beanの種類ごとに使用できる同時実行数制御の機能を次の表に示します。

表8‒4　Enterprise Beanの種類ごとに使用できる同時実行数制御の機能

Enterprise Beanの種類

使用できる制御機能

Stateless Session Bean※

インスタンスプーリング

Stateful Session Bean

セッション制御

Entity Bean

インスタンスプーリングとセッション制御

Message-driven Bean

インスタンスプーリング

注※　Stateless Session Beanの同時実行数を制御する場合は，CTMを利用することをお勧めします。CTMを利用して同時実行数を制御する方法については，「8.3.6　CTMを使用して同時実行数を制御する」で説明します。

なお，Enterprise Beanの同時実行数制御のうち，実行待ちリクエストをキューの概念で管理できるのは，Message-driven Beanだけです。Message-driven Beanでは，JMSのキューを使用して実行待ちリクエストを管理します。これ以外のEnterprise Beanでは，同時実行数以上のリクエストが送信された場合，設定に応じて次のどれかの処理が実行されます。

インスタンスに空きが出るまで待ち続ける

すぐに例外としてクライアントに返却する

インスタンス取得用に設定したタイムアウト時間が経過したら，例外としてクライアントに返却する（Stateless Session Beanのmethod-readyプールまたはEntity Beanのpoolプールの場合）

(2)　Stateless Session Beanの同時実行数制御

Stateless Session Beanでは，インスタンスプーリングを利用できます。通常の同時アクセス数をインスタンスプーリングの最小値として設定して，想定している最大同時アクセス数以上の値を，インスタンスプーリングの上限値に指定します。これによって，通常のアクセス時にはインスタンスを生成する時間を省略できるので，処理性能が向上します。さらに，アクセス数が増大した場合でも，想定している最大同時アクセス数までは処理でき，それ以上のリクエストの実行は待たせるように制御できます。

なお，デフォルトの設定の場合，上限値以上のリクエストがエラーで返却されることはありません。プールされているインスタンスに空きができるまで待ち続けます。エラーで返却したい場合は，必要に応じてインスタンス取得待ちのタイムアウトを設定してください。

(3)　Stateful Session Beanの同時実行数制御

Stateful Session Beanでは，クライアントごとにセッションごとの状態があるため，厳密な同時実行数制御はできません。ただし，セッション単位での流量制御（セッション制御）ができます。

想定している最大同時セッション数以上の値を，セッション制御の上限値として指定します。アクセス数が増大して，想定している最大同時セッション数以上のアクセスがあった場合には，セッションを確立しないで，クライアントに例外（java.rmi.RemoteException）を通知できます。

ポイント

リクエスト単位で同時実行制御が必要な場合は，サーブレット，JSPまたはStateless Session Beanを経由してStateful Session Beanを呼び出すことで，Webアプリケーションの同時実行数制御またはインスタンスプーリングを利用した同時実行数制御ができるようになります。

(4)　Entity Beanの同時実行数制御

Entity Beanでは，クライアントごとに管理する状態を持つセッションの上限値の設定とインスタンスプーリングによって，同時実行数の制御ができます。なお，セッション数が上限に達した場合，インスタンスプーリングに空きがあっても，新しいセッションでのリクエストは実行できません。

セッション数の上限を超えた場合は，セッションの作成に失敗した時点ですぐにクライアントに例外（java.rmi.RemoteException）が通知されます。また，デフォルトの設定の場合，インスタンスプール数の上限値以上のリクエストは，エラーで返却されることはなく，プールされているインスタンスに空きができるまで待ち続けます。エラーで返却したい場合は，必要に応じてインスタンス取得待ちのタイムアウトを設定してください。

なお，Entity Beanに対するリクエストの実行では，データベースへのアクセスが発生します。このため，同時実行できるリクエスト数は，データベースにアクセスするためのコネクション数にも制限されます。

(5)　Message-driven Beanの同時実行数制御

Message-driven Beanでは，インスタンスプーリングを利用できます。想定している最大メッセージ数以上の値を，インスタンスプーリングの上限値として指定します。これによって，メッセージ到着時にインスタンスを生成する時間を省略できるので，処理性能が向上します。さらに，メッセージ数が増大した場合でも，インスタンスプーリングの上限値以上のメッセージは，実行を待たせるように制御できます。

なお，Message-driven Beanでは，JMSのキューによって，到着メッセージを実行待ちキューで管理できます。

参考

TP1インバウンド連携機能を使用してOpenTP1のSUPからMessage-driven Beanを呼び出す場合や，CJMSプロバイダを使用してMessage-driven Beanを呼び出す場合，ここで説明した内容以外に，使用するコンポーネントを考慮した同時実行数を検討する必要があります。詳細は，マニュアル「アプリケーションサーバ 機能解説基本・開発編(コンテナ共通機能)」の「4.　OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）」，または「7.　CJMSプロバイダ」を参照してください。

8.3.6　CTMを使用して同時実行数を制御する

CTMを使用している場合，Stateless Session Beanの同時実行数を制御できます。

CTMは，J2EEサーバとは独立したプロセス群です。EJBクライアントとJ2EEサーバ間のStateless Session Beanの呼び出しを中継し，Stateless Session Beanを呼び出す際に，同時実行数制御をします。なお，CTMによる同時実行数制御の単位はJ2EEアプリケーションです。

(1)　CTMを使用したStateless Session Beanの同時実行数制御

CTMによる同時実行数制御（流量制御）によって，次に示すチューニングができます。

CPUやI／O処理に掛かる負荷が異なる，複数のJ2EEアプリケーションがJ2EEサーバ上にある場合に，それぞれの条件に適した同時実行数が設定できます。

CTMで実行待ちキュー（スケジュールキュー）を管理するので，実行待ちリクエスト数を一定数以下に保ち，それ以上のリクエストが送信された場合にはクライアントに例外を通知できます。

特定のJ2EEサーバの負荷が高い場合に，ほかのJ2EEサーバにリクエストを振り分けられます。

CTMによるStateless Session Beanの同時実行数制御の例を次の図に示します。

図8‒5　CTMによるStateless Session Beanの同時実行数制御の例

ポイント

CTMは同一ホスト上のJ2EEサーバでのStateless Session Beanの呼び出しを制御して，そのホスト上での同時実行スレッド数を制御できます。アプリケーションサーバマシンのマシンスペックにも左右されますが，1台のマシン当たりCTMデーモンを1プロセス起動して，J2EEサーバを2〜4プロセス起動する構成を推奨します。

なお，CTMによる同時実行スレッド数は，稼働中のCTMデーモンでも動的に変更できます。

CTMの同時実行数を制御する機能の詳細，および稼働中のCTMデーモンで実行するCTMの同時実行スレッド数動的変更の手順については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「3.4　リクエストの流量制御」を参照してください。

(2)　EJBコンテナのインスタンスプーリングとの使い分けの指針

CTMを使用して同時実行数を制御することをお勧めします。なお，CTMによる同時実行数制御は，EJBコンテナでのインスタンスプーリングを利用した同時実行数制御と併用できます。

EJBコンテナの機能を使用した同時実行数制御に加えて，CTMによって同時実行数を制御するメリットは，次のとおりです。

あるEJBコンテナで同時実行数が上限に達した場合に，ほかのJ2EEサーバにリクエストを振り分けられます。

同時実行数が上限に達していなくても，特定のJ2EEサーバの負荷が高い場合，ほかのJ2EEサーバにリクエストを振り分けられます。

CTMで実行待ちキュー（スケジュールキュー）の管理をして，実行待ちリクエスト数を一定に保ち，それ以上のリクエストを受け付けた場合はクライアントにエラーを通知できます。

ポイント

CTMによる同時実行数制御とEJBコンテナでのインスタンスプーリングを併用する場合，Stateless Session Beanのインスタンスプーリング数はCTMの同時実行数以上に設定する必要があります。

また，運用時にCTMの同時実行数を動的に変更する場合は，Stateless Session Beanのインスタンスプーリング数の上限は無制限にする必要があります。なお，デフォルトでは無制限に設定されています。デフォルトから変更しないでください。

8.3.7　同時実行数を最適化するためのチューニングパラメタ

ここでは，同時実行数の最適化で使用するチューニングパラメタの設定方法についてまとめて示します。

(1)　リクエスト処理スレッド数

Webコンテナのリクエスト処理スレッド数のチューニングパラメタの設定方法について説明します。

次の表に示す項目をSmart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒5　Webコンテナのリクエスト処理スレッド数のチューニングパラメタ

設定項目

設定対象

設定個所（パラメタ名）

J2EEサーバ起動時に生成するリクエスト処理スレッド数

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.min_threads

Webクライアントまたはリバースプロキシとの接続数の上限※1

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.max_connections

Webクライアントまたはリバースプロキシとの接続数の上限を超えた場合に使用されるTCP/IPのListenキュー（バックログ）の最大値※2

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.backlog

リクエスト処理スレッド数の最大数

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.max_threads

注※1

常設コネクションの場合，リバースプロキシから接続されるコネクション数以上の値を定義してください。

注※2

常設コネクションの場合，キューとして使用できません。

なお，J2EEサーバの前段に置くリバースプロキシとしてHTTP Serverを使用している場合のチューニングパラメタについては，マニュアル「HTTP Server 」を参照してください。

(2)　Webアプリケーションの同時実行数

URLグループ単位，Webアプリケーション単位，またはWebコンテナ単位に設定します。

(a)　URLグループ単位の同時実行数

URLグループ単位の同時実行数のチューニングパラメタの設定方法について説明します。設定項目ごとに設定方法と設定個所が異なります。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒6　URLグループ単位の同時実行数のチューニングパラメタ（Smart Composer機能で設定する項目）

設定項目

設定対象

設定個所（パラメタ名）

Webコンテナ単位での最大同時実行スレッド数

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.max_servlet_execute_threads

デフォルトの実行待ちキューサイズ

論理J2EEサーバ（j2ee-server）

webserver.container.thread_control.queue_size

次の表に示す項目は，サーバ管理コマンド（cjsetappprop）で設定します。パラメタは，WAR属性ファイルに定義します。

表8‒7　URLグループ単位の同時実行数のチューニングパラメタ（サーバ管理コマンド（cjsetappprop）で設定する項目）

設定項目

設定個所（パラメタ名）

Webアプリケーション単位での最大同時実行スレッド数

<thread-control>タグ下の<thread-control-max-threads>

Webアプリケーションの占有スレッド数

<thread-control>タグ下の<thread-control-exclusive-threads>

Webアプリケーション単位の実行待ちキューサイズ

<thread-control>タグ下の<thread-control-queue-size>

URLグループ単位の同時実行スレッド数制御の定義名

<thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-name>

URLグループ単位での最大同時実行スレッド数

<thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-max-threads>

URLグループ単位の占有スレッド数

<thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-exclusive-threads>

URLグループ単位の実行待ちキューサイズ

<thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-queue-size>

URLグループ単位の制御対象となるURLパターン

<thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-mapping>

(b)　Webアプリケーション単位の同時実行数

Webアプリケーション単位の同時実行数をチューニングするパラメタの設定方法について説明します。設定項目ごとに設定方法と設定個所が異なります。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒8　Webアプリケーション単位の同時実行数のチューニングパラメタ（Smart Composer機能で設定する項目）

設定項目

設定対象

設定個所（パラメタ名）

Webコンテナ単位での最大同時実行スレッド数

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.max_servlet_execute_threads

デフォルトの実行待ちキューサイズ

論理J2EEサーバ（j2ee-server）

webserver.container.thread_control.queue_size

次の表に示す項目は，サーバ管理コマンド（cjsetappprop）で設定します。パラメタは，WAR属性ファイルに定義します。

表8‒9　Webアプリケーション単位の同時実行数のチューニングパラメタ（サーバ管理コマンド（cjsetappprop）で設定する項目）

設定項目

設定個所（パラメタ名）

Webアプリケーション単位での最大同時実行スレッド数

<thread-control-max-threads>

Webアプリケーションの占有スレッド数

<thread-control-exclusive-threads>

Webアプリケーション単位の実行待ちキューサイズ

<thread-control-queue-size>

(c)　Webコンテナ単位の同時実行数

Webコンテナ単位の同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目をSmart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒10　Webコンテナ単位の同時実行数のチューニングパラメタ

設定項目

設定対象

設定個所（パラメタ名）

Webコンテナ単位での最大同時実行スレッド数

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.max_servlet_execute_threads

(3)　Enterprise Beanの同時実行数

Enterprise Beanの同時実行数は，Enterprise Bean単位に設定します。Enterprise Beanの種類ごとに説明します。

(a)　Stateless Session Beanの同時実行数

Stateless Session Beanの同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目を，サーバ管理コマンド（cjsetappprop）で設定します。パラメタは，Session Bean属性ファイルに定義します。

表8‒11　Stateless Session Beanの同時実行数のチューニングパラメタ

設定項目

設定個所（パラメタ名）

プールで管理するインスタンスの最大値

<stateless><pooled-instance>タグ下の<maximum>※

プールで管理するインスタンスの最小値

<stateless><pooled-instance>タグ下の<minimum>

注※　運用時にCTMの同時実行数を動的に変更する場合は，最大値は無制限（「0」）に設定する必要があります。

(b)　Stateful Session Beanの同時実行数

Stateful Session Beanの同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目を，サーバ管理コマンド（cjsetappprop）で設定します。パラメタは，Session Bean属性ファイルに定義します。

表8‒12　Stateful Session Beanの同時実行数のチューニングパラメタ

設定項目

設定個所（パラメタ名）

クライアントから作成可能なセッションの上限

<stateful>タグ下の<maximum-active-sessions>

使われていないインスタンスが削除されるまでの時間（分）

<stateful>タグ下の<removal-timeout>

(c)　Entity Beanの同時実行数

Entity Beanの同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目を，サーバ管理コマンド（cjsetappprop）で設定します。パラメタは，Entity Bean属性ファイルに定義します。

表8‒13　Entity Beanの同時実行数のチューニングパラメタ

設定項目

設定個所（パラメタ名）

クライアントから作成可能なEntity Beanの最大値

<maximum-instances>

使われていないEntity BeanのEJBObjectが削除されるまでの時間（分）

<entity-timeout>

(d)　Message-driven Beanの同時実行数

Message-driven Beanの同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目を，サーバ管理コマンド（cjsetappprop）で設定します。パラメタは，Message-driven Bean属性ファイルに定義します。

表8‒14　Message-driven Beanの同時実行数のチューニングパラメタ

設定項目

設定個所（パラメタ名）

プールで管理するインスタンスの数の最大値

<pooled-instance><maximum>

プールで管理するインスタンスの数の最小値

<pooled-instance><minimum>

(4)　CTMで制御する同時実行数

CTMで制御する同時実行数をチューニングするパラメタの設定方法について説明します。CTMデーモン，アプリケーション，およびStateless Session Beanに設定する項目があります。

CTMデーモンに設定する項目

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒15　CTMで制御する同時実行数のチューニングパラメタ（Smart Composer機能で設定する項目）

設定項目

設定対象

設定個所（パラメタ名）

CTMが制御するスレッドの最大値およびキューごとのリクエストの登録数

論理CTM（component-transaction-monitor）

ctm.DispatchParallelCount

アプリケーションまたはStateless Session Beanに設定する項目

次の表に示す項目は，サーバ管理コマンドで設定します。パラメタは，アプリケーション属性ファイルまたはSession Bean属性ファイルに定義します。

表8‒16　CTMで制御する同時実行数のチューニングパラメタ（サーバ管理コマンドで設定する項目）

設定項目

定義ファイル

設定対象

設定個所（パラメタ名）

アプリケーションをCTMによる同時実行数制御の対象にするかどうか

アプリケーション属性ファイル

アプリケーション

<managed-by-ctm>

アプリケーションの同時実行スレッド数

アプリケーション属性ファイル

アプリケーション

<scheduling>タグ下の<parallel-count>

Stateless Session BeanをCTMによる同時実行数制御の対象にするかどうか

Session Bean属性ファイル

Stateless Session Bean

<enable-scheduling>

Bean単位のキューについての設定※

Session Bean属性ファイル

Stateless Session Bean

<scheduling>タグ下の<parallel-count>

注※　スケジュールキューをBean単位に配置する場合に必要です。スケジュールキューの配置方法は，アプリケーション属性ファイルの<scheduling-unit>タブに設定します。

8.4　Enterprise Beanの呼び出し方法を最適化する

この節では，Enterprise Beanの呼び出し方を最適化する方法について説明します。

通常，Enterprise Beanは，リモートインタフェースを使用してRMI-IIOP経由で呼び出されます。しかし，この方法の場合，同じJ2EEアプリケーションや同じJ2EEサーバ内で動作しているEnterprise Beanから呼び出すときにも，リモート接続と同じオーバーヘッドが掛かってしまいます。

これに対して，Enterprise Beanの呼び出し方を最適化してスループットの向上を図るために，次の呼び出し方法が使用できます。

ローカルインタフェースを使用した呼び出し

リモートインタフェースのローカル呼び出し

リモートインタフェースの参照渡し

これらの呼び出し方法には，それぞれ，次の表に示す特徴があります。この表では，標準仕様に準拠しているか（標準仕様），性能は向上するか（性能），位置透過性はあるか（位置透過），保守性に優れているか（保守性）の四つの特徴で比較しています。アプリケーションやシステムの特徴に応じて使い分けてください。

表8‒17　Enterprise Beanの呼び出し方法の特徴

呼び出し方法の種類

標準仕様

性能

位置透過

保守性

ローカルインタフェース

○

○

×

○

リモートインタフェースのローカル呼び出し

○

△

○

○

リモートインタフェースの参照渡し

×

○

△

×

（凡例）

○：対応している。／優れている。

△：対応しているが，一部制限がある。／やや悪い。

×：対応していない。／悪い。

なお，ローカルインタフェースの詳細については，EJBの仕様を参照してください。

リモートインタフェースのローカル呼び出しおよびリモートインタフェースの参照渡しの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.13　EJBのリモートインタフェースの呼び出し」を参照してください。

8.4.1　ローカルインタフェースを使用する

アプリケーション開発時に，J2EE標準仕様に準拠したローカルインタフェースを使用する方法です。

ローカルインタフェースは，Enterprise Beanの呼び出しを通常の同一スレッドのメソッド呼び出しとして実行する機能です。J2EEの標準機能なので，ポータビリティがあります。ただし，クライアント側，サーバ側の両方でローカル呼び出し専用のローカルインタフェースを使用したプログラムを作成する必要があるため，位置透過性はなくなります。

なお，ローカルインタフェースは，参照渡しによる呼び出しになります。また，同一J2EEサーバ内であっても，異なるJ2EEアプリケーション間での呼び出しには適用できません。

8.4.2　リモートインタフェースのローカル呼び出し最適化機能を使用する

同一アプリケーション内または同一J2EEサーバ内でのEnterprise Beanのリモートインタフェースによる呼び出しを，同一スレッドの延長によって実行する機能（ローカル呼び出し最適化機能）を使用する方法です。クライアント側，サーバ側の両方でリモートインタフェースを使用したプログラムを作成するので，位置透過性が保てます。

なお，デフォルトの状態では，同一アプリケーション内のローカル呼び出し最適化機能を使用する設定になっています。

8.4.3　リモートインタフェースの参照渡し機能を使用する

ローカル呼び出し最適化機能を使用する場合に，引数や戻り値で使用するオブジェクト型などのサイズが大きいデータの受け渡しを参照渡しにすることで，処理の高速化を図る方法です。

次のような条件の場合に，高速化が期待できます。

表8‒18　リモートインタフェースの参照渡しで高速化が期待できる条件

項目

処理内容

ビジネスメソッドの処理

仮引数経由で取得したデータに対して，直接変更をしないで参照だけする処理

ビジネスメソッドの引数と戻り値

配列やCollectionなどのクラスで大量のデータを受け渡す処理

呼び出すEnterprise Beanの位置

同一のJ2EEアプリケーション内，または同一のJ2EEサーバ内

ただし，リモートインタフェースでのデータの受け渡しは本来値渡しです。このため，値渡しを前提に作成されたプログラムは正しく動作しなくなるおそれがあるので注意してください。正しく動作しなくなるプログラムの例を次に示します。

図8‒6　正しく動作しなくなるプログラムの例

また，次の場合，この機能を使用しても効果がありません。

プリミティブ型（単純型）の場合（常に値渡しになるため）

受け渡すデータのサイズが小さい場合

この機能は，J2EEサーバ単位またはEnterprise Bean単位で設定できます。

8.4.4　Enterprise Beanの呼び出し方法を最適化するためのチューニングパラメタ

ここでは，Enterprise Beanの呼び出し方法の最適化で使用するチューニングパラメタの設定方法についてまとめて示します。

(1)　ローカルインタフェースの使用

アプリケーション作成時に，J2EEで定義されているローカルインタフェースを使用してください。

(2)　リモートインタフェースのローカル呼び出し機能の使用

リモートインタフェースのローカル呼び出し機能のチューニングパラメタの設定方法について説明します。

次の表に示す項目をSmart Composer機能で設定します。パラメタは簡易構築定義ファイルに定義します。

表8‒19　リモートインタフェースのローカル呼び出し機能のチューニングパラメタ

設定項目

設定対象

設定個所（パラメタ名）

ローカル呼び出し最適化機能の適用範囲

論理J2EEサーバ（j2ee-server）

ejbserver.rmi.localinvocation.scope

(3)　リモートインタフェースの参照渡し機能の使用

リモートインタフェースの参照渡し機能のチューニングパラメタの設定方法について説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは簡易構築定義ファイルに定義します。

表8‒20　リモートインタフェースの参照渡し機能のチューニングパラメタ（Smart Composer機能で設定する項目）

設定項目

設定対象

パラメタ名

リモートインタフェースの参照渡し機能の使用（J2EEサーバ単位）

論理J2EEサーバ（j2ee-server）

ejbserver.rmi.passbyreference

次の表に示す項目は，サーバ管理コマンド（cjsetappprop）で設定します。パラメタはSession Bean属性ファイルまたはEntity Bean属性ファイルに定義します。

表8‒21　リモートインタフェースの参照渡し機能のチューニングパラメタ（サーバ管理コマンド（cjsetappprop）で設定する項目）

設定項目

パラメタ名

リモートインタフェースの参照渡し機能の使用（Enterprise Bean単位）

<pass-by-reference>

8.5　データベースへのアクセス方法を最適化する

データベースへのアクセス方法の最適化について説明します。

J2EEサーバでは，データベースアクセス方法のチューニングに次の2種類の方法を使用できます。

コネクションプーリング

ステートメントプーリング

8.5.1　コネクションプーリングを使用する

ここでは，J2EEサーバでコネクションプーリングを使用する利点と，コネクションプーリングに関連して使用できる機能について説明します。

また，JPAプロバイダでは，DB Connectorのコネクションを取得します。

(1)　コネクションプーリングを使用する利点

データベースなどのEISとのコネクションの確立は，負荷が高くなる処理です。コネクションプーリングを使用することで，負荷を軽くできます。コネクションプーリングは，J2EEサーバによって一度取得，生成したコネクションをプールしておき，それを再利用することで処理性能の向上を図る機能です。データベースなどにアクセスするたびにコネクションを再取得する場合に比べて，性能劣化を防ぐ効果があります。

なお，EISとの接続方法によって，使用できる機能が異なります。詳細は，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.14.1　コネクションプーリング」を参照してください。

なお，デフォルトの設定では，コネクションプーリングは有効になっています。

(2)　使用できる機能

コネクションプーリングで使用できる機能と設定時の指針について示します。

コネクションプーリングでは，次の機能を使用できます。

プールするコネクションの最大値と最小値を指定する

プール内のコネクションを検査して無効なコネクションを破棄する※1

コネクション取得失敗時にリトライする※2

スイーパによって使わないコネクションをプールから削除する※2

コネクションウォーミングアップによってあらかじめコネクションをプールしておく

コネクション枯渇時のコネクション取得要求を取得待ちキューに入れる

コネクションプール内の不要なコネクションを段階的に減少させる

注※1　この機能を使用する場合，コネクションの検査にタイムアウトを設定することもできます。

注※2　これらの機能は，デフォルトの設定では無効になっています。必要に応じて使用してください。

(a)　プールするコネクションの最小値と最大値を指定する

コネクションプーリングを設定する場合は，プールするコネクションの最小値と最大値を設定します。無制限にした場合はコネクションが無制限に確立されます。

最小値および最大値は，定常状態で発生するデータベースなどのEISへの同時アクセス数，トランザクション数，業務の同時実行数などを参考にして決定してください。

プールするコネクションの最大値は，同時実行スレッド数，Session Beanインスタンスプールとの間で，次の関係式を満たすように設定することを推奨します。

プールするコネクションの最大値≧Session Beanインスタンスプール≧同時実行スレッド数

(b)　プール内のコネクションを検査して無効なコネクションを破棄する

プール内のコネクションに障害が発生していないかどうかをコネクション取得時または定期的にチェックして，障害が発生したコネクションをプールから削除します（コネクション障害検知）。コネクション取得時に障害が発生しているコネクションを取得してしまうことを防ぎ，接続に失敗する可能性を低くできます。この機能は，DB Connectorを使用してデータベースにアクセスするためのコネクションに対して有効です。なお，SQL Serverを使用する場合，DB ConnectorのselectMethodプロパティにdirectを指定したときには，この機能は使用できません。

コネクション障害検知を実行するタイミングの使い分けの指針は次のとおりです。業務の種類に応じて使い分けてください。

表8‒22　コネクション障害検知を実行するタイミングの使い分けの指針

業務の種類

タイミング

EISとの接続の失敗が許容されない業務

コネクション取得頻度が低い業務

コネクション取得時に障害検知を実行する設定をお勧めします。

コネクション取得時に掛かる処理時間は，コネクション障害検知を実行しない場合に比べて多く掛かりますが，障害が発生しているコネクションを取得する可能性が低くなります。

コネクション取得頻度が高い業務

障害が発生したコネクションを取得してもある程度許容されるような業務

定期的に障害検知を実行する設定をお勧めします。チェック間隔をある程度長くすることで，コネクション障害検知処理のために性能が劣化することを防げます。ただし，障害が発生しているコネクションを取得してしまうおそれがあります。

また，コネクション障害検知を実行する場合，コネクション障害検知の実行にタイムアウトを設定できます。サーバ障害やネットワーク障害が発生してリソースからの応答が返らない場合，コネクション障害検知の実行に対しても応答が返らなくなることがあります。タイムアウトを設定しておくことで，リソースからの応答が返らない場合も，コネクション障害検知処理を終了して，処理を継続できます。なお，この場合は，コネクションに障害が発生していると判断されます。

ポイント

コネクション障害検知にタイムアウトを設定した場合，システム内で，コネクションプールのコネクション数に応じたコネクション管理スレッドが生成されます。このため，コネクション障害検知にタイムアウトを設定すると，設定しない場合に比べて多くのメモリを消費するので，注意が必要です。

コネクション管理スレッドは，コネクションプールのコネクション数の最大値の2倍の数が作成されます。必要なメモリ使用量を適切に見積もってください。

コネクション管理スレッドは，コネクション数調節機能のタイムアウトと共通で使用されます。このため，コネクション障害検知にタイムアウトを設定した場合，コネクション数調節機能のタイムアウトも有効になります。

コネクション障害検知のタイムアウトを有効にしてコネクション障害検知を実施する場合，コネクションプールから取り除いた未使用コネクションは，コネクションプール内のコネクション数としてカウントされません。そのため，コネクションプール内のコネクションとコネクションプールから取り除いた未使用コネクションの総数が，コネクションプールのコネクション数の最大値を一時的に超える場合があります。

(c)　コネクション取得失敗時にリトライする

コネクションの取得に失敗したときに，ユーザプログラムでリトライする必要がなくなります。業務処理のレスポンスが下がっても，障害発生による業務停止を防ぎたい場合に設定してください。

リトライ回数とリトライ間隔を設定する場合の指針について次に示します。

リトライ回数を増やしたり，リトライ間隔を大きくしたりすると，コネクション取得処理が発生した場合に，待ち時間が発生するおそれがあります。

リトライ間隔×リトライ回数の時間が長過ぎると，RMI-IIOP通信のタイムアウトなどが発生しますが，タイムアウト後もリトライを続けます。このため，リトライ間隔×リトライ回数の時間は，タイムアウト値以下の値になるように設定してください。

同一リソースのコネクションを使用する業務の所要時間にも左右されますが，10秒以上を指定することを推奨します。

(d)　スイーパによって使わないコネクションをプールから自動削除する

一定時間使用しなかったコネクションをスイーパによってプールから自動削除します。コネクションを未使用のままプーリングすると問題が発生する場合に設定します。リソースアダプタ単位に設定できます。

(e)　コネクションウォーミングアップによってあらかじめコネクションをプールしておく

J2EEサーバの起動時またはリソースアダプタのスタート時にコネクションを最小値まであらかじめ取得してプールしておく機能です。コネクションプールの使用を開始した直後の，アプリケーションからのコネクション要求のレスポンスを向上できます。ただし，J2EEサーバ起動またはリソースアダプタのスタート時の処理時間が掛かります。

(f)　コネクション枯渇時のコネクション取得要求を待ち状態にする

プールしているコネクションをすべて使い切っている状態でコネクション取得要求があった場合に，コネクション取得要求を待ち状態にする機能です。

使用中のコネクションが解放されるか，コネクションが破棄されてコネクション最大数よりも少なくなった場合に，すぐにコネクション取得要求を再開できます。また，待ち時間も設定できるので，一定時間を経過してコネクションを取得できなかった場合はエラーにできます。

(g)　コネクションプール内の不要なコネクションを段階的に減少させる

コネクションプール内に不要なコネクションがある場合に，コネクション数を段階的に減らす機能です（コネクション数調節機能）。

一定間隔でコネクションプールの数をチェックします。チェック直前までの間の最大同時実行コネクション数を基準として，プール内にそれ以上の数のコネクションがある場合は，多い分のコネクションを削除します。これによって，プール内のコネクションは実際の稼働実績に適した数になるので，コネクション生成コストの削減や，リソース資源の節約ができます。

また，コネクションの削除処理にタイムアウトを設定できます。タイムアウトには，コネクション管理スレッドを使用します。なお，コネクション管理スレッドは，コネクション障害検知のタイムアウトでも使用されます。

ポイント

コネクション管理スレッドは，コネクション障害検知のタイムアウトと共通で使用されます。このため，コネクション数調節機能にタイムアウトを設定した場合，コネクション障害検知のタイムアウトも有効になります。

また，コネクション数調節機能を使用すると，コネクションプールのコネクション数を調整するために取り除いた未使用コネクションは，コネクションプール内のコネクション数としてカウントされません。そのため，コネクションプール内のコネクションとコネクションプールから取り除いた未使用コネクションの総数が，コネクションプールのコネクション数の最大値を一時的に超える場合があります。

8.5.2　ステートメントプーリングを使用する

ここでは，ステートメントプーリングを使用する利点と，設定の指針について説明します。

この機能は，DB Connectorを利用している場合に使用できる機能です。また，使用できるかどうかは，EISとの接続方法によって異なります。XDM/RD E2 11-01以前のバージョンの場合，ステートメントプーリングは使用できません。詳細は，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「3.14.4　ステートメントプーリング」を参照してください。

(1)　ステートメントプーリングを使用する利点

データベースにアクセスするときに必要なSQL文やストアドプロシジャなどのステートメントの生成は，負荷が高くなる処理です。ステートメントプーリングを使用することで，負荷を軽くできます。ステートメントプーリングは，一度生成したステートメントであるPreparedStatementとCallableStatementをプーリングしておき，それを再利用することで処理性能の向上を図る機能です。データベースなどにアクセスするたびにステートメントを再生成する場合に比べて，処理性能が向上します。

なお，PreparedStatementおよびCallableStatementとは，それぞれ，JDBCのAPIであるjava.sql.PreparedStatementとjava.sql.CallableStatementのインスタンスです。

(2)　設定の指針

ステートメントプーリングを利用するためには，アプリケーション開発時に次の点に留意する必要があります。

同じシグネチャを持つjava.sql.Connection#prepareStatementメソッドを使用します。

java.sql.Connection#prepareStatementメソッドでは同じ引数値を指定します。

これらを満たさないアプリケーションでは，ステートメントプーリングは有効に動作しません。

また，ステートメントプーリングを使用するときには，コネクションプーリングとの関連を理解した上で使用してください。アプリケーション構成および環境設定時に留意する点を次に示します。

物理コネクションのインスタンスごとにPreparedStatementおよびCallableStatementがプールされます。このため，コネクション取得時にプールされているコネクションが複数ある場合には，ステートメントがまだプールされていないコネクションが割り当てられることがあります。

それぞれのステートメントのインスタンスをプールするときには，使用しているJDBCドライバのコネクションごとの上限値を考慮してプールサイズを設定する必要があります。

コネクションプールとステートメントプールの関係を次の図に示します。

図8‒7　コネクションプールとステートメントプールの関係

ステートメントプーリングのプールサイズを決めるときには，業務処理の内容に応じて，コネクションプーリングとの関係を考慮した上で決めてください。例えば，異なる業務処理で同じデータベースを使用する場合であっても，異なるテーブルにアクセスする場合や異なるSQL文を使用する場合は，一つのDB Connectorでコネクションプールとステートメントプールのサイズを大きくするよりも，業務処理ごとに別々のDB Connectorを用意して，その業務で必要な分だけの小さなコネクションプールやステートメントプールを用意する方が，効率が良い場合があります。

図8‒8　業務処理に応じたコネクションプールとステートメントプールの利用

ただし，DB Connectorを複数用意してプールサイズを小さくすると，業務ごとにプールされているコネクション数の余裕がなくなり，アクセスのピーク時にコネクション不足が発生するおそれがあります。このため，業務の同時実行数などを詳細に見積もって，コネクション数不足ができるだけ発生しないようにチューニングしてください。また，プールのサイズは，業務処理ごとに，どのくらいのステートメントを利用するかによって調整してください。

一つのDB Connectorを利用する場合のステートメントプールサイズは，次の値を集計して決定します。なお，DB Connectorが内部でステートメントプールを一つ利用することを考慮してプールサイズを見積もってください。

PreparedStatementのプールサイズを設定する指針とサイズの算出方法

コネクションごとのJDBCドライバのリソース制限を上限として，同一のDB Connectorを利用するPreparedStatementの利用数を基に算出してください。なお，JDBCドライバのリソース制限については，使用しているJDBCドライバの制限値に従ってください。

利用数は，次の数を集計して求めます。

サーブレットおよびJSPから，異なる引数を指定してjava.sql.Connection#prepareStatementメソッドを呼び出している数

Session BeanおよびEntity Bean（BMP）から，異なる引数を指定してjava.sql.Connection#prepareStatementメソッドを呼び出している数

Entity Bean（CMP）に対して，J2EEサーバが内部的にPreparedStatementで使用するSQLの数

Message-driven Beanから，異なる引数を指定してjava.sql.Connection#prepareStatementメソッドを呼び出している数

CallableStatementのプールサイズを設定する指針とサイズの算出方法

コネクションごとのJDBCドライバのリソース制限を上限として，同一のDB Connectorを利用するCallableStatementの利用数を基に算出してください。なお，JDBCドライバのリソース制限については，使用しているJDBCドライバの制限値に従ってください。

利用数は，次の数を集計して求めます。

サーブレットおよびJSPから，異なる引数を指定してjava.sql.Connection#prepareCallメソッドを呼び出している数

Session BeanおよびEntity Bean（BMP）から，異なる引数を指定してjava.sql.Connection#prepareCallメソッドを呼び出している数

Message-driven Beanから，異なる引数を指定してjava.sql.Connection#prepareCallメソッドを呼び出している数

8.5.3　データベースへのアクセス方法を最適化するためのチューニングパラメタ

ここでは，データベースへのアクセス方法の最適化で使用するチューニングパラメタの設定方法についてまとめて示します。

(1)　コネクションプーリング

コネクションプーリングのチューニングパラメタの設定方法について説明します。

次の表に示す項目は，リソースアダプタ単位に，サーバ管理コマンド（cjsetresprop/cjsetrarprop）で設定します。パラメタは，Connector属性ファイルに定義します。

表8‒23　コネクションプーリングのチューニングパラメタ

設定項目

設定個所（パラメタ名）※1

コネクションプールにプールするコネクションの最小値

<property>タグに指定するMinPoolSize

コネクションプールにプールするコネクションの最大値

<property>タグに指定するMaxPoolSize

プール内のコネクションに障害が発生しているかどうかをチェックする方法の選択

<property>タグに指定するValidationType

プール内のコネクションに障害が発生しているかどうかのチェックを定期的に実行する場合の間隔

<property>タグに指定するValidationInterval

コネクション枯渇時にコネクション取得要求をキューで管理するかどうかの選択

<property>タグに指定するRequestQueueEnable

コネクション枯渇時のコネクション取得要求をキューで管理する場合の待ち時間

<property>タグに指定するRequestQueueTimeout

コネクションの取得に失敗した場合のリトライ回数※2

<property>タグに指定するRetryCount

コネクションの取得に失敗した場合のリトライ間隔※2

<property>タグに指定するRetryInterval

コネクションの最終利用時刻からコネクションを自動破棄するかを判定するまでの時間

<property>タグに指定するConnectionTimeout

コネクションの自動破棄（コネクションスイーパ）が動作する間隔

<property>タグに指定するSweeperInterval

コネクションのウォーミングアップを使用するかどうかの選択

<property>タグに指定するWarmup

コネクション障害検知にタイムアウト時間を設定するかどうかの選択※3

<property>タグに指定するNetworkFailureTimeout

コネクション数調節機能での削除処理にタイムアウト時間を設定するかどうかの選択※3

コネクション数調節機能が動作する間隔

<property>タグに指定するConnectionPoolAdjustmentInterval

注※1　クラスタコネクションプール機能（互換機能）を使用している場合は，メンバリソースアダプタで設定します。

注※2　クラスタコネクションプール機能（互換機能）を使用している場合は，設定できません。

注※3　コネクション障害検知のタイムアウトとコネクション数調節機能のタイムアウトでは，共通のコネクション管理メソッドを使用します。このため，どちらかのタイムアウトを設定すると，コネクション障害検知とコネクション数調節機能の両方のタイムアウトが有効になります。コネクション障害検知，およびコネクション数調節機能のタイムアウト時間を変更したい場合は，簡易構築定義ファイルで設定するJ2EEサーバ用のパラメタ（ejbserver.connectionpool.validation.timeout）の設定を変更してください。詳細は，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.11.2　J2EEサーバ用ユーザプロパティを設定するパラメタ」を参照してください。

ポイント

HiRDBまたはXDM/RD E2でコネクションプーリング機能を使用する場合，次の設定を推奨します。

HiRDBでコネクションプーリング機能を使用する場合

HiRDBのサーバからコネクションを切断されないようにHiRDBクライアント環境変数を設定してください。詳細は，マニュアル「HiRDB UAP開発ガイド」を参照してください。

XDM/RD E2でコネクションプーリング機能を使用する場合

DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文のSVINTERVALパラメタに「0」を指定します。このパラメタについては，マニュアル「VOS3　Database Connection Server」を参照してください。

上記を設定しなかった場合，プールしているコネクションが，タイムアウトによってデータベースから切断されることがあります。

障害検知機能を使用している場合

障害検知機能によって，タイムアウトでデータベースから切断されたコネクションを破棄します。コネクションは正常に取得できます。

障害検知機能を使用していない場合

タイムアウトでデータベースから切断されたコネクションを取得します。

(2)　ステートメントプーリング

ステートメントプーリングのチューニングパラメタの設定方法について説明します。

次の表に示す項目は，サーバ管理コマンド（cjsetresprop/cjsetrarprop）で設定します。パラメタは，Connector属性ファイルに定義します。

表8‒24　ステートメントプーリングのチューニングパラメタ

設定項目

パラメタ名※

物理コネクションごとにプールするPreparedStatementの数

<config-property>タグに指定するPreparedStatementPoolSize

物理コネクションごとにプールするCallableStatementの数

<config-property>タグに指定するCallableStatementPoolSize

注※　クラスタコネクションプール機能（互換機能）を使用している場合は，メンバリソースアダプタで設定します。

8.6　タイムアウトを設定する

アプリケーションサーバのシステムでは，トラブル発生時にリクエストの応答が戻ってこない状態になることを防ぐために，幾つかのポイントにタイムアウトを設定できます。

この節では，システム全体でタイムアウトが設定できるポイントと，設定する場合の指針について説明します。

参考

TP1インバウンド連携機能を使用してOpenTP1からアプリケーションサーバを呼び出す場合，この節で説明する内容のほか，OpenTP1側の設定を考慮したタイムアウトの設定が必要です。詳細は，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「4.　OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）」を参照してください。

8.6.1　タイムアウトが設定できるポイント

J2EEアプリケーションを実行するシステムでは，次の図に示すポイントにタイムアウトが設定できます。なお，次の図は，クライアントがWebブラウザの場合です。また，Webサーバと連携する場合と，Webサーバを経由しないでJ2EEサーバに直接リクエストを送受信する場合で，ポイントが異なります。

図8‒9　タイムアウトが設定できるポイント（Webサーバ連携の場合）

なお，クライアントがEJBクライアントの場合は，WebコンテナをEJBクライアントに置き換えてください。EJBクライアントからデータベースまでの範囲のタイムアウトが設定できます。

また，Webサーバを経由しないでJ2EEサーバに直接リクエストを送受信する場合は，Webサーバとリバースプロキシは該当しません。このため，タイムアウトを設定するポイントとして，ポイント1〜4は該当しません。J2EEサーバに直接リクエストを送受信する場合にタイムアウトが設定できるポイントについて，次の図に示します。

図8‒10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）

それぞれのポイントに設定するタイムアウトは，次の表に示すような用途で使い分けられます。

表8‒25　各ポイントに設定するタイムアウトの目的とデフォルトのタイムアウト設定

ポイント

タイムアウトの種類

主な用途

1

Webサーバ側で設定するクライアントからのリクエスト受信およびクライアントへのデータ送信のタイムアウト

通信路の障害，またはWebサーバの障害の検知

2

リバースプロキシ側で設定するWebコンテナへのリクエスト送信処理のうち，コネクション確立のタイムアウト

通信路の障害またはWebコンテナの障害検知

3

リバースプロキシ側で設定するWebコンテナへのリクエスト送信処理のうち，リクエストヘッダおよびリクエストボディ送信のタイムアウト

通信路の障害またはWebコンテナの障害検知

4

リバースプロキシ側で設定するWebコンテナからのデータ受信のタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

5

Webコンテナ側で設定するリバースプロキシまたはWebクライアントからのデータ受信のタイムアウト

通信路の障害，Webサーバの障害検知，または不正なクライアントからのアクセスの検知

6

Webアプリケーションで設定するメソッドの実行時間のタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど）

7

EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIネーミングサービス呼び出しのタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

8※

EJBクライアント側で設定するCTMからのEnterprise Bean呼び出しのタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

9

EJBで設定するメソッドの実行時間のタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど）

10

EJBコンテナ側で設定するデータベースのトランザクションタイムアウト

データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止

11

DB Connectorで設定するコネクション取得時のタイムアウト

コネクション取得時の障害検知（通信路の障害またはリソース枯渇）

12

データベースのタイムアウト

データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止

13

Webコンテナ側で設定するリバースプロキシまたはWebクライアントへのレスポンス送信のタイムアウト

通信路の障害またはWebサーバの障害検知

注※　CTMを使用している場合にだけ存在するポイントです。CTMを利用しない構成の場合，ポイント7の範囲はWebコンテナからEJBコンテナにEJBリモート呼び出しを実行してから，EJBコンテナからWebコンテナに実行結果が送信されるまでの間になります。

これらのタイムアウトの基本的な設定指針は次のとおりです。

タイムアウト値の設定は，呼び出し元（WebクライアントまたはEJBクライアント）に近いほど大きな値を設定するのが原則です。このため，次の関係で設定することを推奨します。

ポイント1<ポイント5

ポイント4>ポイント6>ポイント7

ポイント7=ポイント8>ポイント9>ポイント10

ポイント10>ポイント11

ポイント9>ポイント12

ポイント1<ポイント13

4，7，10，12のポイントのタイムアウト値を設定する場合は，呼び出し処理に通常どの程度の時間が掛かっているかを見極めた上で，呼び出す処理（業務）ごとに算出して設定してください。

なお，1〜13のポイントは，システムでの位置づけによって，次の三つに分けられます。

Webフロントシステムで意識する必要があるポイント（1〜6，および13）

詳細は，「8.6.2　Webフロントシステムでのタイムアウトを設定する」を参照してください。

バックシステムで意識する必要があるポイント（7〜9）

詳細は，「8.6.3　バックシステムでのタイムアウトを設定する」を参照してください。

データベース接続時に意識する必要があるポイント（10〜12）

このポイントは，さらにトランザクションでのタイムアウト，DB Connectorでのタイムアウト，およびデータベースでのタイムアウトに分けて意識する必要があります。

詳細は，「8.6.4　トランザクションタイムアウトを設定する」，「8.6.6　データベースでのタイムアウトを設定する」を参照してください。

それぞれのポイントでの設定については，「8.6.8　タイムアウトを設定するチューニングパラメタ」を参照してください。

参考

それぞれのポイントのデフォルト値は次のとおりです。

ポイント

デフォルト値

1

60秒

2

60秒

3

60秒

4

60秒

5

300秒

6

設定されていません。タイムアウトしません。

7

設定されていません。レスポンスを待ち続けます。

8

ポイント7と同じ値がEnterprise Bean呼び出し時に自動的に引き継がれて設定されます。

9

設定されていません。タイムアウトしません。

10

180秒

11

タイムアウトの設定個所ごとに異なります。

物理コネクション確立時のタイムアウト：8秒

コネクション枯渇時のコネクション取得要求のタイムアウト：30秒

コネクション障害検知時のタイムアウト：5秒

12

データベースの種類とタイムアウトの設定個所ごとに異なります。

HiRDBの場合

ロック解放待ちタイムアウト：180秒

レスポンスタイムアウト：0秒（HiRDBクライアントはHiRDBサーバからの応答があるまで待ち続けます）

リクエスト間隔タイムアウト：600秒

Oracleの場合（グローバルトランザクションを使用するとき）

ロック解放待ちタイムアウト：60秒

SQL Serverの場合

メモリ取得待ちタイムアウト：-1（-1を指定した場合の動作は，SQL Serverのドキュメントを参照してください）

ロック解放待ちタイムアウト：-1（ロックが解放されるまで待ち続けます）

XDM/RD E2の場合

ロック解放待ちタイムアウト：なし（タイムアウト時間を監視しません）

SQL実行CPU時間タイムアウト：10秒

SQL実行経過時間タイムアウト：0秒（タイムアウト時間を監視しません）

トランザクション経過時間タイムアウト：600秒

レスポンスタイムアウト：0秒（HiRDBクライアントはXDM/RD E2サーバからの応答があるまで待ち続けます）

13

300秒

8.6.2　Webフロントシステムでのタイムアウトを設定する

ここでは，Webフロントシステムでのタイムアウトの設定について説明します。

Webフロントシステムのタイムアウトを設定する場合は，システム全体のタイムアウトのうち，次の図に示す，1〜6および13のポイントについて意識する必要があります。この番号は，「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」と対応しています。

ポイント

Webサーバを経由しないでJ2EEサーバに直接リクエストを送受信する場合，設定できるのは5〜13のポイントです。1〜4のポイントは該当しません。

図8‒11　Webフロントシステムの場合に意識するタイムアウトのポイント（1〜6，および13のポイント）

Webサーバでのクライアントからのリクエスト受信，およびクライアントへのデータ送信待ち時間（1のポイント）

Webブラウザからの要求が滞った場合に，タイムアウトによってWebサーバのリソースを解放します。また，Webブラウザへの応答が滞った場合（Webブラウザが受信しない場合）に，タイムアウトによってWebサーバおよびJ2EEサーバ内のWebコンテナのリソースを解放します。

これらの待ち時間には，同じ値が設定されます。Webサーバと連携する場合にだけ設定できるポイントです。

Webサーバに登録したリバースプロキシでのWebコンテナへのリクエスト送信待ち時間（2および3のポイント）

リバースプロキシからWebコンテナへのリクエスト送信時に，Webコンテナ自体のトラブル，またはWebサーバとWebコンテナ間の通信路でのトラブルによって制御が戻らなくなった場合に，タイムアウトによってWebサーバのリソースを解放します。また，同時にWebブラウザにエラーを通知します。Webサーバと連携する場合にだけ設定できるポイントです。

ポイント2はWebコンテナとのコネクション確立の待ち時間，ポイント3はWebコンテナへのリクエスト送信処理の待ち時間です。

Webサーバに登録したリバースプロキシでのWebコンテナからのデータ受信待ち時間（4のポイント）

J2EEアプリケーションで何かのトラブルが発生して制御が戻らなくなった場合に，タイムアウトによってWebサーバのリソースを解放します。また，同時にWebブラウザにエラーを通知します。Webサーバと連携する場合にだけ設定できるポイントです。

ポイント

設定の単位はリバースプロキシの転送先単位です。このため，業務によって処理に掛かる時間が異なる場合は，業務に対応するWebアプリケーション単位でリバースプロキシの転送先を定義してタイムアウトを設定することをお勧めします。

WebコンテナでのリバースプロキシまたはWebクライアントからのデータ受信待ち時間（5のポイント）

Webサーバ連携の場合は，リバースプロキシからWebコンテナへのリクエスト送信時に，Webサーバ自体のトラブル，またはWebサーバとWebコンテナ間の通信路でのトラブルによって要求が滞ったときに，J2EEサーバ（Webコンテナ）のリソースを解放します。

Webサーバを経由しないでJ2EEサーバに直接リクエストを送受信する場合は，Webブラウザからの要求が滞ったときに，J2EEサーバ（Webコンテナ）のリソースを解放します。

ポイント

リバースプロキシを使用する場合は，タイムアウトを無効にした常設コネクションにすることをお勧めします。

なお，ポイント5のタイムアウトを無効にした状態で，Webコンテナでのリクエスト処理時間よりもポイント4のタイムアウト時間が短い場合，リバースプロキシ側でタイムアウトが発生します。

この場合，クライアントとWebサーバ間の通信は切断されるため，Webサーバは新たなクライアントからの接続を受け入れ，J2EEサーバへの新たな接続を試みます。ただし，リバースプロキシ側でタイムアウトになったリクエストが，J2EEサーバ内で処理中であり，かつすでにJ2EEサーバの最大同時接続数までコネクションが接続されているとき，リクエストの処理が完了するまで，J2EEサーバは新規の接続を受け付けられない状態になります。

そのため，常設コネクションにする場合は，ポイント4のタイムアウト時間をWebコンテナでのリクエスト処理時間よりも長く設定することを推奨します。

Webコンテナ上でのリクエスト処理待ち時間（6のポイント）

J2EEアプリケーションの実行時間監視機能を利用します。

「8.6.7　J2EEアプリケーションのメソッドタイムアウトを設定する」を参照してください。

WebコンテナからリバースプロキシまたはWebクライアントへのレスポンス送信待ち時間（13のポイント）

Webサーバ連携の場合は，Webコンテナからリバースプロキシへのレスポンス送信時に，Webサーバ自体のトラブル，またはWebサーバとWebコンテナ間の通信路でのトラブルによって制御が戻らなくなった場合に，タイムアウトによってWebコンテナのリソースを解放します。

Webサーバを経由しないでJ2EEサーバに直接リクエストを送受信する場合は，Webブラウザへの通信が滞ったときに，タイムアウトによってWebコンテナのリソースを解放します。

8.6.3　バックシステムでのタイムアウトを設定する

ここでは，バックシステムでのタイムアウトの設定について説明します。なお，バックシステムでのタイムアウトのうち，データベースなどのEISとのトランザクションに関連するタイムアウトについては，「8.6.4　トランザクションタイムアウトを設定する」で説明します。ここではEJBクライアントとEJBコンテナに関連するタイムアウトについて説明します。

バックシステムのタイムアウトを設定する場合は，システム全体のタイムアウトのうち，次の図に示す，7〜9のポイントについて意識する必要があります。なお，この番号は，「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」と対応しています。

図8‒12　バックシステムの場合に意識するタイムアウトのポイント

Enterprise Beanをリモート呼び出し（RMI-IIOP通信）する場合とCORBAネーミングサービスを呼び出す場合のクライアント側待ち時間（7のポイント）

CORBAネーミングサービスまたはJ2EEアプリケーションへのアクセスで何かのトラブルが発生して制御が戻らなくなった場合に，タイムアウトによってEJBクライアントにエラーを通知します。

CTMまたはEJBクライアントからEnterprise Beanを呼び出す場合のクライアント側待ち時間（8のポイント）

J2EEアプリケーションで，無限ループやデッドロックなど何らかのトラブルが発生した場合に，CTMのリソースを解放します。また，EJBクライアントにエラーを通知します。

ポイント

EJBクライアントからEnterprise Beanを呼び出す場合，タイムアウトはusrconf.propertiesまたはアプリケーションサーバが提供するAPI（com.hitachi.software.ejb.ejbclient.RequestTimeoutConfigクラスのメソッド）に指定できます。

usrconf.propertiesの定義は，プロセス全体に影響します。APIに指定したタイムアウトは，ビジネスメソッドを呼び出すスレッドまたはオブジェクトの範囲に影響します。また，APIの指定は，usrconf.propertiesの定義よりも優先されます。

このため，プロセス全体に設定したい標準的な値をusrconf.propertiesに定義して，呼び出す業務によって細かく設定したい値は適宜APIを使用して設定することをお勧めします。

Enterprise Beanの呼び出しでタイムアウトが発生した場合，EJBクライアント側には，javax.rmi.RemoteException（org.omg.CORBA.TIMEOUTなど）例外が通知されます。これによって，クライアント側のリクエストはキャンセルされます。ただし，この時点でサーバ側のEnterprise Beanの処理がすでに開始されていた場合は，そのまま処理が継続されます。このため，タイムアウトが発生した場合でも，サーバ側の処理は正常に終了することがあります。

EJBコンテナ上でのメソッド処理待ち時間（9のポイント）

J2EEアプリケーションの実行時間監視機能を利用します。

「8.6.7　J2EEアプリケーションのメソッドタイムアウトを設定する」を参照してください。

また，9のポイントで，Stateless Session Beanのmethod-readyプールおよびEntity Beanのpoolプールのインスタンスが時間内に取得できない場合も，タイムアウトが設定できます。この場合は，クライアントにjava.rmi.RemoteException（リモートクライアントの場合）またはjavax.ejb.EJBException（ローカルクライアントの場合）が送出されます。

8.6.4　トランザクションタイムアウトを設定する

ここでは，トランザクションタイムアウトの設定について説明します。トランザクションタイムアウトは，データベースシステムなどEISとのトランザクションに設定します。

DB Connectorを使用してデータベースにアクセスするときのトランザクションタイムアウトについて説明します。

トランザクションタイムアウトを設定する場合は，システム全体のタイムアウトのうち，EJBコンテナとデータベースのトランザクション（図の10のポイント）について意識する必要があります。なお，この番号は，「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」と対応しています。

図8‒13　EISとのトランザクションで意識するタイムアウトのポイント

トランザクションタイムアウトが発生すると，アプリケーションサーバによって，次の処理が実行されます。

実行中のトランザクションはロールバックされます。

トランザクションに参加しているコネクションはクローズされ，コネクションプールから削除されます。

ポイント

トランザクションのタイムアウトは，CMTの場合とUserTransactionの場合で設定方法が異なります。

CMTの場合

CMTの場合，トランザクションのタイムアウトは，usrconf.propertiesで定義するか，またはEnterprise Bean，インタフェース，もしくはメソッドの属性として設定できます。Enterprise Bean，インタフェースまたはメソッドの属性は，サーバ管理コマンドで設定します。

usrconf.propertiesの定義は，プロセス全体に影響します。Enterprise Bean，インタフェースまたはメソッドの属性に設定したタイムアウトは，該当するEnterprise Bean，インタフェースまたはメソッドが使用するトランザクションの範囲だけに影響します。また，この指定は，usrconf.propertiesの定義よりも優先されます。

このため，プロセス全体に設定したい標準的な値をusrconf.propertiesに定義して，呼び出す業務によって細かく設定したい値はEnterprise Bean，インタフェース，またはメソッドの属性として設定することをお勧めします。

UserTransactionの場合

UserTransactionの場合，トランザクションのタイムアウトは，usrconf.propertiesまたはJTAのAPI（javax.transaction.UserTransaction#setTransactionTimeoutメソッド）に指定できます。

usrconf.propertiesの定義は，プロセス全体に影響します。APIに指定したタイムアウトは，APIを発行したトランザクションの範囲だけに影響します。また，APIの指定は，usrconf.propertiesの定義よりも優先されます。

このため，プロセス全体に設定したい標準的な値をusrconf.propertiesに定義して，呼び出す業務によって細かく設定したい値は適宜APIを使用して設定することをお勧めします。

ポイント

トランザクションタイムアウトとコネクション取得に関連する設定値として，次のような関係が成り立つように設定してください。

トランザクションタイムアウト＞コネクション枯渇時のコネクション取得要求のタイムアウト＋障害検知タイムアウト＋接続確立の最大待ち時間×コネクション取得実行回数＋リトライ間隔×リトライ回数

これをパラメタで示すと次のようになります。

ejbserver.jta.TransactionManager.defaultTimeOut＞RequestQueueTimeout＋ejbserver.connectionpool.validation.timeout＋loginTimeout×（RetryCount＋1）＋RetryInterval×RetryCount

また，トランザクションタイムアウトの設定値には，コネクション取得に掛かる時間以外にトランザクションの実行時間を加算する必要があります。

トランザクションタイムアウトが発生した場合，ユーザアプリケーションに例外は通知されません。ただし，メッセージKDJE31002-WがログファイルとJ2EEサーバのコンソールに出力されます。また，トランザクションタイムアウトが発生したあとで，ユーザアプリケーションから該当するトランザクションを使用してJTAインタフェースまたはJDBCインタフェースを使用しようとすると，例外が通知されます。

8.6.5　DB Connectorでのタイムアウトを設定する

ここでは，DB Connectorでのタイムアウトの設定について説明します。

DB Connectorでは，次の3種類のタイムアウトを設定できます。

物理コネクション確立時のタイムアウト

物理コネクションの確立時に発生するタイムアウトです。HiRDB，OracleおよびSQL Serverで設定できます。

このタイムアウトが発生した場合に実行される動作は次のとおりです。

ユーザアプリケーションに例外が通知されます。

コネクション枯渇時のコネクション取得要求のタイムアウト

コネクション枯渇時のコネクション取得要求待ち時に発生するタイムアウトです。

このタイムアウトが発生した場合に実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

コネクション障害検知時のタイムアウト

コネクション障害検知時に発生するタイムアウトです。コネクション取得要求時に障害検知された場合に発生します。

このタイムアウトが発生した場合に実行される動作は次のとおりです。

タイムアウトが発生したことを示すメッセージKDJE48602-Wが出力されます。障害検知されたコネクションは破棄されて，新たに作成されたコネクションがユーザプログラムに返されます。

8.6.6　データベースでのタイムアウトを設定する

ここでは，次に示すデータベースでのタイムアウトの設定について説明します。

HiRDB

MySQL

Oracle

PostgreSQL

SQL Server

XDM/RD E2

なお，Oracleの場合は，グローバルトランザクションとローカルトランザクションのどちらを使用しているかによって，設定できる項目が異なります。

(1)　HiRDBのタイムアウト

HiRDBでは，次の3種類のタイムアウトを設定できます。

ロック解放待ちタイムアウト

デッドロックやリソースの長時間占有を防止するために設定するタイムアウトです。HiRDBサーバのシステム共通定義のpd_lck_wait_timeoutパラメタに設定します。ここで設定するタイムアウト時間は，排他待ち時間を監視する最大時間です。排他待ち時間とは，排他要求が待ち状態になってから解除されるまでの時間です。

このタイムアウトが発生した場合にアプリケーションサーバおよびHiRDBによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すHiRDBのメッセージKFPA11770-Iが出力されます。または，デッドロックが発生したことを示すHiRDBのメッセージKFPA11911-Eが出力されます。

実行中のトランザクションはロールバックされます。

ユーザアプリケーションのビジネスメソッド終了後に，コネクションはクローズされ，コネクションプールから削除されます。

レスポンスタイムアウト

データベースシステムのサーバ側の障害を検知するためのタイムアウトです。

HiRDBのクライアント環境変数のPDCWAITTIMEに設定します。ここで設定するタイムアウト時間は，HiRDBクライアントからHiRDBサーバに要求をしてから，応答が戻ってくるまでのHiRDBクライアントの最大待ち時間です。長時間SQLの時間を監視する場合などに指定します。

このタイムアウトが発生した場合にアプリケーションサーバおよびHiRDBによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すHiRDBのメッセージKFPA11732-Eが出力されます。

実行中のトランザクションはロールバックされます。

コネクションはクローズされて，コネクションプールから削除されます。

リクエスト間隔タイムアウト

データベースシステムのクライアント側の障害を検知するためのタイムアウトです。

HiRDBのクライアント環境変数のPDSWAITTIMEに設定します。ここで設定するタイムアウトは，HiRDBサーバがHiRDBクライアントからの要求に対する応答を返してから，次にHiRDBクライアントから要求が送信されるまでのHiRDBサーバの最大待ち時間です。時間監視は，トランザクションの処理中（SQL実行開始からコミットまたはロールバックまでの間）が対象になります。HiRDBクライアントからの要求がHiRDBサーバに到着した段階でリセットされます。

このタイムアウトが発生した場合にアプリケーションサーバおよびHiRDBによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すHiRDBのメッセージKFPA11723-Eが出力されます。

実行中のトランザクションはロールバックされます。

コネクションはクローズされて，コネクションプールから削除されます。

ノンブロックモードでのコネクション確立タイムアウト

LAN障害を早く検知するためのタイムアウトです。

HiRDBのクライアント環境変数のPDNBLOCKWAITTIMEに設定します。ここで設定するタイムアウトは，HiRDBサーバとHiRDBクライアントの間のコネクション確立を監視する時間です。

このタイムアウトが発生した場合にアプリケーションサーバおよびHiRDBによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

(2)　MySQLのタイムアウト

MySQLのタイムアウトについてはMySQLのマニュアルを参照してください。

(3)　Oracleのタイムアウト（ローカルトランザクションの場合）

Oracleでローカルトランザクションを使用している場合は，次のタイムアウトを設定できます。

クエリータイムアウト

クエリータイムアウトは，JDBCドライバとしてOracle JDBC Thin Driverを使用する場合だけ設定できるタイムアウトです。java.sql.StatementインタフェースのsetQueryTimeoutメソッドを利用してタイムアウトを設定します。Oracle JDBC Thin Driverを使用してOracleに接続する場合の注意事項は，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6.7　Oracleと接続する場合の前提条件と注意事項」を参照してください。

なお，デッドロックが発生した場合は，OracleのメッセージORA-00060が出力されます。また，アプリケーションサーバによってユーザアプリケーションのビジネスメソッド終了後にコネクションがクローズされ，コネクションプールから削除されます。

(4)　Oracleのタイムアウト（グローバルトランザクションの場合）

Oracleでグローバルトランザクションを使用している場合は，次のタイムアウトを設定できます。

クエリータイムアウト

クエリータイムアウトについては，「8.6.6(3)　Oracleのタイムアウト（ローカルトランザクションの場合）」のクエリータイムアウトの説明を参照してください。

ロック解放待ちタイムアウト

デッドロックやリソースの長時間占有を防止するために設定するタイムアウトです。Oracleのサーバ定義のDISTRIBUTED_LOCK_TIMEOUTパラメタに設定します。このタイムアウトが発生した場合にアプリケーションサーバおよびOracleによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すOracleのメッセージORA-02049が出力されます。または，デッドロックが発生したことを示すOracleのメッセージORA-00060が出力されます。

ユーザアプリケーションのビジネスメソッド終了後に，コネクションはクローズされ，コネクションプールから削除されます。

なお，実行中のトランザクションはロールバックされません。

(5)　PostgreSQLのタイムアウト

PostgreSQLのタイムアウトについてはPostgreSQLのマニュアルを参照してください。

(6)　SQL Serverのタイムアウト

SQL Serverでは，次の2種類のタイムアウトを設定できます。

メモリ取得待ちタイムアウト

SQL実行時のメモリ取得待ち時間を監視するために設定するタイムアウトです。SQL Serverの環境設定オプションのquery waitパラメタに設定します。ここで設定するタイムアウト時間は，SQLの実行に必要なメモリが得られなかったときのメモリ取得待ち時間です。

このタイムアウトが発生した場合にアプリケーションサーバおよびSQL Serverによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すSQL Serverのメッセージ8645が出力されます。

実行中のトランザクションはロールバックされます。

ユーザアプリケーションプログラムのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

ロック解放待ちタイムアウト

デッドロックやリソースの長時間占有を防止するために設定するタイムアウトです。SQL ServerのSET LOCK_TIMEOUTステートメントを実行することで設定します。ここで設定するタイムアウト時間は，ロックが解除されるまでの待ち時間です。

このタイムアウトが発生した場合にアプリケーションサーバおよびSQL Serverによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すSQL Serverのメッセージ1222が出力されます。

ユーザアプリケーションプログラムのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

また，SQL Serverでデッドロックが発生した場合にアプリケーションサーバおよびSQL Serverによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

デッドロックが発生したことを示すSQL Serverのメッセージ1205が出力されます。

実行中のトランザクションはロールバックされます。

ユーザアプリケーションプログラムのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

(7)　XDM/RD E2のタイムアウト

XDM/RD E2では，次の5種類のタイムアウトを設定できます。

ロック解放待ちタイムアウト

デッドロックやリソースの長時間占有を防止するために設定するタイムアウトです。XDM/BASEのシステムオプション定義のTIMERパラメタに設定します。ここで設定するタイムアウト時間は，排他待ち時間を監視する最大時間です。排他待ち時間とは，排他要求が待ち状態になってから解除されるまでの時間です。

このタイムアウトが発生した場合に，アプリケーションサーバおよびXDM/RD E2によって実行される動作は次のとおりです。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトまたはデッドロックが発生したことを示すXDM/RD E2のメッセージJXZ1911Iが出力されます。

実行中のトランザクションはロールバックされます。

J2EEアプリケーションのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

また，XDM/RD E2でデッドロックが発生したときの動作は，ロック解放待ちタイムアウトが発生したときと同じになります。

SQL実行CPU時間タイムアウト

SQL実行時のCPU処理時間を監視するために設定するタイムアウトです。DBコネクションサーバのコントロール空間起動制御文またはサーバ空間起動制御文のSQLCTIMEパラメタに設定します。ここで設定するタイムアウト時間は，一つのSQLを実行したときのCPU処理時間を監視する最大時間です。長時間SQLの時間を監視する場合などに指定します。

このタイムアウトが発生した場合にアプリケーションサーバおよびXDM/RD E2によって実行される動作は次のとおりです。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すメッセージが出力されます。メッセージは，DBコネクションサーバのコントロール空間起動制御文に指定したVPARTOPTIONパラメタの指定値によって変わります。指定を省略するかERROR NORMALを指定した場合には，HiRDBクライアントのメッセージKFPA11723-Eが出力されます。それ以外の値を指定した場合には，XDM/RD E2のメッセージJXZ1874Iが出力されます。

実行中のトランザクションはロールバックされます。

VPARTOPTIONパラメタの指定を省略するかERROR NORMALを指定した場合には，コネクションはクローズされ，コネクションプールから削除されます。それ以外の値を指定した場合には，タイムアウト発生後の初回のデータベースアクセス時，またはJ2EEアプリケーションのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

SQL実行経過時間タイムアウト

SQL実行時の経過時間を監視するために設定するタイムアウトです。DBコネクションサーバのコントロール空間起動制御文またはサーバ空間起動制御文のSQLETIMEパラメタに設定します。ここで設定するタイムアウト時間は，一つのSQLを実行したときの経過時間を監視する最大時間です。長時間SQLの時間を監視する場合などに指定します。

このタイムアウトが発生した場合にアプリケーションサーバおよびXDM/RD E2によって実行される動作は次のとおりです。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すメッセージが出力されます。メッセージは，DBコネクションサーバのコントロール空間起動制御文に指定したVPARTOPTIONパラメタの指定値によって変わります。指定を省略するか，ERROR NORMALまたはERROR SQLCTIMEを指定した場合には，HiRDBクライアントのメッセージKFPA11723-Eが出力されます。それ以外の値を指定した場合には，XDM/RD E2のメッセージJXZ1874Iが出力されます。

実行中のトランザクションはロールバックされます。

VPARTOPTIONパラメタの指定を省略するか，ERROR NORMALまたはERROR SQLCTIMEを指定した場合には，コネクションはクローズされ，コネクションプールから削除されます。それ以外の値を指定した場合には，タイムアウト発生後の初回のデータベースアクセス時，またはJ2EEアプリケーションのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

トランザクション経過時間タイムアウト

トランザクションの開始時点からの経過時間を監視するために設定するタイムアウトです。DBコネクションサーバのコントロール空間起動制御文またはサーバ空間起動制御文のSVETIMEパラメタに設定します。ここで設定するタイムアウト時間は，トランザクションの経過時間を監視する最大時間です。

このタイムアウトが発生した場合にアプリケーションサーバおよびXDM/RD E2によって実行される動作は次のとおりです。なお，タイムアウトが発生したときにSQLを実行していた場合には，その時点で実行されます。SQLを実行していなかった場合には，タイムアウト発生後のSQL実行時に実行されます。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すメッセージが出力されます。メッセージは，DBコネクションサーバのコントロール空間起動制御文に指定したVPARTOPTIONパラメタの指定値によって変わります。指定を省略するか，ERROR NORMALまたはERROR SQLCTIMEを指定した場合には，HiRDBクライアントのメッセージKFPA11723-Eが出力されます。それ以外の値を指定した場合には，XDM/RD E2のメッセージJXZ1874Iが出力されます。

実行中のトランザクションはロールバックされます。

VPARTOPTIONパラメタの指定を省略するか，ERROR NORMALまたはERROR SQLCTIMEを指定した場合には，コネクションはクローズされ，コネクションプールから削除されます。それ以外の値を指定した場合には，タイムアウト発生後の初回のデータベースアクセス時，またはJ2EEアプリケーションのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

レスポンスタイムアウト

データベースシステムのサーバ側の障害を検知するためのタイムアウトです。

HiRDBのクライアント環境変数のPDCWAITTIMEに設定します。ここで設定するタイムアウト時間は，HiRDBクライアントからXDM/RD E2サーバに要求をしてから，応答が戻ってくるまでのHiRDBクライアントの最大待ち時間です。長時間SQLの時間を監視する場合などに指定します。

このタイムアウトが発生した場合にアプリケーションサーバおよびHiRDBによって実行される動作は次のとおりです。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すHiRDBクライアントのメッセージKFPA11732-Eが出力されます。

実行中のトランザクションはロールバックされます。

コネクションはクローズされて，コネクションプールから削除されます。

(8)　データベースへのアクセスでタイムアウトまたはデッドロックが発生した場合のユーザアプリケーションの処理

ユーザアプリケーションでデータベースのタイムアウトまたはデッドロックによる例外が発生した場合には，実行中のトランザクションをロールバックして，ビジネスメソッドの処理を中止してください。また，必要に応じてこの項で説明したタイムアウトパラメタを見直してください。

8.6.7　J2EEアプリケーションのメソッドタイムアウトを設定する

ここでは，J2EEアプリケーションのメソッドタイムアウトの設定について説明します。メソッドタイムアウトを設定することによって，ポイント6とポイント9で，WebコンテナまたはEJBコンテナ上の業務処理での無限ループが発生した場合などに，タイムアウトによって検知できるようになります。また，タイムアウトを検知したメソッドを強制的にキャンセル（メソッドキャンセル）することもできます。メソッドキャンセル機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3.2　J2EEアプリケーション実行時間の監視とは」を参照してください。

メソッドタイムアウトを設定する場合の考え方について説明します。

J2EEアプリケーション内でメソッドの呼び出しが入れ子になっている場合，タイムアウト値として，呼び出し元の方に大きな値を設定するように，メソッドの呼び出し順序を考慮して設定してください。

設定例を次に示します。

図8‒14　メソッドのタイムアウトの設定例

この例では，呼び出し元に近いメソッドに大きな値を設定しています。これによって，メソッドのどこかでタイムアウトが発生した場合，クライアントから遠いメソッドから順番にタイムアウトが発生します。タイムアウトはメッセージで通知されます。設定によっては，このタイミングでメソッドキャンセルを自動実行できます。

リモート呼び出しを実行するメソッドに対してメソッドタイムアウトおよびメソッドキャンセルを設定した場合は，呼び出し順序に注意してください。メソッドキャンセル機能では，リモート呼び出し中のメソッドは保護区で実行中と判断されます。呼び出し元に近いメソッドで先にタイムアウトが発生した場合，メソッドはリモート呼び出し中であるため，メソッドキャンセルができません。例のように呼び出し元に近い方に大きい値を設定しておけば，タイムアウトは呼び出し元から遠い順に発生するため，タイムアウトが発生したメソッドがリモート呼び出しをしていることはありません。このため，確実にメソッドキャンセルを実行できます。

ローカル呼び出しを実行するメソッドに対してメソッドタイムアウトおよびメソッドキャンセルをする設定をした場合も，呼び出し元から遠い順にキャンセルされるようにすることで，タイムアウトが発生したメソッドとキャンセルが実行されたメソッドを一致させることができます。

タイムアウト値を設定できるメソッドについては，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3.4　メソッドキャンセルとは」を参照してください。

ローカル呼び出しのメソッドを入れ子で呼び出している場合の注意

簡易構築定義ファイルの<param-name>タグに指定するejbserver.rmi.localinvocation.scopeにappまたはallを指定している場合，一つのメソッドから入れ子で呼び出されるローカル呼び出しのメソッドは，すべて同一スレッド上で実行されます。このとき，次の点に注意してください。

入れ子で呼び出されるメソッドのタイムアウトやメソッドキャンセルが失敗すると，そのメソッドが終了するまで同一スレッドのほかのメソッドではタイムアウトが発生しません。

タイムアウトが発生したメソッドから入れ子で呼び出されているメソッドに対してメソッドキャンセルを実行した場合，コンテナによってキャンセルされるのは，メソッドキャンセルを実行した対象のメソッドだけです。タイムアウトが発生した呼び出し元のメソッドは，キャンセルの対象にはなりません。このため，キャンセルを実行したあとも，通常入れ子のメソッドの呼び出す場合と同様に，順次呼び出されたメソッドが終了していきます。なお，それらの順次呼び出されるメソッドもタイムアウト監視の対象になります。

同一スレッド上でローカル呼び出しのメソッドを入れ子で呼び出している場合の注意を次の図に示します。

図8‒15　同一スレッド上でローカル呼び出しのメソッドを入れ子で呼び出している場合の注意

8.6.8　タイムアウトを設定するチューニングパラメタ

ここでは，タイムアウトの設定で使用するチューニングパラメタの設定方法についてまとめて示します。

(1)　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」のポイント1のタイムアウトを設定するチューニングパラメタです。Webサーバ連携の場合だけ指定できます。

表8‒26　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウトのチューニングパラメタ

設定項目

設定個所

クライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

httpsd.confのTimeoutディレクティブ

(2)　リバースプロキシ側で設定するWebコンテナへのデータ送信のタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」のポイント2，およびポイント3のタイムアウトを設定するチューニングパラメタです。リバースプロキシ側で設定するタイムアウトのチューニングパラメタについて説明します。なお，これらのチューニングパラメタは，Webサーバ連携の場合だけ指定できます。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒27　リバースプロキシ側で設定するタイムアウトのチューニングパラメタ

ポイント

設定項目

設定対象

設定個所（パラメタ名）

2

リクエスト送信時のWebコンテナに対するコネクション確立のタイムアウト

論理Webサーバ（web-server）

manager.web.reverseproxy.mappingのtimeoutキー

3

リクエスト送信のタイムアウト

論理Webサーバ（web-server）

manager.web.reverseproxy.mappingのtimeoutキー

(3)　リバースプロキシ側で設定するWebコンテナからのデータ受信のタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」のポイント4のタイムアウトを設定するチューニングパラメタです。

リバースプロキシの転送先単位で設定します。リバースプロキシ側で設定するタイムアウトのチューニングパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒28　リバースプロキシ側で設定するタイムアウトのチューニングパラメタ

設定項目

設定対象

設定個所（パラメタ名）

レスポンスデータ待ちの通信タイムアウト

論理Webサーバ（web-server）

manager.web.reverseproxy.mappingのtimeoutキー

Webサーバ連携の場合だけ指定できます。

(4)　Webコンテナ側で設定するリバースプロキシまたはWebクライアントからのデータ受信のタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」のポイント5のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒29　Webコンテナ側で設定するタイムアウトのチューニングパラメタ

設定項目

設定対象

設定個所（パラメタ名）

リバースプロキシまたはWebクライアントからの応答待ちのタイムアウト

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.receive_timeout

(5)　Webコンテナ側で設定するリバースプロキシまたはWebクライアントへのデータ受信のタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」のポイント13のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒30　Webコンテナ側で設定するタイムアウトのチューニングパラメタ

設定項目

設定対象

パラメタ名

レスポンス送信処理のタイムアウト

論理J2EEサーバ（j2ee-server）

webserver.connector.nio_http.send_timeout

(6)　EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」のポイント7のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位，EJBクライアントアプリケーション単位またはAPIによる呼び出し単位に設定します。

EJBクライアント側で設定するタイムアウトのチューニングパラメタ（RMI-IIOP通信によるリモート呼び出し）を次の表に示します。

表8‒31　EJBクライアント側で設定するタイムアウトのチューニングパラメタ（RMI-IIOP通信によるリモート呼び出し）

単位

設定方法

設定項目

設定個所

J2EEサーバ単位

Smart Composer機能

クライアントとサーバ間の通信タイムアウト

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.rmi.request.timeout

EJBクライアントアプリケーション単位

ファイル編集または開始時に指定するシステムプロパティの指定

定義ファイル（ファイル編集の場合）

usrconf.properties

パラメタ名

ejbserver.rmi.request.timeoutキー

API単位

API

オブジェクト単位で設定する場合

RequestTimeoutConfig#setRequestTimeout(java.rmi.Remote obj, int sec)メソッド※

スレッド単位で設定する場合

RequestTimeoutConfig#setRequestTimeout(int sec)メソッド※

注※　パッケージ名はcom.hitachi.software.ejb.ejbclientです。

EJBクライアント側で設定するタイムアウトのチューニングパラメタ（ネーミングサービス呼び出し）を次の表に示します。

表8‒32　EJBクライアント側で設定するタイムアウトのチューニングパラメタ（ネーミングサービス呼び出し）

単位

設定方法

設定項目

設定個所

J2EEサーバ単位

Smart Composer機能

ネーミングサービスとの通信タイムアウト時間

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.jndi.request.timeout

EJBクライアントアプリケーション単位

ファイル編集または開始時に指定するシステムプロパティの指定

定義ファイル（ファイル編集の場合）

usrconf.properties

パラメタ名

ejbserver.jndi.request.timeoutキー

(7)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」のポイント8のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位，EJBクライアントアプリケーション単位またはAPIによる呼び出し単位に設定します。

なお，このタイムアウトの設定値には，「8.6.8(6)　EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト」で指定した設定値と同じ値が引き継がれます。

(8)　EJBコンテナ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合）

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」のポイント10のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位，Enterprise Bean，インタフェース，メソッド単位（CMTの場合），またはAPIによる呼び出し単位（BMTの場合）に設定します。

トランザクションタイムアウトのチューニングパラメタを次の表に示します。

表8‒33　トランザクションタイムアウトのチューニングパラメタ

単位

設定方法

設定項目

設定個所

J2EEサーバ単位

Smart Composer機能

トランザクションのトランザクションタイムアウト時間のデフォルト

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.jta.TransactionManager.defaultTimeOut

Enterprise Bean，インタフェース，メソッド単位（CMTの場合）

サーバ管理コマンドのcjsetapppropコマンド

トランザクションタイムアウト時間

定義ファイル

Session Bean属性ファイル，Entity Bean属性ファイル，またはMessage-driven Bean属性ファイル

パラメタ名

<ejb-transaction-timeout>

API単位（BMTの場合）

API

UserTransaction#setTransactionTimeoutメソッド※

注※　パッケージ名はjavax.transactionです。

(9)　DB Connectorのタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」のポイント11のタイムアウトを設定するチューニングパラメタです。

DB Connector単位に設定します。

DB Connectorのチューニングパラメタを次の表に示します。

表8‒34　DB Connectorのチューニングパラメタ

単位

設定方法

設定項目

設定個所

DB Connector単位

サーバ管理コマンドのcjsetrarpropまたはcjsetresprop

物理コネクション確立時のタイムアウト

定義ファイル

Connector属性ファイル

設定対象

DB Connector

パラメタ名

loginTimeout

コネクション枯渇時のコネクション取得要求のタイムアウト

定義ファイル

Connector属性ファイル

設定対象

DB Connector

パラメタ名

RequestQueueTimeout

J2EEサーバ単位

Smart Composer機能

コネクション障害検知のタイムアウト

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.connectionpool.validation.timeout※

注※　コネクション数調節機能のタイムアウト時間と同じプロパティになります。

(10)　データベースのタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」のポイント12のタイムアウトを設定するチューニングパラメタです。

データベースのタイムアウトは，使用するデータベースの種類によって異なります。なお，ここでは，DB Connectorを使用してHiRDB，Oracle，SQL ServerまたはXDM/RD E2にアクセスする場合のタイムアウトの設定方法について説明します。

参考

Oracleを使用している場合，チューニングパラメタによってタイムアウトが設定できるのは，グローバルトランザクションを使用しているときだけです。ローカルトランザクションを使用している場合，パラメタによってタイムアウトを設定することはできません。ただし，メソッドで設定するクエリータイムアウトは，ローカルトランザクション，グローバルトランザクションのどちらでも設定できます。

(a)　HiRDBのタイムアウトの設定

HiRDBサーバのシステム共通定義またはHiRDBのクライアント環境変数に設定します。詳細は，マニュアル「HiRDB システム定義」またはマニュアル「HiRDB UAP開発ガイド」を参照してください。

HiRDBのタイムアウトを設定するチューニングパラメタを次の表に示します。

表8‒35　HiRDBのタイムアウトを設定するチューニングパラメタ

タイムアウトの種類

設定個所

設定方法（パラメタ名）

設定内容

ロック解放待ちタイムアウト

HiRDBサーバのシステム共通定義

pd_lck_wait_timeoutパラメタ

設定値は任意です。

レスポンスタイムアウト

HiRDBのクライアント環境変数

PDCWAITTIME

設定値は任意です。ただし，グローバルトランザクションの場合はトランザクションタイムアウトの値よりも大きな値を指定します。

リクエスト間隔タイムアウト

HiRDBのクライアント環境変数

PDSWAITTIME

設定値は任意です。ただし，グローバルトランザクションの場合はトランザクションタイムアウトの値よりも大きな値を指定します。

参考

PDCWAITTIMEやPDSWAITTIMEがトランザクションタイムアウトの値よりも小さいと，トランザクションとしては制限時間内であっても，データベースの処理は制限時間オーバーになってタイムアウトが発生します。

その場合，トランザクション中であるにもかかわらずデータベースからコネクションが切断され，トランザクションマネージャがトランザクションを決着できなくなります。

また，グローバルトランザクションの場合，コネクション切断後はトランザクション決着の指示が届かないため，トランザクションのリカバリが必要になります。

(b)　Oracleのタイムアウトの設定（グローバルトランザクションを使用している場合）

Oracleのサーバ定義のDISTRIBUTED_LOCK_TIMEOUTパラメタに設定します。

なお，このほか，XAOpenStringのSesTmパラメタの設定がタイムアウトに影響します。このパラメタは，チューニングできません。

(c)　SQL Serverのタイムアウトの設定

SQL Serverの環境設定オプションのパラメタ，またはステートメントの実行によって設定します。

SQL Serverのタイムアウトを設定するチューニングパラメタを次の表に示します。

表8‒36　SQL Serverのタイムアウトを設定するチューニングパラメタ

タイムアウトの種類

設定個所

設定方法（パラメタ名／ステートメント名）

設定内容

メモリ取得待ちタイムアウト

サーバー構成オプション

query waitパラメタ

設定値は任意です。

ロック解放待ちタイムアウト

−

SET LOCK_TIMEOUTステートメント

設定値は任意です。

（凡例）

−：該当しない。

(d)　XDM/RD E2のタイムアウトの設定

XDM/BASEのシステムオプション定義，HiRDBのクライアント環境変数，またはDBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文に設定します。

XDM/RD E2のタイムアウトを設定するチューニングパラメタを次の表に示します。

表8‒37　XDM/RD E2のタイムアウトを設定するチューニングパラメタ

タイムアウトの種類

設定個所

設定方法（パラメタ名）

設定内容

ロック解放待ちタイムアウト

XDM/BASEのシステムオプション定義

TIMER

設定値は任意です。※1

SQL実行CPU時間タイムアウト

DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文

SQLCTIME

設定値は任意です。ただし，グローバルトランザクションの場合はトランザクションタイムアウトの値よりも大きな値を指定します。※2

SQL実行経過時間タイムアウト

DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文

SQLETIME

設定値は任意です。ただし，グローバルトランザクションの場合はトランザクションタイムアウトの値よりも大きな値を指定します。※2

トランザクション経過時間タイムアウト

DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文

SVETIME

設定値は任意です。ただし，グローバルトランザクションの場合はトランザクションタイムアウトの値よりも大きな値を指定します。※2

レスポンスタイムアウト

HiRDBクライアント環境変数

PDCWAITTIME

設定値は任意です。ただし，グローバルトランザクションの場合はトランザクションタイムアウトの値よりも大きな値を指定します。※3

注※1

詳細については，マニュアル「VOS3　データマネジメントシステム XDM E2系 システム定義（XDM/BASE・SD・TM2）」を参照してください。

注※2

詳細については，マニュアル「VOS3　Database Connection Server」を参照してください。

注※3

詳細については，マニュアル「HiRDB XDM/RD E2接続機能」を参照してください。

(11)　J2EEアプリケーションのメソッドタイムアウト

「図8-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）」または「図8-10　タイムアウトが設定できるポイント（J2EEサーバに直接リクエストを送受信する場合）」のポイント6とポイント9のタイムアウトを設定するチューニングパラメタです。

Webアプリケーション内またはEnterprise Bean内のメソッド単位にタイムアウトを設定する場合は，アプリケーションの属性として設定します。また，タイムアウトが発生した場合の動作についても，アプリケーションの属性として設定します。これらの項目は，サーバ管理コマンド（cjsetappprop）で設定します。

メソッドの実行時間のタイムアウトを設定するチューニングパラメタを次の表に示します。なお，ポイントごとに設定個所が異なります。

表8‒38　メソッド実行時間のタイムアウトを設定するチューニングパラメタ

対象になるポイント

タイムアウトの種類およびタイムアウト時の動作

設定個所

6

フィルタ，サーブレットまたはJSPのリクエスト処理メソッド

定義ファイル

サーブレット属性ファイル

パラメタ名

<method-observation-timeout>

9

Enterprise Beanのリクエスト処理メソッド

定義ファイル

Session Bean属性ファイル，Entity Bean属性ファイルまたはMessage-driven Bean属性ファイル

パラメタ名

<ejb-method-observation-timeout>

6および9

タイムアウト発生時のアプリケーション単位の動作

定義ファイル

アプリケーション属性ファイル

パラメタ名

<method-observation-recovery-mode>

8.7　Webアプリケーションの動作を最適化する

この節では，Webアプリケーションのパフォーマンスチューニングの方法について説明します。Webフロントシステムの場合に検討してください。

ここでは，次の3種類のチューニング方法について説明します。

静的コンテンツとWebアプリケーションの配置を切り分ける

静的コンテンツをキャッシュする

8.7.1　静的コンテンツとWebアプリケーションの配置を切り分ける

HTMLファイルや画像ファイルなど，クライアントからの要求に対する応答に使用するファイルのうち，リクエスト内容に影響されないで常に同じ内容になるコンテンツを，静的コンテンツといいます。一方，サーブレットやJSPのように，クライアントからの要求に応じて動的に生成されるコンテンツを動的コンテンツといいます。

ここでは，静的コンテンツを動的コンテンツであるWebアプリケーションと切り分けて配置することで，パフォーマンスの向上を図る方法について説明します。

なお，それぞれの設定例では，Webブラウザに，次の図に示すようなフレームやインラインイメージで構成されるHTMLページを表示する場合の例を基に説明します。

図8‒16　静的コンテンツと動的コンテンツで構成されるHTMLページの例

この構成の場合，次のファイルは動的に生成されない静的コンテンツです。

スタイルシート（CSSファイルなど）

インラインイメージ（画像ファイル）

フレームなどを定義したHTMLファイル

静的コンテンツをWebアプリケーションに組み込んで扱うと，Webコンテナで処理する必要がない静的コンテンツをやり取りする場合でもWebサーバとWebコンテナ間で常にアクセスが発生します。特に画像ファイルなどの場合は，データサイズが大きいため，処理時間が掛かります。

静的コンテンツはWebアプリケーションと分離して，Webサーバ上に配置することをお勧めします。これによって，ネットワークアクセスの回数およびやり取りするデータのサイズを減らし，パフォーマンスの向上が図れます。静的コンテンツとWebアプリケーションの処理のイメージを次の図に示します。

図8‒17　静的コンテンツとWebアプリケーションの処理のイメージ

Webアプリケーションと分離した静的コンテンツの配置方法について説明します。なお，ここでは，「図8-16　静的コンテンツと動的コンテンツで構成されるHTMLページの例」で示した構成のHTMLページを例として説明します。

「図8-16　静的コンテンツと動的コンテンツで構成されるHTMLページの例」の場合，次のような静的コンテンツをWebサーバに配置することで，パフォーマンスの向上が図れます。

Webサーバに配置するコンテンツ

スタイルシート（CSSファイルなど）

インラインイメージ（画像ファイル）

フレームなどを定義したHTMLファイル

配置の例を次の図に示します。

図8‒18　静的コンテンツをWebサーバに配置する例（Webサーバ連携の場合）

このマッピングをするためには，マッピング定義を次のように記述します。詳細は，マニュアル「HTTP Server」の「6.2.6(17)　ProxyPass」ディレクティブを参照してください。

リバースプロキシの定義

ProxyPass /APP/    http://myj2eeserver/APP/

注意事項

Webサーバ連携の場合，Webサーバには，Webアプリケーションのファイルをすべて配置するのではなく，クライアントから直接アクセスされる静的コンテンツだけを配置するようにしてください。

リバースプロキシでは，リクエストの拡張子やパス情報を正しく読み取ることができない場合に，動的コンテンツに対するリクエストを誤って静的コンテンツに対するリクエストと判断することがあります。この場合，リバースプロキシはJ2EEサーバに処理を振り分けないで，Webサーバ上のコンテンツをそのままクライアントに送信してしまいます。Webサーバ上にサーブレットやJSPなどの動的コンテンツを配置している場合に，動的コンテンツに対するリクエストが静的コンテンツへのリクエストとして扱われてしまうと，クラスファイルの実体やJSPなどのコンテンツのソースがレスポンスとしてリクエスト元のクライアントに送信されてしまうおそれがあります。

8.7.2　静的コンテンツをキャッシュする

Webコンテナでは，静的コンテンツをメモリに保持（キャッシュ）できます。一度アクセスした静的コンテンツの内容をメモリに保持しておくことによって，2回目以降のアクセス時のファイルシステムへのアクセス回数を減らし，応答速度の向上を図れます。

ここでは，静的コンテンツをキャッシュする場合に必要なチューニングの方法について説明します。

チューニングできるのは，次の項目です。

静的コンテンツをキャッシュするかどうかの選択

静的コンテンツのキャッシュに使用するメモリサイズの上限値

キャッシュする静的コンテンツのファイルサイズの上限値

それぞれについて説明します。なお，これらの項目は，Webコンテナ単位およびWebアプリケーション単位で設定できます。Webアプリケーション単位の設定は，Webコンテナ単位の設定よりも優先されます。このため，J2EEサーバ全体としてデフォルトの値を指定したい場合はWebコンテナ単位の値に設定して，細かな設定をしたい場合は適宜Webアプリケーション単位に設定してください。

ポイント

メモリサイズの見積もりとの関係

静的コンテンツのキャッシュでは，メモリを使用して応答速度の向上を図ります。このため，この機能を使用する場合は，サーバで使用できるメモリ量に応じてチューニングする必要があります。

静的コンテンツのキャッシュで使用するメモリサイズは，Webアプリケーション単位に設定します。Webアプリケーション単位に設定したメモリサイズの合計値が，J2EEサーバ全体で静的コンテンツのキャッシュのために使用するメモリサイズの最大値になります。このため，この機能を使用する場合は，J2EEサーバで必要なメモリサイズを見積もる際に，Webアプリケーション単位に設定したメモリサイズの合計値を加算してください。

(1)　静的コンテンツをキャッシュするかどうかの選択

静的コンテンツのキャッシュは，デフォルトの設定では使用されない機能です。このため，使用する場合はパラメタを変更する必要があります。

なお，静的コンテンツのキャッシュの使用は，Webコンテナ単位およびWebアプリケーション単位で設定でき，Webアプリケーション単位の設定は，Webコンテナ単位の設定よりも優先されます。ただし，Webコンテナ単位の設定で強制的な無効を選択している場合は，Webアプリケーション単位の設定も無効になります。強制的な無効は，次のような場合に使用できます。

静的コンテンツのキャッシュを有効にしたときと無効にしたときのメモリ使用量の差を検証したい場合

Webアプリケーション単位の設定を保持した状態で静的コンテンツのキャッシュを一時的に無効にしたい場合

(2)　静的コンテンツのキャッシュに使用するメモリサイズの上限値

静的コンテンツをキャッシュするために，Webアプリケーション単位で使用するメモリサイズを設定できます。なお，それぞれのWebアプリケーションで設定した値よりもキャッシュの合計サイズが大きくなる場合は，アクセスされていない時間が最も長いキャッシュから削除されます。削除は，キャッシュの合計サイズが設定値以下になるまで繰り返されます。

メモリサイズの設定の指針を次に示します。

メモリサイズの設定の指針

Webアプリケーション内に含まれる静的コンテンツのサイズの合計値以下の値を設定します。

Webアプリケーションの内容によって最適な値は異なります。このため，値を設定してから静的コンテンツに対するリクエストの応答速度を測定して，高い効果が出る最適なキャッシュのサイズを見つける必要があります。

(3)　キャッシュする静的コンテンツのファイルサイズの上限値

静的コンテンツのキャッシュの対象とするコンテンツのファイルサイズの上限を設定できます。上限を設定した場合，上限を超えるファイルサイズのコンテンツについてはキャッシュされないで，使用するたびに毎回ファイルシステムから取得されます。

ファイルサイズの設定の指針を次に示します。

ファイルサイズの設定の指針

Webアプリケーション内に含まれる静的コンテンツ中の，ファイルサイズが最大であるコンテンツのファイルサイズ以下の値を設定します。

大きなサイズの静的コンテンツがキャッシュされることによって，アクセス頻度の高いほかの静的コンテンツのキャッシュが破棄されないように留意して，値を設定します。

(4)　静的コンテンツの稼働状況の確認

静的コンテンツの稼働状況は，Webアプリケーションを停止したときに出力されるメッセージKDJE39234-Iの出力内容で確認できます。キャッシュされている静的コンテンツの合計サイズやコンテンツの個数などが出力されるので，必要に応じて各パラメタをチューニングしてください。

8.7.3　Webアプリケーションの動作を最適化するためのチューニングパラメタ

ここでは，Webアプリケーションの動作を最適化するために使用するチューニングパラメタの設定方法についてまとめて示します。

(1)　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

静的コンテンツとWebアプリケーションの配置の切り分けは，Webサーバの動作を定義するファイルのパラメタとして指定します。設定個所，ファイルおよびパラメタは，使用するWebサーバの種類によって異なります。

設定方法および設定個所を次に示します。

表8‒39　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

設定方法

設定個所

Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理Webサーバ（web-server)

パラメタ名

manager.web.reverseproxy.mapping

(2)　静的コンテンツをキャッシュするためのチューニングパラメタ

静的コンテンツをキャッシュするためのチューニングパラメタについて説明します。これらのチューニングパラメタは，Webコンテナ単位またはWebアプリケーション単位に設定します。

Webコンテナ単位に設定するチューニングパラメタの設定方法について，次の表に示します。これらの項目は，Smart Composer機能で設定します。

表8‒40　静的コンテンツをキャッシュするためのチューニングパラメタ（Webコンテナ単位で設定する項目）

設定項目

設定個所

静的コンテンツのキャッシュを使用するかどうかの選択

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.static_content.cache.enabled

Webアプリケーション単位のメモリサイズの上限値の設定

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.static_content.cache.size

キャッシュする静的コンテンツのファイルサイズの上限値の設定

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.static_content.cache.filesize.threshold

Webアプリケーション単位に設定するチューニングパラメタについて示します。Webアプリケーション単位に設定する項目は，web.xmlを直接編集するか，サーバ管理コマンドを使用して設定します。デプロイ前のWebアプリケーションに設定する場合は，web.xmlを編集してください。デプロイ後のWebアプリケーションに設定する場合は，サーバ管理コマンド（cjsetappprop）を使用してください。

設定内容を次の表に示します。

表8‒41　静的コンテンツをキャッシュするためのチューニングパラメタ（Webアプリケーション単位で設定する項目）

設定項目

設定内容※

静的コンテンツのキャッシュを使用するかどうかの選択

<param-name>タグ

com.hitachi.software.web.static_content.cache.enabled

<param-value>タグ

（設定値）

Webアプリケーション単位のメモリサイズの上限値の設定

<param-name>タグ

com.hitachi.software.web.static_content.cache.size

<param-value>タグ

（設定値）

キャッシュする静的コンテンツのファイルサイズの上限値の設定

<param-name>タグ

com.hitachi.software.web.static_content.cache.filesize.threshold

<param-value>タグ

（設定値）

注

（設定値）に設定できる値の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.19.2　DDでの定義（Webアプリケーション単位での設定）」を参照してください。

注※

web.xmlを直接編集する場合，<web-app>タグ内に<context-param>タグを追加して，<context-param>タグ内に<param-name>タグおよび<param-value>タグを追加します。

サーバ管理コマンドを使用する場合，WAR属性ファイルの<hitachi-war-property>タグ内に<context-param>タグを追加して，<context-param>タグ内に<param-name>タグおよび<param-value>タグを追加します。

8.8　CTMの動作を最適化する

CTMを使用したシステムのパフォーマンスチューニングの方法について説明します。CTMを使用したバックシステムの場合に検討してください。

ここでは，次の4種類のチューニング方法について説明します。

CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔をチューニングする

負荷状況監視間隔をチューニングする

CTMデーモンのタイムアウト閉塞を設定する

CTMで振り分けるリクエストの優先順位を設定する

8.8.1　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔をチューニングする

システムに存在する複数のCTMドメインマネジャ間，およびCTMドメイン内の複数のCTMデーモン間では，お互いの稼働状態を監視するために，定期的に通信処理が実行されています。

ここでは，それぞれの通信処理間隔をチューニングする場合の考え方について説明します。

(1)　CTMドメインマネジャ間で稼働状態を監視する間隔のチューニング

CTMドメインマネジャ間では，お互いのホストにあるCTMデーモンの情報を定期的に交換しています。この情報を基に，自ホストで受け付けたリクエストを適宜ほかのホストのCTMデーモンに振り分けています。

情報を交換するタイミングでは，お互いが稼働状態であるかどうかも同時に確認します。相手のホストのCTMドメインマネジャが停止している場合は，そのホストにはリクエストを振り分けないようにします。CTMドメインマネジャでは，情報を交換する間隔に一定の係数を掛けた時間以上応答がない場合に，相手のCTMドメインマネジャが停止していると判断します。

情報を交換する間隔の設定個所は，相手のCTMドメインマネジャが同じネットワークセグメント内にあるか，異なるネットワークセグメントにあるかによって異なります。稼働状態を判断するときに使用する係数のデフォルトは2です。例えば，同じネットワークセグメント内にあるCTMドメインマネジャの稼働情報を確認する場合，Management Serverを使用して構築したシステムでは，CTMドメイン構成情報の送信間隔に2を掛けた時間以上応答がない場合は，停止していると判断します。CTMドメイン構成情報の送信間隔が60秒の場合は，120秒間応答がない場合に，停止していると判断します。

この係数を変更することによって，通信処理の最適化が図れます。

係数に指定する値は，通信によって発生する処理の負荷を考慮して，適切な値を検討してください。基準になる送信間隔も必要に応じて検討してください。係数を小さくすると，間隔が短くなり，相手のCTMドメインマネジャが停止したことがすぐに検知できます。これによって，CTMデーモンが停止しているホストにリクエストを送信してしまうことを防げます。ただし，間隔が短過ぎると，通信処理が多く発生し，通信負荷が掛かります。

(2)　CTMデーモン間で稼働状態を監視する間隔のチューニング

CTMデーモン間では，CTMドメインマネジャ間でやり取りした情報を基に，相互にリクエストの振り分け処理をしています。

リクエストの振り分け先のCTMデーモンから一定時間応答がない場合，振り分け元のCTMデーモンでは，相手のCTMデーモンが停止していると判断して，以降のリクエストを振り分けないようにします。

デフォルトの設定では，CTMデーモンは180秒間応答を待ちます。180秒以上応答がない場合，相手のCTMデーモンが停止していると判断します。この値を変更することで，不要な処理待ち時間を短縮できます。

値は，リクエストとして送信するデータの大きさなど考慮して，適切な値を設定してください。間隔を短くすることで，相手のホストのトラブルを迅速に検知できるため，トラブルの影響が少ない状態でシステムから切り離すことができるようになります。ただし，間隔が短過ぎると，大きなサイズのデータを転送している間にタイムアウトが発生してしまうおそれがあります。

8.8.2　負荷状況監視間隔をチューニングする

CTMドメイン内の複数のCTMデーモン間では，それぞれのスケジュールキューの負荷情報を監視しています。監視結果は，CTMデーモン間のリクエスト振り分け時に利用されます。

負荷状況監視間隔は，チューニングできます。なお，デフォルトの状態では10秒です。

負荷状況監視間隔を短くすることで，その時点の状況に応じた振り分けができるようになります。ただし，短くし過ぎると，通信が多発して，負荷が高くなります。

なお，負荷状況監視間隔に0を設定した場合は，J2EEサーバ起動時の負荷状況を一度だけ収集して，その値を使用し続けます。

8.8.3　CTMデーモンのタイムアウト閉塞を設定する

CTMデーモンに対応するJ2EEサーバにトラブルが発生した場合，CTMデーモンが送信したリクエストでタイムアウトが発生します。そのままの状態で運用を続けると，CTMデーモンはトラブルが発生したJ2EEサーバに対してリクエストを送信し続けるため，そのつどリクエストでタイムアウトが発生してしまいます。

これに対処するために，CTMデーモンには，タイムアウト閉塞を設定できます。タイムアウト閉塞とは，一定時間内に規定回数以上のリクエストのタイムアウトが発生した場合に，CTMデーモンのスケジュールキューを閉塞する機能です。これによって，トラブルが発生したCTMデーモンでそれ以上リクエストを受け付けなくなり，ほかのCTMデーモンが受け付けるようになります。リクエストは正常に稼働しているJ2EEサーバに振り分けられるようになります。

8.8.4　CTMで振り分けるリクエストの優先順位を設定する

CTMで制御するリクエストには，優先順位が付けられます。すぐに実行する必要があるリクエストに高い優先順位を設定しておくことで，スケジュールキューの中で滞留することなく，迅速な処理ができるようになります。

リクエストの優先順位は，CTMにリクエストを送信する，EJBクライアントアプリケーションまたはJ2EEサーバに対して設定できます。優先順位を高く設定したEJBクライアントアプリケーションまたはJ2EEサーバから送信されたリクエストは，スケジュールキューに格納されているほかのクライアントからのリクエストよりも優先されて処理されます。

8.8.5　CTMの動作を最適化するチューニングパラメタ

ここでは，CTMの動作の最適化で使用するチューニングパラメタの設定方法についてまとめて示します。

(1)　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔を設定するチューニングパラメタ

CTMドメインマネジャの稼働状態の監視間隔をチューニングするパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

なお，監視間隔は，送信間隔×係数の値になります。

表8‒42　CTMドメインマネジャの稼働状態の監視間隔をチューニングするパラメタ

対象

設定項目

設定対象

設定個所（パラメタ名）

同じネットワークセグメント内にあるCTMドメインマネジャ

送信間隔

論理CTMドメインマネジャ（ctm-domain-manager）

cdm.SendInterval

係数

論理CTMドメインマネジャ（ctm-domain-manager）

cdm.AliveCheckCount

異なるネットワークセグメントにあるCTMドメインマネジャ

送信間隔

論理CTMドメインマネジャ（ctm-domain-manager）

cdm.SendHostInterval

係数

論理CTMドメインマネジャ（ctm-domain-manager）

cdm.AliveCheckCount

CTMデーモンの稼働状態の監視間隔をチューニングするパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒43　CTMデーモンの稼働状態の監視間隔をチューニングするパラメタ

設定項目

設定対象

設定個所（パラメタ名）

CTMデーモン間転送時のタイムアウト

論理CTM

ctm.DCSendTimeOut

(2)　負荷状況監視間隔を設定するチューニングパラメタ

負荷状況監視間隔をチューニングするパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒44　負荷情報監視間隔をチューニングするパラメタ

設定項目

設定対象

設定個所（パラメタ名）

CTMデーモン間転送時のタイムアウト

論理CTM

ctm.LoadCheckInterval

(3)　CTMデーモンのタイムアウト閉塞を設定するチューニングパラメタ

タイムアウト閉塞は，タイムアウト発生回数と監視間隔を設定しておくことによって，実行されます。

CTMデーモンのタイムアウト閉塞をチューニングするパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表8‒45　CTMデーモンのタイムアウト閉塞をチューニングするパラメタ

設定項目

設定対象

設定個所（パラメタ名）

タイムアウト発生回数

論理CTM

ctm.RequestCount

監視時間間隔

論理CTM

ctm.RequestInterval

(4)　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ

CTMで振り分けるリクエストの優先順位の設定は，EJBクライアントアプリケーションの場合と，J2EEサーバの場合で異なります。また，J2EEサーバの場合，システムの構築方法によって設定個所が異なります。CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタを次の表に示します。

表8‒46　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ

設定単位

設定方法

設定個所

EJBクライアントアプリケーション

ファイル編集またはEJBクライアントアプリケーション開始時に指定するシステムプロパティの指定

定義ファイル（ファイル編集の場合）

usrconf.properties

パラメタ名

ejbserver.client.ctm.RequestPriorityキー

J2EEサーバ

Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.client.ctm.RequestPriority

9　パフォーマンスチューニング（バッチアプリケーション実行基盤）

この章では，バッチアプリケーションを実行するシステムのパフォーマンスをチューニングする方法について説明します。

パフォーマンスチューニングによって動作環境を最適化することで，システムの性能を最大限に生かせるようになります。

J2EEアプリケーション実行基盤のパフォーマンスチューニングについて検討する場合は，「8.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）」を参照してください。

9.1　パフォーマンスチューニングで考慮すること

この節では，バッチアプリケーション実行基盤のパフォーマンスチューニングで考慮することについて説明します。

9.1.1　パフォーマンスチューニングの観点

バッチアプリケーション実行基盤のパフォーマンスチューニングは，次の観点で実施します。

データベースアクセス方法の最適化

タイムアウトの設定

フルガーベージコレクションを発生させるメモリ使用量のしきい値の設定

それぞれのポイントについて説明します。

(1)　データベースアクセス方法の最適化

データベースアクセス方法の最適化は，生成に時間が掛かるコネクションやステートメントをプールしておくことで，データベースアクセス時のオーバーヘッドを削減することを目的とします。

パフォーマンスチューニングでは，次に示す機能を有効に活用することで，データベースアクセス処理を最適化し，スループットを向上させます。

コネクションプーリング

ステートメントプーリング（PreparedStatementおよびCallableStatementのプーリング）

データベースアクセス方法は，データベースとの接続にDB Connectorを使用している場合に最適化できます。

(2)　タイムアウトの設定

タイムアウトの設定は，システムのトラブル発生を検知して，リクエストの応答が返らなくなることを防ぎ，適宜リソースを解放することを目的とします。

設定できるタイムアウトには，次の種類があります。

Enterprise Beanを呼び出す時のタイムアウト

トランザクションのタイムアウト

データベースのタイムアウト

(3)　フルガーベージコレクションを発生させるメモリ使用量のしきい値の設定

フルガーベージコレクションの制御で使用するしきい値は，オンライン処理とバッチ処理で同じリソースを使用する場合に設定します。バッチサーバのフルガーベージコレクションによってオンライン処理を中断させないことを目的とします。

フルガーベージコレクションの実行を制御することによって，リソースを排他していないタイミングで適切にフルガーベージコレクションを実行できます。

9.1.2　チューニング手順

パフォーマンスチューニングは，システムのパフォーマンスを生かす最適な設定を見つける作業です。構築した環境で，実際に処理を実行しながら，パラメタの調整やボトルネックの調査，解消によってパフォーマンスを向上させていきます。

チューニング作業では，まず，目標値を決定します。次に，各パラメタに初期値を設定した状態でスループットを測定します。各パラメタを調整しながら，目標値に近い最適な値を見つけていきます。

チューニングの際，CPUの利用率の測定には，OSに付属している監視ツールなどが利用できます。JavaVMに関するアプリケーションサーバの稼働情報については，稼働情報収集機能などで確認できます。確認方法については，マニュアル「アプリケーションサーバ機能解説 運用／監視／連携編」の「3.　稼働情報の監視（稼働情報収集機能）」を参照してください。

なお，CPU利用率が100%からかなり低い状態で飽和した場合は，システム上に入出力処理や排他処理などのボトルネックがあるおそれがあります。ボトルネックを調査し，対策してから，再度パフォーマンスチューニングを実行してください。アプリケーションサーバでは，システムのボトルネックの調査に，性能解析トレースを利用できます。性能解析トレースの機能詳細，および性能解析トレースを利用して取得したトレースファイルの利用方法については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」を参照してください。

9.1.3　チューニング項目

バッチアプリケーション実行基盤でのチューニング項目について，次の表に示します。

表9‒1　バッチアプリケーション実行基盤でのチューニング項目

チューニング項目

利用できる機能

参照先

データベースアクセス方法の最適化

コネクションプーリング※1

8.5.1※2

ステートメントプーリング※1

8.5.2※2

タイムアウトの設定

Enterprise Bean呼び出しでのタイムアウトの設定

8.6.3※2 ，※3

トランザクションタイムアウトの設定

9.3.2

データベースでのタイムアウトの設定

8.6.6※2

フルガーベージコレクションの制御※1

しきい値の設定

9.4

注※1

DB Connectorを使用している場合に利用できる機能です。

注※2

J2EEアプリケーション実行基盤の説明を参照してください。その際，説明中の「J2EEサーバ」を「バッチサーバ」に読み替えてください。また，「J2EEアプリケーション」を「バッチアプリケーション」に読み替えてください。

注※3

Enterprise Bean呼び出しでは，J2EEアプリケーション実行基盤のバックシステムと同じ項目にタイムアウトを設定できます。

9.2　チューニングの方法

この節では，チューニングの方法について説明します。チューニングの方法は，設定対象の種類によって異なります。

9.2.1　バッチサーバのチューニング

バッチサーバのチューニングには，Smart Composer機能の簡易構築定義ファイルを使用します。簡易構築定義ファイルでは，<configuration>タグ下の<logical-server-type>に設定対象とする論理サーバの種類（J2EEサーバ※）を指定して，<param>タグ下でパラメタ名とその値を設定します。簡易構築定義ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

注※

Smart Composer機能では，バッチサーバをJ2EEサーバとして扱います。

9.2.2　リソースのチューニング

リソースのチューニングをする場合は，サーバ管理コマンドを使用します。

サーバ管理コマンドを使用する場合は，Connector属性ファイルを編集します。Connector属性ファイルの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

9.3　タイムアウトを設定する

アプリケーションサーバのシステムでは，トラブル発生時にリクエストの応答が戻ってこない状態になることを防ぐために，幾つかのポイントにタイムアウトを設定できます。

この節では，システム全体でタイムアウトが設定できるポイントと，設定する場合の指針について説明します。

9.3.1　タイムアウトが設定できるポイント

バッチアプリケーションを実行するシステムでは，次の図に示すポイントにタイムアウトが設定できます。

図9‒1　タイムアウトが設定できるポイント

それぞれのポイントに設定するタイムアウトは，次の表に示すような用途で使い分けられます。

表9‒2　各ポイントに設定するタイムアウトの目的とデフォルトのタイムアウト設定

ポイント

タイムアウトの種類

主な用途

1

バッチサーバ側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIネーミングサービス呼び出しのタイムアウト

バッチサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

2※

バッチサーバ側で設定するCTMからのEnterprise Bean呼び出しのタイムアウト

バッチサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

3

Enterprise Bean呼び出しアクセスしたEJBで設定するメソッドの実行時間のタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど）

4

バッチサーバ側で設定するデータベースのトランザクションタイムアウト

データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止

5

データベースのタイムアウト

データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止

注※　CTMを使用している場合にだけ存在するポイントです。CTMを利用しない構成の場合，ポイント2の範囲はバッチサーバからEJBコンテナにEJBリモート呼び出しを実行してから，EJBコンテナからバッチサーバに実行結果が送信されるまでの間になります。

これらのタイムアウトの基本的な設定指針は次のとおりです。

タイムアウト値の設定は，呼び出し元（バッチサーバ）に近いほど大きな値を設定するのが原則です。このため，次の関係で設定することを推奨します。

ポイント1=ポイント2>ポイント3>ポイント4>ポイント5

1，4，5のポイントのタイムアウト値を設定する場合は，呼び出し処理に通常どの程度の時間が掛かっているかを見極めた上で，呼び出す処理（業務）ごとに算出して設定してください。

なお，1〜5のポイントは，システムでの位置づけによって，次の二つに分けられます。

Enterprise Bean呼び出しで意識する必要があるポイント（1〜3）

このポイントでタイムアウトを設定する項目は，J2EEアプリケーション実行基盤のバックシステムで設定できる項目と同じです。詳細は，「8.6.3　バックシステムでのタイムアウトを設定する」を参照してください。

データベース接続時に意識する必要があるポイント（4と5）

このポイントは，さらにトランザクションでのタイムアウトとデータベースでのタイムアウトに分けて意識する必要があります。

トランザクションでのタイムアウトの詳細は，「9.3.2　トランザクションタイムアウトを設定する」を参照してください。

データベースでのタイムアウトを設定する項目は，J2EEアプリケーション実行基盤のバックシステムで設定できる項目と同じです。詳細は，「8.6.6　データベースでのタイムアウトを設定する」を参照してください。

それぞれのポイントでの設定については，バッチアプリケーション実行基盤の「9.3.3　タイムアウトを設定するチューニングパラメタ」，およびJ2EEアプリケーション実行基盤の「8.6.8　タイムアウトを設定するチューニングパラメタ」を参照してください。

参考

それぞれのポイントのデフォルト値は次のとおりです。

ポイント

デフォルト値

1

設定されていません。レスポンスを待ち続けます。

2

ポイント1と同じ値がEnterprise Bean呼び出し時に自動的に引き継がれて設定されます。

3

設定されていません。タイムアウトしません。

4

180秒

5

データベースの種類とタイムアウトの設定個所ごとに異なります。※

HiRDBの場合

ロック解放待ちタイムアウト：180秒

レスポンスタイムアウト：0秒（HiRDBクライアントはHiRDBサーバからの応答があるまで待ち続けます）

リクエスト間隔タイムアウト：600秒

SQL Serverの場合

メモリ取得待ちタイムアウト：-1（-1を指定した場合の動作は，SQL Serverのドキュメントを参照してください）

ロック解放待ちタイムアウト：-1（ロックが解放されるまで待ち続けます）

XDM/RD E2の場合

ロック解放待ちタイムアウト：なし（タイムアウト時間を監視しません）

SQL実行CPU時間タイムアウト：10秒

SQL実行経過時間タイムアウト：0秒（タイムアウト時間を監視しません）

トランザクション経過時間タイムアウト：600秒

レスポンスタイムアウト：0秒（HiRDBクライアントはXDM/RD E2サーバからの応答があるまで待ち続けます）

注※

Oracleの場合，ロック解放待ちタイムアウトのデフォルトはありません。

9.3.2　トランザクションタイムアウトを設定する

ここでは，トランザクションタイムアウトの設定について説明します。トランザクションタイムアウトは，データベースシステムなどEISとのトランザクションに設定します。DB Connectorを使用してデータベースにアクセスするときのトランザクションタイムアウトについて説明します。

トランザクションタイムアウトを設定する場合は，システム全体のタイムアウトのうち，バッチサーバとデータベースのトランザクションについて意識する必要があります。

トランザクションタイムアウトが発生すると，アプリケーションサーバによって，次の処理が実行されます。

実行中のトランザクションはロールバックされます。

トランザクションに参加しているコネクションはクローズされ，コネクションプールから削除されます。

ポイント

トランザクションの管理方法はBMTになります。トランザクションのタイムアウトは，usrconf.propertiesまたはJTAのAPI（javax.transaction.UserTransaction#setTransactionTimeoutメソッド）に指定できます。

usrconf.propertiesの定義は，プロセス全体に影響します。APIに指定したタイムアウトは，APIを発行したトランザクションの範囲だけに影響します。また，APIの指定は，usrconf.propertiesの定義よりも優先されます。

このため，プロセス全体に設定したい標準的な値をusrconf.propertiesに定義して，呼び出す業務によって細かく設定したい値は適宜APIを使用して設定することをお勧めします。

トランザクションタイムアウトが発生した場合，バッチアプリケーションに例外は通知されません。ただし，メッセージKDJE31002-Wがログファイルとバッチサーバのコンソールに出力されます。また，トランザクションタイムアウトが発生したあとで，バッチアプリケーションから該当するトランザクションを使用してJTAインタフェースまたはJDBCインタフェースを使用しようとすると，例外が通知されます。

9.3.3　タイムアウトを設定するチューニングパラメタ

ここでは，タイムアウトの設定で使用するチューニングパラメタの設定方法についてまとめて示します。

(1)　バッチサーバ側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト

「図9-1　タイムアウトが設定できるポイント」のポイント1のタイムアウトを設定するチューニングパラメタです。

設定方法は，J2EEアプリケーション実行基盤と同じです。「8.6.8(6)　EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト」を参照してください。

なお，「8.6.8　タイムアウトを設定するチューニングパラメタ」の説明中の「ポイント7」が，「図9-1　タイムアウトが設定できるポイント」の「ポイント1」に対応します。

(2)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト

「図9-1　タイムアウトが設定できるポイント」のポイント2のタイムアウトを設定するチューニングパラメタです。

設定方法は，J2EEアプリケーション実行基盤と同じです。「8.6.8(7)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト」を参照してください。

なお，「8.6.8　タイムアウトを設定するチューニングパラメタ」の説明中の「ポイント8」が，「図9-1　タイムアウトが設定できるポイント」の「ポイント2」に対応します。

(3)　Enterprise Bean呼び出しアクセスしたEJBで設定するメソッドの実行時間のタイムアウト

「図9-1　タイムアウトが設定できるポイント」のポイント3のタイムアウトを設定するチューニングパラメタです。

設定方法は，J2EEアプリケーション実行基盤と同じです。「8.6.8(11)　J2EEアプリケーションのメソッドタイムアウト」を参照してください。

なお，「8.6.8　タイムアウトを設定するチューニングパラメタ」の説明中の「ポイント9」が，「図9-1　タイムアウトが設定できるポイント」の「ポイント3」に対応します。

(4)　バッチサーバ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合）

「図9-1　タイムアウトが設定できるポイント」のポイント4のタイムアウトを設定するチューニングパラメタです。

バッチサーバ単位，Enterprise Bean，インタフェース，APIによる呼び出し単位（BMTの場合）に設定します。

トランザクションタイムアウトのチューニングパラメタを次の表に示します。

表9‒3　トランザクションタイムアウトのチューニングパラメタ

単位

設定方法

設定項目

設定個所

バッチサーバ単位

Smart Composer機能

トランザクションのトランザクションタイムアウト時間のデフォルト

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.jta.TransactionManager.defaultTimeOut

API単位（BMT）

API

トランザクションタイムアウト時間

UserTransaction#setTransactionTimeoutメソッド※

注※　パッケージ名はjavax.transactionです。

(5)　データベースのタイムアウト

「図9-1　タイムアウトが設定できるポイント」のポイント5のタイムアウトを設定するチューニングパラメタです。

設定方法は，J2EEアプリケーション実行基盤と同じです。「8.6.8(10)　データベースのタイムアウト」を参照してください。

なお，「8.6.8　タイムアウトを設定するチューニングパラメタ」の説明中の「ポイント12」が，「図9-1　タイムアウトが設定できるポイント」の「ポイント5」に対応します。

9.4　GC制御で使用するしきい値を設定する

バッチサーバのFullGCを実行するタイミングは，メモリ使用量にしきい値を設定することで制御できます。しきい値は，バッチ処理とオンライン処理で同じリソースにアクセスする場合に設定することをお勧めします。適切なしきい値を設定しておくことで，オンライン処理とバッチ処理の両方のスループットを確保できます。

ポイント

FullGCの詳細については，「7.2.7　GCの発生とメモリ空間の関係」を参照してください。

9.4.1　しきい値を設定する目的

オンライン処理とバッチ処理で同じリソースにアクセスする場合，オンライン処理のスループットに影響を与えないように考慮する必要があります。

バッチアプリケーション実行時に空きメモリが少なくなると，JavaVMによってバッチサーバのFullGCが実行されます。この場合，バッチサーバ上で動作するすべてのプログラムの処理が中断されます。バッチアプリケーションがリソースを排他していた場合，そのリソースはバッチサーバのFullGC実行中も排他された状態になります。オンライン処理の中に排他中のリソースを使用する処理があった場合は，そのオンライン処理も中断されてしまいます。

これを防ぐために，メモリ使用量のしきい値を設定して，メモリ不足が起こる前に明示的にFullGCを発生させるようにします。明示的なFullGCは，リソースを排他していないタイミングで発生するように制御できます。JavaVMによってFullGCが実行される前に空きメモリを増やしておくことで，リソース排他中にFullGCが実行されることを防ぎます。

しきい値を設定した場合，次に示す状態になるとFullGCが実行されます。ただし，そのときにバッチアプリケーションがリソースを排他していた場合は，排他が解除されるまで待ってから実行されます。

SerialGCが有効な場合

Tenured領域消費サイズのTenured領域合計サイズに対する割合≧しきい値

New領域合計サイズのTenured領域最大空きサイズに対する割合≧しきい値

Metaspace領域消費サイズのMetaspace領域最大サイズに対する割合≧しきい値

G1GCが有効な場合

Javaヒープ領域消費サイズのJavaヒープ領域合計サイズに対する割合≧しきい値

Metaspace領域消費サイズのMetaspace領域最大サイズに対する割合≧しきい値

9.4.2　しきい値設定の考え方

しきい値は，次の式で算出した値を目安に算出できます。

しきい値≦100−（100×リソース排他解除を待つ間に必要な空きメモリのサイズ）／最大メモリサイズ

しきい値設定の際には，次の点を考慮してください。

FullGCの発生頻度

リソース排他解除を待つ間に必要な空きメモリ

ここでは，FullGCの発生頻度としきい値の関係と，リソース排他解除を待つ間に必要な空きメモリのサイズの見積もり方法について説明します。

(1)　FullGCの発生頻度としきい値の関係

FullGCはプログラムの実行速度に比べて時間の掛かる処理です。このため，JavaVMのチューニングでは，FullGCをできるだけ発生させないようにします。JavaVMのチューニングの考え方については，「7.3.1　チューニングの考え方」を参照してください。

しきい値を設定して明示的に実行するFullGCも，頻度が少なくなるよう，チューニングする必要があります。

設定したしきい値ごとのメモリ使用量の例を，次の図に示します。

図9‒2　設定したしきい値ごとのメモリ使用量の例

JavaVMでのメモリ使用量は，時間の経過とともに増加していき，FullGCが発生すると減少します。

しきい値に0を設定した場合は，JavaVMによって自動的に実行されるまでFullGCは実行されません。しきい値に小さな値を設定した場合は，大きな値を指定した場合に比べて，FullGCが実行される頻度が高くなります。図の場合は，しきい値として80を設定した場合の方が，50を設定した場合よりもFullGCの実行頻度を低く抑えることができています。

ただし，FullGCの実行頻度を少なくした場合，1回の実行に掛かる時間は，頻繁に実行する場合に比べて長くなります。

(2)　リソース排他解除を待つ間に必要な空きメモリの見積もり

メモリ使用量がしきい値以上になった場合，リソース排他が解除されるまでFullGCは実行されません。しかし，リソース排他の解除を待っている間にJavaVMが必要とするメモリが不足した場合は，リソース排他解除を待たないでJavaVMによってFullGCが実行されてしまいます。

リソース排他解除を待つ間に空きメモリが不足した場合の例を次の図に示します。

図9‒3　リソース排他解除を待つ間に空きメモリが不足した場合の例

ポイント

JavaVMにFullGCを実行させないために必要な空きメモリについては，「7.2.7　GCの発生とメモリ空間の関係」を参照してください。

FullGCが発生するメモリ使用量を100とする場合，リソース排他解除待ち区間に使用できるメモリサイズは，「100−しきい値（%）」です。

例えば，しきい値として「95」のように高い値を指定した場合は，リソース排他解除を待っている間に使用できる空きメモリが5%と少ないため，リソース排他が解除される前にJavaVMによって自動的にFullGCが実施されてしまうおそれがあります。

このため，しきい値を見積もる場合には，リソース排他待ち区間にメモリが不足しないよう，十分に余裕を持った値を設定するようにしてください。

注意事項

リソース排他解除待ち区間で空きメモリが不足してJavaVMによるFullGCが実行された場合，リソースの排他が解除されたタイミングで，FullGC制御によってもう一度FullGCが実行されます。

9.4.3　GC制御で使用するしきい値を設定するためのチューニングパラメタ

ここでは，バッチサーバのFullGCを実行するしきい値を設定するために使用するチューニングパラメタの設定方法について示します。

表9‒4　バッチサーバのFullGCを実行するしきい値を設定するチューニングパラメタ

設定項目

設定個所

しきい値

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.batch.gc.watch.threshold

付録

付録A　HTTPセッションで利用するExplicitヒープの効率的な利用

明示管理ヒープ機能を利用する場合，J2EEサーバのデフォルトでは，HTTPセッションに関するオブジェクトがExplicitヒープに配置されます。HTTPセッションを配置するExplicitメモリブロック領域の確保および解放のタイミングについては，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.4.1　HTTPセッションに関するオブジェクト」を参照してください。なお，オブジェクトの寿命の考え方や，どのようなExplicitメモリブロックが自動解放の対象となるかなどについては，「付録B　Explicitヒープに配置するオブジェクトの寿命による明示管理ヒープ機能への影響」を参照してください。

HTTPセッションに明示管理ヒープ機能を適用する場合は，次の観点を考慮してアプリケーションを実装すると，効率良く適用できます。

HTTPセッションに格納するオブジェクトの寿命

HTTPセッションに格納するオブジェクトの更新頻度

HTTPセッションを作成するタイミング

また，これらの観点を考慮した実装となっているかどうかは，J2EEサーバのログで確認できます。

ここでは，観点ごとに，アプリケーションの実装方法，およびJ2EEサーバのログによる確認方法について説明します。

付録A.1　HTTPセッションに格納するオブジェクトの寿命を考慮する

HTTPセッションに格納するオブジェクトの寿命を考慮したアプリケーションの実装方法，およびJ2EEサーバのログによる確認方法について説明します。

(1)　アプリケーション実装時の考慮点

HTTPセッションには，HTTPセッションが破棄されるときに解放されるオブジェクトだけを格納することをお勧めします。このようなオブジェクトの割合が多いと，自動解放処理の時間が短くなります。HTTPセッションが破棄されたあとも残存するオブジェクトがあると，新たなExplicitメモリブロックが生成され，オブジェクトはそこに移動され，以降の自動解放処理の対象となります。また，移動されたオブジェクトは，HTTPセッションと対応しないオブジェクトとなります。

明示管理ヒープ機能では，setAttributeメソッドでHTTPセッションに格納したオブジェクトから直接または間接的に参照されているオブジェクトは，HTTPセッションに格納されていると見なします。これらのオブジェクトは，昇格するタイミングでExplicitメモリブロックに移動します。HTTPセッションに格納したオブジェクトからの参照関係が複雑になると，HTTPセッションを破棄したあとも使用され続けるオブジェクトが，HTTPセッションに格納されてしまう可能性が高くなります。

このため，HTTPセッションに格納するオブジェクトは，String型のオブジェクトや，プリミティブ型またはプリミティブ型配列を格納した場合など，できるだけシンプルにするのをお勧めします。

アプリケーションの設計上，HTTPセッションが破棄したあとも使用され続けるオブジェクトをHTTPセッションに格納する必要がある場合は，明示管理ヒープ機能適用除外クラス指定機能の利用を検討してください。明示管理ヒープ機能適用除外クラス指定機能については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.10　Explicitメモリブロックの自動解放処理に掛かる時間の短縮」を参照してください。

(2)　J2EEサーバログによる確認方法

HTTPセッションに格納するオブジェクトの寿命は，スレッドダンプの内容から確認します。

確認手順を次に示します。

J2EEサーバを起動し，HTTPセッションが破棄されるまでの一とおりの業務を実行します。

HTTPセッションが破棄されたあと，eheapprofコマンドを実行してスレッドダンプを取得します。

<EM_NAME>が"NULL"のExplicitメモリブロックを検索します。

"NULL"のExplicitメモリブロックがない場合は，HTTPセッションが破棄されたあとも使用され続けるオブジェクトがないことを示します。

"NULL"のExplicitメモリブロックがある場合は，「used」（Explicitメモリブロックの利用済みサイズ）の値を確認します。

出力例を次に示します。

"NULL" eid=1(0x02f25610)/A, total 542K, used 501K, garbage 0K (92.4% used/total, 0.0% garbage/used, 0 blocks) Enable

このExplicitメモリブロックには，HTTPセッションが破棄されたあとも使用され続けるオブジェクトがあることを示します。ただし，「used」の値が数キロバイト〜数メガバイト程度の場合は，自動解放処理時間に大きな影響を与えることはありません。

(3)　HTTPセッションの破棄後にHTTPセッションに格納したオブジェクトが使用される仕組み

HTTPセッションが破棄したあともHTTPセッションに格納したオブジェクトが使用されてしまう仕組みを説明します。ここでは，代表的な例として，HTTPセッションに格納したオブジェクトから共有データ（オブジェクト）を参照する例を次の図に示します。

図A‒1　HTTPセッションに格納したオブジェクトから共有データ（オブジェクト）を参照する例

この例は，setAttributeメソッドでHTTPセッションに格納したオブジェクトから共有データであるオブジェクトAを参照している例です。オブジェクトAはHTTPセッションに格納されていないようにも見えますが，参照関係に基づくオブジェクトの移動によって，参照元のどれかのHTTPセッションに対応するExplicitメモリブロックに移動します。この例では，Explicitメモリブロック1に移動するとします。参照関係の基づくオブジェクトの移動については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動」を参照してください。

このあと，Explicitメモリブロック1に対応するHTTPセッションが破棄されて，自動解放処理が発生すると，外部（解放対象外のExplicitメモリブロック）から参照されているオブジェクトAは，新規のExplicitメモリブロックxに移動されます。このExplicitメモリブロックxはHTTPセッションと対応していないExplicitメモリブロックとなります。HTTPセッションを破棄したあとのExplicitメモリブロックの状態を次の図に示します。

図A‒2　HTTPセッションを破棄したあとのExplicitメモリブロックの状態

HTTPセッションの破棄と対応した自動解放は，対象となるExplicitメモリブロックに使用中のオブジェクトが多いほど，処理に時間が掛かります。また，HTTPセッションの破棄と対応した自動解放処理時に使用中のオブジェクトは，HTTPセッションとは対応しないExplicitメモリブロックに移動され，自動解放処理の対象となります。このオブジェクトを解放できない期間が長いほど，このオブジェクトが自動解放処理の対象となる回数が増え，スループットやレイテンシの悪化につながることがあります。

この例の場合，共有データであるオブジェクトAへの参照は，n個のHTTPセッションが一つもなくなるまで消えないと考えられます。その間は，新規のExplicitメモリブロックxの自動解放処理を繰り返すことになり，効率が悪くなります。共有データのサイズが小さければ，特に大きな影響はありませんが，数百メガバイト以上の巨大なサイズの場合は，自動解放処理時間への影響が大きく，スループットやレイテンシの悪化の原因となることがあります。

付録A.2　HTTPセッションに格納するオブジェクトの更新頻度を考慮する

HTTPセッションに格納するオブジェクトの更新頻度を考慮したアプリケーションの実装方法，およびJ2EEサーバのログによる確認方法について説明します。

(1)　アプリケーション実装時の考慮点

HTTPセッションに格納したオブジェクトの更新回数が少ないほど，Explicitメモリブロックのメモリ効率が良くなります。例えば，setAttributeメソッドを第1引数の「name」が同じ値で複数回呼び出すと，同じ値で呼び出した回数分だけ第2引数の「value」のオブジェクトが更新されます。これがオブジェクトの更新回数となります。

HTTPセッションに格納したオブジェクトが更新されると，更新前のオブジェクトは使用済みになりますが，そのメモリ領域はHTTPセッションの破棄まで解放されません。このため，更新回数が少ないほどメモリ効率は良くなります。オブジェクトの更新を，短い周期（CopyGC間隔の10倍程度以下の周期）で繰り返す場合は問題ありませんが，長い周期で繰り返すと長寿命オブジェクトとなってExplicitメモリブロックに移動するため，注意してください。Explicitメモリブロックに移動したオブジェクトは，使用済みとなっても，HTTPセッションの破棄まで解放されません。明示管理ヒープ機能を適用しない場合，このようなオブジェクトはフルガーベージコレクション発生時に解放されます。特に，日中はHTTPセッションが破棄されないといった，HTTPセッションの生存期間が長いシステムの場合は，長い周期でオブジェクトの更新を繰り返す状況となりやすいことがあります。

アプリケーションの設計上，HTTPセッションに格納したオブジェクトの更新回数が多くなる場合は，次の点を考慮して，明示管理ヒープ機能の適用可否を判断してください。

明示管理ヒープ機能を適用しない場合のフルガーベージコレクションによるレイテンシのスパイク

明示管理ヒープ機能を適用した場合のメモリ効率の悪化

(2)　J2EEサーバログによる確認方法

HTTPセッションに格納するオブジェクトの更新頻度は，スレッドダンプの内容から確認します。

確認手順を次に示します。

J2EEサーバを起動し，HTTPセッションが破棄される直前までの業務を実行します。

eheapprofコマンドを実行してスレッドダンプを取得します。

<EM_NAME>が"CCC#HttpSession"のExplicitメモリブロックを検索します。

"CCC#HttpSession"のExplicitメモリブロックは，HTTPセッションと対応するブロックです。「used」（Explicitメモリブロックの利用済みサイズ）の値と，アプリケーション開発時に算出して見積もったHTTPセッションに格納するオブジェクトの合計サイズを比較します。オブジェクトの更新頻度が高いと，二つの値に大きな差が生じ，「used」の値が大きくなります。

出力例を次に示します。

"CCC#HttpSession" eid=97(0x02f25610)/R, total 16K, used 8K, garbage 0K (50.1% used/total, 0.0% garbage/used, 0 blocks) Enable

(3)　Explicitメモリブロックに使用済みのHTTPセッションに関するオブジェクトが残存する仕組み

更新を繰り返した結果，使用済みのHTTPセッションに関するオブジェクトが，Explicitメモリブロックに残存してしまう仕組みを説明します。ここで説明するオブジェクトは，HTTPセッションの破棄よりも生存期間が短い長寿命オブジェクトです。

明示管理ヒープ機能が有効な場合と明示管理ヒープ機能が無効な場合のオブジェクトの解放処理の違いを次の図に示します。

図A‒3　明示管理ヒープ機能が有効な場合と明示管理ヒープ機能が無効な場合のオブジェクトの解放処理の違い

この図は，HTTPセッションが長時間破棄されない例です。時刻2では，オブジェクトの更新によって，4個のオブジェクトが使用済みとなります。時刻3では，明示管理ヒープ機能が無効な場合，Tenured領域のサイズがフルガーベージコレクションを発生するためのしきい値を超えたため，フルガーベージコレクション（図中のFullGC発生が該当します）が発生し，使用済みのオブジェクトは解放されます。明示管理ヒープ機能が有効な場合，フルガーベージコレクションが発生しないため，使用済みのオブジェクトは解放されないで残ります。さらに時間が経過した時刻nでも，HTTPセッションはまだ破棄されません。明示管理ヒープ機能が無効な場合，しきい値によるフルガーベージコレクションの発生でTenured領域の使用済みのオブジェクトは解放されます。明示管理ヒープ機能が有効な場合，HTTPセッションが破棄されるまで自動解放処理が発生しないため，使用済みで解放されていないオブジェクトが残り，Explicitヒープがあふれる可能性が高くなります。

この例の時刻nでは，使用済みで解放されていないオブジェクトは16個ですが，長時間（例えば，日中の間など）HTTPセッションを破棄しないことを要件とするシステムでは，さらに多くの使用済みのオブジェクトが解放されない状況になるおそれがあります。

付録A.3　HTTPセッションを作成するタイミングを考慮する

HTTPセッションを作成するタイミングを考慮したアプリケーションの実装方法，およびJ2EEサーバのログによる確認方法について説明します。

(1)　アプリケーション実装時の考慮点

アプリケーションで使用しないHTTPセッションは作成しないようにすると，Explicitメモリブロックのメモリ効率が良くなります。J2EEサーバには，暗黙的にHTTPセッションを使用する機能があるため，注意が必要です。

ExplicitメモリブロックとHTTPセッションは1対1で対応します。また，一つのExplicitメモリブロックの最小サイズは，16キロバイト（デフォルトの場合は64キロバイト）です。HTTPセッションを一つ作成すると，HTTPセッションに格納するオブジェクトがなくても，Explicitヒープ領域を16キロバイト使用します。このため，実際には使用しないHTTPセッションは作成しないほうがメモリ効率は良くなります。例えば，使用しないHTTPセッションをサーブレットへのアクセスごとに作成し，HTTPセッションのタイムアウトまで破棄しないアプリケーションがあったとします。タイムアウトが30分，30分に1万回のサーブレットへのアクセスがあるとすると，16キロバイト×1万=160メガバイト（デフォルトの場合は640メガバイト）のExplicitヒープ領域を使用します。

また，JSPでは，デフォルトでアクセスごとにHTTPセッションを作成します。このため，HTTPセッションが不要な処理（例えば，J2EEサーバのヘルスチェック）でJSPを使用している場合は，不要なHTTPセッションのオブジェクトが生成されてExplicitヒープがあふれるおそれがあります。セッションを必要としないJSPでは，明示的にHttpSessionオブジェクトを作成しない設定にしてください。設定には，pageディレクティブのsession属性を使用します。

アプリケーションが変更できない場合は，HTTPセッションで利用するExplicitヒープの省メモリ化機能の利用を検討してください。HTTPセッションで利用するExplicitヒープの省メモリ化機能については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.11　HTTPセッションで利用するExplicitヒープのメモリ使用量の削減」を参照してください。この機能を利用すると，HTTPセッションの破棄前でも利用率の低いExplicitメモリブロックに格納されていたオブジェクトをほかの領域に移動して集約して，利用率の低いExplicitメモリブロックを自動解放します。アプリケーションサーバ内でのHTTPセッションとExplicitメモリブロックの関係が多対1になります。複数のHTTPセッションで一つのExplicitメモリブロックを共有できるため，Explicitメモリブロックの利用率が向上します。これによって，HTTPセッションが確保するExplicitヒープのメモリ使用量を削減できます。

(2)　J2EEサーバログによる確認方法

不要なHTTPセッションに対応するExplicitメモリブロックが作成されていないかどうかは，スレッドダンプの内容から確認します。

確認手順を次に示します。

J2EEサーバを起動し，業務を実行します。

アプリケーションで暗黙的にHTTPセッションを使用していることもあるので，HTTPセッションを使用する業務に絞り込まないようにしてください。

業務の実行中に，eheapprofコマンドを実行してスレッドダンプを取得します。

Explicitヒープ情報に出力された，「used/total」（Explicitメモリブロック利用率）と，「spaces exist」（有効なExplicitメモリブロックの数）の値を確認します。

出力例を次に示します。

max 31415926K, total 162816K, used 150528K, garbage 10004K (0.0% used/max, 91.1% used/total, 6.6% garbage/used), 3 spaces exist

この例では，「used/total」の値が91.1％となっています。この値が100％に近いほどメモリ効率がよい状態です。この値が1けただったり，「spaces exist」の値が想定するHTTPセッションの数を大幅に上回ったりしていないかを確認します。

付録B　Explicitヒープに配置するオブジェクトの寿命による明示管理ヒープ機能への影響

明示管理ヒープ機能の効率的な利用には，Explicitヒープに配置するオブジェクトの寿命が大きく影響します。Explicitヒープ内のExplicitメモリブロックを自動解放するタイミングで，そのブロック内のすべてのオブジェクトが使用済みであると，自動解放処理時間が短くなり，メモリ効率も良くなります。

ここでは，明示管理ヒープ機能の自動解放処理で対象となるExplicitメモリブロックの選択方法，およびExplicitヒープのメモリ使用量やオブジェクトの寿命の考え方について説明します。これらを理解した上で，「付録A　HTTPセッションで利用するExplicitヒープの効率的な利用」の考慮点を確認し，明示管理ヒープ機能の効率的な利用を検討してください。

付録B.1　Explicitメモリブロックの自動解放処理への影響

明示管理ヒープ機能の効率的な利用には，Explicitメモリブロックの自動解放処理の効率が大きく影響します。明示管理ヒープ機能では，レイテンシのスパイクが発生しないようにこまめな自動解放をするために，メモリ領域（Explicitヒープ）をExplicitメモリブロック単位に分割して管理し，そのブロック単位に自動解放処理を実行します。Explicitメモリブロックの自動解放処理は，GCのタイミングで必要に応じて実行されます。また，自動解放処理中は，フルガーベージコレクションと同様にアプリケーションの実行が停止します。このため，自動解放処理の時間が短いほどスループットやレイテンシが向上します。

Explicitメモリブロックの自動解放処理を次の図に示します。

図B‒1　Explicitメモリブロックの自動解放処理

自動解放処理では，自動解放処理対象のExplicitメモリブロックに使用中のオブジェクトがあると，新規にExplicitメモリブロックを作成して移動します。使用中のオブジェクトが大量にあると，その量に比例して自動解放処理の時間は増加します。また，新規に作成されたExplicitメモリブロック（この例では6と7）の自動解放処理も再度実行する必要があるため，全体的な自動解放処理の時間も増加します。このため，自動解放処理時に使用中のオブジェクトがExplicitメモリブロックに少ないほど，自動解放処理の効率は向上します。このことからも，明示管理ヒープ機能では，オブジェクトの寿命が効率に影響することがわかります。

なお，自動解放処理対象のExplicitメモリブロックは，次の方法で選択されます。

自動解放処理対象のExplicitメモリブロックの選択方法について

JavaVMは，次のどれかに該当するExplicitメモリブロックを自動解放処理対象として選択（解放予約）します。

前回から今回までの自動解放処理の間で破棄されたHTTPセッションに対応するブロック

自動解放処理で新規作成されたブロック

自動配置機能で作成されたブロック

ただし，2.および3.のブロックは，Explicitヒープの増分と解放率予測，またはしきい値によって選択されたブロックだけが，自動解放処理対象となります。

Explicitヒープの増分と解放率予測，またはしきい値による選択方法について説明します。

Explicitヒープの増分と解放率予測による選択

次の情報を基に複数のブロックを選択します。通常はこの方法を使用します。

前回の自動解放処理以降のExplicitヒープサイズの増分

過去の自動解放処理の解放率（自動解放できたオブジェクトの割合）

各ブロック内のオブジェクトの使用率の予測値

まず，「前回の自動解放処理以降のExplicitヒープサイズの増分」から，自動解放する予定のExplicitヒープサイズの目標値（以降，目標自動解放サイズといいます）を設定します。Explicitヒープが単調増加しないためには，Explicitヒープサイズの増分以上自動解放する必要があり，増分が大きいほど目標自動解放サイズは大きくなります。目標自動解放サイズを自動解放するためには，複数のブロックの合計でどの程度のサイズを選択すればよいか（以降，選択サイズといいます）を計算します。あるブロックを自動解放処理しても，そのブロック内のすべてのオブジェクトが解放できるとは限りません。そこで，「過去の自動解放処理の解放率」を基に，自動解放する予定のオブジェクトの解放率を予測します。予測した解放率で目標自動解放サイズを達成するために必要となる選択サイズを計算します。「過去の自動解放処理の解放率」が低いほど，選択サイズは大きくなります。

次に，「各ブロック内のオブジェクトの使用率の予測値」ですべてのブロックをソートし，使用中のオブジェクトの割合が低いと予測するブロックから順に選択します。選択したブロックの合計サイズが選択サイズに達すると選択を打ち切ります。ここで選択されたブロックが自動解放処理対象になります。

しきい値による選択

「Explicitヒープの増分と解放率予測による選択」では，使用中のオブジェクトの割合が常に高いブロックや，選択サイズを超えるサイズのブロックは選択されません。このため，ExplicitメモリブロックのサイズがExplicitヒープ全体サイズの一定の割合（しきい値）を超えた場合，強制的に自動解放処理対象として選択します。なお，「しきい値による選択」で選択したブロックは，「Explicitヒープの増分と解放率予測による選択」では選択されません。

付録B.2　Explicitヒープのメモリ使用量への影響

明示管理ヒープ機能の効率的な利用には，Explicitヒープのメモリ使用量が大きく影響します。自動解放処理の対象となるまでは，Explicitメモリブロック中に使用済みのオブジェクトが多いほど，Explicitヒープのメモリ効率が悪くなります。例えば，図B-1のExplicitメモリブロック2は，三つのうち二つのオブジェクトが使用済み（66%が使用済み）です。しかし，Explicitメモリブロック2の使用済みのオブジェクトは，自動解放処理対象に選択されるまでは自動解放されません。このことから，自動解放処理の前は，Explicitメモリブロック中に使用中のオブジェクトが多いほうがメモリ効率は良くなります。

付録B.3　Explicitヒープに配置するオブジェクトの参照関係と寿命との関係

Explicitヒープに配置するオブジェクトから参照されるオブジェクトは，GCが発生すると，「参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動」処理によって，JavaヒープからExplicitメモリブロックへ移動します。この処理は再帰的に適用され，参照関係の末端にあるオブジェクトまでExplicitメモリブロックへ移動します。このため，Explicitメモリブロック内のオブジェクトから，寿命の異なるオブジェクトへの参照が少ないほど，Explicitメモリブロック内のオブジェクトの寿命が同一に近づきます。寿命が同一に近づくことで，同じタイミングで自動解放され，メモリ効率は良くなります。すなわち，オブジェクトの参照関係は，できるだけ同一寿命のオブジェクト間で閉じるように，アプリケーションを実装することが必要になります。例えば，寿命の長い管理テーブルオブジェクトと，寿命の短い1業務で使用するデータオブジェクトの間では，参照関係がないほうが効率は良くなります。参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「7.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動」を参照してください。

付録C　推奨手順以外の方法でパフォーマンスチューニングをする場合のチューニングパラメタ

ここでは，「8.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）」および「9.　パフォーマンスチューニング（バッチアプリケーション実行基盤）」で説明した項目について，推奨手順以外の方法でチューニングを実施するためのチューニングパラメタについて説明します。推奨以外の方法とは，運用管理ポータルを使用して設定する方法，およびファイル編集によって設定する方法です。

チューニングの考え方については，「8.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）」および「9.　パフォーマンスチューニング（バッチアプリケーション実行基盤）」を参照してください。

付録C.1　同時実行数を最適化するためのチューニングパラメタ（推奨手順以外の方法）

ここでは，同時実行数の最適化で使用するチューニングパラメタの設定方法と設定個所についてまとめて示します。

(1)　NIO HTTPサーバ使用時のリクエスト処理スレッド数

NIO HTTPサーバを使用している場合の，リクエスト処理スレッド数のチューニングパラメタの設定方法および設定個所について，次の表に示します。

なお，Webサーバ連携でHTTP Serverを使用している場合のチューニングパラメタについては，マニュアル「HTTP Server」を参照してください。

表C‒1　NIO HTTPサーバ使用時のリクエスト処理スレッド数のチューニングパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

J2EEサーバ起動時に生成するリクエスト処理スレッド数

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「最小スレッド数」

ファイル編集

usrconf.propertiesのwebserver.connector.nio_http.min_threadsキー

Webクライアントまたはリバースプロキシとの接続数の上限

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「Webクライアントとの接続設定」の「最大接続数」

ファイル編集

usrconf.propertiesのwebserver.connector.nio_http.max_connectionsキー

Webクライアントまたはリバースプロキシとの接続数の上限を超えた場合に使用されるTCP/IPのListenキュー（バックログ）の最大値

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「Webクライアントとの接続設定」の「TCPリスンキューの長さ」

ファイル編集

usrconf.propertiesのwebserver.connector.nio_http.backlogキー

リクエスト処理スレッドの最大数

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「最大スレッド数」

ファイル編集

usrconf.propertiesのwebserver.connector.nio_http.max_threadsキー

(2)　Webアプリケーションの同時実行数

URLグループ単位，Webアプリケーション単位，またはWebコンテナ単位に設定します。

(a)　URLグループ単位の同時実行数

URLグループ単位の同時実行数のチューニングパラメタの設定方法および設定個所について，次の表に示します。

表C‒2　URLグループ単位の同時実行数のチューニングパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

Webコンテナ単位での最大同時実行スレッド数

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「同時実行スレッド数」

ファイル編集

usrconf.propertiesのwebserver.connector.nio_http.max_servlet_execute_threadsキー

デフォルトの実行待ちキューサイズ

運用管理ポータル

［Webコンテナの設定］画面の「Webコンテナの設定」の「実行待ちキューサイズ」

ファイル編集

usrconf.propertiesのwebserver.container.thread_control.queue_sizeキー

次の設定項目については，推奨手順の場合と違いがありません。

Webアプリケーション単位での最大同時実行スレッド数

Webアプリケーションの占有スレッド数

Webアプリケーション単位の実行待ちキューサイズ

URLグループ単位の同時実行スレッド数制御の定義名

URLグループ単位での最大同時実行スレッド数

URLグループ単位の占有スレッド数

URLグループ単位の実行待ちキューサイズ

URLグループ単位の制御対象となるURLパターン

(b)　Webアプリケーション単位の同時実行数

Webアプリケーション単位の同時実行数をチューニングするパラメタの設定方法および設定個所について，次の表に示します。

表C‒3　Webアプリケーション単位の同時実行数のチューニングパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

Webコンテナ単位での最大同時実行スレッド数

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「同時実行スレッド数」

ファイル編集

usrconf.propertiesのwebserver.connector.nio_http.max_servlet_execute_threadsキー

デフォルトの実行待ちキューサイズ

運用管理ポータル

［Webコンテナの設定］画面の「Webコンテナの設定」の「実行待ちキューサイズ」

ファイル編集

usrconf.propertiesのwebserver.container.thread_control.queue_sizeキー

次の設定項目については，推奨手順と違いがありません。

Webアプリケーション単位での最大同時実行スレッド数

Webアプリケーションの占有スレッド数

Webアプリケーション単位の実行待ちキューサイズ

(c)　Webコンテナ単位の同時実行数

Webコンテナ単位の同時実行数をチューニングするパラメタの設定方法および設定個所について，次の表に示します。

表C‒4　Webコンテナ単位の同時実行数のチューニングパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

Webコンテナ単位での最大同時実行スレッド数

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「同時実行スレッド数」

ファイル編集

usrconf.propertiesのwebserver.connector.nio_http.max_servlet_execute_threadsキー

(3)　Enterprise Beanの同時実行数

Enterprise Beanの同時実行数は，Enterprise Bean単位に設定します。

Enterprise Beanの同時実行数のチューニングパラメタについては，推奨手順の場合と違いがありません。

(4)　CTMで制御する同時実行数

CTMで制御する同時実行数のチューニングパラメタの設定方法および設定個所について，次の表に示します。CTMデーモン，アプリケーション，およびStateless Session Beanに設定する項目があります。

CTMで制御する同時実行数のチューニングパラメタの設定方法および設定個所について，次の表に示します。

表C‒5　CTMで制御する同時実行数のチューニングパラメタ（推奨手順以外の方法）

設定対象

設定項目

設定方法

設定個所

CTMデーモン

CTMが制御するスレッドの最大値およびキューごとのリクエストの登録数

運用管理ポータル

［スケジューリングの設定］画面の「CTMキューの設定」の「スレッド最大値」

ファイル編集

ctmstartコマンドの引数「-CTMDispatchParallelCount」

なお，アプリケーションまたはStateless Session Beanに対する設定項目については，推奨手順の場合と違いがありません。

付録C.2　Enterprise Beanの呼び出し方法を最適化するためのチューニングパラメタ（推奨手順以外の方法）

ここでは，Enterprise Beanの呼び出し方法の最適化で使用するチューニングパラメタの設定個所についてまとめて示します。

(1)　ローカルインタフェースの使用

アプリケーション作成時に，J2EEで定義されているローカルインタフェースを使用してください。

推奨手順の場合と違いはありません。

(2)　リモートインタフェースのローカル呼び出し機能の使用

リモートインタフェースのローカル呼び出し機能をチューニングするパラメタの設定方法および設定個所について，次の表に示します。

表C‒6　リモートインタフェースのローカル呼び出し機能のチューニングパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

ローカル呼び出し最適化機能の適用範囲

運用管理ポータル

［EJBコンテナの設定］画面の「オプション」の「J2EEアプリケーションの呼び出し方式」

ファイル編集

usrconf.propertiesのejbserver.rmi.localinvocation.scopeキー

(3)　リモートインタフェースの参照渡し機能の使用

リモートインタフェースの参照渡し機能をチューニングするパラメタの設定方法および設定個所について，次の表に示します。

表C‒7　リモートインタフェースの参照渡し機能のチューニングパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

リモートインタフェースの参照渡し機能の使用（J2EEサーバ単位）

運用管理ポータル

［EJBコンテナの設定］画面の「オプション」の「リモートインタフェースの参照渡し」

ファイル編集

usrconf.propertiesのejbserver.rmi.passbyreferenceキー

なお，リモートインタフェースの参照渡し機能の使用（Enterprise Bean単位）については，推奨手順の場合と違いがありません。

付録C.3　データベースへのアクセス方法を最適化するためのチューニングパラメタ（推奨手順以外の方法）

データベースへのアクセス方法の最適化で使用するチューニングパラメタについては，推奨手順の場合と違いがありません。

付録C.4　タイムアウトを設定するチューニングパラメタ（推奨手順以外の方法）

ここでは，タイムアウトの設定で使用するチューニングパラメタの設定個所についてまとめて示します。

(1)　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

Webサーバ連携の場合は，Webサーバ単位に設定します。Webサーバ連携の場合だけ指定できます。

表C‒8　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法

設定個所

運用管理ポータル

［Webサーバの設定］画面の「項目ごとに設定します。」の「追加ディレクティブ」のTimeoutディレクティブ

ファイル編集※

httpsd.confのTimeoutディレクティブ

注※　HTTP Serverの定義ファイルであるhttpd.confを編集して設定します。

(2)　HTTP Serverのリバースプロキシで設定するWebコンテナとのデータ送受信のタイムアウト

HTTP Serverのリバースプロキシ側で設定するタイムアウトのチューニングパラメタを次の表に示します。なお，これらのチューニングパラメタは，Webサーバ連携の場合だけ指定できます。

表C‒9　HTTP Serverのリバースプロキシ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法

設定個所

運用管理ポータル

［リバースプロキシの設定］画面の「リクエストのマッピングに関する設定」の「タイムアウト時間」

ファイル編集

httpsd.confのProxyPassパラメタのtimeoutキー

(3)　Webコンテナ側で設定するリバースプロキシまたはWebクライアントからのデータ受信のタイムアウト

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタを次の表に示します。

表C‒10　Webコンテナ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法

設定個所

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「Webクライアントとの接続設定」の「通信タイムアウト」の「リクエスト受信」

ファイル編集

usrconf.propertiesのwebserver.connector.nio_http.receive_timeoutキー

(4)　Webコンテナ側で設定するリバースプロキシまたはWebクライアントへのデータ送信のタイムアウト

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタを次の表に示します。

表C‒11　Webコンテナ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法

設定個所

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「Webクライアントとの接続設定」の「通信タイムアウト」の「レスポンス送信」

ファイル編集

usrconf.propertiesのwebserver.connector.nio_http.send_timeoutキー

付録C.5　Webアプリケーションの動作を最適化するためのチューニングパラメタ（推奨手順以外の場合）

ここでは，Webアプリケーションの動作を最適化するために使用するチューニングパラメタの設定個所についてまとめて示します。

(1)　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

静的コンテンツとWebアプリケーションの配置の切り分けは，Webサーバの動作を定義するファイルのパラメタとして指定します。

表C‒12　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ（推奨手順以外の場合）

設定方法

設定個所

運用管理ポータル

［論理Webサーバの定義］画面の「リバースプロキシの設定」

ファイル編集

httpsd.confのProxyPassディレクティブ※

注※　httpsd.confの詳細については，マニュアル「HTTP Server」を参照してください。

(2)　静的コンテンツをキャッシュするためのチューニングパラメタ

静的コンテンツをキャッシュするためのチューニングパラメタについて説明します。これらのチューニングパラメタは，Webコンテナ単位またはWebアプリケーション単位に設定します。

Webコンテナ単位に設定するチューニングパラメタの設定方法および設定個所について，次の表に示します。

表C‒13　静的コンテンツをキャッシュするためのチューニングパラメタ（Webコンテナ単位で設定する項目）（推奨手順以外の場合）

設定項目

設定方法

設定個所

静的コンテンツのキャッシュを使用するかどうかの選択

運用管理ポータル

［Webコンテナの設定］画面の「Webコンテナの設定」の「静的コンテンツキャッシュ機能」

ファイル編集

usrconf.propertiesのwebserver.static_content.cache.enabledキー

Webアプリケーション単位のメモリサイズの上限値の設定

運用管理ポータル

［Webコンテナの設定］画面の「Webコンテナの設定」の「キャッシュサイズ」

ファイル編集

usrconf.propertiesのwebserver.static_content.cache.sizeキー

キャッシュする静的コンテンツのファイルサイズの上限値の設定

運用管理ポータル

［Webコンテナの設定］画面の「Webコンテナの設定」の「ファイルサイズ」

ファイル編集

usrconf.propertiesのwebserver.static_content.cache.filesize.thresholdキー

Webアプリケーション単位に設定するチューニングパラメタについては，推奨手順の場合と違いがありません。

付録C.6　CTMの動作を最適化するチューニングパラメタ（推奨手順以外の方法）

ここでは，CTMの動作の最適化で使用するチューニングパラメタの設定個所についてまとめて示します。

(1)　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔を設定するチューニングパラメタ

CTMドメインマネジャの稼働状態の監視間隔をチューニングするパラメタを次に示します。

監視間隔は，送信間隔×係数の値になります。

表C‒14　CTMドメインマネジャの稼働状態の監視間隔をチューニングするパラメタ（推奨手順以外の方法）

対象

設定項目

設定方法

設定個所

同じネットワークセグメント内にあるCTMドメインマネジャ

送信間隔

運用管理ポータル

論理CTMドメインマネジャの［ネットワーク設定］画面の「CTMドメイン構成情報の送信間隔」

コマンド実行

ctmdmstartコマンドの引数「-CTMSendInterval」

係数

運用管理ポータル

論理CTMドメインマネジャの［ネットワーク設定］画面の「ドメインマネジャ生存判定間隔係数」

コマンド実行

ctmdmstartコマンドの引数「-CTMAliveCheckCount」

異なるネットワークセグメントにあるCTMドメインマネジャ

送信間隔

運用管理ポータル

論理CTMドメインマネジャの［ネットワーク設定］画面の「指定ホストへの構成情報の送信間隔」

コマンド実行

ctmdmstartコマンドの引数「-CTMSendHostInterval」

係数

運用管理ポータル

論理CTMドメインマネジャの［ネットワーク設定］画面の「ドメインマネジャ生存判定間隔係数」

コマンド実行

ctmdmstartコマンドの引数「-CTMAliveCheckCount」

CTMデーモンの稼働状態の監視間隔をチューニングするパラメタを次に示します。

表C‒15　CTMデーモンの稼働状態の監視間隔をチューニングするパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

CTMデーモン間転送時のタイムアウト

運用管理ポータル

論理CTMの［CTM間通信の設定］画面の「リクエスト転送時のタイムアウト時間」

コマンド実行

ctmstartコマンドの引数「-CTMDCSendTimeOut」

(2)　負荷状況監視間隔を設定するチューニングパラメタ

負荷状況監視間隔のチューニングパラメタを次に示します。

表C‒16　負荷情報監視間隔のチューニングパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

CTMデーモン間転送時のタイムアウト

運用管理ポータル

論理CTMの［スケジューリングの設定］画面の「負荷情報監視間隔」

コマンド実行

ctmstartコマンドの引数「-CTMLoadCheckInterval」

(3)　CTMデーモンのタイムアウト閉塞を設定するチューニングパラメタ

タイムアウト閉塞は，タイムアウト発生回数と監視間隔を設定しておくことによって，実行されます。

CTMデーモンのタイムアウト閉塞のチューニングパラメタを次に示します。

表C‒17　CTMデーモンのタイムアウト閉塞のチューニングパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

タイムアウト発生回数

運用管理ポータル

論理CTMの［スケジューリングの設定］画面の「タイムアウト閉塞」の「自動閉塞するタイムアウト発生回数」

コマンド実行

ctmstartコマンドの引数「-CTMWatchRequest」（一つ目のオプション引数）

監視時間間隔

運用管理ポータル

論理CTMの［スケジューリングの設定］画面の「タイムアウト閉塞」の「監視時間間隔」

コマンド実行

ctmstartコマンドの引数「-CTMWatchRequest」（二つ目のオプション引数）

(4)　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ

CTMで振り分けるリクエストの優先順位の設定は，EJBクライアントアプリケーションの場合と，J2EEサーバの場合で異なります。また，J2EEサーバの場合，システムの構築方法によって設定個所が異なります。CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタを次に示します。

表C‒18　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ（推奨手順以外の方法）

設定単位

設定方法

設定個所

J2EEサーバ

運用管理ポータル

論理J2EEサーバの［EJBコンテナの設定］画面の「CTMの設定」の「リクエストの優先順位」

ファイル編集

usrconf.propertiesのejbserver.client.ctm.RequestPriorityキー

EJBクライアントアプリケーション単位のチューニングパラメタについては，推奨手順の場合と違いがありません。

付録C.7　バッチサーバのフルガーベージコレクションを発生させるしきい値を設定するためのチューニングパラメタ（推奨手順以外の方法）

バッチサーバのフルガーベージコレクションを実行するしきい値を設定するために使用するチューニングパラメタについて説明します。

この項目は，バッチサーバで，フルガーベージコレクションの実行を制御するときにチューニングを検討してください。

表C‒19　バッチサーバのフルガーベージコレクションを実行するしきい値を設定するチューニングパラメタ

設定項目

設定方法

設定個所

しきい値

運用管理ポータル

［コンテナの設定］画面の「拡張パラメタ」

usrconf.properties

ejbserver.batch.gc.watch.thresholdキー

付録D　用語解説

マニュアルで使用する用語について

マニュアル「アプリケーションサーバ & BPM/ESB基盤 用語解説」を参照してください。

索引

記号

-XX:+HitachiVerboseGCPrintTenuringDistributionオプション[1]

C

cjclstartapプロセスの見積もり[1]

CJMSPリソースアダプタ[1]

Concurrent Marking（CM）[1]

CopyGC[1]

CopyGCの仕組み[1]

CORBAネーミングサービス（インプロセス起動時）のスレッド数の見積もり[1]

CTM[1]、[2]

CTMとEJBコンテナ（J2EEサーバ）の配置[1]

CTMのデーモンプロセスが使用するメモリの使用量の見積もり[1]

Cヒープ領域[1]

D

DB Connector[1]

DB Connector for Reliable Messaging[1]

DD[1]

E

Eden領域[1]

EJBクライアント[1]、[2]

EJBクライアント構成[1]

EJBコンテナ[1]

EJB-JAR[1]

Enterprise Beanの呼び出し方法の最適化[1]

Explicitヒープ[1]、[2]

Explicitヒープあふれ[1]

Explicitヒープのチューニング[1]

Explicitヒープ領域[1]

F

FullGC[1]、[2]、[3]

FullGC発生を抑止するためのチューニングの概要[1]

G

G1GCで実行されるGC[1]

G1GCの概要[1]

G1GCの仕組み[1]

G1GCのチューニング[1]

GC[1]、[2]

GC対象外の領域（明示管理ヒープ機能を使用したExplicitヒープ領域の利用）[1]

GCとJavaVMのメモリ管理の概要[1]

GCの発生とメモリ空間の関係[1]

I

InPlace[1]

J

J2EEアプリケーション[1]、[2]

J2EEアプリケーションとJ2EEコンポーネントの関係[1]

J2EEアプリケーションの構造[1]

J2EEコンテナ[1]

J2EEコンポーネント[1]

J2EEサーバ[1]、[2]

J2EEサーバが使用する仮想メモリの使用量の見積もり[1]

J2EEサーバの構成[1]

J2EEサーバの構造[1]

J2EEサービス[1]、[2]

J2EEリソース[1]、[2]

JavaVMオプション[1]

JavaVM固有領域[1]

JavaVMで使用するメモリ空間の構成（ZGCの場合）[1]

JavaVMのメモリチューニング[1]

Javaヒープ[1]

Javaヒープ内に一定期間存在するオブジェクトの扱いの検討[1]

Javaヒープ内のMetaspace領域のメモリサイズの見積もり[1]

Javaヒープ内のNew領域のメモリサイズの見積もり[1]

Javaヒープ内のTenured領域のメモリサイズの見積もり[1]

Javaヒープの最大サイズ／初期サイズの決定[1]

Javaヒープのチューニング[1]

Javaヒープ領域のメモリ管理方法（ZGCの場合）[1]

JCAとEISの配置[1]

JP1と連携したシステムの運用[1]

JPAプロバイダ[1]

M

Management Server[1]、[2]、[3]、[4]

Metaspace領域[1]

MixedGC[1]、[2]

N

N:1リカバリシステム[1]

New領域を対象としたGCの仕組み[1]

NIO HTTPサーバ[1]

O

OS固有領域[1]

OSのパラメタ設定（ZGCの場合）[1]

OutOfMemory発生時強制終了機能[1]

OutOfMemoryハンドリング機能[1]

P

PRFデーモン[1]、[2]

S

SerialGC使用時のJavaVMで使用するメモリ空間の構成[1]

SerialGCの概要[1]

SerialGCの仕組み[1]

Survivor領域[1]

T

Tenured領域[1]

TP1/Client/J[1]

TP1/Message Queue - Access[1]

TP1 Connector[1]

TP1インバウンドアダプタ[1]

TPBroker OTMクライアント[1]

TPBrokerクライアント[1]

W

Webアプリケーション[1]

Webクライアント構成[1]

Webコンテナ[1]

Webサーバ[1]

Webサーバ選択の指針[1]

WebサーバとWebコンテナ（J2EEサーバ）の配置[1]

Webフロントシステム[1]

Y

YoungGC[1]、[2]

Z

ZGCサイクル[1]

ZGC使用時の他機能への影響（JDK17以降の場合）[1]

ZGC使用時の注意事項（JDK17以降の場合）[1]

ZGCでのGCの考え方[1]

ZGC独自のGC発生要因[1]

ZGCの概要[1]

ZGCの仕組み（JDK17以降の場合）[1]

ZGCのチューニング（JDK17以降の場合）[1]

あ

アーカイブ形式のJ2EEアプリケーション[1]

アクセスポイント[1]、[2]

アクセスポイントになるコンポーネントの種類ごとに検討が必要な項目[1]

アセンブル[1]

アプリケーションサーバ[1]

アプリケーションサーバが使用するTCP/UDPのポート番号[1]

アプリケーションサーバマシン[1]

アプリケーションで明示管理ヒープ機能を使用する場合のメモリサイズの見積もり[1]

アプリケーションの構成[1]

アプリケーションの種類ごとにチューニングできる項目[1]

い

インスタンスプーリング[1]

う

運用管理エージェント[1]、[2]

運用管理サーバ[1]、[2]

運用管理サーバマシン[1]

運用管理サーバモデル[1]

運用管理ドメイン[1]

お

オブジェクトの寿命[1]、[2]

オブジェクトの退避[1]、[2]

オンライン業務[1]

か

拡張verbosegc情報[1]

拡張verbosegc情報を使用したFullGCの要因の分析方法[1]

仮想メモリの使用量の見積もり[1]

き

機能ごとに必要なプロセス（アプリケーションサーバ以外によって提供されるもの）と提供するソフトウェア[1]

機能ごとに必要なプロセスまたはモジュール（アプリケーションサーバによって提供されるもの）[1]、[2]

機能ごとに必要なモジュール（アプリケーションサーバ以外によって提供されるもの）と提供するソフトウェア[1]、[2]

機能レイヤ[1]

く

クエリータイムアウト[1]

クライアント側のアプリケーションサーバ[1]

クライアントマシン[1]

クラスタソフトウェアと連携したシステムの運用[1]

け

系切り替え[1]

こ

コードキャッシュ領域[1]

コネクション障害検知[1]

コネクション数調節機能[1]

コネクションプーリング[1]

コンテナ拡張ライブラリ[1]、[2]

さ

サーバ側のアプリケーションサーバ[1]

し

システム構成図で使用する図の凡例[1]

システム構成図で使用する図の凡例（ホストの分類）[1]

システム構成に共通する留意点[1]

システム構成の考え方[1]

システム設計の流れ[1]

システム設計の目的[1]

システム全体の自動運転[1]

システム全体の集中監視[1]

システムの分類に応じて必要なプロセス[1]

実行待ちキューサイズ[1]

出力内容が変更される機能（ZGCの場合）[1]

使用が制限される機能（ZGCの場合）[1]

す

スタック領域[1]

ステートメントプーリング[1]

せ

静的コンテンツ[1]

静的コンテンツのキャッシュ[1]

世代別GC[1]、[2]

セッション制御[1]、[2]

そ

相互系切り替えシステム[1]

相互スタンバイ[1]

相互スタンバイ構成[1]

ち

チューニング手順[1]、[2]、[3]

チューニングの考え方[1]

チューニングの流れ[1]

チューニングの流れ（ZGCの場合）[1]

チューニングの方法[1]、[2]

て

データベースアクセス方法の最適化[1]、[2]

データベースセッションフェイルオーバ機能[1]

デプロイ[1]

展開ディレクトリ形式のJ2EEアプリケーション[1]

と

統合ネーミングスケジューラサーバ[1]

同時実行数の最適化[1]

動的コンテンツ[1]

トランザクションコンテキストのプロパゲーション[1]

ね

ネーミングサービスの配置[1]

は

バックシステム[1]

バッチアプリケーション[1]、[2]

バッチ業務[1]

バッチサーバ[1]、[2]

バッチサーバの構成[1]

バッチサーバの構造[1]

バッチサービス[1]

パフォーマンスチューニング[1]、[2]

パフォーマンストレーサ[1]、[2]

ふ

プロセスごとに使用するメモリの見積もり[1]

ほ

ホスト単位管理モデル[1]

め

明示管理ヒープ機能適用時に発生しやすい問題とその解決方法[1]

明示管理ヒープ機能の自動配置機能を使用したExplicitヒープの利用の検討[1]

メソッドキャンセル[1]

メモリ空間とリージョンの関係[1]

ゆ

ユーザサーバ[1]、[2]

ら

ライブラリJAR[1]

り

リージョンの使われ方[1]

リカバリ専用サーバ[1]

リバースプロキシ機能を有効にしたWebサーバ[1]

れ

レイヤ5スイッチ[1]、[2]

ろ

ローカル呼び出し最適化機能[1]

論理サーバ[1]

論理ユーザサーバ[1]