為什麼伺服器上的磁碟 I/O 會飆升到 100%
磁碟 I/O 飆升到 100% 意味著你的儲存子系統已經無法即時處理不斷湧入的讀寫請求。觸發原因幾乎總是某個背景工作、排程服務，或突發的工作負載。硬體故障很少是主要原因。
高應用程式負載、低效查詢、過於詳細的日誌記錄、備份工作以及組態限制，通常才是最常見的罪魁禍首。你會看到延遲上升、查詢卡頓、逾時，以及連鎖式服務故障。這些問題都會迅速損害系統效能。
本文將說明為什麼磁碟 I/O 會升高、如何追蹤尖峰來源，以及哪些修復措施可以恢復正常吞吐量。
磁碟 I/O 基礎與 100% 尖峰
磁碟 I/O 指的是伺服器送往儲存裝置的每一次讀寫操作。每個請求都會帶來成本。IOPS 衡量裝置每秒能完成多少次這類請求。延遲衡量單次請求完成所需的時間。佇列深度表示正在排隊等待處理的請求數量。這三個指標會連動變化，而且它們比單看使用率更能說明問題。
作業系統如何衡量磁碟使用率
作業系統會依固定時間間隔對儲存裝置進行取樣。它會記錄在取樣視窗內，裝置至少有一個請求正在處理中所佔用的時間百分比。這個百分比就是你在監控工具中看到的使用率數值。100% 的讀值只表示磁碟在整個取樣視窗內從未閒置，並不代表磁碟已經損壞或即將損壞。
這個差異非常重要。一個忙碌的磁碟在佇列較短時，依然可能快速回應請求。可是一旦磁碟達到 100%，同時佇列又很深，那就是另一回事了。在 Windows Server 上，磁碟效能可能飆升到 90%–100%。使用者會立刻感受到這種延遲。
為什麼磁碟 I/O 飆升到 100% 會傷害效能
當儲存被打滿時，請求就會開始堆積。應用程式等待資料的時間會變長，而增加的延遲會向磁碟之上的每一層擴散。查詢會停滯，逾時會觸發，依賴它的服務也會隨之變慢。因此，磁碟 I/O 飆升到 100% 會演變成整個系統層面的問題，而不只是儲存問題。
CPU 的表現也能說明同樣的問題。請留意 I/O wait 百分比，它顯示的是處理器有多少時間處於閒置狀態，只是在等待儲存完成操作。
如果 I/O wait 百分比大於 1 除以 CPU 核心數，那麼你的 CPU 核心就在等待磁碟。
在一台四核心伺服器上，這個門檻是 25%。一旦超過，處理器就無事可做，只能等儲存追上來。理解磁碟 I/O 及其對系統效能的影響，要從這裡開始：使用率告訴你磁碟很忙，而延遲和佇列深度則告訴你這種忙碌是否真的在傷害效能。
高磁碟 I/O 負載的原因
磁碟 I/O 突然飆升到 100%，幾乎總是由某個背景工作或排程服務引起。硬體故障很少是原因。你應該先查看工作負載模式和軟體行為，因為大多數故障都可以從這兩個面向解釋。
工作負載與應用程式原因
資料密集型應用程式如果在沒有快取的情況下執行大型檔案或資料庫操作，就會造成很高的磁碟 I/O。每個請求都會直接打到儲存裝置上，佇列很快就會增加。你可以透過兩個訊號辨識這種模式：I/O 需求很高，而 CPU 使用率卻很低。伺服器大部分時間都耗在等待外部操作上，因此當磁碟吃緊時，處理器反而處於閒置狀態。
常見例子包括：處理大量網路請求的 Web 伺服器與資料庫伺服器、頻繁讀寫磁碟的檔案伺服器，以及需要頻繁發起網路請求與擷取資料的用戶端應用程式，例如郵件用戶端或社群媒體應用程式。
SQL Server 執行個體則會以另一種形式表現出同樣的問題。這裡的高 I/O 通常來自大量掃描、更多的頁面查找，以及高頁面讀取量。最佳化不佳的查詢會迫使資料庫引擎讀取遠超結果集實際所需的資料頁。缺少索引，會讓原本應該是小範圍查找的操作變成全資料表掃描，而代價最終由磁碟承擔。
軟體、驅動程式與組態原因
並不是所有尖峰都能追溯到應用需求。若某次高 I/O 持續時間固定，且 I/O 模式重複出現，那更可能是驅動程式或軟體問題，而不是硬體損壞。規律性本身就是線索。真正的硬體退化通常表現為不穩定、無規律，而不是像節拍器一樣精準重複。
例如，一個 Linux VM 如果顯示磁碟讀取量在 1G 左右的高位運行，這種讀取流量就足以迫使其他操作等待，即便 CPU 仍有空閒容量。瓶頸出現在儲存路徑上，所有競爭該路徑的程序都會受到影響。
多種軟體與組態問題都可能產生這種壓力。下表將每一種原因與可用於確認它的測試方式對應起來。
| 軟體 / 驅動程式 / 組態問題 | 表明是軟體或驅動程式問題（而非硬體）的證據 |
|---|---|
| OneDrive/SharePoint 檔案同步打滿磁碟 I/O | 暫時暫停 OneDrive 同步，並觀察磁碟 I/O 壓力是否下降；如果效能恢復，原因就是軟體（同步行為），而不是硬體。 |
| 防毒 / EDR 掃描占用磁碟資源 | 暫時暫停 AV 掃描，並檢查 Task Manager 中的磁碟 I/O；如果 I/O 降低，則問題出在安全軟體，而非硬體故障。 |
| 瀏覽器與背景程序爭搶磁碟資源 | 使用 Task Manager（Ctrl+Shift+Esc）或 macOS Activity Monitor，辨識哪個程序（如 Teams.exe、OneDrive、AV、瀏覽器）是主要的磁碟 I/O 消耗者。 |
| 桌面用戶端設定、快取或本機環境問題 | 將桌面用戶端與 Web 用戶端進行比較。如果 Web 用戶端表現更好，則問題與桌面用戶端設定、快取或本機環境有關，而不是硬體。 |
| 過時或故障的 GPU 驅動程式 / 硬體加速 | 在 Teams Settings → General → Use hardware acceleration 中切換硬體加速，再測試後更新 GPU 驅動程式。驅動程式問題可能導致看似像硬體故障的渲染問題。 |
| 損壞的 Teams 快取 | 清理 %appdata% 下的 Teams 快取；如果問題解決，則說明這是軟體/快取問題，而不是硬體。 |
| 對 Teams 程序過於激進的 AV/EDR 掃描 | 與安全團隊合作，為 Teams 程序建立安全例外，或調整掃描排程；問題得到解決即可證明屬於軟體原因。 |
還有一個因素值得注意。dpc 佇列的組織方式會影響系統處理延遲程序呼叫的方式，而在高磁碟 I/O 負載下，錯誤設定的佇列可能進一步增加延遲。無論這些來源中的哪一種造成了過量磁碟 I/O，都會拖累所有依賴儲存的服務效能。在調查高磁碟 I/O 時，尖峰出現的模式與時間點，是你最有力的證據。
硬體與基礎設施限制
工作負載與軟體問題解釋了大多數尖峰，但儲存裝置本身仍可能構成硬上限。在歸咎於應用程式之前，你應該先排除這些限制。
何時是磁碟本身成為瓶頸
每顆磁碟都有自己的 IOPS 上限，而一旦工作負載超過這個上限，請求就會持續排隊。老舊的 HDD 所能提供的 IOPS 遠低於現代 SSD，因此以前運行良好的任務，如今也可能把機械碟打滿。故障中的 SSD 則表現不同：它可能在徹底損壞前就開始變慢、重試操作，或吞吐量下降。RAID 重建會給整個陣列帶來大量背景讀寫，而這些重建流量會一直與正式業務競爭，直到重建完成。
這些情況確實存在，但比起工作負載與軟體原因，它們並不常見。先檢查磁碟健康狀態、SMART 資料以及陣列狀態。如果硬體回報正常，就應該去別處查找原因。
虛擬化與雲端儲存的影響
虛擬機會與其他租戶共用實體儲存。當鄰居執行個體運行重負載工作時，你的執行個體也會在同一個佇列裡等待，於是你會看到 I/O 效能下降，但這與自身工作負載無關。雲端執行個體也面臨同樣的問題。雲端服務供應商會依據磁碟區類型限制 IOPS，而共用儲存池還會吸收來自其他客戶的壓力。
這種「吵雜鄰居」效應很難僅從單一來賓系統內部證明。請將你的指標與服務供應商基線進行比較，並在一天中的不同時間進行測試。如果某種模式總是跟著別人的作息出現，那指向的就是共用基礎設施，而不是你的伺服器。
與工作負載和軟體原因相比，硬體故障依然很少見。應將磁碟 I/O 限制視為容量問題，而不是預設解釋。當你調查瓶頸時，請先透過廠商規格與服務供應商文件確認上限，再決定是否更換硬體。
如何診斷高磁碟 I/O 尖峰
看不見，就修不好。先用對工具，再把這些指標放在一起看。單獨一個使用率數字會誤導你。延遲、佇列深度與等待時間一起，才能揭示真正的問題。
第一時間應查看的指標與命令
Linux 提供了多種適合此類工作的工具。使用 iostat 查看每個裝置的吞吐量與延遲，使用 iotop 查看每個程序的活動，使用 atop 取得系統即時快照，使用 pidstat 查看按時間取樣的程序層級統計資訊。在 Windows 上，可以使用 Performance Monitor、Resource Monitor 以及底層 Perfmon 計數器。每個工具回答的問題略有不同，所以你應依據需要確認的內容來選擇。
| 工具 | 平台 | 可查看內容 |
|---|---|---|
iostat | Linux | 每個裝置的吞吐量、延遲與佇列深度 |
iotop | Linux | 每個程序的讀寫活動 |
atop | Linux | 系統範圍的即時資源快照 |
pidstat | Linux | 按時間取樣的程序層級統計資訊 |
| Performance Monitor | Windows | 歷史計數器與警示 |
| Resource Monitor | Windows | 即時的每程序磁碟活動 |
請把這些指標結合起來看，不要孤立解讀。高使用率但佇列短、延遲低，通常是無害的。高使用率同時佇列很深、延遲上升，則是緊急情況。還要檢查 I/O wait。如果 I/O wait 超過 1 除以 CPU 核心數，那麼處理器就是在空等儲存追上來。在四核心機器上，這個門檻是 25%。這種排障方法能幫助你區分：磁碟只是繁忙，還是已經成為真正的瓶頸。
將尖峰追蹤到具體程序
一旦確認了尖峰，就要把它對應到具體來源。請依照以下步驟操作：
- 在
iotop或 Resource Monitor 中依磁碟活動對程序排序。 - 記錄磁碟占用最高的程序及其讀寫速率。
- 檢查這種模式是否按固定週期重複出現，例如每 13 秒一次的模式通常說明是驅動程式或軟體問題。
- 將其出現時間與排程工作、cron 工作與備份視窗進行交叉比對。
- 檢查該程序的擁有者、服務名稱以及啟動時間。
如果一個程序只在備份視窗中出現，那就指向排程工作。如果它持續運行，那就更像應用程式或服務。如果某種模式以機械般精準的節奏重複，那通常指向驅動程式問題。假設你發現某個 Linux VM 的讀取量達到大約 1G，而其他操作都在等待，這樣的流量規模就能很快鎖定元凶，你也就能及時處理。
目標其實很簡單：確認尖峰、找出程序、歸類原因。這個順序可以把模糊的效能下降，轉化成一個具體且可修復的問題。
修復並預防 I/O 效能問題
立即緩解措施
你已經把尖峰追蹤到某個程序。現在就可以採取行動。先從成本最低的修復著手：限制或重新安排有問題的工作。一個在尖峰時段執行的備份工作，可以移到維護視窗。同步用戶端可以在辦公時間暫停。這些調整幾乎沒有成本，而且通常幾分鐘內就能緩解瓶頸。
接下來，在最需要的地方增加快取。調整 I/O 使用最高的服務，讓更多資料快取在 RAM 中。這樣可以減少對儲存的直接讀取並縮短佇列。對於資料庫工作負載，要最佳化慢查詢並補上缺少的索引。一次全資料表掃描會比一次單列查找帶來多得多的讀取壓力。還應把詳細日誌移到獨立磁碟區上。若日誌與資料放在同一顆磁碟上，等於把同一裝置上的壓力加倍。
長期預防與監控
被動修復只能爭取時間。預防才能阻止問題再次發生。請在系統正常運行時為 I/O 效能建立基線。記錄每個磁碟區的典型 IOPS、延遲與佇列深度。這些數字會在問題出現時成為你的參考標準。
針對延遲與佇列深度設定警示，而不只是盯著使用率。一個 100% 但延遲很低的磁碟，表示它很忙，但依然健康。一個只有 60% 使用率卻延遲持續上升的磁碟，反而是危險訊號。在高磁碟 I/O 負載再次來臨之前，提前做好容量規劃。每一季審查成長趨勢，並在需求到來前預先擴充儲存。當你能及早發現問題時，管理與解決這類故障就會容易得多。高磁碟 I/O 負載下的效能表現，仰賴的是準備，而不是運氣。
磁碟 I/O 飆升到 100% 是一種症狀，而不是根本原因。真正的答案通常隱藏在工作負載模式、應用程式行為或基礎設施限制之中。請遵循這個順序：確認尖峰、識別程序、歸類原因、然後採取措施。這個流程能把模糊的系統變慢，轉變成一個可定位、可修復的問題。
主動監控可以預防大多數事故。追蹤基線、延遲與佇列深度——而不只是使用率。一個忙碌但佇列短的磁碟依然健康。延遲上升則是提早暴露風險的訊號。
應把磁碟 I/O 視為容量與架構設計問題。要在高負載再次出現之前就規劃好儲存成長。你的系統效能仰賴準備，而不是運氣。
常見問題
磁碟顯示 100% 就代表硬碟要壞了嗎？
不是。這個數值只表示裝置在取樣視窗內始終處於忙碌狀態。故障中的磁碟通常表現為無規律的異常，而不是穩定的高飽和。請先檢查 SMART 資料與陣列狀態以排除硬體問題。如果這些都正常，就應把重點放在工作負載與軟體上。
我要怎麼判斷原因是軟體還是硬體？
觀察時序模式。重複出現的規律通常指向驅動程式或軟體問題；硬體退化則更像是隨機發生。你也可以暫停一個可疑服務，例如同步用戶端或防毒掃描，看看壓力是否下降。若暫停後恢復正常，就能確認是軟體原因。
當使用率看起來很高時，哪個指標最重要？
延遲與佇列深度比單純的使用率更有參考價值。一個忙碌但佇列短的磁碟依然健康。延遲上升才是真正的危險訊號。同時也要檢查 I/O wait。當它超過 1 除以 CPU 核心數時，處理器就是在空等儲存回應。
虛擬機會自己造成儲存瓶頸嗎？
有時會。但你的執行個體也在與其他租戶共用實體儲存。鄰居執行個體運行重負載工作時，會把你的請求一併推入同一個佇列。請將自己的指標與服務供應商基線比較，並在不同時段測試。如果某種模式總是跟著他人的時間表出現，那就表示問題出在共用基礎設施。
當尖峰出現時，我應該先修什麼？
先限制或重新安排有問題的工作。把備份工作移到維護視窗，或在辦公時間暫停同步用戶端。然後再增加快取、最佳化慢查詢，並把詳細日誌移到獨立的磁碟區上。這些措施通常能在幾分鐘內緩解瓶頸。
