Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP-UX   >  Knowledge-on-Demand  >  Javaパフォーマンス・チューニング

Javaパフォーマンス・チューニング

第1回:基本的ルール、パフォーマンス・ツールの使い方

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
連載Javaパフォーマンス・チューニング:第1回

チューニングの手順


パフォーマンスの問題を速やかに解決しなくてはならない状況では、計測や分析に時間をかけず、推測に基づく安易な対応を取ってしまいがちです。しかし大抵の場合、こうした対応は状況をさらに悪化させかねません。場当たり的な対応をする代わりに、以下に示す一定の手順に従ってパフォーマンス・チューニングを実施することが望ましいでしょう。図1は、この手順を図示したものです。
Javaパフォーマンス・チューニング 第1回
パフォーマンス・チューニングのルール
チューニングの手順
ページ:  戻る   |   1   2

図1:パフォーマンス・チューニングの手順
  図1:パフォーマンス・チューニングの手順

評価(Assess)


最初に実施する「評価」の段階では、以下に示す各項目について調査を進めていきます。これらの項目を明らかにすることで、何をどこまでチューニングするのかといった基本的な前提条件があぶり出されます。

  • システムの構成
  • アプリケーションの設計
  • パフォーマンスの目標
  • ピーク時の負荷の大きさと期間
  • システムやアプリケーションに施された変更内容
  • パフォーマンスの問題が発生する期間

この段階で最初に実施すべき作業は、ユーザ・リクエストが処理される上で通過する全てのマシンの構成を列挙することです。具体的には、以下の内容についてまとめます。

  • マシンのCPU数とクロックスピード(CPU数はglanceやgpmで確認可能)
  • メインメモリ容量(同じくglanceやgpmで確認)
  • ディスク容量(使用領域と未使用領域のサイズ。dfコマンドで確認)
  • OSのチューニング可能なパラメータの値(HPjconfigツールで確認)
  • OSに適用されるべきパッチ(HPjconfigで確認)
  • JVMのバージョン(「java -version」コマンドで確認)
  • JVMに指定しているオプション(-Xmsや-Xmxなど)
例えば、「java -version」コマンドを実行すると、JVMのバージョン情報が以下のように得られます。

java version "1.3.1.01-release"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1.01- release-010816-12:37)
Java HotSpot(TM) Server VM (build 1.3.1 1.3.1.01-release-010816-
13:34-PA_RISC2.0 PA2.0, mixed mode)

これらのバージョン情報は、Javaプログラムのパフォーマンスを評価する上で欠かせない基本情報となります。問題の内容によっては、最新バージョンのJVMにアップグレードしたり、OSに最新のパッチを適用したり、JVM起動時に適切なオプションを指定したりといった簡単な方法で解決できることもあります。

一般的には、最新バージョンのJVMにアップグレードを行い、OSに最新のパッチ・セットを適用することが推奨されています。OSのパッチについては、HPが提供する「HPjconfig」を利用することで、適切なパッチが適用されているかをチェックすることが可能です。なお、同ツールについては、次回の連載で詳しく説明する予定です。

測定(Measurement)


パフォーマンス・チューニングにおける次の段階は「測定」です。この段階では、実際のシステムを動作させることで、アプリケーションのパフォーマンスを測定します。

HP-UX上で動作するJavaアプリケーションのパフォーマンスを測定する手段としては、「sar」や「top」といった標準的なツールに加えて、以下の手段を利用することができます。

  • パフォーマンス測定ツール「glance」および「gpm」
  • JVMオプション「-Xverbosegc」(分析ツール「HPjtune」)
  • JVMオプション「-Xeprof」(分析ツール「HPjmeter」)
  • 「kill -3」によるスタックトレースの取得

これらの手段を利用した情報の収集には、かなりの手間と時間がかかる場合もあります。しかし、この測定の作業と次に説明する分析の作業は、実際にシステムに手を加える前に完了させておくことがポイントです。


分析(Analyze)


測定を終えた後は、収集した大量のデータを「分析」する段階に進みます。とはいえ、それぞれのツールが出力するデータの形態はまちまちであり、それらを正確に解釈することは容易な作業ではありません。冒頭で述べたとおり、1つのシステムは複雑に依存し合う多数の要素で構成されているのです。

収集したデータの分析方法については、次回以降の本連載で詳しく解説する予定です。

特定(Identify)


分析の作業によって、システムのボトルネックはどこに存在するのかを「特定」することが可能になります。いったんボトルネックを見極めることができれば、パフォーマンスを改善するためにどのようなチューニングを施せばよいのかが明らかになります。もっとも、1つのボトルネックを解消すると、今度は別の場所が新たなボトルネックとなる場合も少なくありません。

変更(Tune)


ボトルネックを特定したならば、その後に取るべき道は2つあります。それは、システムのリソースを増加させるか、あるいはリソースへの要求を減らすか、いずれかの「変更」を施すことです。どちらにせよ、変更の対象は1箇所に限定しなくてはなりません。2箇所以上に変更を施すと、どれがパフォーマンスに影響を及ぼしたのか分からなくなってしまいます。

また実施した変更については、随時ノートなどに記録するようにします。変更の履歴を残すことで、後々の混乱を避けることができるはずです。

以上、連載第1回では、Javaパフォーマンス・チューニングにおける基本的なルールとチューニング手順について説明しました。次回以降は、ツールを利用したチューニング作業の実際を解説します。

連載記事一覧 戻る ページ:  戻る   |   1   2

連載 「Javaパフォーマンス・チューニング」記事一覧

第1回:基本的ルール、パフォーマンス・ツールの使い方
第2回:ガベージ・コレクション
第3回:ヒープ・メモリ管理
第4回:マルチスレッドによるリソース競合
第5回:メモリ・リークの発見
第6回:メモリ・リーク解析とHotSpot JVM

 その他の連載記事


本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

HPEサポートセンター
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項