上个月我在排查一个生产问题的时候被一条看似人畜无害的systemd命令整得相当狼狈。宿主机上几个Java容器跑得好好的突然开始CPU告警容器里的线程像约好了一样疯狂抢占核资源top里看CPU使用率节节攀升业务量却纹丝不动。折腾了两天最后定位到根因有人顺手执行了一条systemctl set-property把容器所在cgroup父节点的CPU集合收窄了容器原有的CPU绑核配置被内核按父级范围重新计算绑核直接错乱。今天把这条线完整拆开讲清楚希望同样被systemd和容器绑核问题折腾的人少走点弯路。文章会覆盖现象、cgroup v2的cpuset底层层逻辑、systemd命令为什么能“越权”改容器CPU归属、完整的复现步骤以及我最后沉淀下来的排查和规避手段。不管你是运维、SRE还是偶尔需要碰容器的后端开发这套知识都值得收藏。1. 先从事故现场说起一条命令引发的“CPU打架”1.1 诡异的现象业务没涨CPU却炸了那台机器是双路物理机上面用Docker跑了几个无状态Java服务。我们当时给核心服务做了绑核处理intended让某个容器固定在逻辑核4到7上用来避开宿主机上其他高负载业务和系统进程的干扰。这个方案跑了一个多月一直很平稳。出事那天下午监控开始告警。容器CPU使用率从平时的30%左右一路冲到90%以上RT从20ms飙升到300ms。我第一时间去看了业务指标请求量没涨、错误率没涨、数据库连接数也没涨。这就很反常了流量没变CPU为什么会突然爆掉更怪的是mpstat的输出。绑核后本来只应该负载集中在4-7号核上可现场看到的是4-5号核已经打满6-7号核反而有一搭没一搭地跑0-3号核上也开始出现不少用户态负载。容器里的进程明显不在自己该待的CPU上四处流窜。1.2 一开始的排查方向全跑偏了这种“性能无端恶化”的问题第一反应肯定是看应用层。我先扎进JVM日志看GCFull GC频率没有异常变化怀疑锁竞争但线程dump看下来业务锁的阻塞队列并没有明显堆积又怀疑是网络层重传检查了丢包率和TCP重传计数都正常。接着我用perf去抓容器内进程的调度行为看到了大量reschedule IPI和迁移事件。一个进程频繁从一个核被踢到另一个核每次迁移都伴随cache miss、TLB flush线程间的同步开销成倍增加。到这里我才隐约觉得问题出在CPU的分配逻辑上而不是应用本身。把视角从应用挪到宿主机后我用systemd-cgtop扫了一眼cgroup视图立刻发现了异常容器所在的cgroup节点实际生效的CPU集合effective_cpus只剩4-5而我记忆里配置的明明是4-7。一个核的集合硬生生被砍掉了一半所有线程挤在两个核上抢时间片这就是“CPU打架”的直接原因。2. systemd和容器之间到底谁该管CPU绑核2.1 容器在systemd的cgroup树里就是“上下级”大多数现代Linux发行版里systemd不只是1号进程它同时还是cgroup的主要管理者。在cgroup v2模式下系统根目录下的整棵cgroup树都是systemd在维护常见的system.slice、user.slice、machine.slice这些顶层节点全部归systemd管。Docker、containerd这些容器运行时本质上也依赖cgroup来约束容器资源。它们创建的容器scope会作为叶子节点挂到systemd管理的树上。比如当Docker配置使用systemd cgroup driver时一个容器的cgroup路径通常是这样的/sys/fs/cgroup/system.slice/docker-容器ID.scope也就是说systemd和容器运行时管理的是同一棵树。systemd管理的是树的主干和主要分支容器运行时管理的是某个分支下面的叶子。平时两者井水不犯河水可一旦有人用手动方式去操作树上的某个非叶子节点容器叶子立刻就会受到影响。2.2 cgroup v2的cpuset父级收窄实际生效集合跟着缩水cgroup v2的cpuset控制器和v1有一个非常大的区别v2里引入了两个不同的概念一个叫cpuset.cpus一个叫cpuset.effective_cpus。cpuset.cpus是“这个cgroup想用哪些核”你可以把它理解成请求值。cpuset.effective_cpus是“内核最终决定让这个cgroup用哪些核”它是实际生效值。v2的内核会强制保证任意一个cgroup的实际生效CPU集合必须是它父节点的实际生效CPU集合的子集。这个设计本意是好的避免子cgroup用到父cgroup根本不允许的CPU。但它带来一个副作用如果父节点的有效集合被收窄子节点即便在自己的cpuset.cpus文件里写着“4-7”实际可用集合也会自动和父节点的范围求交集变成“4-5”甚至空集。很多操作者只盯着cpuset.cpus看完全忽略cpuset.effective_cpus于是根本想不明白为什么容器绑核会悄悄失效。2.3 Delegate机制谁来动这棵子树的“产权”systemd知道自己管不了所有cgroup细节所以设计了Delegate机制。如果一个unit设置了Delegateyessystemd就把这棵子树“让渡”给里面的程序自己管理默认不会去动子树内部的cgroup属性。Docker服务本身一般是有Delegate的所以systemd不会挨个去改Docker创建的容器cgroup。但这里有个关键漏洞Delegate只保护了docker.service这棵子树内部容器的上级节点是system.slice而system.slice不是Docker的领地。它是systemd直接管理的顶层slice。执行systemctl set-property system.slice AllowedCPUs...的时候systemd完全有权修改这个节点修改结果又会顺着cgroup树传导到下面的所有容器。换句话说容器运行时的绑定只是“局部安排”systemd对上级slice的配置才是“全局规划”。全局规划一变局部安排瞬间作废。3. 根因深挖一条systemd命令如何“越权”改写容器绑核3.1 systemctl set-property对CPU集合做了什么systemd给运维提供了一个非常方便的属性设置入口systemctl set-property。它可以动态调整一个unit的CPU、内存、IO等限制其中和CPU绑核直接相关的属性叫AllowedCPUs。执行下面的命令时sudo systemctl set-property system.slice AllowedCPUs0-5systemd会做两件事先把磁盘上的持久化配置写成drop-in文件再立刻把当前运行中的cgroup节点属性更新掉。最终落在内核cgroup文件系统上就是/sys/fs/cgroup/system.slice/cpuset.cpus的内容变成了“0-5”。这个命令还有个隐藏特点它会持久化。你执行一次重启之后依然生效除非手动撤销。很多人以为它和临时改一下sysctl差不多重启就恢复原样这是个致命误解。到这里受害者链条已经完整了systemd把system.slice的CPU集合从默认的“0-7”收窄到“0-5”容器的cgroup作为system.slice的子节点实际生效集合自动变成自身请求“4-7”和父级有效集合“0-5”的交集也就是“4-5”。绑核范围从4个核缩小到2个核大量线程被塞进两个核里疯狂竞争。3.2 交点被吃掉一场典型的CPU资源争夺战当一个cgroup的实际生效CPU集合被压缩后内核调度器会做什么它会尝试把该cgroup内所有线程迁到新的合法CPU集合上。这个迁移不是一次性完成的而是一批一批进行的。在迁移过程中会出现几种典型的性能恶化现象第一迁移风暴。线程在不同CPU之间反复挪动每次迁移都要发送内部处理器中断IPI被迁移的线程cache是冷的首次访问内存全是cache miss。多线程程序在这种状态下同步原语的开销会暴涨。第二核间争抢。原本4个核平均分摊线程现在全压到2个核上。线程数不变核数减半每个核上的运行队列长度直接翻倍。时间片轮转频率变快上下文切换次数呈指数级上升CPU的有效利用率反而下降。第三锁抖动。Java这类多线程应用里锁非常密集。锁竞争本身已经很伤再加上抢锁的线程被频繁迁移锁的cache line在CPU之间来回弹等待时间被放大。top里CPU使用率飙升的背后其实有相当大比例是在空转和等待。3.3 另一个容易被忽略的入口systemd-run临时scope除了set-property我还踩过另一个坑systemd-run。它可以在当前cgroup树里创建一个临时scope来运行命令并且同样支持-p AllowedCPUs...参数。例如启动一个压测进程并限制它到2-3号核sudo systemd-run --scope -p AllowedCPUs2-3 stress-ng --cpu 4问题在于systemd-run创建的temporary scope默认会挂在当前用户对应的slice下如果这个slice恰好和容器所在的system.slice有层级关系或者你显式指定了--slicesystem.slice那它同样会改写system.slice节点上的cpuset属性和3.1里的set-property殊途同归。更隐蔽的是有些systemd-tailored服务脚本会在启动时执行类似systemd-run --scope的逻辑意图是给某个子进程做资源隔离但操作对象选错了层级结果把整棵子树都带偏了。3.4 容器里如果是Java破坏力还会被放大为什么这次事故里Java服务受害最明显JVM对CPU数量是有“记忆”的。从JDK 8u191开始JVM默认开启UseContainerSupport启动时会根据容器可用的CPU数量来初始化并行线程池、GC线程数、ForkJoinPool的commonPool大小。但JVM只在启动时做一次探测。如果容器启动时看到的CPU集合是4-7JVM就会按照4个可用来配置线程池。一旦运行过程中cpuset被systemd收窄成4-5JVM内部线程池大小不会跟着自动调整还是原来的规模。原本4个核的线程配置现在只让跑2个核线程之间疯狂排队GC线程和业务线程互相挤占整个进程的响应能力直接崩盘。这提醒我们一个事如果容器里跑的是JVM、Node.js这些对CPU核数敏感的运行时有绑核错乱带来的后果会被运行时自身的缓存配置进一步放大。监控告警如果只看容器CPU使用率很容易被误导。4. 实操复现在测试环境里复刻一次“CPU打架”4.1 准备一套可复现的实验环境光讲理论没有体验我强烈建议你在测试机上手敲一遍。环境要求并不复杂一台装了systemd的Linux机器建议Ubuntu 22.04或CentOS Stream 9确认cgroup是v2然后装好Docker并确认Docker的cgroup driver用的是systemd。cgroup版本可以这样验证stat -fc %T /sys/fs/cgroup如果输出是cgroup2fs那就是cgroup v2。再看Docker的driverdocker info | grep -i cgroup我的测试机输出是Cgroup Driver: systemd这是现在主流发行版上很常见的配置。4.2 容器正常绑核时应该看到什么启动一个容器并让CPU绑到4-7号核。为了后续方便压测我在容器里装了stress-ngdocker run -it --cpuset-cpus 4-7 ubuntu:22.04 bash apt-get update apt-get install -y stress-ng此时在宿主机上找到容器主进程PIDdocker inspect -f {{.State.Pid}} 容器名 taskset -pc PID正常情况下的输出应该是PID 12345s current affinity list: 4-7再看容器cgroup下的两个关键文件。路径可能是/sys/fs/cgroup/system.slice/docker-ID.scope也可能在不同发行版上略有差异用systemd-cgls可以方便地确认cat /sys/fs/cgroup/system.slice/docker-ID.scope/cpuset.cpus cat /sys/fs/cgroup/system.slice/docker-ID.scope/cpuset.effective_cpus稳定状态下两个文件输出的都是4-7。请求值和实际生效值一致一切都好。4.3 执行systemd命令观察绑核如何错乱现在进入事故现场的核心动作在宿主机上执行sudo systemctl set-property system.slice AllowedCPUs0-5这条命令把system.slice这个父级节点的CPU集合收窄到了0-5。执行之后不要急着看cpuset.cpus它很可能仍然是4-7因为容器运行时之前设置的请求值还在。真正发生变化的是cat /sys/fs/cgroup/system.slice/docker-ID.scope/cpuset.effective_cpus输出变成了4-5。原因就是内核自动做了父级有效集合和子级请求集合的交集计算{0-5} ∩ {4-7} {4-5}。再看容器进程的实际亲和性taskset -pc PID输出同样变成了4-5。你已经成功复刻了一次绑核错乱配置上写着4-7实际运行在4-5。4.4 用taskset和perf坐实“CPU打架”光看到affinity变了还不够我建议顺手把性能恶化也复现出来。容器里跑8个CPU密集型任务让线程数量大于可用核数stress-ng --cpu 8 --timeout 60同时在宿主机上用mpstat观察mpstat -P ALL 1你会看到4号和5号核的%user飙到接近100%6号和7号核闲置0-3号核也可能因为迁移产生少量负载。各核负载严重不均run queue拉长上下文切换计数器暴涨。如果还想看到进程迁移的实锤可以用perf的sched子命令抓一小段调度事件perf sched record sleep 5 perf sched latency输出里会清晰列出大量迁移事件就是因为线程被反复从一个核挪到另一个核导致的。到这一步“CPU打架”已经从抽象概念变成了可以量化的现象。5. 排查和修复如何快速定位并收敛问题5.1 排查命令速查表遇到类似问题直接按下面的顺序快速过一遍基本能定位是不是cpuset错乱想确认的信息使用的命令关键看什么cgroup版本stat -fc %T /sys/fs/cgroup是否为cgroup2fscgroup树结构systemd-cgls容器scope挂在哪容器的理想CPU集合cat .../cpuset.cpus请求值不一定代表实际容器的实际CPU集合cat .../cpuset.effective_cpus最终生效值才是真配置进程亲和性taskset -pc PID实际允许哪些核进程视图grep Cpus_allowed_list /proc/PID/status和taskset结果互相印证systemd当前属性systemctl show system.slice -p AllowedCPUs谁改过slice配置这里我特别强调cpuset.effective_cpus才是真相cpuset.cpus只是愿望。排查时如果只看了后者你永远找不到问题。5.2 快速恢复把cpuset改回原样确认是system.slice被收窄后恢复操作也不难。把AllowedCPUs改回原始范围就行。比如原来的机器是0-7sudo systemctl set-property system.slice AllowedCPUs0-7这条命令会把system.slice的cpuset.cpus改回0-7同时持久化的drop-in配置也会更新。容器节点的effective_cpus会跟着重新展开。如果容器进程的affinity没有立刻恢复可以用taskset手动重置或者直接重启容器让它重新初始化。注意恢复前务必确认这台机器原本的完整CPU范围是什么。如果不知道可以用lscpu看一下在线CPU列表或者先查systemd之前记录的属性。瞎填一个太小的范围会把故障扩大。恢复之后建议再检查一下其他容器和系统服务systemctl show配合grep可以批量确认还有哪些slice、service的AllowedCPUs被改动过。5.3 根治从操作姿势上堵住这个坑恢复只是止血真正要解决的是操作习惯问题。我说的第一条建议就是不要在宿主机上通过systemctl set-property直接改容器所在父级slice的CPU属性。容器需要绑核请用容器运行时自己的接口Docker就是--cpuset-cpusKubernetes就是request/limits加Guaranteed QoS。这样绑核配置会执行在容器cgroup节点上不会动到父级。如果确实需要用systemd的unit机制管理容器那请把unit放在独立的slice里并且给容器运行时设置好Delegate。比如给Docker配置一个独立的delegated slice避免直接复用system.slice这种全局节点。再看systemd-run。使用临时scope时建议这样处理显式指定--unit和--slice把它放到一个专用的临时目录下面不要依赖默认继承。执行前还要用systemd-run --scope -p AllowedCPUs... -- test command完整写出参数确保影响范围可预期。另外任何会改动cgroup资源属性的systemd命令都建议纳入变更管理流程。不要手敲一行命令就完事要把操作意图、影响范围、回滚方案一起带上。这种看起来很“轻”的命令实际上破坏力一点不轻。6. 这次事故背后的运维思考6.1 绑核错乱打破的不只是性能很多人对绑核的认知停留在“性能优化”层面觉得绑了核就能减少迁移、提升缓存命中率。但这次事故提醒我绑核在业务视角里也是资源隔离承诺的一部分。一个容器被限制到指定核上既是给它一个稳定的运行环境也是让其他容器和进程不受它的干扰。当systemd命令把容器从4-7挤到4-5被挤出去的不仅仅是两个核的算力更是隔离边界的完整性。容器A的线程开始和容器B的进程抢占同一个物理核共享L1/L2缓存本来互不可见的负载模式被强行暴露在彼此面前。这种资源层面上的“串味”一旦发生性能排除难度极高因为表面指标看起来还是“CPU忙”但忙的原因已经彻底变了。就算这次业务请求没出大问题这种共享也埋着隐患。6.2 把cgroup操作收口到唯一入口这条坑让我在团队里定了个不成文的规矩cgroup树上的写操作只允许通过容器运行时或专门的编排平台入口进行禁止任何人直接用系统级命令去改slice级的资源属性。unesp日志审计要开像set-property、systemd-run -p这类命令需要被审计日志记录到具体操作人和时间。我还加了一个监控维度定期采集关键容器的cpuset.effective_cpus如果和预期配置不一致直接告警不等到业务恶化才发现。另外如果容器里跑的是Java建议在启动参数里加上-XX:ActiveProcessorCount显式告诉JVM按容器实际预期核数去初始化线程池。这个参数不能解决cpuset被改的问题但能减少运行时缓存配置和实际资源严重不匹配带来的次生灾害。6.3 最后的个人心得踩过几次坑之后我对容器CPU相关的排障有了一个顽固的习惯遇到任何“CPU高但业务量没涨”的怪问题第一件事永远是去看cgroup的实际生效配置而不是先分析应用代码。Linux内核的cpuset逻辑非常严谨它不会自己出错绝大多数“错误”都来自于上层有人用不在计划内的方式动了它。systemd和容器本是同一条cgroup树上的伙伴协作得好是相安无事协作得不好就是这次事故里看到的“CPU打架”。希望这篇文章能帮你多留个心眼下次再看到有人随手执行systemd命令时能想到它背后可能牵扯到的整棵资源树。
上个月我在排查一个生产问题的时候被一条看似人畜无害的systemd命令整得相当狼狈。宿主机上几个Java容器跑得好好的突然开始CPU告警容器里的线程像约好了一样疯狂抢占核资源top里看CPU使用率节节攀升业务量却纹丝不动。折腾了两天最后定位到根因有人顺手执行了一条systemctl set-property把容器所在cgroup父节点的CPU集合收窄了容器原有的CPU绑核配置被内核按父级范围重新计算绑核直接错乱。今天把这条线完整拆开讲清楚希望同样被systemd和容器绑核问题折腾的人少走点弯路。文章会覆盖现象、cgroup v2的cpuset底层层逻辑、systemd命令为什么能“越权”改容器CPU归属、完整的复现步骤以及我最后沉淀下来的排查和规避手段。不管你是运维、SRE还是偶尔需要碰容器的后端开发这套知识都值得收藏。1. 先从事故现场说起一条命令引发的“CPU打架”1.1 诡异的现象业务没涨CPU却炸了那台机器是双路物理机上面用Docker跑了几个无状态Java服务。我们当时给核心服务做了绑核处理intended让某个容器固定在逻辑核4到7上用来避开宿主机上其他高负载业务和系统进程的干扰。这个方案跑了一个多月一直很平稳。出事那天下午监控开始告警。容器CPU使用率从平时的30%左右一路冲到90%以上RT从20ms飙升到300ms。我第一时间去看了业务指标请求量没涨、错误率没涨、数据库连接数也没涨。这就很反常了流量没变CPU为什么会突然爆掉更怪的是mpstat的输出。绑核后本来只应该负载集中在4-7号核上可现场看到的是4-5号核已经打满6-7号核反而有一搭没一搭地跑0-3号核上也开始出现不少用户态负载。容器里的进程明显不在自己该待的CPU上四处流窜。1.2 一开始的排查方向全跑偏了这种“性能无端恶化”的问题第一反应肯定是看应用层。我先扎进JVM日志看GCFull GC频率没有异常变化怀疑锁竞争但线程dump看下来业务锁的阻塞队列并没有明显堆积又怀疑是网络层重传检查了丢包率和TCP重传计数都正常。接着我用perf去抓容器内进程的调度行为看到了大量reschedule IPI和迁移事件。一个进程频繁从一个核被踢到另一个核每次迁移都伴随cache miss、TLB flush线程间的同步开销成倍增加。到这里我才隐约觉得问题出在CPU的分配逻辑上而不是应用本身。把视角从应用挪到宿主机后我用systemd-cgtop扫了一眼cgroup视图立刻发现了异常容器所在的cgroup节点实际生效的CPU集合effective_cpus只剩4-5而我记忆里配置的明明是4-7。一个核的集合硬生生被砍掉了一半所有线程挤在两个核上抢时间片这就是“CPU打架”的直接原因。2. systemd和容器之间到底谁该管CPU绑核2.1 容器在systemd的cgroup树里就是“上下级”大多数现代Linux发行版里systemd不只是1号进程它同时还是cgroup的主要管理者。在cgroup v2模式下系统根目录下的整棵cgroup树都是systemd在维护常见的system.slice、user.slice、machine.slice这些顶层节点全部归systemd管。Docker、containerd这些容器运行时本质上也依赖cgroup来约束容器资源。它们创建的容器scope会作为叶子节点挂到systemd管理的树上。比如当Docker配置使用systemd cgroup driver时一个容器的cgroup路径通常是这样的/sys/fs/cgroup/system.slice/docker-容器ID.scope也就是说systemd和容器运行时管理的是同一棵树。systemd管理的是树的主干和主要分支容器运行时管理的是某个分支下面的叶子。平时两者井水不犯河水可一旦有人用手动方式去操作树上的某个非叶子节点容器叶子立刻就会受到影响。2.2 cgroup v2的cpuset父级收窄实际生效集合跟着缩水cgroup v2的cpuset控制器和v1有一个非常大的区别v2里引入了两个不同的概念一个叫cpuset.cpus一个叫cpuset.effective_cpus。cpuset.cpus是“这个cgroup想用哪些核”你可以把它理解成请求值。cpuset.effective_cpus是“内核最终决定让这个cgroup用哪些核”它是实际生效值。v2的内核会强制保证任意一个cgroup的实际生效CPU集合必须是它父节点的实际生效CPU集合的子集。这个设计本意是好的避免子cgroup用到父cgroup根本不允许的CPU。但它带来一个副作用如果父节点的有效集合被收窄子节点即便在自己的cpuset.cpus文件里写着“4-7”实际可用集合也会自动和父节点的范围求交集变成“4-5”甚至空集。很多操作者只盯着cpuset.cpus看完全忽略cpuset.effective_cpus于是根本想不明白为什么容器绑核会悄悄失效。2.3 Delegate机制谁来动这棵子树的“产权”systemd知道自己管不了所有cgroup细节所以设计了Delegate机制。如果一个unit设置了Delegateyessystemd就把这棵子树“让渡”给里面的程序自己管理默认不会去动子树内部的cgroup属性。Docker服务本身一般是有Delegate的所以systemd不会挨个去改Docker创建的容器cgroup。但这里有个关键漏洞Delegate只保护了docker.service这棵子树内部容器的上级节点是system.slice而system.slice不是Docker的领地。它是systemd直接管理的顶层slice。执行systemctl set-property system.slice AllowedCPUs...的时候systemd完全有权修改这个节点修改结果又会顺着cgroup树传导到下面的所有容器。换句话说容器运行时的绑定只是“局部安排”systemd对上级slice的配置才是“全局规划”。全局规划一变局部安排瞬间作废。3. 根因深挖一条systemd命令如何“越权”改写容器绑核3.1 systemctl set-property对CPU集合做了什么systemd给运维提供了一个非常方便的属性设置入口systemctl set-property。它可以动态调整一个unit的CPU、内存、IO等限制其中和CPU绑核直接相关的属性叫AllowedCPUs。执行下面的命令时sudo systemctl set-property system.slice AllowedCPUs0-5systemd会做两件事先把磁盘上的持久化配置写成drop-in文件再立刻把当前运行中的cgroup节点属性更新掉。最终落在内核cgroup文件系统上就是/sys/fs/cgroup/system.slice/cpuset.cpus的内容变成了“0-5”。这个命令还有个隐藏特点它会持久化。你执行一次重启之后依然生效除非手动撤销。很多人以为它和临时改一下sysctl差不多重启就恢复原样这是个致命误解。到这里受害者链条已经完整了systemd把system.slice的CPU集合从默认的“0-7”收窄到“0-5”容器的cgroup作为system.slice的子节点实际生效集合自动变成自身请求“4-7”和父级有效集合“0-5”的交集也就是“4-5”。绑核范围从4个核缩小到2个核大量线程被塞进两个核里疯狂竞争。3.2 交点被吃掉一场典型的CPU资源争夺战当一个cgroup的实际生效CPU集合被压缩后内核调度器会做什么它会尝试把该cgroup内所有线程迁到新的合法CPU集合上。这个迁移不是一次性完成的而是一批一批进行的。在迁移过程中会出现几种典型的性能恶化现象第一迁移风暴。线程在不同CPU之间反复挪动每次迁移都要发送内部处理器中断IPI被迁移的线程cache是冷的首次访问内存全是cache miss。多线程程序在这种状态下同步原语的开销会暴涨。第二核间争抢。原本4个核平均分摊线程现在全压到2个核上。线程数不变核数减半每个核上的运行队列长度直接翻倍。时间片轮转频率变快上下文切换次数呈指数级上升CPU的有效利用率反而下降。第三锁抖动。Java这类多线程应用里锁非常密集。锁竞争本身已经很伤再加上抢锁的线程被频繁迁移锁的cache line在CPU之间来回弹等待时间被放大。top里CPU使用率飙升的背后其实有相当大比例是在空转和等待。3.3 另一个容易被忽略的入口systemd-run临时scope除了set-property我还踩过另一个坑systemd-run。它可以在当前cgroup树里创建一个临时scope来运行命令并且同样支持-p AllowedCPUs...参数。例如启动一个压测进程并限制它到2-3号核sudo systemd-run --scope -p AllowedCPUs2-3 stress-ng --cpu 4问题在于systemd-run创建的temporary scope默认会挂在当前用户对应的slice下如果这个slice恰好和容器所在的system.slice有层级关系或者你显式指定了--slicesystem.slice那它同样会改写system.slice节点上的cpuset属性和3.1里的set-property殊途同归。更隐蔽的是有些systemd-tailored服务脚本会在启动时执行类似systemd-run --scope的逻辑意图是给某个子进程做资源隔离但操作对象选错了层级结果把整棵子树都带偏了。3.4 容器里如果是Java破坏力还会被放大为什么这次事故里Java服务受害最明显JVM对CPU数量是有“记忆”的。从JDK 8u191开始JVM默认开启UseContainerSupport启动时会根据容器可用的CPU数量来初始化并行线程池、GC线程数、ForkJoinPool的commonPool大小。但JVM只在启动时做一次探测。如果容器启动时看到的CPU集合是4-7JVM就会按照4个可用来配置线程池。一旦运行过程中cpuset被systemd收窄成4-5JVM内部线程池大小不会跟着自动调整还是原来的规模。原本4个核的线程配置现在只让跑2个核线程之间疯狂排队GC线程和业务线程互相挤占整个进程的响应能力直接崩盘。这提醒我们一个事如果容器里跑的是JVM、Node.js这些对CPU核数敏感的运行时有绑核错乱带来的后果会被运行时自身的缓存配置进一步放大。监控告警如果只看容器CPU使用率很容易被误导。4. 实操复现在测试环境里复刻一次“CPU打架”4.1 准备一套可复现的实验环境光讲理论没有体验我强烈建议你在测试机上手敲一遍。环境要求并不复杂一台装了systemd的Linux机器建议Ubuntu 22.04或CentOS Stream 9确认cgroup是v2然后装好Docker并确认Docker的cgroup driver用的是systemd。cgroup版本可以这样验证stat -fc %T /sys/fs/cgroup如果输出是cgroup2fs那就是cgroup v2。再看Docker的driverdocker info | grep -i cgroup我的测试机输出是Cgroup Driver: systemd这是现在主流发行版上很常见的配置。4.2 容器正常绑核时应该看到什么启动一个容器并让CPU绑到4-7号核。为了后续方便压测我在容器里装了stress-ngdocker run -it --cpuset-cpus 4-7 ubuntu:22.04 bash apt-get update apt-get install -y stress-ng此时在宿主机上找到容器主进程PIDdocker inspect -f {{.State.Pid}} 容器名 taskset -pc PID正常情况下的输出应该是PID 12345s current affinity list: 4-7再看容器cgroup下的两个关键文件。路径可能是/sys/fs/cgroup/system.slice/docker-ID.scope也可能在不同发行版上略有差异用systemd-cgls可以方便地确认cat /sys/fs/cgroup/system.slice/docker-ID.scope/cpuset.cpus cat /sys/fs/cgroup/system.slice/docker-ID.scope/cpuset.effective_cpus稳定状态下两个文件输出的都是4-7。请求值和实际生效值一致一切都好。4.3 执行systemd命令观察绑核如何错乱现在进入事故现场的核心动作在宿主机上执行sudo systemctl set-property system.slice AllowedCPUs0-5这条命令把system.slice这个父级节点的CPU集合收窄到了0-5。执行之后不要急着看cpuset.cpus它很可能仍然是4-7因为容器运行时之前设置的请求值还在。真正发生变化的是cat /sys/fs/cgroup/system.slice/docker-ID.scope/cpuset.effective_cpus输出变成了4-5。原因就是内核自动做了父级有效集合和子级请求集合的交集计算{0-5} ∩ {4-7} {4-5}。再看容器进程的实际亲和性taskset -pc PID输出同样变成了4-5。你已经成功复刻了一次绑核错乱配置上写着4-7实际运行在4-5。4.4 用taskset和perf坐实“CPU打架”光看到affinity变了还不够我建议顺手把性能恶化也复现出来。容器里跑8个CPU密集型任务让线程数量大于可用核数stress-ng --cpu 8 --timeout 60同时在宿主机上用mpstat观察mpstat -P ALL 1你会看到4号和5号核的%user飙到接近100%6号和7号核闲置0-3号核也可能因为迁移产生少量负载。各核负载严重不均run queue拉长上下文切换计数器暴涨。如果还想看到进程迁移的实锤可以用perf的sched子命令抓一小段调度事件perf sched record sleep 5 perf sched latency输出里会清晰列出大量迁移事件就是因为线程被反复从一个核挪到另一个核导致的。到这一步“CPU打架”已经从抽象概念变成了可以量化的现象。5. 排查和修复如何快速定位并收敛问题5.1 排查命令速查表遇到类似问题直接按下面的顺序快速过一遍基本能定位是不是cpuset错乱想确认的信息使用的命令关键看什么cgroup版本stat -fc %T /sys/fs/cgroup是否为cgroup2fscgroup树结构systemd-cgls容器scope挂在哪容器的理想CPU集合cat .../cpuset.cpus请求值不一定代表实际容器的实际CPU集合cat .../cpuset.effective_cpus最终生效值才是真配置进程亲和性taskset -pc PID实际允许哪些核进程视图grep Cpus_allowed_list /proc/PID/status和taskset结果互相印证systemd当前属性systemctl show system.slice -p AllowedCPUs谁改过slice配置这里我特别强调cpuset.effective_cpus才是真相cpuset.cpus只是愿望。排查时如果只看了后者你永远找不到问题。5.2 快速恢复把cpuset改回原样确认是system.slice被收窄后恢复操作也不难。把AllowedCPUs改回原始范围就行。比如原来的机器是0-7sudo systemctl set-property system.slice AllowedCPUs0-7这条命令会把system.slice的cpuset.cpus改回0-7同时持久化的drop-in配置也会更新。容器节点的effective_cpus会跟着重新展开。如果容器进程的affinity没有立刻恢复可以用taskset手动重置或者直接重启容器让它重新初始化。注意恢复前务必确认这台机器原本的完整CPU范围是什么。如果不知道可以用lscpu看一下在线CPU列表或者先查systemd之前记录的属性。瞎填一个太小的范围会把故障扩大。恢复之后建议再检查一下其他容器和系统服务systemctl show配合grep可以批量确认还有哪些slice、service的AllowedCPUs被改动过。5.3 根治从操作姿势上堵住这个坑恢复只是止血真正要解决的是操作习惯问题。我说的第一条建议就是不要在宿主机上通过systemctl set-property直接改容器所在父级slice的CPU属性。容器需要绑核请用容器运行时自己的接口Docker就是--cpuset-cpusKubernetes就是request/limits加Guaranteed QoS。这样绑核配置会执行在容器cgroup节点上不会动到父级。如果确实需要用systemd的unit机制管理容器那请把unit放在独立的slice里并且给容器运行时设置好Delegate。比如给Docker配置一个独立的delegated slice避免直接复用system.slice这种全局节点。再看systemd-run。使用临时scope时建议这样处理显式指定--unit和--slice把它放到一个专用的临时目录下面不要依赖默认继承。执行前还要用systemd-run --scope -p AllowedCPUs... -- test command完整写出参数确保影响范围可预期。另外任何会改动cgroup资源属性的systemd命令都建议纳入变更管理流程。不要手敲一行命令就完事要把操作意图、影响范围、回滚方案一起带上。这种看起来很“轻”的命令实际上破坏力一点不轻。6. 这次事故背后的运维思考6.1 绑核错乱打破的不只是性能很多人对绑核的认知停留在“性能优化”层面觉得绑了核就能减少迁移、提升缓存命中率。但这次事故提醒我绑核在业务视角里也是资源隔离承诺的一部分。一个容器被限制到指定核上既是给它一个稳定的运行环境也是让其他容器和进程不受它的干扰。当systemd命令把容器从4-7挤到4-5被挤出去的不仅仅是两个核的算力更是隔离边界的完整性。容器A的线程开始和容器B的进程抢占同一个物理核共享L1/L2缓存本来互不可见的负载模式被强行暴露在彼此面前。这种资源层面上的“串味”一旦发生性能排除难度极高因为表面指标看起来还是“CPU忙”但忙的原因已经彻底变了。就算这次业务请求没出大问题这种共享也埋着隐患。6.2 把cgroup操作收口到唯一入口这条坑让我在团队里定了个不成文的规矩cgroup树上的写操作只允许通过容器运行时或专门的编排平台入口进行禁止任何人直接用系统级命令去改slice级的资源属性。unesp日志审计要开像set-property、systemd-run -p这类命令需要被审计日志记录到具体操作人和时间。我还加了一个监控维度定期采集关键容器的cpuset.effective_cpus如果和预期配置不一致直接告警不等到业务恶化才发现。另外如果容器里跑的是Java建议在启动参数里加上-XX:ActiveProcessorCount显式告诉JVM按容器实际预期核数去初始化线程池。这个参数不能解决cpuset被改的问题但能减少运行时缓存配置和实际资源严重不匹配带来的次生灾害。6.3 最后的个人心得踩过几次坑之后我对容器CPU相关的排障有了一个顽固的习惯遇到任何“CPU高但业务量没涨”的怪问题第一件事永远是去看cgroup的实际生效配置而不是先分析应用代码。Linux内核的cpuset逻辑非常严谨它不会自己出错绝大多数“错误”都来自于上层有人用不在计划内的方式动了它。systemd和容器本是同一条cgroup树上的伙伴协作得好是相安无事协作得不好就是这次事故里看到的“CPU打架”。希望这篇文章能帮你多留个心眼下次再看到有人随手执行systemd命令时能想到它背后可能牵扯到的整棵资源树。
