複数のデータベースを実行している単一のSQL2012 SP4ノードがあります。
サーバーには20 GBのメモリが利用可能で、14 GBがSQLに割り当てられています(他に何も実行されていない)。
SQLは数分ごとにバッファキャッシュ全体をダンプします。ページの平均余命は0に達し、バッファキャッシュ記述子はキャッシュに何もないことを示します。
私はリソースモニターの通知を確認しました。通知は数ミリ秒ごとに高/定常/低から跳ね回っています。
RESOURCE_MEMPHYSICAL_HIGH RESOURCE_MEM_STEADY RESOURCE_MEMPHYSICAL_LOW
タイムスタンプが数ミリ秒離れています。 PLEは基本的に鋸歯状のパターンです。
これはSQL2012 SP1とこの質問で以前に発生するのを見ました。
SQL Server 2012 Free Pages in Buffer Cache Not Beused
私はすでにSP4に更新していますが、同様の問題のようです。
サービスアカウントのLPIMをオンにして、最大メモリ設定をいじってみました。最大メモリを減らすと、バッファキャッシュが空になる頻度が高くなったようです。
次に確認することについてのアイデアはありますか?
サーバーのワークロードは文字通り何もありません(ERPシステム内のアイテムのリストをスクロールしており、キャッシュが再び低下する前に約40-50MBに達します)。
SP1からアップグレードしてこれを修正したので興味深いです。そこにあるキャッシュは約500MBに達していました。それ以来、私は最大メモリ設定を14GBに落としました。
Windowsがパニックに陥り、SQLでのメモリプレッシャーに関する誤った通知をスローしているのではないかと思います-最大メモリがunboundedに設定されているサーバーは問題なく実行されているようですが、数百MBを超えるキャッシュを満たしていないようです-しかし今はやっと50に達する...
詳細:尋ねた人のために
コア数:4
データベースサイズ:80GB
エラーログは次を示します:A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 247928, committed (KB): 495656, memory utilization: 50%.
このリンクからスクリプトを実行した結果: https://www.sqlskills.com/blogs/jonathan/identifying-external-memory-pressure-with-dm_os_ring_buffers-and-ring_buffer_resource_monitor/
これらの解釈方法がわからない-さまざまなタイミングで内部メモリと外部メモリの両方に圧力がかかっているようです。
さらに詳しい情報:
これは、合計RAMが96GBのホスト上にあるHyper-Vゲストであり、その約半分がゲストに割り当てられています。
症状は次のようになります。
SQL Server 2012 x64-50%を超えるRAMを安全に割り当てることはできません
ただし、SQLに14GBを割り当てたとき、症状がすぐに発生しました(かろうじて3GBのサーバーメモリがコミットされました)。
昨夜、ゲストメモリを32GBに増やしたところ、問題は解消しましたが、サーバーメモリ全体のコミットは14GBしかありません(そして、DBを実行するビジネスは今朝忙しいため、通常、パフォーマンスの問題が発生します)。
現時点では、キャッシュ内の約8〜9GBのデータは安定しているようです。
このボックスのワークロードには20GBで十分であることを示唆しているようです。とりあえず32 GBのままにしておくのはうれしいですが、VM/SQLをより適切に構成できるように、この問題の一番下に到達したいと思います。
答えが見つかれば更新していきます!
さらに詳しい情報:
LPIMをオンにした後でSQLを再起動しませんでした(これは要件であるとは認識していませんでした)が、この設定をオンのままにして再起動し、メモリをアップグレードしたため、メモリの増加またはLPIMによって問題が緩和されたかどうかはわかりません。
サーバーがアイドル状態のときに今夜ジャンプし、再び20GBでどのように見えるかを確認します。
さらに詳しい情報:
現在、サーバーは32GBが割り当てられており、問題なく動いています。それ以降、問題は発生していません。これが再び発生した場合、私はこの質問に戻って掘り続けます。
現在のところ謎のままですが、私は現時点では問題をマスクしているだけだと思います。
自分で問題を解決したようですが、ソリューションに関する関連情報の概要を次に示します。
Microsoftの記事 Server Memory Server Configuration Options (Microsoft | SQL Docs)のセクション メモリオプションの手動設定
(emphasismine)
また、min_server_memory値を設定することは、仮想化環境で不可欠です基盤となるホストからのメモリプレッシャーがからメモリを割り当て解除しないようにしますゲストSQL Server仮想マシン(VM)上のバッファープールは、許容可能なパフォーマンスに必要な量を超えています。
メモリ内のページのロック (同じドキュメント)に関するセクションには、次のような同等の説得力のある段落があります。
(emphasismine)
このWindowsポリシーは、どのアカウントがプロセスを使用して物理メモリにデータを保持できるかを決定し、システムがディスク上の仮想メモリにデータをページングできないようにします。メモリ内のページをロックすると、メモリからディスクへのページングが発生したときにサーバーが応答し続ける場合があります。 SQL Server Standardエディション以降のインスタンスでは、sqlservr.exeを実行する権限を持つアカウントにWindows Lock Pages in Memory(LPIM)ユーザー権利が付与されている場合、Lock Pages in MemoryオプションがONに設定されます。
LPIMセクションでは、次のことを説明します。
(emphasismine)
このオプションを設定しても、SQL Serverの動的メモリ管理には影響がなく、他のメモリ担当者の要求に応じて拡張または縮小できます。 [ページをメモリにロック]ユーザー権利を使用する場合は、上記のように最大サーバーメモリの上限を設定することをお勧めします。
...そして重要なコメントで:
(emphasismine)
このオプションの設定は、必要な場合にのみ使用する必要があります。つまり、sqlservrプロセスがページアウトされている兆候がある場合は、です。この場合、エラー17890がエラーログに報告され、次の例のようになります。
A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: #### seconds. Working set (KB): ####, committed (KB): ####, memory utilization: ##%.
SQL Server 2012(11.x)以降、Standard Editionがロックされたページを使用する場合、トレースフラグ845は必要ありません。
上記の調査結果と観察に基づいて、問題の解決策は次の設定を構成することです。
あなたのコメントに基づくmin_server_memory
(5-10 GB?):
現時点では、キャッシュ内の約8〜9GBのデータは安定しているようです。
...およびmin_server_memory
の設定に関するMicrosoftの推奨事項。
max_server_memory
(20〜32 GB)観察に基づく:
このボックスのワークロードには20GBで十分であることを示唆しているようです。とりあえず32 GBのままにしておくのはうれしいのですが、VM/SQLをより適切に構成できるように、この問題の一番下に到達したいと思います。
...およびmax_server_memory
の設定に関するMicrosoftの推奨事項。
このオプションの設定は、必要な場合にのみ使用する必要があります。つまり、sqlservrプロセスがページアウトされている兆候がある場合は、です。
(1つ)仮想化環境を持つことの利点は、リソースを共有できる/すべきであり、場合によってはオーバーコミットすることさえできます。ただし、ハードウェアが複数のインスタンスをホストしている場合、メモリ内のページのロック(LPIM)をオンにすると、Hyper-V環境に悪影響を及ぼす可能性があります。 RAM=のオーバーコミットメントは、他のインスタンスを使い果たす可能性があります。
すべてのレバーを切り替えることを検討する前に、設定1と2から始めてください。これらのメモリ設定の微調整が機能しない場合は、LPIMをオンにすることを検討してください十分なハードウェアがある場合。