rsyslog狂写磁盘是IO瓶颈常见根因，需通过top看%wa>30%、iostat查w/s和w_await异常、iotop确认rsyslogd高IO占比，并检查其是否写入系统盘或低性能存储，再结合配置排查debug日志、sync开启及日志路径问题。
直接看 rsyslog 进程是否在狂写磁盘，再确认它写的日志路径是否落在系统盘或低性能盘上——这是最常见也最容易被忽略的根因。
第一步：确认 iowait 确实高且由写操作主导
运行 top，紧盯 %wa 列：持续高于 30% 就需立即干预；若同时 %us + %sy 很低（比如总和不到 15%），基本可排除 CPU 计算瓶颈，锁定为 IO 等待问题。
接着用 iostat -xm 2 观察写密集型指标：
• w/s（每秒写请求数）是否远超 r/s；
• wkB/s 是否占吞吐大头；
• w_await 是否 > 30ms（说明写请求排队严重）；
• %util 是否接近或超过 90%，尤其对应 sda 或 nvme0n1p1 这类系统盘设备。
第二步：揪出 rsyslog 是不是真凶
执行 sudo iotop -oP -d 2（只显示实际 IO 进程，按进程而非线程）：
• 找到 COMMAND 列为 rsyslogd 的行；
• 看它的 DISK WRITE 是否长期稳居 Top 3，且数值跳变剧烈（如 80–150 MB/s 波动）；
• 若看到 rsyslogd 占用 IO% 高达 70%+，基本坐实。
补充验证：
• pidstat -d -p $(pgrep rsyslogd) 2 查看该进程每秒写入字节数；
• lsof -p $(pgrep rsyslogd) | grep REG | grep -E "\.log$|\/var\/log" 确认它正往哪些日志文件猛写。
第三步：定位高频写盘的具体原因
检查 rsyslog 配置是否“失控”：
• grep -v "^#" /etc/rsyslog.conf /etc/rsyslog.d/*.conf | grep -E "(debug|Debug|level|Level)" —— 看是否误启了 debug 级别日志；
• ls -lh /var/log/ | grep -E "(messages|syslog|kern|secure)" —— 看单个日志文件是否在 1 分钟内增长超 10MB；
• journalctl -u rsyslog --since "2 minutes ago" | wc -l —— 若输出数万行，说明上游有大量异常事件涌入（如内核 panic 循环、服务反复崩溃、网络设备频繁 up/down）。
特别注意：
• 是否配置了 $ActionFileEnableSync on 或 sync="on"？这会让每次写都强制刷盘，极大放大 IO 压力；
• 是否将日志写到了 NFS 或云盘挂载点？这些存储延迟高、重试多，小量写入也会触发高 w_await。
第四步：快速缓解与长期修复
应急止血（立刻执行）：
• 临时关闭 debug 日志：sed -i 's/.*debug.*/#&/' /etc/rsyslog.d/*.conf && systemctl reload rsyslog；
• 若日志已撑爆磁盘，先清空大日志：truncate -s 0 /var/log/messages（慎用，建议先备份）；
• 禁用同步刷盘：echo '$ActionFileEnableSync off' >> /etc/rsyslog.conf && systemctl restart rsyslog。
长期加固：
• 启用日志轮转并限制大小：/etc/logrotate.d/rsyslog 中加入 size 100M 和 maxlogsize 1G；
• 把高频日志（如 messages、secure）单独切到高性能盘或 SSD 分区；
• 对中间件日志改用异步框架（Log4j2 的 AsyncAppender、Logback 的 AsyncAppender），避免和 rsyslog 争抢磁盘。
