上个月调试一台跑 PREEMPT_RT 内核的工控机实时控制线程按 2ms 周期运行结果日志一多周期抖动直接飙到 30ms。最先怀疑是中断亲和性、CPU 隔离的问题查了一圈都没中。最后用blktrace一看真正的元凶是/var/log下日志文件轮转触发的 fsync整块磁盘的 IO 被打满实时线程在一个文件锁上等了一个完整的调度周期。从那以后我把 Rsyslog 和 Journald 的异步写入彻底翻了一遍也摸清了磁盘 IO 阻塞实时任务的各种路径。这篇就把整套调优思路、配置参数、验证方法完整写下来给正在做实时 Linux 后台服务、边缘计算网关、工业控制器日志方案的人一个可以直接照抄的参考。1. 为什么后台写日志能把实时线程卡出几十毫秒毛刺1.1 日志链路里的三个同步陷阱很多人以为日志就是往文件里写几行字后台进程慢点也无所谓。但在实时 Linux 系统里日志路径上有三个地方都可能让前台任务同步等待。第一个陷阱是syslog()系统调用本身。传统 syslog 协议走 Unix domain socket应用把日志丢给 rsyslogd 后返回。这套设计本来是异步的但当 rsyslogd 的 socket 接收缓冲区写满时sendmsg()会阻塞应用就得等。换句话说日志消费速度跟不上生产速度时异步会退化成同步。第二个陷阱是 Journald 的磁盘同步。systemd-journald 把日志写入 journal 文件后会在一定条件下调用fsync()。fsync 不是立即返回的它要等数据真正落到磁盘介质上机械盘寻道、SSD 掉速、磁盘控制器写缓存忙都会让这个调用等上几十甚至上百毫秒。journald 执行 fsync 时自己卡住不要紧关键是 journal 文件在/var/log上文件锁被 journald 持有其他要写日志、读日志的进程都得排队。第三个陷阱是文件锁和 logrotate。日志轮转时要把旧文件改名、创建新文件、执行 postrotate 脚本这个过程中持有文件锁期间任何想写同一个日志文件的任务都会阻塞。工业现场常见的就是 logrotate 恰好和实时任务的高峰撞在一起。1.2 优先级反转的现实版本教科书里的优先级反转是低优先级任务持有锁高优先级任务等锁。实时 Linux 系统加了优先级继承协议但只覆盖显式的pthread_mutex等锁机制。文件锁、内核块 IO 等待、ext4 journal 提交这类路径优先级继承并不总是有效。举个例子日志进程以普通优先级运行拿到日志文件的锁开始写几千行日志中途触发文件系统分配块、等待 journal commit。此时 SCHED_FIFO 的实时线程来了它需要读日志或者写日志必须等那把锁。实时线程不会因为优先级高就插队获得文件锁只能干等磁盘完成当前 IO。这就是低优先级日志进程打劫高优先级实时任务的现实版本。1.3 磁盘层的不可控寻道、GC 与 cache 回写机械盘顺序写尚有几十 MB/s 的持续性能但随机写或遇到寻道就是几毫秒到几十毫秒的延迟实时任务等不起。SSD 的情况更隐蔽正常延迟几十微秒遇到垃圾回收、写放大、NVMe 队列深度陡增时尾延迟能飙到几十毫秒这个长尾对实时系统最致命。还有一个容易忽略的点是文件系统自身的 journal。ext4 在dataordered模式下每次提交都要把元数据和数据块落盘磁盘缓存的回写时机由内核控制不受用户进程优先级影响。所有这些合在一起就形成了那句话磁盘 IO 延迟不可控所以实时任务绝不能同步等磁盘。2. 设计思路把日志写入从实时热路径上彻底剥离2.1 先定延迟预算再谈日志方案任何实时系统先要有延迟预算。比如控制任务周期是 2ms那日志链路引入的最坏延迟应该控制在任务周期的十分之一以内也就是 200us 左右。这个预算决定了日志方案不能是尽量快而必须是绝不阻塞调用方。在实际项目中我给自己定的原则是实时线程所在路径上绝对不能出现任何write()、fsync()、文件锁等待、IO 排队等待。这些操作一律交给独立的消费者线程实时线程只负责把日志丢进内存队列就返回。2.2 日志通路选型Journald、Rsyslog 与应用直写先梳理一下常见的三种日志通路及其实时性特征。通路方案实时性风险适用场景Journald 直接持久化Storageautojournald 周期 fsync磁盘繁忙时阻塞不可控需要本机留存完整日志、可接受偶尔抖动Journald 内存模式 Rsyslog 异步队列调用方只写内存队列磁盘写由低优先级消费者承担实时任务为主日志允许少量丢失应用直接 open/write/fsync 日志文件每次写盘都暴露在实时路径上风险最高不建议实时线程使用在我处理的实时系统里默认推荐第三种组合Journald 接收日志但只放内存Rsyslog 通过 imjournal 从内存 journal 读取日志进入自己的异步队列再由低优先级工作线程批量写入磁盘或转发远程。这样就形成了生产者写内存、队列做缓冲、消费者批量刷盘的三段式结构。2.3 核心架构生产者-队列-消费者整个方案的核心思路是剥离开产生日志和写磁盘这两个动作。产生日志的动作必须快速、无阻塞写磁盘的动作可以慢但必须有界、可控、低优先级。实现上Journald 本身充当第一级缓冲它接收应用日志后写入/run/log/journal这种 tmpfs 内存文件系统不直接触发块 IORsyslog 的 imjournal 模块从内存 journal 读取日志投递到自身的主队列rsyslog 的 omfile 动作在另一端批量出队用可控制的节奏写入持久化磁盘。这里有个关键点队列必须提供背压保护。队列满时新的入队请求要能快速超时返回或者丢弃而不是无限期阻塞调用方。这决定了系统在极端高负载下的表现——宁可丢日志不能卡任务。3. Journald 侧实战调大缓冲窗口、压低同步频率3.1 推荐的 journald.conf 配置与参数含义Journald 的配置文件在/etc/systemd/journald.conf。实时场景下我通常这样设置[Journal] Storageauto Compressyes Sealno SplitModehost SyncIntervalSec10m RateLimitIntervalSec30s RateLimitBurst20000 SystemMaxUse4G SystemMaxFileSize1G RuntimeMaxUse512M RuntimeMaxFileSize128M逐个说下关键参数。SyncIntervalSec10m是核心它控制 journald 强制 fsync 的周期。默认值是 5 分钟我调到 10 分钟甚至更长就是为了减少后台 fsync 打断磁盘节奏的频率。注意这个参数不是完全不 fsync在关机、切换 journal 文件等场景下 journald 仍然会同步。Sealno关闭 journal 文件的 HMAC 签名封存。封存功能默认并非全部发行版开启但显式关闭可以减少周期性校验带来的 CPU 开销。实时系统里 CPU 预算非常宝贵不值得花在验签上。RateLimitIntervalSec30s配合RateLimitBurst20000是为了防止实时任务突发大量日志时被 journald 的默认限流策略误伤。默认的 10000 条 / 30 秒在极端情况下不够用调大后可以降低丢日志概率但仍要注意 journald 在高负载下仍有静默丢弃的可能。3.2 Storagevolatile 的取舍日志可丢就只用内存如果业务允许日志在系统重启后丢失或者日志最终会转发到远程日志中心那么Storagevolatile是最省心的选择。这种模式下 journald 只写/run/log/journal对应的 tmpfs完全不产生持久化磁盘 IO实时任务彻底摆脱了 journald 写盘的干扰。代价是重启后日志全部清空磁盘上的持久化目录不会继续积累。对工业控制器、边缘网关这类设备日志本来就是给远程运维看的本机留不留都行。我的建议是能接受丢日志的实时系统直接用 volatile再把 Rsyslog 配成转发到远程不能接受的用Storageauto加独立日志盘并把SyncIntervalSec调大。3.3 别让 journald 同时成为 CPU 瓶颈很多人只盯着磁盘忽略了 journald 在高日志速率下的 CPU 占用。journald 本身要对日志做解析、时间戳格式化、压缩。Compressyes开启后 CPU 开销会增加但在日志量大的场景下能显著降低磁盘写入量一般建议保留。如果实时任务所在 CPU 核非常紧张可以考虑把 systemd-journald 的 CPUAffinity 限制到某个不怎么跑实时任务的核心上[Service] CPUAffinity2,3配合下一章要讲的 IO 优先级设置让 journald 成为一个有界、有偏向的后台消费者。4. Rsyslog 异步队列从逐条写文件改成批量出队4.1 imjournal 与 main_queue 的分工Rsyslog 在实时日志方案里承担的角色是读取 格式化 写入/转发。imjournal 模块负责从 journald 的 journal 文件读取新日志投递到 rsyslog 的主队列主队列背后的工作线程以批次为单位取出日志交给 omfile 或 omfwd 执行。这套结构和请求-响应模型完全不同。应用产生日志后journald 写入内存rsyslog 的 imjournal 按轮询间隔读取之后进队列队列满时 rsyslog 会按配置的timeoutenqueue策略拒绝新日志而不是无限等待。这样任何一环慢都不会反向阻塞日志生产者。4.2 一套可以抄的 main_queue 配置Rsyslog 的异步配置写在/etc/rsyslog.conf里核心是主队列参数。下面是我在一台 16 核实时工控机上实际使用的配置global(queue.size200000) module(loadimjournal StateFile/var/lib/rsysql/imjournal.state) module(loadomfile) module(loadomfwd) template(nameRtFormat typestring string%timegenerated% %syslogtag% %msg%\n) main_queue( queue.typelinkedList queue.size200000 queue.highwatermark150000 queue.lowwatermark20000 queue.maxdiskspace1G queue.filenamert_queue queue.spoolDirectory/var/spool/rsyslog queue.dequeuebatchsize1024 queue.timeoutenqueue3 queue.timeoutshutdown10 queue.timeoutactioncompletion10 )参数含义拆解如下queue.typelinkedList表示用链表内存队列。fixedArray 的固定数组在突发流量时可能提前占满链表在日志量波动大的场景下更灵活代价是每条日志多一点点内存开销。queue.size是队列最大条数上限我按系统内存余量配到 20 万条。以平均每条日志 500 字节计算约占用 100MB 内存这在 16G 内存的工控机上可以接受。队列越大允许的突发缓冲越深但内存占用也随之增长需要按实际硬件来折中。highwatermark和lowwatermark是磁盘辅助队列的启停水位。队列长度达到高水位时rsyslog 开始把后续日志写入磁盘辅助文件降到低水位后停止。这里设置的150000和20000保证大部分时间日志停留在内存队列中只有极端情况才触发磁盘辅助。dequeuebatchsize1024是关键中的关键它控制工作线程一次取出多少条日志再执行写入。默认值较低一次取几十条调到 1024 后写日志的频率大幅降低每次都是顺序批量写磁盘效率明显提升。代价是单批次在队列里的等待时间变长日志到文件的延迟会增加一点。实时场景下我们优先保证任务不卡日志晚几秒落盘完全可接受。timeoutenqueue3表示队列真的满了时入队最多等 3 秒超时就丢弃当前这批日志。这个参数就是那道宁可丢日志也不能卡调用方的保险闸。4.3 action 级队列与 DiskAssist 兜底除了主队列rsyslog 允许给单个动作单独配队列。这个能力在一个重要日志目标拖垮其他所有日志的场景下很有用。比如把远程转发单独隔离出来ruleset(namertlogs) { action( typeomfwd target192.168.10.20 port514 protocoludp queue.typefixedArray queue.size50000 queue.highwatermark40000 queue.lowwatermark5000 queue.dequeuebatchsize512 queue.timeoutenqueue2 queue.maxdiskspace512M queue.filenamefwd_queue ) }如果远程日志服务器慢或者网络抖动这个 action 队列会吸收缓冲不会影响本机其他日志目标的写入节奏。DiskAssist 机制同样重要。配置了queue.filename、queue.spoolDirectory和queue.maxdiskspace后当内存队列持续处于高水位时rsyslog 会把超出部分的日志落盘到 spool 目录防止进程内存耗尽。对实时系统来说这是极端情况下的兜底不是常态路径。4.4 日志到远程omfwd 与本地零落盘组合如果远程日志中心可用最干净的组合是 journald 用 volatile、rsyslog 只负责转发、本机完全不落盘日志文件。这样日志数据永远在内存和网络缓冲区之间流动完全不依赖本地磁盘的 IO 性能。action( typeomfwd targetlog-center.example.internal port6514 protocoltcp templateRtFormat action.resumeRetryCount-1 )resumeRetryCount-1表示断线后无限重连配合队列缓冲保证网络瞬断时日志不丢。这个方案唯一的弱点是依赖网络可靠性适合有专网或稳定数据链路的工业现场。5. 让日志进程让路IO 优先级、挂载参数与调度器协同5.1 用 systemd 把 journald 和 rsyslog 的 IO 优先级压到最低异步队列解决了调用方不被阻塞的问题还没解决日志进程本身抢磁盘带宽的问题。当实时任务的数据盘和日志盘共用同一块物理磁盘时日志进程的高频 IO 会挤占实时数据读写的带宽延长实时任务的 IO 完成时间。Linux 的 ionice 提供了三类 IO 调度优先级realtime最高、best-effort默认、idle最低。日志这种后台任务直接压到 idle 最合适。在 systemd 服务里设置[Service] IOSchedulingClassidle IOSchedulingPriority7 IOWeight1对 rsyslog 和 systemd-journald 都执行systemctl edit systemd-journald systemctl edit rsyslog写入上面的片段后重启服务然后验证systemctl show systemd-journald -p IOSchedulingClass systemctl show rsyslog -p IOSchedulingPriorityIOSchedulingClassidle表示该进程的 IO 请求只在磁盘完全空闲时才会被调度。对于实时任务的数据读写来说日志进程直接变成透明人。IOWeight1是 cgroup v2 的权重值1 是几乎最低档位进一步保证日志 IO 不会和实时 IO 竞争。5.2 文件系统挂载参数降低周期性刷盘频率如果日志最终还是落在本地盘挂载参数能显著影响刷盘行为。以下配置适合日志分区/dev/sdb1 /var/log ext4 noatime,nodiratime,datawriteback,commit120 0 2noatime,nodiratime关闭文件访问时间更新减少元数据写入。datawriteback让文件数据不经过 journal只记录元数据能减少 journal 写入量但崩溃时文件内容可能处于不一致状态这点必须和业务侧确认接受。commit120把文件系统 journal 提交周期从默认 5 秒拉长到 120 秒减少周期性刷盘带来的突刺。如果你对数据一致性要求高坚持用dataordered那至少把commit调大让 journal 提交尽可能聚合。日志文件本来就不是数据库事务日志掉电丢几秒日志通常可以接受但游戏规则要在设计文档里写明白。5.3 块设备调度器日志盘和数据盘要分而治之块设备调度器决定了 IO 请求在设备队列里的排序方式。机械盘用mq-deadline或bfqNVMe 盘通常直接none。查看当前调度器cat /sys/block/sda/queue/scheduler我的建议分三层实时任务的数据盘和日志盘在物理层面分开这是最优解必须共享一块盘时给日志盘设置独立分区并限制 IO 优先级调度器层面机械盘用bfq配合上面设置的 idle 类NVMe 用none即可。物理隔离的意义远大于任何软件参数。实时任务的数据读写和日志刷盘如果落在一块盘上哪怕日志进程是 idle 类磁盘固件内部的处理也会互相干扰。能上两块盘就不共用一块这是架构层面的决策。5.4 实时调度规则与日志进程的关系这里顺带回应一下怎样配置实时 Linux 调度规则这个经常被问到的问题。实时线程用SCHED_FIFO或SCHED_RR只能保证 CPU 不被普通进程抢占但解决不了线程自身陷入 D 状态等待磁盘 IO 的问题。一个实时线程如果发起了fsync()它就处于不可中断睡眠CPU 调度规则再高也没用只能傻等磁盘。所以实时任务里写日志的正确姿势是实时线程绝不直接打开文件写而是把日志塞到内存环形缓冲区或发给 journald由独立的低优先级进程去刷盘。实时调度规则管的是 CPU 资源分配日志架构管的是消除 IO 同步等待两者缺一不可。6. 验证效果用 cyclictest 和 IO 监控对比优化前后6.1 构造一个能复现的日志风暴 实时负载压测环境没有实测数据的优化都是玄学我当时用 cyclictest 模拟实时负载再用脚本灌日志风暴对比前后的延迟分布。压测脚本大概长这样#!/bin/bash # 实时负载1 个线程SCHED_FIFO 优先级 951ms 周期跑 10 万次 cyclictest -t 1 -p 95 -i 1000 -l 100000 -h 400 -m -q /tmp/cyclictest-before.txt # 日志风暴连续往 syslog 写带时间戳的日志模拟业务峰值 for i in $(seq 1 500000); do logger -p user.info rt-noise $i $(date %s%N) done 跑完后让 iostat 在后台记录磁盘状态iostat -x 1 60 /tmp/iostat-before.txt6.2 看延迟直方图和最大值不是看平均值cyclictest 的-h 400会输出延迟直方图。重点关注最大值和 99.9 分位平均值对实时系统没有意义。优化前我测得的最大延迟在 32ms 左右优化后最大值降到 180us 以内效果立竿见影。对比表格大致如下场景平均延迟最大延迟99.9% 延迟基线无日志负载12us38us22us默认配置 日志风暴68us32ms2.4ms优化后 日志风暴15us180us42us这个对比充分说明日志配置不合理时最坏延迟能高出两个数量级而合理的异步化能把日志风暴的影响压回接近基线水平。6.3 看 fsync 频率和块设备排队指标延迟数字之外还要从系统层面确认优化确实生效。用 strace 数 journald 的 fsync 调用次数strace -f -p $(pidof systemd-journald) -e tracefsync -c跑 10 分钟后优化前的 fsync 调用次数可能上百次优化后个位数。同时用iostat -x 1看磁盘的await和%util日志风暴期间优化前的await可能飙升到几十毫秒优化后保持稳定低值。rsyslog 队列状态也可以直接监控/usr/sbin/rsyslogd -Q或者看/var/log/syslog里是否出现队列满的告警。实际调试中我会把queue.size临时调小来制造告警验证timeoutenqueue确实生效确认极端情况下系统不会卡死。6.4 长稳测试才是硬通货日志和 IO 的干扰有一个特点不频繁但一旦发生就是大坑。单次测试可能刚好没踩到 logrotate、刚好没遇到 SSD 垃圾回收所以必须长时间跑。我建议至少 8 小时连续测试中间人为触发几次 logrotate、journal 文件轮转和磁盘写入压力再统计全程最大延迟。很多优化完很稳的方案就是倒在 4 小时后的那次 logrotate 上的。把 logrotate 时间错开实时任务高峰期或者干脆在低峰期执行也是很实用的手段。7. 容易忽略的坑限流、audit、队列超时7.1 journald rate limit 静默丢日志journald 默认的RateLimitIntervalSec30s和RateLimitBurst10000在日志量瞬时飙升时会触发限流超出的日志被静默丢弃应用层完全感知不到。实时任务的日志往往就是突发式的开机自检、故障录波、控制事件都可能瞬间产生大量日志。建议把 burst 调到业务峰值的两倍以上同时用 tcpdump 或导出的日志对比确认没有静默丢失。7.2 auditd 和 logrotate 是另一个隐藏刷盘者很多人只盯着 journald 和 rsyslog忽略了 auditd。内核审计模块如果配置不当在日志风暴期间触发审计事件auditd 的 backlog 会被打满进而影响系统调用性能。如果实时任务系统不需要审计功能直接关掉审计服务是干净的方案必须保留的话把 backlog 调大并限制max_log_file的触发动作。logrotate 的问题前面提过再补充一点确保日志文件的轮转时间不和实时任务的周期任务重叠可以用cron配到凌晨低峰或者在 systemd timer 里加随机延迟避免所有服务同时触发轮转造成 IO 峰值叠加。7.3 队列参数别盲调内存、出队延迟和丢日志窗口异步队列的参数是互相牵扯的。queue.size调大带来更长的事件延迟——日志在队列里等得越久落盘时间越晚dequeuebatchsize调大提升吞吐但也会让日志在队列里积累更多timeoutenqueue调大增加了阻塞容忍度却违背了绝不卡调用方的初衷。我的参数设计逻辑是先定业务可接受的日志最大延迟比如 10 秒内必须落盘或转发再按日志峰值速率算队列深度最后按硬件内存余量定queue.size。日志这种数据宁可丢也不能让它卡住实时控制回路。把这句话写进团队的设计评审文档比任何参数都重要。7.4 实时系统的日志哲学该丢就丢但要知道丢了什么做实时系统时间长了对日志的态度会从一条都不能丢变成允许丢但要有监控告诉我是谁丢了。异步队列、内存缓冲、限流策略本质都是在延迟、可靠性、资源消耗之间做折中。日志异步化之后必须配套可观测性队列长度、丢弃计数、落盘延迟这些指标要暴露出来不然就是蒙着眼睛做优化。我的最终配置在这个思路上落地实时任务的日志路径上没有任何同步磁盘等待journald 是内存缓冲rsyslog 是批量消费者IO 优先级最低磁盘物理隔离。跑了一个月下来实时任务的最坏延迟始终稳定在预算以内日志也一条不落地到了远程日志中心。最后再给一个小技巧调完参数后把/etc/systemd/journald.conf和/etc/rsyslog.conf的差异保存下来放进版本管理同时在部署文档里写明为什么这些参数要这样配。等三个月后你自己回来看配置会发现当初的决策记录比任何运维文档都值钱。 
长河君 · 2026/10/10 20:32:00 · 阅读 1.2k 实时Linux日志异步化：消除磁盘IO对实时任务的卡顿干扰
上个月调试一台跑 PREEMPT_RT 内核的工控机实时控制线程按 2ms 周期运行结果日志一多周期抖动直接飙到 30ms。最先怀疑是中断亲和性、CPU 隔离的问题查了一圈都没中。最后用blktrace一看真正的元凶是/var/log下日志文件轮转触发的 fsync整块磁盘的 IO 被打满实时线程在一个文件锁上等了一个完整的调度周期。从那以后我把 Rsyslog 和 Journald 的异步写入彻底翻了一遍也摸清了磁盘 IO 阻塞实时任务的各种路径。这篇就把整套调优思路、配置参数、验证方法完整写下来给正在做实时 Linux 后台服务、边缘计算网关、工业控制器日志方案的人一个可以直接照抄的参考。1. 为什么后台写日志能把实时线程卡出几十毫秒毛刺1.1 日志链路里的三个同步陷阱很多人以为日志就是往文件里写几行字后台进程慢点也无所谓。但在实时 Linux 系统里日志路径上有三个地方都可能让前台任务同步等待。第一个陷阱是syslog()系统调用本身。传统 syslog 协议走 Unix domain socket应用把日志丢给 rsyslogd 后返回。这套设计本来是异步的但当 rsyslogd 的 socket 接收缓冲区写满时sendmsg()会阻塞应用就得等。换句话说日志消费速度跟不上生产速度时异步会退化成同步。第二个陷阱是 Journald 的磁盘同步。systemd-journald 把日志写入 journal 文件后会在一定条件下调用fsync()。fsync 不是立即返回的它要等数据真正落到磁盘介质上机械盘寻道、SSD 掉速、磁盘控制器写缓存忙都会让这个调用等上几十甚至上百毫秒。journald 执行 fsync 时自己卡住不要紧关键是 journal 文件在/var/log上文件锁被 journald 持有其他要写日志、读日志的进程都得排队。第三个陷阱是文件锁和 logrotate。日志轮转时要把旧文件改名、创建新文件、执行 postrotate 脚本这个过程中持有文件锁期间任何想写同一个日志文件的任务都会阻塞。工业现场常见的就是 logrotate 恰好和实时任务的高峰撞在一起。1.2 优先级反转的现实版本教科书里的优先级反转是低优先级任务持有锁高优先级任务等锁。实时 Linux 系统加了优先级继承协议但只覆盖显式的pthread_mutex等锁机制。文件锁、内核块 IO 等待、ext4 journal 提交这类路径优先级继承并不总是有效。举个例子日志进程以普通优先级运行拿到日志文件的锁开始写几千行日志中途触发文件系统分配块、等待 journal commit。此时 SCHED_FIFO 的实时线程来了它需要读日志或者写日志必须等那把锁。实时线程不会因为优先级高就插队获得文件锁只能干等磁盘完成当前 IO。这就是低优先级日志进程打劫高优先级实时任务的现实版本。1.3 磁盘层的不可控寻道、GC 与 cache 回写机械盘顺序写尚有几十 MB/s 的持续性能但随机写或遇到寻道就是几毫秒到几十毫秒的延迟实时任务等不起。SSD 的情况更隐蔽正常延迟几十微秒遇到垃圾回收、写放大、NVMe 队列深度陡增时尾延迟能飙到几十毫秒这个长尾对实时系统最致命。还有一个容易忽略的点是文件系统自身的 journal。ext4 在dataordered模式下每次提交都要把元数据和数据块落盘磁盘缓存的回写时机由内核控制不受用户进程优先级影响。所有这些合在一起就形成了那句话磁盘 IO 延迟不可控所以实时任务绝不能同步等磁盘。2. 设计思路把日志写入从实时热路径上彻底剥离2.1 先定延迟预算再谈日志方案任何实时系统先要有延迟预算。比如控制任务周期是 2ms那日志链路引入的最坏延迟应该控制在任务周期的十分之一以内也就是 200us 左右。这个预算决定了日志方案不能是尽量快而必须是绝不阻塞调用方。在实际项目中我给自己定的原则是实时线程所在路径上绝对不能出现任何write()、fsync()、文件锁等待、IO 排队等待。这些操作一律交给独立的消费者线程实时线程只负责把日志丢进内存队列就返回。2.2 日志通路选型Journald、Rsyslog 与应用直写先梳理一下常见的三种日志通路及其实时性特征。通路方案实时性风险适用场景Journald 直接持久化Storageautojournald 周期 fsync磁盘繁忙时阻塞不可控需要本机留存完整日志、可接受偶尔抖动Journald 内存模式 Rsyslog 异步队列调用方只写内存队列磁盘写由低优先级消费者承担实时任务为主日志允许少量丢失应用直接 open/write/fsync 日志文件每次写盘都暴露在实时路径上风险最高不建议实时线程使用在我处理的实时系统里默认推荐第三种组合Journald 接收日志但只放内存Rsyslog 通过 imjournal 从内存 journal 读取日志进入自己的异步队列再由低优先级工作线程批量写入磁盘或转发远程。这样就形成了生产者写内存、队列做缓冲、消费者批量刷盘的三段式结构。2.3 核心架构生产者-队列-消费者整个方案的核心思路是剥离开产生日志和写磁盘这两个动作。产生日志的动作必须快速、无阻塞写磁盘的动作可以慢但必须有界、可控、低优先级。实现上Journald 本身充当第一级缓冲它接收应用日志后写入/run/log/journal这种 tmpfs 内存文件系统不直接触发块 IORsyslog 的 imjournal 模块从内存 journal 读取日志投递到自身的主队列rsyslog 的 omfile 动作在另一端批量出队用可控制的节奏写入持久化磁盘。这里有个关键点队列必须提供背压保护。队列满时新的入队请求要能快速超时返回或者丢弃而不是无限期阻塞调用方。这决定了系统在极端高负载下的表现——宁可丢日志不能卡任务。3. Journald 侧实战调大缓冲窗口、压低同步频率3.1 推荐的 journald.conf 配置与参数含义Journald 的配置文件在/etc/systemd/journald.conf。实时场景下我通常这样设置[Journal] Storageauto Compressyes Sealno SplitModehost SyncIntervalSec10m RateLimitIntervalSec30s RateLimitBurst20000 SystemMaxUse4G SystemMaxFileSize1G RuntimeMaxUse512M RuntimeMaxFileSize128M逐个说下关键参数。SyncIntervalSec10m是核心它控制 journald 强制 fsync 的周期。默认值是 5 分钟我调到 10 分钟甚至更长就是为了减少后台 fsync 打断磁盘节奏的频率。注意这个参数不是完全不 fsync在关机、切换 journal 文件等场景下 journald 仍然会同步。Sealno关闭 journal 文件的 HMAC 签名封存。封存功能默认并非全部发行版开启但显式关闭可以减少周期性校验带来的 CPU 开销。实时系统里 CPU 预算非常宝贵不值得花在验签上。RateLimitIntervalSec30s配合RateLimitBurst20000是为了防止实时任务突发大量日志时被 journald 的默认限流策略误伤。默认的 10000 条 / 30 秒在极端情况下不够用调大后可以降低丢日志概率但仍要注意 journald 在高负载下仍有静默丢弃的可能。3.2 Storagevolatile 的取舍日志可丢就只用内存如果业务允许日志在系统重启后丢失或者日志最终会转发到远程日志中心那么Storagevolatile是最省心的选择。这种模式下 journald 只写/run/log/journal对应的 tmpfs完全不产生持久化磁盘 IO实时任务彻底摆脱了 journald 写盘的干扰。代价是重启后日志全部清空磁盘上的持久化目录不会继续积累。对工业控制器、边缘网关这类设备日志本来就是给远程运维看的本机留不留都行。我的建议是能接受丢日志的实时系统直接用 volatile再把 Rsyslog 配成转发到远程不能接受的用Storageauto加独立日志盘并把SyncIntervalSec调大。3.3 别让 journald 同时成为 CPU 瓶颈很多人只盯着磁盘忽略了 journald 在高日志速率下的 CPU 占用。journald 本身要对日志做解析、时间戳格式化、压缩。Compressyes开启后 CPU 开销会增加但在日志量大的场景下能显著降低磁盘写入量一般建议保留。如果实时任务所在 CPU 核非常紧张可以考虑把 systemd-journald 的 CPUAffinity 限制到某个不怎么跑实时任务的核心上[Service] CPUAffinity2,3配合下一章要讲的 IO 优先级设置让 journald 成为一个有界、有偏向的后台消费者。4. Rsyslog 异步队列从逐条写文件改成批量出队4.1 imjournal 与 main_queue 的分工Rsyslog 在实时日志方案里承担的角色是读取 格式化 写入/转发。imjournal 模块负责从 journald 的 journal 文件读取新日志投递到 rsyslog 的主队列主队列背后的工作线程以批次为单位取出日志交给 omfile 或 omfwd 执行。这套结构和请求-响应模型完全不同。应用产生日志后journald 写入内存rsyslog 的 imjournal 按轮询间隔读取之后进队列队列满时 rsyslog 会按配置的timeoutenqueue策略拒绝新日志而不是无限等待。这样任何一环慢都不会反向阻塞日志生产者。4.2 一套可以抄的 main_queue 配置Rsyslog 的异步配置写在/etc/rsyslog.conf里核心是主队列参数。下面是我在一台 16 核实时工控机上实际使用的配置global(queue.size200000) module(loadimjournal StateFile/var/lib/rsysql/imjournal.state) module(loadomfile) module(loadomfwd) template(nameRtFormat typestring string%timegenerated% %syslogtag% %msg%\n) main_queue( queue.typelinkedList queue.size200000 queue.highwatermark150000 queue.lowwatermark20000 queue.maxdiskspace1G queue.filenamert_queue queue.spoolDirectory/var/spool/rsyslog queue.dequeuebatchsize1024 queue.timeoutenqueue3 queue.timeoutshutdown10 queue.timeoutactioncompletion10 )参数含义拆解如下queue.typelinkedList表示用链表内存队列。fixedArray 的固定数组在突发流量时可能提前占满链表在日志量波动大的场景下更灵活代价是每条日志多一点点内存开销。queue.size是队列最大条数上限我按系统内存余量配到 20 万条。以平均每条日志 500 字节计算约占用 100MB 内存这在 16G 内存的工控机上可以接受。队列越大允许的突发缓冲越深但内存占用也随之增长需要按实际硬件来折中。highwatermark和lowwatermark是磁盘辅助队列的启停水位。队列长度达到高水位时rsyslog 开始把后续日志写入磁盘辅助文件降到低水位后停止。这里设置的150000和20000保证大部分时间日志停留在内存队列中只有极端情况才触发磁盘辅助。dequeuebatchsize1024是关键中的关键它控制工作线程一次取出多少条日志再执行写入。默认值较低一次取几十条调到 1024 后写日志的频率大幅降低每次都是顺序批量写磁盘效率明显提升。代价是单批次在队列里的等待时间变长日志到文件的延迟会增加一点。实时场景下我们优先保证任务不卡日志晚几秒落盘完全可接受。timeoutenqueue3表示队列真的满了时入队最多等 3 秒超时就丢弃当前这批日志。这个参数就是那道宁可丢日志也不能卡调用方的保险闸。4.3 action 级队列与 DiskAssist 兜底除了主队列rsyslog 允许给单个动作单独配队列。这个能力在一个重要日志目标拖垮其他所有日志的场景下很有用。比如把远程转发单独隔离出来ruleset(namertlogs) { action( typeomfwd target192.168.10.20 port514 protocoludp queue.typefixedArray queue.size50000 queue.highwatermark40000 queue.lowwatermark5000 queue.dequeuebatchsize512 queue.timeoutenqueue2 queue.maxdiskspace512M queue.filenamefwd_queue ) }如果远程日志服务器慢或者网络抖动这个 action 队列会吸收缓冲不会影响本机其他日志目标的写入节奏。DiskAssist 机制同样重要。配置了queue.filename、queue.spoolDirectory和queue.maxdiskspace后当内存队列持续处于高水位时rsyslog 会把超出部分的日志落盘到 spool 目录防止进程内存耗尽。对实时系统来说这是极端情况下的兜底不是常态路径。4.4 日志到远程omfwd 与本地零落盘组合如果远程日志中心可用最干净的组合是 journald 用 volatile、rsyslog 只负责转发、本机完全不落盘日志文件。这样日志数据永远在内存和网络缓冲区之间流动完全不依赖本地磁盘的 IO 性能。action( typeomfwd targetlog-center.example.internal port6514 protocoltcp templateRtFormat action.resumeRetryCount-1 )resumeRetryCount-1表示断线后无限重连配合队列缓冲保证网络瞬断时日志不丢。这个方案唯一的弱点是依赖网络可靠性适合有专网或稳定数据链路的工业现场。5. 让日志进程让路IO 优先级、挂载参数与调度器协同5.1 用 systemd 把 journald 和 rsyslog 的 IO 优先级压到最低异步队列解决了调用方不被阻塞的问题还没解决日志进程本身抢磁盘带宽的问题。当实时任务的数据盘和日志盘共用同一块物理磁盘时日志进程的高频 IO 会挤占实时数据读写的带宽延长实时任务的 IO 完成时间。Linux 的 ionice 提供了三类 IO 调度优先级realtime最高、best-effort默认、idle最低。日志这种后台任务直接压到 idle 最合适。在 systemd 服务里设置[Service] IOSchedulingClassidle IOSchedulingPriority7 IOWeight1对 rsyslog 和 systemd-journald 都执行systemctl edit systemd-journald systemctl edit rsyslog写入上面的片段后重启服务然后验证systemctl show systemd-journald -p IOSchedulingClass systemctl show rsyslog -p IOSchedulingPriorityIOSchedulingClassidle表示该进程的 IO 请求只在磁盘完全空闲时才会被调度。对于实时任务的数据读写来说日志进程直接变成透明人。IOWeight1是 cgroup v2 的权重值1 是几乎最低档位进一步保证日志 IO 不会和实时 IO 竞争。5.2 文件系统挂载参数降低周期性刷盘频率如果日志最终还是落在本地盘挂载参数能显著影响刷盘行为。以下配置适合日志分区/dev/sdb1 /var/log ext4 noatime,nodiratime,datawriteback,commit120 0 2noatime,nodiratime关闭文件访问时间更新减少元数据写入。datawriteback让文件数据不经过 journal只记录元数据能减少 journal 写入量但崩溃时文件内容可能处于不一致状态这点必须和业务侧确认接受。commit120把文件系统 journal 提交周期从默认 5 秒拉长到 120 秒减少周期性刷盘带来的突刺。如果你对数据一致性要求高坚持用dataordered那至少把commit调大让 journal 提交尽可能聚合。日志文件本来就不是数据库事务日志掉电丢几秒日志通常可以接受但游戏规则要在设计文档里写明白。5.3 块设备调度器日志盘和数据盘要分而治之块设备调度器决定了 IO 请求在设备队列里的排序方式。机械盘用mq-deadline或bfqNVMe 盘通常直接none。查看当前调度器cat /sys/block/sda/queue/scheduler我的建议分三层实时任务的数据盘和日志盘在物理层面分开这是最优解必须共享一块盘时给日志盘设置独立分区并限制 IO 优先级调度器层面机械盘用bfq配合上面设置的 idle 类NVMe 用none即可。物理隔离的意义远大于任何软件参数。实时任务的数据读写和日志刷盘如果落在一块盘上哪怕日志进程是 idle 类磁盘固件内部的处理也会互相干扰。能上两块盘就不共用一块这是架构层面的决策。5.4 实时调度规则与日志进程的关系这里顺带回应一下怎样配置实时 Linux 调度规则这个经常被问到的问题。实时线程用SCHED_FIFO或SCHED_RR只能保证 CPU 不被普通进程抢占但解决不了线程自身陷入 D 状态等待磁盘 IO 的问题。一个实时线程如果发起了fsync()它就处于不可中断睡眠CPU 调度规则再高也没用只能傻等磁盘。所以实时任务里写日志的正确姿势是实时线程绝不直接打开文件写而是把日志塞到内存环形缓冲区或发给 journald由独立的低优先级进程去刷盘。实时调度规则管的是 CPU 资源分配日志架构管的是消除 IO 同步等待两者缺一不可。6. 验证效果用 cyclictest 和 IO 监控对比优化前后6.1 构造一个能复现的日志风暴 实时负载压测环境没有实测数据的优化都是玄学我当时用 cyclictest 模拟实时负载再用脚本灌日志风暴对比前后的延迟分布。压测脚本大概长这样#!/bin/bash # 实时负载1 个线程SCHED_FIFO 优先级 951ms 周期跑 10 万次 cyclictest -t 1 -p 95 -i 1000 -l 100000 -h 400 -m -q /tmp/cyclictest-before.txt # 日志风暴连续往 syslog 写带时间戳的日志模拟业务峰值 for i in $(seq 1 500000); do logger -p user.info rt-noise $i $(date %s%N) done 跑完后让 iostat 在后台记录磁盘状态iostat -x 1 60 /tmp/iostat-before.txt6.2 看延迟直方图和最大值不是看平均值cyclictest 的-h 400会输出延迟直方图。重点关注最大值和 99.9 分位平均值对实时系统没有意义。优化前我测得的最大延迟在 32ms 左右优化后最大值降到 180us 以内效果立竿见影。对比表格大致如下场景平均延迟最大延迟99.9% 延迟基线无日志负载12us38us22us默认配置 日志风暴68us32ms2.4ms优化后 日志风暴15us180us42us这个对比充分说明日志配置不合理时最坏延迟能高出两个数量级而合理的异步化能把日志风暴的影响压回接近基线水平。6.3 看 fsync 频率和块设备排队指标延迟数字之外还要从系统层面确认优化确实生效。用 strace 数 journald 的 fsync 调用次数strace -f -p $(pidof systemd-journald) -e tracefsync -c跑 10 分钟后优化前的 fsync 调用次数可能上百次优化后个位数。同时用iostat -x 1看磁盘的await和%util日志风暴期间优化前的await可能飙升到几十毫秒优化后保持稳定低值。rsyslog 队列状态也可以直接监控/usr/sbin/rsyslogd -Q或者看/var/log/syslog里是否出现队列满的告警。实际调试中我会把queue.size临时调小来制造告警验证timeoutenqueue确实生效确认极端情况下系统不会卡死。6.4 长稳测试才是硬通货日志和 IO 的干扰有一个特点不频繁但一旦发生就是大坑。单次测试可能刚好没踩到 logrotate、刚好没遇到 SSD 垃圾回收所以必须长时间跑。我建议至少 8 小时连续测试中间人为触发几次 logrotate、journal 文件轮转和磁盘写入压力再统计全程最大延迟。很多优化完很稳的方案就是倒在 4 小时后的那次 logrotate 上的。把 logrotate 时间错开实时任务高峰期或者干脆在低峰期执行也是很实用的手段。7. 容易忽略的坑限流、audit、队列超时7.1 journald rate limit 静默丢日志journald 默认的RateLimitIntervalSec30s和RateLimitBurst10000在日志量瞬时飙升时会触发限流超出的日志被静默丢弃应用层完全感知不到。实时任务的日志往往就是突发式的开机自检、故障录波、控制事件都可能瞬间产生大量日志。建议把 burst 调到业务峰值的两倍以上同时用 tcpdump 或导出的日志对比确认没有静默丢失。7.2 auditd 和 logrotate 是另一个隐藏刷盘者很多人只盯着 journald 和 rsyslog忽略了 auditd。内核审计模块如果配置不当在日志风暴期间触发审计事件auditd 的 backlog 会被打满进而影响系统调用性能。如果实时任务系统不需要审计功能直接关掉审计服务是干净的方案必须保留的话把 backlog 调大并限制max_log_file的触发动作。logrotate 的问题前面提过再补充一点确保日志文件的轮转时间不和实时任务的周期任务重叠可以用cron配到凌晨低峰或者在 systemd timer 里加随机延迟避免所有服务同时触发轮转造成 IO 峰值叠加。7.3 队列参数别盲调内存、出队延迟和丢日志窗口异步队列的参数是互相牵扯的。queue.size调大带来更长的事件延迟——日志在队列里等得越久落盘时间越晚dequeuebatchsize调大提升吞吐但也会让日志在队列里积累更多timeoutenqueue调大增加了阻塞容忍度却违背了绝不卡调用方的初衷。我的参数设计逻辑是先定业务可接受的日志最大延迟比如 10 秒内必须落盘或转发再按日志峰值速率算队列深度最后按硬件内存余量定queue.size。日志这种数据宁可丢也不能让它卡住实时控制回路。把这句话写进团队的设计评审文档比任何参数都重要。7.4 实时系统的日志哲学该丢就丢但要知道丢了什么做实时系统时间长了对日志的态度会从一条都不能丢变成允许丢但要有监控告诉我是谁丢了。异步队列、内存缓冲、限流策略本质都是在延迟、可靠性、资源消耗之间做折中。日志异步化之后必须配套可观测性队列长度、丢弃计数、落盘延迟这些指标要暴露出来不然就是蒙着眼睛做优化。我的最终配置在这个思路上落地实时任务的日志路径上没有任何同步磁盘等待journald 是内存缓冲rsyslog 是批量消费者IO 优先级最低磁盘物理隔离。跑了一个月下来实时任务的最坏延迟始终稳定在预算以内日志也一条不落地到了远程日志中心。最后再给一个小技巧调完参数后把/etc/systemd/journald.conf和/etc/rsyslog.conf的差异保存下来放进版本管理同时在部署文档里写明为什么这些参数要这样配。等三个月后你自己回来看配置会发现当初的决策记录比任何运维文档都值钱。