Sql-Server
根據 CPU 型號為 SQL 伺服器設置 MAX 記憶體
我有一個關於重新設置 MAX SQL 記憶體設置的一般問題-
對於我們目前具有以下規格的 CPU，伺服器團隊將作業系統記憶體從 400GB 提高到 1TB：
- 英特爾® 至強® 處理器 E5-4640 v2 - 每個處理器有 4 個插槽 10 核，啟用了 HT，因此總共有 80 個邏輯處理器 4 個 NUMA 節點
查看英特爾網站上的規格，這裡支持的最大記憶體似乎是 768。
那麼這在 SQL 空間方面究竟意味著什麼？即使作業系統有 1 TB，是否應該根據 1 TB 或 768 GB 設置 MAX 記憶體設置？我們可以在嘗試提高 MAX 記憶體設置時看到 SQL 的問題，比如說超過 850，當我們將其降低到 400 時又恢復正常。
增加 SQL MAX 記憶體時的問題 - 根據超時設置，執行超過 3 秒的查詢的應用程序超時。
測試了這幾次，看起來是一樣的。需要了解原因
感謝您對此的投入。
最大記憶體設置是 SQL 將使用多少 RAM。它通常不會使用超過最大記憶體集。（根據 Shanky 的評論，該規則的例外情況見下文）：引用 記憶體管理架構指南
- 直接向 Windows 發出的記憶體分配請求：這些請求包括 Windows 堆使用和由載入到 SQL Server 程序中的模組進行的直接虛擬分配。此類記憶體分配請求的範例包括來自擴展儲存過程 DLL 的分配、使用自動化過程（sp_OA 呼叫）創建的對像以及來自連結伺服器提供程序的分配。
現在，如果您的硬體有 1 TB，但作業系統中只能辨識 768Gb，將最大記憶體設置為高於 768Gb 將允許 SQL 使用所有可用 RAM（作業系統檢測到的所有 RAM），這可能會導致潛在問題作業系統，因為它必須對 SQL 施加記憶體壓力才能收回它。
根據作業系統看到的 RAM 大小設置 SQL MaxMemory 設置，它應該很好。（為作業系統留出至少 4 Gb）
Ps 不要將 min memory 設置為與 max memory 相同的值。將其設置得較低，因為當存在記憶體壓力時，SQL 不會在最小值下釋放 RAM，這可能導致作業系統崩潰。
