失控的计划任务
SysAdmin Crisis 中失控的 cron 任务：备份在凌晨三点前后启动，把 CPU 钉在 100%，直到被停止。了解它的日志特征。
最后更新:
一个计划任务被触发，却迟迟不结束，把 CPU 一直占在 100%。它是唯一一个在处理之后还会卷土重来的事件——因为处理进程并不等于处理调度。
它做什么
在目标机器上，CPU 进入饱和：先是 WARN，然后是 CRIT，可用率随之下滑。这个任务是一个有名字的进程，会连同 PID 出现在 top 的输出里；所以难点并不在诊断。
难点在于，调度器仍然活着。停掉进程之后，同一个事件实例不久又会把它启动起来。这种情况会发生有限的次数，直到该任务自己的时间窗口自行关闭——所以反复处理它的那一夜确实会结束，但结束是因为任务耗尽了耐心，而不是因为解决了什么；收尾的那行日志也是这么说的。
日志特征
在 cron 日志中，一个任务启动，随后 monit 显示同一个名字超过了 CPU 阈值：
03:02:15 db-01 CRON[24310]: (root) CMD (/opt/jobs/backup.sh)
03:02:51 db-01 monit[588]: 'backup.sh' cpu usage of 100% matches resource limit [cpu usage > 80.0%]
03:03:40 db-01 monit[588]: 'db-01' cpu usage of 98% matches resource limit [cpu usage > 90.0%]
时间点也是特征的一部分。这个事件往往落在班次中段，03:00 前后——恰好是真实备份窗口开启的时刻。进程可以用 top 找到；是谁启动的，写在 ps 和 cron 记录里。
置之不理的后果
单台机器上持续的 CPU 饱和，外加未解决事件带来的 SLA 债务。这是可以挺过去的——机器不会自行进入 DOWN——但只要它还在运行，可用率就会不断流失。
如何区分
| 看起来相似 | 区分依据 |
|---|---|
| DDoS 洪水 | 两者都会占满 CPU。洪水覆盖各台 Web 机器，并伴有内核的 SYN 警告；失控任务则在单台机器上点出单个进程，没有流量方面的来龙去脉。 |
| 内存泄漏 | 两者都会点出一个进程。看哪项指标在变动：这里是 CPU，那里是 RAM。 |
何时出现
| 最早出现的夜 | 4 |
| 前提 | 一台 db 机器 |
| 权重 | 85 |
| 同时出现 | 一个实例 |