誰も知らないメモリ・チューニングの極意を教えよう：Dr. K's SQL Serverチューニング研修（2）（2/3 ページ）

[熊澤幸生, 工藤淳（インタビュアー），エイ・エヌ・テイ/オフィスローグ]

「設定すべきメモリ・パラメータ」を知ることが
無用のCPU負荷を避け、メモリを100％活用する極意

AWEを正しく設定して4Gbytesを超える物理メモリを活用する

　ちょうどよい機会なので、AWEの設定方法について触れておきましょう。「Enterprise Manager」で「SQL Server 2000のプロパティ」を開くことができますが、実はこのプロパティは「sp_configure」環境設定オプションと連動しています。ただし、このプロパティ画面には「AWEを指定する」というチェックボックスがありません（図4）。従って「awe enabled」を有効にしようとすると、やはり「sp_configure」から設定するしかないのです。面倒と感じるかもしれませんが、これができないと、いくら4Gbytes以上の物理メモリを積んでも、SQL Server 2000は通常の動的なメモリ割り当てモードで動作し、4Gbytesまでしかメモリを使用できないのです。

図4　SQL Server 2000のプロパティ画面
「Enterprise Manager」で「SQL Serverのプロパティ」を開き「メモリ」タブを表示したところ。ここからAWEを設定することはできない。

　リスト2にAWEを有効にする設定を載せておきましょう。「awe enabled」を「1」に設定するとAWEが有効になり、SQL Server 2000 Enterprise Editionはアドレス空間のサイズを動的に管理しなくなって4Gbytesを超えるメモリを利用できるようになります。

sp_configure 'awe enabled', 1
RECONFIGURE
GO

リスト2　SQL Server 2000 Enterprise EditionでAWEを有効にする設定

　ちなみに、SQL Server 2005のプロパティ画面では、AWEを設定できるようになっています（図5）。

図5　SQL Server 2005のプロパティ画面（クリックすると拡大します）
「Management Studio」で「サーバーのプロパティ」を開き「メモリ」ページを表示したところ。「サーバー メモリ オプション」からAWEを設定できるようになっている。

Buffer Cacheの領域不足がパフォーマンスを悪化させる

　ここで、さらに詳しくAWEの仕組みを見てみましょう。図6に示した「AWEのアドレス空間」の中で、「Buffer Cache」だけが4Gbytesの仮想アドレス空間を超えてメモリを使用しています。これは「Buffer Cache」のみに仮想アドレス空間の4Gbytes制限を超えて使える機能があることを示しています。これを可能にするのがAWEを設定する目的となります。「Buffer Cache」が4Gbytesの仮想アドレス空間外に逃げることで、結果的にほかのオブジェクトは限られた仮想アドレス空間を有効に使えることになり、パフォーマンスが向上します。

図6　AWEのアドレス空間と4Gbytesの仮想アドレス空間

　そもそもSQL Server 2000には、6種類のメモリ上のオブジェクトがあります。これらのオブジェクトに割り当てられたメモリの合計を設定するのが「sp_configure」環境設定オプションの「max server memory」です。図7ではこれが「4019」（4Gbytes）になっているにもかかわらず、「awe enabled」が「0」のままです。つまり「使える上限は4Gbytes」といいながら、一方で「AWEは使うな」といっているわけですね。これが「メモリはあるのに使えていない」原因です。

図7　「sp_configure」環境設定オプションの「awe enabled」と「max server memory」（クリックすると拡大します）

　上で触れた「6種類のメモリ上のオブジェクト」とは

• Sort／Hash／Index
• User Connections
• Lock Area
• Optimizer Code
• Procedure Cache
• Buffer Cache

ですが、この中で最も重要なのが「Buffer Cache」です。ここにはインデックスページやデータページといった重要なキャッシュが格納されています。メモリ上のオブジェクトをモニタした図8で「Buffer Cache」の数値の高低差に注目すると、合計で1.61Gbytes利用できる合計メモリのうち、多いときは1.4Gbytes近くを使っていますが、ほかのオブジェクトにメモリを食われると最低では0.75Gbytes程度まで落ち込んでしまいます。メモリを取り合った結果生じたこの落差が、SQL Serverのパフォーマンスに大きな悪影響を及ぼすのです。

図8　SQL Serverのメモリ・オブジェクトごとの使用状況（クリックすると拡大します）
パフォーマンス診断ツールを使って、メモリプール（1.61Gbytes）の内訳を1分ごとに約30分間モニタしたもの。赤く示したところは各オブジェクトの最大メモリ使用量。メモリ不足によるオブジェクト間の競合が発生している。

　メモリ不足によるオブジェクト間の競合が発生して「Buffer Cache」が少なくなってくると、LRUというアルゴリズム（第1回参照）が、収まり切らなくなったキャッシュを古いものから順に吐き出していきます。これは少ないメモリを有効に使おうとする機能ですが、吐き出されてしまったキャッシュの中にアクセス頻度の高いデータがあると、次のアクセスではSQL Serverはディスクへそのデータを読み込みにいきます。この結果、メモリに余裕があれば必要なかったはずのCPU負荷やディスクI/Oが繰り返し発生する悪循環が起こり、SQL Serverのパフォーマンスを悪化させます。これがいわゆる「メモリプレッシャー」と呼ばれる現象です。（次ページに続く）