一条消息平均在几十微秒内完成，不代表系统可靠。只要少数样本因为线程迁移、缓存失效、跨 NUMA 节点访问或内核调度产生明显延迟，策略回测与实盘表现就可能出现偏差。此时，均值没有解释力。需要观察 P99、P99.9，甚至更高分位数。
CPU 亲和性绑定是处理这类问题的基础设置之一。它不能单独构成低延迟架构，也不能消除所有中断和调度抖动。但它可以减少线程在 CPU 核心之间迁移，稳定缓存局部性，并为后续的核心隔离、内存绑定和中断治理提供边界。
核心路径很短：
1. 查询当前线程或进程运行在哪些 CPU 上。
2. 将关键线程限制在指定核心。
3. 将关键核心从普通调度和系统噪声中隔离。
4. 使用性能计数器验证上下文切换是否下降。
5. 对尾部延迟重新测量，而不是只看平均值。
CPU亲和性绑定到底改变了什么
Linux 调度器默认拥有完整的 CPU 选择权。线程可在多个核心之间运行。调度器会根据负载、优先级、亲和性掩码和系统状态做出决策。
这对通用服务器是合理的。对高频交易系统则不一定。
行情接收、行情解析、订单簿更新、策略计算和交易接口通常存在明确的时序关系。关键线程在核心之间迁移后，会产生几类成本：
- 原核心上的 L1、L2 缓存内容不再直接可用。
- 新核心需要重新建立指令和数据缓存。
- 线程可能跨越 NUMA 节点。
- 调度器需要重新进行负载均衡。
- 迁移过程可能引入额外的上下文切换。
- 共享数据结构的缓存一致性流量增加。
CPU 亲和性绑定的作用，是缩小调度器的可选范围。
如果一个线程被绑定到 CPU 2，它不会因为普通负载均衡自动迁移到 CPU 3。若绑定到 CPU 2 和 CPU 3，调度器仍可在这两个核心之间选择。绑定范围越窄，执行位置越稳定，但可用计算资源也越少。
这不是加速开关。
绑定之后，线程的单次执行不一定更快。收益通常体现为：
- 延迟分布更集中。
- 尾部样本减少。
- 缓存局部性更稳定。
- 核心之间的迁移减少。
- 不同测试轮次之间的结果更接近。
因此，验证 CPU 亲和性绑定时，不能只比较平均延迟。至少需要同时记录中位数、P99、P99.9、最大值、上下文切换和 CPU 迁移次数。
CPU 亲和性绑定不是让 CPU 更快，而是减少调度器对关键路径的随机选择。
先区分进程、线程和 CPU 掩码
实际操作中最常见的错误，是把进程、线程和 CPU 核心当成同一个对象处理。
Linux 的调度单位是线程。一个进程可以包含多个线程。主线程、行情接收线程、策略线程、日志线程和网络发送线程可能分别拥有不同的 CPU 亲和性。
对进程执行 taskset，不等于已经完成了精确的线程级布局。
进程级绑定
最简单的形式是：
taskset -c 2 ./trading_gateway
这会限制新启动进程使用 CPU 2。进程中的线程通常会继承这个限制，但它不会自动把不同线程均匀分配到多个核心。所有线程可能仍然竞争同一个核心。
也可以对已有进程设置亲和性：
taskset -cp 2 <PID>
这里的 <PID> 是进程号。输出通常会显示当前允许使用的 CPU 列表。修改已有进程时，需要确认权限和目标对象。
如果绑定多个核心，可以写成：
taskset -c 2,3 ./trading_gateway
或者：
taskset -c 2-3 ./trading_gateway
这表示进程可以运行在 CPU 2 和 CPU 3 上。它不表示主线程使用 CPU 2，工作线程使用 CPU 3。具体调度仍由 Linux 决定。
线程级绑定
高频交易系统通常需要线程级绑定。
对于一个包含多个工作线程的程序，合理布局可能是：
- 行情接收线程固定在 CPU 2。
- 行情解析线程固定在 CPU 3。
- 订单簿更新线程固定在 CPU 4。
- 策略计算线程固定在 CPU 5。
- 下单发送线程固定在 CPU 6。
- 日志、监控和管理接口放在普通核心。
这类布局不能通过一次 taskset -p <PID> 自动完成。需要在线程创建后分别设置亲和性。Linux 提供两个常用接口：
sched_setaffinity(2)：可以为指定线程设置 CPU 亲和性。pthread_setaffinity_np(3)：可以在程序中为指定线程设置亲和性。
代码层绑定的优势是对象更明确。可以根据线程职责、线程编号或启动阶段完成设置。不会把所有辅助线程错误地压到关键核心上。
需要注意，Linux 中线程具有独立的线程标识。调试时不能只记录进程号，还应记录线程标识、线程名称和当前 CPU。
CPU 掩码
taskset -p <PID> 通常输出十六进制的 Affinity Mask。
例如，某个掩码对应 CPU 0、CPU 2 和 CPU 4。掩码本身适合脚本处理，但不适合人工快速阅读。查看核心列表时，优先使用：
taskset -cp <PID>
这会输出类似 0,2,4 或 0-3 的格式。
对于自动化部署，建议同时保留两种信息：
- 原始十六进制掩码。
- 可读的核心列表。
- 目标线程名称。
- 绑定动作的时间戳。
- 绑定前后的校验结果。
否则，出现延迟异常时，很难判断问题来自配置、进程重启还是线程重新创建。
如何检查 CPU 亲和性绑定是否生效
检查分为三个层次。
第一层是配置检查。确认允许的 CPU 集合是否正确。
第二层是运行检查。确认线程实际运行位置是否发生迁移。
第三层是性能检查。确认尾部延迟是否改善。
使用 taskset 查询
已有进程可以执行：
taskset -p <PID>
查看十六进制掩码。
使用：
taskset -cp <PID>
查看核心列表。
如果需要检查某个启动命令，可以直接使用：
taskset -c 4 ./market_data_service
随后再查询进程的实际配置。
这里的重点不是命令是否返回成功，而是返回内容是否符合线程布局设计。一个常见错误是：启动命令绑定了 CPU 4，程序内部创建的线程却在初始化阶段覆盖了亲和性配置。最终结果与启动参数不一致。
使用 /proc 查看进程状态
Linux 的 /proc/<pid>/status 中包含与 CPU 亲和性相关的信息。可以检查 Cpus_allowed 和 Cpus_allowed_list。
可读字段比十六进制掩码更适合人工审计。对于脚本，则可以保存原始字段并转换成结构化数据。
示例路径：
/proc/<PID>/status
检查时关注以下问题：
- 允许使用的 CPU 是否是预期集合。
- 进程重启后配置是否仍然存在。
- 关键进程与日志进程是否使用了同一组核心。
- 是否出现超出规划范围的核心编号。
- 容器或控制组是否进一步限制了 CPU 集合。
如果部署在容器中，还要区分 Linux 进程看到的 CPU 编号和宿主机物理 CPU 编号。容器的 CPU 可见性、控制组限制和宿主机隔离参数可能叠加。只查看容器内部的 taskset 输出，不能完整说明物理拓扑。
查看实际运行核心
静态亲和性不等于实际运行结果。
可以通过线程级运行信息观察最近一次运行在哪个 CPU。也可以使用系统监控、性能分析工具或 /proc 相关接口确认执行位置。关键是必须按线程观察，不要只看进程级数据。
一个进程的主线程可能固定在 CPU 2，但行情解析线程仍然运行在 CPU 3 和 CPU 4。进程级检查显示配置正常，关键线程级检查却可能发现布局并不符合设计。
适合记录的字段包括：
| 字段 | 作用 |
|---|---|
| 进程标识 | 确定目标进程 |
| 线程标识 | 区分实际调度对象 |
| 线程名称 | 映射业务职责 |
| 允许 CPU 列表 | 验证亲和性配置 |
| 最近运行 CPU | 观察实际执行位置 |
| NUMA 节点 | 判断内存与核心是否匹配 |
| 上下文切换计数 | 观察调度干扰 |
| 迁移次数 | 识别核心迁移 |
这张表不应只在故障时使用。生产部署时就应该定期采集。低延迟系统的问题通常不是持续发生，而是以少量尾部样本的形式出现。
从进程绑定到线程布局
CPU 亲和性设置的难点，不在命令本身，而在布局。
关键路径不能共享一个核心
假设行情接收、订单簿更新和策略计算全部绑定到 CPU 2。三个线程之间可能存在锁竞争、缓存争用和调度切换。
此时，绑定没有消除抖动。只是把抖动集中到一个核心。
核心路径的线程划分应当依据数据流，而不是依据进程数量。需要先画出线程之间的依赖关系：
1. 网卡或用户态网络层接收数据。
2. 解码行情消息。
3. 更新本地订单簿。
4. 计算指标或生成交易信号。
5. 构造订单请求。
6. 写入交易接口。
7. 接收回报并更新状态。
如果这些步骤由不同线程完成，就需要明确每个线程的 CPU 范围。若存在生产者和消费者关系，还要考虑它们之间的共享队列和缓存一致性成本。
对于极低延迟路径，过度拆分线程可能比单线程流水线更差。线程之间的队列、锁、原子操作和缓存同步都会引入成本。CPU 绑定只能优化既有结构，不能修复错误的并发模型。
辅助线程必须离开关键核心
日志、指标、心跳、配置刷新、文件写入、垃圾回收和管理接口都可能产生不可预测的系统调用。
这些线程不应与行情处理或下单线程共享隔离核心。
如果不能彻底迁移辅助线程，至少应当限制它们的 CPU 范围。常见做法是将普通业务线程放在一组核心，将关键线程放在另一组核心。
但需要检查线程库的默认行为。某些运行时会创建后台线程。某些日志框架会异步写盘。某些网络库会启动事件循环线程。只绑定主线程而不处理后台线程，配置就不完整。
超线程不是独立物理核心
CPU 编号只是逻辑处理器编号。两个逻辑 CPU 可能共享同一个物理核心及其执行资源、缓存或其他硬件资源。
如果关键线程绑定到一个逻辑 CPU，而另一个逻辑 CPU 上运行了普通任务，仍可能发生资源竞争。高频交易场景通常需要先确认：
- 物理核心与逻辑核心的对应关系。
- 同一物理核心上的兄弟线程。
- L1、L2、L3 缓存拓扑。
- NUMA 节点与 CPU 的对应关系。
- 中断和内核线程当前运行在哪些逻辑 CPU。
不能把连续编号简单理解为连续的物理核心。CPU 2 和 CPU 3 可能不是最优组合。需要以实际硬件拓扑为准。
NUMA 节点必须同时规划
在双路或多路服务器中，CPU 和内存通常分布在不同 NUMA 节点。线程固定在某个节点的 CPU 上，但数据分配在另一个节点的内存中，仍然会产生跨节点访问。
CPU 亲和性绑定解决的是调度位置。它不自动解决内存位置。
如果行情缓冲区、订单簿对象和策略状态在错误的 NUMA 节点分配，线程即使不迁移，访问延迟仍可能增加。更严重的是，首次触碰内存的线程可能决定页面所在节点。初始化阶段的线程布局会影响后续运行。
因此，低延迟系统至少需要同时考虑：
- 线程绑定到哪个 CPU。
- CPU 属于哪个 NUMA 节点。
- 数据结构由哪个线程初始化。
- 内存分配发生在哪个节点。
- 网卡所在 PCIe 根端口属于哪个节点。
- 网络接收线程与网卡中断是否位于相近节点。
不要把 CPU 亲和性当成 NUMA 优化的替代品。两者是不同层次的问题。
isolcpus、nohz_full 和 rcu_nocbs 的组合
只使用 taskset，只能限制目标线程可以运行的核心。操作系统仍然可能在这些核心上处理时钟中断、RCU 回调和其他内核工作。
如果关键核心需要更低的调度噪声，通常需要组合使用内核参数：
isolcpusnohz_fullrcu_nocbs
例如：
isolcpus=1-7
nohz_full=1-7
rcu_nocbs=1-7
这些参数不是同一个功能。
isolcpus
isolcpus 用于将指定核心从普通调度器的负载均衡中隔离。它可以减少普通任务被调度到这些核心上的概率，并降低调度器主动迁移负载的机会。
但它不代表核心完全没有内核活动。
时钟中断、RCU 回调和硬件中断仍可能造成干扰。只配置 isolcpus，不能宣称已经消除所有上下文切换。
nohz_full
nohz_full 用于减少指定核心上的周期性时钟 tick。对于长期运行单一用户态线程的核心，它可以降低定时器带来的干扰。
该参数有使用条件。核心上运行的任务数量、内核版本、系统配置和线程行为都会影响效果。关键核心上如果同时运行多个活跃任务，收益会下降。
它也不是绝对静默模式。其他定时器、硬件中断和内核工作仍需单独处理。
rcu_nocbs
rcu_nocbs 用于将 RCU 回调从指定核心移出，减少 RCU 工作对关键线程的干扰。
它需要与其他参数和用户空间线程布局配合。只写入启动参数而不观察实际回调执行位置，仍然可能得到错误结论。
为什么必须组合
三者处理不同来源的内核活动。一个参数只能覆盖一个范围。
| 设置 | 主要作用 | 不能单独解决的问题 |
|---|---|---|
isolcpus | 减少普通调度和负载均衡 | 时钟中断、RCU 回调、硬件中断 |
nohz_full | 减少周期性时钟 tick | 所有内核中断和后台任务 |
rcu_nocbs | 移出 RCU 回调 | 网络中断、定时器和应用线程竞争 |
taskset | 限制目标线程可运行的 CPU | 核心上的其他系统噪声 |
| 线程级亲和性接口 | 精确绑定指定线程 | 错误的线程设计和 NUMA 布局 |
实际配置还需要考虑系统启动参数、引导加载器、内核版本和运维流程。修改参数后必须重启并验证。配置文件存在，不等于运行时生效。
用 perf 验证，而不是凭感觉判断
低延迟优化最容易出现的错误，是配置看起来正确，性能却没有改善。解决方法是建立可重复的验证过程。
可以使用 perf 统计调度切换事件。例如：
perf stat -e 'sched:sched_switch' -a -A --timeout 10000
该命令用于观察指定时间窗口内的调度切换。成功隔离的核心上，sched_switch 计数应当非常低。
这里有几个限制。
第一，计数范围必须明确。系统级统计、CPU 级统计和进程级统计代表不同含义。不能把全机结果当成关键核心结果。
第二，测试期间必须保持负载条件稳定。行情消息量、订单事件、日志量和后台任务变化都会改变调度结果。
第三，低上下文切换不代表低延迟。线程可能没有频繁切换，但仍然受到硬件中断、缓存争用、内存访问和锁竞争影响。
第四，需要保留基线。至少进行两组测试：
- 未绑定或原始配置。
- 绑定、隔离和线程布局后的配置。
每组测试应记录同一批输入数据、相同程序版本、相同编译参数和相同运行时间。否则，优化前后的差异无法归因。
建议采集以下指标：
- 消息接收延迟。
- 行情解析延迟。
- 订单簿更新时间。
- 策略计算耗时。
- 下单请求发送耗时。
- 端到端延迟。
- P50、P90、P99、P99.9。
- 最大延迟。
- 上下文切换。
- CPU 迁移。
- 缓存未命中。
- 跨 NUMA 访问。
- 硬件中断分布。
其中，最大延迟不适合作为唯一判断依据。单个异常样本可能来自系统维护、磁盘事件或其他不可重复因素。分位数更适合观察尾部结构，但也必须结合测试窗口长度。
一个可执行的验证流程
第一步：记录硬件拓扑
先确认 CPU 编号、物理核心、超线程和 NUMA 节点。不要直接假设 CPU 编号具有拓扑顺序。
同时记录网卡、PCIe 设备和内存节点的关系。交易系统中的网络路径并不只经过 CPU。设备所在节点可能影响数据进入用户空间后的访问成本。
第二步：列出全部线程
获取目标进程的线程列表。对每个线程记录：
- 线程名称。
- 线程标识。
- 线程职责。
- 当前亲和性。
- 目标 CPU。
- 所属 NUMA 节点。
- 是否属于关键路径。
如果程序没有设置线程名称，先补齐。没有线程名称的调优工作会快速退化成数字匹配。
第三步：制定核心分配表
不要先执行命令，再决定布局。先写清楚分配关系。
| 线程类型 | 建议处理方式 | 原因 |
|---|---|---|
| 行情接收 | 固定到专用核心 | 减少接收路径迁移 |
| 行情解析 | 与数据流匹配的独立核心 | 降低解析线程竞争 |
| 订单簿更新 | 固定且保持数据局部性 | 减少共享缓存抖动 |
| 策略计算 | 视计算量配置核心 | 避免与接收线程争用 |
| 下单发送 | 固定到明确核心 | 控制发送路径尾延迟 |
| 日志写入 | 放入普通核心 | 避免文件和系统调用干扰 |
| 监控与管理 | 放入普通核心 | 避免侵入交易关键路径 |
| 垃圾回收或运行时后台线程 | 单独规划 | 防止隐藏线程占用关键核心 |
这不是固定模板。线程数量、消息类型、策略复杂度和网络模型不同，最优布局也不同。
第四步：执行绑定
短期验证可以使用 taskset。生产系统更适合在代码层使用 sched_setaffinity 或 pthread_setaffinity_np。
代码层设置时，需要处理失败情况。绑定失败不能静默继续。应该记录错误、线程名称、目标 CPU 和系统返回值。
同时，绑定动作应发生在正确的生命周期阶段。线程创建后立即设置，通常比进程启动后由外部脚本延迟设置更可控。延迟设置期间，线程可能已经执行过初始化、分配内存或建立缓存。
第五步：配置核心隔离
在确认线程布局有效后，再考虑 isolcpus、nohz_full 和 rcu_nocbs。
不要一开始就修改全部启动参数。参数越多，问题越难归因。应该按照阶段增加：
1. 只做线程亲和性绑定。
2. 观察调度和尾延迟。
3. 加入普通核心与关键核心的分离。
4. 再加入内核核心隔离参数。
5. 最后处理中断、网络和 NUMA。
每一阶段都保留数据。
第六步：检查调度切换
使用 perf stat 观察关键核心。成功隔离后，sched_switch 计数应明显降低，但不能只看单次结果。
需要重复运行。低延迟测试中，偶然结果没有价值。至少要确认结果在不同测试轮次中方向一致。
第七步：重新测量尾部延迟
如果平均延迟下降，但 P99.9 上升，不能称为优化成功。
如果 P99.9 下降，但吞吐量明显下降，也需要重新评估。绑定核心通常会减少可调度资源。过度隔离可能使其他线程排队，最终把压力转移到队列、网络发送或回报处理阶段。
常见的错误配置
只绑定主进程
这是最常见的误区。
进程包含多个线程。主进程的亲和性结果无法说明每个线程的实际分配。尤其是使用线程池、异步网络库或带后台任务的运行时，辅助线程会改变实际调度结构。
修复方法是按线程检查。至少检查行情、策略、下单、日志和监控线程。
把所有线程绑定到同一个核心
这样可以减少迁移，但会增加竞争。关键路径变成串行队列，辅助线程还可能触发上下文切换。
绑定的目标不是让所有线程停在一个核心，而是让每个关键阶段拥有明确的资源边界。
只设置 isolcpus
仅使用 isolcpus 不能彻底消除 Linux 内核干扰。时钟 tick、RCU 回调和硬件中断仍可能存在。
必须通过 perf 或其他观测手段验证，而不是根据启动参数推断结果。
只看平均延迟
平均值对尾部异常不敏感。一次明显的调度抖动可能对均值影响很小，却直接影响 P99.9。
高频交易系统应该保存延迟直方图或分位数序列。单个平均值不足以支持优化结论。
忽略中断亲和性
关键线程已经固定在 CPU 4，但网卡中断也集中在 CPU 4。此时，线程仍会被网络中断打断。
中断分布属于独立配置。不能因为进程亲和性正确，就认为硬件中断已经避开关键核心。具体网卡驱动、用户态网络框架和硬件参数需要单独验证。不同设备的配置命令也不能互相套用。
忽略 NUMA
线程在节点 0，数据在节点 1。CPU 绑定仍然可能产生跨节点访问。
这类问题常见于启动阶段。初始化线程、内存分配线程和实际计算线程不是同一个线程时，页面位置可能与设计不符。
绑定范围过窄
如果策略线程需要多个核心，而配置只允许一个核心，系统可能出现排队。此时上下文切换减少了，但任务等待增加了。
低延迟并不等于核心越少越好。应根据工作集、消息速率和线程模型选择范围。
忽略程序重启
手工执行 taskset -cp 只能修改当前实例。进程重启后，配置可能恢复默认值。
生产环境需要把亲和性设置写入启动脚本、服务管理配置或程序初始化逻辑，并在每次启动后执行自动校验。
CPU亲和性与回测的关系
CPU 亲和性通常被认为是实盘部署问题，但它也会影响回测。
回测系统如果使用多线程并行计算，线程迁移和缓存争用可能让不同批次的运行时间产生波动。对需要稳定基准的参数优化任务，这种波动会污染性能比较。
更重要的是，回测延迟与实盘延迟不是同一个指标。
回测可以使用历史数据重放，重点是信号、成交、滑点和资金曲线。实盘系统还需要处理：
- 网络接收。
- 消息解码。
- 订单簿状态。
- 线程同步。
- 交易接口调用。
- 回报处理。
- 进程间通信。
- 系统调度。
因此，CPU 亲和性绑定不会自动让回测策略更有效。它只可能让执行环境更稳定。策略收益、成交概率和风险模型仍然需要独立验证。
参数优化也需要避免过拟合。某一组 CPU 绑定参数在一台服务器、一个内核版本和一批行情数据上表现良好，不代表迁移到其他硬件后仍然有效。
优化对象不应只是一个延迟数字，而应是完整的分布：
- 延迟中位数。
- 高分位延迟。
- 延迟方差。
- 超时次数。
- 吞吐量。
- CPU 利用率。
- 核心空闲率。
- 上下文切换。
- 系统维护成本。
一个更稳妥的配置判断逻辑
可以用以下顺序判断问题来源：
1. 线程是否发生迁移。
如果关键线程频繁跨核心运行，先处理亲和性。
2. 线程是否跨 NUMA 节点访问。
如果线程位置稳定但延迟仍高，检查内存分配和设备拓扑。
3. 关键核心是否存在上下文切换。
如果 sched_switch 较高，检查辅助线程、定时器和内核工作。
4. 硬件中断是否落在关键核心。
如果中断集中在交易线程所在核心，需要重新规划中断分布。
5. 共享数据是否产生缓存竞争。
如果 CPU 绑定后仍有明显尾部延迟，检查锁、原子变量和缓存行布局。
6. 线程之间是否存在不必要的队列。
如果每一步都跨线程传递，调度成本可能超过计算成本。
7. 系统是否已经进入过度优化状态。
如果配置复杂、收益不稳定、故障难以复现，应减少参数而不是继续增加参数。
这个顺序从调度位置开始，逐步进入内存、内核、硬件和应用层。不要在没有确认前一层问题之前，直接修改更底层参数。
生产部署中的审计项
CPU 亲和性配置必须可观察、可恢复、可比较。
每次发布至少保留以下信息：
- 操作系统版本。
- Linux 内核版本。
- CPU 型号和逻辑核心数量。
- 物理核心拓扑。
- NUMA 节点拓扑。
- 关键线程清单。
- 线程与核心的映射。
- 启动参数。
- 进程和线程亲和性。
- 测试输入及时间窗口。
- 延迟分位数。
perf统计结果。- 中断分布。
- 配置变更记录。
不要只把配置写在文档中。让程序在启动时输出运行日志，主动报告：
- 当前线程标识。
- 允许使用的 CPU。
- 实际检测到的 NUMA 节点。
- 绑定是否成功。
- 关键线程是否缺失。
- 目标核心是否已经被其他服务占用。
如果绑定失败，应该让部署失败，而不是让系统带着未知配置继续运行。低延迟系统最危险的状态不是明确的错误，而是配置表面正常、运行时实际不一致。
绑定设置的边界
CPU 亲和性绑定能处理调度范围问题。它不能解决以下问题：
- 算法复杂度过高。
- 锁竞争严重。
- 内存布局不合理。
- 数据结构频繁分配。
- 网络协议栈路径过长。
- 订单接口本身存在排队。
- 日志系统阻塞关键线程。
- 编译器生成了低效代码。
- 缓存行发生严重伪共享。
- 外部交易柜台出现不可控延迟。
- 网卡、驱动和用户态网络配置不匹配。
如果关键路径中存在大量动态内存分配，先处理内存管理。若策略计算本身占满核心，先处理算法和数据结构。若延迟主要来自跨进程通信，先检查通信模型。
绑定不是万能补丁。
能被绑定的只是线程。不能被绑定的是错误的架构。
结论
CPU 亲和性绑定的实现并不复杂。
查询可以使用 taskset -p <PID> 和 taskset -cp <PID>。启动时可以使用 taskset -c <CPU_LIST> <COMMAND>。代码层可以使用 sched_setaffinity(2) 或 pthread_setaffinity_np(3) 完成线程级绑定。
真正复杂的是边界设计：
- 绑定进程，还是绑定线程。
- 一个核心承载多少关键任务。
- 超线程兄弟核心是否避开。
- 线程与内存是否位于同一 NUMA 节点。
- 普通任务和中断是否离开关键核心。
- 是否需要组合
isolcpus、nohz_full和rcu_nocbs。 - 绑定后 P99.9 是否真的下降。
- 配置能否在重启后自动恢复。
- 结果能否在不同硬件和内核环境中复现。
验证必须基于数据。使用 perf 观察 sched_switch，按线程记录运行位置，按分位数比较延迟。不要根据命令执行成功推断系统已经完成优化。
参数优化的建议是逐层进行。先处理线程迁移，再处理 NUMA，再处理内核噪声，最后处理中断和应用内部竞争。每次只改变一组参数。保留基线。避免在单一测试样本上过拟合。
模型和系统都有边界。CPU 亲和性可以降低调度不确定性，但不会消除所有尾部延迟。最终性能取决于线程布局、缓存局部性、内存拓扑、网络路径、内核配置和交易接口的共同结果。
Related reading: 无锁队列与RingBuffer：低延迟交易系统的内存级优化原理 and 量化交易服务器的部署抉择：物理托管与云服务器的延迟与成本博弈.