 |
≫ |
|
|
|
|
| 連載の第1回では、パフォーマンス・チューニングにおける基本的ルールや、HPが提供する各種のJavaパフォーマンス・ツールの使い方を説明します。なお、今後の連載では、JVMレベルに留まらず、HP-UXのカーネル・パラメータやネットワーク・パラメータのレベルでのチューニング方法も解説します。また、より高度なチューニング技法として、JVMのガーベジ・コレクションやスレッド競合に注目する方法も紹介する予定です。 |
|
|
|
|
パフォーマンス・チューニングにはいくつかの基本ルールがあります。これらのルールは、どのようなシステムに対しても適用できる一般的なものと言えるでしょう。パフォーマンス・チューニングについて技術的な詳細を論じる前に、まずはこれらの普遍的なルールをいくつか紹介します。 |
|
ルール1： システムのパフォーマンスは、互いに依存する多数の要素の影響を受ける
|
|
|
|
| |
1つのシステムの内部では、数多くのコンポーネントが協調して動作しており、互いに複雑な依存関係を結んでいます。そのため、パフォーマンスのボトルネックがどの場所にあるのかを一目見ただけで特定するのは、きわめて困難です。
また、こうした複雑な依存関係によって、次のルールも導かれます。 |
|
|
|
ルール2： パフォーマンス・チューニングは、常にトレード・オフを伴う
|
|
|
|
| |
システムのパフォーマンス・チューニングには、OSの動作メカニズムをはじめ、パフォーマンスに影響を与える依存関係の理解が必要です。ある部分にチューニングを施せば、他の部分で性能の劣化を招く可能性もあるのです。例えば、メモリ利用率を向上させるためのチューニングによって、ファイル・システムのパフォーマンスが低下するようなケースも考えられます。よって、アプリケーションの要件や、メモリとファイル・システムの相互作用を理解し、トレード・オフの最適なポイントを見極めることが重要となります。
また、ボトルネックが存在する場合には、システムに備わるリソースと、それに対する要求のバランスを上手に維持しなくてはなりません。ボトルネックを解消するためには、リソースを増加させるか、あるいは要求を減らすかのいずれかしかないのです。そうした観点でも、システム内部のリソースの使用状況を詳細に観察することが大きな意味を持ちます。
さらに、システムの挙動を観察する上では、次のルールが役に立つでしょう。 |
|
|
|
ルール3： システムに影響を与えずにシステムを観察することは不可能である
|
|
|
|
| |
システムを観察することは、それ自体がシステムのリソースを消費する行為でもあります。もちろん、使用するツールの種類によってその消費量は異なってきます。例えば、GUI版のglanceである「gpm」は、glanceやvmstatといったテキスト・ベースのツールに比べて、はるかに大きいメモリ（5MB以上）を消費します。
また、こうしたツールはリソースを消費するだけでなく、システムの挙動そのものをも変えてしまうことに注意してください。十分なメモリを持たないシステムでは、ツールのメモリ消費によってOSのスラッシング（過度なスワッピング）が発生するかもしれません。こうなると、システムをありのままの姿で観察することはもはや不可能です。
どの程度までならシステムに与える影響を許容できるのでしょうか。これは、ツールを選択する上で重要なポイントとなります。また、状況に応じて様々なツールを使い分けることが必要となるでしょう。これは、次のルールで言い表すことができます。 |
|
|
|
ルール4： チューニングに必要な全てのデータを提供できる万能ツールは存在しない
|
|
|
|
| |
どのような状況でも問題を解決できる完璧なツールは存在しません。よって、パフォーマンス・チューニングでは、数多くのツールの使い方を習得せざるを得ないのです。また、複数のツールを使用することで、得られた情報をクロス・チェックすることができ、ツールが本当に正しい情報を提供しているか確認することも可能となります。 |
|
|
| 本ページの内容は執筆時の情報に基づいており、異なる場合があります。 |
|
印刷用画面へ
