追加コスト 0 で行う SQL Server のパフォーマンス改善・ボトルネック解消 その0

こんにちは、nagino です。

記事をまとめようとしているとなかなか書けずに時間だけ過ぎていくので、しばらくタイトルのネタで雑多に書き散らし、最後にまとめようかと思います。

さて、いつの時代でも人気な Topic がパフォーマンス改善・ボトルネック解消ではないでしょうか。

しかし、なまじ異常系の Topic だけに複雑であり、誤解や神話が多いのも事実ではないでしょうか。

まず大前提として、以下を押さえる必要があります。

1. パフォーマンスは最遅コンポーネントのパフォーマンスに従属する。

現在のシステムは、様々なコンポーネントや要素が複雑に絡み合っています。

仮にコンポーネントが以下の 3 つがあったとします。

A ： 毎分 10 要求分の処理を行える

B ： 毎分 8 要求分の処理を行える

C ： 毎分 50 要求分の処理を行える

ここで、このシステムでは A ⇒ B ⇒ C の順に処理を行うとします。

そうすると、このシステム全体では毎分 8 要求しか処理できません。

B がボトルネックです。

さて、ここで B に投資して処理能力を 10 倍の毎分 80 要求の処理を行える状態にしたとします。

（ディスク IO のコンポーネントであれば、RAID 1+0 を導入する、など）

そうするとシステム全体のパフォーマンスはどうなるでしょうか。

毎分 10 要求しか処理できません。

1.25 倍にしかなりません。

システムが遅いからといってそのボトルネックを解消しても、隠れボトルネックが存在する場合、それが顕在化するため、解決にはなりません。

このため、ともすると効果を見誤ることになります。

ですので、常に測定とボトルネックの判別が非常に重要になります。

ちなみにボトルネックの解決は Try & Error と経験と勘、という話も聞きますが、ある意味正しく、その一方上記の意味で不適切だと考えています。

症状から原因が特定できるケースなどは、経験と勘が有効ですし、Try するのが最速の解決方法です。

一方で未知の障害に関しては、そのようなやり方では運任せとなり、泥沼になりかねません。

自身の経験と、直面している問題、求められる作業水準に応じて手法を取捨選択するというのが正しいと考えています。

2.現象と原因が直結するとは限らない。

これは、例えば以下のようなケースです。

ディスクの IO が非常に多く、そのため処理が遅いサーバがあるとします。

しかし、実はプログラムの質が低いためにメモリを大量に消費し、メモリ不足のために仮想メモリを大量に使用し、仮想メモリのためにディスク IO が非常に多くなっているかもしれません。

この場合は、根本解決はプログラムの改修ですが、メモリやディスク負荷からハードウェアの性能不足や、SQL Server の性能不足と判断してしまうこともありえます。

原因から現象が発生し、その現象が原因となってさらに別の現象を発生させることがあるため、原因らしき事象があった場合に、それが真の原因かどうかを検討する必要があります。

3.費用対効果を考える。

これも、上記の例の場合を考えてみます。

当然根本的な解決はプログラムの改修ですが、開発会社との取引が現在無いか改修のコストが非常にかかってしまう場合、プログラムの改修が難しい場合は、実は無理してプログラムの改修を行うより、より高性能なサーバーにリプレースするほうが安く問題を解決できる場合が多々あります。

研究ではなく業務で行っている技術者にとっては、根本解決ではなく回避策（ワークアラウンド）で対処というのも現実解としてありえます。

これを常に念頭において、根本解決が困難な場合には逃げ道を考えることも、意外と大事だったりします・・・。

このあたりを考えつつ、追加投資無しで行える調査手法やパフォーマンス改善について、次回以降言及・検討していきたいと思います。