RAM)の32GBのサーバーで実行されているSQL Server 2012インスタンスが2つあり、他にはほとんど実行されていません。
1つのインスタンスが正常に動作しています。そのワーキングセットメモリは、SQL Serverの最大サーバーメモリ設定に近いコミットの近くで実行されています。
他のインスタンス(画像で強調表示されている)は、予想どおりに動作していません。最小および最大のメモリ設定をどのように構成しても、サーバーに十分な量のRAM=)があるにもかかわらず、数百MBを超えるワーキングセットメモリを取得できません。
これは、特に高負荷時のパフォーマンスに非常に悪影響を及ぼします。データベースは十分に使用されており、このインスタンスが正常に動作している場合*、サーバーの最大メモリ設定である20GBまですぐにいっぱいになります。
サーバーが再起動されました。インスタンスが再起動されました。さまざまな最小/最大設定に変更し、正常に動作しているインスタンスを停止しようとしました-何とかしていないことを確認するだけです。問題は同じままですが、1つのインスタンスが最小および最大のメモリ設定に正常に応答するように見えますが、他のインスタンスは応答しません。
*何が変更されたかわからない。それ以外の場合は元に戻す。
タスクマネージャーまたはリソースモニターのメモリカウンターは、SQL Serverのメモリ使用量を判断するのに適した方法ではありません。 SQL Serverがロックされたページを使用している場合、 これらは表示されません ワーキングセットまたはプライベートバイト。
SQL Serverがロックされたページを使用しているかどうかを確認するには、多くの方法があります。エラーログで次のようなメッセージを探すことができます。
Using locked pages in the memory manager
または、 sys.dm_os_process_memory
DMV locked_page_allocations_kb
列を確認します。たとえば、ロックされたページを使用するローカルテストインスタンスでは、次のようになります。
一方、リソースモニターには次のように表示されます。
これは、質問のコメントで言及したsys.dm_os_sys_memory
DMVとは異なります。
DMVには、仮想メモリまたは物理メモリの高低の指標を含む、あらゆる種類の有用なメモリ使用情報があります。これらはすべてBooks Onlineで説明されています。
最近、誰かがSQL Serverの起動アカウントにSeLockMemoryPrivilege
を付与したか、アカウントがLocalSystem
に変更された可能性があります デフォルトでこの権限を持っています =。
一般的に言えば、 メモリ内のページのロックは良いことです 。