複数のデータベースを実行している単一のSQL2012 SP4ノードがあります。

サーバーには20 GBのメモリが利用可能で、14 GBがSQLに割り当てられています（他にボックスで実行されているものはありません）。

SQLは数分ごとにバッファキャッシュ全体をダンプします。ページの平均余命はゼロになり、バッファキャッシュ記述子はキャッシュに何もないことを示します。

私はリソースモニターの通知を確認しました。通知は数ミリ秒ごとに高/定常/低から跳ね回っています。

RESOURCE_MEMPHYSICAL_HIGH RESOURCE_MEM_STEADY RESOURCE_MEMPHYSICAL_LOW

タイムスタンプが数ミリ秒離れています。PLEは基本的に鋸歯状のパターンです。

これは、SQL2012 SP1とこの質問で以前に発生したのを見たことがあります。

バッファーキャッシュ内のSQL Server 2012空きページが使用されていない

私はすでにSP4に更新していますが、同様の問題のようです。

サービスアカウントのLPIMをオンにして、最大メモリ設定をいじってみました。最大メモリを下げると、バッファキャッシュがより頻繁に空になるようです。

次に確認することについてのアイデアはありますか？

サーバーのワークロードは文字通り何もありません（ERPシステムでアイテムのリストをスクロールしていますが、キャッシュが再び低下するまでに約40〜50 MBに達します）。

SP1からアップグレードしてこれを修正したので興味深いです。キャッシュが約500MBになりました。それ以来、私は最大メモリ設定を14GBに落としました。

Windowsがパニックに陥り、SQLでのメモリプレッシャーに関する誤った通知をスローしているのではないかと思います。つまり、最大メモリが無制限に設定されているサーバーは問題なく動作しているようですが、数百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のサーバーメモリがコミットされました）。

昨夜、ゲストメモリを32 GBに増やして問題は解消しましたが、サーバーメモリの合計のコミットは14 GBしかありません（そして、DBを実行するビジネスは今朝忙しいため、通常、パフォーマンスの問題があります）。

現時点では、キャッシュ内の約8〜9GBのデータは安定しているようです。

このボックスのワークロードには20GBで十分であることを示唆しているようです。とりあえず32 GBのままにしておくのはうれしいですが、VM / SQLをより適切に構成できるように、この問題の一番下に到達したいと思います。

答えが見つかれば更新していきます！

さらに詳しい情報：

LPIMをオンにした後はSQLを再起動しませんでした（これが要件であるとは認識していませんでした）が、この設定をオンのままにして再起動してメモリをアップグレードしたため、メモリの増加またはLPIMによって問題が緩和されたかどうかはわかりません。

サーバーがアイドル状態のときに今夜ジャンプし、再び20GBでどのように見えるかを確認します。

さらに詳しい情報：

現在、サーバーは32GBが割り当てられた状態で正常に動作しています。それ以来、問題は発生していません。これが再び発生した場合、私はこの質問に戻って掘り続けます。

現在のところ謎のままですが、私は現時点では問題をマスクしているだけだと思います。

ご自身で問題を解決されたようですが、ソリューションに関する関連情報の概要を以下に示します。

サーバーメモリサーバー構成オプション

Microsoftは、「メモリオプションを手動で設定する」セクションの記事「Server Memory Server Configuration Options（Microsoft | SQL Docs）」に書き込みます。

_{（強調鉱山）}

また、仮想化環境ではmin_server_memory値の設定が不可欠です。これにより、基盤となるホストからのメモリプレッシャーによって、ゲストSQL Server仮想マシン（VM）のバッファープールからメモリの割り当てを解除して、許容できるパフォーマンスに必要な量を超えないようにします。

メモリ内のページのロックに関するセクション（同じドキュメント）には、次のように説得力のある同じ段落があります。

_{（強調鉱山）}

このWindowsポリシーは、どのアカウントがプロセスを使用してデータを物理メモリに保持できるかを決定し、システムがデータをディスク上の仮想メモリにページングできないようにします。メモリ内のページをロックすると、メモリからディスクへのページングが発生したときにサーバーの応答性が維持される場合があります。SQL Server Standard Edition以降のインスタンスでは、sqlservr.exeを実行する特権を持つアカウントにWindows Lock Pages in Memory（LPIM）ユーザー権利が付与されている場合、Lock Pages in MemoryオプションがONに設定されます。

LPIMセクションでは、次のことを説明します。

_{（強調鉱山）}

このオプションを設定しても、SQL Serverの動的メモリ管理には影響がなく、他のメモリ担当者の要求に応じて拡張または縮小できます。[メモリ内のページのロック]ユーザー権利を使用する場合、上記のように最大サーバーメモリの上限を設定することをお勧めします。

...そして重要なコメントで：

_{（強調鉱山）}

このオプションの設定は、必要な場合、つまり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は必要ありません。

解決

上記の結果と観察結果に基づいて、問題の解決策は次の設定を構成することです。

1. min_server_memory （5-10 GB？）あなたのコメントに基づく：

   現時点では、キャッシュ内の約8〜9GBのデータは安定しているようです。

   ...と設定のMicrosoftの勧告min_server_memory。

2. max_server_memory （20-32 GB）あなたの観察に基づく：

   このボックスのワークロードには20GBで十分であることを示唆しているようです。とりあえず32 GBのままにしておくのはうれしいですが、VM / SQLをより適切に構成できるように、この問題の一番下に到達したいと思います。

   ...と設定のMicrosoftの勧告max_server_memory。

3. メモリ内のページのロック：SQL Serverサービスアカウントに対して有効化されています。
   言及したSQL ServerインスタンスのERRORLOGエントリと、記事でのMicrosoftの参照に基づいています。

   このオプションの設定は、必要な場合、つまりsqlservrプロセスがページアウトされている兆候がある場合にのみ使用してください。

続行する前に...

（1つ）仮想化環境を持つことの利点は、リソースを共有できる/すべきであり、場合によってはオーバーコミットすることさえできます。ただし、ハードウェアが複数のインスタンスをホストしている場合、メモリ内のページのロック（LPIM）をオンにすると、Hyper-V環境に悪影響を及ぼす可能性があります。RAMの過剰使用は他のインスタンスを使い果たす可能性があります。

すべてのレバーを切り替えることを検討する前に、設定1と2から始めてください。これらのメモリ設定の微調整が機能しない場合は、十分なハードウェアがある場合にLPIMを有効にすることを検討してください。