Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP-UX   >  Knowledge-on-Demand  >  Javaパフォーマンス・チューニング

Javaパフォーマンス・チューニング

第3回:ヒープ・メモリ管理

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Javaパフォーマンス・チューニング:第3回 Javaパフォーマンス・チューニング:第3回
Javaパフォーマンス・チューニング 第3回
Javaにおけるヒープ・メモリ管理
チューニング結果の解析
ページ:  戻る   |   1   2

チューニング結果の解析


オプション-Xverbosegcを指定すると、非常に大量のログが出力されます。このログをMS Excelなどの表計算ソフトに取り込むのも1つのテクニックです。これにより、時間の経過とともにNEW領域とOLD領域が増減する様子をグラフに描くことが可能です。また、表計算ソフトを利用する以外にも、HPが提供するJavaベースのチューニング・ツールHPjtuneを使用することもできます。HPjtuneは、以下のURLから入手することができます。

HPjtuneダウンロード

ここでは簡単な例として、Java ベンチマークプログラムの1つである「SPEC JBB2000」実行時のGCによるOLD領域のサイズ変化を観察してみます。

図4:SPEC JBB2000実行時のOLD領域のサイズ変化(チューニング前)
図4:SPEC JBB2000実行時のOLD領域のサイズ変化(チューニング前)

図4は、ヒープ・サイズのチューニングを行わずにSPEC JBB2000を実行した結果です。同図を見れば、GCが頻発してOLD領域が急激に増加していることが分かります。これはNEW領域が小さすぎるためにオーバーフローが発生し、OLD領域がオブジェクトであふれている状況を示しています。また、Full GCのたびに同領域が大幅に縮小していることも分かります。つまり、短命なオブジェクトまでもがOLD領域に移動されていると推測できます(なお、OLD領域のサイズが増加傾向にあるのは、SPEC JBB2000の特性によるものです)。

一方、図5は、JVMのオプション指定により、ヒープ・サイズのチューニングを実施した後の結果です。

図5:SPEC JBB2000実行時のOLD領域のサイズ変化(チューニング後)
図5:SPEC JBB2000実行時のOLD領域のサイズ変化(チューニング後)

図4と比較すると、GCの回数も減少し、OLD領域の急激な増加も見られません。これは、NEW領域やOLD領域の拡張、およびSurvivorRatioの変更などを実施したことにより、ヒープ・メモリが理想的な利用状況に調整されたことを示しています。

以上、今回はJavaにおけるガベージ・コレクションのメカニズムを解説し、JVMオプションの指定によるチューニング方法を説明しました。次回は、JVMのスレッドによるリソース競合の解消について解説する予定です。

連載記事一覧 戻る ページ:  戻る   |   1   2

連載 「Javaパフォーマンス・チューニング」記事一覧

第1回:基本的ルール、パフォーマンス・ツールの使い方
第2回:ガベージ・コレクション
第3回:ヒープ・メモリ管理
第4回:マルチスレッドによるリソース競合
第5回:メモリ・リークの発見
第6回:メモリ・リーク解析とHotSpot JVM

 その他の連載記事


本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

HPEサポートセンター
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項