ディスクのボトルネックの解決法
データベースの性能問題に占めるディスクボトルネックの割合は非常に大きい。リレーショナルエンジンの主要な目的は,いかにディスクI/Oの少ない方法を見つけ出すか,ということである。
パフォーマンスモニタで採取したパフォーマンスデータを分析した結果,メモリマネージャのページングによるディスクI/Oがディスクボトルネックの主原因であれば,メモリを追加する。ディスクボトルネックの原因が特定のアプリケーションに起因するのであれば,データベース論理設計やアプリケーション設計を見直し,ディスクI/O回数を減らすか,そのアプリケーションの稼働時間をオフピーク時間に移動する。メモリマネージャや特定のアプリケーションのディスクI/Oがディスクボトルネックの原因となり得ないのであれば,ディスクの処理能力が不足しているので,高速なディスクドライブに変更するか,新たにディスクドライブを追加してディスクI/Oアクティビティをそれらのディスクドライブに分散させることが必要になる。
ディスクがボトルネックである場合の解決策は,ハードウェアレベルとアプリケーションレベルの双方でディスクI/Oを少なくできないかを検討することである。手順としては,まずアプリケーションを見直し,ディスクI/Oを少なくする。次に,複数のディスクドライブに均等にディスクI/Oアクティビティを分散させる。もし,すべてのドライブが稼働中で,それ以上ディスクI/Oアクティビティを分散させることができないのであれば,物理ディスクドライブを追加してディスクI/Oアクティビティを分散させる。物理ディスクドライブを追加する場合は,ディスクコントローラやSCSIインターフェイスも追加して負荷を分割させるべきである。
ディスクサブシステムは,物理ハードディスク,ディスクコントローラ,RAIDコントローラ,SCSIインターフェイス,PCIバスなど,さまざまなコンポーネントから構成されている。ところが,パフォーマンスモニタでは,これらのコンポーネントのどれがボトルネックとなっているかを直接検出することはできない。パフォーマンスモニタで計測可能なカウンタの値には,さまざまなコンポーネントに起因する情報が区別なく示されているにすぎないのである。たとえば,パフォーマンスモニタでディスクI/Oの待ち行列を示すカウンタを調査した結果,待ち行列が過剰に生成されていることがわかったとしても,それがSCSIチャネルに起因するかどうかを直接検出することはできない*1。現実には,多くのディスクドライブ(10台またはそれ以上)をSCSIチャネルに接続して,各ディスクドライブがディスクI/Oを最大の処理能力で実行していれば,SCSIチャネルがボトルネックとなるトラブルは十分起こり得る。したがって,パフォーマンスモニタを利用してディスクのボトルネックを検証する場合には,パフォーマンスモニタで得られた情報を元に,さまざまな可能性を検討することが重要となる。先のSCSIチャネルの例でいえば,ボトルネックになっているかもしれないSCSIチャネルに接続されているディスクドライブの一部(半数程度)を新たに追加したSCSIチャネルに移動させ,ディスクI/Oを分散させて状況の変化を観察することで,SCSIチャネルにボトルネックがあるか否かを判定できる。
ディスクにボトルネックがあると判明した場合には,状況に応じて次のような対策を講じることができるだろう。
- LogicalDisk:% Disk Timeカウンタの値がピークに達している場合は,max async IOオプションの値を減らし,LogicalDisk:% Disk Timeカウンタの値に余裕がある場合は,max async IOオプションの値を増やして,評価してみる。max async IOオプションに大きな値を設定しすぎると,SQL Serverによるそのほかの入出力処理で必要とされるディスクサブシステムの帯域幅がCheckpointスレッドやLazyWriterスレッドに独占されてしまうおそれがあるので,注意しなければならない
- 論理データベース設計およびインデックス設計を見直し,ディスクI/Oの要求数を減少させる*2
- 低速なディスクドライブを使用している場合は,高速なディスクドライブに変更する。最新のPCサーバーのように最高速のディスクドライブが接続されているのであれば,ディスクドライブを追加し,ディスクI/Oを分散させる
- 低速なディスクコントローラを使用している場合は,高速なディスクコントローラに変更する
- 1台のディスクドライブあたり,ランダムアクセスで75回,シーケンシャルアクセスで150回のI/Oを目安にディスクドライブを追加し,ディスクI/Oを分散させる
- 1つのRAIDコントローラに対してディスクドライブは5〜6台以下を目安とする。これを超える場合にはRAIDコントローラを追加し,ディスクドライブを分割してディスクI/Oを分散させる
- PCIバス1スロットあたり3つのRAIDコントローラを目安とする。これを超える場合には,複数のPCIバスにRAIDコントローラおよびディスクドライブを分散させる
- データ,インデックス,トランザクションログを,それぞれ物理的に異なるディスクドライブに配置する
- ファイルグループを活用してテーブルを複数のディスクドライブに分散させ,データアクセスを並列化させる
- テーブルを分割して別のディスクドライブに配置する
- ハードウェアベンダによっては,RAIDコントローラがサービスしているI/Oの量を調査したり,RAIDコントローラがI/O要求を待機させているか否かを検出したりするツールを提供していることもある。必要ならば,RAIDコントローラを開発したハードウェアベンダなどに問い合わせてみるとよいだろう。
- 「9.4 データベースのチューニング」,「9.5 インデックスのチューニング」,「9.6 アプリケーションのチューニング」を参照すること。
| Chapter 9 44/46 |
