SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Server の 3 種類のメモリモデル

leave a comment

8/4 (土) の SQLTO 第5回勉強会 の内容に含めようかと考えたのですが、ちょっと話が膨らみすぎてしまいそうなのでブログでまとめてみたいと思います。

技術情報としては以下の SQL Server Premier Field Engineer Blog の記事がまとまっているかと思います。

SQL Server memory models (Part I)
SQL Server memory models (Part II)

詳細は CSS SQL Server Engineers のこちらの記事で。
SQL Server and Large Pages Explained….

■メモリモデルの種類


バッファプール (データやクエリのキャッシュで主に使われる領域) のメモリモデルには以下の 3 種類があります。

  • 従来モデル
    通常の設定
  • AWE モデル
    SQL Server のサービスアカウントにメモリ内のページのロック (Lock Page in Memory : LPM) を付与
  • ラージページモデル
    AWE モデルの設定 + 物理メモリ 8 GB 以上 + TF834

特に設定をしない場合は 従来モデル (Conventional : Conventional  Model) でのメモリ割り当てとなります。
この場合、 Small Page でのメモリ割り当てとなるようで、4KB 単位 (IA 64 の場合は 8KB 単位) でメモリ領域を確保するようです。
メモリ管理
# WOW64 の技術情報ですが x64 ネイティブで実行する場合の参考になるかと。

 

AWE モデル (AWE Model : MMAWE) は Lock Page in Memory を使用したメモリの割り当てになります。
Address Windowing Extensions

SQL Server 2012 では AWE を利用して 32 ビットメモリ割り当ての拡張 (2GB or 3GB (/3G) 以上のメモリ割り当て) はすることはできませんが、Lock Page in Memory (LPM) を使用してロックされたメモリとしてメモリを確保する機能は引き続き使用することができます。
SQL Server 2012 の 32 ビット (x86) を使用した場合のメモリ上限については The "awe enabled" SQL Server feature is deprecated で公開されています。
# LPM も AWE API を利用したメモリ割り当てといわれることがあるのですが、こちらは引き続き使用できます。

SQL Server 2008 R2 までは Standard Edition で LPM を使用する場合、トレースフラグの設定 (TF845) が必要でした。
SQL Server 2005 Standard Edition 64 ビット システムまたは SQL Server 2008 Standard Edition 64 ビット システムでのロックされたページのサポート

SQL Server 2012 では Standard Edition を使用していても、トレースフラグの設定が不要となっています。
How to enable the "locked pages" feature in SQL Server 2012

AWE モデルはメモリ確保時にロックされたページとして確保をしますので、他のプロセスでメモリが必要になった場合のワーキングセットのトリミングを防ぐことができるようになります。これについては、8/4 の勉強会でお話をさせていただく予定です。

ワーキングセットのトリミングが発生すると、バッファプールの内容が瞬間的に大量にページアウトされるためパフォーマンスに大きな影響が発生します。AWE モデルを使用する目的としてはこのワーキングセットのトリミングを防ぐ点が一番に挙げられるかと思います。
image

なお、LPM を設定した場合は Max Server Memory を指定して、SQL Server が使用するメモリの上限を設定するのが推奨となります。
# ワーキングセットのトリミングが発生しない設定で他のプロセスでメモリが必要になると、メモリが圧迫してしまいますので上限を設定しておきます。

機能が有効になっている場合、SQL Server の ERRORLOG に以下のメッセージが表示されますので、これで有効になっているかの判断をすることができます。
image

AWE モデルを使用したメモリ割り当ての場合、VirtualAlloc function を MEM_PHYSICAL を指定して実行されています。
この状態では、MEM_PHYSICAL での指定ですのでメモリの確保は Small Page (4KB) で行われているかと思います。

AWE モデルで割り当てられたメモリに関してはワーキングセット (WorkingSet) ではないためタスクマネージャーやパフォーマンスモニターのプロセスからは使用しているメモリを判断することができません。
# コミット済みの仮想メモリを見ることである程度の確認はできるのですが。
AWE モデルを使用している場合は awe enabled オプション に記載されているように Total Server Memory や他のカウンターからメモリの使用状況を把握する必要があります。

なお、SQL Server 2008 以降では、sys.dm_os_process_memory という DMV が使用できるようになっており、この DMV の locked_page_allocations_kb から AWE モデルで取得されているページを確認することができます。

 

最後のモデルが ラージページモデル (Large Page Model : MMLarge) となります。

これは LPM + TF 834 を指定した場合に使用することができます。
Tuning options for SQL Server 2005 and SQL Server 2008 when running in high performance workloads

8GB 以上のメモリを SQL Server に搭載している場合、ERRORLOG に以下のメッセージが 出力されます。
image

SQL Server  2012 ですと上記のメッセージしか出力されないのですが、SQL Server 2008 R2 だと以下のようなメッセージが追加で出力されています。
image

これらのメッセージが出力されている場合はラージページモデルを使用することができるようになります。

このメッセージが出力されているだけではラージページモデルを使用できるというだけで、LPM + TF 834 を設定することでラージページモデルを使用することが可能となります。
ラージページモデルで動作している場合は、ERRRORLOG に [Using locked pages in the memory manager] ではなく [Using large pages in the memory manager] と出力されます。

image

ラージページでメモリを確保する場合 VirtualAlloc function が MEM_LARGE_PAGES で確保され GetLargePageMinimum によると最小で 2MB 単位となるようです。
# ERRORLOG の 2097152 は API で取得したラージページの最小値を粒度として出力しているそうです。

ERRORLOG には、Large Page Allocated : 32 MB として出力がされていますので、粒度としては 2MB を使用して 32MB を一つのまとまりとして主にメモリを取得しているのかなと思うのですがこの辺の情報がみあたらないのですよね。
# 情報をお持ちの方がいらっしゃいましたらコメントいただけると幸いです。

Managed Heap Virtual Memory によると x64 では 2MB / IA64 では 16MB がラージページの粒度となるようですね。

このログが出力されることでラージページモデルで動作をすることができるようになります。
このモデルの特徴としてはラージページでメモリを確保するということもあるのですが、以前 VMMap でみる TF834 の設定 で紹介したように SQL Server のサービス起動時にメモリをコミットする点もあると思います。

OS 上でメモリの断片化が進んでいる場合などは、ラージページによるメモリの割り当てができずエラーになりサービスが起動できないということもあるようですので、設定後は OS を再起動をして連続したメモリを確保できるようにするのが良いかと思います。

ラージページでメモリを割り当てることで、TLB の参照コストを減らすことができるようですね。
# 仮想アドレスキャッシュと物理アドレスキャッシュ が参考になります。

なお、ラージページで取得されたメモリに関しては sys.dm_os_process_memory large_page_allocations_kb で確認することができます。
# ラージページが使用されていない場合、この値が増えてないと思います。

この辺の動作は SQL Server 特有ということではなく Windows の通常の動作 の中で実現されているので OS の基本動作をもっと勉強しないとな~と痛感しました。

インサイド Microsoft Windows 第4版〈上〉 (マイクロソフト公式解説書)インサイドMicrosoft Windows第4版〈下〉 (マイクロソフト公式解説書) を読んでもっと勉強しないとですね。

Share

Written by Masayuki.Ozawa

7月 20th, 2012 at 9:04 am

Posted in SQL Server

Tagged with

Leave a Reply