SQL Server 隨著時間的推移變得越來越慢，直到我們不得不重新啟動它

我們有一個混合了 OLAP/OLTP 工作負載的數據庫。查詢是非常臨時的，並且是在中間層應用程序伺服器中動態創建的。當我們啟動伺服器時，性能還算可以接受，但是記憶體消耗越來越多，直到所有可用記憶體（30GB）用完為止。之後，系統變得越來越慢。

類似的命令Dbcc freeproccache無效。

裡面的交易select * from sys.dm_tran_session_transactions不多（不超過系統正常的時候），有時候這個列表是空的。

第一個結果dbcc memorystatus是

VM Reserved               42136628
VM Committed               1487176
Locked Pages Allocated    24994048
Reserved Memory               1024
Reserved Memory In Use           0

重新啟動 SQL Server 可以暫時解決問題。

1. 是什麼導致了這種行為？如何避免？
2. 如果一個真正的解決方案太難了，是否有一個命令可以強制 SQL Server 在沒有完全重新啟動 DBMS 的情況下實際釋放所有記憶體？

伺服器在專用硬體（不是 VM）上執行。我們有一些預定的工作，但我們將它們禁用了一段時間，沒有任何變化。在同一台伺服器上執行其他中間層應用程序，但它們使用的記憶體不超過 2GB，CPU 可以忽略不計，幾乎沒有 I/O。我們重新啟動了所有此類應用程序，沒有任何變化。

我建議在此伺服器上收集性能指標，這樣您就可以消除對這些類型問題的故障排除的猜測。如果您不知道從哪裡開始，請參閱這篇文章以獲得更完整的指南。

特別是，我會檢查性能計數器Memory\Available MBytes，Paging File(_Total)\% Usage因為您說問題僅在緩衝池已滿時才開始發生。您從這些計數器返回的數字可能表明需要針對分配給伺服器的物理記憶體量調整最大伺服器記憶體設置（向上或向下）。正如我在這裡提到的，我不建議將最大記憶體設置基於物理記憶體量，除非作為有根據的猜測作為起點。始終測量結果，並從那裡進行調整。

如果可用記憶體量太低（< 500），或者頁面文件使用量超過零，這可能表明 SQL Server 實例被過度使用：在 SQL Server 2008 R2 上，最大伺服器記憶體設置僅控制緩衝池大小，而不是其他記憶體使用情況，例如計劃記憶體。SQL Server 也不關心您可能在系統上執行的其他應用程序。這種額外的記憶體使用會給 Windows 或其他應用程序帶來記憶體壓力，可能會導致磁碟交換。這是您要不惜一切代價避免的事情，特別是如果頁面文件存在於僅由簡單 RAID 1 鏡像支持的捲上。我的感覺是這就是問題所在，取消最大伺服器記憶體設置應該可以解決問題。

如果可用記憶體量很高（> 1000）並且頁面文件使用量為零，您可能可以稍微提高最大伺服器記憶體（以 256 MB 為增量）以最大化伺服器的記憶體使用量。但是，這很可能無法解決問題，您需要查看其他地方，可能是物理磁碟計數器和緩衝池頁面預期壽命。如果查詢正在破壞緩衝池，除了提高磁碟性能、增加伺服器可用的物理記憶體量以便所有數據頁可以同時放入記憶體或修改數據庫以不佔用太多空間之外，您無能為力物理空間（可能通過使用行或頁面壓縮，或者通過使用更高的 重建索引FILLFACTOR）。

我在這裡發表了一篇關於這個主題的文章，更深入地討論了這個問題以及如何解決它。

引用自：https://dba.stackexchange.com/questions/31218