SQL Server 2005でガラッと変わった個所とは？：Dr. K's SQL Serverチューニング研修 Part II（1）（2/4 ページ）

» 2007年07月10日 10時00分公開

ストレージエンジンはどのようにNUMAを認識するか

　もう少しNUMAについて技術的側面から掘り下げていきたいと思います。「肝心のパフォーマンス・チューニングの話は？」。いやいや、そんなに急がないでください。NUMAを理解することは、これからのデータベースの基本となるアーキテクチャを理解することです。ここが分かっていなければ、パフォーマンス・チューニングの具体的なTipsを1つ2つ覚えたところで、小手先の理解にすぎません。あなたが今後、応用力と創造性にあふれたデータベース・アーキテクトに成長するためにも、ぜひここは最初にして最重要のポイントと思って、しっかり学んでください。

　NUMAというのは、「CPUコアを複数持ったチップセット＋セル内のローカルメモリ」の構成です。例えば、HP Integrity Superdomeでは、「デュアルコアインテル Itanium 2プロセッサー9000番台」（Montecito）というCPUを搭載しています。Montecitoは4つの物理コア（4ソケット）が1つのセルを構成しています。その中には8個のCPU（論理コア）があることになります。では、SQL Server 2005のストレージエンジンはどうやってNUMAのCPUを制御するのでしょうか。

　ストレージエンジンの中では、NUMAの1セルに対してスケジューラノードを1つ割り当て、その下に実装されているコアの数だけスケジューラを持ちます。例えばMontecitoだと、NUMAの1セルの下にSQL Server 2005のスケジューラが8つ載るわけです。ノード内にはメモリスペースがあって、その中にはデータキャッシュやプロシージャキャッシュ、ユーザーコネクションなどが収められていますが、これらが全部ローカルノード内にあるわけです（図3）。

図3　SQL Server 2005のスケジューラとNUMAの関係

　一方、Lazy Writer、Resource Monitorといったパフォーマンスに大きな影響を与えるスレッド群は各ノードに関連付けられており、仮にノードが4つあるマシンならば、SQL Serverの下でLazy Writerなどが4つ並行して動くことになります。すなわち、ローカルメモリ単位にSQL OS（SOSと呼ばれている）の常駐タスクがn個動くのです。その結果、一定期間ごとにメモリ上の更新データをディスクに書き込んだり、コミット単位にログを書き込んだりする作業が、ノード単位にパラレルで動きます。

　NUMAのアーキテクチャをサポートしていなかったSQL Server 2000までは、1つのノードしか扱えませんでした。そこで1つのノードの下にコアの数だけスケジューラを直接つなげて、1つのメモリの中でやりとりをしていたわけです。

　これがSQL Server 2005になってからは、ストレージエンジンからNUMAを認識できるので、NUMAのセル単位にノードを1つ以上持てるようになりました。ノードと関連付けられた64bitのメモリスペースがあって、そこにローカルサイドのキャッシュを持てるようになったのです。その結果、ローカルノードで持っている64bitのメモリスペース単位で、システムのいわゆる裏方ともいうべきスレッドをn個動かして、全体のスケーラビリティを上げるようになっています。これが今回SQL Server 2000と2005で比較して、NUMAに関して最も改良された部分です（裏方スレッドに関しては前回の連載「チューニングとは……スレッドとの格闘に尽きる」を参照）。