Java 仮想マシンの設定

83.29/3724.32 * 100 = 2.236%

ガーベッジ・コレクションに 5% を超える時間を費やし、ガーベッジ・コレクションが頻繁に発生している場合は、 Java ヒープ・サイズを増やす必要があります。

割り振られたヒープが増大しているかどうかを判別するには、各ガーベッジ・コレクション・サイクルの後に割り振られていない状態のヒープのパーセンテージを確認して、そのパーセンテージが減少し続けていないか検証します。フリー・スペースの パーセンテージが減少し続けている場合は、ガーベッジ・コレクション間のヒープ・サイズが徐々に増大しています。この状態は、アプリケーションにメモリー・リークが発生していることを示している可能性があります。

同期サービスのホット・リスタート同期機能を使用可能にする場合は、-DhotRestartSync を指定します。この機能は、デプロイメント・マネージャーがアクティブでない場合には 構成更新が行われない環境でインストールが実行されていることを、同期サービスに示します。 したがって、そのサービスは、デプロイメント・マネージャーまたはノード・エージェント・サーバーの再始動時に、 完全なリポジトリーの比較を行う必要はありません。 この機能を使用可能にすると、デプロイメント・マネージャーまたはノード・エージェントの再始動後の、 最初の同期操作の効率が向上します。 これは、特に混合リリース・セルを含み、複数のノードを使用して、複数のアプリケーションを実行するインストールの場合に当てはまります。

IBM SDK and Runtime Environment for AIX®, Java Technology Edition バージョン 7 で提供されている Advanced Encryption Standard (AES) 機能を使用可能にする場合は、このオプションを true に設定します。AES は、複数のラウンドによりデータの暗号化および暗号化解除を行う対称ブロック暗号です。この機能を使用可能にすることにより、WebSphere Application Server SSL 処理でのパフォーマンスが向上しました。

クラス・ロード中にクラス検証ステージをスキップする場合は、-Xverify:none を指定します。-Xverify:none を使用すると Java クラス検証を使用不可にすることができ、 起動時間が 10 パーセントから 15 パーセント改善されます。ただし、この引数を指定すると、 破損したクラス・データや無効なクラス・データは検出されません。破損したクラス・データがロードされると、JVM が 予期しない動作をしたり、JVM に障害が起きたりする可能性があります。

トラブルの回避:

• 計測エラーが発生すると JVM で障害が起きる可能性があるため、 バイトコードを変更する場合はこの引数を使用しないでください。
• この引数の使用中に JVM 障害が発生するか、 または JVM が予期しない動作をする場合は、JVM の問題をデバッグする第一段階としてこの引数を除去します。
• IBM i では、この引数はサポートされません。

gotcha

クラス・ガーベッジ・コレクションを使用不可にする場合は、-Xnoclassgc を指定します。 この引数によりクラスの再使用率が増加し、パフォーマンスが若干向上します。ただし、これらのクラスが所有する リソースは、クラスが呼び出されない場合でもそのまま使用中と見なされます。

トラブルの回避: ガーベッジ・コレクションのパフォーマンスへの影響は通常ごくわずかです。Java Platform, Enterprise Edition (Java EE) ベースのシステムでクラス・ガーベッジ・コレクションをオフにすると、アプリケーションのクラス・ローダーが頻繁に使用されるため、事実上クラス・データのメモリー・リークが発生し、JVM でメモリー不足による例外がスローされます。gotcha

ガーベッジ・コレクションをモニターする場合は、verbose:gc 構成設定を使用することができます。作成された出力を使用して、これらのリソースの再利用によりパフォーマンスに与える影響を判別することができます。

-Xnoclassgc 引数を指定する場合、アプリケーションを再デプロイするときには常に、必ずアプリケーション・サーバーを再始動して、アプリケーションの前のバージョンからのクラスと静的データをクリアする必要があります。

トラブルの回避: IBM i では、この引数はサポートされません。 このプラットフォームでクラス・ガーベッジ・コレクションを使用不可にするには、-noclassgc 引数を使用する必要があります。gotcha

一度に複数のガーベッジ・コレクション・スレッドを使用する場合は、-Xgcthreads を指定します。このガーベッジ・コレクション技法は、 パラレル・ガーベッジ・コレクション と呼ばれます。この引数は、IBM Developer Kit にのみ有効です。

この値を「汎用 JVM 引数」フィールドに入力する場合は、ご使用のマシンで実行中のプロセッサーの数も入力してください。

以下のように -Xgcthreads を指定します。

-Xgcthreads<number of processors>

トラブルの回避: -Xgcthreads とプロセッサー数の値 n の間にスペースを入れないでください。

例えば、5 台のプロセッサーで -Xgcthreads を指定する場合は -Xgcthreads5 となります。

gotcha

ベスト・プラクティス: ご使用のマシンに複数のプロセッサーが搭載されている場合は、パラレル・ガーベッジ・コレクションを使用する必要があります。bprac

トラブルの回避: IBM i では、この引数はサポートされません。gotcha

ヒープ圧縮を使用不可にする場合は、-Xnocompactgc を指定します。ヒープ圧縮は、最もコストを必要とする ガーベッジ・コレクション操作です。IBM Developer Kit を使用する場合は、 ヒープ圧縮は避ける必要があります。ヒープ圧縮を使用不可にすると、それに付随するすべてのオーバーヘッドがなくなります。

トラブルの回避: IBM i では、この引数はサポートされません。gotcha

-Xgcpolicy を指定して、 ガーベッジ・コレクション・ポリシーを設定します。この引数は、IBM Developer Kit にのみ有効です。

スループットを最適化したい場合で、 長時間のガーベッジ・コレクションの一時停止が発生しても問題ないのであれば、 この引数を optthruput に設定します。

世代的ガーベッジ・コレクターを使用する場合、この引数に gencon を設定します。この世代的な方式では、ガーベッジ・コレクションの収集休止時間を短縮するとともに、高スループットを実現します。 この目的を達成するために、ヒープは新旧のセグメントに分割されます。 存続時間が長いオブジェクトは古いスペースにプロモートされますが、存続時間が短いオブジェクトは新規スペースに格納されて短時間にガーベッジ・コレクションが実行されます。 gencon ポリシーは多くのアプリケーションにとって大きなメリットを提供します。ただし、すべてのアプリケーションにとって適切なわけではなく、一般に調整が難しくなります。

ヒープがいっぱいになる前に、スタックから開始されるアプリケーション・スレッドを追跡するのに並行マーキングを使用する場合は、この引数に optavgpause を指定します。このパラメーターが指定されると、 ガーベッジ・コレクターの一時停止は均一になり、長時間の一時停止は発生しなくなります。 ただし、このポリシーを使用するとスレッドが追加の作業を実行する必要がある場合があるため、スループットは低下します。

一般に使用プロセッサー数が 8 つを超えるマルチプロセッサー・システムでパフォーマンスを向上させる場合、 この引数に subpool を設定します。このポリシーは IBM System i®、System p®、および System z® の各プロセッサーでのみ、使用できます。subpool ポリシーは optthruput ポリシーと似ていますが、ヒープがサブプールに分割されて、オブジェクト割り振りのスケーラビリティーが改善される点が異なります。

トラブルの回避: IBM i では、この引数はサポートされません。gotcha

Java Platform, Standard Edition 6 (Java SE 6) には、 生成ガーベッジ・コレクションが備えられています。これにより、存続期間が異なるオブジェクトを個別のメモリー・プールに組み込むことができます。 ガーベッジ・コレクション・サイクルでは、存続期間に応じて、相互に独立してオブジェクトを収集します。 追加パラメーターを使用することで、メモリー・プールのサイズを個々に設定できます。 より良好なパフォーマンスを達成するには、ライフサイクルの短いオブジェクトを含むプール・サイズを設定します。 これにより、プール内のオブジェクトが複数のガーベッジ・コレクション・サイクルに渡って存続することがなくなります。 NewSize および MaxNewSize パラメーターを使用して、 新規世代プールのサイズを指定します。

-XX:NewSize=lower_bound
-XX:MaxNewSize=upper_bound
 -XX:SurvivorRatio=new_ratio_size 

ベスト・プラクティス: ただし、JVM のヒープ・サイズが 1 GB を超える場合は、以下の値を使用する必要があります。

• -XX:NewSize=640m
• -XX:MaxNewSize=640m
• -XX:SurvivorRatio=16

bprac

あるいは、総ヒープ・サイズの 50% から 60% を新世代プールに設定することが可能です。

トラブルの回避: IBM i では、この引数はサポートされません。gotcha

最低フリー・ヒープ・サイズのパーセンテージを変更する場合は、-Xminf を指定します。フリー・スペースが指定量よりも少ない場合、 ヒープは大きくなります。リセット使用可能モードでは、 この引数によりミドルウェアおよび一時的ヒープのフリー・スペースの最小パーセンテージが指定されます。 この引数に指定される値は浮動小数点数で、0 から 1 の間の値です。 デフォルトは .3 (30%) です。

トラブルの回避: IBM i では、この引数はサポートされません。gotcha

Java SE 6 の Java HotSpot Technology では、時間と共にバイトコードの実行方法を最適化するアルゴリズムを含む最適な JVM を使用します。 JVM は、-server および -client の 2 つのモードで実行します。 ほとんどの場合、-server モードを使用します。これにより、長期間にわたるランタイム実行の効率を向上させることができます。

デフォルトの -client モードを使用する場合は、 サーバー起動時間が短縮され、作成されるメモリーのフットプリントが減少します。 ただし、このモードでは拡張パフォーマンスは低下します。サーバーの起動時間よりパフォーマンスが優先される場合は、-server モードを使用するとパフォーマンスが向上します。プロセス・サイズおよびサーバー起動時間をモニターして、-client モードと -server モードを使用した際のパフォーマンスの違いを確認することができます。

トラブルの回避: IBM i では、この引数はサポートされません。gotcha

-Dcom.ibm.CORBA.RequestTimeout= timeout_interval 引数を指定して、 クライアントから送信された要求に応答するタイムアウト期間を設定します。 この引数は、-D オプションを使用します。timeout_interval は秒単位のタイムアウト期間です。 ネットワークで極端な待ち時間が発生している場合は、タイムアウトを防ぐために大きい値を指定します。 指定した値が小さ過ぎると、 ワークロード管理に関与するアプリケーション・サーバーが応答を受け取る前にタイムアウトになる可能性があります。

アプリケーションでタイムアウトの問題が発生した場合にのみ、この引数を指定してください。この引数に推奨値はありません。

-Dcom.ibm.server.allow.sigkill=true 引数により、ノード・エージェント・プロセスは、Ping 間隔に指定された時間内に stop メソッドが完了しない場合に、プロセスの terminate メソッドを使用することができます。 この設定は、ノード・エージェントがアプリケーション・サーバーをモニター中に、そのアプリケーション・サーバーとの接続が失われた場合に便利です。

アプリケーション・サーバーに自動再始動が有効に設定されているため、アプリケーション・サーバーのモニター・ポリシーにより、ノード・エージェントがアプリケーション・サーバーの再始動を許可されると、ノード・エージェントはアプリケーション・サーバー・プロセスに対して stop メソッドを実行します。 停止処理の間、ノード・エージェントはアプリケーション・サーバーをモニターします。そして、アプリケーション・サーバーが Ping 間隔に指定された時間内に停止しない場合に、この引数が true (これがデフォルト値) に設定されていると、ノード・エージェントはアプリケーション・サーバー・プロセスに対して terminate メソッドを実行して、 アプリケーション・サーバーのプロセスを停止させます。

この引数を false に設定している場合、ノード・エージェントは stop プロセスのモニターを継続しますが、アプリケーション・サーバーの再始動は試みません。

管理コンソールを使用してこの引数を使用不可に設定するには、 「システム管理」>「ノード・エージェント」>「nodeagent_name」 > 「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」>「汎用 JVM 引数」をクリックします。

この引数は、アラームがシステム・ログのハング・スレッド・メッセージ内の完全なスタック・トレースを報告する最大回数を指定します。

システムのアラーム・スレッドがアクティブである時間が、アラーム・スレッド・モニターのしきい値より長い場合、アプリケーション・サーバーは、アラーム・スレッドの名前、アラーム・スレッドがアクティブになっている時間の長さ、および完全な例外スタック・トレースと共にハング・スレッド・メッセージをログに記録します。完全なスタック・トレースは、遅延の原因をデバッグするには役立ちますが、ハング・スレッド・メッセージが頻繁にトリガーされる場合は、長メッセージが繰り返されることで、システム・ログ内の他の情報を見つけにくくなる可能性があります。この引数を 0 より大きい整数に設定して、1 つのアラームがその完全なスタック・トレースを報告する最大回数を指定してください。回数がこのしきい値に達すると、それ以降の各ハング・スレッド・メッセージには、ハング・アラーム・ハンドラーのエントリーのみが含まれます。

デフォルト値の 0 は、アラームのすべてのハング・スレッド・メッセージに完全なスタック・トレースが含まれることを示します。

native_stdout および native_stderr ログ・ファイルに出力されるすべてのサーバー・デバッグ・メッセージの前にタイム・スタンプとスレッド ID を追加するには、この引数を指定します。そのタイム・スタンプとスレッド ID を使用して、アプリケーション・サーバー・ブートストラップ・コンポーネントの動作を他のサーバー・メカニズムの動作と相互に関連付けることができます。この相関は、SystemOut および SystemErr ログ・ファイル内に示されます。デフォルトでは、この動作は使用不可となっています。

汎用 JVM 引数 -Dws.ext.debug=true を使用してサーバーが構成されている場合、そのサーバーは、ブートストラッピング・シーケンス中に、デバッグ・メッセージを native_stdout.log および native_stderr.log に発行します。また、-Dcom.ibm.websphere.native.logging.timestamp も true に設定されている場合、以下の例に示すように、サーバーはデバッグ・メッセージをタイム・スタンプとスレッド ID と共に出力します。

[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[0]=-nosplash
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[1]=-application
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[2]=com.ibm.ws.bootstrap.WSLauncher
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[3]=com.ibm.ws.runtime.WsServer

この引数は z/OS の場合にのみ適用されます。クライアントのワークロード管理状態のリフレッシュが早過ぎるかまたは遅過ぎる場合は、-Dcom.ibm.websphere.wlm.unusable.interval= timeout_interval 引数を指定して、com.ibm.websphere.wlm.unusable.interval プロパティーの値を変更します。 このプロパティーでは、ワークロード管理クライアント・ランタイムが、サーバーを使用不可とマークした後、 再度そのサーバーへの接続を試みるまでの間の待機時間を秒単位で指定します。この引数は、-D オプションを使用します。デフォルト値は 300 秒です。このプロパティーが大きい値に設定されると、 サーバーは長時間使用不可であるとマークされます。 これで、ワークロード管理リフレッシュ・プロトコルが、 この時間枠が終了するまではクライアントのワークロード管理状態をリフレッシュ しないようになります。

この引数は z/OS の場合にのみ適用されます。-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= 引数を指定して、 バッファーが不要になった直後に、個別に直接バイト・バッファーのストレージを解放する必要があることを示します。 この引数でサポートされる値は、com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl のみです。

-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

z/OS プラットフォームの場合は、新規接続で使用される初期読み取りバッファーが接続に必要ではなくなった直後に、 チャネルがこれらのバッファーをリリースするために、TCP チャネルの zaioFreeInitialBuffers カスタム・プロパティー を指定する場合にも、この引数を指定する必要があります。

SIP 準拠検査が SIP プロキシー・サーバーで有効になっているかどうかを指定します。SIP 準拠検査により、SIP メッセージが Session Initiation Protocol 標準に準拠するようにします。このプロパティーが true に設定されると、SIP 準拠検査が使用可能になります。

トラブルの回避: z/OS WebSphere Application Server Network Deployment 環境でプロキシー・サーバーを実行していて、プロキシー・サーバーがクラスターの一部でない場合、 isSipComplianceEnabled SIP プロキシー・サーバー・カスタム・プロパティーを使用して、その SIP プロキシー・サーバーに対して SIP 準拠検査を使用可能または使用不可にします。ただし、スタンドアロン・アプリケーション・サーバーを実行しているか、プロキシー・サーバーがクラスターの一部である場合、 この汎用 JVM 引数を使用して、SIP 準拠検査を使用可能または使用不可にする必要があります。gotcha

-Xshareclasses:none 引数を指定して、プロセスの共有クラス・オプションを使用不可にします。 Java SE 6 で使用可能な共有クラス・オプションにより、キャッシュでクラスを共有できます。キャッシュでクラスを共有すると、起動時間が短縮され、メモリー占有スペースを縮小できます。 アプリケーション・サーバー、ノード・エージェントおよびデプロイメント・マネージャーなどのプロセスは、この共有クラス・オプションを使用できます。

このオプションを使用すると、プロセスを使用していない場合にキャッシュをクリアする必要があります。 キャッシュをクリアするには、app_server_root/bin/clearClassCache.bat/sh ユーティリティーを呼び出すか、プロセスを停止してからそのプロセスを再始動します。

トラブルの回避:

• IBM JVM for J2SE 5 は、 Solaris、HP、および IBM i ではサポートされません。
• アプリケーション・サーバー・プロセスで稼働中の Java EE アプリケーション・クラスは、共有クラス・キャッシュには追加されません。

gotcha

-XXallowvmshutdown:false 引数を使用すると、正しくない JVM の前の動作に戻ります。 Java 5.0 SR10 および Java 6 SR5 は、Java 仮想マシン (JVM) が適切にシャットダウンしない問題を修正します。以前の動作に依存するアプリケーションがある場合は、この引数を汎用 JVM 引数セクションに追加することで前の動作に戻ることができます。