IBMのWASはJVMやGCをどのように扱っているのか？：WebSphereサーバ・チューニング入門（3）（4/4 ページ）

» 2007年08月02日 00時00分公開

[上野憲一郎，日本アイ・ビー・エム]

GCチューニングのための標準ツール：GCログ

　CGのチューニングを実施するために、広く一般に使われているものとして、GCログがあります。これは、汎用のJVMランタイムが提供するもので、javaコマンドの“-verbose:gc”オプションを指定することにより取得できます。

　WASのJVMランタイムに対しては、WAS管理コンソール上で「冗長GC」を指定することにより設定できます（図13参照）。

　冗長GCを指定すると、native_stderr.logにGCの情報が記録されます。以下に、“-Xgcpolicy:optthruput”“-Xgcpolicy:optavgpause”“-Xgcpolicy:gencon”の3つのオプションごとのサンプル・ログを載せます。

図15　-Xgcpolicy:optthruput指定時のGCログ（画像をクリックすると拡大します）

図16　-Xgcpolicy:optavgpause指定時のGCログ（画像をクリックすると拡大します）

図17　-Xgcpolicy:gencon指定時のGCログ（画像をクリックすると拡大します）

　このように、“-verbose:gc”オプションを指定することにより、GCに関する情報が取得できるので、GC発生頻度やGCに費やした時間を確認しながら、適切なオプションを見つけ出していくことになります。

　WAS 6.1のIBM JVMの「メモリ管理機能の強化」についての解説は以上です。

【2】ヒープメモリ・フラグメンテーションに対する改善

　WAS 6.0（およびそれ以前）のJVMでは、ヒープメモリ・フラグメンテーションが発生する場合があります。

ヒープメモリ・フラグメンテーションとは？なぜ起こる？

　ヒープメモリ・フラグメンテーションは、ヒープ領域に断続的な空きスペースが存在するにもかかわらず、オブジェクトが個々の空きスペースよりも大きな領域を必要とした場合に、JVMが十分な空き領域を見つけられず、OutOfMemoryエラーを発生させる可能性があります。

　“Pinned Object”（JNIから参照されているオブジェクト）および“Dosed Object”（スタックから参照されているオブジェクト）と呼ばれるオブジェクトは、動かすことができず、これらオブジェクトがヒープに存在することにより、このフラグメンテーションが発生します。

図18　Pinned Objectによるメモリ・フラグメンテーション

ヒープメモリ・フラグメンテーションへの対応策（6.0以前）

　対応策として、専用のプールを用意し（-Xkおよび-Xpオプションで指定）、これら動かすことのできないオブジェクトを、そこに配置することにより、ヒープのフラグメンテーションを防ぐという方法を取っていました（参照：「Heap fragmentation with IBM 1.3.1 and 1.4.2 JVMs」）。

図19　kCluster／pClusterの指定によるメモリ・フラグメンテーションの防止

ヒープメモリ・フラグメンテーションへの対応策（6.1から）

　WAS 6.1のIBM JVMは、“Type Accurate” Garbage Collectorを採用することにより、スタックにあるデータがポイントしているものが、オブジェクトなのかノン・オブジェクトなのかを区別できるようになりました。これにより、“Pinned Object”および“Dosed Object”の問題を解決し、ヒープメモリ・フラグメンテーションの発生を抑制できるようになりました。

【3】Shared Classesサポート

Shared Classesの利点

　Shared Classesは、複数のJVM（WASインスタンス）を同一マシン上で稼働させる場合に、以下のことが可能になります。

スタティック・クラスを共有メモリ内のキャッシュに共有することにより、仮想メモリの大幅な削減
JVM（WAS）の起動時間の大幅な削減

　そして、“-Xshareclasses:＜cacheName＞”オプションを指定することにより利用可能です。例えば、「-Xshareclasses:mycache」というような指定になります。

キャッシュを廃棄する方法

　使用されていないキャッシュを廃棄する方法として、指定時間以上使われていなかった場合に削除する方法と明示的に削除する方法が提供されています。

　前者の例としては、「-Xshareclasses:mycache,expire=10000」というような指定（単位は分）になります。後者の例としては、-Xshareclasses:destroyAll（すべてのキャッシュを廃棄）、あるいは、-Xshareclasses:destroy,name=mycache（指定したキャッシュのみを廃棄）という指定になります。

キャッシュサイズを指定する方法

　また、-Xscmxオプションでキャッシュサイズを指定できます。例えば、-Xscmx20mというような指定になります。

チューニングには調査と解析の“繰り返し”が必要

　今回は、WAS 6.1に含まれるIBM JVMのチューニングについて、GCの解説を中心にお話ししました。どのCG方式が最適であるかは、使用するWASの機能およびアプリケーションによって異なります。

　従いまして、何度かテストを繰り返しながら、初期ヒープ・サイズおよび最大ヒープ・サイズの調整、GC方式の選択、各GC方式に応じたオプションの指定（“-Xgcpolicy:gencon”指定時の“-Xmn”オプションなど）などを行うことになります。その際には、“-verbose:gc”オプション（冗長GC）を指定して、native_stderr.logに記録されるGCログを取得し、その解析を実施します。そして、解析結果を基に、JVMの調整を再度行うという“繰り返し”が必要です。

　また、WAS 6.1では、以前のバージョンで問題であったメモリ・フラグメンテーションの改善や、Shared Classesのサポートにより、複数WASインスタンスを同一マシン上で稼働させる場合のメモリ使用量の抑制およびWASの起動時間の大幅な削減が実現可能となりました。

参考文献

＠IT関連記事

Javaパフォーマンスチューニング
JVMレベルにとどまらず、OSのカーネル・パラメータやネットワーク・パラメータのレベルでのチューニングを6回の連載で紹介する
第1回 Javaパフォーマンスチューニングのルール
 第2回 Javaのガベージ・コレクションを知る
 第3回 Javaのヒープ・メモリ管理の仕組み
 第4回 Javaのマルチスレッドによるリソース競合から守る
 第5回 Javaアプリのメモリ・リークを発見する
 第6回 HotSpot VMの特性を知る
連載各回の解説はこちら

チューニングのためのJava VM講座
パフォーマンスチューニングに関わるエンジニアのためのJava VM講座。2回に渡ってHotSpot VMの基礎知識を解説します
前編 HotSpot VMの基本構造を理解する
 後編ガベージコレクタの仕組みを理解する
連載各回の解説はこちら

現場から学ぶWebアプリ開発のトラブルハック
現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集
第2回　“Stop the World”を防ぐコンカレントGCとは？
第5回　OutOfMemoryエラー発生!? GCがあるのに、なぜ？
連載各回の解説はこちら

メモリは足りているのに“OutOfMemory”のなぞ
[連載]事例に学ぶWebシステム開発のワンポイント(9) メモリが足りているのに、OutOfMemoryのエラーに悩まされるケースは多い。いくつかの原因とその解決法を紹介
「Java Solution」フォーラム 2003/2/15

プロフィール

日本アイ・ビー・エム東京基礎研究所　アドバイザリー・リサーチャー

上野憲一郎（うえのけんいちろう）
kenueno@jp.ibm.com

日本アイ・ビー・エムに入社後、システム・エンジニアとして10年ほど活動した後、米国IBMへ赴任。米国IBM Raleighソフトウェア開発研究所にて、WebSphere Application Server開発部門のパフォーマンス専門グループのメンバーとして活動。2003年に帰国後、IBM東京基礎研究所にて、XML、Web サービス、SOA関連技術の研究開発に従事。WebSphere Application Serverパフォーマンス専門家として、セミナーなどで講演も実施。

主な著書
「WebSphere V3.5 Handbook」（Prentice Hall）

主な訳書
「Webサービスプラットフォームアーキテクチャ」（エスアイビーアクセス）

「次回」へ

「WebSphereサーバ・チューニング入門」バックナンバー