最大サーバーメモリの変更は、プランキャッシュをクリアし、（明らかに）メモリ設定を変更する以外に何をしますか？）

32 GBのRAMと4つのコア、60〜80の同時接続でSQL Server 2012 SP3を実行し、主にアドホックなワークロードで、SQL Serverプロセス（CPU）が急上昇し、予測できない時間に1日に1回または2回急上昇し続けています。スパイクの根本的な原因の特定に取り組んでいます。それまでの間、最大メモリ設定の変更（アップまたはダウン）が、CPUの負荷を通常に戻す唯一の方法であることがわかりました。

ログを確認し、StackExchange（https://dba.stackexchange.com/a/183276）を検索すると、最大メモリ設定を変更することにより、プランキャッシュがフラッシュされていることがわかります。ただし、DBCC FREESYSTEMCACHE（ 'SQL Plans'）を介してプランキャッシュをフラッシュすると、CPU負荷は通常に戻りません。

最大メモリ設定を変更すると、天候に関係なく問題が解決するため、問題は最大サーバーメモリ設定に直接関連しているようには見えません。そのため、メモリ設定を変更する他のことを理解し、その情報を使用してCPUスパイクの根本的な原因を特定しようとしています。

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

max server memory （本質的にはsys.dm_os_memory_clerksにあるメモリクラークを含む）SQL Serverのメモリ割り当てを制御します。

• バッファプール
• メモリをコンパイルする
• すべてのキャッシュ
• qeメモリ許可
• ロックマネージャメモリ
• clrメモリー

したがって、これらのコンポーネントはすべて、max server memory設定の変更によって影響を受けます。

余談ですが、これはCPUスパイクの原因を特定するための非常に困難な方法になります。トラブルシューティングには次の記事を使用することをお勧めします。

1. Joe SackによるSQL Server CPUパフォーマンス問題のトラブルシューティング
2. SQL Serverを攻撃しているものを見つけるにはどうすればよいですか？