內存未滿時分頁文件使用率高

Question

我收到了一台托管 SQL Server 的服務器，我被要求對其性能問題的原因進行罰款。

在監視 PerfMon 時，我發現：

分頁文件： % 使用率 = 3 天平均25% 。 內存：頁/秒 > 1 平均 3 天。 我所知道的是，如果 % Usage 大於 2%，那么由於內存壓力和內存空間不足，分頁過多。 但是，如果當我打開資源監視器，內存選項卡時，我發現：

-26 GB 正在使用中（總 RAM 為 32 GB）-2 GB 待機 - 和4 GB 內存可用！！！！！！

如果有 4 GB 空閑內存，為什么要分頁？！ 最重要的是為什么它（分頁百分比）太高了？！

有人請解釋這種情況以及如何將頁面文件的使用百分比降低到正常水平。

請注意，SQL Server Max. 內存設置為15GB

Answer 1

頁面文件的使用本身並不是一個主要的危險信號。 即使有足夠的 RAM 可用，操作系統也會傾向於使用頁面文件，因為它允許它在需要時從 RAM 轉儲內存的相關部分 - 不要將頁面文件的使用視為內存從 RAM移動到 HDD -這只是一個副本。 所有訪問仍將使用 RAM，操作系統只是在為意外情況做准備 - 如果它沒有將內存預先寫入頁面文件，則內存請求將不得不等待“舊”內存在釋放之前被轉儲RAM 用於其他用途。

此外，您似乎對分頁的工作方式有些困惑。 所有用戶空間內存總是被分頁，這與頁面文件本身無關 - 它只是意味着您正在使用虛擬內存。 您正在尋找的指標是每秒硬故障數（編輯：呃，我誤讀了您正在閱讀的內容 - 頁數/秒是有多少硬故障；不過，其余的仍然適用），它告訴您發生的頻率操作系統必須實際從頁面文件中讀取數據。 即便如此，每秒 1 次也非常低。 在該數字超過每秒 50 次之前，您幾乎看不到任何東西，而對於 SSD 而言則要高得多（在我的特定系統上，我可能會遇到數千個硬故障而沒有明顯的內存延遲 - 這會因實際硬盤驅動器和您的芯片組和驅動程序）。

最后，SQL Server 性能受到影響的方式太多了。 如果您沒有真正的 DBA（或者至少是具有豐富 DB 經驗的人），那么您就有麻煩了。 您的大多數查詢行都會將您引向死胡同 - 像數據庫引擎一樣復雜和優化的東西總是很難正確診斷。 識別跡象 - 是否存在高 CPU 使用率？ RAM使用率高嗎？ 是否存在 I/O 使用率高的查詢？ 是否有特定查詢給您帶來麻煩，或者整個數據庫是否受到影響？ 您的索引和表格是否得到妥善維護？ 這些只是最基本的。 一旦你有一些像這樣的額外信息，試試DBA.StackExchange.com - SO 並不是尋求 DBA 建議的正確地方:)

Answer 2

真的只是在黑暗中拍攝一些照片，可能有點隨機，但我幾乎無法立即發現：

• 是否有進程會選擇無用的大數據集或運行過於頻繁的操作？ （例如，糟糕的應用程序開發人員的做法是在任何地方使用SELECT *或獲取所有數據，然后在應用程序級別對其進行過濾或在循環中運行數據庫查詢而不是獲取一次記錄集等）
• 索引正確嗎？ （例如，盡可能減少關鍵查找操作的葉元素，是否使用適當的索引備份大量查詢以避免表和索引掃描等）
• 如何管理數據群？ （例如，是否可能由於不正確的聚集索引或並行插入而導致頁面拆分過多，是否發生了一些索引重建等）