“Stop the World”を防ぐコンカレントGCとは?:現場から学ぶWebアプリ開発のトラブルハック(2)(2/2 ページ)
本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。(編集部)
コンカレントGCのチューニング
本稿で対象とするJava VMはJava SE 5.0 Update11とする。バージョンにより挙動が異なる場合もあるので、実際に使用するときには動作を確認しつつ使用してもらいたい。
■GC方式を指定する
コンカレントGCを使用するには、Java VMの起動時に表1のオプションを指定する。
オプション | 意味 | |
---|---|---|
-XX:+UseConcMarkSweepGC | コンカレントGCの有効化 |
さらに、表2のパラメータを状況に応じて追加する。
オプション | 意味 | |
---|---|---|
-XX:+CMSParallelRemarkEnabled | メジャーGCのRemarkフェイズをマルチスレッドで実行 | |
-XX:+UseParNewGC | マイナーGCをマルチスレッドで実行 |
この表2のパラメータは、動作させるマシンのCPUが2個以上かつ物理メモリが2Gbytes以上の場合には、自動設定される。
■Heapの全体サイズを指定する
コンカレントGCでも、スループットGCと同じくHeapの全体サイズを指定する。ヒープの全体サイズは、以下を考慮に入れて設定する。
- OSの空きメモリ量
Heapの全体サイズは、ハードウェアの搭載物理メモリ量から、OSやそのほかのソフトウェアが必要とするメモリ量を引いた値以下にする。これは、Heapのサイズを大きくし過ぎると、スワップが発生し大幅に性能が劣化するためだ - アプリケーションが必要とするメモリ量
ユーザーごとにHttpSessionに積み込むオブジェクトのサイズや、キャッシュされたオブジェクトのサイズなど、必要となるオブジェクトのサイズを積算し、それ以上の値にする
実際には、アプリケーションが必要とするメモリ量を積算することは難しい。OSの空きメモリ量を基に概算で設定し、負荷試験を行いながらメモリがオーバーしていないことを確認していくケースが多い。
Heapの全体サイズは、スループットGCと同じ表3のオプションで設定する。
オプション | 意味 | デフォルト値 | |
---|---|---|---|
-Xms | Heapの最小値を指定。-Xms1024mのように、Mbyte単位での指定も可能 | 2Mbytes | |
-Xmx | Heapの最大値を指定。-Xmx1024mのように、Mbyte単位での指定も可能 | 64Mbytes |
最小値=最大値とすることで、動的なHeapの拡大・縮小に伴う性能劣化を防ぐことが可能だ。試してみてほしい。
■New世代領域のチューニング
コンカレントGCにおいてマイナーGCを有効活用するため、表4のオプションを変更する。
オプション | 意味 | デフォルト値 | |
---|---|---|---|
-Xmn(-XX:NewSize)、 -XX:NewRatio |
New世代領域に割り当てるサイズを指定。NewRatioはOld世代領域との比率で指定し、NewSizeはサイズで指定 | -XX:NewRatio=12 | |
-XX:SurvivorRatio | Eden領域とSurvivor領域のサイズを比率で指定 | コンカレントGCを使用すると、1024 | |
-XX:MaxTenuringThreshold | New世代領域において、オブジェクトがこの値で指定する回数のマイナーGCを超えて生き残ると、Old世代領域に移動 | コンカレントGCを使用すると、0 | |
-XX:TargetSurvivorRatio | Survivor領域がいっぱいと判断される使用率 | 50% |
具体的にどのような数値に変更すればよいかは、アプリケーションの作りや環境によって異なる。そこで、以下では簡単なベンチマークを実施して、コンカレントGCの有効性について確認してみよう。
対決! GCパフォーマンス測定!!
以下の3つのパターンで性能を比較してみよう。
- スループットGC
- コンカレントGC(New世代領域のチューニングなし)
- コンカレントGC(New世代領域のチューニングあり)
なお、ベンチマークにはIPAのOSS活用整備基盤事業で開発したJBentoStoreを使用した。
■ベンチマーク環境
ベンチマークは表5に示す環境上で行った。
CPU | Intel Pentium 4 3.2Gbytes | |
メモリ | 2Gbytes | |
OS | Red Hat ES4 U3 | |
Java VM | Java SE 5.0 Update11 | |
APサーバ | Tomcat 5.5.23 | |
評価対象ソフトウェア | JBentoStore 1.0 |
指定したJVMパラメータは、以下のとおり。
- スループットGC
-server -Xmx1024m -Xmx1024m -Xmn=256m - コンカレントGC(New世代領域のチューニングなし)
-server -Xms1024m -Xmx1024m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC - コンカレントGC(New世代領域のチューニングあり)
-server -Xms1024m -Xmx1024m -Xmn256m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=32 -XX:TargetSurvivorRatio=90
■測定結果はいかに!?
スループットと平均応答時間のグラフを図4、図5に示す。
New世代領域チューニングなしのコンカレントGCでは、150クライアントまではそのほかのGCと同じ性能だが、200クライアント時に13%程度スループットが劣化した。一方、チューニングを行ったコンカレントGCはスループットGCに対して、性能劣化が殆どない。
このように、マイナーGCを使用するようにチューニングされたコンカレントGCは、理想的な性能を満たしている。
コンカレントGCは現場で使えるレベルに成熟
本記事では、マイナーGCをうまく活用するコンカレントGCの仕組みや設定について解説し、またベンチマーク結果も示した。コンカレントGCは比較的新しく出てきたGC方式であり、その使用に不安を感じる人もいるかもしれない。しかし、本記事で紹介したチューニングを行えば、十分に使いこなせるはずだ。
筆者は、コンカレントGCがすでに現場で使えるレベルに成熟していると考えている。Full GCに悩んでいる方は、コンカレントGCの導入を検討してみてはいかがだろうか。
プロフィール
金子 崇之(かねこ たかゆき)
NTTデータ先端技術株式会社 オープンソース事業部所属。
入社よりJavaを用いたWebシステムの開発支援にかかわる。最近では、主にオープンソースのアプリケーションサーバに関する検証や技術支援、トラブルシューティングに明け暮れている
- 数百キロのコードでブルー - ドクターTomcat緊急救命
- DB操作の“壁”を壊すJPAが起こした「赤壁の戦い」
- アプリ開発でも、よ〜く考えよう。キャッシュは大事だよ
- スレッドダンプの森で覚えた死のロックへの違和感
- ThreadとHashMapに潜む無限回廊は実に面白い?
- JavaのGC頻度に惑わされた年末年始の苦いメモリ
- 肥え続けるTomcatと胃を痛めるトラブルハッカー
- 【トラブル大捜査線】失われたコネクションを追え!
- 【真夏の夜のミステリー】Tomcatを殺したのは誰だ?
- OutOfMemoryエラー発生!? GCがあるのに、なぜ?
- DBアクセスのトラブルは終盤で発覚しがち……
- 【実録ドキュメント】そのログ本当に必要ですか?
- “Stop the World”を防ぐコンカレントGCとは?
- Webアプリの問題点を「見える化」する7つ道具
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- HotSpot VMの基本構造を理解する
チューニングのためのJava VM講座(前編) パフォーマンスチューニングに関わるエンジニアのためのJava VM講座。2回に渡ってHotSpot VMの基礎知識を解説します - 実行速度に挑戦してきたJava VMの歴史
Javaの歴史は実行速度向上の歴史でもあった。今日のJava VMが完成するまでのアーキテクチャの変遷を振り返ることで、Java VMの理解をより深めることができる - 事例に学ぶWebシステム開発のワンポイント
現場のエンジニアの経験から得られた、アプリケーション・サーバをベースとしたWebシステム開発におけるノウハウ、注意点について解説 - 第1回 クラスタ化すると遅くなる?(2002/3/9)
- 第2回 キャッシュが性能劣化をもたらす謎を解く(2002/3/23)
- 第3回 クラスタは何台までOK?(2002/4/19)
- 第4回 マルチスレッドのいたずらに注意(2002/5/14)
- 第5回 クラスタによるアプリケーションの動的アップデート(2002/6/4)
- 第6回 APサーバからの応答がなくなった、なぜ?(2002/11/30)
- 第7回 低負荷なのにCPU使用率が100%?(2002/12/11)
- 第8回 文字化け“???”の法則とその防止策(2003/1/28)
- 第9回 メモリは足りているのに“OutOfMemory”のなぞ(2003/2/15)
- 第10回 レスポンスキャッシュでパフォーマンス向上(2003/3/29)
- 第11回 JDBC接続を高速化―PreparedCacheの活用(2003/4/18)
- 第12回 ブラウザキャッシュでパフォーマンス向上(2003/5/10)
- 第13回 ファイルアップロード/ダウンロードに潜むわな(2003/6/12)