SQLServer 2016 不斷增加被盜記憶體
在幾天的時間裡，我們的數據庫伺服器上的被盜記憶體增長緩慢。它似乎穩定在 130-140GB 左右，此時我們開始遇到更大的問題，例如記憶體不足錯誤、多秒凍結和 AG 故障轉移。重新啟動後大約一周開始出現問題。我已經開始記錄被盜記憶體的歷史，如下圖：
查看
sys.dm_os_memory_clerks，似乎其中大部分來自記錄在 NUMA 節點 0 上的緩衝池中的非頁面記憶體：
pages_kb隨著時間的推移跟踪緩衝池的總數顯示頁面數量隨著virtual_memory_committed_kb增長而下降。（4 月 13 日，伺服器因 windows 更新而重新啟動。緩衝池在大約一個小時內填充到 400GB）
有沒有人見過這種行為？
我們正在執行 SQLServer 2016 CU12 13.0.5698.0 伺服器是一個 64 核的 AWS EC2 i3.16xlarge 實例。我們有許多其他相同大小的集群都顯示了這個問題。我們在 32 核 i3.8xlarge 實例上也有一些集群，這些集群也顯示了被盜記憶體的增長，但它們最終不會停止/拋出記憶體不足錯誤。唯一的區別（除了規模）是 64 核伺服器有 2 個 NUMA 節點。
更新： MS 表示 KB4536005 中的錯誤修復沒有被反向移植到 SQL2016。
我有一個懷疑。首先 - 您可以向 Microsoft 開具支持票嗎？
檢查我的懷疑的最簡單方法是擷取
$$ \SQLServer:Memory Node(*)\Stolen Node Memory (KB) $$對於兩個 NUMA 節點，並將總和與$$ \SQLServer:Memory Manager\Stolen Server Memory (KB) $$. 如果我的懷疑是正確的，那麼當麻煩正在醞釀時，兩者之間的差異——似乎他們應該總是同意——將會非常高。另一個明顯的特徵：最多 N-1 個 SQLOS NUMA 節點可能顯示了這種關係（其中 N 是 NUMA 節點的數量） $$ database node memory $$+$$ stolen node memory $$+$$ free node memory $$>$$ total node memory $$ 我在這些部落格文章中描述了這個問題。
https://sql-sasquatch.blogspot.com/2018/07/sql-server-2016-memory-accounting.html
https://sql-sasquatch.blogspot.com/2018/10/sql-server-2016-memory-accounting-part.html
基本核算問題是，有時緩衝池增長的方式是緩衝描述符塊從 SQLOS 節點 A 分配，但 bdbs 中引用的頁面實際上來自 SQLOS 節點 B。這種情況的結果是一部分物理記憶體由 SQLOS 控制被重複計算：在節點 A（bdb 所在的位置）上佔用相同的記憶體
$$ Database Node Memory $$ AND在 SQLOS 節點 B 上記為$$ Stolen Node Memory $$. 這種情況令人困惑且效率低下……但這還不是問題的全面發展。 當這麼多節點 B 時，問題就完全爆發了
$$ stolen node memory $$也是節點A$$ database node memory $$那個節點 B$$ database node memory $$降至節點 B 的約 2%$$ target node memory $$. 發生這種情況時，$$ \SQLServer:Buffer Manager\Free list stalls/sec $$飛漲 - 當這發生在我們身上時，我們看到了 2000/秒。SQL Server 正在嘗試糾正該問題（太少$$ database node memory $$) 在節點 B 上通過修剪節點 B 上的各種類型的記憶體。但它不能！因為$$ stolen node memory $$不在任何各種預期的記憶體類型中。 臨時解決方案：當
$$ total node memory $$方法$$ target node memory $$但$$ database node memory $$接近 2%$$ target node memory $$，執行 DBCC DROPCLEANBUFFERS。 kb4536005 解決了 SQL Server 2017 CU20 和 SQL Server 2019 CU2 中的此問題。 https://support.microsoft.com/en-us/help/4536005/improvement-fix-incorrect-memory-page-accounting-that-causes-out-of-me
SQL Server 2016 SP2 CU5，kb4470916 中有類似的聲音修復。 https://support.microsoft.com/en-ca/help/4470916/fix-out-of-memory-error-occurs-when-database-node-memory-kb-drops-belo
但是，我不相信 kb4470916 解決了雙重會計問題。因此，雖然它可以提高 SQL Server 對具有單個 SQLOS 節點的響應
$$ database node memory $$在約 2% 的門檻值上，我認為由於這種重複計算，它留下了戳熊的可能性。這可能就是你所處的情況。 但是，如果總和
$$ stolen node memory $$跨越兩個節點總是與$$ stolen server memory $$在這種情況下，您可以忘記這一切，就好像這是一場噩夢。:-)