一種自動清除/重新啟動虛擬記憶體蠕變的方法？

我知道這樣做不是很好的做法，但我的公司負擔不起我試圖為我們的問題找到合適的解決方案。我讀過這篇文章，我可以對 SQL Server 2005 做同樣的事情，但我希望有更好（更快？）的方法。

問題如下：

我們有一個在 Windows Server 2003 上執行的 ASP.net 網站 (ASP2)，它還託管我們的 SQL Server 2005 數據庫並進行安裝。

最近我們注意到我們的 SQL Server 2005 實例的 VM 已送出記憶體空間增長了，幾乎達到了我們設置為 1.7 GB 的 VM 保留空間（嗯，太多了？）。

執行我們的 SQL Server 的 PC 伺服器具有 4 GB 的 RAM 和高達 3.5 GB 的可用磁碟空間，用於安裝 SQL Server 2005。數據庫本身位於 350 GB 的共享空間上（為此有兩個分區：分別是 C 和 D 驅動器）。

因此，就虛擬機空間而言，我認為我們有足夠的空間並將我們的虛擬機限制設置為 1.7 GB（理想情況下為 2 GB）就足夠了。

數據庫本身的大小小於 500 MB。

當我們的 VM Committed 值接近 VM Reserved 值時，服務會大大減慢。我知道解決這個問題的唯一方法是停止所有 SQL 服務服務並重新啟動它們。但是在 24 小時內，VM Committed 仍然在爬升！

有沒有一種方法可以讓我試圖找出問題的原因，而只需在一夜之間自動重新啟動所有服務？或者我真的應該試圖找出我們問題的原因嗎？

我做了一些調查（但正如我所說，我們現在時間很差），並找到了這個 SQL 查詢（見下文），它告訴我什麼實際查詢似乎最佔用 CPU（不確定這是否有什麼需要解決我上面原來的虛擬機問題）。

它顯示了一個查詢恰好在一夜之間執行，並且可能是該查詢只是佔用記憶體而不將其釋放回池中？

有沒有辦法在 SQL Server 中“關閉”執行緒/記憶體分配等，以便釋放記憶體？

這是 CPU “hog search” 查詢（由this提供）

select  
   highest_cpu_queries.plan_handle,  
   highest_cpu_queries.total_worker_time, 
   q.dbid, 
   q.objectid, 
   q.number, 
   q.encrypted, 
   q.[text] 
from  
   (select top 50  
       qs.plan_handle,  
       qs.total_worker_time 
   from  
       sys.dm_exec_query_stats qs 
   order by qs.total_worker_time desc) as highest_cpu_queries 
   cross apply sys.dm_exec_sql_text(plan_handle) as q 
order by highest_cpu_queries.total_worker_time desc

---

編輯，回答 Pathum 的問題：

執行查詢的結果：

---------------------------------------------------------------------------------------------------- 
Memory usage details for SQL Server instance SERVER9 (9.00.4053.00 - X86) - Standard Edition)
----------------------------------------------------------------------------------------------------

Memory visible to the Operating System
Physical Memory_MB|Physical Memory_GB|Virtual Memory GB 4091|4|2
Buffer Pool Usage at the Moment
BPool_Committed_MB|BPool_Commit_Tgt_MB|BPool_Visible_MB
519.250000|1599.875000|1599.875000

Total Memory used by SQL Server Buffer Pool as reported by Perfmon counters
Mem_KB|Mem_MB|Mem_GB 531712|519.250000|0.507080078

Memory needed as per current Workload for SQL Server instance    
Mem_KB|Mem_MB|Mem_GB 1638272|1599.875000|1.562377929

Total amount of dynamic memory the server is using for maintaining connections
Mem_KB|Mem_MB|Mem_GB 560|0.546875|0.000534057

Total amount of dynamic memory the server is using for locks
Mem_KB|Mem_MB|Mem_GB 968|0.945312|0.000923156

Total amount of dynamic memory the server is using for the dynamic SQL cache
Mem_KB|Mem_MB|Mem_GB 1120|1.093750|0.001068115

Total amount of dynamic memory the server is using for query optimization
Mem_KB|Mem_MB|Mem_GB 552|0.539062|0.000526428

Total amount of dynamic memory used for hash, sort and create index operations.
Mem_KB|Mem_MB|Mem_GB 0|0.000000|0.000000000

Total Amount of memory consumed by cursors
Mem_KB|Mem_MB|Mem_GB 480|0.468750|0.000457763

Number of pages in the buffer pool (includes database, free, and stolen).
8KB_Pages|Pages_in_KB|Pages_in_MB 66464|531712.000000|519.250000000

Number of Data pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 50135|401080.000000|391.679687500

Number of Free pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 895|7160.000000|6.992187500

Number of Reserved pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 0|0.000000|0.000000000

Number of Stolen pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 15434|123472.000000|120.578125000

Number of Plan Cache pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 11953|95624.000000|93.382812500

Page Life Expectancy - Number of seconds a page will stay in the buffer pool without references
Page Life in seconds|PLE Status 47011|PLE is Healthy

Number of requests per second that had to wait for a free page
Free list stalls/sec 0


Number of pages flushed to disk/sec by a checkpoint or other operation that require all dirty pages to be flushed
Checkpoint pages/sec 572

Number of buffers written per second by the buffer manager"s lazy writer
Lazy writes/sec 0

Total number of processes waiting for a workspace memory grant
Memory Grants Pending 0

Total number of processes that have successfully acquired a workspace memory grant
Memory Grants Outstanding 0

---

第二次查詢，檢查記憶體壓力：

SELECT object_name, cntr_value 
FROM sys.dm_os_performance_counters 
WHERE counter_name IN ('Total Server Memory (KB)', 'Target Server Memory (KB)');

結果：

object_name|cntr_value
SQLServer:Memory Manager        |1638272
SQLServer:Memory Manager        |531712
(2 row(s) affected)

---

• 我的伺服器是 32 位的。我們不會出於任何原因遷移到 64 位。
• sp_configur無法提供來自電子資訊的值，這是保密的。:)

首先，每當您發布與 SQL Server 相關的問題時，請發布“SQL Server 的版本和版本”，您不會相信答案可能會隨著版本的不同而完全改變。

最近我們注意到我們的 SQL Server 2005 實例的 VM 已送出記憶體空間增長了，幾乎達到了我們設置為 1.7 GB 的 VM 保留空間（嗯，太多了？）。

你為什麼看VM committedand VM reserved，你真的知道它在說什麼嗎？您想從 VM 送出/保留中推斷出什麼。VM 保留是 SQL Server 保留的虛擬地址空間 (VAS) 總量。SQL Server 可以根據其 VAS 限制保留 VAS，即 64 位為 8 TB，32 位預設為 2 G。所以當虛擬機保留高時沒有問題。這是正常行為。保留的記憶體實際上是 SQL Server“認為”它將來可能使用的記憶體。而且由於保留的 VM 是 1.7 GI，所以不認為這有問題

VM 已送出意味著虛擬地址空間 (VAS) 或 SQL Server 已送出的虛擬記憶體或physical RAM系統上支持的記憶體的總量。已送出的記憶體具有與之關聯的物理記憶體。已送出表示 SQL Server 目前正在使用的總虛擬記憶體。

當我們的 VM Committed 值接近 VM Reserved 值時，服務會大大減慢。我知道解決這個問題的唯一方法是停止所有 SQL 服務服務並重新啟動它們。但是在 24 小時內，VM Committed 仍然在爬升！

在 SQL Server 上，送出的虛擬機可以等於保留的虛擬機，這不一定是問題。請不要養成重新啟動 SQL Server IMO 的習慣，這是你能做的最糟糕的事情。現在我認為您在 SQL Server 中面臨性能問題，您需要首先找出導致伺服器緩慢的實際原因。要開始使用，您可以參考如何分析 SQL Server 性能

這實際上可以幫助您找出問題所在。相信我，從您發布的內容來看，在我看來，它似乎不是記憶體問題，您再次提供了有關 SQL Server 版本的有限資訊，因此我的回答是有限的。

請在您的問題中添加以下輸出

Select @@Version

您的 SQL Server 是否已修補到 SQL Server 2005 SP4。一定是。您可以使用以下命令閱讀錯誤日誌並將其內容髮佈到某個共享位置並附加有問題的連結嗎？我想看看錯誤日誌中有什麼。

sp_readerrorlog

你說你只有 4 G 的 SQL Server 你為 SQL Server 設置了最大伺服器記憶體嗎？

Windows Server 2003 是否已修補到最新的 Service Pack。確保 Windows Server 中存在過度修剪 SQL Server 記憶體的錯誤。

編輯：

.Microsoft SQL Server 2005 - 9.00.4053.00 (Intel X86) 2009 年 5 月 26 日 14:24:20 版權所有 (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 5.2（Build 3790：Service Pack 2）

您的 SQL Server 是 32 位，而 Windows Server 是標準版 32 位。無論如何，您不能強制 Windows 伺服器使用超過 4 G 的 RAM，因此在 SQL Server 上啟用 AWE 是沒有意義的，因為它可能允許數據和索引頁面查看超出 2 G 的 VAS 限制的記憶體。我只能建議您將 SQL Server 和 Windows 作業系統都升級到 64 位。我會推薦帶有 SP2 的 SQL Server 2012 和 windows Server 2012 或 windows server 2008 r2，但要確保兩者都是 64 位的。

如果這是不可能的，您可以將 Windows Server 2003 從標準升級到企業，那麼您可以啟用 PAE 並且視窗伺服器可以看到超過 4 G。之後啟用 AWE 以允許 SQL Server 數據和索引頁面看到大於 2 G 的記憶體。到目前為止，無論如何，SQL Server VAS 都被限制為 2G，因此它無法訪問超過 2G 的記憶體

如果您想了解有關 32 位記憶體配置的資訊，請閱讀本文

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