チューニング・ステップの繰り返し
パフォーマンス分析で明白なことは、常に次のボトルネックが存在することです。 あるリソースの使用を減らすということは、別のリソースがスループットまたは応答時間を制限することを意味します。
例えば、使用率レベルが以下のようなシステムがあるとします。
CPU: 90% ディスク: 70% メモリー: 60%
このワークロードは CPU 制約のワークロードです。 CPU のロードを 90% から 45% に減らすように、ワークロードを首尾よくチューニングできれば、 パフォーマンスは 2 倍に向上するものと期待されるかもしれません。 残念ながら、ワークロードには現在入出力の制約があり、その使用率はほぼ次のとおりです。
CPU: 45% ディスク: 90% メモリー: 60%
CPU 使用率の改善により、プログラムはディスク要求をより迅速に実行依頼することができますが、 その後ディスク・ドライブの能力によって課される制限に突き当たることになります。 パフォーマンスの改善は、当初予想した 100% ではなく、30% にとどまるでしょう。
常に新しいクリティカル・リソースが存在します。 重要な問題は、手持ちのリソースでパフォーマンス目標を達成することができるかどうかです。
重要: vmo、ioo、schedo、no、および nfso チューニング・コマンドによって不適切なチューニングが行われると、
システム・パフォーマンスやアプリケーション・パフォーマンスの低下、
あるいはシステム・ハングなど、システムが思わぬ動作をすることがあります。
変更は、パフォーマンス分析によってボトルネックが識別できたときだけ適用すべきです。
注: パフォーマンスがからむチューニング設定には、一般的な推奨事項のようなものはありません。