連載
» 2007年04月24日 00時00分 公開

現場から学ぶWebアプリ開発のトラブルハック(2):“Stop the World”を防ぐコンカレントGCとは? (1/2)

本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。(編集部)

[金子崇之,NTTデータ先端技術]

Full GC問題の時代が再び到来!

 それまで順調に動いていたはずのWebアプリケーションが、ある時突然、応答を返さなくなる。そして、運用者があたふたしている間に、何事もなかったかのように再び動き出す。

 Javaで構築したシステムにかかわる者ならば誰しもが体験するであろう事象、そうFull GC(ガベージ・コレクション)だ。Full GCが行われている間、すべてのアプリケーションスレッドは停止する。この事象は“Stop the World”とも呼ばれている。

 Full GCに対しては、世代別GCを適切にチューニングし、発生回数を減らす事で対処してきた。しかし、世代別GCのチューニングでは、Full GC1回当たりの停止時間を短くできない。サーバに搭載されるメモリが数Gbytesを超えるのが当たり前になってきた現在では、Javaに指定するHeapサイズも1Gbyteを超えるケースが出てきている。そのためHeapサイズの巨大化に伴い、Full GC時間が無視できなくなってきている。

 本稿では、Full GC時間を改善するための手段となる「コンカレントGC」について解説する。

ガベージ・コレクションにもいろいろある

従来のGC=世代別GCとは?

 コンカレントGCの解説の前に、従来の世代別GCについて簡単に振り返っておこう。世代別GCは、Java VMのHeap領域をNew世代Old世代に分け、オブジェクトの生存期間に応じてGCを効率化する。生成された後、すぐに不要となる短命オブジェクトをNew世代領域で回収し、比較的長い期間必要となる長命オブジェクトをOld世代領域で長期的に管理する。

 例えば、Webアプリケーションでは、以下のようにオブジェクトを分類できるだろう。

  • 短命オブジェクト
    • レスポンス返却後は不要となるオブジェクト。例えば、リクエストパラメータとなるStringオブジェクトや、ServletRequestに格納されたオブジェクト
  • 長命オブジェクト
    • HttpSessionに格納されたオブジェクト
    • ServletContextClassのstatic領域などに格納されたキャッシュ的なオブジェクト

Old世代のGC(メジャーGC=Full GC)とNew世代のGC(マイナーGC)

 New世代のGC(マイナーGC)には、高速なCopy方式のGCが使用される。一方、Full GCとも呼ばれるOld世代のGC(メジャーGC)にはMark-Sweep-Compact方式のGCが使用される。Mark-Sweep-Compact方式のGCは、その名のとおり、以下の流れで処理を行う。

  • 生存中のオブジェクトをすべてマーキング(Mark
  • マークが付いていないオブジェクトを除去(Sweep
  • 空き領域を確保するためのオブジェクトのHeap内再配置を行う(Compact

 メジャーGCはコストが高く、時間がかかってしまう。

図1 従来のGC(スループットGC) 図1 従来のGC(スループットGC)

 これらのGCは、高速化のために複数のスレッドで実行することもでき、それらはパラレルGCと呼ばれている。しかし、いくら複数のスレッドでGCを実行しても、その間すべてのアプリケーションのスレッドは停止される。

 本稿ではコンカレントGCと区別するために、従来の世代別GCを「スループットGC」と呼ぶ。

コンカレントGCとは?

 コンカレントGCはJ2SE 1.4から使用できるGC方式で、Old世代のGCをアプリケーションスレッドと並列に実行する。

 しかし、GCのアルゴリズム上、すべてのアプリケーションスレッドを停止する必要のある期間がどうしても存在する。コンカレントGCでは、GCを次の4つのフェイズに分割して処理することで、その期間を最小化している。

図2 コンカレントGCの4つのフェイズ 図2 コンカレントGCの4つのフェイズ
  • Initail Mark
    • 生存オブジェクトをたどるための出発点(root)となるオブジェクトをマークする。rootとなるオブジェクトは限られているため、マーキングはすぐに終了
    • すべてのアプリケーションスレッドを停止させる必要がある
  • Concurrent Mark
    アプリケーションスレッドと並列に、rootからたどれるオブジェクトに対してマーキングを進める。並列に実行しているため以下のような状況が発生
    • マークしたオブジェクトに新たにオブジェクトの参照が追加され、生存しているのにマークされていないオブジェクトが存在
    • マークしたオブジェクトが使われなくなり、回収漏れとなるオブジェクトが存在
  • Remark
    • Concurrent Markフェイズで実施したマーキングの整合性を確保する
      • 新たに追加されたオブジェクトの参照をチェックし、マーク漏れをなくす
      • マークしたオブジェクトが不要になっていたとしても、次回のGCで回収されることを期待し、何も行わない
    • すべてのアプリケーションスレッドを停止させる必要がある
  • Concurrent Sweep
    • マーキングされていないオブジェクトは参照がなくなったと判断されるため、それらを回収し空き領域を作成
    • アプリケーションスレッドと並列に行われる

 このような仕組みにより、コンカレントGCでは“Stop the World”を回避している。

コンカレントGCの問題点

 一見良いことずくめのように思えるコンカレントGCだが、問題点もある。コンカレントGC実行中はGCスレッドが動作している分、負荷が高くなる。そのため、全体的なスループット(ある単位時間当たりの処理能力)は下がり、応答時間も遅くなるのだ。

図3 応答時間の比較イメージ 図3 応答時間の比較イメージ

 どれくらい性能が劣化するかについては、アプリケーションの作り方や、システムに対する負荷状況により異なる。筆者の経験では、コンカレントGCの高負荷時の性能がスループットGCと比較し、30%程度低下したこともあった。このような大幅な性能劣化があると、コンカレントGCの採用を見送らざるを得ない。

性能劣化の原因

 コンカレントGCはなぜここまで性能が劣化してしまうのだろうか。実はコンカレントGCでは、New世代領域に関連するオプションのデフォルト値として「-XX:SurvivorRatio=1024 -XX:MaxTenuringThreshold=0」という値が設定される(オプションの意味については、後述)。そのため、1回のマイナーGCで回収されなかった短命オブジェクトはすぐにOld世代領域に移動してしまう。結果として、Old世代領域の使用量が上がりやすくなり、メジャーGCの回数が増えてしまうのだ。

 この問題を解決するための手段として、コンカレントGCと世代別GCを組み合わせて使用することが可能だ。以降では、マイナーGCを活用したコンカレントGCのためのチューニングについて見ていこう。

       1|2 次のページへ

Copyright© 2018 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。