一、概述

1.1 背景介紹

監控大屏上iowait突然飆到 80%，SSH 連上去敲個ls要等 5 秒才有響應，業務日志瘋狂報超時，數據庫慢查詢告警刷屏。這種場景在 SRE 的日常里出現頻率極高，尤其是跑著 MySQL、Elasticsearch、Kafka 這類重 IO 業務的機器上。CPU 看著不高，內存也沒爆，但系統就是卡得像被凍住了一樣——十有八九是磁盤 IO 出了問題。

磁盤 IO 問題的棘手之處在于，它不像 CPU 打滿那樣一眼就能看出來。IO 瓶頸可能藏在文件系統層、Block 層、設備驅動層，甚至是 RAID 卡的緩存策略里。一個%util100% 到底意味著什么？await高是磁盤慢還是隊列深？svctm這個指標還能不能信？這些問題如果搞不清楚，排查就會走彎路。

這篇文章從 Linux IO 棧的全貌講起，把 iostat、iotop、blktrace、fio、bpftrace 這套工具鏈串起來，覆蓋從"發現 IO 問題"到"定位根因"再到"調優解決"的完整鏈路。

1.2 技術特點

全棧視角：從 VFS 到塊設備驅動，逐層拆解 IO 路徑，不停留在工具表面

工具鏈完整：iostat 看全局、iotop 定進程、blktrace 追請求、fio 做基準、bpftrace 抓延遲

面向實戰：每個工具都給出真實場景下的輸出解讀，不是照搬 man page

調優閉環：不只是發現問題，還覆蓋 readahead、dirty ratio、調度器等內核參數調優

1.3 適用場景

場景一：生產環境突發 IO 飆升，系統響應變慢甚至卡死，需要快速定位是哪個進程在瘋狂讀寫

場景二：數據庫服務器 IO 延遲周期性升高，需要區分是磁盤性能不足還是應用層 IO 模式有問題

場景三：新機器上線前需要做磁盤性能基準測試，評估 SSD/HDD 是否滿足業務 IOPS 和吞吐需求

場景四：容器環境下多個 Pod 共享磁盤，需要找出 IO 資源的爭搶源頭

1.4 環境要求

二、Linux IO 棧全景與調度器

要排查 IO 問題，首先得搞清楚一個 IO 請求從應用程序發出到磁盤完成，中間經過了哪些環節。不理解 IO 棧的層次結構，看 iostat 的輸出就只是在看數字。

2.1 IO 棧分層架構

應用程序 (read/write/pread/pwrite/io_uring)
  |
  v
VFS (Virtual File System) --- Page Cache
  |
  v
文件系統 (ext4 / xfs / btrfs)
  |
  v
Block Layer (通用塊層)
  | - IO 合并 (merge)
  | - IO 調度 (mq-deadline/bfq/kyber/none)
  | - 請求隊列 (多隊列 blk-mq)
  v
設備驅動 (NVMe driver / SCSI / virtio-blk)
  |
  v
物理設備 (NVMe SSD / SATA SSD / HDD / 云盤)

每一層都可能成為瓶頸，排查時需要逐層排除：

VFS + Page Cache 層：大部分讀請求會命中 Page Cache 直接返回，根本不會到磁盤。如果free -h看到buff/cache很小，或者sar -B顯示pgpgin很高，說明緩存命中率低，大量讀請求穿透到了磁盤。寫請求默認走 writeback 模式，先寫到 Page Cache 的臟頁里，由內核的pdflush/flush線程異步刷盤。

文件系統層：ext4 的 journal 寫入、xfs 的 log 寫入都會產生額外的 IO。文件系統碎片化嚴重時，順序讀會退化成隨機讀。filefrag命令可以查看文件碎片程度。

Block Layer：這是 iostat 能觀測到的層。IO 請求在這里被合并（相鄰的小 IO 合并成大 IO）、排序、調度。blk-mq（多隊列塊層）是 6.x 內核的默認架構，每個 CPU 核心有獨立的軟件隊列，減少了鎖競爭。

設備驅動和物理設備：NVMe 設備有自己的硬件多隊列（通常 64 個隊列，每隊列 64K 深度），SATA SSD 只有單隊列（NCQ 深度 32）。這個差異直接影響并發 IO 性能。

2.2 IO 調度器詳解

內核 6.x 提供了四種 IO 調度器，針對不同設備類型選擇合適的調度器對性能影響很大。

# 查看當前磁盤使用的調度器（方括號標記的是當前生效的）
cat /sys/block/sda/queue/scheduler
# 輸出示例：[mq-deadline] kyber bfq none

# 運行時切換調度器（立即生效，不需要重啟）
echo"bfq"> /sys/block/sda/queue/scheduler

四種調度器的選型策略：

選型建議：NVMe SSD 直接用none，不要畫蛇添足加調度器。HDD 用mq-deadline保證讀延遲可控。多用戶共享 HDD 的場景（比如編譯服務器）用bfq防止某個進程獨占 IO 帶寬。kyber在實際生產中用得不多，它的自適應機制在負載波動大的場景下表現不夠穩定。

# 持久化調度器配置（udev 規則）
cat > /etc/udev/rules.d/60-io-scheduler.rules <

	

	2.3 SSD vs HDD 的 IO 特性差異

	理解 SSD 和 HDD 的物理特性差異，是正確解讀 IO 指標的前提。

				特性
			

				HDD
			

				SATA SSD
			

				NVMe SSD
		

				隨機讀 IOPS
			

				100-200
			

				30K-90K
			

				200K-1M+
		

				隨機寫 IOPS
			

				100-200
			

				20K-70K
			

				100K-500K+
		

				順序讀吞吐
			

				150-250 MB/s
			

				500-560 MB/s
			

				3-7 GB/s
		

				順序寫吞吐
			

				150-250 MB/s
			

				400-530 MB/s
			

				2-5 GB/s
		

				平均延遲
			

				5-15ms
			

				0.05-0.1ms
			

				0.01-0.03ms
		

				隊列深度
			

				1（NCQ=32）
			

				32（NCQ）
			

				64K x 多隊列
		

				%util 參考意義
			

				高（機械臂同一時刻只能服務一個位置）
			

				低（內部并行度高）
			

				極低（不要看這個指標）
		

	這里有一個非常關鍵的認知：**%util對 SSD 幾乎沒有參考價值**。HDD 是單通道設備，%util100% 確實意味著磁盤忙不過來。但 SSD 內部有大量并行通道，%util100% 可能只用了實際能力的 10%。判斷 SSD 是否到達瓶頸，應該看await（IO 延遲）和實際 IOPS 是否接近設備標稱值。

	三、iostat 輸出深度解讀

	iostat 是 IO 排查的第一站，但它的輸出字段很多，不少人只會看%util，這遠遠不夠。

	3.1 iostat 基礎用法

	
# 最常用的命令：每秒刷新一次，顯示擴展信息，單位用 MB
# -x 擴展模式 -m 單位MB -t 顯示時間戳 1 間隔1秒
iostat -xmt 1

# 只看特定磁盤
iostat -xmt -d nvme0n1 sda 1

# 看第一次輸出要注意：第一行是系統啟動以來的累計平均值，不是實時數據
# 從第二行開始才是每秒的實時數據，排查問題時忽略第一行


	

	3.2 輸出字段逐個拆解

	一條典型的 iostat -x 輸出：

	
Device r/s  rkB/s  rrqm/s %rrqm r_await rareq-sz w/s  wkB/s  wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util
sda   850.00 13600.0 45.00  5.03  0.85   16.00   320.00 25600.0 120.00 27.27 2.30   80.00  0.00 0.00  0.00  0.00  0.00   0.00   0.00 0.00  1.25  78.40


	

	核心指標解讀：

				指標
			

				含義
			

				怎么看
		

				r/s /w/s
			

				每秒完成的讀/寫請求數（IOPS）
			

				HDD 超過 150 就要警惕，NVMe 到 10 萬都正常
		

				rkB/s /wkB/s
			

				每秒讀/寫的數據量（吞吐）
			

				對比磁盤標稱帶寬，接近上限說明帶寬打滿
		

				rrqm/s /wrqm/s
			

				每秒合并的讀/寫請求數
			

				合并率高說明應用的 IO 模式比較友好（順序或相鄰）
		

				r_await /w_await
			

				讀/寫請求的平均耗時（ms），包含隊列等待+設備服務時間
			

				最重要的延遲指標 。HDD 正常 5-15ms，SSD 正常 0.05-0.5ms
		

				aqu-sz
			

				平均請求隊列長度
			

				隊列長說明設備處理不過來，請求在排隊
		

				%util
			

				設備繁忙時間百分比
			

				HDD 有參考意義，SSD 參考價值低（前面解釋過）
		

				rareq-sz /wareq-sz
			

				平均請求大小（KB）
			

				判斷 IO 模式：4-8KB 是典型隨機 IO，128KB+ 是順序 IO
		

	已廢棄的 svctm：老版本 iostat 有svctm（設備服務時間）字段，sysstat 12.x 已經標記為不可靠并計劃移除。這個值是用%util / (r/s + w/s)反算出來的，在多隊列設備上完全失真。不要再用svctm做任何判斷。

	3.3 iostat 實戰判斷模板

	
# 場景判斷速查：
# 1. await 高 + aqu-sz 高 + %util 高 → 磁盤確實忙不過來（HDD 常見）
# 2. await 高 + aqu-sz 低 + %util 低 → 單個 IO 慢，可能是磁盤硬件問題或 RAID 降級
# 3. await 正常 + w/s 極高 + wkB/s 低 → 大量小寫入，考慮合并 IO 或調大 dirty ratio
# 4. rrqm/s 接近 0 + rareq-sz 很小 → 純隨機讀，Page Cache 沒起作用
# 5. w_await 遠高于 r_await → 寫入瓶頸，檢查 fsync 頻率和 journal 模式


	

	3.4 用 sar 看 IO 歷史趨勢

	iostat 只能看實時數據，要回溯歷史得靠 sar。sysstat 默認每 10 分鐘采集一次數據，保存在/var/log/sysstat/或/var/log/sa/下。

	
# 查看今天的磁盤 IO 歷史（-d 磁盤統計，-p 顯示設備名）
sar -dp 0

# 查看昨天的數據
sar -dp -f /var/log/sysstat/sa$(date -d yesterday +%d)

# 查看指定時間段
sar -dp -s 0200 -e 0400

# 輸出示例：
# 0201 DEV    tps   rkB/s   wkB/s areq-sz aqu-sz await %util
# 0201 sda   1250.00 10000.00 40000.00  40.00  3.50  2.80 92.00
# 0201 sda   120.00  960.00  2400.00  28.00  0.15  1.25 12.00


	

	凌晨 2:10 到 2:20 之間 IO 明顯飆升，tps 從 120 跳到 1250，%util從 12% 到 92%。結合業務日志看這個時間段在做什么——大概率是定時任務（備份、日志輪轉、ETL 作業）。

	四、iotop 定位 IO 密集進程

	iostat 告訴你磁盤整體很忙，但不告訴你是誰在讀寫。這時候需要 iotop 來定位到具體進程。

	4.1 iotop 基礎用法

	
# 需要 root 權限（依賴內核的 taskstats 接口）
# -o 只顯示有 IO 活動的進程（過濾掉空閑的）
# -P 顯示進程而不是線程
# -a 累積模式（顯示自啟動以來的累計 IO 量）
sudo iotop -oP

# 推薦使用 iotop-c（C 語言重寫版，性能更好）
# Ubuntu: sudo apt install iotop-c
sudo iotop-c -oP


	

	4.2 iotop 輸出解讀

	
Total DISK READ:    125.50 M/s | Total DISK WRITE:    42.30 M/s
Actual DISK READ:   125.50 M/s | Actual DISK WRITE:    8.75 M/s
  TID PRIO USER   DISK READ DISK WRITE SWAPIN   IO>  COMMAND
 12847 be/4 mysql   98.20 M/s  5.60 M/s  0.00 % 82.35 % mysqld --defaults-file=/etc/mysql/my.cnf
 3021 be/4 root   22.10 M/s  0.00 B/s  0.00 % 15.20 % tar czf /backup/db-20260206.tar.gz /var/lib/mysql
  891 be/4 elastic  5.20 M/s  36.70 M/s  0.00 %  8.50 % java -Xms16g ... elasticsearch


	

	幾個關鍵信息：

	Total DISK READ/WRITE：所有進程請求的 IO 總量（經過 Page Cache 之前）

	Actual DISK READ/WRITE：實際落到磁盤的 IO 量。Actual WRITE 遠小于 Total WRITE 是正常的，因為寫入先到 Page Cache，異步刷盤

	**IO>**：該進程等待 IO 的時間占比，這個值高說明進程被 IO 阻塞了

	PRIO：IO 優先級，be/4表示 best-effort 類第 4 級（默認值）

	上面的輸出一眼就能看出：mysql 進程在瘋狂讀數據（98 MB/s），同時有個 tar 備份任務也在讀（22 MB/s）。兩個大讀取任務疊加，磁盤帶寬被打滿了。

	4.3 用 ionice 調整 IO 優先級

	找到了搗亂的進程，如果不能直接 kill，可以用 ionice 降低它的 IO 優先級：

	
# IO 調度類：
# 1 = Realtime（實時，慎用）
# 2 = Best-effort（默認，0-7 級，數字越小優先級越高）
# 3 = Idle（空閑時才執行，適合備份任務）

# 把備份進程降到 Idle 級別（只在磁盤空閑時才給它 IO）
sudo ionice -c 3 -p 3021

# 啟動備份任務時直接指定低優先級
sudo ionice -c 3 nice -n 19 tar czf /backup/db-20260206.tar.gz /var/lib/mysql

# 注意：ionice 只在 bfq 和 mq-deadline 調度器下生效
# none 調度器（NVMe 默認）不支持 IO 優先級


	

	4.4 pidstat 補充進程級 IO 統計

	iotop 是交互式的，不方便腳本化采集。pidstat 可以按固定間隔輸出進程 IO 數據：

	
# -d 顯示 IO 統計 1 每秒采集 10 采集10次
pidstat -d 1 10

# 只看特定進程
pidstat -d -p 12847 1

# 輸出示例：
# Time   UID PID  kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
# 1501 999 12847 98200.00 5600.00  800.00   45  mysqld


	

	kB_ccwr/s是被取消的寫入量（寫入 Page Cache 后又被覆蓋，沒有實際落盤），iodelay是進程因為 IO 等待而被延遲的 tick 數。

	五、blktrace + btt 深度分析

	iostat 和 iotop 能解決 80% 的 IO 問題，但遇到復雜場景——比如需要知道 IO 請求在塊層各個階段分別花了多少時間——就需要 blktrace 出場了。

	5.1 blktrace 工作原理

	blktrace 在內核的塊層埋了追蹤點，記錄每個 IO 請求的完整生命周期：

	
Q (Queued)   → 請求進入塊層隊列
G (Get request) → 分配 request 結構體
M (Merged)   → 與已有請求合并
I (Inserted)  → 插入調度器隊列
D (Dispatched) → 下發到設備驅動
C (Completed)  → 設備完成 IO


	

	每個階段之間的時間差就是該階段的耗時。Q→C是總耗時，D→C是設備實際服務時間，Q→D是在軟件層排隊和調度的時間。

	5.2 blktrace 實戰

	
# 采集 sda 的塊層追蹤數據，持續 10 秒
sudo blktrace -d /dev/sda -w 10 -o trace

# 會生成 trace.blktrace.0, trace.blktrace.1 ... 每個 CPU 一個文件

# 用 blkparse 解析成可讀格式
blkparse -i trace -o trace.txt

# 輸出示例（每行一個事件）：
# 8,0 1 1 0.000000000 12847 Q R 123456 + 8 [mysqld]
# 8,0 1 2 0.000001200 12847 G R 123456 + 8 [mysqld]
# 8,0 1 3 0.000002500 12847 I R 123456 + 8 [mysqld]
# 8,0 1 4 0.000015000 12847 D R 123456 + 8 [mysqld]
# 8,0 1 5 0.000850000   0  C R 123456 + 8 [0]
# 解讀：mysqld 發起了一個讀請求，扇區 123456 開始讀 8 個扇區（4KB）
# Q→D 排隊 15us，D→C 設備服務 835us，總耗時 850us


	

	5.3 btt 統計分析

	逐行看 blkparse 輸出不現實，btt 工具可以自動統計各階段的延遲分布：

	
# 用 btt 分析（需要先用 blkparse 生成二進制格式）
blkparse -i trace -d trace.bin
btt -i trace.bin

# btt 輸出的關鍵段落：

# ==================== All Devices ====================
#       ALL      MIN      AVG      MAX      N
# --------------- ------------- ------------- ------------- -----------
# Q2C        0.000085000  0.001250000  0.025000000    12847
# Q2D        0.000005000  0.000018000  0.000350000    12847
# D2C        0.000080000  0.001232000  0.024800000    12847

# Q2C = 總延遲（隊列到完成）
# Q2D = 軟件層延遲（隊列到下發）
# D2C = 硬件層延遲（下發到完成）


	

	上面的數據說明：平均總延遲 1.25ms，其中軟件層只占 0.018ms，硬件層占 1.232ms。瓶頸在設備本身，不在內核調度。如果反過來 Q2D 很大而 D2C 很小，說明是調度器或隊列配置有問題。

	5.4 iowatcher 可視化

	blktrace 的數據還可以用 iowatcher 生成可視化圖表，直觀展示 IO 模式：

	
# 安裝 iowatcher
sudo apt install iowatcher

# 生成 SVG 圖表
iowatcher -t trace -o io-pattern.svg

# 圖表包含：IOPS 時間線、吞吐時間線、IO 延遲分布、IO 偏移量分布（可以看出是順序還是隨機）


	

	六、fio 磁盤性能基準測試

	排查 IO 問題時經常需要回答一個基本問題：這塊磁盤到底能跑多快？是磁盤本身性能不行，還是應用的 IO 模式有問題？fio 是回答這個問題的標準工具。

	6.1 fio 核心參數

	
# 安裝 fio
sudo apt install fio  # Debian/Ubuntu
sudo dnf install fio  # RHEL/Fedora


	

	fio 的參數很多，但核心就這幾個：

				參數
			

				含義
			

				常用值
		

				--rw
			

				IO 模式
			

				read /write/randread/randwrite/randrw
		

				--bs
			

				塊大小
			

				4k （數據庫隨機IO）、128k/1m（順序IO）
		

				--iodepth
			

				隊列深度
			

				HDD 用 1-4，SATA SSD 用 32，NVMe 用 64-128
		

				--ioengine
			

				IO 引擎
			

				libaio （Linux AIO）、io_uring（推薦，內核 6.x）
		

				--numjobs
			

				并發任務數
			

				通常 1-4，測多隊列性能時增大
		

				--size
			

				測試文件大小
			

				至少是內存的 2 倍，避免 Page Cache 干擾
		

				--direct
			

				繞過 Page Cache
			

				1 （基準測試必須開啟）
		

				--runtime
			

				運行時長
			

				60-120 秒，太短數據不穩定
		

	6.2 標準測試場景

	
# 場景1：隨機讀 IOPS（模擬數據庫查詢）
fio --name=rand-read --ioengine=io_uring --rw=randread 
  --bs=4k --iodepth=64 --numjobs=4 --size=4G 
  --direct=1 --runtime=60 --group_reporting 
  --filename=/dev/nvme0n1 # 注意：直接測裸設備會銷毀數據！測試用文件更安全

# 更安全的方式：在文件系統上測試
fio --name=rand-read --ioengine=io_uring --rw=randread 
  --bs=4k --iodepth=64 --numjobs=4 --size=4G 
  --direct=1 --runtime=60 --group_reporting 
  --directory=/mnt/test

# 場景2：隨機寫 IOPS（模擬數據庫寫入）
fio --name=rand-write --ioengine=io_uring --rw=randwrite 
  --bs=4k --iodepth=64 --numjobs=4 --size=4G 
  --direct=1 --runtime=60 --group_reporting 
  --directory=/mnt/test

# 場景3：順序讀吞吐（模擬大文件掃描、備份）
fio --name=seq-read --ioengine=io_uring --rw=read
  --bs=1m --iodepth=16 --numjobs=1 --size=8G 
  --direct=1 --runtime=60 --group_reporting 
  --directory=/mnt/test

# 場景4：混合隨機讀寫 7:3（模擬 OLTP 數據庫）
fio --name=mixed-rw --ioengine=io_uring --rw=randrw --rwmixread=70 
  --bs=4k --iodepth=32 --numjobs=4 --size=4G 
  --direct=1 --runtime=60 --group_reporting 
  --directory=/mnt/test


	

	6.3 fio 輸出解讀

	
rand-read: (groupid=0,jobs=4): err= 0: pid=5678
read: IOPS=185.2k, BW=723MiB/s (758MB/s)
  slat (nsec): min=1200, max=85000, avg=2850.00, stdev=1200.00
  clat (usec): min=45, max=12500, avg=1350.00, stdev=680.00
  lat (usec): min=48, max=12520, avg=1353.00, stdev=681.00
  clat percentiles (usec):
  | 1.00th=[ 120], 5.00th=[ 245], 10.00th=[ 400],
  | 50.00th=[ 1150], 90.00th=[ 2350], 95.00th=[ 2900],
  | 99.00th=[ 4500], 99.50th=[ 5800], 99.99th=[10800]
 bw ( KiB/s): min=680000, max=760000, per=100.00%, avg=740800.00
 iops    : min=170000, max=190000, avg=185200.00


	

	關鍵指標：

	IOPS=185.2k：每秒 18.5 萬次隨機讀，這是一塊性能不錯的 NVMe SSD

	slat（submission latency）：提交延遲，從應用發起到進入內核，通常在微秒級

	clat（completion latency）：完成延遲，從進入內核到 IO 完成，這是最關注的指標

	lat：總延遲 = slat + clat

	clat percentiles：延遲分位數，P99=4.5ms 說明 99% 的請求在 4.5ms 內完成。關注 P99 和 P99.9，平均值會掩蓋長尾延遲

	6.4 io_uring vs libaio

	內核 6.x 環境下強烈推薦使用io_uring引擎替代傳統的libaio：

	
# 對比測試：同樣參數，只換引擎
# libaio
fio --name=aio-test --ioengine=libaio --rw=randread 
  --bs=4k --iodepth=128 --numjobs=1 --size=4G 
  --direct=1 --runtime=30 --directory=/mnt/test

# io_uring
fio --name=uring-test --ioengine=io_uring --rw=randread 
  --bs=4k --iodepth=128 --numjobs=1 --size=4G 
  --direct=1 --runtime=30 --directory=/mnt/test


	

	io_uring 的優勢在于減少了系統調用次數（通過共享內存的提交/完成隊列），在高 IOPS 場景下能比 libaio 高出 10%-30% 的性能。現代數據庫（如 PostgreSQL 16+、RocksDB）已經原生支持 io_uring。

	七、文件系統選擇

	文件系統是 IO 棧中直接影響性能的一層，選錯文件系統可能導致性能差距達到 2-3 倍。

	7.1 ext4 / xfs / btrfs 對比

				特性
			

				ext4
			

				xfs
			

				btrfs
		

				最大文件系統
			

				1 EB
			

				8 EB
			

				16 EB
		

				最大單文件
			

				16 TB
			

				8 EB
			

				16 EB
		

				元數據日志
			

				有序/回寫
			

				有序
			

				CoW（無傳統日志）
		

				在線擴容
			

				支持
			

				支持
			

				支持
		

				在線縮容
			

				支持
			

				不支持
			

				支持
		

				快照
			

				不支持
			

				不支持
			

				原生支持
		

				透明壓縮
			

				不支持
			

				不支持
			

				支持（zstd/lzo）
		

				小文件性能
			

				優秀
			

				良好
			

				一般
		

				大文件順序寫
			

				良好
			

				優秀
			

				良好
		

				并發寫入
			

				一般（單 journal）
			

				優秀（延遲分配）
			

				良好
		

				生產穩定性
			

				極高
			

				極高
			

				高（6.x 內核已成熟）
		

	選型建議：

	數據庫服務器（MySQL/PostgreSQL）：xfs。延遲分配和優秀的并發寫入性能對數據庫友好，RHEL 默認文件系統

	通用 Linux 服務器：ext4。最穩定、最成熟、調優資料最多，Ubuntu 默認文件系統

	需要快照/壓縮的場景（日志存儲、容器存儲）：btrfs。透明壓縮可以節省 30%-50% 的磁盤空間，快照功能方便備份

	Kubernetes 節點：xfs。containerd/CRI-O 的 overlayfs 在 xfs 上表現更好

	7.2 文件系統掛載參數調優

	
# ext4 高性能掛載參數
mount -o noatime,nodiratime,barrier=0,data=writeback /dev/sda1 /data
# noatime: 不更新訪問時間戳，減少寫入
# nodiratime: 不更新目錄訪問時間
# barrier=0: 關閉寫屏障（僅在有 BBU 的 RAID 卡上使用，否則斷電丟數據）
# data=writeback: 元數據日志模式，比默認的 ordered 快但斷電風險略高

# xfs 高性能掛載參數
mount -o noatime,logbufs=8,logbsize=256k /dev/sda1 /data
# logbufs=8: 增大日志緩沖區數量
# logbsize=256k: 增大日志緩沖區大小

# /etc/fstab 持久化配置
/dev/nvme0n1p1 /data xfs defaults,noatime,logbufs=8,logbsize=256k 0 2


	

	八、IO 性能調優

	8.1 readahead 預讀調優

	預讀是內核在檢測到順序讀模式時，提前讀取后續數據到 Page Cache 的機制。對順序讀密集的場景（日志分析、數據導出）效果顯著。

	
# 查看當前預讀值（單位：512字節扇區，默認 256 = 128KB）
blockdev --getra /dev/sda

# 調大預讀值（適合順序讀場景，如 Kafka、HDFS）
sudo blockdev --setra 2048 /dev/sda # 1MB 預讀

# 調小預讀值（適合純隨機讀場景，如數據庫 OLTP）
sudo blockdev --setra 64 /dev/sda  # 32KB 預讀

# 持久化配置（udev 規則）
echo'ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{bdi/read_ahead_kb}="1024"'
  > /etc/udev/rules.d/61-readahead.rules


	

	8.2 dirty ratio 臟頁參數調優

	臟頁參數控制 Page Cache 中臟數據的刷盤策略，直接影響寫入性能和數據安全性。

	
# 查看當前臟頁參數
sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs vm.dirty_writeback_centisecs

# 參數說明：
# vm.dirty_ratio = 20      # 臟頁占內存 20% 時，寫入進程被阻塞，同步刷盤（硬上限）
# vm.dirty_background_ratio = 10 # 臟頁占內存 10% 時，后臺線程開始異步刷盤（軟上限）
# vm.dirty_expire_centisecs = 3000 # 臟頁超過 30 秒必須刷盤
# vm.dirty_writeback_centisecs = 500 # 后臺刷盤線程每 5 秒喚醒一次


	

	不同場景的調優策略：

	
# 數據庫服務器（低延遲優先，減少突發刷盤導致的延遲毛刺）
sysctl -w vm.dirty_ratio=5
sysctl -w vm.dirty_background_ratio=2
sysctl -w vm.dirty_expire_centisecs=1000
sysctl -w vm.dirty_writeback_centisecs=100

# 日志/流式寫入服務器（吞吐優先，允許更多臟頁緩沖）
sysctl -w vm.dirty_ratio=40
sysctl -w vm.dirty_background_ratio=20
sysctl -w vm.dirty_expire_centisecs=6000
sysctl -w vm.dirty_writeback_centisecs=500

# 持久化到 /etc/sysctl.d/60-io-tuning.conf
cat > /etc/sysctl.d/60-io-tuning.conf <

	

	8.3 隊列深度與 nr_requests 調優

	
# 查看塊設備隊列深度
cat /sys/block/sda/queue/nr_requests
# 默認值通常是 256

# NVMe 設備的硬件隊列深度
cat /sys/block/nvme0n1/queue/nr_requests

# 對于高并發 IO 場景，可以適當增大隊列深度
echo1024 > /sys/block/sda/queue/nr_requests

# 查看當前 IO 合并策略
cat /sys/block/sda/queue/nomerges
# 0 = 允許合并（默認） 1 = 禁止前向合并 2 = 完全禁止合并
# 純隨機 IO 場景可以設為 2，省去合并檢查的開銷


	

	8.4 cgroup v2 IO 限制

	在多租戶或容器環境下，用 cgroup v2 的 io 控制器限制進程的 IO 帶寬和 IOPS：

	
# 查看設備號（major:minor）
ls -l /dev/sda
# brw-rw---- 1 root disk 8, 0 ... → 設備號 8:0

# 創建 cgroup 并設置 IO 限制
mkdir -p /sys/fs/cgroup/backup-jobs
echo"+io"> /sys/fs/cgroup/backup-jobs/cgroup.subtree_control

# 限制 sda 上的讀寫帶寬為 50MB/s，IOPS 為 1000
echo"8:0 rbps=52428800 wbps=52428800 riops=1000 wiops=1000"
  > /sys/fs/cgroup/backup-jobs/io.max

# 把備份進程加入這個 cgroup
echo$BACKUP_PID> /sys/fs/cgroup/backup-jobs/cgroup.procs

# Kubernetes 中通過 Pod 的 resources 或 annotation 配置
# 也可以用 io.latency 控制器設置延遲目標
echo"8:0 target=5000"> /sys/fs/cgroup/db-workload/io.latency
# 保證 db-workload 組的 IO 延遲不超過 5ms，其他組讓路


	

	九、常見 IO 問題排查案例

	9.1 案例一：凌晨定時任務導致數據庫延遲飆升

	現象：每天凌晨 230，MySQL 慢查詢數量暴增 10 倍，await從 0.5ms 飆到 15ms。

	排查過程：

	
# 1. 先看 iostat 確認 IO 確實有問題
iostat -xmt 1
# 發現 w_await 從 0.5ms 漲到 15ms，wkB/s 從 20MB/s 漲到 180MB/s

# 2. iotop 找出誰在寫
sudo iotop -oP
# 發現兩個大戶：
# mysqld   → 20MB/s 寫入（正常業務）
# rsync    → 160MB/s 讀取（備份任務在全量拷貝數據目錄）

# 3. 確認 rsync 是定時任務觸發的
ps aux | grep rsync
# root 5432 rsync -avz /var/lib/mysql/ backup-server:/backup/mysql/

# 4. rsync 的大量順序讀把磁盤帶寬吃滿，MySQL 的隨機 IO 被擠壓


	

	解決方案：

	
# 方案1：用 ionice 降低備份任務優先級
ionice -c 3 nice -n 19 rsync -avz /var/lib/mysql/ backup-server:/backup/mysql/

# 方案2：用 cgroup v2 限制備份任務的 IO 帶寬
echo"8:0 rbps=52428800 wbps=52428800"> /sys/fs/cgroup/backup/io.max

# 方案3：用 rsync 的 --bwlimit 限制傳輸速率
rsync -avz --bwlimit=50000 /var/lib/mysql/ backup-server:/backup/mysql/
# --bwlimit 單位是 KB/s，50000 = 50MB/s


	

	9.2 案例二：ext4 journal 寫放大導致寫入性能驟降

	現象：一臺跑 Elasticsearch 的機器，寫入吞吐突然從 200MB/s 降到 40MB/s，iostat 顯示w/s很高但wareq-sz只有 4KB。

	排查過程：

	
# 1. iostat 看寫入模式
iostat -xmt -d sda 1
# w/s=8500 wkB/s=34000 wareq-sz=4.0 w_await=3.5 %util=98

# 大量 4KB 小寫入，這不像 ES 的正常行為（ES 的 segment merge 是大塊順序寫）

# 2. 用 blktrace 看寫入來源
sudo blktrace -d /dev/sda -w 5 -o journal-trace
blkparse -i journal-trace | grep"W"| awk'{print $NF}'| sort | uniq -c | sort -rn | head
# 發現大量寫入來自 [jbd2/sda1-8]，這是 ext4 的 journal 線程

# 3. 檢查文件系統 journal 模式
tune2fs -l /dev/sda1 | grep"Journal"
# Default mount options: journal_data
# journal_data 模式會把所有數據都寫一遍 journal，寫放大 2 倍！


	

	解決方案：

	
# 切換到 ordered 模式（只對元數據做 journal，數據直接寫）
sudo mount -o remount,data=ordered /data

# 或者在 /etc/fstab 中修改
/dev/sda1 /data ext4 defaults,noatime,data=ordered 0 2

# 如果是 ES 這種自己管理數據一致性的應用，甚至可以用 writeback 模式
# 但要確保有 UPS 或 BBU，否則斷電可能丟數據


	

	9.3 案例三：NVMe SSD %util 100% 但實際遠未飽和

	現象：監控告警 NVMe 磁盤%util持續 100%，但業務沒有感知到任何延遲。

	排查過程：

	
# 1. iostat 看詳細指標
iostat -xmt -d nvme0n1 1
# r/s=45000 rkB/s=180000 r_await=0.08 aqu-sz=3.6 %util=100

# r_await 只有 0.08ms（80 微秒），完全正常
# IOPS 45K，這塊 NVMe 標稱能跑 500K IOPS，遠沒到極限

# 2. 這是 %util 計算方式的問題
# %util = (IO 請求數 * 每次 IO 耗時) / 采樣間隔
# 當并發 IO 足夠多時，即使每個 IO 很快，%util 也會算到 100%
# 對于多隊列設備，%util 100% 不代表設備飽和


	

	結論：這是一個誤告警。對 NVMe SSD 應該基于await和 IOPS 來判斷是否飽和，而不是%util。監控告警規則需要調整：

	
# Prometheus 告警規則（修正版）
# 不再用 %util 告警 NVMe 設備，改用 await
-alert:DiskIOHighLatency
expr:|
  rate(node_disk_io_time_weighted_seconds_total[5m])
  / rate(node_disk_io_time_seconds_total[5m]) > 0.005
for:5m
labels:
 severity:warning
annotations:
 summary:"磁盤 IO 平均延遲超過 5ms"


	

	十、bpftrace 追蹤 IO 延遲

	iostat 給的是平均值，blktrace 數據量太大不適合長期運行。bpftrace 可以用極低的開銷實時追蹤 IO 延遲分布，是定位長尾延遲問題的利器。

	10.1 biolatency：IO 延遲直方圖

	
# bcc-tools 自帶的 biolatency 腳本（最簡單的用法）
sudo biolatency-bpfcc -D 1
# -D 按磁盤分別統計 1 每秒輸出一次

# 輸出示例：
# disk = nvme0n1
#   usecs        : count  distribution
#     0 -> 1     : 0    |                    |
#     2 -> 3     : 0    |                    |
#     4 -> 7     : 125   |**                   |
#     8 -> 15     : 2840   |****************************************|
#     16 -> 31     : 1950   |***************************       |
#     32 -> 63     : 680   |*********                |
#     64 -> 127    : 245   |***                   |
#    128 -> 255    : 42    |                    |
#    256 -> 511    : 8    |                    |
#    512 -> 1023    : 3    |                    |
#    1024 -> 2047    : 1    |                    |

# 大部分 IO 在 8-31 微秒完成，但有少量請求到了毫秒級——這就是長尾延遲


	

	10.2 自定義 bpftrace 腳本：按進程追蹤 IO 延遲

	biolatency 只能看全局分布，如果要按進程區分，需要自己寫 bpftrace 腳本：

	
# 保存為 io-latency-by-process.bt
sudo bpftrace -e'
tracepointblock_rq_issue
{
  @start[args->dev, args->sector] = nsecs;
  @comm[args->dev, args->sector] = comm;
}

tracepointblock_rq_complete
/@start[args->dev, args->sector]/
{
  $lat = (nsecs - @start[args->dev, args->sector]) / 1000; // 轉換為微秒
  @latency[@comm[args->dev, args->sector]] = hist($lat);
  delete(@start[args->dev, args->sector]);
  delete(@comm[args->dev, args->sector]);
}

END
{
  clear(@start);
  clear(@comm);
}
'

# 輸出會按進程名分別顯示延遲直方圖：
# @latency[mysqld]:
# [8, 16)  1250 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
# [16, 32)  680 |@@@@@@@@@@@@@@@@@@@@@          |
# ...
# @latency[rsync]:
# [128, 256) 420 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
# [256, 512) 380 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  |
# ...


	

	10.3 biosnoop：逐條追蹤 IO 請求

	當需要看每一條 IO 請求的詳細信息時，用 biosnoop：

	
# 追蹤所有 IO 請求，顯示進程名、延遲、扇區等
sudo biosnoop-bpfcc -d nvme0n1

# 輸出示例：
# TIME(s) COMM     PID  DISK   T SECTOR    BYTES LAT(ms)
# 0.000  mysqld    12847 nvme0n1  R 12345678   4096  0.08
# 0.001  mysqld    12847 nvme0n1  R 12345686   4096  0.09
# 0.003  jbd2/sda1-8 891  nvme0n1  W 98765432   16384 0.15
# 0.850  rsync    5432 nvme0n1  R 55555555   131072 0.12

# 只看延遲超過 1ms 的慢 IO
sudo biosnoop-bpfcc -d nvme0n1 -Q | awk'$NF > 1.0'


	

	10.4 ext4slower / xfs_slower：文件系統級慢 IO 追蹤

	有時候塊設備層延遲正常，但文件系統層有額外開銷（鎖競爭、journal 等待）。bcc-tools 提供了文件系統級別的慢操作追蹤：

	
# 追蹤 ext4 上超過 1ms 的操作
sudo ext4slower-bpfcc 1

# 追蹤 xfs 上超過 1ms 的操作
sudo xfsslower-bpfcc 1

# 輸出示例：
# TIME   COMM     PID  T BYTES  OFF_KB  LAT(ms) FILENAME
# 1501 mysqld    12847 R 16384  1024   2.35  ibdata1
# 1501 mysqld    12847 S 0    0    5.80  ib_logfile0
# T 列：R=read W=write O=open S=fsync
# fsync 延遲 5.8ms，這可能是 journal 寫入導致的


	

	這個工具能直接關聯到文件名，比 biosnoop 更容易定位到具體是哪個文件的 IO 有問題。

	十一、IO 排查流程總結

	11.1 排查決策樹

	
系統卡頓/業務超時
 |
 v
top 看 %wa (iowait) ──── 低 → 不是 IO 問題，排查 CPU/內存/網絡
 |
 高
 v
iostat -xmt 1 ──── await 正常 → 可能是應用層阻塞，不是磁盤瓶頸
 |
 await 高
 v
判斷設備類型 ──── NVMe → 看 await + IOPS，忽略 %util
 |        HDD → %util + await + aqu-sz 綜合判斷
 v
iotop -oP ──── 找到 IO 大戶進程
 |
 v
分析 IO 模式 ──── wareq-sz/rareq-sz 小(4-8KB) → 隨機 IO
 |        wareq-sz/rareq-sz 大(128K+) → 順序 IO
 v
深入分析 ──── blktrace+btt 看各階段延遲
 |      bpftrace 看延遲分布和長尾
 |      fio 做基準對比
 v
調優/解決 ──── 調度器/readahead/dirty ratio/cgroup 限制/硬件升級


	

	11.2 工具速查表

				工具
			

				用途
			

				關鍵命令
			

				開銷
		

				top
			

				看 iowait 占比
			

				top -d 1 ，按 1 展開核心
			

				極低
		

				iostat
			

				磁盤整體 IOPS/延遲/吞吐
			

				iostat -xmt 1
			

				極低
		

				sar
			

				IO 歷史趨勢回溯
			

				sar -dp -s 02:00 -e 04:00
			

				無（讀歷史數據）
		

				iotop
			

				定位 IO 密集進程
			

				sudo iotop -oP
			

				低
		

				pidstat
			

				進程級 IO 統計（可腳本化）
			

				pidstat -d 1 10
			

				極低
		

				ionice
			

				調整進程 IO 優先級
			

				ionice -c 3 -p 
			

				無
		

				blktrace
			

				塊層 IO 請求全生命周期追蹤
			

				blktrace -d /dev/sda -w 10
			

				中（生成大量數據）
		

				btt
			

				blktrace 數據統計分析
			

				btt -i trace.bin
			

				無（離線分析）
		

				fio
			

				磁盤基準性能測試
			

				見第六章各場景命令
			

				高（壓測工具）
		

				biolatency
			

				IO 延遲直方圖分布
			

				sudo biolatency-bpfcc -D 1
			

				低
		

				biosnoop
			

				逐條 IO 請求追蹤
			

				sudo biosnoop-bpfcc -d sda
			

				中
		

				ext4slower
			

				文件系統級慢操作追蹤
			

				sudo ext4slower-bpfcc 1
			

				低
		

	11.3 調優參數速查

				調優項
			

				參數/文件
			

				推薦值
			

				適用場景
		

				IO 調度器
			

				/sys/block/*/queue/scheduler
			

				NVMe:none，HDD:mq-deadline
			

				所有場景
		

				預讀大小
			

				blockdev --setra
			

				順序讀: 2048+，隨機讀: 64
			

				Kafka/HDFS vs 數據庫
		

				臟頁硬上限
			

				vm.dirty_ratio
			

				數據庫: 5，日志: 40
			

				寫入密集場景
		

				臟頁軟上限
			

				vm.dirty_background_ratio
			

				數據庫: 2，日志: 20
			

				寫入密集場景
		

				臟頁過期
			

				vm.dirty_expire_centisecs
			

				數據庫: 1000，日志: 6000
			

				寫入密集場景
		

				隊列深度
			

				/sys/block/*/queue/nr_requests
			

				高并發: 1024，默認: 256
			

				高 IOPS 場景
		

				IO 合并
			

				/sys/block/*/queue/nomerges
			

				隨機 IO: 2，順序 IO: 0
			

				純隨機 IO 場景
		

				文件系統
			

				mount options
			

				noatime 必開
			

				所有場景
		

	十二、總結

	12.1 技術要點回顧

	IO 棧認知層面：

	分層排查是基本功：一個 IO 請求從 VFS 到文件系統、Block Layer、設備驅動、物理設備，至少經過五層。排查 IO 問題的核心方法論就是逐層定位，而不是上來就調內核參數碰運氣。搞清楚瓶頸在軟件層（Q2D）還是硬件層（D2C），后續的調優方向完全不同

	%util的適用邊界必須搞清楚：這是生產環境中最高頻的認知誤區。HDD 是單通道設備，%util100% 確實意味著飽和；但 SSD 內部有大量并行通道，%util100% 可能只用了實際能力的 10%。NVMe 設備判斷是否飽和，看await和實際 IOPS 與標稱值的差距，%util直接忽略

	await是延遲排查的錨點：它包含隊列等待和設備服務兩部分時間。HDD 正常 5-15ms，SATA SSD 正常 0.05-0.5ms，NVMe 正常 0.01-0.1ms。超出正常范圍就要往下查，低于正常范圍說明磁盤還有余量

	svctm已廢棄，不要再用：sysstat 12.x 明確標記該字段不可靠，它是用%util反算出來的，在 blk-mq 多隊列架構下完全失真

	工具鏈層面：

	iostat → iotop → blktrace → bpftrace，四級遞進：iostat 回答"磁盤整體忙不忙"，iotop 回答"誰在讀寫"，blktrace 回答"IO 請求在各階段花了多少時間"，bpftrace 回答"延遲分布長什么樣、長尾在哪里"。每個工具解決一個層面的問題，不要指望一個工具搞定所有事

	fio 基準測試是調優的前提：不做基準就調參數等于盲調。先用 fio 的io_uring引擎跑出磁盤在 4K 隨機讀寫、128K 順序讀寫下的 IOPS 和吞吐上限，再拿業務實際負載的 iostat 數據去對比，才能判斷是磁盤能力不足還是應用 IO 模式有問題

	調優參數層面：

	IO 調度器選型直接影響性能：NVMe 用none（硬件自帶調度，軟件層不要畫蛇添足），HDD 用mq-deadline（保證讀延遲可控），多租戶共享 HDD 用bfq（按進程公平分配帶寬）。用 udev 規則持久化，不要每次重啟后手動設置

	臟頁參數是寫入延遲毛刺的主因：數據庫場景把dirty_ratio調到 5%、dirty_background_ratio調到 2%，可以顯著減少突發刷盤導致的延遲抖動。這是最常被忽略但效果最明顯的調優項

	readahead 要按場景區分：Kafka、HDFS 這類順序讀密集的場景調大到 1MB 以上；MySQL OLTP 這類純隨機讀場景調小到 32KB，避免預讀浪費帶寬

	cgroup v2 的 io 控制器是多租戶環境的剛需：io.max做硬限制、io.latency做延遲保障、io.weight做權重分配，三者配合使用可以在不升級硬件的前提下解決 IO 爭搶問題

	六、總結

	6.2 進階學習方向

	eBPF/bpftrace 存儲觀測體系：本文用到的 biolatency、biosnoop 只是 bcc-tools 的預置腳本，實際生產中經常需要自定義追蹤邏輯。bpftrace 支持掛載到block_rq_issue、block_rq_complete等 tracepoint 上，按進程、按設備、按 IO 大小做多維度延遲分布統計。更進一步，可以用 libbpf + CO-RE 編寫常駐的 IO 觀測 daemon，替代 blktrace 實現低開銷的長期追蹤。Brendan Gregg 的 bpftrace 工具集和 libbpf-bootstrap 項目是兩個值得深入研究的起點

	io_uring 異步 IO 框架：io_uring 通過用戶態和內核態共享的 SQ（提交隊列）/CQ（完成隊列）環形緩沖區，將系統調用開銷降到接近零。在高 IOPS 場景下比 libaio 高出 10%-30% 的性能。值得關注的高級特性包括：固定緩沖區（fixed buffers）避免每次 IO 的內存注冊開銷、鏈式提交（linked SQEs）實現原子性多步操作、多環共享（IORING_SETUP_ATTACH_WQ）減少內核線程數。PostgreSQL 16+、RocksDB、SPDK 已經原生集成 io_uring，理解其工作機制對評估和調優這些系統的 IO 性能有直接幫助

	NVMe 深度優化：NVMe 設備的性能調優遠不止選個none調度器。硬件多隊列到 CPU 核心的映射關系（通過/proc/interrupts和smp_affinity查看和調整）在 NUMA 架構下對延遲影響顯著——跨 NUMA 節點訪問 NVMe 隊列會增加 30%-50% 的延遲。此外，NVMe 的 namespace 管理、SR-IOV 虛擬化直通、CMB（Controller Memory Buffer）、ZNS（Zoned Namespace）等特性在大規模存儲集群中逐漸落地，nvme-cli工具集是管理和診斷 NVMe 設備的必備技能

	存儲棧全鏈路可觀測性建設：把 iostat/sar 的指標接入 Prometheus（通過 node_exporter 的 diskstats collector），用 Grafana 構建磁盤 IO 大盤，配合本文提到的告警規則（基于 await 而非 %util），形成從指標采集、異常告警到根因定位的完整閉環。對于 Kubernetes 環境，還需要關注 CSI 驅動層面的 IO 指標和 PV/PVC 級別的 IO 隔離

	12.3 參考資料

	Linux Block IO Layer- 內核官方塊層文檔，理解 blk-mq 架構的權威來源

	iostat(1) man page - sysstat- iostat 各字段的精確定義，排查時遇到指標含義不確定直接查這里

	BPF Performance Tools (Brendan Gregg)- eBPF 性能工具的系統性參考書，第九章專門講磁盤 IO 追蹤

	fio Documentation- fio 官方文檔，參數說明最全，做基準測試前必讀

	Linux Storage Stack Diagram- Linux 存儲棧可視化全景圖，每個內核版本都有對應的更新版本

	io_uring 內核文檔- io_uring 的內核側官方文檔，涵蓋 API 設計和使用約束

	liburing GitHub- io_uring 的用戶態封裝庫，Jens Axboe 維護，示例代碼是學習 io_uring 編程的最佳入口

	bcc/libbpf-tools- biolatency、biosnoop 等工具的 libbpf 版本源碼，比 Python 版性能更好

	NVMe CLI- NVMe 設備管理和診斷的命令行工具集，支持 SMART 信息查看、固件更新、namespace 管理

	Systems Performance, 2nd Edition (Brendan Gregg)- 系統性能分析的經典著作，磁盤 IO 章節覆蓋了從原理到工具的完整知識體系