Sun Application Server のチューニング

最新の『Sun Java System Application Server パフォーマンスのチューニングガイド』の「アプリケーションサーバーのチューニング」の章では、Sun Java System Application Server のチューニング方法について説明しています。このドキュメントは、次の URL から入手できます。http://docs.sun.com/app/docs

また、Sun Application Server 8.2 Enterprise Edition をお使いの場合は、次のように変更すれば「並列モードのエラー」が解決され、パフォーマンスが改善され予測しやすくなるはずです。

• 古い世代のコレクションを常に実行している場合は、アプリケーションのヒープ面積を見直し、このサイズを増やしてみてください。たとえば、次のようにします。

  • 500M バイトは小さめなサイズですので、この値を 3G バイトに増やせば向上する場合があります。

  • 若い世代コレクションが 2G バイトの場合、スカベンジするたびに約 70M バイトをプロモートします。スカベンジを少なくとも 1 回行うと 70M バイトをプロモートするということを念頭に置いてください。たとえば、次の SurvivorRatio が必要になることがあります。

    2 G バイト/70 M バイト X 2 = 4096/70 = 55

    ここで、次のように設定します。

    -XX:SurvivorRatio=32 -XX:MaxTenuringThreshold=1

    この比率に設定すれば、早すぎるプロモートを防ぐことができ、またスカベンジパフォーマンスの低下の原因となりうる「偏り」も防ぐことができます。

• -XX:CMSInitiatingOccupancyFraction=60 と設定しておけば、CMS コレクションがこのしきい値に達するまで起動したままになります。たとえば、次のようにします。

  56402.647: [GC [1 CMS-initial-mark: 265707K(1048576K)] 1729560K(3129600K), 3.4141523 secs]

  -XX:CMSInitiatingOccupancy=60 を削除し (デフォルト値の 69% を使用)、次の行を加えます。

  -XX:UseCMSInitiatingOccupancyOnly

• 若い世代のコレクションが 2G バイトで、古い世代のコレクションが 1G バイトの場合でも、早すぎる CMS コレクションが行われてしまうことがあります。この比率を逆転してみてください。次のように、若い世代のコレクションを 1 G バイト、古い世代のコレクションを 2 G バイトに設定します。

  -Xms3G -Xmx3G -Xmn1G

  また、-XX:NewRatio を削除します。若い世代と全体のヒープサイズを明示的に指定していた場合は、この比率は余分です。

• Java 開発キット (JDK^TM ソフトウェア) の 5uXX バージョンを使用していて、過度に長すぎる「abortable preclean」サイクルがある場合は、一時的な回避策として -XX:CMSMaxAbortablePrecleanLoops=5 を使用することができます。

この値は、さらに調整する必要があります。

• ガベージコレクタのパフォーマンスの詳細を表示するには、次の行を追加します。

  -XX:+PrintHeapAtGC

  ---

  注 –

  冗長的なガベージコレクションデータの生成量が増えるので、このコマンドは慎重に使用してください。ガベージコレクタの出力の保存先に十分なディスク空き容量があることを確認してください。

  ---

• Sun Fire^TM T2000 サーバーを使用している場合は、DTLB (Data Translation Look-aside Buffer) のヒープが大きいとリソースが不足してしまうことがあります。Java ヒープに大きなページを使用することでパフォーマンスに役立つことがよくあります。たとえば、次のようにします。

  -XX:+UseLargePages