全部產品
Search
文件中心

:Linux系統磁碟I/O負載較高問題的排查與處理

更新時間:Jun 20, 2025

使用Linux執行個體時,如果遇到執行個體運行卡頓或檔案讀寫速度較慢等問題,可能是磁碟I/O 負載高導致,您可以參考本文內容排查並解決問題。

問題現象

使用Linux系統的ECS執行個體時,出現如下現象。

  • 出現系統運行卡頓、檔案讀寫變慢、應用效能下降或內部服務響應慢等問題。

  • 通過ECS控制台查看執行個體磁碟I/O負載監控時,發現磁碟I/O負載過高(參考值:當前I/O讀寫≥該雲端硬碟I/O效能指標的80%,可認為I/O負載過高)。

  • 收到了磁碟I/O負載超過設定閾值的警示資訊。

可能原因

引起磁碟I/O負載過高的常見原因如下:

  • 異常的進程或服務佔用大量磁碟I/O,導致磁碟I/O負載過高。

  • 業務程式及業務情境對執行個體的磁碟I/O負載要求較高,執行個體的磁碟I/O效能不足以支撐業務開展所需的磁碟I/O效能要求。

排查步驟

要定位磁碟I/O負載過高的問題,您可以參見下述操作步驟進行問題的排查定位。

使用iostat查看整體磁碟I/O負載

iostat是一款Linux系統中監控I/O效能的工具,可以查看磁碟整體I/O負載情況。

  1. 執行如下命令,查看系統I/O負載情況。

    sudo iostat -d -m 3 5

    遇到“iostat: command not found” 問題如何處理?

    大多數Linux發行版已預裝iostat 工具(通常包含在 sysstat 工具包中),無需手動安裝。若未找到該命令,可以執行如下命令安裝該工具。

    Alibaba Cloud Linux / CentOS / Fedora

    sudo yum install -y sysstat

    Ubuntu / Debian

    sudo apt install -y sysstat

    openSUSE

    sudo zypper install -y sysstat
    說明
    • -d:僅顯示裝置統計資訊,不顯示CPU使用方式。

    • -m:以MB為單位顯示。

    • 3:統計時間間隔。

    • 5:統計次數。

    回顯結果樣本如下。

    Linux 5.10.134-18.al8.x86_64 (iZbpxxxxxxxxxxxxxxxaqhZ)  04/07/2025      _x86_64_        (4 CPU)
    
    Device             tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
    vda             145.67         0.00       126.81          0        380
    vdb               0.00         0.00         0.00          0          0
    
    Device             tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
    vda             161.33         0.00       127.24          0        381
    vdb               0.00         0.00         0.00          0          0
    ......

    顯示結果中各項參數說明如下。更多參數說明,請運行man iostat查看。

    • Device磁碟名稱。

    • tps:每秒I/O請求數。

    • MB_read/s:每秒檔案讀取速度。

    • MB_wrtn/s:每秒檔案寫入速度。

    • MB_read:讀取的檔案大小。

    • MB_wrtn:寫入的檔案大小。

重要
  • 若檢測到磁碟I/O實際效能顯著低於阿里雲官方公布的Block Storage服務效能指標,建議您優先檢查磁碟分割是否完成4K對齊。通過確認分區對齊狀態,可快速定位因對齊配置不當導致的效能損耗問題。

  • 關於Block Storage效能的更多資訊,請參見雲端硬碟概述

使用iotop查看進程的磁碟IO負載

iotop是一個用來監視磁碟I/O使用狀況的工具,可以查看單個進程的磁碟IO負載。

  1. 執行如下命令,安裝iotop。

    Alibaba Cloud Linux / CentOS / Fedora

    sudo yum install -y iotop

    Ubuntu / Debian

    sudo apt install -y iotop

    openSUSE

    sudo zypper install -y iotop
  2. 執行如下命令,查看磁碟I/O負載。

    sudo iotop -P -k -d 3
    說明
    • -P:顯示PID。

    • -k:以KB為單位顯示。

    • -d:統計時間間隔,單位為秒,預設值為1。

    回顯結果樣本如下。如需退出程式,請按q鍵。

    Total DISK READ :       0.00 K/s | Total DISK WRITE :   80373.45 K/s
    Actual DISK READ:       0.00 K/s | Actual DISK WRITE:  127781.85 K/s
        PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                                                  
      17250 be/4 root        0.00 K/s 80354.87 K/s  0.00 % 95.99 % dd if=/dev/zero of=/mnt/dev_vdb/swap bs=1M count=10240
      15192 be/3 root        0.00 K/s    6.64 K/s  0.00 % 60.56 % [jbd2/vdb1-8]
      17152 be/4 root        0.00 K/s    0.00 K/s  0.00 % 59.55 % [kworker/u8:0
    ......

    關於回顯結果的參數說明如下,更多參數說明,可執行iotop -h查詢。

    • PID:進程ID。

    • DISK READ:進程讀操作的I/O速度。

    • DISK WRITE:進程寫操作的I/O速度。

    • SWAPIN:進程等待從交換空間(Swap Space)換入(Swap In)記憶體頁面所佔用的 CPU 時間百分比。

    • IO>:進程因 I/O 等待所佔用的 CPU 時間百分比(包括 Swap 換入和磁碟 I/O 等待)。

    • COMMAND:進程的命令名稱。

說明

如果定位到kjournald進程佔用較高磁碟I/O資源,建議修改對應分區的Journal size參數解決該問題。具體操作,請參見kjournald進程佔用較高磁碟I/O資源問題處理

處理磁碟I/O負載高的問題

常見磁碟I/O負載高問題原因及解決方案如下。

問題現象

原因

解決方案

異常使用者程式或進程長時間佔用大量磁碟I/O資源。

該程式為異常程式或進程,運行時佔用過多磁碟I/O資源。

通過在iotop工具定位到佔用磁碟I/O資源較多的程式的PID,並通過sudo kill -9 <PID>來結束該進程。

警告

在您結束進程前,請務必確保您瞭解該進程的相關資訊,避免因誤操作導致您的業務中斷。

正常使用者程式或進程長時間佔用大量磁碟I/O資源。

該程式為正常業務程式或進程,運行時佔用過多磁碟I/O資源。

如果雲端硬碟出現磁碟I/O效能瓶頸,您可以根據實際情況選擇對應的處理方案:

  • 變更雲端硬碟類型:當使用SSD雲端硬碟出現磁碟I/O瓶頸時,您可以選擇更換雲端硬碟類型為ESSD,以提升雲端硬碟效能。相關操作,請參見變更雲端硬碟類型

  • 變更雲端硬碟效能層級:當使用ESSD雲端硬碟出現磁碟I/O瓶頸時,您可以升級雲端硬碟的效能層級。相關操作,請參見修改ESSD雲端硬碟效能層級

  • 修改雲端硬碟效能配置:當使用ESSD AutoPL雲端硬碟出現磁碟I/O瓶頸時,您可以修改雲端硬碟效能配置。相關操作,請參見修改ESSD AutoPL雲端硬碟效能配置

  • 升級執行個體規格:當升級雲端硬碟規格時,遇到執行個體規格限制無法升級效能更好的雲端硬碟時,您可以先升級執行個體規格。相關操作,請參見修改執行個體規格

  • 沒有單個程式或進程佔用大量磁碟I/O資源。

  • 單個程式或進程偶發磁碟I/O佔用過高,但期間較短,且發生頻率較低。

當前執行個體的服務正常運行所需磁碟I/O資源效能大於執行個體的磁碟I/O效能。

常見問題

檢查磁碟分割是否完成4K對齊

您可以參考如下操作,以確認當前磁碟裝置分區是否完成4k對齊。下述樣本中以/dev/vdb1裝置分區為例,實際使用中請您根據實際情況替換裝置分區名稱。

說明

4K對齊是指將分區的起始位置和檔案系統的邏輯簇的起始位置與硬碟的物理扇區大小(通常為4KB)進行對齊。以提升磁碟I/O效能。

  1. 運行如下命令,查看裝置分區是否4k對齊。

    sudo parted /dev/vdb1 align-check optimal 1

    回顯結果樣本如下,表明該裝置分區已經4K對齊。您可以跳過下述步驟,繼續查看處理磁碟I/O負載高的問題

    1 aligned
  2. 如果裝置分區沒有完成4k對齊,請手動進行處理,具體操作,請參見建立GPT分區時,分區未對齊如何解決

  3. 在完成裝置分區4k對齊後,您可以重新查詢磁碟I/O讀寫效能,以確認是否達到阿里雲官方公布的Block Storage服務效能指標。

kjournald進程佔用較高磁碟I/O資源問題處理

  • 問題現象:使用iotop排查分析,發現kjournald進程佔用了大量磁碟I/O資源。

  • 問題原因:該問題通常是由於ext3檔案系統設定的Total Journal size太小導致。

    說明

    kjournald是ext3檔案系統的核心日誌管理進程,負責執行I/O操作的日誌記錄與同步。在持續向ext3檔案系統執行寫入操作時,該進程會不斷累加日誌佔用空間。當預寫記錄檔(Journal)的大小達到預先設定的Total Journal Size閾值時,系統將觸發強制日誌落盤操作。此時,進程會阻塞後續寫入請求直至同步完成,可能引發CPU資源爭用加劇、記憶體佔用激增及整體I/O效能下降等問題。

  • 解決方案

    • 使用Workbench終端串連登入Linux執行個體(SSH)

    • 執行如下命令,查看相應分區的Journal size大小。下述樣本中以/dev/vdb1裝置為例,實際使用中請您根據實際情況替換裝置名稱。

      sudo dumpe2fs /dev/vdb1 | grep -i Journal

      回顯結果樣本如下,表示/dev/xvda1分區的Total Journal size為64 M。

      dumpe2fs 1.46.0 (29-Jan-2020)
      Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
      Journal inode:            8
      Journal backup:           inode blocks
      Journal features:         (none)
      Total journal size:       64M
      Total journal blocks:     16384
      Journal sequence:         0x00000001
      Journal start:            0
    • 執行如下命令,查詢該裝置當前的掛載資訊。

      sudo mount | grep /dev/vdb1

      回顯資訊樣本如下,記錄該資訊以供後續重新掛載該裝置。

      /dev/vdb1 on /mnt/dev_vdb type ext4 (rw,relatime)
    • 執行如下命令,卸載該裝置。

      sudo umount /dev/vdb1
      說明

      如果卸載時出現如下報錯:umount: /mnt/dev_vdb: target is busy,表明當前裝置正在使用,您可以結束等待該裝置

    • 執行如下命令,修改Journal size大小為 400 M。您可以結合實際業務情境、Block Storage裝置參數等因素進行綜合考慮,以設定合適的Total journal size大小。

      sudo mke2fs -J size=400 /dev/vdb1
    • 修改完成後,運行如下命令,重新掛載該裝置。

      sudo mount /dev/vdb1 /mnt/dev_vdb/

相關文檔