Agenda はじめに メモリ って何だろう? SQL Server で使うメモリ メモリ関連の設定 メモリ周りのトラブル モニタリング
はじめに 全体のテーマ 本セッションでは SQL Server のメモリを理解するための知識とその挙動を説明します ゴール メモリに関わる知識を整理し わからない単語を無くす 自分の関わるシステムをメモリを切り口に振り返ってみる トラブルが起きたときに何が起きたのか想像できるようになる
メモリ って何だろう? 物理メモリと仮想メモリ 物理メモリと仮想メモリの違いは説明できますか? malloc や new で確保できるメモリはどちらでしょうか? 物理メモリについて 物理メモリはマザーボードに刺さっているあの メモリ 物理メモリの詳細については今回は触れない 内部の動きはハードウェア屋さんへ
メモリ って何だろう? 昔は仮想メモリなんて無かった プログラムが使うメモリ = 物理メモリ ( 少ない ) マルチスレッドで動かすことは稀だった プログラムが OS を暴走させるなんて当たり前だった もう我慢の限界!! もっとメモリが使いたい! プログラム間でメモリのやりくりなんてしたくない! ちょっとくらいマナーが悪いプログラムも許してくれ!
メモリ って何だろう? そこで仮想メモリです プログラムごとに独立した ( 比較的大きな ) メモリ空間 独立しているからプログラム同士が干渉しあわない 物理メモリサイズ以上の大きさの空間を使える OS の動作は保護される 等々のメリットがある 昨今の OS は全て仮想メモリが利用できます
メモリ って何だろう? 仮想メモリとは プロセスごとに用意された仮想のメモリ空間 プロセスは仮想メモリに対して読み書きを行う OS は仮想メモリアドレスを物理メモリアドレスに変換する Windows では 32 ビットの場合 4G が表現上の最大 OS とプロセスでそれぞれ 2GB まで使える
メモリ って何だろう? Address 仮想メモリ Page Director y Page Table 物理メモリ CR3 レジスタ
メモリ って何だろう? 用語 ワーキングセット ページング TLB (Translation Look aside Buffer) ページファイル 説明 プロセスが使っている仮想メモリの内 物理メモリに乗っているメモリページ ワーキングセットの内 あまり使われないメモリをページファイルに書き出す またはページファイルから物理メモリに書き戻す動作 仮想アドレスと物理アドレスの変換テーブルをバッファリングする領域 プロセッサ上に存在する 物理メモリからページアウトされたデータを待避するファイル
メモリ って何だろう? 用語ヒーププール仮想メモリの状態 perfmon 説明 プロセスごとに存在するメモリの 山 メモリ要求を出すと 適宜切り出して使える 戻すと山に残っている隣り合ったメモリのかたまりとくっついて 次の要求に備える Malloc や new で取られる カーネルが持っているメモリの 池 OS やカーネルが使うメモリ ページプールや非ページプールなどがある ページング処理より高いレベルで動作する場合は非ページプールを使う必要がある Committed/Reserved/Free の 3 つがある 利用されている場合は Committed 後から使うので予約しておきたいときは Reserved パフォーマンスカウンタ Windows OS では標準的にパフォーマンス取得に利用される SQL Server のカウンタも取得できる 内部的にはレジストリアクセスし 定期的に計上される値を取得する
SQL Server が使うメモリ Buffer Pool Data Page Cache Plan Cache Lock Sort Mem To Leave Buffer Pool 8kb で管理され メモリ空間の大半を占める Data Page Cache Plan Cache Lock Sort Mem To Leave 8kb で収まらないオブジェクトの管理や非定型な利用が多い Call Stack CLR/Xp
SQL Server が使うメモリ Buffer Pool の管理方法 LRU-K アルゴリズム よく使われるものはメモリ上に残る 8KB の単位で利用される Cache Hit オブジェクトを要求したとき そのオブジェクトがメモリ上にあった Cache Hit!! ディスク I/O を伴わない分 Cache Hit した方が効率がよい
SQL Server が使うメモリ バッファプールとディスク I/O LRU-K アルゴリズムでデータはメモリから追い出される バッファのデータはデータファイルへ書き込まれる 書き込みは Lazywriter が行う Lazywriter 定期的にメモリをチェックし 不必要なデータをファイルに書き出す メモリ不足 (= メモリプレッシャー ) になってくるとチェック間隔が短くなる
SQL Server が使うメモリ 仮想メモリの上限 32 ビットの場合 4G が表現上の最大 2^32 = 4G 32 ビットでは OS とプロセスでそれぞれ 2GB まで使える ユーザ空間を 3GB にすること (4GT) が可能だが非推奨 http://support.microsoft.com/kb/171793/ja ページテーブル不足 プール不足を招く 64 ビットは現時点では事実上の無制限
メモリ関連の設定 起動直後 最大拡張 縮小 最大サイズと最小サイズ Max server memory SQL Server が使うメモリの最大値 Buffer Pool Buffer Pool Buffer Pool Min server memory メモリを縮小していくときの最小値 実は最もメモリが小さいのは起動直後 Min server memory 起動直後は (memory size) < (min server memory) があり得る Max server memory
メモリ関連の設定 32bit で 4GB 以上のメモリを使う設定 /PAEオプションをつけたOS 起動 (bcdeditやboot.ini) Lock Page in Memory 権限 SQL Serverの起動アカウントに権限を付与する AWE 領域を確保するAPI(AllocateUserPhysicalPage) の実行条件となる AWE enabled SQL Server が AWE 領域を使えるように設定 Max server memory の指定 AWE 領域は開放されないので領域確保には上限を設ける http://msdn.microsoft.com/ja-jp/library/ms190673.aspx
メモリ関連の設定 Buffer Pool Data Page Cache Plan Cache Lock Sort AWE Area AWE って何? AWE は Address Windowing Extensions の略で OS に搭載された機能の 1 つ 仮想メモリ空間に Window を作り 物理メモリをマッピングすることで 4GB 以上のメモリを利用できる SQL Server は Data Page Cache しか AWE 領域を使えない
メモリ関連の設定 個人的なお勧め OSもSQL Serverも64bitを利用する Lock Page in Memory 権限を付与する Max server memoryを指定し OSに十分なメモリを残す 十分にシステムテストで叩いて裏付けを取る
メモリ周りのトラブル ワーキングセットのトリミング OS は物理メモリが極端に不足するとワーキングセット (= プロセスが使っている物理メモリ ) を強制的に取り上げる ワーキングセットのトリミング Sqlservr.exe だけではなく 他のプロセスもワーキングセットが減少する 64bitOS でよく発生し パフォーマンス劣化を起こしやすい 回避策 Lock Page in Memory 権限を起動アカウントに与える Max server memory を設定する http://support.microsoft.com/kb/918483/
メモリ周りのトラブル 処理量に対してメモリが不足している 大量のバッファが必要になると SQL Server は lazywriter がデータファイルへバッファを書き出す その結果 バッファだけのデータ参照ができる確率が下がり パフォーマンスが劣化する 一見 I/O のネックに見えることもある 回避策 物理メモリを増やす 不必要なデータスキャンが起きていないか調べてみる システムテストでメモリ不足が起きないか事前にチェックする
モニタリング モニタリングの意義 障害分析 警戒のため何らかのモニタリングが必要 パフォーマンス値は後からは取れない! モニタリング対象 物理メモリの空き容量 SQL Server がどれくらい効率的にメモリを再利用しているか 過度なページングが発生していないか 等々 他にも観点はたくさん http://msdn.microsoft.com/ja-jp/library/ms176018.aspx
モニタリング 監視対象 閾値 説明 Memory: Available Bytes Process(SQL Server): Pages/sec Process(SQL Server): Working set SQL Server: Buffer Manager: Cache Hit Ratio SQL Server: Buffer Manager: Page Life Expectancy OS で Free であると認識されている物理メモリの容量 Sqlservr.exe が秒当たりページングした回数 Sqlservr.exe が使っている物理メモリの容量 90% 以上 Buffer pool でのキャッシュヒット率 高いほどメモリが効率的に使われていることを示す 300 以上 Buffer pool 上にページが乗っている時間 (= ページの寿命 ) 高い方がメモリが効率的に使われていることを示す
モニタリング パフォーマンス値解釈の注意点 閾値超過が起きても必ず問題となるわけではない アプリケーションが性能要件を満たしていれば何の問題もない!! 必要以上に閾値監視にこだわらない ( 一瞬の閾値超過でも影響が少なければ無視で良いはず ) 注意すべき動作 SQL Server はメモリの先読みをするので メモリプレシャーになっていてもキャッシュヒット率が高い場合がある メモリプレッシャーは Page Life Expectancy で行う
まとめ 仮想メモリと物理メモリの違い プロセスが使うのは仮想メモリ OS が物理メモリに変換 SQL Server のメモリコンポーネント Buffer Pool と Mem To Leave メモリ制御のパラメータ Max/min server memory, AWE, Lock Page in Memory よくあるメモリトラブル ページング ワーキングセットのトリミング メモリプレッシャー モニタリングの方法 OS から見たときのカウンタと SQL のカウンタ
まとめ 本セッションで話さなかった / 話せなかったこと SQL Server 内のさらに細かいメモリ割り当ての話 仮想メモリの断片化の話 メモリリークやメモリ破壊の話 OS が持っている特殊なメモリの話 NUMA に関わる話
ご清聴ありがとうございました 何か不明点があれば質問して下さい!