如果想让 systemd 服务的 CPUAffinity 配置长期保留并稳定生效，真正可靠的做法只有一种：直接写入 [Service] 段。写法也需要注意，必须使用空格分隔 CPU 编号或范围，例如 CPUAffinity=0 2 4 或 0-3，这里不支持逗号分隔。如果配置了多行，systemd 会按逻辑 OR 的方式进行合并。修改完成后，别忘了执行两步：先运行 daemon-reload，再重启对应服务。

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

在 Linux 中，其实并没有所谓“系统级全局 CPU 亲和力开关”。很多人所说的“为系统进程设置绑定规则”，本质上指的是针对由 systemd 管理的服务进程——例如 sshd、nginx、redis-server——分别设置可持久化、服务重启后依然有效的 CPU 亲和力策略。如果直接修改内核参数，或者试图用一套规则强行限制所有进程，不仅无法达到预期效果，严重时还可能导致 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 并不会让已经运行的进程重新加载 CPU 绑定规则

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

执行 taskset -pc 1,3 1234 看起来像是设置成功了，但几秒钟后进程又跑到其他 CPU 核上——这通常不是命令失效，而是 Linux 调度器或运行环境在介入：

• 进程内部可能主动调用了 sched_setaffinity（例如 Java JVM 启动时启用了 -XX:+UseNUMA，或 Go runtime 自动调整亲和力），从而覆盖了 shell 层设置的结果
• 目标 CPU 可能被 isolcpus 内核参数隔离，但没有通过 cpuset cgroup 显式授权，导致调度器拒绝将进程迁移过去
• 进程如果采用了 SCHED_FIFO 实时调度策略，而你指定的 CPU 又被高优先级 IRQ 长时间占用，内核可能会强制迁出进程，以保证中断响应能力
• taskset 只对当前进程生效，它后续通过 fork() 创建的子进程默认可能继承全开掩码（0xffffffff），不会自动持续沿用你设置的绑定策略

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

通过代码控制 CPU 亲和力，适用于线程池、DPDK、实时音频处理等典型场景，但“调用一次就一定成功”恰恰是最常见的误区：

• 必须检查 sched_setaffinity() 的返回值：if (sched_setaffinity(0, sizeof(cpuset), &cpuset) == -1)，常见失败原因包括：EPERM（非 root 用户尝试绑定隔离核）、EINVAL（CPU 编号越界或对应 CPU 已 offline）、EIO（与 cgroup 限制发生冲突）
• 不要硬编码 CPU 编号，应该先通过 sysconf(_SC_NPROCESSORS_ONLN) 获取当前在线 CPU 数量，再结合 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 架构的 Linux 服务器中，应优先将进程、所使用的内存、网卡 RSS 队列以及 GPU 设备尽量放在同一 NUMA 节点内，例如 numactl --cpunodebind=0 --membind=0 ./app
• 在开启超线程的环境下，同一个物理核心上的两个逻辑 CPU（如 0 和 1）会共享 L1/L2 缓存，高吞吐业务更适合错开绑定（例如使用 0/2/4…），以减少缓存争用
• 务必至少预留 1–2 个 CPU 给系统关键任务使用，例如 IRQ、ksoftirqd、sshd、监控 agent 等，否则过度绑核可能导致系统失联、SSH 无法登录，甚至出现中断饥饿