老板扔来一句“服务器卡死了赶紧看看”你登上机器一瞧CPU 是空闲的内存也够用load average 却飙到了几十整个系统慢得像幻灯片。这时候你要是跟老板说“磁盘I/O的问题”他没概念但你要是接着一句“实在查不出来”这锅可就稳稳扣你头上了。别急这篇文章就是教你怎么在服务器卡顿但 CPU 寸功未立的时候把磁盘I/O这个“隐形杀手”揪出来并且彻底解决它。我做了多年运维踩过的坑都写在这里从原理到命令从排查到根治一次性讲清楚。作为运维工程师我太熟悉这个场景了业务线上报故障第一反应永远是 CPU 飙高或者内存吃紧拆开监控面板一看CPU 30%内存剩 60%看着健康得不行。可业务就是卡SSH 敲个命令都要等两秒。这种“看似健康实则垂死”的状态十有八九是磁盘I/O在背后捣鬼。这篇文章适合所有接触过服务器的人无论是刚入门的小白还是多年老兵都能从这里拿到一套能直接用的排查方法论和根治方案。1. 先别急着甩锅卡顿排查的正确顺序1.1 为什么“CPU空闲”和“系统卡顿”能同时发生很多人刚入行时有个思维定式CPU 闲着 系统没在忙。这个定式在大部分场景下没错但它漏掉了最要命的一环——等待。计算机运行是 CPU 在干活可活干完了总得把结果写出去、把数据读进来吧这个过程就是I/O。当 CPU 向磁盘发起一次读写请求而磁盘迟迟没响应时CPU 只能干等着它不消耗计算资源执行线程被阻塞于是我们看到的就是“CPU 空闲”。同时那些被阻塞的任务还在排队系统负载load average会持续走高新来的任务挤不进来整个系统就像高峰期的地铁入口——明明站台上没几个人在走路但你就是进不去。这个现象在 Linux 里有专门的指标叫 iowait意思是 CPU 等待I/O完成的时间占比。如果 top 命令里 %wa 这一栏超过了 20%基本可以断定磁盘就是当前最紧的瓶颈。我见过不少同事一上来直接重启服务、删缓存结果治标不治本。其实只要理解了“CPU 等待I/O”的原理你就知道为什么重启永远无法解决这类问题——磁盘的物理能力就摆在那你不改变 I/O 的规模和分布加多少重启都没用。1.2 常规监控面板为什么不告诉你真相现在市面上主流的监控系统默认展示的都是 CPU 使用率、内存使用量、网络带宽这些“显性指标”。磁盘监控模块往往被放进“其他”分类里即便有展示也只是磁盘空间用量而不是磁盘 I/O 的时延和吞吐。这种信息不对称的监控配置是很多误判的源头。我之前帮忙排查过一个项目监控面板一切正常但业务方的反馈是“每天下午三点准时卡成 PPT持续半小时”。后来查出来下午三点正好是定时任务跑批的时间一个批量脚本在短时间内对数据库发起大量扫表操作I/O 吞吐瞬间打满。监控里没有磁盘吞吐的告警项这事要是没深入查恐怕能被当作“灵异事件”记入项目史册。所以排查之前我强烈建议你先搞清楚自己的监控系统到底采集了哪些指标。如果只有 CPU 和内存接下来的排查你就得靠命令行工具自己补课千万别拿监控面板的“一切正常”当结论。1.3 排查前必做的数据采集清单每次遇到性能问题我会在动手前先做一轮“快照采集”把系统当时的静态信息和动态信息都留下来。因为服务器卡顿往往是间歇性的等你看完面板再敲命令场景可能已经变了。建议按下面的顺序来记录uptime的输出看负载均值 1/5/15 分钟的趋势。记录free -h的输出确认物理内存和交换分区swap的使用情况。记录dmesg -T | tail -50的输出看有没有硬件报错、文件系统异常或者内核警告。记录top -bn1的输出重点看 %Cpu(s) 里的 wa 字段以及进程列表里有没有 D 状态不可中断睡眠的进程。这四组命令耗时不过十几秒但它们构成了一套完整的“案发现场记录”。排查卡顿问题时最忌讳的就是凭感觉东看一眼西敲一下最后什么证据都没留下。这套快照不仅帮你自己分析后面如果要把问题甩给开发或者硬件厂商也是最有说服力的依据。2. 五分钟定位从怀疑I/O到实锤2.1 用 iostat 一眼看穿磁盘状态确认 I/O 有问题最直接的工具是iostat它来自sysstat包很多系统默认没装。Debian/Ubuntu 别急着用 yum 或 apt 直接装先在测试环境试好CentOS 上通常一条yum install sysstat -y就搞定。装完以后直接执行iostat -x 1 5参数的含义是这样的-x表示显示扩展统计信息1是采样间隔设为 1 秒5是总共采样 5 次。输出的核心字段有这些需要看懂r/s和w/s每秒读/写请求次数对应着磁盘的 IOPS。rkB/s和wkB/s每秒读/写的数据量对应着吞吐带宽。avgqu-sz平均请求队列长度如果这个值长期大于 2说明请求堆得满满的磁盘处理不过来了。await请求的平均处理时间毫秒包含排队时间和实际处理时间。机械硬盘正常情况下在 10 到 30 毫秒SSD 通常低于 1 毫秒。如果看到几百毫秒的数据磁盘要么在退化要么已经过载。%util设备忙闲百分比。很多人把这个当磁盘“使用率”看其实它有很严重的误导性——当多个磁盘组成 RAID 或者有 I/O 调度器合并请求时即便 %util 到 100%磁盘物理层未必真的全速运转。我用 iostat 的最大心得是不要单独看某一个指标要把avgqu-sz、await、%util三个字段联合起来看队列长、时延高、利用率满三合一才是真正的 I/O 瓶颈。只看到%util高就下结论很容易误伤好人。2.2 用 pidstat 和 iotop 锁死元凶进程iostat 告诉你磁盘有问题但没有告诉你谁在制造问题。这时候要上pidstat同样是 sysstat 包自带的工具执行pidstat -d 1 5输出里会列出各个进程每秒钟的读写数据量很好用。但 pidstat 有一个致命盲区——它只能看到进程主动发起的读写无法快速呈现那些生命周期极短的进程。比如一个脚本频繁启动、疯狂写日志然后退出pidstat 可能只看到一个模糊的影子。所以我会推荐同时用iotop来兜底iotop -oP-o表示只看有I/O操作的进程-P表示只看进程不看线程。这个命令的好处是刷新频率高、趋势直观。它需要 root 权限很多生产环境出于安全考虑没给运维账户开 sudo这时候你可以请值班管理员配合操作或者用下面这种方式绕过——查看进程的I/O字节数cat /proc/PID/io读rchar和wchar字段前后隔几秒对比就能算出大致的读写速率。这个方法不需要任何额外权限只要有进程 ID 就能用是应急场景下最轻量的定位手段。2.3 顺着进程往下挖文件描述符与系统调用确定了“哪个进程在读写”下一个问题就是“它在读写什么文件”。Linux 下一切皆文件进程的所有 I/O 行为都体现在文件描述符里。执行ls -l /proc/PID/fd你会看到一堆符号链接链接指向的就是进程打开的文件。如果发现某个日志文件的描述符反复被访问或者在往某个临时文件里狂写元凶基本就露头了。再配套使用strace直接跟踪进程的系统调用strace -cp -p PID-c统计模式-p指定进程 ID跑个十几秒后按 CtrlC 退出它会告诉你这段时间该进程最频繁调用的是哪些系统调用。如果write系统调用占据了绝大部分次数和耗时那就是在反复写数据。我曾经用这套组合拳在一个负载几十的服务器上抓到一个不断写错误日志的进程文件路径是个隐藏目录开发的代码又刚好没有做日志级别控制一个循环异常就把磁盘写穿了。2.4 现场走查完整定位动作演示我把上面所有步骤串成一个完整演示你照做就行。假设你接到一台卡顿服务器先跑top看到%Cpu(s): wa85.5好I/O 一定是瓶颈记下load average数值继续跑iostat -x 1 3发现sda设备的%util是 99%await是 320msavgqu-sz是 8.9铁证如山。再跑iotop -oP一眼扫到某 Java 进程的IO列异常高比如K 500MB/s记下它的 PID。接着看这个进程在写什么ls -l /proc/PID/fd | grep deleted你会发现它打开了一个已经被删除的日志文件——这更糟文件删了但句柄没释放磁盘空间不会回收I/O 还在持续产生。然后你面向开发说“你看这个进程在疯狂写日志”开发打开代码一看某个循环里只要捕获到异常就打印堆栈日志级别还设在 DEBUG好了全部串起来。整套流程不超过五分钟但每一步都有据可查没有一步是猜测。3. 揪出背后的真正“元凶”几种常见I/O诱因3.1 循环写日志代码层面的隐性问题I/O 故障的根源里日志问题常年高居榜首。我们排查过的案例里十次有七次最后都能追溯到某段代码在频繁打印日志。常见的设计缺陷有三种。第一种是日志级别设置过高比如把生产环境的日志级别调成 DEBUG数据库连接池每秒心跳都输出一行一天下来光日志就写了几个 GB。第二种是异常处理不当在 catch 块里直接printStackTrace()如果这个异常发生在高频循环中等于每循环一次就往磁盘写一堆堆栈信息。第三种是日志文件轮转策略缺失写单个文件写到系统文件大小上限进程卡住后才开始刷盘。针对日志问题我的经验是生产环境日志级别务必设置成 WARN 或 ERROR 以上使用带异步写入能力的日志框架务必配置 logrotate 或应用自带的轮转功能按大小和按天都要设保留最近五到十份即可。3.2 内存吃紧引发的 swap 风暴内存不足时系统会把一些进程的数据换到磁盘的交换分区上。如果内存持续紧张系统会频繁地在物理内存和交换分区之间搬运数据这个行为本身就产生大量的 I/O。更要命的是这种 swap 风暴通常出现在业务高峰期和正常的业务 I/O 叠加直接把磁盘打到晕头转向。判断方法不复杂执行free -h如果 swap 的 used 数值长时间不小同时top里si和so两列数值很高那就是 swap 风暴。这里有个关键认知swap 本身不是洪水猛兽它是一种保护机制真正的问题是“频繁交换”。系统在内存不足时会把最近很少访问的内存页先换出去但如果业务访问模式很差刚换出去的页面马上又要读回来就形成了“换入换出”的抖动循环。避免 swap 风暴的根本手段是加内存或者调降应用的缓存配置而不是简单粗暴地关掉 swap。关掉 swap 只会让内存耗尽时直接触发 OOM 杀进程业务一样受损。日常维护中建议把vm.swappiness从默认的 60 调低到 10 左右让系统优先使用物理内存减少不必要的交换行为。3.3 数据库全表扫描与临时排序网站的慢背后常常是数据库的 I/O 风暴。数据库的读写是最典型的 I/O 密集型操作尤其当某条 SQL 没走索引、全表扫描一张几千万行的表时磁盘读盘量是天文数字。我遇到过最夸张的一次是一条模糊查询把单表一亿行的数据全部读了进来单次查询持续时间长达二十分钟期间磁盘读吞吐被占满其他所有业务全部瘫痪。即使走了索引排序和分组操作也可能把临时结果写到磁盘上。MySQL 在内存不够执行 ORDER BY 或者 GROUP BY 时会创建临时表落到磁盘的临时目录里这个过程同样是 I/O。所以排查数据库型卡顿的时候除了看系统层面的 I/O 指标还要到数据库内部去看开启慢查询日志定位具体的慢 SQL。用EXPLAIN看执行计划检查有没有全表扫描、临时表、文件排序。检查数据库缓冲池大小调大缓冲池能显著减少物理读。数据库导致的 I/O 问题表象是磁盘利用率高根子是 SQL 写得差。这时候运维能做的是给开发提供证据链而不是自己闷头优化系统参数。3.4 文件系统层面与硬件自身的坑最后一种常见诱因藏在文件系统和硬件层。文件系统层面比如在超大目录上执行find全盘搜索或者做增量备份时遍历了海量小文件这些操作会将目录项和元数据疯狂读入内存虽然底层数据量不大但请求数极多IOPS 被打满原本很快的操作变成龟速。硬件层面则五花八门机械硬盘出现了坏道导致反复重读、SSD 的垃圾回收机制导致写放大、硬件 RAID 卡电池耗尽触发写缓存失效、虚拟机磁盘在宿主机上共享一块物理盘被邻居挤压等等。这些问题的特点是你察系统一切正常但就是 I/O 很慢。排查策略是做硬件健康检查——看smartctl的输出看dmesg有没有 I/O error再看看宿主机层面有没有其他虚拟机在下黑手。4. 彻底根除五套 I/O 优化与加固方案4.1 日志降噪与轮转策略落地日志类的 I/O 问题找到了根因之后整改动作其实很标准化。首先是开发侧调整日志级别把不必要的信息拒之门外其次是应用侧引入异步日志把日志写入交由后台线程批量处理降低对业务线程的阻塞最后是系统侧强化 logrotate 的配置。这里给一份常见的 logrotate 配置参考/path/to/your/app/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }daily按天轮转rotate 7保留 7 份compress对旧日志进行压缩copytruncate适合那些无法通过重启应用来释放文件句柄的场景。配置完以后记得跑一次logrotate -d /etc/logrotate.conf做试运行确认配置文件语法没有问题。4.2 数据库和缓存层的 I/O 减负数据库是 I/O 大户优化它的 I/O 通常从三个方向进行。第一是调大数据库的缓存池或缓冲池。以 MySQL 为例InnoDB buffer pool 默认只有 128MB在内存允许的情况下调到总内存的 60% 到 70%就能大幅减少磁盘物理读。第二是优化 SQL消灭全表扫描给高频查询字段加索引避免大表的文件排序。第三是把重复的查询结果缓存起来引入 Redis 或者 Memcached把热点数据的读取压力从磁盘转移到内存。需要强调的是任何一次数据库参数调整都要经过充分的评估和灰度验证不要直接在核心库上拍脑袋改。你改了缓冲池大小如果触发内存分配的连锁反应可能导致操作系统交换。4.3 存储设备升级与系统参数调优软件层面能调的都调完之后如果 I/O 压力依然很大剩下的路就是硬件升级。从机械硬盘换到 SSD是性价比最高的一次变革。SSD 的随机读写能力是机械盘的几十倍对于高并发随机的读写场景简直是降维打击。升级之后磁盘的 I/O 瓶颈窗口会被大大拉高短时间内不用担心同类问题再犯。在系统层面我们可以调整块设备的 I/O 调度器。现代的 SSD 设备一般用none或mq-deadline调度器不需要传统的 CFQ 那种复杂的电梯算法。查看当前调度器的方法cat /sys/block/sda/queue/scheduler临时切换echo mq-deadline /sys/block/sda/queue/scheduler永久生效要写进 udev 规则或内核启动参数不同发行版细节不一样建议在测试环境先验证。4.4 内存与文件缓存参数调优很多 I/O 问题本质上是内存问题因为文件缓存Page Cache的存在本来可以避免大量的磁盘读。如果系统频繁地把文件缓存里的页面清理掉反倒造成反复的磁盘读那就是策略失当。内核里有几个关键参数值得关注。vm.dirty_ratio表示一个进程脏页占总内存比例的上限超过这个值进程自身会被强制同步刷盘。vm.dirty_background_ratio表示整个系统脏页达到某个比例时后台内核线程开始异步刷盘。为了让写入波峰更平滑通常建议保持默认或者适当调高dirty_background_ratio让脏页在后台就慢慢消化不要让一次性攒太多触发同步阻塞。还有一个参数是前文提到过的vm.swappiness改小它我就不再重复了。所有这些参数都可以用sysctl -w临时验证效果确认稳定后再固化到/etc/sysctl.conf。4.5 限流与隔离保护“邻居”也是保护自己如果整个服务器上跑了很多业务某一个业务的 I/O 风暴很容易殃及池鱼。成熟的云平台和容器体系早就提供了 I/O 隔离的机制。比如 systemd 管理的服务可以设置IOWeight和IOReadBandwidthMax来限制某服务的 I/O 权重和带宽上限。Docker 容器则可以使用--device-read-bps和--device-write-bps参数做同样的限制。一般我还会建议对定时任务做物理资源隔离把重 I/O 的批处理任务错峰执行。比如日报生成放在深夜、数据备份放在凌晨与业务高峰错开。这一招不需要任何技术深度但效果立竿见影。5. 实战复盘一次线上“卡死”的完整排障记录5.1 告警触发与第一反应这个案例发生在给某客户维护的一套系统上。上午十点多监控警报突然拉响业务接口平均响应时间从 50ms 飙升到 5 秒以上还伴随大量超时错误。客户群里已经开始有人催问“到底怎么回事”。我第一时间登上跳板机准备连服务器结果明显感觉到 SSH 登录都比平时慢半拍——凭经验这已经不是简单的高并发问题了。我没有直接重启应用而是按照快照采集的流程先敲了uptime和top。top的输出瞬间让所有人都安静了CPU 占用率 10% 都不到但load average已经达到 45wa数值高达 90%以上。我心里马上有数了这就是典型的 I/O 瓶颈。5.2 逐层定位的逻辑链第二步执行iostat -x 1 5结果把问题锁死在某块数据盘上%util一直满负荷运转await超过了 1000 毫秒。我看了一眼时间——这个盘上挂着的正是数据库的实例。第三步用iotop -oP追踪进程看到一连串 mysqld 的读操作吞吐量居高不下。这就引出了一个新问题数据库在读什么于是登录数据库开启慢查询日志几分钟后抓到一条 SQL一条针对核心订单表数据量已经过亿的模糊查询执行计划里清楚地写着type: ALL全表扫描。源头终于找到了某后台运营同事在做导出操作时写了一条没带索引的模糊查询数据库只能把整张表读一遍。这种查询在中午高峰时段执行直接把底层磁盘的读带宽打爆连带着所有其他正常业务都被拖下水。5.3 最终修复动作与效果对比当时的处理分三步同时进行。第一后台把这条慢查询先杀了让数据库恢复呼吸。第二给这个新增的查询字段补上联合索引保证后续同类查询能走索引。第三在数据库连接池和应用层加了一层限流类似的重查询只能排队执行不允许并发进场。从找到元凶到执行完动作大概十五分钟数据库的await降回 1ms 以内接口响应恢复到几十毫秒。整个过程没有重启任何服务业务中断时长被压缩到最小。复盘时我们补上了监控短板给%util、await、top的wa字段都设置了告警阈值同时规定所有后台运营发起的临时查询必须经过统一的查询平台禁止直接连库执行。5.4 复盘总结排障时最怕什么这次排障能快速收场一个重要原因是全程没有“猜到哪算哪”每一步都基于数据做决策。排障最怕的是三件事一是盲目重启把现场都毁掉二是只看症状不分层比如看到数据库慢就去优化数据库忽略了系统层面 I/O 已经被打满的事实三是不留记录复盘全靠记忆后续改进无从下手。我后来总是跟团队强调排障的过程要像刑侦一样保留证据链。每个阶段收集到的数据都要留存这样不仅有利于当前问题的解决还能沉淀成团队的故障知识库下次别人遇到类似问题可以少走弯路。6. 日常防线让“隐形杀手”现身于一场虚惊之前6.1 监控指标与告警阈值设计与其等到卡顿发生再排查不如在日常监控里把 I/O 指标纳入重点。单台服务器的 I/O 不仅仅是iostat上的那几行数字还有块设备层的监控。建议在你的监控系统里至少添加以下指标设备%util超过 80% 持续五分钟告警。设备await超过 100ms 持续五分钟告警。系统iowait占 CPU 的比例超过 20% 持续五分钟告警。进程级 I/O 读写速率超过预设阈值告警。这里说一个我踩过的坑直接对%util设置一条固定阈值并不科学因为不同的设备和业务模型适合的%util上限完全不同。比如 SSD 正常能承受 90% 的 util但机械盘可能到 70% 整个系统就开始卡了。更稳健的做法是设置“相对性告警”即比过去七天的同期均值高出三倍以上才触发告警这样既灵敏又不会误报满天飞。6.2 日常巡检命令速查表下面是给我自己的、也是给你们的一份高频巡检命令速查表。建议每周至少跑一次特别是业务高峰期前后# 系统整体状态 uptime top -bn1 | head -20 free -h # 磁盘I/O详情 iostat -x 1 5 # 进程I/O排行 pidstat -d 1 5 # 挂载点与磁盘空间 df -hT巡检不是刷指标而是观察趋势。每一次记录的数据如果不在同一张图表上连续看就发现不了“每周三下午堵一次”这种规律。我通常会把这些命令的输出重定向到文件里保存然后用脚本做简单统计一旦发现规律性异常提前介入往往成本最低。6.3 常见问题速查与应急指引最后整理一份常见问题速查表方便你在被老板盯着的时候快速翻答案症状特征优先排查项应急动作CPU 空闲、load 很高iostat -x看 await 和 %util用 iotop 找高 I/O 进程暂停或限制它swap 使用持续增长free -h确认检查内存大户考虑重启业务或加内存数据库响应突然变慢慢查询日志杀会话、补索引、调缓存日志文件异常增长du -sh *找大文件关日志级别清理并配置轮转定时任务时段卡顿对照 crontab 和 I/O 趋势错峰执行限速批量任务文件系统操作极慢dmesg找 I/O error检查硬件健康联系厂商这张表对于 80% 的“卡顿”场景够用了。剩下 20% 的疑难杂症大概率藏在硬件故障、内核 bug、虚拟化平台干扰这些深水区那就要靠前面那些底层工具一点一点排查了。归根结底服务器卡顿这件事最让人头疼的不是问题本身而是“看起来一切正常”的假象。我自己踩过几次类似的坑之后现在遇到任何卡顿第一反应永远是先看一眼iowait再看一眼 D 状态进程最后才去碰 CPU 和内存。这套思维方式帮我在无数次“CPU 空闲但服务器卡死”的困境中全身而退。希望这篇文章也能成为你工具箱里的一把趁手家伙下次再遇到这个“隐形杀手”心里有数手里不慌。 
长河君 · 2026/10/17 7:47:20 · 阅读 1.2k CPU空闲但服务器卡顿？磁盘I/O瓶颈排查与优化实战
老板扔来一句“服务器卡死了赶紧看看”你登上机器一瞧CPU 是空闲的内存也够用load average 却飙到了几十整个系统慢得像幻灯片。这时候你要是跟老板说“磁盘I/O的问题”他没概念但你要是接着一句“实在查不出来”这锅可就稳稳扣你头上了。别急这篇文章就是教你怎么在服务器卡顿但 CPU 寸功未立的时候把磁盘I/O这个“隐形杀手”揪出来并且彻底解决它。我做了多年运维踩过的坑都写在这里从原理到命令从排查到根治一次性讲清楚。作为运维工程师我太熟悉这个场景了业务线上报故障第一反应永远是 CPU 飙高或者内存吃紧拆开监控面板一看CPU 30%内存剩 60%看着健康得不行。可业务就是卡SSH 敲个命令都要等两秒。这种“看似健康实则垂死”的状态十有八九是磁盘I/O在背后捣鬼。这篇文章适合所有接触过服务器的人无论是刚入门的小白还是多年老兵都能从这里拿到一套能直接用的排查方法论和根治方案。1. 先别急着甩锅卡顿排查的正确顺序1.1 为什么“CPU空闲”和“系统卡顿”能同时发生很多人刚入行时有个思维定式CPU 闲着 系统没在忙。这个定式在大部分场景下没错但它漏掉了最要命的一环——等待。计算机运行是 CPU 在干活可活干完了总得把结果写出去、把数据读进来吧这个过程就是I/O。当 CPU 向磁盘发起一次读写请求而磁盘迟迟没响应时CPU 只能干等着它不消耗计算资源执行线程被阻塞于是我们看到的就是“CPU 空闲”。同时那些被阻塞的任务还在排队系统负载load average会持续走高新来的任务挤不进来整个系统就像高峰期的地铁入口——明明站台上没几个人在走路但你就是进不去。这个现象在 Linux 里有专门的指标叫 iowait意思是 CPU 等待I/O完成的时间占比。如果 top 命令里 %wa 这一栏超过了 20%基本可以断定磁盘就是当前最紧的瓶颈。我见过不少同事一上来直接重启服务、删缓存结果治标不治本。其实只要理解了“CPU 等待I/O”的原理你就知道为什么重启永远无法解决这类问题——磁盘的物理能力就摆在那你不改变 I/O 的规模和分布加多少重启都没用。1.2 常规监控面板为什么不告诉你真相现在市面上主流的监控系统默认展示的都是 CPU 使用率、内存使用量、网络带宽这些“显性指标”。磁盘监控模块往往被放进“其他”分类里即便有展示也只是磁盘空间用量而不是磁盘 I/O 的时延和吞吐。这种信息不对称的监控配置是很多误判的源头。我之前帮忙排查过一个项目监控面板一切正常但业务方的反馈是“每天下午三点准时卡成 PPT持续半小时”。后来查出来下午三点正好是定时任务跑批的时间一个批量脚本在短时间内对数据库发起大量扫表操作I/O 吞吐瞬间打满。监控里没有磁盘吞吐的告警项这事要是没深入查恐怕能被当作“灵异事件”记入项目史册。所以排查之前我强烈建议你先搞清楚自己的监控系统到底采集了哪些指标。如果只有 CPU 和内存接下来的排查你就得靠命令行工具自己补课千万别拿监控面板的“一切正常”当结论。1.3 排查前必做的数据采集清单每次遇到性能问题我会在动手前先做一轮“快照采集”把系统当时的静态信息和动态信息都留下来。因为服务器卡顿往往是间歇性的等你看完面板再敲命令场景可能已经变了。建议按下面的顺序来记录uptime的输出看负载均值 1/5/15 分钟的趋势。记录free -h的输出确认物理内存和交换分区swap的使用情况。记录dmesg -T | tail -50的输出看有没有硬件报错、文件系统异常或者内核警告。记录top -bn1的输出重点看 %Cpu(s) 里的 wa 字段以及进程列表里有没有 D 状态不可中断睡眠的进程。这四组命令耗时不过十几秒但它们构成了一套完整的“案发现场记录”。排查卡顿问题时最忌讳的就是凭感觉东看一眼西敲一下最后什么证据都没留下。这套快照不仅帮你自己分析后面如果要把问题甩给开发或者硬件厂商也是最有说服力的依据。2. 五分钟定位从怀疑I/O到实锤2.1 用 iostat 一眼看穿磁盘状态确认 I/O 有问题最直接的工具是iostat它来自sysstat包很多系统默认没装。Debian/Ubuntu 别急着用 yum 或 apt 直接装先在测试环境试好CentOS 上通常一条yum install sysstat -y就搞定。装完以后直接执行iostat -x 1 5参数的含义是这样的-x表示显示扩展统计信息1是采样间隔设为 1 秒5是总共采样 5 次。输出的核心字段有这些需要看懂r/s和w/s每秒读/写请求次数对应着磁盘的 IOPS。rkB/s和wkB/s每秒读/写的数据量对应着吞吐带宽。avgqu-sz平均请求队列长度如果这个值长期大于 2说明请求堆得满满的磁盘处理不过来了。await请求的平均处理时间毫秒包含排队时间和实际处理时间。机械硬盘正常情况下在 10 到 30 毫秒SSD 通常低于 1 毫秒。如果看到几百毫秒的数据磁盘要么在退化要么已经过载。%util设备忙闲百分比。很多人把这个当磁盘“使用率”看其实它有很严重的误导性——当多个磁盘组成 RAID 或者有 I/O 调度器合并请求时即便 %util 到 100%磁盘物理层未必真的全速运转。我用 iostat 的最大心得是不要单独看某一个指标要把avgqu-sz、await、%util三个字段联合起来看队列长、时延高、利用率满三合一才是真正的 I/O 瓶颈。只看到%util高就下结论很容易误伤好人。2.2 用 pidstat 和 iotop 锁死元凶进程iostat 告诉你磁盘有问题但没有告诉你谁在制造问题。这时候要上pidstat同样是 sysstat 包自带的工具执行pidstat -d 1 5输出里会列出各个进程每秒钟的读写数据量很好用。但 pidstat 有一个致命盲区——它只能看到进程主动发起的读写无法快速呈现那些生命周期极短的进程。比如一个脚本频繁启动、疯狂写日志然后退出pidstat 可能只看到一个模糊的影子。所以我会推荐同时用iotop来兜底iotop -oP-o表示只看有I/O操作的进程-P表示只看进程不看线程。这个命令的好处是刷新频率高、趋势直观。它需要 root 权限很多生产环境出于安全考虑没给运维账户开 sudo这时候你可以请值班管理员配合操作或者用下面这种方式绕过——查看进程的I/O字节数cat /proc/PID/io读rchar和wchar字段前后隔几秒对比就能算出大致的读写速率。这个方法不需要任何额外权限只要有进程 ID 就能用是应急场景下最轻量的定位手段。2.3 顺着进程往下挖文件描述符与系统调用确定了“哪个进程在读写”下一个问题就是“它在读写什么文件”。Linux 下一切皆文件进程的所有 I/O 行为都体现在文件描述符里。执行ls -l /proc/PID/fd你会看到一堆符号链接链接指向的就是进程打开的文件。如果发现某个日志文件的描述符反复被访问或者在往某个临时文件里狂写元凶基本就露头了。再配套使用strace直接跟踪进程的系统调用strace -cp -p PID-c统计模式-p指定进程 ID跑个十几秒后按 CtrlC 退出它会告诉你这段时间该进程最频繁调用的是哪些系统调用。如果write系统调用占据了绝大部分次数和耗时那就是在反复写数据。我曾经用这套组合拳在一个负载几十的服务器上抓到一个不断写错误日志的进程文件路径是个隐藏目录开发的代码又刚好没有做日志级别控制一个循环异常就把磁盘写穿了。2.4 现场走查完整定位动作演示我把上面所有步骤串成一个完整演示你照做就行。假设你接到一台卡顿服务器先跑top看到%Cpu(s): wa85.5好I/O 一定是瓶颈记下load average数值继续跑iostat -x 1 3发现sda设备的%util是 99%await是 320msavgqu-sz是 8.9铁证如山。再跑iotop -oP一眼扫到某 Java 进程的IO列异常高比如K 500MB/s记下它的 PID。接着看这个进程在写什么ls -l /proc/PID/fd | grep deleted你会发现它打开了一个已经被删除的日志文件——这更糟文件删了但句柄没释放磁盘空间不会回收I/O 还在持续产生。然后你面向开发说“你看这个进程在疯狂写日志”开发打开代码一看某个循环里只要捕获到异常就打印堆栈日志级别还设在 DEBUG好了全部串起来。整套流程不超过五分钟但每一步都有据可查没有一步是猜测。3. 揪出背后的真正“元凶”几种常见I/O诱因3.1 循环写日志代码层面的隐性问题I/O 故障的根源里日志问题常年高居榜首。我们排查过的案例里十次有七次最后都能追溯到某段代码在频繁打印日志。常见的设计缺陷有三种。第一种是日志级别设置过高比如把生产环境的日志级别调成 DEBUG数据库连接池每秒心跳都输出一行一天下来光日志就写了几个 GB。第二种是异常处理不当在 catch 块里直接printStackTrace()如果这个异常发生在高频循环中等于每循环一次就往磁盘写一堆堆栈信息。第三种是日志文件轮转策略缺失写单个文件写到系统文件大小上限进程卡住后才开始刷盘。针对日志问题我的经验是生产环境日志级别务必设置成 WARN 或 ERROR 以上使用带异步写入能力的日志框架务必配置 logrotate 或应用自带的轮转功能按大小和按天都要设保留最近五到十份即可。3.2 内存吃紧引发的 swap 风暴内存不足时系统会把一些进程的数据换到磁盘的交换分区上。如果内存持续紧张系统会频繁地在物理内存和交换分区之间搬运数据这个行为本身就产生大量的 I/O。更要命的是这种 swap 风暴通常出现在业务高峰期和正常的业务 I/O 叠加直接把磁盘打到晕头转向。判断方法不复杂执行free -h如果 swap 的 used 数值长时间不小同时top里si和so两列数值很高那就是 swap 风暴。这里有个关键认知swap 本身不是洪水猛兽它是一种保护机制真正的问题是“频繁交换”。系统在内存不足时会把最近很少访问的内存页先换出去但如果业务访问模式很差刚换出去的页面马上又要读回来就形成了“换入换出”的抖动循环。避免 swap 风暴的根本手段是加内存或者调降应用的缓存配置而不是简单粗暴地关掉 swap。关掉 swap 只会让内存耗尽时直接触发 OOM 杀进程业务一样受损。日常维护中建议把vm.swappiness从默认的 60 调低到 10 左右让系统优先使用物理内存减少不必要的交换行为。3.3 数据库全表扫描与临时排序网站的慢背后常常是数据库的 I/O 风暴。数据库的读写是最典型的 I/O 密集型操作尤其当某条 SQL 没走索引、全表扫描一张几千万行的表时磁盘读盘量是天文数字。我遇到过最夸张的一次是一条模糊查询把单表一亿行的数据全部读了进来单次查询持续时间长达二十分钟期间磁盘读吞吐被占满其他所有业务全部瘫痪。即使走了索引排序和分组操作也可能把临时结果写到磁盘上。MySQL 在内存不够执行 ORDER BY 或者 GROUP BY 时会创建临时表落到磁盘的临时目录里这个过程同样是 I/O。所以排查数据库型卡顿的时候除了看系统层面的 I/O 指标还要到数据库内部去看开启慢查询日志定位具体的慢 SQL。用EXPLAIN看执行计划检查有没有全表扫描、临时表、文件排序。检查数据库缓冲池大小调大缓冲池能显著减少物理读。数据库导致的 I/O 问题表象是磁盘利用率高根子是 SQL 写得差。这时候运维能做的是给开发提供证据链而不是自己闷头优化系统参数。3.4 文件系统层面与硬件自身的坑最后一种常见诱因藏在文件系统和硬件层。文件系统层面比如在超大目录上执行find全盘搜索或者做增量备份时遍历了海量小文件这些操作会将目录项和元数据疯狂读入内存虽然底层数据量不大但请求数极多IOPS 被打满原本很快的操作变成龟速。硬件层面则五花八门机械硬盘出现了坏道导致反复重读、SSD 的垃圾回收机制导致写放大、硬件 RAID 卡电池耗尽触发写缓存失效、虚拟机磁盘在宿主机上共享一块物理盘被邻居挤压等等。这些问题的特点是你察系统一切正常但就是 I/O 很慢。排查策略是做硬件健康检查——看smartctl的输出看dmesg有没有 I/O error再看看宿主机层面有没有其他虚拟机在下黑手。4. 彻底根除五套 I/O 优化与加固方案4.1 日志降噪与轮转策略落地日志类的 I/O 问题找到了根因之后整改动作其实很标准化。首先是开发侧调整日志级别把不必要的信息拒之门外其次是应用侧引入异步日志把日志写入交由后台线程批量处理降低对业务线程的阻塞最后是系统侧强化 logrotate 的配置。这里给一份常见的 logrotate 配置参考/path/to/your/app/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }daily按天轮转rotate 7保留 7 份compress对旧日志进行压缩copytruncate适合那些无法通过重启应用来释放文件句柄的场景。配置完以后记得跑一次logrotate -d /etc/logrotate.conf做试运行确认配置文件语法没有问题。4.2 数据库和缓存层的 I/O 减负数据库是 I/O 大户优化它的 I/O 通常从三个方向进行。第一是调大数据库的缓存池或缓冲池。以 MySQL 为例InnoDB buffer pool 默认只有 128MB在内存允许的情况下调到总内存的 60% 到 70%就能大幅减少磁盘物理读。第二是优化 SQL消灭全表扫描给高频查询字段加索引避免大表的文件排序。第三是把重复的查询结果缓存起来引入 Redis 或者 Memcached把热点数据的读取压力从磁盘转移到内存。需要强调的是任何一次数据库参数调整都要经过充分的评估和灰度验证不要直接在核心库上拍脑袋改。你改了缓冲池大小如果触发内存分配的连锁反应可能导致操作系统交换。4.3 存储设备升级与系统参数调优软件层面能调的都调完之后如果 I/O 压力依然很大剩下的路就是硬件升级。从机械硬盘换到 SSD是性价比最高的一次变革。SSD 的随机读写能力是机械盘的几十倍对于高并发随机的读写场景简直是降维打击。升级之后磁盘的 I/O 瓶颈窗口会被大大拉高短时间内不用担心同类问题再犯。在系统层面我们可以调整块设备的 I/O 调度器。现代的 SSD 设备一般用none或mq-deadline调度器不需要传统的 CFQ 那种复杂的电梯算法。查看当前调度器的方法cat /sys/block/sda/queue/scheduler临时切换echo mq-deadline /sys/block/sda/queue/scheduler永久生效要写进 udev 规则或内核启动参数不同发行版细节不一样建议在测试环境先验证。4.4 内存与文件缓存参数调优很多 I/O 问题本质上是内存问题因为文件缓存Page Cache的存在本来可以避免大量的磁盘读。如果系统频繁地把文件缓存里的页面清理掉反倒造成反复的磁盘读那就是策略失当。内核里有几个关键参数值得关注。vm.dirty_ratio表示一个进程脏页占总内存比例的上限超过这个值进程自身会被强制同步刷盘。vm.dirty_background_ratio表示整个系统脏页达到某个比例时后台内核线程开始异步刷盘。为了让写入波峰更平滑通常建议保持默认或者适当调高dirty_background_ratio让脏页在后台就慢慢消化不要让一次性攒太多触发同步阻塞。还有一个参数是前文提到过的vm.swappiness改小它我就不再重复了。所有这些参数都可以用sysctl -w临时验证效果确认稳定后再固化到/etc/sysctl.conf。4.5 限流与隔离保护“邻居”也是保护自己如果整个服务器上跑了很多业务某一个业务的 I/O 风暴很容易殃及池鱼。成熟的云平台和容器体系早就提供了 I/O 隔离的机制。比如 systemd 管理的服务可以设置IOWeight和IOReadBandwidthMax来限制某服务的 I/O 权重和带宽上限。Docker 容器则可以使用--device-read-bps和--device-write-bps参数做同样的限制。一般我还会建议对定时任务做物理资源隔离把重 I/O 的批处理任务错峰执行。比如日报生成放在深夜、数据备份放在凌晨与业务高峰错开。这一招不需要任何技术深度但效果立竿见影。5. 实战复盘一次线上“卡死”的完整排障记录5.1 告警触发与第一反应这个案例发生在给某客户维护的一套系统上。上午十点多监控警报突然拉响业务接口平均响应时间从 50ms 飙升到 5 秒以上还伴随大量超时错误。客户群里已经开始有人催问“到底怎么回事”。我第一时间登上跳板机准备连服务器结果明显感觉到 SSH 登录都比平时慢半拍——凭经验这已经不是简单的高并发问题了。我没有直接重启应用而是按照快照采集的流程先敲了uptime和top。top的输出瞬间让所有人都安静了CPU 占用率 10% 都不到但load average已经达到 45wa数值高达 90%以上。我心里马上有数了这就是典型的 I/O 瓶颈。5.2 逐层定位的逻辑链第二步执行iostat -x 1 5结果把问题锁死在某块数据盘上%util一直满负荷运转await超过了 1000 毫秒。我看了一眼时间——这个盘上挂着的正是数据库的实例。第三步用iotop -oP追踪进程看到一连串 mysqld 的读操作吞吐量居高不下。这就引出了一个新问题数据库在读什么于是登录数据库开启慢查询日志几分钟后抓到一条 SQL一条针对核心订单表数据量已经过亿的模糊查询执行计划里清楚地写着type: ALL全表扫描。源头终于找到了某后台运营同事在做导出操作时写了一条没带索引的模糊查询数据库只能把整张表读一遍。这种查询在中午高峰时段执行直接把底层磁盘的读带宽打爆连带着所有其他正常业务都被拖下水。5.3 最终修复动作与效果对比当时的处理分三步同时进行。第一后台把这条慢查询先杀了让数据库恢复呼吸。第二给这个新增的查询字段补上联合索引保证后续同类查询能走索引。第三在数据库连接池和应用层加了一层限流类似的重查询只能排队执行不允许并发进场。从找到元凶到执行完动作大概十五分钟数据库的await降回 1ms 以内接口响应恢复到几十毫秒。整个过程没有重启任何服务业务中断时长被压缩到最小。复盘时我们补上了监控短板给%util、await、top的wa字段都设置了告警阈值同时规定所有后台运营发起的临时查询必须经过统一的查询平台禁止直接连库执行。5.4 复盘总结排障时最怕什么这次排障能快速收场一个重要原因是全程没有“猜到哪算哪”每一步都基于数据做决策。排障最怕的是三件事一是盲目重启把现场都毁掉二是只看症状不分层比如看到数据库慢就去优化数据库忽略了系统层面 I/O 已经被打满的事实三是不留记录复盘全靠记忆后续改进无从下手。我后来总是跟团队强调排障的过程要像刑侦一样保留证据链。每个阶段收集到的数据都要留存这样不仅有利于当前问题的解决还能沉淀成团队的故障知识库下次别人遇到类似问题可以少走弯路。6. 日常防线让“隐形杀手”现身于一场虚惊之前6.1 监控指标与告警阈值设计与其等到卡顿发生再排查不如在日常监控里把 I/O 指标纳入重点。单台服务器的 I/O 不仅仅是iostat上的那几行数字还有块设备层的监控。建议在你的监控系统里至少添加以下指标设备%util超过 80% 持续五分钟告警。设备await超过 100ms 持续五分钟告警。系统iowait占 CPU 的比例超过 20% 持续五分钟告警。进程级 I/O 读写速率超过预设阈值告警。这里说一个我踩过的坑直接对%util设置一条固定阈值并不科学因为不同的设备和业务模型适合的%util上限完全不同。比如 SSD 正常能承受 90% 的 util但机械盘可能到 70% 整个系统就开始卡了。更稳健的做法是设置“相对性告警”即比过去七天的同期均值高出三倍以上才触发告警这样既灵敏又不会误报满天飞。6.2 日常巡检命令速查表下面是给我自己的、也是给你们的一份高频巡检命令速查表。建议每周至少跑一次特别是业务高峰期前后# 系统整体状态 uptime top -bn1 | head -20 free -h # 磁盘I/O详情 iostat -x 1 5 # 进程I/O排行 pidstat -d 1 5 # 挂载点与磁盘空间 df -hT巡检不是刷指标而是观察趋势。每一次记录的数据如果不在同一张图表上连续看就发现不了“每周三下午堵一次”这种规律。我通常会把这些命令的输出重定向到文件里保存然后用脚本做简单统计一旦发现规律性异常提前介入往往成本最低。6.3 常见问题速查与应急指引最后整理一份常见问题速查表方便你在被老板盯着的时候快速翻答案症状特征优先排查项应急动作CPU 空闲、load 很高iostat -x看 await 和 %util用 iotop 找高 I/O 进程暂停或限制它swap 使用持续增长free -h确认检查内存大户考虑重启业务或加内存数据库响应突然变慢慢查询日志杀会话、补索引、调缓存日志文件异常增长du -sh *找大文件关日志级别清理并配置轮转定时任务时段卡顿对照 crontab 和 I/O 趋势错峰执行限速批量任务文件系统操作极慢dmesg找 I/O error检查硬件健康联系厂商这张表对于 80% 的“卡顿”场景够用了。剩下 20% 的疑难杂症大概率藏在硬件故障、内核 bug、虚拟化平台干扰这些深水区那就要靠前面那些底层工具一点一点排查了。归根结底服务器卡顿这件事最让人头疼的不是问题本身而是“看起来一切正常”的假象。我自己踩过几次类似的坑之后现在遇到任何卡顿第一反应永远是先看一眼iowait再看一眼 D 状态进程最后才去碰 CPU 和内存。这套思维方式帮我在无数次“CPU 空闲但服务器卡死”的困境中全身而退。希望这篇文章也能成为你工具箱里的一把趁手家伙下次再遇到这个“隐形杀手”心里有数手里不慌。