这个坑值得记一笔。每天凌晨日志轮转一跑，监控就看到 CPU 从两成冲到九成，同一时段的报表任务全部超时，而待压缩的日志也不过十几 G。
这类报错背后常见的原因有几处，逐个排除就行。几十 G 的日志用单进程压缩，只能吃到一个核；压缩命令用默认的高压缩级别，速度非常慢；没有配延迟压缩，切割和压缩在同一次里完成。
上来先看各服务的压缩配置
grep -r compress /etc/logrotate.d/再往下确认是否配了延迟压缩
grep -n delaycompress /etc/logrotate.d/app降优先级手动演练一次
nice -n 19 logrotate -f /etc/logrotate.conf末了确认实际执行时间
cat /etc/cron.daily/logrotate中途换过一次思路，把范围缩到最小的那一层，反而快了。
改完先别撤，确认这几项。下次切割时 CPU 峰值不超过四成，报表任务耗时回到正常水平，日志仍按策略归档。
补一句。压缩比和 CPU 开销是此消彼长的，日志留存要求不高时缩短保留天数，比压得更狠更省资源。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。