| Interstage Application Server チューニングガイド |
|
目次
索引
|
| 第3章 J2EEのチューニング |
IJServerをチューニングする時に考慮するポイントは以下です。ここに記述されたチューニングは、ServletコンテナとEJBコンテナの両方に有効です。
1つのIJServerを、複数のプロセスで起動できます。これにより、負荷を分散できます。
IJServerのプロセス多重度は、Interstage管理コンソールのワークユニット設定またはisj2eeadminコマンドで指定できます。詳細については、Interstage管理コンソールのヘルプを参照してください。isj2eeadminコマンドについては、“リファレンスマニュアル（コマンド編）”の“isj2eeadmin”を参照してください。
Interstage管理コンソールまたはisj2eeadminコマンドを使用して、ワークユニット設定のJava VMオプションを指定することで、IJServerが動作するJava VMのパラメタを変更して動作させることができます。
パラメタを変更して、Java VMヒープ領域サイズなどを変更できます。
JDK 1.4の場合における最大ヒープ領域サイズの例を次に示します。
最大ヒープ領域のサイズの省略値は、Java VMによって異なりますので、JDKのドキュメントを参照してください。java.lang.OutOfMemoryErrorが多発する場合には、本定義項目で、Java VMの最大ヒープ領域を増加させてください。
Java VMの最大ヒープ領域を1024メガバイトとする場合の設定
-Xmx1024m
なお、Interstageではヒープ領域の問題を警告メッセージで通知する、予兆監視機能を提供しています。
警告メッセージが出力された場合、そのまま業務を継続すると、メモリ不足やレスポンス低下などの問題が発生する可能性があります。これらの問題を解決するために、警告メッセージに記載されている不足リソースの情報を元に、チューニングを実施してください。
Java VMで問題となる異常の原因は、ヒープ領域またはPerm領域の不足です。これを回避するために、現在の上限値を20％増加させて運用を再開します。それでも警告が出力される場合は、上限値を更に20％増加させて、警告が出力されなくなるまで繰り返しチューニングを実施してください。チューニングを繰り返し行い、警告メッセージが出力されない状態にすることで、安定稼動するシステムを構築することができます。
予兆監視機能については、“Interstage Application Server 運用ガイド”を参照してください。
IJServerでは、JavaのRMI機能による自動ガーベジコレクションがデフォルトで1時間隔で動作します。
RMI機能による自動ガーベジコレクションの発生間隔は、Interstage管理コンソール > “ワークユニット名” > [環境設定]タブ > [ワークユニット設定]のJava VMオプションに、“-Dsun.rmi.dgc.client.gcInterval=発生間隔”および“-Dsun.rmi.dgc.server.gcInterval=発生間隔”を指定してチューニングします。発生間隔には、ミリ秒単位で数値を指定してください。
指定がない場合には、IJServerの起動時に“-Dsun.rmi.dgc.client.gcInterval=3600000”および“-Dsun.rmi.dgc.server.gcInterval=3600000”が自動的に設定されます。
isj2eeadminコマンドを使用して、設定することもできます。isj2eeadminコマンドについては、“リファレンスマニュアル（コマンド編）”の“isj2eeadmin”を参照してください。
なお、RMI機能による自動ガーベジコレクションの発生間隔をチューニングしても、ガーベジコレクション発生回数が削減されない場合、Java VMのヒープ領域サイズが不足している可能性がありますので、Java VMのヒープ領域サイズのチューニングを行うことで削減される場合があります。“Java VMのヒープ領域サイズ”を参照ください。
EJBアプリケーションからデータベースにアクセスする場合、EJBアプリケーションの実行多重度を上げるには、トランザクションアイソレーションレベル(以降、アイソレーションレベルと呼びます)を考慮する必要があります。アイソレーションレベルとは、データベースに対する排他整合性水準のことです。
使用できるアイソレーションレベルを以下に示します。アイソレーションレベルの詳細は、使用するデータベースのマニュアルを参照してください。
アイソレーションレベルの設定は、UserTransaction.begin()メソッドを発行してから、UserTransaction.commit()メソッドまたはUserTransaction.rollback()メソッドを発行するまでの間有効です。
アイソレーションレベルは、Interstage管理コンソールまたはisj2eeadminコマンドで設定します。設定方法の詳細については、Interstage管理コンソールのヘルプを参照してください。isj2eeadminコマンドについては、“リファレンスマニュアル（コマンド編）”の“isj2eeadmin”を参照してください。
【DBMSにOracleを使用している場合】
「ORA-8177：このトランザクションのアクセスを逐次化できません。」というエラーは、トランザクションアイソレーションレベルにTransaction-serializableが設定されているにもかかわらず、複数のユーザが同時に同一の表を更新した場合など、トランザクションのシリアル化を保障できない場合に出力され、ユーザにその旨を伝えています。
トランザクションアイソレーションレベルにTransaction-serializableを設定し、エラー「ORA-8177」が発生した場合は、アプリケーション側で単に「異常終了」と判断するのではなく、トランザクションのロールバック後に「リトライ」させるなどの対処が必要になります。
なお、トランザクションアイソレーションレベルがTransaction-read-committed(Oracleのデフォルト)の場合は、「ORA-8177」エラーが発生することはありません。特にTransaction-serializableの設定が必須ではない場合、Transaction-read-committedを設定することにより、同時実行性が向上し、「ORA-8177」エラーも発生しなくなります。
ここでは、JDBCのコネクションの以下について説明します。
InterstageのJNDIサービスプロバイダから取得したJDBCデータソースを使用した場合、JDBCのコネクションはプーリングされて再利用されます。
コネクションプーリングには、以下の2種類があります。
それぞれの特徴は、以下のとおりです。
コネクションプーリングの機能概要については、“J2EEユーザーズガイド”の“JDBC(データベース)のコネクション”を参照してください。
チューニング方法について説明します。
以下に、各データベースとコネクションプーリングの対応について記載します。
|
DB種別 |
コネクションプーリング |
|
Oracle |
Interstageでコネクションプーリングを行います。 |
|
Symfoware |
JDBCドライバでコネクションプーリングを行います。 |
|
SQL Server |
Interstageでコネクションプーリングを行います。 |
|
|
データソースの種類に“Interstageでコネクションプーリングを行う”を選択している場合に、Interstageでコネクションプーリングを行います。 |
以下に、Interstage管理コンソールまたはisj2eeadminコマンドを使用して設定可能なパラメタを示します。
パラメタは、データソースごとにIJServerの環境設定で設定します。
|
パラメタ |
説明 |
設定値 |
|
事前コネクト数 (注1) (注4) |
運用で必要なコネクションを、起動時にあらかじめ取得することにより、初回疎通時から2回目以降と同等の処理速度が得られます。 |
最大値：2147483647 |
|
最大コネクション数 (注2) |
最大コネクション数を抑止することにより、メモリ資源を抑止することが可能です。 |
最大値：2147483647 |
|
コネクションタイムアウト (注2) |
最大コネクション数分のコネクションすべてがJ2EEアプリケーションで使用中の状態で、コネクションの接続要求が来た場合に、プールにコネクションが返却されるのを待つ時間を指定します。 |
最大値：2147483647 |
|
アイドルタイムアウト (注2) |
使用されていないコネクションをタイムアウトで破棄することにより、無駄なメモリ資源を解放することができます。 |
最大値：2147483647 |
|
異常時の再接続 (注2) |
JDBCコネクションの自動再接続機能(注3)を使用するかどうかを指定します。 |
する/しない(デフォルト) |
|
インターバル時間 (注2) |
JDBCコネクションの自動再接続機能(注3)において、プーリングされているJDBCのコネクションが使用できない場合、またはDBMSへの接続に失敗した場合、再度接続を行うまでのインターバル時間を指定します。 |
最大値：2147483647 |
|
リトライ回数 (注2) |
JDBCコネクションの自動再接続機能(注3)において、プーリングされているJDBCのコネクションが使用できない場合、またはDBMSへの接続に失敗した場合、再度接続を試みる回数を指定します。 |
最大値：2147483647 |
|
.bindingsファイルを作成しない場合 |
Oracle |
SQL Server |
PostgreSQL |
|
OracleConnectionPoolDataSourceまたはOracleXADataSourceを、File SystemService Provider(※)に登録 |
SQLServerDataSourceを、File SystemService Provider(※)に登録 |
org.postgresql.jdbc2.optional.ConnectionPool(JDBC2.0の場合)またはorg.postgresql.jdbc3.Jdbc3ConnectionPool(JDBC3.0の場合)を、File SystemService Provider(※)に登録 |
(※) File System Service Providerは、米国Sun Microsystems.Inc.が提供するJNDIのサービスプロバイダです。
|
項目 |
Oracle |
SQL Server |
PostgreSQL |
|
接続方法 |
JDBC2.X(データソース接続) |
JDBC2.X(データソース接続) |
JDBC2.0またはJDBC3.0 |
|
トランザクション種別 |
分散トランザクション機能を使用しない。 |
分散トランザクション機能を使用しない。 |
分散トランザクション機能を使用しない。 |
なお、Symfowareの場合は、Connection Managerの機能を使用することで、データベースサーバのダウンおよび通信回線の異常発生時にも同等の運用を行うことが可能です。
Connection Managerの詳細については、Connection Managerのマニュアル“Connection Managerユーザーズガイド”を参照してください。
SQLServerとPostgreSQLは、クライアント機能を使用してリモート接続する場合のみのサポートとなります。
Interstage管理コンソールでは、運用中のIJServerの稼動情報を表示します。出力される情報により、性能のボトルネックの検出や、性能チューニングの効果の確認ができます。
以下の情報が出力されます。出力される情報の詳細は、Interstage管理コンソールのヘルプを参照してください。
Interstage Traffic Directorを利用して、IJServerとWebサーバを分離して運用するシステムの負荷分散をする場合、故障監視用のコネクション(スレッド)が必要となります。
この場合、IJServerの同時処理数を設定するときは実際の同時処理数に監視用の数を考慮してください。設定は以下になります。
設定する同時処理数 = 実際の同時処理数 + 1(監視用)
なお、Interstage Traffic Directorの常設コネクション数を設定する場合は、実際の同時処理数を設定してください(監視用の数は加算しないでください)。常設コネクション数については、Interstage Traffic Directorのマニュアルを参照してください。
|
目次
索引
|
