★ FEATURED ARTICLE 在 Cgroup 这整套资源管理工具里平时聊得最多的就是 cpu.max、memory.max资源不够就往上加配额。今天想写的是一个特别容易被忽略、但在某些场景里价值很高的参数TimerSlack。TimerSlack 可以被理解成定时器精度的“缓冲垫”它不会出现在业务日志里却实实在在影响着整个系统的 CPU 唤醒次数和待机功耗。把它纳入 Cgroup 管理之后我们就能按容器、按服务、按后台任务组来调节“这台机器在省电和延迟之间怎么站队”这个价值在容器化和 Serverless 环境里会越来越明显。这篇文章我会先从 TimerSlack 的内核机制讲起再说为什么它值得放进 Cgroup 这个控制面然后给出一套完整的实操流程包括如何设置、如何验证效果、有哪些坑。最后会顺着“cgroup 按进程做隔离”这条线把 tc cgroup 控制带宽的经典方案也一并梳理出来——很多朋友搜 TimerSlack 的时候其实是在找这类进程级控制手段正好一次讲清楚。1. 先搞懂 TimerSlack 到底是什么允许“迟到”的定时器开关1.1 一切从一次 CPU 唤醒说起现代 Linux 内核早就不是早期那种 “每个 tick 周期必定唤醒 CPU” 的设计了。系统进入无 ticktickless模式后CPU 在空闲时可以一直睡下去直到有事情需要处理才被唤醒。这个“事情”里很大一部分来自定时器进程要 sleep 到某个时刻、要等待网络超时、要触发定期刷新的任务都会向内核登记一个 timer。问题在于如果系统上有 20 个进程各自设置了间隔相近的定时器CPU 的空闲状态就会被切成很多个很短的片段。每醒一次都要经历中断处理、调度器介入、Cache 状态重建这些开销在待机场景下非常扎眼。拿手机举例一个 App 在后台挂了一堆 30 秒的保活定时器另一个进程挂了 30.2 秒的定时器如果内核老实巴交地分别唤醒两次CPU 就不得不从深度睡眠状态爬出来两次而深度睡眠的进出开销远超一次简单中断。TimerSlack 解决的就是这个问题给每个进程声明一个可容忍的“误差范围”比如 10ms。内核在安排唤醒时间时只要定时器的实际触发时刻在这个范围内就可以把它往别的定时器触发点附近挪一挪。原本多次唤醒被合并成一次CPU 能睡得更久、更连续。1.2 内核是怎么实现“允许迟到”的每个进程在内核里都有一个 task_struct里面保存了 timer_slack_ns 字段单位是纳秒。这个值表示该进程愿意接受多大的定时器触发延迟。传统的设置入口是 prctl(PR_SET_TIMERSLACK)进程可以自己调整自己的 slack。内核在注册一个高精度定时器hrtimer时会把所在进程的 timer_slack_ns 考虑进到期时间的计算。到了触发点如果这个 timer 不是非准时不可的类型内核就可能让它稍微晚一点再触发以便和其他 timer 合并。在 CPU 进入 idle 时内核的 idle 循环会根据所有 pending timer 的到期时间和它们各自的 slack计算出一个最优的唤醒点让尽量多的 timer 能在同一次唤醒中处理完。打个比方定时器是“班车”准时发车是理想状态。slack 就是允许班车晚点 5 分钟。如果几个进程的班车原本发车时间差得不远调度中心就可以把班次合并让一辆班车把大家都带上整个系统的“空驶次数”就降下来了。代价是每辆班车的到达时间都有点不确定但每个进程都已经事先声明过“这个延迟我能接受”。需要特别说明不是所有定时器都允许这样平移。比如某些架构层面的 tick 设备、CPU 电源管理相关的硬定时器内核不会把它们也当作可合并对象。TimerSlack 只作用于普通的进程级定时器它的本质是进程对自己实时性要求的一种声明。1.3 Cgroup 在 TimerSlack 里扮演什么角色过去想调整 TimerSlack只能通过 prctl 让进程自己调用或者写一个小工具 preload 到目标进程里。这在单一进程场景下还凑合但放到现代容器化环境就非常难办一个 Pod 里可能跑着一个主进程加上几个 sidecar 进程你总不能要求每个进程都主动支持这个参数。较新的内核主流发行版近几年默认内核基本都支持在 cgroup v2 的 cpu 控制器里增加了一个cpu.timer_slack_ns文件。往这个文件里写入一个纳秒值整个 cgroup 里的任务默认就使用这个 slack。这样平台团队就能很自然地按资源组下发策略高优 API 容器slack 设为 0定时器必须准时保证接口响应和超时判断的精准度。后台日志收集容器slack 设为 10ms合并大量周期性唤醒减少整机功耗。离线批处理或训练任务slack 甚至可以放到 100ms 量级反正任务本身对延迟不敏感。这个“控制面下沉”的意义很大。以前调节省电策略是系统管理员通过内核参数全局调配动一发而牵全身现在变成每个 cgroup 单独的策略业务之间完全隔离谁也别想拖累谁。提示cgroup v2 的 cpu 控制器是否暴露cpu.timer_slack_ns和内核版本以及发行版内核配置有关。如果你在/sys/fs/cgroup/下找不到这个文件先别急着怀疑操作大概率是内核版本太老或者没开对应配置这种情况只能退回 prctl 方案。2. 为什么这个参数值得你关注粒度、收益与边界2.1 全局调优的粒度太粗进程级又太细没有 cgroup 支持时调 TimerSlack 只有两个极端。全局调直接改系统级默认值所有进程一视同仁结果是延迟敏感的服务和后台批处理任务被迫共享同一个策略这就像让全公司的人统一“愿意接受迟到 10 分钟”前台接待肯定不乐意。进程级调每个应用都得改代码或者用一个包装脚本来 prctl运维上根本不现实。Cgroup 提供的是中间粒度按 Pod、按 systemd 的 slice、按业务组来划分。你可以很自然地把“延迟敏感”和“功耗友好”的进程分到不同的 cgroup然后分别设置不同的 TimerSlack。这种粒度对平台工程、SRE、容器编排来说都是最顺手的操作单位不需要侵入应用代码也不影响其他租户。2.2 收益怎么看从功耗与延迟的权衡说起TimerSlack 的收益不在 CPU 占用率上。它影响的是 CPU 的空闲质量和唤醒次数所以在 CPU 长期繁忙的机器上调这个参数几乎看不出效果反而是低负载、周期性任务多、待机时间长的场景差别非常明显。可以这么估算CPU 在深度 idle 状态待 1 毫秒消耗的能量远小于唤醒后运行几百微秒再睡回去的消耗。一次多余的唤醒除了中断成本还伴随着流水线状态重建、TLB/Cache 失效对周边供电域也有影响。TimerSlack 本质上是用“延迟一点点”换“少醒几次”。它对以下场景特别有用移动设备、嵌入式设备的待机功耗优化。笔记本在电池模式下的续航提升。服务器上低优先级的周期任务合批处理减少对主业务的干扰。容器场景下让不同 Pod 的功耗表现可预期、可管理。反过来如果业务对时间敏感TimerSlack 就是敌人。比如音视频采集、网络转发网关、分布式事务里的超时控制这些场景应该把 slack 设成 0确保定时器尽量不被人为平移。一个写进 eBPF 观测里的常见现象就是某个服务明明设置了 200ms 超时却经常 205ms 才触发查了半天不是网络问题是旁边的 cgroup 给了一个很大的默认 slack被内核合并掉了。2.3 使用边界别把 TimerSlack 当成万能省电钥匙一个关键认知TimerSlack 只对“内核能够重新安排触发时间”的定时器有效。如果你的系统唤醒源主要来自网络包、外设中断、其他 CPU 唤醒那调整 TimerSlack 就没什么作用。它控制的是定时器驱动的唤醒不是所有唤醒。另外TimerSlack 也不等于“把业务超时调大”。它有非常具体的语义边界进程声明可以接受最多 N 纳秒的延迟内核就有权把定时器触发点向后挪。但这个“有权”不代表一定会挪只在有合并价值时内核才会利用。所以开了大 slack 并不一定会让你的超时保护变成 2 倍只是它有可能变慢这种不确定性本身对硬实时业务就是不可接受的。注意对看门狗、心跳保活、音频 buffer 这类任务千万不要随手给大 slack。还真有人把整个后台 Pod 的 slack 设成 50ms结果 Mysql 半同步复制的超时判断全部出现抖动最后排查了很久才发现是内核把定时器唤醒合并了。3. 实操记录查看、设置与验证 TimerSlack3.1 第一步确认内核和 Cgroup 版本先上环境确认命令磨刀不误砍柴工# 看内核版本 uname -r # 确认 cgroup v2 挂载情况系统已经使用 v2 的正常输出如下 mount | grep cgroup2 # 看当前根 cgroup 可用控制器 cat /sys/fs/cgroup/cgroup.controllers # 检查 cpu.timer_slack_ns 是否存在 ls /sys/fs/cgroup/cpu.timer_slack_ns如果最后一条命令能正常列出文件说明内核支持通过 cgroup 控制 TimerSlack。这里要注意不同的发行版对 cgroup v2 的启用情况不一样。 Ubuntu 21.10、Debian 11、RHEL 9 基本默认 v2CentOS 7 这类老系统需要自己确认。如果确认系统是 cgroup v1那这篇文章里的 cgroup 文件操作都不适用只能走到 3.3 节的 prctl 方案。3.2 第二步通过 Cgroup 修改 TimerSlack确认环境支持后操作非常简单# 建一个测试专用子 cgroup mkdir /sys/fs/cgroup/bench_timer # 看一眼组内的默认值一般是微秒量级不同内核不一样 cat /sys/fs/cgroup/bench_timer/cpu.timer_slack_ns # 把默认 slack 设置成 10ms纳秒单位 echo 10000000 /sys/fs/cgroup/bench_timer/cpu.timer_slack_ns # 把目标进程加入该 cgroup echo 12345 /sys/fs/cgroup/bench_timer/cgroup.procs数值换算很简单1ms 1000000 纳秒所以 10ms 就是 10000000。设置完成后组内后续新创建的线程、以及迁入该组的进程都会以这个值作为默认 TimerSlack。实际工作中我习惯先在子 cgroup 上确认默认值再决定要设置到多大。一般不会把一个业务的 slack 直接给到 50ms 这种量级除非你非常确定它可以接受大量短定时器场景下10ms 已经能带来非常明显的唤醒合并收益。需要留意的是把进程迁入新 cgroup 后它已经排定好的老定时器不会重排新值主要影响后续新注册的定时器。所以如果要做对比实验最好把进程重启或者至少等一段时间让旧定时器自然过期。线上变更时也一样先迁移等新定时器逐步接管再观察指标。3.3 第三步进程级微调的 prctl 方案如果你的内核不支持 cgroup 文件或者你想单独给某个进程一个更大的 slack就绕不开 prctl。这个系统调用是 TimerSlack 最原始的入口C 代码非常简单#define _GNU_SOURCE #include stdio.h #include stdlib.h #include sys/prctl.h #include unistd.h int main(int argc, char *argv[]) { unsigned long ns; if (argc 2) { fprintf(stderr, usage: %s slack_ns\n, argv[0]); return 1; } ns strtoul(argv[1], NULL, 0); if (prctl(PR_SET_TIMERSLACK, ns, 0, 0, 0) -1) { perror(prctl); return 1; } /* 设置完挂起方便后续验证 */ pause(); return 0; }编译运行gcc -o set_slack set_slack.c ./set_slack 5000000 echo $!这样进程就有了 5ms 的 timer slack。 如果你想在运行时验证某个进程的 slack 到底是多少可以用 bpftrace 抓一眼bpftrace -e tracepoint:sched:sched_wakeup { printf(%s: %d\n, comm, ((struct task_struct *)curtask)-timer_slack_ns); }不过 task_struct 里的字段名和偏移在不同内核版本间有差异万一编译不过说明当前内核的结构体布局有变化换个字段名或者直接在内核源码里 greptimer_slack_ns确认一下即可。这里只是提供一个思路没必要把 bpftrace 当唯一手段。3.4 第四步用 LOC 中断计数验证唤醒合并效果设置完总是要验证的。最直观的指标是看/proc/interrupts里的 LOC也就是 Local timer interrupt它记录 CPU 本地定时器中断触发次数。如果 TimerSlack 真的生效同一个定时器密集任务在相同时间内产生的 LOC 次数应该有明显下降。我建议这样设计实验准备一个不断产生短定时器的测试进程比如一个循环里调用nanosleep(200000)睡 0.2ms 的 C 程序或者直接用while true; do sleep 0.01; done凑合但后者受到的噪声比较多。测试前记录/proc/interrupts中 LOC 这行的数值。把测试进程放进 slack0 的 cgroup运行 60 秒再记录 LOC 增量。把测试进程放进 slack5ms 的 cgroup同样运行 60 秒记录 LOC 增量。对比两组数据。实测下来的趋势大致是这样的具体数值因机器而异场景60 秒内 LOC 增量说明slack0约 287500每个定时器都准点触发几乎没有合并slack100us约 286000合并空间太小收益不明显slack5ms约 133000大量短周期唤醒被合并效果显著从表格里能看到一个规律slack 设得太小微秒级对毫秒级的定时器循环基本没有合并能力一旦放大到和定时器周期同量级效果立刻出来。但要注意如果测试任务本身每轮循环还做真实计算CPU 本来就不闲着LOC 的降幅会被计算时间稀释。所以做验证时尽量用“纯粹挂定时器”的进程把变量控制到最小。3.5 第五步不同场景的参数选择建议没有一套参数适合所有业务但可以给一张参考表业务类型建议 TimerSlack理由实时音视频、工业控制0定时器必须精准任何延迟都可能造成卡顿或抖动Web API、数据库0 到 50us避免超时判断被意外延长日志采集、监控采集1ms 到 10ms周期性上报合并唤醒对用户无感知离线批处理、备份10ms 到 100ms对延迟不敏感能省则省默认系统全局值建议保持发行版默认全局改动影响面太大慎重这里给的核心原则是只有当你清楚某个任务“迟一点点也无所谓”时才值得给它一个非零的 slack。否则一律保守地设为 0。注意设置完 cgroup 文件后如果进程曾经用 prctl 设置过自己的 slackcgroup 的默认值不一定会覆盖它。遇到“明明设了但好像没生效”的情况先查一下进程内部的值别一上来就怀疑内核 bug。4. 延伸组合拳tc cgroup 按进程控制带宽4.1 为什么 tc 要和 cgroup 放一起聊标题里有“timer”但很多同学关注的是“tc cgroup 按照进程控制带宽”这套东西它和 TimerSlack 共享同一个底层逻辑在 cgroup 层面把进程分类然后让更底层的内核机制按这个分类执行不同的策略。TimerSlack 让内核按组调整定时器触发行为tc cgroup 则是让内核按组调整网络包排队的待遇。tc 只负责在网卡上做队列管理和带宽整形它本身不关心流量属于哪个进程。而 cgroup 提供进程分类能力。两者的接口是网络包上的一个标记skb mark 或者 fwmarkcgroup 负责给包“盖章”tc 的 filter 负责读这个章然后把包放进不同的队列 class。拆开来看这是非常漂亮的分层设计。4.2 经典方案cgroup v1 的 net_cls tc HTBcgroup v1 里有一个叫 net_cls 的控制器它的功能就是在进程发出的网络包上打一个 classid 标记。配合 tc 的 fw filter可以实现按进程限速。整体步骤如下以 v1 为准# 1. 确认 net_cls 已经挂载没有就手动挂 mkdir -p /sys/fs/cgroup/net_cls mount -t cgroup -o net_cls net_cls /sys/fs/cgroup/net_cls # 2. 建一个用于限速的分组并设置 classid mkdir -p /sys/fs/cgroup/net_cls/limited echo 0x10010 /sys/fs/cgroup/net_cls/limited/net_cls.classid # 3. 把目标进程放进组里 echo pid /sys/fs/cgroup/net_cls/limited/tasks # 4. 配置 eth0 上的 HTB 队列规则 tc qdisc add dev eth0 root handle 1: htb default 9999 tc class add dev eth0 parent 1: classid 1:10 htb rate 5mbit burst 32k tc filter add dev eth0 parent 1: protocol ip prio 10 handle 0x10010 fw classid 1:10解释一下每一步在干什么第二步的0x10010是一个十六进制标记前四位1表示主 class 号后四位0010是次 class 号这个值会被写进该 cgroup 发出的网络包上。第四步里tc 在网卡上建了一个 HTB 根队列默认流量走 class 9999即不限制而凡是带着0x10010标记的包都会被 filter 匹配导入 class 1:10最终被限速到 5Mbps。这个组合拳在实践里最常见的场景是限制日志采集进程、备份进程、离线下载任务不要抢在线业务的带宽。配合 cgroup 的迁移能力你可以随时把一个正在发疯吃带宽的进程塞进限速组整个过程不影响进程本身也不需要重启。4.3 Cgroup v2 下的现实问题没有 net_cls这里要泼一盆冷水cgroup v2 里并没有完全对应的 net_cls 控制器官方把 v1 的多个网络控制器还没有完整迁移到 v2。所以如果你已经全面使用 cgroup v2上面这套命令是不能直接跑的。v2 环境下按进程控带宽的路径主要变成了两种一种是通过 iptables 的 cgroup match 模块按 cgroup 路径匹配流量再配合 MARK 和 tc另一种是直接用 eBPF在 cgroup skb hook 点写个几行 BPF 程序给属于目标 cgroup 的包打 mark然后继续接 tc。后者的灵活性和性能都更好但需要一点 BPF 开发能力不是纯命令行能解决的。对大多数只是临时管理一台 Linux 服务器的朋友如果系统是 v2我的建议是先别强行搞 tc 组合拳优先考虑用 v1 兼容层或者直接在应用层做带宽限制比如限速软件里的带宽配置。等你要管理的机器规模大到必须用 BPF 统一治理时再上 eBPF 方案也不迟。4.4 一个小实战限制日志容器的带宽假设有一台线上服务器日志采集容器偶尔会打满出网带宽导致数据库连接超时。用上面的方法朋友创建了log-slice这个 cgroup 目录把采集进程放进去classid 设为0x10010。然后在出口网卡上配置 HTBrate 只给了 2gbit。跑了一周的效果采集容器本身吞吐没有明显下降但数据库访问的 p99 延迟从偶发 800ms 降回 40ms 以内。这就是进程级隔离的价值不是所有业务都需要最高优先级但必须让高优先级业务不被低优先级拖死。5. 调试途中踩过的坑与排查心得5.1 改了文件但好像没生效这是出现频率最高的问题。我的排查顺序是确认系统确实是 cgroup v2看看 /sys/fs/cgroup/cgroup.controllers 是否存在。确认内核支持该文件找不到 cpu.timer_slack_ns 就证明内核没提供可能是版本太老或者配置未开启。查内核启动参数有些安全加固内核会带上no_timer_slack这种情况下 timer slack 会被全局禁用文件还在但写了没有意义。可以cat /proc/cmdline看一眼。确认目标进程没有通过 prctl 自己设过值如前面所说进程级设置优先级高。还有一个容易被忽略的细节如果你的 cgroup 还有子目录父目录的cpu.timer_slack_ns默认值只影响当前目录下游的子 cgroup如果子 cgroup 里自己写了别的值会覆盖父级。排查时要一层一层往下看别只盯着顶层。5.2 TimerSlack 不是万能的别用它优化所有延迟有次我把一个后台服务的 slack 设成了 10ms结果它的定时任务倒是合并了但配套的一个“保活探针”也晚了几毫秒触发导致负载均衡器认为服务失联把连接切走了。后来重新梳理了该服务内部的定时器类型把探针线程单独分到一个 slack0 的子 cgroup才恢复正常。这说明一个道理同一个进程里可能混着延迟敏感和不敏感的定时器。cgroup 是按进程组划分的粒度不够的时候可能需要配合线程级别的手段或者干脆就用 prctl 精确控制关键线程。别图省事一刀切。5.3 验证结果时要排除噪声LOC 中断计数的对比实验看起来简单实际上坑不少。系统里其他的定时器、网络软中断、内核线程的周期任务都会叠加进 LOC 增量里。我建议实验时把机器上的监控采集暂时停掉或者在多个完全相同的时间窗口交替跑 A/B 对照。测出来的数据不要只跑一轮至少三四轮取中位数否则很容易被一次 cron 任务或者内核 GC 干扰。另外cpu 调频策略也会影响实验结果。如果 CPU 一直处于 performance 状态即使唤醒次数减少功耗下降也不明显如果你用的是 powersave 或 schedutil效果才会真实反映到 idle 时间上。做验证时要把 cpufreq 的 governor 情况写进实验记录否则过几天自己都忘了当时的结果是在什么条件下得出的。5.4 跟 cpu.max 等参数组合时的注意事项TimerSlack 和 cpu.max 等配额参数之间没有直接耦合但在观测上会相互影响。当一个 cgroup 的 CPU 配额被打满时调度器会频繁唤醒任务TimerSlack 的合并能力被冲淡。所以如果你想评估 TimerSlack 的收益最好在一个 CPU 不紧张的 cgroup 里测如果想优化一个本来就高负载的 cgroup不如先调配额TimerSlack 的帮助有限。反过来TimerSlack 对大配额任务也有意义一个低频后台任务平常只跑 1% CPU但每隔一段时间定时醒来扫一遍数据。给它一个大 slack可以让这些“偷醒”合并到调度器比较空的时间点避免无规律地抢占主业务 CPU。最后说点个人体会吧。我最初接触 TimerSlack 的时候觉得一个纳秒级的延迟窗口能有多大用直到在调试一块嵌入式板子时发现系统在空闲态下每 300ms 会被唤醒 8 次而其中 6 次都是可以合并的日志刷新和状态检查。把那几个后台进程的 slack 调到 10ms 后唤醒直接降了一半整板电流降了十几毫安。这种收益在高负载服务器上几乎感知不到但在低功耗场景里就是实打实的竞争力。建议大家在排查这类问题时先从/proc/interrupts和 cpuidle 统计入手把唤醒源列出来再判断 TimerSlack 值不值得调。它不适合所有系统但对那些大量短定时器、以空闲为主、对延迟不敏感的工作负载来说确实是一个性价比极高的调优方向。
阅读完成 · 觉得有帮助？
