如何在Linux中设置具体的系统进程亲和力绑定规则

想把 systemd 服务的 CPUAffinity 配置长期、稳定地保留下来，真正靠谱的办法只有一种：直接写进 [Service] 段。写法也有讲究，必须使用空格分隔的 CPU 编号或范围，比如 CPUAffinity=0 2 4 或 0-3，这里不支持逗号。要是写了多行，systemd 会按逻辑 OR 的方式合并处理。配置改完之后，别漏掉两步：先执行 daemon-reload，再重启对应服务。

systemd 服务配置 CPUAffinity 是唯一可靠的持久化方式

Linux 其实并不存在所谓“系统级的全局亲和力开关”。很多人提到“给系统进程设置绑定规则”，本质上说的，是针对由 systemd 管理的服务进程——比如 sshd、nginx、redis-server——分别做可持久、重启后依然生效的亲和力绑定。要是直接去改内核参数，或者想用一套规则把所有进程统一卡住，不但达不到目的，严重的话还可能把 SSH 卡死，甚至让系统响应直接中断。

关键点在于：CPUAffinity 必须写在服务单元文件的 [Service] 段里，且只影响该服务主进程及其显式 fork 的子进程（不自动继承）：

• CPUAffinity=0 2 4 表示允许运行在逻辑 CPU 0、2、4 上；CPUAffinity=0-3 表示允许 CPU 0/1/2/3
• 不支持逗号分隔，不支持 CPUAffinity=0,2 这种写法；混合范围与单数（如 0-1 3）是合法的
• 多行 CPUAffinity= 会被 systemd 合并为逻辑 OR，例如同时写 CPUAffinity=0 1 和 CPUAffinity=4 5，等效于允许在 CPU 0/1/4/5 上运行
• 修改后必须执行 sudo systemctl daemon-reload && sudo systemctl restart servicename.service，仅 daemon-reload 不会重载已运行进程

taskset -pc 对已运行进程重绑定常失败，原因要逐条排查

执行 taskset -pc 1,3 1234 看似成功，但几秒后进程又跑到了其他核上——这不是命令失效，而是调度器在干预：

• 进程内部调用了 sched_setaffinity（比如 Ja va JVM 启动时加了 -XX:+UseNUMA 或 Go runtime 自动调整），覆盖了 shell 层面的设置
• 目标 CPU 被 isolcpus 内核参数隔离，但没通过 cpuset cgroup 显式授权，导致调度器拒绝迁移
• 进程使用了 SCHED_FIFO 实时策略，而你指定的 CPU 正被高优先级 IRQ 占满，内核强制迁出以保障中断响应
• taskset 只作用于当前进程，其 fork() 出的子进程默认继承全开掩码（0xffffffff），不会自动延续绑定

C/C++ 中调用 sched_setaffinity 必须检查返回值和运行时条件

代码级控制适用于工作线程池、DPDK、实时音频等场景，但“设上就行”是最大误区：

• 必须检查 sched_setaffinity() 返回值：if (sched_setaffinity(0, sizeof(cpuset), &cpuset) == -1)，常见失败原因包括：EPERM（非 root 绑隔离核）、EINVAL（CPU 编号越界或已 offline）、EIO（cgroup 限制冲突）
• 不要硬编码 CPU 编号，先用 sysconf(_SC_NPROCESSORS_ONLN) 获取在线核数，再结合 lscpu 输出的 topology 判断物理核/超线程关系
• 若需绑定到某个物理核的两个逻辑核（HT），应显式 CPU_SET(0, &cpuset); CPU_SET(1, &cpuset);，不能只设 CPU_SET(0, &cpuset) 期望自动包含超线程伙伴
• 线程级绑定要用 pthread_setaffinity_np()，传入真实线程 ID，而非进程 PID

绑定前不看 lscpu 和 NUMA 拓扑，90% 的性能优化会适得其反

盲目按编号绑 CPU 0/1/2/3，很可能跨 NUMA 节点访问内存，延迟翻倍：

• 运行 lscpu 查看 NUMA node(s)、CPU(s)、Core(s) per socket 和 Socket(s)，确认逻辑 CPU 编号与物理位置的映射
• 在 NUMA 系统中，优先将进程、其使用的内存、网卡 RSS 队列、GPU 设备绑定在同一 NUMA 节点内；例如 numactl --cpunodebind=0 --membind=0 ./app
• 超线程环境下，同物理核的两个逻辑 CPU（如 0 和 1）共享 L1/L2 缓存，高吞吐服务建议错开使用（如绑 0/2/4…），避免缓存争抢
• 务必预留至少 1–2 个 CPU 给系统：IRQ、ksoftirqd、sshd、监控 agent，否则绑死会导致系统失联或中断饥饿

实际生效的绑定从来不是“设完就稳”，而是“查拓扑 → 定策略 → 配 systemd 或写代码 → 验证 taskset -cp PID → 监控 perf sched latency 和缓存命中率”。最容易被忽略的是：绑定只是起点，后续的中断分布、内存分配策略、cgroup 限制，都会动态覆盖它。