為什麼需要定期重新啟動以保持我的實例執行良好？
我們在 SQL 2005 上有一個生產數據庫伺服器。一切都正常執行了一段時間，但幾週後我們看到性能顯著下降。只有重新啟動 SQL Server 才能使性能恢復正常。
一些背景：
- 執行超過 1200 個數據庫（大部分是單租戶，一些是多租戶）。在任何人談論只遷移到多租戶之前，保持這種結構是有正當理由的……
- 記憶體為 16 GB。重新啟動後，SQL Server 很快就會恢復到 15 GB 的使用量。
- 活動數據庫連接大約有 80 個連接——考慮到每個程序的每個 Web 伺服器有一個連接池，我們認為這相當健康——所以我們沒有連接洩漏問題。
我們在非高峰時間嘗試了幾件事： - 執行 DBCC DROPCLEANBUFFERS（帶有 CHECKPOINT）以清除數據記憶體。它沒有任何效果，也不會清除任何 RAM 使用情況）。- 執行 FREEPROCCACHE 和 FREESYSTEMCACHE 以清除查詢計劃和儲存的 proc 記憶體。沒有效果。
顯然，在活動的生產環境中重新啟動 SQL Server 並不理想。我們缺少一些東西。還有人經歷這個嗎？
更新：2012 年 4 月 28 日 仍在與這個問題作鬥爭。我已將 SQL Server 的記憶體降低到 10 GB，只是為了排除與作業系統的任何爭用。我越來越接近縮小範圍，但需要我下一步的幫助。
這是我發現的，重新啟動 SQL Server 後，頁面文件在 12.3 GB 和 12.5 GB 之間徘徊。它會保持這種狀態好幾天。伺服器執行緒總數將在 850 到 930 之間掛起 - 連續幾天也穩定且一致（sqlserver 穩定在 55 到 85 之間，具體取決於流量）。
然後，有一個“事件”。我不知道事件是什麼，我在日誌中看不到它，我在星期幾或它發生的時間看不到任何一致的東西，但他的頁面文件突然跳轉到 14.1 或 14.2 GB，執行緒跳轉到 1750 到 1785 之間。
發生這種情況時檢查性能，其中 900 多個執行緒是 sqlserver。所以我去 sp_who2 看看這些執行緒是從哪裡來的……只有使用過的 80 個左右的數據庫連接。
所以….有沒有人知道我如何找到 SQL 伺服器上這 900 個執行緒的其餘部分在哪裡，以及它們在做什麼？
更新：2012 年 6 月 1 日 仍在與這個問題作鬥爭。對於仍在閱讀本文的任何人，執行緒跳躍的問題已得到解決。這是由自動更新的 ComVault 備份軟體引起的。它正在創建一個執行緒，試圖備份不再存在的數據庫（它正在維護以前數據庫的列表），而不僅僅是備份目前數據庫。
但是 - 問題仍然存在，我們必須每週重新開始，或多或少幾天。與 Rackspace 團隊合作，看看他們是否能有所啟發。
你說一切都很好，然後幾週後，性能下降。（通常，人們聲稱性能下降很快，或者在特定時間，或者看似隨機的時間間隔。這可能意味著糟糕的 I/O 性能或鎖定風暴或在奇怪的時間執行的 CPU 密集型查詢，或重量級計劃作業或缺乏索引或錯誤的統計數據導致 CPU 密集型查詢或磁碟讀取。或其他東西。）周是不尋常的。
我的假設是您伺服器上的另一個應用程序正在洩漏記憶體。我在病毒軟體（每個 DBA 最喜歡的伺服器軟體惡棍）和第 3 方監控軟體中看到了這一點。隨著時間的推移，我會仔細檢查 SQL Server 的記憶體使用情況，並且還會獲取盒子上所有其他應用程序的所有記憶體使用情況。如果您對 SQL Server 的記憶體使用設置了硬性限制並將其設置為不允許分頁，則可能是其他應用程序正在被分頁並耗盡 I/O 容量。
不難尋找。如果您還沒有在伺服器上保存指標，我會啟動 Perfmon 並讓它每 30 或 60 分鐘抓取一次樣本。幾天后，您可能會看到另一個應用程序的記憶體使用率上升。
SQL Server 日誌中是否有錯誤消息指出“sql server 的重要部分已被分頁”？這也將是一個很大的線索。
讓我祝賀您能夠在一個只有 16 GB RAM 的 SQL Server 實例上執行 1200 個 DB，並且在平穩執行幾週後只遇到這些類型的問題。在當地 PASS 章節講述的好故事。
現在進行故障排除：SQL 和作業系統的 RAM 均為 16 GB。我假設您的最大記憶體設置為 15 GB 或最大。這可能會導致緩衝池用完所有記憶體並阻塞作業系統。您是說清理緩衝池和記憶體沒有顯示任何差異，而且您的 PLE 高於 300。這證明了記憶體瓶頸。伺服器上的 CPU 和 IO（規格/統計數據）如何？
執行
select * from sys.dm_exec_request where session_id>50 and session_id<>@@spid以及您看到的資源爭用是什麼（wait_type、wait_time、last_wait_type、wait_resource）。