進化するCPUをパワー全開で走らせるテクニック：Dr. K's SQL Serverチューニング研修（8）（3/3 ページ）

NUMAアーキテクチャを取り込んだ
SQL Server 2005とWindows Server 2003

　NUMAの先進性に注目したSQL Serverの開発陣は、スケーラビリティを上げるための究極のアーキテクチャはNUMAしかないだろうと考えました。そこで、SQL Server 2000がItanium 2の64bitに対応したときからHPと密接に共同研究を行い、このアーキテクチャをSQL Serverのエンジンに取り込むことを試みました。

　そのためにまず、OSサイドでNUMAのアーキテクチャをハンドリングしなくてはならないので、Windows Server 2003にNUMAのAPIを搭載しました。そして、SQL Server 2005は、NUMAのAPIをさらに拡張して「ノード」と呼ぶようになりました。例えば16CPUのマシンだと1セルに物理的なコアが4つ入るので、4つのノードを持っているというわけです。

　NUMAのAPIには、どのノードがI/Oを持っているのか教えてくれる機能が備わっています。SQL Serverのエンジンはディスクに対する複数のI/Oを受けるときに、あらかじめこのNUMAのAPIを使うことで、「何番目のノード、どのスケジューラに対してI/O関係のスレッドを集中的に立てるか？」を判断できるようになっているのです。これが完全に実装されたのが、Windows Server 2003とSQL Server 2005です。

　SQL Serverを使った新しいシステムを考えていくうえで重要なのは、2年先、3年先にトランザクション量が増えるのが予測できるのであれば、いまの開発時点でどれくらいのハードウェアを用意しておけば、どこまで対応できるかということをしっかりと把握して対策を講じておくことです。

　そのときの1つの目安として、ここで紹介したようなハードウェア＝CPUの最新知識を身に付けておくのは大変大事です。例えば32bitのXeon系であれば「最低でもメモリは8Gbytesは用意しておこう」とか、「CPUは4つの物理ソケットを持ったマシンにしておけば、将来トランザクションが急増しても、こういう最新機能を使うことによって解決できる」といった判断があらかじめできるからです。

チューニングを究めるなら
ハードウェアの基礎知識を真剣に学ぶこと

　ここまで読んでくると、SQL Serverはごく最近になってようやくマルチプロセッサに対応したと思う人がいるかもしれません。しかし、SQL Serverはバージョン4.2のころからマルチプロセッサを前提にしたアーキテクチャになっているのです。だからもしSQL Serverのチューニングをとことんまで追求しようと思うならば、今回お話ししているようなハードウェア、とりわけCPU周りのアーキテクチャに関することを、しっかりと勉強してください。

　もう1つはOSについて、皆さんがどれくらいしっかりした基礎知識を持っているのかをお聞きしたい。以前メモリに関するテーマの回でも取り上げましたが、メモリには「仮想メモリ」と「物理メモリ」があります。しかし仮想メモリはしょせん絵に描いたもちで、全体で物理メモリが足りなくなればページングという現象が起きて、物理メモリを複数のスレッドが奪い合うことになり、結果的にオーバーヘッドが発生することになります。だからチューニングを知りたいなら、メモリの制御を知ることが大事なのです。

　マルチスレッドの技術知識も必要です。OSのカーネルのスレッドとユーザーモードのスレッドとを、いかに割り込み技術を使って無駄なく制御し、CPUを遊ばせないようにするにはどうしたらいいかを考えるには、OSの中身が分かっていないとどうにもなりません。

　私もチューニングの問題に真剣に取り組む中で、SQL Serverの専門家である技術者と話をしていて分かったことは、いまのSQL ServerやPCサーバを使っている方々が、ハードウェアとOSに関する基礎知識を持たないまま実務を行っているケースが非常に多いということです。ここに、日常的に起こるさまざまなトラブルの根があるのではないかと思っています。

　私がなぜユーザーのトラブルの相談を聞いて、問題点の所在が的確に分かるかというと、ハードウェアやOSの基礎知識を熟知しているからです。そういう根本の知識があって、初めて「SQL Serverの中でこういうことが起きていて、こういう結果になっているのだろう」という仮説が立てられるのです。皆さんに基礎を学んでほしいというのは、トラブルの原因が分かるからだけではありません。原因を構成する基本のメカニズムが理解できれば、その後の解決の道筋までもおのずと見えてくるからなのです。

　仮説が立てられれば、次はマイクロソフトやサードベンダの提供しているいろいろなツールを使いながら、その仮説を可視化できます。ところがそうして突き詰めていった結論が、「オーバーヘッド」の一語に尽きてしまったりする場合も往々にしてあります。そしてたいがいの人は、ここから先へ進めない。

　しかし、そのオーバーヘッドの原因というのは、これまた別のところにあるわけです。なぜそんな高い負荷がソースにかかっているかというと、必ず何か原因があるからです。ではその原因は何か？

なぜそういうことになっているのか？ という仮説を順番に検証していって、最後に大本の問題点を見つけていくという過程で、ハードウェアやOSの基礎知識というのは、非常に役に立つものなのです。

　今後、SQL Serverのチューニングを本気でやっていこうとする人は、ハードウェアやOSについての勉強をきちんと突き詰めていかないといけません。これはおそらく何年たっても変わらない話です。どんどんOSもデータベースも賢くなって、プログラムの書き方がイベントドリブンやオブジェクト指向に変わったとしても、基本は私が初めてコンピュータを学んだ30年前からほとんど変わっていないのです。

　「そこまで知らなくても、SQL Serverは、どうにか動いてしまう」という人もいるでしょう。しかし、それだけにきちんと勉強しないままいくと、ある段階で限界が来てしまってそれ以上の進歩が望めなくなるのです。例えばコードを書く技術には優れていても、その人が優れたアーキテクトになれるとは限りません。やはり基礎知識が身に付いているかどうかで決まってきます。これはデータベースに限らず、どの世界でも同じだと思います。（「次回」へ続く）