Linux磁盘IO排查与性能优化实战

服务器慢，CPU和内存都正常，很可能是磁盘IO的问题。

但很多人排查到这一步就卡住了——知道是IO问题，不知道具体哪个进程、哪个文件、怎么优化。

这篇把磁盘IO排查的思路和工具整理一下。

先判断是不是IO问题

看load average

uptime# 10:30:01 up 30 days, 1:23, 2 users, load average: 15.32, 12.45, 8.67

load高但CPU使用率不高，大概率是IO等待。

看iowait

top

看%wa（IO Wait），如果这个值很高（比如超过20%），说明CPU在等IO。

%Cpu(s): 5.2 us, 2.1 sy, 0.0 ni, 72.3 id, 20.1 wa, 0.0 hi, 0.3 si, 0.0 st ^^^^ 这个

或者用vmstat：

vmstat1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 5 0 234567 123456 789012 0 0 450 2300 234 567 5 2 73 20 0 ^ ^^ 阻塞进程数 wa

b列是阻塞在IO上的进程数，wa是IO等待百分比。

找出是谁在搞IO

iotop

最直观的工具，类似top但看IO：

# 需要安装aptinstalliotop# Debian/Ubuntuyuminstalliotop# CentOS# 运行iotop

输出：

Total DISK READ: 15.23 M/s | Total DISK WRITE: 45.67 M/s Actual DISK READ: 15.23 M/s | Actual DISK WRITE: 32.10 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 12345 be/4 mysql 5.23 M/s 30.45 M/s 0.00 % 85.32 % mysqld 23456 be/4 root 8.00 M/s 0.00 B/s 0.00 % 45.12 % rsync

一眼就能看到是mysql和rsync在搞IO。

常用参数：

iotop -o# 只显示有IO的进程iotop -P# 只显示进程，不显示线程iotop -a# 累计IO，而不是瞬时iotop -p12345# 只看某个进程

iostat

看整体磁盘状态：

# 需要安装sysstatiostat -xz1

Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util sda 25.00 150.00 400.00 3000.00 0.00 50.00 0.00 25.00 0.50 15.00 2.25 16.00 20.00 5.71 100.00 ^^^^ 关键指标

关键指标：

• %util：磁盘繁忙程度，接近100%说明磁盘很忙
• r_await/w_await：读写平均等待时间（毫秒），越大说明越慢
• aqu-sz：平均队列长度，越大说明请求积压越多

如果%util很高但吞吐量（rkB/s、wkB/s）不大，说明磁盘性能有问题或者是随机IO太多。

pidstat

看某个进程的IO：

pidstat -d1

10:30:01 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command 10:30:02 1000 12345 500.00 3000.00 0.00 15 mysqld 10:30:02 0 23456 8000.00 0.00 0.00 5 rsync

指定进程：

pidstat -d -p123451

找出是哪个文件

知道进程了，想知道它在读写哪个文件。

lsof

# 看进程打开的文件lsof-p12345# 只看某个目录下的文件lsof+D /var/lib/mysql/# 看某个文件被谁打开lsof/var/log/syslog

用strace跟踪

# 跟踪进程的IO系统调用strace-p12345-etrace=read,write,open,close -f# 统计系统调用耗时strace-p12345-c

输出：

% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 85.23 2.345678 45 52000 write 10.12 0.278901 12 23000 read 3.45 0.094567 8 12000 fsync

能看到时间主要花在write和fsync上。

/proc文件系统

# 看进程的文件描述符ls-l /proc/12345/fd/# 看某个fd的读写位置cat/proc/12345/fdinfo/3

常见问题和优化

问题1：日志写太多

应用疯狂写日志是常见问题。

排查：

# 找出写入最多的文件lsof-p$(pgrep java)|grep-E"\.log$"

优化：

• 调高日志级别（DEBUG改成INFO）
• 异步写日志
• 日志文件放到单独的磁盘

问题2：频繁fsync

数据库为了数据安全会频繁fsync，但很吃性能。

strace-p$(pgrep mysqld)-e fsync -c

如果fsync调用很多，考虑：

• 调整MySQL的innodb_flush_log_at_trx_commit
• 用SSD
• 用带电容的RAID卡（可以安全地缓存写入）

问题3：随机IO太多

机械硬盘最怕随机IO。

判断方法：

• iostat看r/s和w/s很高，但吞吐量不大
• await很高

优化：

• 换SSD（最直接）
• 增加内存让更多数据缓存
• 优化应用减少随机访问

问题4：swap导致IO

内存不够用了，系统把数据换到磁盘。

vmstat1

看si和so列（swap in/out），如果不为0说明在用swap。

# 看哪个进程在用swapforpidin/proc/[0-9]*;doawk'/VmSwap/{print "'$pid'", $2}'$pid/status2>/dev/nulldone|sort-k2 -n|tail

解决：加内存，或者找出内存泄漏的进程。

问题5：RAID卡缓存

如果有RAID卡，检查缓存是否开启：

# 不同RAID卡命令不同# LSI/Broadcommegacli -LDInfo -Lall -aALL|grep"Cache"# HPhpssacli ctrl all show config

Write Back缓存能大幅提升写入性能，但需要电池/电容保护。

文件系统优化

选择合适的文件系统

• ext4：稳定，适合大多数场景
• xfs：大文件、高并发写入更好
• 不要用ext3：太老了

挂载参数

# 查看当前挂载参数mount|grepsda# 常用优化参数# /etc/fstab/dev/sda1 /data xfs defaults,noatime,nodiratime00

• noatime：不更新文件访问时间，减少写入
• nodiratime：不更新目录访问时间

I/O调度器

# 查看当前调度器cat/sys/block/sda/queue/scheduler# [mq-deadline] kyber bfq none# 临时修改echomq-deadline>/sys/block/sda/queue/scheduler# 永久修改：内核参数# GRUB_CMDLINE_LINUX="elevator=mq-deadline"

• SSD推荐：none或mq-deadline
• HDD推荐：mq-deadline

实用命令汇总

# 快速判断IO情况iostat -xz15# 找IO大户iotop -oP# 看某个进程的IOpidstat -d -p$(pgrep mysql)1# 看进程打开的文件lsof-p$(pgrep mysql)|head-50# 磁盘测试（慎用，会写数据）# 测试顺序写ddif=/dev/zeroof=testbs=1Mcount=1024oflag=direct# 测试顺序读ddif=testof=/dev/nullbs=1Miflag=direct# 更专业的测试用fiofio --name=randwrite --ioengine=libaio --direct=1--bs=4k --size=1G --numjobs=4--runtime=60--rw=randwrite

一个排查例子

前阵子有台服务器load飙到50多，CPU才20%。

排查过程：

# 1. 确认是IO问题vmstat1# wa 35%，b列一直有十几个# 2. 找出谁在搞IOiotop -oP# 发现是一个Java进程，写入30MB/s# 3. 看它在写什么文件lsof-p12345|grep-E"\.(log|dat|tmp)"# 发现在疯狂写一个app.log# 4. 看日志内容tail-f /var/log/app/app.log# 全是DEBUG级别的SQL日志# 5. 解决# 调高日志级别，DEBUG改成INFO

问题解决，load降到2以内。

IO问题排查套路就这些：

1. 先确认是IO问题（iowait、vmstat）
2. 找出是谁（iotop、pidstat）
3. 找出是什么文件（lsof、strace）
4. 针对性优化

工具不用都记住，知道有这些东西，用的时候来查就行。