Server(以下、WAS)についてのパフォーマンス・チューニングに関する入門記事です。Serverを参照してください)前回は、WASパフォーマンス・チューニングの主要項目について簡単な説明をし、パフォーマンス・チューニングの主要項目の1つである「トランスポート・チャネル・サービス」について解説しました。Machine(以下、JVM)に関するチューニングについて解説します。WASで扱うJVMの種類とバージョンは?WASは、稼働するプラットフォームによって異なるJVM実装を使用しています。具体的には、以下のとおりです。JVMを中心に取り上げていきます。JVMについては、各ベンダのWebサイトを参照してください。SDK)のリリースをまとめます(SolarisおよびHP-UXプラットフォームを除く)。5.0)に対応しております。6.1のJVMのチューニングに焦点を当てて解説していくことにします。JVMは、多くの改善がなされております。その中でもパフォーマンスに関連する項目としては、以下が挙げられます。Classesサポート注意!正確には、JVMにはJITコンパイラが含まれておりません。Environment)のコンポーネントです。従って本来ならば、「JVM」ではなく「JRE」と記述するべきですが、チューニング項目の多くがJVMの設定ですので、本連載ではJVMと記載することにしました。6.1のJVMのパフォーマンス関連項目について、少し詳しく説明した後で、パフォーマンス・チューニングについて解説することにします。6.1では、ヒープ・メモリの管理機能が強化されました。Collection)の強化です。“-Xgcpolicy:”の設定で調整が可能です。JVMが採用しているGC方式について解説をしていきます。その後で、“-Xgcpolicy:”の設定について説明します。GCを理解するための2つの視点GCは、Javaにおけるメモリ関連のパフォーマンス・ボトルネックの大きな要因といえます。GCについては、2つの視点で観察する必要があります。GC発生頻度ヒープ・サイズとアロケーション・レートに依存GC時間の長さヒープ・サイズとヒープ内のオブジェクト数に依存。大ざっぱにいうと、ヒープ・サイズが小さいと、GCが頻繁に発生し、逆に、ヒープ・サイズが大きいとGC発生回数は抑えられるが、1回のGC時間が長くなるGC方式を理解するための3つの観点GCの振る舞いを調整するに当たり、GC方式を理解することはとても重要です。GC方式については、大きく3つの観点で検討することにします。フラットなヒープ領域1:ヒープ領域確保の仕方まずは、「どのように、ヒープに空き領域を確保するのか」という視点での説明です。この視点では、以下の2つのGCアルゴリズムについて検討します。Objectとしてマークを付けます(Mark処理)。Object”と見なされ、ヒープからふき取られます(Sweep処理)。Sweep処理後のヒープ領域Sweep処理の後、ヒープに空き領域ができますが、それらは細かく分割され点在します。そのようなヒープの状況では、トータルのヒープ空き領域が十分なサイズであったとしても、大きなオブジェクトをアロケートしようとした際には、連続した空き領域が必要になる場合があります。Objectをヒープの先頭の方に移動します(Compact処理)。Objectの移動に伴う関連する参照の更新なども行います。Collectorが必要と判断した際に、実施されます。GCは、ヒープ領域を2つに分割して使用します。新しく生成されるオブジェクトは、そのうちの片方の領域に割り当てられます。その領域がいっぱいになり、これ以上オブジェクトを割り当てられなくなると、GCが開始されます。Objectを検出(マーク)します。Objectをもう一方の領域にコピーします(Copy処理)。Copy処理(GC1回目)この処理を行いながら、オブジェクトの移動に伴うリファレンスデータの更新も併せて行います。Objectのみが、一方の領域にまとめて配置された状態になります。空領域に端からオブジェクトをコピーしていくため、コピー処理後、ヒープには連続した空き領域が確保されていることになります。Objectの後ろに割り当てられます。その領域がいっぱいになると、前回の処理のコピー元とコピー先を入れ替えて、同様の処理を次のGCとして実施します。GCは、ヒープの半分の領域のみを実際のオブジェクトの割り当てに利用しています。従って、ヒープ・メモリの利用効率という観点では効率的とはいえないでしょう。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。