会，日志写入显著拖慢磁盘I/O，取决于同步模式、硬件类型与配置；同步写阻塞进程，异步写引发回写尖峰，HDD易现随机写瓶颈，SSD需关注写放大而非%util。
日志写入会显著拖慢磁盘 I/O 吗？
会，但取决于写入模式和底层配置。同步写入（如 fsync()、O_SYNC）会让进程阻塞直到数据落盘，直接放大延迟；异步写入（默认 O_WRONLY + page cache）则把压力转移到内核回写线程（pdflush 或 writeback），可能引发突发 I/O 尖峰。高频率小日志（如每秒千条 syslog）叠加元数据更新（inode、目录项），容易触发磁盘随机写瓶颈，尤其在 HDD 上。
关键判断点：
- 用
iotop -o观察rsyslogd或应用进程的WRITE%IO，若持续 >30%，说明日志是 I/O 主因 -
iostat -x 1中%util接近 100% 且await>50ms，基本可判定磁盘被日志写满 - SSD 上注意
%util失真——它不反映 NAND 写放大，需结合smartctl -a看Media_Wearout_Indicator
rsyslog 的 $ActionFileEnableSync 和 sync() 调用有什么区别？
$ActionFileEnableSync on 是 rsyslog 配置项，等效于对每个日志文件 open() 时加 O_SYNC 标志；而手动调用 sync() 是刷整个 page cache，影响所有脏页，完全不精准。前者只保证单条日志原子落盘，后者会把其他无关进程的缓存也强制刷下去，反而加剧 I/O 毛刺。
实操建议：
- 禁用
$ActionFileEnableSync（默认就是 off），改用$ActionQueueSaveOnShutdown on+$ActionQueueMaxDiskSpace控制队列上限 - 若必须强持久化，优先选
$ActionFileWriteMethod mmapped（内存映射写），比omfile的普通 write() + fsync() 吞吐高 3–5 倍 - 避免在日志路径挂载选项里加
sync（如/etc/fstab中的defaults,sync），这会让所有文件操作变同步
journalctl 日志和传统 syslog 共存时，I/O 怎么分配？
systemd-journald 默认将日志写入二进制 /run/log/journal/（tmpfs，纯内存）和 /var/log/journal/（磁盘）。只要 /var/log/journal/ 存在且可写，journald 就会双写：先写内存再异步刷盘。此时 rsyslog 若还通过 imjournal 模块读取 journal，会产生额外 read + parse 开销，但不增加写 I/O；若 rsyslog 同时也在写自己的文本日志，则磁盘写压力是两者叠加。
常见陷阱：
- 误以为禁用
rsyslog就能省 I/O——其实 journald 刷盘行为不受影响，Storage=volatile才真正停写磁盘 -
journalctl --disk-usage显示的大小 ≠ 实际写入量，因为 journald 用压缩+索引，实际 I/O 还包含日志轮转时的重写和碎片整理 - SSD 上
/var/log/journal/目录权限错误（如非root:systemd-journal）会导致 journald 降级为仅写/run/log/journal/，看似 I/O 下降，实则丢失持久日志
如何用 logrotate 降低日志 I/O 冲击？
logrotate 本身不产生 I/O，但它触发的 postrotate 脚本（比如 kill -USR1 通知 rsyslog 重新打开文件）会引起短时写放大：旧文件 close + 新文件 open + 可能的 fsync。更严重的是，如果配置了 copytruncate，rotate 过程中日志进程仍在写原文件，logrotate 会先 copy 再 truncate，相当于一次完整文件复制（大日志文件极易卡住磁盘）。
安全做法：
- 用
create 640 root root替代copytruncate，让日志进程自己处理新文件创建（需程序支持 SIGHUP） - 对大日志（>100MB），在
logrotate中加delaycompress，避免压缩和 rotate 同时发生 - 把
/var/log单独挂载到低延迟设备（如 NVMe 分区），并设置noatime,nobarrier（XFS）或barrier=0（ext4）减少元数据开销
rsyslog.conf 调参数，却忽略了挂载选项、journal 配置、甚至磁盘调度器（deadline 对日志场景通常比 cfq 更稳）。 
