Javaのメモリ管理には欠陥がある
いまや基幹業務をJava アプリケーションサーバで稼働させるのは珍しくなくなってきている。Javaによる開発生産性の向上も期待でき、ハードウェアコストも抑えることが可能だ。
その一方で、業務処理のピーク時にスループットが低下するなど、性能上のトラブルも発生するようになっている。システムの性能劣化につながる要因として、① CPUネック、② メモリネック、③ バックエンドシステムによるネックの3つがある。ここでは② のメモリネックによる問題を見ていく。特にJava VM(仮想マシン)のメモリ管理機能(ガーベジコレクション)には問題が多い。
ガーベジコレクション(GC)とは、JavaVMが管理するメモリ領域中の使用済みメモリ領域を破棄し、空き領域を作ることだ。これにより効率的なメモリの使用が可能になる。しかしながら現実にはメモリ領域のサイズは非常に大きいため、メモリ領域全体を対象としたGC(Full GC)が発生した場合、その間業務アプリケーションが停止してしまうのである。
GCが対象とするメモリ領域は、Javaヒープと呼ばれる部分と考えてよい。JavaヒープはNew領域とOld 領域で構成される(図参照)。また、短命なインスタンスが格納されているNew領域を対象としたGCをCopy GCと呼ぶ。Copy GCの処理時間は0.01 ~ 0.7 秒であるため、それほど業務には影響がないが、Old 領域も対象としたFull GCでは1~数十秒も処理に時間がかかってしまう。
一方、Java のメモリ管理では、GC実行そのものの回避は不可能だ。そこで注目したのが、GCアルゴリズムの変更ではなく、新たなヒープ管理方式の採用である。それが「明示管理ヒープ方式(略称:Eヒープ方式)」(特許出願済)である。
Full GCレスを実現するEヒープ方式
Full GC を発生させる主要因は、Old領域へ格納されたセッション情報である。セッション情報は長命、つまりログオフ後も残存し、Full GC を頻発させる原因となる。
Eヒープ方式では、セッション情報をEヒープ領域と呼ばれる、Old 領域とは異なる領域に配置する。この結果、Full GC レスが実現されることになる。また、この処理はCosminexusが行うため、既存のプログラムを変更する必要はない。結果、システム全体の処理性能を向上しつつ、安定性をも維持できる。
Cosminexusが持つ 優れたメモリトラブル回避機能
Cosminexusには、メモリトラブルを回避するための機能が多数搭載されている。
メモリトラブルで代表的なのが、プログラム内に解放されないJava オブジェクトが継続的に増加してしまうメモリリークだ。Cosminexusの「ヒーププロファイル機能」を使えば、メモリリークの原因となっている箇所を容易に検出可能になる。特にヒープ情報の出力はJava VM自身で行っているため、高い精度で解析を行うことが可能となっている。