| Interstage Application Server チューニングガイド |
|
目次
索引
|
| 第3章 J2EEのチューニング |
IJServerをチューニングする時に考慮するポイントは以下です。ここに記述されたチューニングは、ServletコンテナとEJBコンテナの両方に有効です。
1つのIJServerを、複数のプロセスで起動できます。これにより、負荷を分散できます。
IJServerのプロセス多重度は、Interstage管理コンソールのワークユニット設定で指定できます。詳細については、Interstage管理コンソールのヘルプを参照してください。
Interstage管理コンソールを使用して、ワークユニット設定のJava VMオプションを指定することで、IJServerが動作するJava VMのパラメタを変更して動作させることができます。
パラメタを変更して、Java VMヒープ領域サイズなどを変更できます。
JDK 1.4の場合における最大ヒープ領域サイズの例を次に示します。
最大ヒープ領域のサイズの省略値は、Java VMによって異なりますので、JDKのドキュメントを参照してください。java.lang.OutOfMemoryErrorが多発する場合には、本定義項目で、Java VMの最大ヒープ領域を増加させてください。
Java VMの最大ヒープ領域を512メガバイトとする場合の設定
-Xmx512m
なお、Interstageではヒープ領域の問題を警告メッセージで通知する、予兆監視機能を提供しています。
警告メッセージが出力された場合、そのまま業務を継続すると、メモリ不足やレスポンス低下などの問題が発生する可能性があります。これらの問題を解決するために、警告メッセージに記載されている不足リソースの情報を元に、チューニングを実施してください。
Java VMで問題となる異常の原因は、ヒープ領域またはPerm領域の不足です。これを回避するために、現在の上限値を20％増加させて運用を再開します。それでも警告が出力される場合は、上限値を更に20％増加させて、警告が出力されなくなるまで繰り返しチューニングを実施してください。チューニングを繰り返し行い、警告メッセージが出力されない状態にすることで、安定稼動するシステムを構築することができます。
予兆監視機能については、“Interstage Application Server 運用ガイド”を参照してください。
EJBアプリケーションからデータベースにアクセスする場合、EJBアプリケーションの実行多重度を上げるには、トランザクションアイソレーションレベル(以降、アイソレーションレベルと呼びます)を考慮する必要があります。アイソレーションレベルとは、データベースに対する排他整合性水準のことです。
使用できるアイソレーションレベルを以下に示します。アイソレーションレベルの詳細は、使用するデータベースのマニュアルを参照してください。
アイソレーションレベルの設定は、UserTransaction.begin()メソッドを発行してから、UserTransaction.commit()メソッドまたはUserTransaction.rollback()メソッドを発行するまでの間有効です。
アイソレーションレベルは、Interstage管理コンソールで設定します。設定方法の詳細については、Interstage管理コンソールのヘルプを参照してください。
【DBMSにOracleを使用している場合】
「ORA-8177：このトランザクションのアクセスを逐次化できません。」というエラーは、トランザクションアイソレーションレベルにTransaction-serializableが設定されているにもかかわらず、複数のユーザが同時に同一の表を更新した場合など、トランザクションのシリアル化を保障できない場合に出力され、ユーザにその旨を伝えています。
トランザクションアイソレーションレベルにTransaction-serializableを設定し、エラー「ORA-8177」が発生した場合は、アプリケーション側で単に「異常終了」と判断するのではなく、トランザクションのロールバック後に「リトライ」させるなどの対処が必要になります。
なお、トランザクションアイソレーションレベルがTransaction-read-committed(Oracleのデフォルト)の場合は、「ORA-8177」エラーが発生することはありません。特にTransaction-serializableの設定が必須ではない場合、Transaction-read-committedを設定することにより、同時実行性が向上し、「ORA-8177」エラーも発生しなくなります。
InterstageのJNDIサービスプロバイダから取得したJDBCデータソースを使用した場合、JDBCのコネクションはプーリングされて再利用されます。
また、プーリングされているJDBCのコネクションを使用する場合、データソース単位にオプションを設定することで、まずそれが使用可能であるかを判定し、使用できないコネクションである場合には、自動的にDBMSに再接続することが可能です。
自動的に再接続することによって、DBMSが回線異常等でダウンした場合にも、IJServerを再起動することなく、アプリケーションを運用することができます。
以下に、Interstage管理コンソールを使用して設定可能なパラメタを示します。
|
パラメタ |
説明 |
設定値 |
|
事前コネクション数 (注1) |
運用で必要なコネクションを、起動時にあらかじめ取得することにより、初回疎通時から2回目以降と同等の処理速度が得られます。 |
最大値：2147483647 |
|
最大コネクション数 (注2) |
最大コネクション数を抑止することにより、メモリ資源を抑止することが可能です。 |
最大値：2147483647 |
|
コネクションタイムアウト |
最大コネクション数分のコネクションすべてが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の場合、File System Service Providerを使用してデータソースを管理します。
|
項目 |
Oracle |
PostgreSQL |
|
接続方法 |
JDBC2.X(データソース接続) |
JDBC2.0またはJDBC3.0 |
|
トランザクション種別 |
分散トランザクション機能を使用しない。 |
分散トランザクション機能を使用しない。 |
なお、Symfowareの場合は、Connection Managerの機能を使用することで、データベースサーバのダウンおよび通信回線の異常発生時にも同等の運用を行うことが可能です。
Connection Managerの詳細については、Connection Managerのマニュアル“Connection Managerユーザーズガイド”を参照してください。
DBMS異常が発生した場合のDBMSへの再接続は、プールからコネクションを取得した時、またはプールにコネクションがない場合にDBMSから直接コネクションを取得した時に行います。(DBMSへの接続を確認した時点で、トランザクションが開始し、SQL発行が可能な状態となります。)
トランザクション中で、かつコネクションを取得した後にDBMSがダウンした場合、そのトランザクション内でDBアクセス、またはEntity Bean (CMP)にアクセス(SQL発行)を行うと例外が発生します。(この際、DBMSへの再接続は行われません。)
この場合、JDBCコネクションをクローズしてトランザクションをロールバックしてから、再度処理を継続してください。(トランザクション管理種別がContainerの場合は、コンテナがロールバックを行います。)
以下に、Entity Bean (CMP)で無効なコネクションを使用した場合に発生する例外を示します。
|
メソッド |
返却される例外 |
|
create |
java.rmi.RemoteException |
|
findByPrimaryKey |
|
|
find<METHOD> |
|
|
remove |
|
|
find<METHOD>の返却値Enumerationに対するnextElementメソッド |
java.lang.RuntimeException |
|
find<METHOD>の返却値CollectionのIteratorに対するnextメソッド |
以下に、トランザクション完了時に発生する例外を示します。
|
メソッド |
返却される例外 |
|
commit |
javax.transaction.HeuristicMixedException |
|
rollback |
- |
Interstage管理コンソールでは、運用中のIJServerの稼動情報を表示します。出力される情報により、性能のボトルネックの検出や、性能チューニングの効果の確認ができます。
以下の情報が出力されます。出力される情報の詳細は、Interstage管理コンソールのヘルプを参照してください。
Interstage Traffic Directorを利用して、IJServerとWebサーバを分離して運用するシステムの負荷分散をする場合、故障監視用のコネクション(スレッド)が必要となります。
この場合、IJServerの同時処理数を設定するときは実際の同時処理数に監視用の数を考慮してください。設定は以下になります。
設定する同時処理数 = 実際の同時処理数 + 1(監視用)
なお、Interstage Traffic Directorの常設コネクション数を設定する場合は、実際の同時処理数を設定してください(監視用の数は加算しないでください)。常設コネクション数については、Interstage Traffic Directorのマニュアルを参照してください。
|
目次
索引
|
