パフォーマンスのボトルネックの特定

設計段階で潜在的なボトルネックを特定することで、ポータルのパフォーマンスニーズを計画することができます。

メモリー消費と、パフォーマンスに与えられる影響に関するセクションに進む前に、Java 仮想マシンのバージョン 1.4.2 のチューニングに関するマニュアルを一読してください。Sun Java System Application Server または Sun Java System Web Server に配備する場合、Java 仮想マシンはバージョン 1.5 になります。ただし、サードパーティーの Web コンテナに配備する場合は、バージョン 1.4.2 を使用することもできます。

http://java.sun.com/products/hotspot/index.html

メモリー消費とガベージコレクション

Portal Server では、可能なかぎり最高のスループットを実現するために、かなりの量のメモリーが必要になります。初期化時に、最大アドレス領域が実質的に確保されますが、必要でないかぎり物理メモリーは割り当てられません。オブジェクトメモリー (ヒープ) 用に確保したアドレス領域全体は、新世代 (eden) と旧世代 (tenured) に分割できます。その名の通り、新世代とは新たに作成された Java オブジェクトであり、旧世代とは現存の Java オブジェクトに割り当てられた空間を指します。

ほとんどのアプリケーションでは新世代用にヒープ全体のかなりの割合を使用するように勧めていますが、Portal Server では、Portal Server が使用するメモリーの大半は長期的に使用されるので、新世代用の領域の 1/8 のみを使用するのが適切です。メモリーを旧世代にコピーするのが早いほど、ガベージコレクション (Garbage Collection、GC) のパフォーマンスは向上します。

デフォルトでは、ヒープのサイズが大きい場合でも、ポータルインスタンスが中程度の負荷で数日間実行されたあとは、GC の遅れによりほとんどのヒープが使用されたように見えます。GC は、常駐セットサイズ (RSS) がヒープ領域全体の約 85 パーセントに達するまで完全なガベージコレクションを実行します。85 パーセントに達すると、ガベージコレクションがパフォーマンスにある程度の影響を及ぼすことがあります。

たとえば、900MHz UltraSPARCIII^TM では、2G バイトのヒープに対するフル GC には10 秒を超えることがあります。その間、システムは Web 要求に応答できません。信頼性のテスト時に、フル GC は応答時間の急激な上昇としてはっきり目に見えるようになります。本稼働時には、ほとんどの場合フル GC が認識されることはありませんが、システムのパフォーマンスを測定する監視スクリプトはフル GC が発生する可能性があることを考慮する必要があります。

フル GC の頻度を測定するのが、Web コンテナにメモリーリークが発生していることを確認する手段となる場合があります。(基準システムの) 予測頻度を示す分析を行い、その結果を観測したフル GC の頻度と比較します。GC の頻度を記録するには、vebose:gc JVM^TM パラメータを使用します。