周五下午三点半测试同事在群里喊了一声“服务器好卡”我放下手头的活登录线上的Linux服务器排查。原本以为十分钟就能搞定结果一查就是两个小时最后终于定位到问题居然出在一个毫不起眼的定时任务上。今天把这次Linux系统排障的完整经过复盘一遍既聊聊服务器变慢时的通用排查思路也想提醒大家有些看起来像“网络问题”或“应用问题”的故障根子可能藏在cron里。这篇文章不打算写成命令大全而是尽量还原一次真实的事故处理过程从接到告警、确认影响范围、逐项排查资源到顺着进程线索挖出隐藏脚本最后止血恢复。如果你是后端开发、运维或者日常需要自己维护Linux服务器这篇内容应该能帮你省下不少弯路。1. 接到报警之后先定方向别急着上手1.1 第一反应先看监控别登服务器遇到服务器“突然变慢”很多人的第一反应是马上ssh登上去敲top我早期也是这样结果一进服务器就被几十个进程晃花了眼越看越懵。后来我养成了个习惯先打开监控大盘把CPU、内存、磁盘IO、网络这四类核心指标过一遍再决定要不要登服务器。监控的价值不只是看“当前什么状态”更要看曲线形态。比如这次故障监控面板上的load曲线呈现典型的锯齿状每隔一小时规律性爬升一次几分钟后又缓慢下降。这种周期性爬升的曲线本身就是一条非常重要的线索。遗憾的是当时我并没有立刻把这个规律重视起来而是按照老思路冲进服务器对着top面板查了半天。如果能早点抓住“周期性负载”这个信号后面根本不用折腾两个小时。所以这次复盘我特别想把这句话放在最前面监控曲线里的周期性特征往往比单点数值信息量大得多。1.2 确认影响范围是整机慢还是单一应用慢登服务器之前最好先确认一下故障范围。测试同事反馈的是“整个网站都很慢”“接口全部超时”而不是“某个页面打不开”这说明大概率不是某个应用自身的逻辑问题而是整机资源被拖垮了。登录服务器后我做的第一件事是跑uptime看到load average已经是12.8瞬间确认了方向——这不是网络问题也不是单个业务进程的锅而是系统整体负载异常超高。接下来要做的就一件事找出是谁在消耗系统资源。这里有个排查习惯值得多说一句如果你一上来就翻业务日志很容易被应用层的报错带偏。正确顺序应该是先看资源层确认瓶颈在CPU、内存还是IO然后再决定要不要深入业务日志。资源层的结论能帮你快速框定排查范围。2. 资源四件套load、CPU、内存、磁盘IO逐项排查2.1 uptime与load average怎么看uptime是排查服务器慢的时候用得最多的命令它输出的内容非常直观$ uptime 16:28:22 up 120 days, 3:16, 2 users, load average: 12.80, 10.24, 6.35后面三个数字分别是1分钟、5分钟、15分钟的平均负载。很多人会问这个数字到底超过多少算不正常最简单的经验是拿它和CPU总核数对比。这台机器是8核load如果长期高于8就意味着系统里有任务在排队等待CPU已经过载了。需要注意load average和CPU使用率不是同一个概念。CPU使用率看的是任务占用CPU资源的比例而load统计的是“正在运行中的任务数”加上“处于不可中断状态的任务数”。当磁盘IO卡死时大量进程会进入D状态CPU使用率可能只有10%但load依然能飙得很高。这正是排查时容易被误导的地方。本次故障里load已经是12.81分钟负载远高于15分钟负载说明系统正好处于一个快速恶化的阶段必须立刻找到元凶。2.2 top/pidstat定位可疑进程接下来就是大家最熟悉的top。$ top top - 16:28:35 up 120 days, 3:16, 2 users, load average: 12.80, 10.24, 6.35 Tasks: 256 total, 5 running, 251 sleeping %Cpu(s): 91.2 us, 6.8 sy, 2.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 65800.0 total, 10240.0 free KiB Swap: 1024.0 total, 512.0 free PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 21598 root 20 0 120570 4216 1628 R 32.6 0.1 145:32.32 sha256sum 21602 root 20 0 120570 4216 1628 R 28.4 0.1 141:12.18 sha256sum 21596 root 20 0 222876 2112 1592 D 15.7 0.1 118:48.66 cat 11873 root 20 0 112456 1988 592 S 3.2 0.0 300:35.41 sh进top界面后我习惯先按P键让进程按CPU使用率排序再按M键让进程按内存排序各看一轮。如果是8核以上机器还可以按1键看每个核的使用情况。这次输出非常显眼排在最前面的不是业务Java进程而是好几个sha256sum进程CPU占用一个比一个高同时还有一个cat进程挂在那里。更奇怪的是这些进程我完全没见过也不像业务进程。我当场就判断这是有脚本在后台做批量文件操作只是还没确定来源。如果top看着不直观可以再用pidstat -d 1单独看进程级别的IO等待时间。这个命令能直观看到哪个进程在疯狂读盘或者写盘对定位磁盘型故障特别有效。pidstat来自sysstat工具包很多精简安装的Linux发行版默认没有需要提前装好。2.3 内存与磁盘IO的检查要点在确认CPU被sha256sum占用之前我还顺带检查了内存和磁盘避免漏掉隐藏瓶颈。先看内存命令是free -h。如果内存不足系统会频繁触发swap出现“做啥都慢”的效果。这台机器内存还有10GB左右空闲swap也基本没变化说明内存不是瓶颈。再看磁盘IO我用的是iostat -x 1$ iostat -x 1 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vda 0.00 0.00 245.00 321.00 42368.0 55680.0 138.00 16.44 29.12 11.30 44.90 2.15 99.80关键要看%util字段它表示磁盘设备的繁忙程度。这台机器的%util已经接近100%说明磁盘几乎每时每刻都在处理I/O请求已经忙到“转不动了”。再结合刚才top里看到的cat进程处于D状态基本可以确定系统正在承受巨大的磁盘I/O压力。这里有一个非常实用的判断技巧如果%util高但r/s和w/s并不夸张通常说明不是数据量真的很大而可能是进程层面产生了大量低效、无意义的I/O操作。这正好和“脚本里反复复制文件、算哈希、再删除”的行为吻合。3. 从进程线索倒查挖出隐藏的定时任务3.1 顺着PID找到脚本的真实身份看到几个陌生的sha256sum和cat进程我做的第一件事不是kill而是先搞清楚它们是谁拉起来的。在Linux环境下进程不是凭空冒出来的一定会有父进程。我跑了一条组合命令把所有可疑进程的父子关系梳理出来$ ps -ef --forest root 11873 1 0 15:00 ? 00:00:00 \_ /bin/sh /opt/backup_check/check_backup.sh root 21598 11873 0 15:02 ? 00:00:32 \_ sha256sum /backup/db_20250109.tar.gz root 21602 11873 0 15:03 ? 00:00:28 \_ sha256sum /backup/www_20250109.tar.gz root 21596 11873 0 15:02 ? 00:00:18 \_ cat /backup/db_20250109.tar.gz进程树里已经写得非常明白这几个进程的父进程PID是11873指向一个脚本/opt/backup_check/check_backup.sh。到这里嫌疑范围从“进程”缩小到了“脚本”。如果机器上进程名伪装成普通的名称或者被改了名字又要怎么看Linux的/proc目录是排障时最靠谱的宝藏。每一个进程PID都对应/proc/PID目录里面有这个进程的全部底细。常用的几招# 查看进程的工作目录 ls -l /proc/21598/cwd # 查看进程启动时的命令行完整参数 cat /proc/21598/cmdline | tr \0 # 查看进程打开了哪些文件 ls -l /proc/21598/fd | head -30这三个命令基本不会骗人。进程可以伪装名称但它正在打开的文件、当前工作目录、真实的命令行参数都会暴露真实目的。3.2 翻cron日志确认触发来源脚本路径有了但还有一个问题没解决这个脚本是手动运行的还是被某个定时任务拉起来的我注意到这个脚本启动时间是15:00而我们排查时是16:28如果是手动运行理论上已经跑了一个半小时结合监控面板上的周期锯齿它更像是被定时拉起的。先看看当前登录用户的crontab$ crontab -l no crontab for admin当前用户下没有任何定时任务。但我人穷志不能短root和其他系统用户的任务还没查呢。直接翻/var/spool/cron/目录里面有这台机器上所有用户的cron配置文件$ ls -l /var/spool/cron/ -rw------- 1 root root 89 Mar 3 09:30 root再看root用户的任务内容$ cat /var/spool/cron/root 0 * * * * /opt/backup_check/check_backup.sh /dev/null 210 * * * *这个cron表达式读起来很简单每小时整点执行一次脚本。标准的cron表达式只有五个字段从左到右是“分、时、日、月、周”这种写法表示每个小时的第0分钟跑一次。把输出重定向到/dev/null说明写这个定时任务的人当时就没想过要留日志。到这里整条链路的证据已经闭环整点触发脚本脚本循环处理备份文件文件太大、任务没跑完下一个整点又触发新进程层层叠加最后CPU和磁盘IO双双被打满。同时监控面板上那个锯齿状曲线也解释通了每个小时爬升一次。这里顺便提醒一句crontab -l只能看当前用户自己的任务排查可疑定时任务时最好把/var/spool/cron/目录、/etc/cron.d/、/etc/crontab都翻一遍免漏掉系统级任务。3.3 查看脚本逻辑一串for循环引发的血案找到脚本之后我把它完整打开看了一遍内容如下#!/bin/bash BACKUP_DIR/backup for f in $BACKUP_DIR/*.tar.gz; do tmp_f/tmp/check_$(date %s)_$(basename $f) cp $f $tmp_f sha256sum $f /dev/null rm -f $tmp_f done这个脚本的本意其实很简单检查备份目录里的tar.gz包是否完整所以对每个压缩文件算一个sha256校验值。但你注意看这个实现方式——它在计算校验和之前先把备份文件复制一份到/tmp算完校验和之后再删掉。复制这一下纯粹是脱了裤子放屁白白制造了大量的磁盘写入和读取。如果备份目录里只有几个小文件还好说。但这台机器的/backup目录里有几十个tar.gz单个文件动不动几十GB。脚本从cp阶段开始就在疯狂读写磁盘到了sha256sum阶段又要大量消耗CPU计算哈希一个脚本把CPU和IO全部打满机器自然慢成了PPT。更离谱的是整个脚本没有任何互斥锁。0 * * * *这个cron任务每小时触发一次但如果上一轮还没跑完下一轮又会新起一个进程。多个sha256sum、多个cp -process同时叠上来最终把系统资源彻底耗尽。业务进程本身没有问题但它们都阻塞在I/O等资源上什么请求都处理不了。这个案例非常典型脚本本身写得没什么高超技术也没有恶意行为就是一次糟糕的定时任务维护直接把生产环境拖垮了。4. 复盘定时任务排查的常见坑与日常预防4.1 定时任务排查的4个常见坑坑点表现应对方法只看业务进程可疑进程像临时工单独看像正常脚本发现陌生进程先看父子关系再查定时任务crontab -l不全明明有定时任务却查不到翻/var/spool/cron/、/etc/cron.d/、/etc/crontabcron环境与登录环境不同脚本里命令找不到、日志为空脚本开头显式设置PATH和关键环境变量脚本无锁无超时上轮没跑完下轮又起进程叠加使用flock互斥锁并设置timeoutcron里常见的坑远不止这一个。比如cron执行时的PATH默认只有/usr/bin:/bin如果你脚本里用了/usr/local/bin下的命令它可能就直接报command not found而且这个报错不会显示在终端里。很多人排查半天最后才发现是环境变量问题。再比如很多开发者以为crontab -l能查到机器上所有定时任务实际上它只显示当前用户的任务。排查服务器上的定时任务正确的做法是同时检查/var/spool/cron/下所有用户的文件以及/etc/cron.d/、/etc/crontab这些系统级位置。我在日常运维中还见过一种情况任务挂在systemd timer下面cron完全查不到所以遇到周期性问题时systemd的timer列表也可以一并确认。4.2 排障习惯先做确认再动手当时我的处理步骤不复杂但顺序很重要。先把cron里的配置注释掉而不是删除保留现场方便后续复盘。注释掉之后新的脚本进程不会再产生但已经跑着的进程还在所以第二步是清理残余进程。我先用top把所有相关PID列出来确认无误后逐个kill掉没有直接用pkill -f check_backup.sh这种模糊匹配方式避免误杀同名的其他进程。第三步是清掉/tmp下面堆积的临时文件释放磁盘空间。服务恢复正常之后才开始改脚本。改的方向也很明确去掉无意义的cp操作直接对源文件做校验加上flock互斥锁再把输出重定向到日志文件。这套“先止血、再定位、后优化”的顺序是我处理线上故障时比较推荐的节奏。很多人遇到问题第一反应是重启服务甚至直接reboot但如果不搞清楚根因重启只能让问题晚点再爆发一次。4.3 定时任务日常管控的三条建议这次事故之后我对定时任务的上线和管理定了几条硬规矩。第一所有脚本尽量使用绝对路径脚本开头显式设置PATH。不要依赖cron自带的默认环境因为它在执行时和你手动打开的终端完全不一样。第二给所有可能耗时较长的任务加互斥锁。比如用flock的方式flock -xn /tmp/check_backup.lock -c /opt/backup_check/check_backup.sh-xn表示如果锁已被占用就直接退出不让新任务继续叠加。对于可能有异常耗时风险的脚本再套一个timeout 600超过10分钟强制杀掉防止它变成僵尸进程一直消耗资源。第三定时任务上线前必须做一轮资源评估。哪怕是“看起来只是算一下校验和”也要在测试环境完整跑一遍观察CPU、内存、IO的峰值。如果写完脚本就直接扔到生产环境的cron里没人知道它在真实数据量下会膨胀成什么样。另外如果你的服务端已经用了xxl-job这类分布式调度平台来统一管理Java体系的定时任务也不要忽略系统层面的cron。很多机器上依然躺着历史遗留的cron配置无人维护无人review一旦出事就是大麻烦。定期巡检cron列表和巡检代码仓库一样应该成为日常运维的一部分。最后说点个人的体会。这次排障花了两小时回头想想真正定位到问题只用了不到十分钟剩下的大部分时间都浪费在“没看监控曲线、没往定时任务方向想”这个思维误区上。那次之后我给自己定了一条规矩任何新上线的定时任务必须在测试环境完整跑一遍并且肉眼观察一轮资源峰值上线后头三天每天盯一眼监控。这个习惯看起来麻烦实际能挡掉不少隐患。服务器慢这种事最怕的不是第一次发生而是每次都要花两小时去查同一个原因。