前回の投稿でパフォーマンスモニタのログが取得できるようになりましたので、WOW64 のメモリの使用状況を確認していきたいと思います。

WOW64 を使用していない環境 (32bit 環境) では SQL Server のメモリ使用状況は以下のようになります。

■/3GB なし

■/3GB あり

/3GB なしで 1.6GB ,/3GB ありで 2.6GB のメモリが使用できています。

 

それでは、WOW64 で動作している SQL Server 2008 R2 / Denali で同様の情報を取得してみます。

■SQL Server 2008 R2

■Denali

WOW64 のアプリケーションの場合、ユーザーモードの領域は 4GB 使用することができます。
そのため、32bit の SQL Server ではありますが、2GB 以上のメモリを使用することが可能です。
# 64bit の OS のため、/3GB スイッチも設定はないですし。

SQL Server 2008 R2 と Denali の WOW64 のメモリ使用状況を比較すると、プランキャッシュの上限に少し差が出ているようでした。
SQL Server 2008 R2 では、プランキャッシュが 1.5GB 程確保できているのですが、Denali では、1GB で頭打ちとなっています。
データとプランで使用しているメモリ合計については両バージョン共に 3.5GB となっているので、WOW64 で使用できるメモリの上限は共に同じになっていることが確認できます。
# 32bit / 64bit 共に、ユーザーモードのメモリ空間をフルには使えないみたいですね。32bit の場合は、1.6GB ぐらいで頭打ちになりますし。この辺はどうしてこのようになるのかをきちんと勉強したいと思います。

参考ではありますが、WOW64 を使用した場合のメモリについては以下の技術情報に記載がされています。
メモリ アーキテクチャ

 

WOW64 で AWE を有効にした場合どうなるかも合わせて試してみました。

■SQL Server 2008 R2 (AWE)

■Denali (AWE)

WOW64 + AWE を使用すると、4GB をフルに使用することができていますね。
# WOW64 + AWE で動作させても変わらないんだろうな～と思っていたので、ちょっと意外でした。
ただし、AWE を使用しても 4GB 以上のメモリを使用することはできていません。
また、AWE を使用することで、設定前と比較して400MB 程度使用可能なメモリが増えているのですが、この増加分はデータベースキャッシュに割り当てられており、プランキャッシュに関しては、1.5GB から変化していません。
このあたりの動きは通常の AWE と同様になるようですね。

現状、Denali では、AWE はサポートしていませんので、AWE を有効にしてもメモリのトレンドは変わりません。

AWE と WOW64 について、数回に分けて投稿してきましたがその検証で取得した値を表にしてみました。
# 数値は SQL Server 2008 R2 のものとなっており、() 内は Denali の値になります。

	データベースキャッシュ(最大)	プランキャッシュ (最大)	利用メモリ (メモリ6 GB 搭載時)
/3GB なし	1.0 GB (1.0 GB)	900 MB (700 MB)	1.6 GB (1.5GB)
/3GB あり	1.5 GB (1.5 GB)	1.5 GB (1.2GB)	2.6 GB (2.5 GB)
AWE	4.1 GB (1.0 GB)	850 MB (700 MB)	4.2 GB (1.5GB)
AWE + /3GB	4.0 GB (1.5 GB)	1.4 GB (1.2GB)	4.1 GB (2.5 GB)
WOW64	3.0 GB (3.0 GB)	1.6 GB (1.0 GB)	3.5 GB (3.5 GB)
WOW64 + /3GB	4.0 GB  (3.0 GB)	1.6 GB(1.0 GB)	4.0 GB (3.5 GB)

# これらの値はあくまでも参考値ですので、環境によって変化します。

SQL Server のエンジニアの端くれなので、診断で環境を見たことはあるのですが自分でデータをとってまとめるという機会がなかったので、今回の投稿はよい機会でした～。

あらためて SQL Server と AWE の最後の投稿として、AWE を有効にしている場合のメモリ情報の取得についてまとめていきたいと思います。

今まで、DBCC MEMORYSTATUS やパフォーマンスモニタでメモリの情報を取得してきました。
特定のアプリケーションのメモリを取得する際には、タスクマネージャやパフォーマンスモニタの Process でワーキングセットを取得する方法もあるかと思います。

AWE を有効にした状態でタスクマネージャーの [sqlserver.exe] のプライベートワーキングセットを確認してみます。

92 MB となっていますね。
パフォーマンスモニタで [sqlserver.exe] の [Working Set] を確認してみます。

平均が [116,969,472] Byte となっています。

DBCC MEMORYSTATUS で SQL Server から使用しているメモリを確認してみます。

AWE Allocated は [4,235,376] KB となっていますので、4GB 程度のメモリが使用されています。

AWE が有効になっている環境でのメモリ取得に関して、技術文書に以下の記載があります。
SQL Server での AWE メモリの有効化

SQL Server のパフォーマンス モニターの Total Server Memory (KB) カウンターを使用して、AWE モードで実行されている SQL Server のインスタンスによって割り当てられたメモリ量を特定するか、sysperfinfo からメモリの使用量を選択します。

AWE を有効にしている場合はプロセスからではなく、SQL Server のパフォーマンスモニタから情報を取得します。

SQL Server が使用しているメモリの合計は、

• Buffer ManagerTotal pages
• Memory ManagerTotal Server Memry (KB)

の何れかで取得することが可能です。

以下の画像が情報を取得したものになります。

Total pages は 8KB ページの数が表示されますので、サイズにするためには
540,672 ページ × 8KB = 4,325,376 KB となります。

Total Server Memory (KB) に関しては KB 表示そのままですね。
両方とも同じ値となりますのでどちらから値を取得しても問題はありません。

SQL Server の現状を見るときには基本的に SQL Server 用のカウンタから追っていくことになります。
現状のメモリ使用状況だけを軽く見たいといった時でも SQL Server のカウンタを使うことで正確な値を取得することができます。

 

6 回に分けて AWE についてまとめてみました。
64bit 化が進んでいる中で、32bit の SQL Server を使用する機会はそれほどないかとは思いますが、SQL Server のメモリの使用状況を勉強するということではいい機会だったと思います。

次の投稿では WOW64 の SQL Server についてまとめてみたいと思います。

今回は Denali の AWE についてまとめていきたいと思います。

32bit の Denali でも AWE を設定することができます。

DBCC MEMORYSTATUS で Memory Manager を確認すると AWE Allocated によるメモリ割り当てがされていることが確認できます。

それでは、どれくらいのメモリが割り当てられるかを試してみたいと思います。
# /3GB スイッチは無効にしてあります。

このグラフの情報は AWE を有効にしている状態で取得をしているのですが、メモリが 1.4GB 程度で頭打ちになっています。

AWE について SQL Server 2008 R2 の BOL で確認をしてみました。
awe enabled オプション

この機能は、Microsoft SQL Server の次のバージョンで削除されます。
新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションはできるだけ早く修正してください

 

SQL Server 2008 R2 の段階で、AWE は次バージョンで削除されることになっています。
# SQL Server 2008 ではこの記載はありませんでしたので、2008 R2 になって明記されたものになります。

SQL Server で実行されているクエリのトレースを取得できるツール、SQL Server Prolifer には [Deprecation] というイベント カテゴリが用意されており、このカテゴリに含まれるイベント クラスを取得すると実行されている SQL が次バージョンでサポートされるかを確認することができます。
Deprecation イベント カテゴリ

それでは、SQL Server 2008 R2 で [awe enabled] を有効にするクエリを実行してイベントを取得してみたいと思います。

[sp_configure] で [awe enabled] を設定しようとすると、[Deprecation Announcement] イベントが発生しているのが確認できます。
メッセージンは以下の内容が表示されています。

sp_configure ‘awe enabled’ は、今後のバージョンの SQL Server では削除される予定です。 新しい開発作業ではこの機能の使用を避け、現在この機能を使用しているアプリケーションでは変更を検討してください。

SQL Server Plofiler からも、[awe enabled] に関しては削除対象となっていることが確認できます。

それでは、Denali で [awe enabled] を設定するとイベントが発生するかを確認してみたいと思います。

sp_configure ‘awe enabled’ will be removed in a future version of SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use it.

Denali でも 、[Deprecation Announcement] が発生しています。
sp_configure で awe enabled は設定ができているので、構文が使用できるかどうかで見るとこのイベントの発生で正常だと思います。

ただし、メモリが使えるかというと簡単に試したところ、通常のユーザーモードの空間内のメモリしか使えていないようですね…。
/3GB スイッチに関しては想定通りの動きとなり、2GB 以上のメモリ空間の利用が可能となります。

現在は CTP 版なので設定できているのかもしれませんが、SQL Server 2008 R2 の BOL に削除されていると記載されている以上、Denali で AWE が使えると思えるのは危険な気がしますね。

検証した感じでは、32bit の Denali のメモリ割り当ては以下のようになりそうです。

ここまでの投稿で、メモリの情報を取得しながら AWE の動作を簡単に確認してきました。
次の投稿では、AWE 有効時のメモリの使用状況の取得についてまとめたいと思います。

前回の投稿で、プランキャッシュの上限について少しまとめてみました。
AWE を有効にしても、プランキャッシュはユーザーモードの中に確保がされますので使用できるメモリは増えません。

プランキャッシュの上限を増やすためには AWE ではなく、/3GB スイッチを利用します。

/3GB スイッチを使用した場合のプランキャッシュの利用状況は以下のようになります。

/3GB スイッチを設定する前は、900 MB 程度だったメモリが、スイッチを設定することにより、1,400 MB 程度まで増加しています。

プランキャッシュですが、Visible ターゲットメモリのサイズに応じて上限が設定されます。
Visible ターゲットメモリは通常のメモリ割り当て (AWE 設定なしで割り当てられるユーザーモード空間) の上限になります。
32bit の場合は 2GB または、3GB が上限となります。

/3GB スイッチを設定しても 3GB のプランキャッシュが設定できるわけではないので注意が必要です。
# いろいろと試してみたのですが、2GB:900 MB / 3GB : 1.4 GB 程度が上限になりそうでしたが、。情報を見ている限りは 75% 取れそうな気もするのですが、これは64bit だけなのかもしれないですね。

/3GB スイッチと AWE を併用した場合のメモリ使用状況はこのようになります。

/3GB スイッチを設定していない場合と比較すると、プランキャッシュの使用状況が増加していることが確認できます。

/3GB スイッチの注意ですが、このスイッチは 16GB を超えるメモリでは使用することができない点です。
AWE の使用

コンピューターに 16 GB を超える使用可能な物理メモリがある場合、オペレーティング システムで 2 GB の仮想アドレス空間がシステム用に必要になるため、サポートできるユーザー モード仮想アドレス空間は 2 GB だけになります。
オペレーティング システムで 16 GB を超えるメモリ範囲を使用するには、Boot.ini ファイルから /3gb パラメーターを削除する必要があります。
このパラメーターがあると、システムで 16 GB を超える物理メモリを使用できません。

プランキャッシュの上限を考えるとできるだけ 64bit のSQL Server を使用したいところですね。

今回は SQL Server 2008 R2 で検証をしていました。
Denali でも 32bit の SQL Server は引き続き提供されます。

次の投稿では、Denali で AWE を有効にした際の動作をまとめていきたいと思います。

AWE を使用すると AWE によってマッピングされたユーザーモード (2GB) を超える領域はデータキャッシュでしか使用されないということを聞くことがあるかと思います。

今回はデータキャッシュとプラン (クエリ) キャッシュについてまとめていきたいと思います。

AWE を使用すると以下のようにメモリを使用することが可能となります。

SQL Server のパフォーマンスモニタでは以下のメモリの情報を取得することが可能です。

以下は Denali で取得できる情報になります。
# SQL Server のバージョンによっては項目が違うのですが、似たような情報は他の項目から取得することができます。

• Connection Memory
• Database Cache Memory (Database pages)
• Free Memory
• Granted Workspace Memory
• Lock Memory
• Optimizer Memory
• SQL Cache Memory (Cache Pages)

これと上の図をマッチングしてみます。

ユーザーモードの領域を超えて割り当てが可能なのは [Database Cache Memory] となります。

それではこのあたりの動きを確認していきたいと思います。
まずはデータベースキャッシュメモリを確認してみます。

今回は SQL Server 2008 R2 の環境を使用しています。
# Denali を使用していないのには理由があるのですが、これは別の機会にまとめる予定です。

■AWE を設定していない状態のデータベースキャッシュメモリの使用状況

まずは AWE を設定していない状態でのデータベースキャッシュメモリの使用状況を確認してみます。
データベースキャッシュメモリはデータをキャッシュするために使用されます。

今回は 17 GB 近いデータが格納されているテーブルを用意しました。

このテーブルに対して SELECT を実行して、データベースキャッシュの状態を確認していきたいと思います。
SELECT は SSMS で実行しているのですが、SSMS のプロセスで余計なメモリを消費されないように実行結果はファイルとして出力しています。
# グリッドやテキストで SSMS 上に結果を表示すると SSMS でメモリを消費してしまいますので。

以下のグラフはサーバーの空きメモリとデータベースキャッシュの状態をグラフにしたものです。

AWE を有効にしていないため、メモリを最大限使用できていないことが確認できます。

それでは、AWE を有効にして同様のデータを取得してみます。

■AWE を設定しいる状態のデータベースキャッシュメモリの使用状況

AWE を設定している状態では以下のようなメモリ使用状態となります。

先ほどと比較して、データベースキャッシュに使用できるサイズが増加していることが確認できます。
AWE が有効に働いていますね。

 

それでは、同様の情報をプランキャッシュでも取得してみたいと思います。

■AWE を設定していない状態のプランキャッシュメモリの使用状況

今回は大量のアドホッククエリを動的に生成して EXEC するクエリを実行して、プランキャッシュにアドホッククエリを大量にキャッシュするようにしてテストをしています。

AWE は設定していないので、プランキャッシュとしては 900 MB 程度が上限となっています。

それでは、AWE を設定して情報を取得してみます。

■AWE を設定している状態のプランキャッシュメモリの使用状況

プランキャッシュに関しては AWE の恩恵が受けられない領域となります。
そのため AWE の設定有無によるメモリ使用量の変更はありません。

AWE を設定してもプランキャッシュは通常のユーザーモードのメモリ空間の中でしか確保ができませんので、AWEの有効有無による差が発生しません。

最後に AWE を有効にした状態で、データベースキャッシュとプランキャッシュを最大限使われるようにした際の情報を取得してみたいと思います。

データベースキャッシュが増加した後にプランキャッシュを増やすようにしています。
# サーバーのスペック的に両方を同時に増加させようとすると結構時間がかかりそうだったもので。

途中からプランキャッシュが増えるようにしていますので、プランキャッシュの増加に合わせてデータベースキャッシュのメモリが減っていります。

AWE を有効にしてもプランキャッシュの上限は変わりません。
プランキャッシュの上限を増やすためには、/3GB スイッチを利用します。

次の投稿では、AWE と /3GB スイッチの併用についてまとめていきたいと思います。

前回の投稿では AWE の設定と設定後の確認について投稿しました。

今回は [動的メモリ] についてまとめていきたいと思います。

SQL Server では [min server memory] と [max server memory] を使用した動的なメモリ割り当てを行うことができます。
この 2 つの値設定することで、SQL Server がどの範囲でメモリを使用するかを指定することができます。
# min server memory はメモリ割り当て後の解放をどの程度まで許容するかの設定で、起動時に確実に確保する設定ではありませんが。

AWE の動的なメモリ割り当てについてですが、以下の技術情報が掲載されています。
SQL Server での AWE メモリの有効化

この中に、以下の記載があります。

Windows 2000 オペレーティング システム上で実行される SQL Server では、AWE マップ メモリの動的割り当てがサポートされていないため、インスタンスごとに max server memory オプションを設定することをお勧めします。

Windows Server 2003 上の SQL Server では、AWE メモリの動的割り当てがサポートされます。

AWE の動的メモリ割り当てに関しては、OS によってサポートの有無が変わってきます。

Windows 2000 Server では動的メモリがサポートされていないため、SQL Server が起動時に可能な限りのメモリを Committed にします。
そのため、[max server memory] を指定することで SQL Server が使用するメモリの条件を設定しておきます。

Windows Server 2003 では動的メモリがサポートされ、SQL Server の起動時には、必要最小限のメモリのみを Committed にして、後は必要に応じて動的にメモリを割り当てます。
動的メモリがサポートされていますので、[min server memory] と [max server memory] を指定しなくても最小限のメモリから必要となるメモリのみを確保していく設定となります。
動的メモリがサポートされていても、サーバー上で稼働しているアプリケーションに影響を及ぼさないように [max server memory] は設定をしていた方が良いとは思います。

書籍によっては、[min server memory] と [max server memory] を同一値に設定して、固定メモリ設定とすると書かれているものがありますので、固定メモリ化するのが良いのかもしれないですね。

 

それでは、AWE の動的メモリ設定についてみていきたいと思います。
今回は SQL Server のバージョンではなく、OS のバージョンによって差が出るということを確認したいため、Windows 2000 Server と Windows Server 2008 上に SQL Server 2005 SP3 の環境を構築しています。
どちらの SQL Server も min server memory = 0 / max server memory =4096 に設定しています。

■Windows 2000 Server の AWE

 

まずは、Windows 2000 Server の AWE 有効時のメモリ割り当てについて見ていきたいと思います。
SQL Server 2005 でも DBCC MEMORYSTATUS は使用できますので AWE Allocated の値を確認してみます。

起動直後の状態なのですが、3,326,920 KB のメモリが割り当てられているのが確認できます。
今回の環境ではメモリは 4GB 割り当てています。
# 物理メモリ 4GB に対して、SQL Server の割り当てメモリが 4GB なのでこのような割り当て状況になっています。

この環境では、AWE を使用しても 3GB と少しが SQL Server のメモリ割り当ての上限のようですね。
この状態では、物理メモリを確保していますが SQL Server 上では大半のメモリは [Free Pages] として認識されています。

以下の画像はパフォーマンスモニタで [Buffer ManagerFree Pages] を取得した内容になります。

平均して [414,107] ページの空きがあります。
414,107 ページ = 414,107 × 8 KB = 3,312,856 KB
となりますので、メモリを確保していても大半が Free Page として認識されています。

■ Windows Server 2008 の AWE

それでは、Windows Server 2008 の SQL Server 2005 でも同様の確認をしてみたいと思います。

Windows Server 2008 の場合は、Windows Server 2003 と同様に動的メモリがサポートされています。
そのため、SQL Server の起動時には必要最小限のメモリのみを確保した状態で起動がされます。

Windows 2000 Server と同様に、Free Page の状態を確認してみます。

Free Page のサイズは、
73 ページ = 73 × 8 KB = 592 KB
となりますので、確保しているメモリの大半は Free Page ではなく起動に必要な領域となっていることが確認できます。

 

■SQL Server 2000 で AWE を確認

先ほどは AWE を SQL Server 2005 で確認をしてみましたが SQL Server 2000 SP4 (8.00.2039) でも確認をしてみたいと思います。

SQL Server 2000 でも DBCC MEMORY STATUS は使用できます。
表示形式が SQL Server 2005 とは異なるのですが、[Buffer Distribution] からメモリを確認することができます。
今回は Windows 2000 Server 上に SQL Server 2000 をインストールしていますので、サービスの起動時は可能な限りのメモリが割り当てられます。

SQL Server 2000 の場合は KB ではなく、ページ数で表示がされます。
250,755 ページ = 250.755 × 8KB = 2,006,040 KB
となります。

SQL Serve 2000 では、Free Pages からはうまく値を取得できなかったので、[Memory ManagerTotal Server Memory (KB)] から情報を取得しています。

平均して、[2,021,680 KB] となっています。

4 GB のメモリを搭載した環境で、AWE を有効にして 2GB のメモリ割り当てというのは少し気になりますよね。
SQL Server 2000 SP4 用に以下の修正プログラムが提供されています。
[FIX] 32 ビット版の SQL Server 2000 SP4 を実行するコンピュータで AWE を有効にすると使用できないメモリ領域がある

SP4 では AWE を有効にしても物理メモリの半分までしかメモリが使用できないという不具合があります。
修正プログラムを実行して再度メモリの使用状況を確認してみます。

421,092 ページ = 421,092 × 8KB = 3,368,736
になりますので、先ほどの SQL Server 2005 の時と同程度のメモリが割り当てられています。

修正プログラムを適用すると Free Page の状況も正常に取得することができました。

421,083 ページ = 421,083 ページ × 8 KB = 3,368,664 KB
になりますので、大半が Free Page となっているのが修正プログラムを適用すると確認ができます。

 

AWE を有効にすると AWE によってマッピングされた 2GB を超える領域はデータキャッシュのみで使用でき、クエリキャッシュはユーザーモードの空間 (2GB の空間)  でしか使用できないという話をよく聞くことがあると思います。

次の投稿では AWE で有効にしたメモリの使用状況についてまとめたいと思います。

32 ビットの SQL Server で大容量のメモリ割り当ての手法として AWE (Address Windowing Extensions) という設定があります。

これから数回に分けて AWE についてまとめていきたいと思います。

■SQL Server の最大メモリ

32 ビットの SQL Server 2008 R2 の最大メモリは以下のようになります。
SQL Server 2008 R2 のインストールに必要なハードウェアおよびソフトウェア

エディション	最大メモリ
Datacenter	オペレーティング システムの最大容量
Enterprise	オペレーティング システムの最大容量
Standard	64 GB

 

32 ビットの SQL Server ではユーザーモードの VAS (仮想アドレス空間) は 2GB または 3GB となり、それ以上のメモリを使用するためには AWE を使用する必要があります。

AWE に関しては以下の技術情報の絵がわかり易いと思います。
プロセス アドレス空間

AWE を使用することでユーザーモードの VAS の一部を使用して、利用できるメモリの領域を拡張することが可能となります。

■AWE を使用するための必須となる前提設定

AWE の使用有無に関しては、SQL Server で設定をするのですが、使用するためには必須となる設定があります。

それが [ローカル セキュリティ ポリシー] の設定です。

ローカル セキュリティ ポリシーで、[メモリ内のページのロック] という権限を SQL Server のサービス起動アカウントに付与する必要があります。
# 英語では、[Lock Pages in Memory] と呼ばれているものになります。
Lock Pages in Memory オプションを有効にする方法 (Windows)

初期設定ではこのポリシーにはどのユーザー / グループも設定はされていません。
SQL Server をローカルシステムで実行していると、ポリシーを設定していなくても AWE を使用することが出来たりするのですが、サービスの専用ユーザーを作成して SQL Server を実行している場合は、このポリシーにサービス用のユーザーを設定する必要があります。

AWE が正常に有効化されていると以下の SQL Server のログに以下のメッセージが表示されます。

Using locked pages in the memory manager.

AWE が有効になっていない場合は以下のメッセージとなります。

Using conventional memory in the memory manager.

 

■ログ以外で AWE が有効になっているかを確認

先ほどはログから AWE が有効になっているかを確認しましたが、他の方法でも確認することができます。
[DBCC MEMORY STATUS] を実行することで、AWE によりメモリが割り当ての情報を取得できます。
[Memory Manager] や他のセクションの情報から [AWE Allocated] を確認することで AWE によるメモリ割り当てが行われているかを確認することができます。

以下が、AWE が正常に動作しているときの情報になります。

[AWE Allocated] に情報が出力されていますね。

AWE が有効になっていない、メモリ内のページのロックが有効になっていない場合は以下のような情報となります。

AWE が使われておらず、通常のメモリ割り当てが行われていますので、[VM Committed] としてメモリが割り当てられているのが確認できます。

ログから見ると実際に使われているかが不安になることがありますので、DBCC MEMORYSTATUS を実行して数値として確認をした方が安心かと思います。

ここまでの設定で AWE を知っている方ですと、[max server memory] と [m
in server memory] の設定は? と思われるかもしれません。

次の投稿でこの辺の設定が影響する、[動的メモリ] についてまとめていきたいと思います。