您將採取哪些步驟來確保具有 128GB RAM 限制的 STANDARD 版本足以滿足您的生產需求？

我的主觀感覺是我們處於某種邊緣，我正在尋找強有力的論據來為未來做出正確的決定。

我們現在正在執行評估版（實際上是企業版）。這給了我空間來測試將 RAM 限制（最大伺服器記憶體）設置為 128 GB 或更多（實際上設置為 169 GB）的影響。我們將之前的狀態稱為（最大伺服器記憶體 = 128 GB）和之後的狀態（最大伺服器記憶體 = 169 GB）。在測試時，我正在收集等待統計資訊和幾個基於記憶體的計數器。

通常，在 RAM 增加之前和之後進行監控時，等待統計資訊沒有太大變化。甚至在等待類型的緩衝區鎖存器和記憶體類別中也沒有。

記憶體計數器提供了更多有趣的值，但它們是否足夠強大的記憶體不足指標？

**記憶體授予掛起：**值保持 = 0 之前和之後

**總和目標伺服器記憶體：**前後保持接近 - 沒有峰值

系統記憶體狀態： 之前 - 它主要處於“物理記憶體狀態我們穩定”狀態之後 - 它進入“可用物理記憶體處於高位”狀態，這並不奇怪

**頁面預期壽命：**隨時間變化很大（之前和之後）之前：有時會低於 300，但平均而言會更多 之後：有時會低於 300（但時間更少）

**Batch Reguests/sec & SQL Compilations / sec：**這兩個計數器之間的比率沒有改變（之前/之後） - 所以緩衝區中的計劃似乎有足夠的空間，不幸的是比率仍然高於 10%。

記憶體使用率

我還將執行以下語句來查看 SQL Server 記憶體的使用情況：

SELECT 
 physical_memory_in_use_kb/1024            AS sql_physical_memory_in_use_MB, 
   large_page_allocations_kb/1024          AS sql_large_page_allocations_MB, 
   locked_page_allocations_kb/1024         AS sql_locked_page_allocations_MB,
   virtual_address_space_reserved_kb/1024  AS sql_VAS_reserved_MB, 
   virtual_address_space_committed_kb/1024 AS sql_VAS_committed_MB, 
   virtual_address_space_available_kb/1024 AS sql_VAS_available_MB,
   page_fault_count                        AS sql_page_fault_count,
   memory_utilization_percentage           AS sql_memory_utilization_percentage, 
   process_physical_memory_low             AS sql_process_physical_memory_low, 
   process_virtual_memory_low              AS sql_process_virtual_memory_low
FROM sys.dm_os_process_memory;  

在某個時刻，當您繼續增加記憶體時，該sql_memory_utilization_percentage列將開始遠離 100%。這是因為 SQL Server 可能不需要更多記憶體。

SQL Server 版功能

根據您的 SQL Server 版本，有一些功能可用或不可用。兩個是閱讀頁面（Microsoft | SQL Docs）一文中描述的預讀和高級掃描功能。

SQL Server 2016 可擴展性和性能

Feature           | Enterprise | Standard
------------------+------------+----------
Read-Ahead        | Yes        | Yes (possible limitations; see Correction)
Advanced Scanning | Yes        | No

SQL Server 2017 可擴展性和性能

Feature           | Enterprise | Standard
------------------+------------+----------
Read-Ahead        | Yes        | Yes (possible limitations; see Correction)
Advanced Scanning | Yes        | No

SQL Server 2019 可擴展性和性能

Feature           | Enterprise | Standard
------------------+------------+----------
Read-Ahead        | Yes        | Yes (possible limitations; see Correction)
Advanced Scanning | Yes        | No

預讀

數據庫引擎支持稱為預讀的性能優化機制。預讀預測完成查詢執行計劃所需的數據和索引頁面，並在查詢實際使用頁面之前將它們帶入緩衝區記憶體。這允許計算和 I/O 重疊，充分利用 CPU 和磁碟。

更正顯然，預讀功能在 SQL Server 的所有版本中都可用。我發現文章When are read ahead reads issue (Microsoft Social MSDN - Paul White) 回答了這個問題。但是，仍然可能存在內部限制，具體取決於會影響標準版中執行的預讀量的版本。

ie Enterprise 可以進一步閱讀，如果情況合適的話。確切的數字可能會因版本而異（第二條引述來自 Bob Dorr 的 SQL Server 2000 I/O 基礎論文 - http://technet.microsoft.com/en-us/library/cc966500.aspx）。這些天可能有 2,048 頁 - 誰能跟得上？;C）

高級掃描

在 SQL Server Enterprise 中，高級掃描功能允許多個任務共享全表掃描。如果 Transact-SQL 語句的執行計劃需要掃描表中的數據頁，並且數據庫引擎檢測到該表已被掃描以查找另一個執行計劃，則數據庫引擎將第二次掃描與第一次掃描連接，在第二次掃描的目前位置。數據庫引擎讀取每一頁一次，並將每一頁中的行傳遞給兩個執行計劃。這一直持續到到達表的末尾。

（取自連結的 Microsoft 文章Reading Pages）

因為您正在**“企業版”**上進行測試，所以您可能會因為這些附加功能而觀察到性能提升。

警告

SQL Server Standard Edition 的版本中可能提供或不提供某些功能。某些功能在同一版本中可用，但具有不同的 Service Pack！

請確保您將 Apple（標準）與 Apple（標準）進行比較，而不是將 Apple（標準）與梨（企業）進行比較。

罕見病例和跟踪標誌

在極少數情況下，記憶體過多可能會適得其反。有關跟踪標誌 2335的知識庫文章中描述了這種情況。

當您將 Microsoft SQL Server 中的 max server memory sp_configure 選項配置為較大的值時，您可能會注意到特定查詢可能執行緩慢。但是，如果您降低此選項的值，相同的查詢可能會執行得更快。

回答你的問題

您將採取哪些步驟來確保具有 128GB RAM 限制的 STANDARD 版本足以滿足您的生產需求？

1. 比較標準版和標準版
2. 密切關注您的基線計數器

• 如果您的計數器顯示性能下降並且使用者抱怨，考慮切換到企業版，如果只是為了企業版中提供的各種功能的好處。請在切換前徹底測試。
• 如果您的計數器沒有顯示性能下降並且使用者很滿意，那麼 128 GB 可能恰到好處。

您將採取哪些步驟來確保具有 128GB RAM 限制的 STANDARD 版本足以滿足您的生產需求？

要“準確”確定您必須在標準版上測試您的應用程序，沒有其他絕對的方法。在企業上測試您的應用程序並假設它會在標准上給出相同的性能結果並不總是有效。與標準相比，企業版具有更好的處理方式，例如與標準版相比，企業版的預讀更好。這只是一個例子。MS 沒有記錄這麼小的事情，我相信不可能記錄所有這麼小的事情。

回憶一下，就像您看到的那樣，當從 169 GB 記憶體移動到 128 GB 記憶體時，與記憶體相關的計數器幾乎沒有任何變化，這僅表明在特定時間通過更改最大伺服器記憶體佔用的額外記憶體實際上並不需要太多任何地方。

我通常覺得如果您的系統上的 RAM 是數據庫總大小的 1/4，它應該沒問題。請注意，這是籠統的陳述，來自我的經驗，並不適用於任何地方。這絕對不意味著如果你有 600GB 的數據庫，你就會開始面臨記憶體壓力，這完全取決於工作量。

你的問題有點開放，但我已經盡力回答了

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