SQL Serverの内部で、
カラオケボックスの順番待ちが行われている？！
それでは、UMSはどのような処理を行っているのか、順を追って見ていきましょう。図2は新しいコネクションが開始されたときの一連の流れです。「Protocol Listeners」という部分で、新規のものかどうかを判断して、ここでネットワークの無応答の監視をしたりします。実際はログインという形でSQL Serverにコネクションが入った段階で、どのUMSを使うか決まってしまいます。その先はずっと同じUMSに対して、途中のセッション情報が引き継がれていくのです。
セッションが確立して、あるクライアントに特定のUMSが割り当てられると、UMSはクライアントの発行するSQLを処理します。図3は、UMSによるスレッド処理のフローを表したものです。
「RUNNING」というのは、現在CPUを使える状態のスレッドを指します。例えばあるクライアントが「select * from XXXX table」というSQLを出したとします。すると、その命令を受けたとたん、このスレッドの状態は「RUNNING」から「Wait」に移行します。
こうなると、フルスキャンが終わって結果セットが絞り込まれるまで、このスレッドはもう何もすることはありません。受け取ったI/Oの要求を別のスレッドに依頼した後、実行権を放棄して「SLEEPING」という状態になります。ストレージエンジンに「テーブルを全件読みたいので、データを全部バッファプールに転送したら私に教えてくださいね」という依頼をして、その結果が返ってくるまで待っているというわけです。
I/Oの要求を依頼された裏方＝ストレージエンジンは、要求されたテーブルのデータをファイルシステムから持ってきます。そしてバッファプールへの転送が終了するとイベントが起きるわけです。当初のスレッドは、このイベントを受け取ると「Runnable List」という状態に移ります。
Runnable Listの内部空間は、いってみれば仲間同士で来ているカラオケボックスみたいなもので、あくまでカラオケを歌っているのは1人ですね。そこでRunnable Listに入ったスレッドたちは、自分にカラオケマイク（CPUの実行権）が回ってくるまで待っているのです。前の人が歌い終わると、初めてバッファプールの中のデータを加工してクライアントに返すというCPUの処理が動くのです。
UMSの中では複数のスレッドがこういった一連の処理をぐるぐると回っているわけで、その開始から完了までが、クライアントから見たひとまとまりのレスポンスタイムになるわけです。そして、この中で待ちが発生するとパフォーマンスの低下として映るのです。
私たちが行うチューニングというのは、結局「なぜこうした待ちが発生しているのか？」を分析することでもあります。インデックスが悪いのではないか、メモリが足りないのではないか、I/Oが少ないのではないか、CPUが足りないのではないか……いろいろな要因があるわけです。これらは、いままで説明した“裏方”のスレッドのどこに問題があるのかを究明していく作業といえます。
すでに気付いている方はいるかもしれませんが、結局これはOSのマルチタスクの制御とまったく同じことを、SQL Serverがやっているということなのです。従来はOSの力を借りてこうした処理を行っていました。ところが、いちいちOSにスーパーバイザーコールでマルチタスクの制御を依頼すると非常に時間がかかりますから、SQL Serverはそういう無駄なことはやめて、全部自分のエンジンの中で一連の制御を完結してしまおうと考えたわけです。極力ユーザーモードで動いて、いわゆるカーネルモードでの動作を最小限にしようというのが、基本的なSQL Serverの設計思想です。
図4はUMSのイベント処理にどういう割り込みの種類があるのかを、もう少し詳しく見たものです。まず「Created」で新規のスレッドを作成します。そのスレッドはまずRunnable Listに行き、そこからさまざまな条件によって図の順をたどっていくわけです。
Copyright © ITmedia, Inc. All Rights Reserved.