為什麼總和目標伺服器記憶體永遠不會達到配置的記憶體值？
我有 100GB 記憶體的 sql server，其中 90GB 分配給 sql server。2 GB 目前是免費的，如任務管理器中所示。
90GB=92160MB（見sql server記憶體設置）
我正在監視總伺服器記憶體和目標伺服器記憶體性能監視器計數器。
我可以看到目標伺服器記憶體永遠不會超過 90150MB，伺服器總記憶體永遠不會超過 89100MB。這可能是什麼原因？
我的理解是目標記憶體應該始終等於 sql server 記憶體設置中配置的設置。但為什麼在我的情況下會有所不同？
我的問題是 - 我已將目標設置為 92160MB，它是一個非常繁忙的數據庫伺服器，那麼為什麼總和目標值沒有達到 92160MB？
Learning_DBAdmin 的回答基本上涵蓋了這個問題。簡而言之，無論您的伺服器本身**有多忙，如果您沒有消耗足夠的數據頁來填充 90 GB 的記憶體，那麼您的 SQL Server 實例將不會佔用 90 GB 的記憶體伺服器。
世界上最繁忙的伺服器只能處理 10 GB 的數據，然後其他 80 GB 的記憶體將被浪費，粗略地說。SQL Server 使用記憶體還有其他用途，例如記憶體執行計劃，但記憶體的主要消費者通常是您正在查詢的數據的數據頁，如果在給定時間不是很多數據，那麼就不是需要大量記憶體。
從角度來看，我曾經管理過一個多 TB 的數據庫，其中最大的表大約有 1.5 TB，其中有 100 億行。執行 SQL 實例的伺服器只有 16 GB 記憶體，足以滿足在其上執行的查詢類型。它的事務性也很重（寫得很忙），每分鐘寫數千行。這是因為在任何給定時間，從磁碟載入到記憶體中的數據量都不會超過幾 GB，因為查詢是在其上執行的。磁碟上的數據為數 TB 無關緊要，伺服器每分鐘都忙於寫入新數據也無關緊要。
對於您的後續問題“我的理解是目標記憶體應始終等於 sql server 記憶體設置中配置的設置。但是為什麼在我的情況下會有所不同？ ”
我通常不再使用 PerfMon 來測量壓力，而且正如我之前建議的那樣，Erik Darling’s
sp_PressureDetector可能是獲得記憶體壓力整體視圖的更好工具。話雖如此，目標記憶體“是 SQL Server 可能分配給緩衝池的記憶體量”，如SQL Server Perfmon Counters - Target vs Total Memory and Max Memory中所述。這意味著（正如我之前所說的）這是可用於從磁碟記憶體數據頁的記憶體量。但這並不意味著 SQL Server 會自動使用那麼多記憶體，尤其是當您沒有查詢足夠的數據來填充緩衝池時。
“我的理解是，目標記憶體應該始終等於 sql server 記憶體設置中配置的設置。”
沒有。考慮預設值
$$ Max Server Memory $$安裝 SQL Server 時為 2,147,483,647 兆字節。那是 2 PB 的 1 mb :-) 讓我們假設有問題的 SQL Server 實例沒有啟用啟動跟踪標誌 834 以及 LPIM。這些實例按自己的規則執行，除非這裡是這種情況，否則無需討論。這是一個非常罕見的配置。
$$ Max Server Memory $$是最大值$$ Target Server Memory $$. 但是，如果$$ Max Server Memory $$不能根據RAM總量來實現，$$ Available memory $$和$$ Free & Zero Page List memory $$, SQL Server 將為$$ Target Server Memory $$.$$ Target Server Memory $$通常支配$$ Total Server Memory $$， 和$$ Total Server Memory $$是總和$$ Database Cache Memory $$,$$ Free Memory $$， 和$$ Stolen Server Memory $$. 下面是一個系統的圖表，顯示了一個搖擺不定
$$ Target Server Memory $$. 隨著該系統上的活動的進行，SQLOS 以外的記憶體使用情況$$ Target Server Memory $$（注意 - 這甚至可能是每個 SQL Server 工作人員 2 mb 私有記憶體的總和，因為該記憶體不包含在$$ Total Server Memory $$) 偶爾會導致來自作業系統的記憶體不足通知。SQL Server 是一個體貼的鄰居，如果允許$$ Min Memory Setting $$會降低$$ Target Server Memory $$量應該可以解決記憶體不足的情況。（順便說一句，這就是為什麼我通常建議保留$$ Min Server Memory $$預設設置為 0 - 不受管制）
在你的情況下，
$$ Target Server Memory $$大約比 2 GB 低$$ Max Server Memory $$. 除非為此實例啟用了 LPIM 和跟踪標誌 834，否則這將是由於 SQL Server 降低以外的記憶體承諾$$ Available $$和/或$$ Free & Zero Page List $$記憶。SQL Server 知道$$ Max Server Memory $$如果不導致記憶體不足通知（或者可能已經收到通知），則無法實現或維護值，因此選擇了較低的值$$ Target Server Memory $$. 監控
$$ Available $$和$$ Free & Zero Page List $$記憶應該證實這種事態。很可能，就像這些圖表來自的系統一樣，系統也正在使用分頁空間。
也許系統上還有另一個重要的記憶體消耗者。SSIS、SSRS ……或者在 VMware VM 的情況下，氣球驅動程序。如果可以辨識並消除或限制另一個記憶體消費者，則更高
$$ Target Server Memory $$應該看到價值——甚至可能達到$$ Max Server Memory $$. 但是，即使辨識並解決了另一個記憶體使用者，對於
$$ Target Server Memory $$到達並停留在$$ Max Server Memory $$可能還需要降低$$ Max Server Memory $$價值。 我個人總是喜歡一個非常穩定的
$$ Target Server Memory $$值等於$$ Max Server Memory $$搖搖晃晃$$ Target Server Memory $$. 為了資源利用和性能評估，我也更喜歡穩定$$ Target Server Memory $$值保持在固定值以下$$ Max Server Memory $$.