並行処理のパフォーマンスに影響を及ぼす「MAX DOP」
待ちの制御という話題に関連して、ここでちょっと「MAX DOP」（max degree of parallelism）というパラメータに触れておきましょう。MAX DOPというのは、1ユーザーコネクションが、複数のスレッドを用いて並行処理を許すかどうかを制御するパラメータです。この既定値は「0」です。つまり「すべてのCPUを利用可能」ということです。
これはどういう意味かというと、まず「親スレッド」は、前ページの図2で述べたように、初期のコネクション確立時点で処理が特定のUMSに決定されると述べました。ところがこの後に、オプティマイザが最適化を行うプロセスが入るのです。
例えばあるクエリを処理するのに「A、B、Cという処理を並列で行って、その結果をDで処理し、次にEで処理し……」という実行計画に最適化されたとします。「MAX DOP ＝ 0」の場合だと、親スレッドを「01」として、ほかのスレッドを「02」「03」という「子スレッド」として使えます。そうすると、並列処理は一見大変うまくいくように見えるのですが、並列処理特有のデータ交換、同期によるオーバーヘッドも生じるために、サーバ全体のパフォーマンスは劣ってしまいます。
すると、既定値「0」はおかしいのではないか、ということになってきます。通常OLTPの場合は、MAX DOPを「1/4 or 1/2×物理CPU（コア数）数」として算出するという式があります。例えば4CPUのSMPマシンであれば、トランザクション処理のときにはMAX DOPを「1」にしなさいというわけですね。それによってパラレル処理を禁止して、シリアライズに処理した方が、サーバ全体としては速い場合があるのです。
ただし、MAX DOPを大きな値、すなわち1以上の（n個）にすることで、パフォーマンス向上に大きな効果が期待できる場合もあります。それはバッチ処理です。例えばドライブレター（ディスク）がたくさんあるシステムで、複数のデータとディスクがあって、全体を管理するインデックスがあってというツリー構造になっていたとします。こういう関係の大規模なデータベースで大量のバッチ処理を行う場合に、MAX DOPの値を大きくすると効果を発揮します。
あるユーザーでは、通常のトランザクション処理のときは「1」に設定して、夜間バッチでは上の式で計算した（n個）の値に動的に設定しています。このように、1つのコネクションがUMS上のスレッドを1個しか使ってはいけないのか、複数使っていいのかというのを制御するのがMAX DOPなのです。なお、MAX DOPは論理CPUではなく物理コアにしなくてはダメです。
バッチ処理とOLTPでこの値を変えて、そのバッチでBCPなどのデータのロードをパラレルで行いたい場合などは、MAX DOPを指定すると大変有効です。ただし通常のトランザクション処理の場合の値は「1」として、並列処理をさせない方が全体のパフォーマンスは上がります。これは、裏方のスレッドの使用するCPUを取り上げないためです。
Runnable Queueは、CPUの数が足りているか否かの目安
待ちの制御に関して、もう1つ見てみましょう。UMSの中にはRunnable Queueという場所があります。ここがいわゆるカラオケの順番待ち行列が待機している場所です。UMSはCPUと1対1の関係なので、RUN（実行）状態のスレッドはいつも1つしかありません。それ以外のスレッドは「Runnable Queue」で自分の順番がくるのを待っています。そして実行可能になるとキューにつながれて、ファストイン／ファストアウトで実行されます。
私にいわせれば、Runnable Queueに順番待ちスレッドがたまってしまうということ自体、パフォーマンス・チューニングの観点から、すでに問題です。ここにキューが生成されていることは、そもそもCPUの数が足りない証拠です。そんなに多くのトランザクションが発生するシステムならば、前もってCPUを増やしておくべきだったのです。そして、改善するならデュアルコア・プロセッサを導入してみてはということです。
連載のおわりに
さて、9回にわたってSQL Serverのチューニングにまつわる技術論を紹介してきました。この限られた記事の中だけで、奥深いSQL Serverチューニングのすべてを解説することはとても不可能ですが、私なりにSQL Serverに携わるプロフェッショナルの知識の一端をお話しすることで、皆さんの関心にわずかでもお応えできたならうれしいと思っています。
この連載で紹介したSQL Serverに関する情報をマイクロソフトが私に公開してくれたのは、2005年の4月以降のことです。それまでは、おそらくこうだろうという自分なりの推測でやっていたのです。こうした変化はマイクロソフトがSQL Serverのさらなる普及を目指して、データベース技術者への支援に全面的に乗り出した証として歓迎したいと思います。
こうした非常にハイレベルなSQL Serverの情報を日ごろから惜しみなく私に提供してくれているのが、米マイクロソフトのカスタマー アドバイザリーチームに所属するトーマス・デイビッドソン（Thomas Davidson）氏です。彼が私に対して、こうした貴重な技術情報のほとんどを提供してくれているのです。まさに、私にとっては最良のパートナーの1人です。今回の連載で紹介した技術情報の中にも、彼を経由して私の手元にもたらされたものは少なくありません。連載の最後に当たって、あらためてデイビッドソン氏へ深い感謝を捧げたいと思います。
また、1995年11月に、私の最も尊敬している、米マイクロソフト・リサーチのジム・グレイ（Gim Gray）博士来日の折に、PASSJ主要メンバーに対して実施していただいた、約1時間のラウンド・テーブル型式でのディスカッションで、ミッションクリティカル分野におけるSQL Serverの今後のロードマップを教えていただき、とても参考になりました。
最後までお付き合いくださった読者の皆さんにも、心から感謝しています。実のところ、初めてSQL Serverのチューニングを学ぼうという人にとっては、簡単な話ばかりではなかったと思います。それでもやはりデータベースのテクニックを究めていこうと思うなら、ここで紹介したような基本をしっかりマスターすることが絶対に欠かせないと私は信じています。ともあれ9回の長きにわたって続けてこられたのは、皆さんからの大きな声援や反響があったからこそです。本当にありがとうございました。
少々気が早いといわれそうですが、こういったとっておきのノウハウを皆さんにご紹介できる企画を、SQL Server 2005でもぜひやってみたいと願っています。では、ぜひまた近いうちにお目にかかりましょう。それまでお元気で！（連載完）
監修者プロフィール
株式会社CSK Winテクノロジ 執行役員 兼 技術推進担当。
熊澤 幸生（くまざわ・ゆきお）
メインフレーム環境で20年近くデータベース関連のITプロジェクトを数多く経験。また1979年から1983年まで米国に駐在し、データ主導型システム設計を実プロジェクトで学ぶ。1994年、アスキーNT（現、CSK Winテクノロジ）設立に参加し、SQL Server Ver 4.2からSQL Server 2000までシステム構築、教育にかかわってきた。現在同社執行役員 Chief Technology Officer。また、SQL Serverユーザー会「PASSJ」の理事として活動中。
- キャッシュを無駄遣いしないようにクエリを書く
- 64ビット時代の「バランスド・システム」
- DB管理者がいますぐ確認すべき3つの設定
- 内部動作を知らずしてチューニングは語れない
- CAT秘伝、バランスド・システムの考え方
- パフォーマンスを語るために歴史を語ろう
- チューニングに大変革をもたらす動的管理ビュー
- SQL Server 2005でガラッと変わった個所とは？
- チューニングとは……スレッドとの格闘に尽きる
- 進化するCPUをパワー全開で走らせるテクニック
- I/Oボトルネックの病巣はこれで究明できる
- I/Oチューニングを成功させる必修ポイント
- 排他制御の落とし穴を避けるインデックス設計
- 排他制御メカニズムから“待ち”原因を究明する
- パフォーマンスを満たす物理メモリ量を算出する
- 誰も知らないメモリ・チューニングの極意を教えよう
- SQL Serverというブラックボックスを開いてみる
Copyright © ITmedia, Inc. All Rights Reserved.