マルチプロセッサマシン上の SQL Server 2000~ システム管理 ~
株式会社 CSK
教育サービス事業部
鈴木 朋夫
2001年11月22日
目次
1. 概要
2. 環境
3. インストール
4.マルチプロセッサマシン上の SQL Server のプロパティ設定
5. 並列処理プラン
1. 概要
SQL Server 2000 を導入される企業では、プラットフォームにマルチプロセッサの機種を選択されることも多いと思いますが、実際には納入されるまでに操作できる機会は少ないのではないでしょうか。
そこで今回は、実際にマルチプロセッサマシンに SQL Server 2000 Enterprise Edition をインストールして、SQL Server と Windows のプロセッサ統合機能を紹介します。
2. 環境
今回のテストには、マルチプロセッサとしては最低限度ですが、デュアル CPU 対応のマザーボートに Pentium IIIを 2 個、ATA (EIDE) ディスクを 2 台、メモリを 512 MB 装着したマシンを使用し、Windows 2000 Advanced Server をインストールしました。
3. インストール
3.1 Windows 2000 の確認
Windows 2000 のインストーラーは、プラットフォームが標準的な構成であればマルチプロセッサを検知し適切なカーネルをインストールします。Windows 2000 がサポートしているコンピュータの種類には次の物があります。
ACPI マルチプロセッサ PC
ACPI ユニプロセッサ PC
ACPI (Advanced Configuration and Power Interface) PC
MPS マルチプロセッサ PC
MPS ユニプロセッサ PC
標準 PC
Compaq SystemPro Multiprocessor or 100% Compatible
Silicon Graphics Visual Workstation
確認は、次のように行います。
[スタート] メニューから [設定] > [コントロールパネル] を選択し、[システム] をダブルクリックします。
[ハードウェア] タブをクリックし、[デバイスマネージャ] ボタンをクリックします。[コンピュータ] の左側の [+] をクリックして下の階層の、コンピュータを右クリックして [プロパティ] を選択します。
図 1 ACPI (Advanced Configuration and Power Interface) PC の場合
図 2 ACPI マルチプロセッサ PC の場合
モダンなマザーボードは、ACPI 機能があります。今回のマシンは図2 の「ACPIマルチプロセッサ PC」が表示されました。
3.2 SQL Server のインストール
マルチプロセッサだからといっても SQL Server 2000 のインストーラーの操作が変わることはないため、特別な操作はありません。
インストール後に SQL Server のプロセスの起動し、[システムモニタ]を使って測定すると、両方の CPU に負荷がかかっていることが分かります。(図3 SQL サーバーのプロセスの起動、ディスク I/O などの負荷が含まれます。)
図 3 SQL Server 2000 を起動させた時の CPU の負荷の変化
3.3 ディスクの書き込みキャッシュ
SQL Server は、メモリで行った変更をログファイルに書き込み(先行書き込みログ機能)、その後データベースの本体のファイルに変更を書き込みます。
このためディスクの書き込みキャッシュが有効で電源に保護が無い場合、停電によりデータベースが矛盾を起こすことがあり得ます。必要に応じて書き込みキャッシュがOFFになっていることを確認します。
図 4 書き込みキャッシュの無効化
3.4 ミラーボリューム
ディスクの障害からデータを保護するために、冗長性(フォールトトレランス)を保つミラーボリューム(RAID1)あるいは RAID5 を使用します。ここでは、Windows 2000 のシステムボリュームにミラーボリュームの設定を行います。
この手順は、[コンピュータの管理]の中の[ディスクの管理]を使って行います。
図 5 ディスクの管理ツール
2 台目のディスクを選択し、右ボタンをクリックして[署名]を選択します。(上の図は署名をした後の状態です。署名前の状態は、ディスク 1 の左側のアイコンに進入禁止マークがついています。またディスクがベーシックディスクになっていることにも注意してください。)
ディスクを選択し、2 台のディスクを「ダイナミックディスク」にアップグレードします。(他の OS とのマルチブートになっている場合は、この操作はしてはいけません。)
図 6 ダイナミックディスクへのアップグレード
この後で再起動が実行されます。
システムディスクをクリックして、[ディスクミラーの作成]を実行します。[再生中]表示が 100 % なると「再生中(システム)」の表示は「正常(システム)」に変化します。これによりミラーの生成が終わり、ディスクが同期していることが確認できます。
図 7 ディスクミラーの最中
4.マルチプロセッサマシン上の SQL Server のプロパティ設定
マルチプロセッサマシン上で SQL Server を実行する場合、Enterprise Manager を使ってサーバーのプロパティで[プロセッサ]に関する設定を行うことができます。
ユニプロセッサでは考えたこともないことですが、SQL Server がどの CPU を使用するのか、スレッドをどのように動作させるかといった事を制御することができます。
4.1 Enterprise Manager からの確認
次の操作で、Enterprise Manager からプロセッサに関する設定を行います。
Enterprise Manager のコンソールツリー内で、SQL Server のアイコンを右クリックして[プロパティ]を選択し、[プロセッサ]タブをクリックします。
次の画面が表示されます。
図 8 プロセッサタブ
4.2 プロセッサ制御
[プロセッサ]タブの内容は[プロセッサ制御]と[並列処理]に別れています。まずプロセッサ制御の設定から見て行きます。
4.2.1 プロセッサ (affinity mask オプション)
Windows NT 4.0/2000 は、マルチプロセッサ環境で実行されている時に、プロセス内のスレッドを複数のプロセッサ間で移動させて実行します。この時、実行するプロセッサを移動したスレッドは、移行するたびにプロセッサキャッシュの再読み込みを行います。
負荷が高いシステムの場合、パフォーマンスを上げるために、プロセッサキャッシュの再読み込み回数を減し、特定のスレッドを実行するプロセッサを指定する機能が提供されています。このプロセッサとスレッドの関連付けを「プロセッサアフィニティ」と呼びます。
SMP (シンメトリックマルチプロセッサ)システムでは、全ての CPU が均等に利用されているかというと必ずしもそうではありません。実際には、Windows NT 4.0/2000 は、ネットワークアダプタカードに関連付ける遅延プロセスコール (DPC) スレッドを、マルチプロセッサシステム内で最も大きな番号で管理されているプロセッサに割り当てています。
このマシンに複数のネットワークアダプタカードがインストールされ、システムが全てのカードをアクティブ化している場合は、DCP スレッドは大きな番号で管理されているプロセッサから個々のカード用の DCP スレッドが1つずつ割り当てられます。
つまり、Windows NT 4.0/ 2000 は、特定プロセッサに OS が処理する特定のタスクを割り当てています。こうしたプロセッサにアプリケーションのスレッドを処理させることで処理効率が下がる場合もあります。
SQL Server 2000 は(7.0 にも存在するサーバーオプションですが)、affinity mask オプションを使用して、こうしたプロセッサに SQL Server のスレッドの割り当てないようにすることができます。
affinity mask はプロセッサをビットで表します。ビットを 1 に設定するとそのプロセッサがスレッドの割り当て先として選択されます。(Enterprise Manager 上では、通常は全てのプロセッサが選択されているはずです。)
デフォルト値では、affinity mask はオール 0(全て選択されているのと同じ)で、この場合は、Windows NT 4.0/2000 のスケジューラー(スケジューリングアルゴリズム)がスレッドのプロセッサアフィニティを設定します。
affinity mask を 0 以外の値に設定すると、SQL Server はその値を選択使用可能なプロセッサを指定するビットマスクと解釈します。
例えば、8 個のプロセッサ(0~7)で構成され、ネットワークアダプタカードが2枚インストールされているシステムでは、カードごとに対応する DPC スレッドがプロセッサ 7 と 6 に割り当てられます。
1、2、4ビットを1に、0、3、5、6、7ビットを0に設定して、プロセッサ 1、2、4 を選択する場合は、16 進値 0x16(10 進値 22、2 進値 00010110)を指定します。ビット番号は右端を0として左に数えています。
affinity mask の指定は以下のようになるはずです。
10 進値 |
2 進ビットマスク |
SQL Server スレッドを処理するプロセッサの番号と数 |
---|---|---|
1 |
00000001 |
0 (1個) |
3 |
00000011 |
0、1 (2個) |
7 |
00000111 |
0、1、2 (3個) |
15 |
00001111 |
0、1、2、3 (4個) |
31 |
00011111 |
0、1、2、3、4 (5個) |
63 |
00111111 |
0、1、2、3、4、5 (6個) |
表 1 affinity mask のパターン例
オンラインマニュアルによれば、affinity mask は 5 個以上のプロセッサを搭載し、高い負荷で動作する SMP システムのパフォーマンスを向上させるために、SQL Server スレッドを特定のプロセッサに関連付けて、使用するプロセッサを指定できると解説されています。
4.2.2 ワーカースレッド最大数 (max worker threads オプション)
SQL Server に接続したユーザをサポートするスレッド数を指定します。SQL Server はこの設定を使ってユーザ接続を処理するスレッド(またはファイバー)のプールを確保しています。原則的に、この値は SQL Server の最大同時接続数に設定しますが、1024 を超える設定はできません。
実際の接続ユーザ数がワーカースレッド最大数より少ない場合は、1 接続ごとに 1 スレッド(またはファイバー)で接続を処理します。ただし、実際の接続数がワーカースレッド最大数を超えると、SQL Server はワーカースレッドプールを構成し、新しい接続を別の接続で利用されていて、使用可能になったワーカースレッドで処理できるようにします。
デフォルト値は 255 ですが、同時接続ユーザ数が少ない場合に、この設定はメモリを無駄にすることがあります。これは設定されたワーカースレッド数がワーカースレッドプールとしてメモリに割り当てられるので、本来バッファキャッシュなどに活用できるメモリリソースが使用されないことになってしまうからです。
同時接続ユーザ数が 255 よりも多いシステムでは、接続ごとにそれを処理するスレッドを1つ割り当てると結果的に大量のリソースが消費され、SQL Server の効率が下がる恐れがあります。また殆どの接続では大半の時間が、実際にはバッチが返されるのを待つことに費やされているため、各ユーザ接続ごとにスレッドを割り当てる必要はありません。
ワーカースレッドプールは、バッチを実質的に同時実行している接続数に対処するサイズ十分なので、同時接続ユーザ数が 255 より多い場合でもワーカースレッド最大数は、デフォルトの 255 で、スレッド(またはファイバー)に効率的に割り当てることができます。
4.2.3 Windows での SQL Server の優先度を上げる
Windows NT/2000 上で実行されるプロセスとスレッドの優先順位は 32 段階に別れています。0 が最低で 31 が最高の優先度を持ちます。スレッドは優先度に基づいてオペレーティングシステムから CPU 時間を割り当てられます。
通常のアプリケーションは 1-15 の可変レベルの中で優先順位を割り当てることができます。16-31 は、リアルタイムレベルと呼びリアルタイム処理を行うアプリケーションが使用することになります。
|
プロセスの優先度 |
プロセスの優先度 |
プロセスの優先度 |
プロセスの優先度 |
---|---|---|---|---|
スレッドの優先度 | リアルタイム | 高 | 普通 | 低 |
Time-Critical |
31 |
15 |
15 |
15 |
Highest |
26 |
15 |
10 |
6 |
Above-normal |
25 |
14 |
9 |
5 |
Normal |
24 |
13 |
8 |
4 |
Below-normal |
23 |
12 |
7 |
3 |
Lowest |
22 |
11 |
6 |
2 |
Idle |
16 |
1 |
1 |
1 |
表 2 プロセスとスレッドの優先度
通常、SQL Server の優先度は 7 となっていますが、[Windows での SQL Server の優先度を上げる]をチェックすることにより、優先度は 13 に上がります。つまりプロセスの優先度が「普通」から「高」に変化することになります。
ただし、スレッドの優先度はオペレーティングシステムにより調整されるため(このため可変レベルと呼ばれる)プロセスの優先度とは異なることがあります。
Books Online では、SQL Server 専用のサーバー以外は、この設定を行わないように推奨しています。
4.2.4 Windows NT ファイバーを使用 (lightweight pooling オプション)
Windows NT 3.51 の SP3 から「ファイバー」機能がサポートされています。ファイバーはスレッドオプジェクトの一部(サブセット)という構造を持つことから、しばしば「ライトウェイトスレッド」と呼ばれます。
ファイバーに関連する関数 (ConvertThreadToFiber, CreateFiber,SwitchFiber など)は主に UNIX から移植されるサーバーアプリケーション用に追加されました。
スレッドとファイバーの決定的な相違は、スレッドの実行はオペレーティングシステムのスケジューラーに制御されますが、ファイバーの実行はアプリケーションが自ら制御できる点です。オペレーティングシステムは、ファイバーの実行に CPU 時間の割り当て(つまり限定)を行ないません。
ファイバーの実行は、ファイバーを含むスレッドがスケジュールされて実行されるまではおこなわれませんが、ファイバーが実行されるとファイバーが終了するか、ファイバーが他のファイバーを実行するように OS に指示するまで実行されます。(すなわちプリエンプションの例外としてファイバーは存在することになります。)
SQL Server は、Windows のスレッドあるいはファイバーを使って、複数のタスクを同時に実行します。SQL Server では、システムプロセスに関して常に複数のスレッドが実行されています。例えば、各サーバー Net-Library 用スレッド、ログイン要求処理用のネットワークスレッド、サービスコントロールマネージャとの通信用のシグナルスレッドを実行しています。
SQL Server は、Windows カーネルを呼び出さなくて済むように、同時実行タスクのスケジューリングと同期を行う、専用スケジューラーをスレッドとして実行します。このスレッドを UMS(ユーザモードスケジューラー)と呼びます。
UMS は、スレッドとファイバーをスケジューリングします。SQL Server は、ユーザ接続処理用のスレッド(またはファイバー)のメモリプールを確保しています。(このプールの最大サイズは、max worker threads オプションで決まります。)
SQL Server は、数の多い(ハイボリュームな)SMP システムでは、ファイバーを使用して性能の向上を実現しています。ファイバーを最適にスケジュールするために、SQL Server は、スレッドを専用のスケジューラーとして使用します。
SQL Server がスレッドとファイバーのどちらを使用するかは[Windows NT ファイバーを使用](lightweight pooling オプション)で決まります。lightweight pooling のデフォルト値は0でスレッドが使用されます。この状態をスレッドモードと呼びます。
[Windows NT ファイバーを使用](lightweight pooling = 1)が設定されると、スレッドの代りにファイバーが使用されます。この状態をファイバーモードと呼びます。
SQL Server はスレッドモードで動作していても、ファイバーモードで動作していても、 1 CPUごとに 1 UMS スレッドを使用して、タスクのスケジューリングと同期を行います。各 SQL Server のプロセスは、プロセスが消滅するまで 1 つの UMS スレッドに関連付けられます。OS は各プロセッサ用の UMS スレッドのスケジュールを管理します。
個々の UMS スレッドは、CPU 時間を割り当てられると、その UMS スレッドに関連した SQL Server プロセスのうちのどれを動かすかを決定します。ただし、拡張ストアドプロシージャや分散クエリを実行するプロセスはUMSで管理されず、OS のスケジューラーが管理します。また、SQL Server のバックアップと復元操作は、それぞれ別の UMS スレッドで管理されます。
SQL Server は、クライアントからバッチを受け取ると、各バッチをワーカープールの利用可能なスレッドまたはファイバーに関係付けます。空きスレッドまたはファイバーがなく、max worker threads に達していない場合は、新しいバッチに新しいスレッドまたはファイバーが割り当てられます。空きスレッドまたはファイバーがなく、max worker threads に達している場合は、スレッドが解放されるまで新しいバッチは待ち状態になります。
スレッドまたはファイバーがバッチに関係付けられると、バッチで作成される最後の結果セットがクライアントに返されるまで、その関係は維持されます。最後の結果セットが返されると、スレッドまたはファイバーが解放され、次に有効なバッチに対してスケジューリングできる状態になります。
5.1 並列処理プラン
クエリの実行プランを並列クエリプランに生成する場合の設定を行います。並列処理プランで設定されるオプションは、サーバーの再起動なしに直ちに有効になります。
5.1.1 使用可能なプロセッサをすべて使用/使用するプロセッサ数 (max degree of parallelism オプション)
[使用するプロセッサ数]の設定は、並列プランの実行に使用するプロセッサ数を制限する場合に使用します。デフォルト設定は、[使用可能なプロセッサをすべて使用]です。(max degree of parallelism = 0 。0 の場合、実際に使用可能な CPU 使用されます。)
アフィニティマスクが設定されている場合は、指定された CPU 数に制限されます。並列プランの生成を行いたくない場合は、[使用するプロセッサ数]を 1 に設定します。
並列プランのクエリの実行に使用されるプロセッサの最大数を制限する場合は、2 以上の値を設定します。最大値は 32 ですが、使用可能な CPU 数を超える値は無視されます。
システム管理者が特定の目的を持って設定する場合を除いて、このオプションを変更する必要はほとんどないと考えられます。
5.1.2 クエリの並列実行を考慮するクエリプランの最小しきい値 (cost threshold for parallelism オプション)
SQL Server が並列プランを作成し、実行する基準となるしきい値を指定します。SQL Server は、クエリを直列で実行した場合の予測コストが[クエリの並列実行を考慮するクエリプランの最小しきい値]の値を超えた場合のみ、クエリの並列プランを作成して実行します。デフォルト値は 5 で、設定可能な範囲は 0~32767 です。(コストとは、特定のハードウェア構成で直列プランを実行するための予想所要時間を秒単位で表したものです。)
実行に使用された並列実行クエリプランのコストが設定値よりも低い場合がありますが、これは実行を予測したときのプランが設定値を超えていたので並列クエリプランが実行されたものです。
[クエリの並列実行を考慮するクエリプランの最小しきい値]の設定を超えるクエリは、
[クエリの並列実行を考慮するクエリプランの最小しきい値]設定は、SMP マシンで、アフィニティマスクで複数のプロセッサが指定されている場合にのみ有効です。利用可能なプロセッサが 1 つの場合、この設定は無視されます。
鈴木 朋夫 : 長年 PC のプログラマをへて 1993 年からインストラクタとして活動しています。株式会社 CSK 教育サービス事業部で主に SQL Server や Windows 2000 などの Microsoft University コースを担当しています。次は教室でお目にかかりましょう。それでは。