有个场景你一定不陌生：服务器CPU占用不高、内存也够，可系统就是卡得要命，打开个网页都费劲，数据库查询慢得让人怀疑人生。这种时候，十有八九是磁盘IO在拖后腿——尤其用机械硬盘的老服务器，或者读写频繁的数据库机器，磁盘常常是第一个扛不住的。今天就把排查磁盘IO的两个趁手工具教给你：iostat看整体状况，iotop揪出具体进程。
先把工具装上，一条命令一个
iostat在sysstat包里，iotop是独立软件包。CentOS上yum install -y sysstat iotop，Debian系apt install -y sysstat iotop，装完就能用。都是免费的老牌工具，不用担心版权问题。
iostat怎么看，重点盯两个数
iostat -x 1 3的意思是每秒采样一次，连续采样三次。输出里重点看两个指标：%util和await。%util是磁盘处理IO请求的时间占比，接近100%说明磁盘基本满负荷了；await是每次IO的平均等待时间，机械盘如果await长期几十毫秒以上，那明显是慢了，SSD一般应该在个位数毫秒。两个数一起看：%util高+await高，磁盘真瓶颈了；%util不高但await高，可能是偶发的慢IO或者队列问题。
还要顺带看看r/s、w/s（每秒读写次数）和rkB/s、wkB/s（吞吐量）。有个细节值得记住：大量小文件随机读写的时候，r/s会很高但吞吐不高，这种最伤机械盘，因为磁头一直在寻道，跑都跑不过来。
iotop：把具体进程揪出来
iostat确认磁盘忙了，下一步就是问：谁在忙？iotop就是干这个的，它跟top长得像，按IO占用排序，实时显示每个进程的读写速度。iotop -o只显示有IO活动的进程，界面干净不闹心；想批量记录就加-b参数，输出几次后自动退出，方便抓数据留证据。看到某个进程读写特别猛，结合业务判断一下：mysqld大量读写可能是业务高峰，备份脚本狂读可能是定时任务在跑，要是冒出个陌生进程大量读写，那就要警惕是不是木马或者挖矿程序了。
揪出来之后，往这几个方向想
磁盘IO高，最常见的几种根子：数据库没索引，查询全表扫描，随机读一堆一堆地来，这个查慢查询日志就能发现，给字段加上索引立竿见影；备份、数据同步这类大任务跟业务抢IO，把它们挪到低峰期跑，或者限个速；swap频繁换入换出，说明内存不够用，系统拿磁盘当内存使，这种加内存才是治本；日志写入太频繁，应用日志、数据库日志级别调太高，适当降级或者改异步。这几个方向排查完，大部分IO问题都能定位。
云服务器的IO，得先分清是谁的锅
云服务器排查IO要多个心眼：你看到的IO性能，受实例规格和云盘类型限制，入门实例的突发IO、共享型云盘在高峰期可能被限流，这是平台层面的，不是你系统里能调的。遇到持续IO打满，先上云控制台看看云盘的监控，如果确实跑到了购买规格的上限，那就不是优化能解决的了，得升级云盘类型或者实例规格。别在系统里白折腾半天，最后发现是盘本身就到顶了。
看IO时顺便看看别的，别一条道走到黑
排查IO也别光盯着磁盘，顺手看看负载、CPU和内存的联动。有时候磁盘IO高只是表象，背后的根子是内存不够在疯狂用swap，或者程序写得烂在反复读写同一个文件。多开几个窗口，top、vmstat、iostat、iotop一起看，互相印证，比单看一个工具更容易找到真相。我见过太多人抱着一个工具不撒手，结果方向都错了还觉得自己查得挺认真。
平时怎么防，别等卡了才查
磁盘IO跟别的指标一样，预防比救火重要。把IO使用率、await这些接进监控，设置告警阈值，磁盘快到瓶颈的时候提前知道。做容量规划的时候，用fio这类工具在低峰期给磁盘跑个基准测试，摸清它到底能扛多大压力，心里有数了，该升级就提前升级，别等到业务高峰期突然崩了才手忙脚乱。反正记住这套思路：iostat确认、iotop定位、结合业务判断、该优化优化该升级升级，磁盘IO就不再是玄学问题了。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
