我可以採取哪些步驟來確定我的伺服器的記憶體配置是否不足？
我的伺服器正在執行 SQL Server 2016。該環境的工作負載相當高，全天有大量的寫入事務和數據讀取。我有一種預感，伺服器沒有配置足夠的記憶體，我想深入研究一下，看看是不是這樣。確定伺服器上可用記憶體量是否以及產生多少爭用的最佳方法是什麼？
我確實查看了 DMV sys.dm_os_wait_stats，當按 waiting_tasks_count desc 排序時，前兩種等待類型是“MEMORY_ALLOCATION_EXT”和“RESERVED_MEMORY_ALLOCATION_EXT”，比任何其他等待類型任務計數都大一個數量級。還有其他地方我可以檢查記憶體壓力或爭用嗎？
編輯：此伺服器上所有數據庫的總大小為 3 TB，具有大部分事務的主數據庫為 2 TB，伺服器上的 RAM 總量為 32 GB。
編輯 2：這是一天中的延遲寫入/第二次性能計數器結果：
這裡有幾個 perfmon 計數器可以用作啟動器。
Memory Grants Pending - 這是一個計數器，告訴您是否有任何查詢等待記憶體授予（記憶體分配）。這實際上應該是 0。如果它始終超過這個值，那麼你就有問題了。
頁面預期壽命 - 這是頁面在記憶體中停留的估計時間量（以秒為單位）。越高越好，但是有一個公式可以計算您的伺服器的最小值實際上應該是多少。過去它至少是 300 秒，但這是一個古老的計算方法，現在應該是每 GB 100 秒。我在 SQL 週六會議期間從 Richard Douglas 那裡得到了這個，所以歸功於他。他為 SentryOne 工作。小於該值表明分配的記憶體太少。還可以將此計數器與 Checkpoint pages/sec 結合使用。請注意，每個 NUMA 節點都有自己的 PLE 值（如果您的 SQL Server 上有多個 NUMA 節點）。SQL Server 開始將資源分配到分配的 8 個以上核心的（軟）NUMA 節點。
延遲寫入/秒 - 當 SQL Server 遇到記憶體壓力時，延遲寫入程序會從記憶體中清除舊頁面。始終高於 20 是一個問題（也從 Richard Douglas 那裡得到了這個）。但是，請將其與頁面預期壽命結合使用。如果您看到較高的 PLE 以及延遲寫入/秒的峰值，則說明某些原因導致 SQL 從其記憶體中刪除頁面並插入新頁面。有關我家庭實驗室的範例，請參見下面的螢幕截圖。
我相信這裡的一些專家對記憶文員有更多的了解，仍然在我的名單上進行更深入的研究，所以也許有人有一些額外的資訊給你（我也非常感興趣:-)）。
編輯：如果您願意，您還可以使用 sys.dm_os_performance_counters 通過查詢即時獲取它們。
2020 年 6 月 24 日編輯：
@JD 關於您 6 月 23 日的評論；由於@Dominique Boucher 和這篇文章的評論，我也深入探勘了記憶體壓力：https ://www.brentozar.com/archive/2020/06/page-life-expectancy-doesnt-mean-傑克和你應該停止看它/. 當我在郵箱裡收到這個時，我笑了；也許他看到了這個文章。:-) 這篇文章告訴我們不要再看它了。好吧，雖然布倫特肯定比我更有經驗，但我認為我不能完全同意他永遠不會看的說法。我在他的 sp_BlitzFirst 的上下文中理解了他的觀點，單個查詢使用最多 25% 的緩衝區記憶體，它是一個滯後指標，等等。但對於趨勢分析和歷史，我仍然會查看 PLE 與 Lazy Writer。如果我想確定伺服器是否隨著時間的推移存在記憶體壓力，這就是我將與等待記憶體授予結合使用的方法。此外，RedGate 和 Quest 的監控工具仍然使用它。現在@Dominique Boucher 說要查看 RESOURCE_SEMAPHORE 等待，我同意，但這很可能與未決記憶體授予的數量一致（您可以輕鬆地向 perfmon 註冊）。如果您有一個恆定的記憶體授予隊列（它與 FIFO 隊列一起使用），那麼您確實有記憶體壓力。
作為參考，這是這個宇宙中某個系統的 Lazy Writer（32 GB 記憶體，1 TB 數據庫，雖然工作負載的類型也很重要）。黃色是batch requests p/s，10表示一個1000，可以看出肯定不是空閒的。
這也是我的家庭實驗室關於記憶體授予與 RESOUCE_SEMPAPHORE 等待的快照（我還看到我突出顯示了 tempdb 寫入，這就是 david 所說的，記憶體太少，所以溢出到 tempdb）：
現在，看看你的性能計數器，我認為你肯定有記憶體問題。我是說; 有些東西不斷地迫使 SQL Server 從緩衝區記憶體中刪除頁面。如果這將是一次，好的，但它似乎一直忙於這樣做……但是，我希望看到它們與 PLE 相比。這可以清楚地表明存在記憶體壓力（隨著時間的推移，我仍然這麼認為）。其次，您還想查看未決的記憶體授予。現在，我之前沒有這麼說，但回頭看，我確實認為你想看看布倫特和多明克所說的等待統計數據。然而，隨著時間的推移，這有點困難。等待統計資訊是累積收集的，因此您需要先清除它們（我不喜歡），然後查看它們是否 RESOURCE_SEMAPHORE 加起來。
您也可以使用 sp_BlitzFirst 對其進行監控，但這只是您執行它時的快照。sp_BlitzFirst（或我記不起的 sp_Blitz）有一個選項可以定期將其記錄在表中，因此您也可以查看它。或者只是以其他方式自己查詢 dm_os_wait_stats 也可以。一般來說，我個人的偏好是隨著時間的推移收集數據來分析這一點。我使用來自 Steve Stedman 的 Database Health Monitor 執行此操作：databasehealth.com。我的家庭實驗室的螢幕截圖：
這樣，您可以更好地監控等待統計資訊，儘管這會花費您一點點資源。
如果您有 SQL Server 2017 或更高版本（我們的環境中還沒有），那麼您也可以使用查詢儲存。從 SQL Server 2017 開始，查詢儲存還記錄等待統計資訊（這是一個可配置選項）。不過要小心，我讀過 Query Store 讓非常繁忙的伺服器癱瘓的故事（您可以使用等待統計資訊進行監控：-P）。當然，在 prod 中實現功能之前，您應該始終進行測試。我們確實使用它，而且效果很好，但是我們有 2016 年，所以我們確實錯過了等待統計選項:-(。
順便一提; 我的策略是收集資訊（性能，如果可能，等待統計資訊），如果你認為記憶體壓力升級 RAM（如果是一個非常容易的 VM），然後收集性能指標並檢查它們是否有所改善。有點簡單，但後者經常被遺忘或做得不好。
