你碰到的这个问题其实是实时线程调度里的典型陷阱——看似调高优先级能让线程更“抢资源”，反而因为RT调度的带宽限制导致被强制休眠，拖垮了整体延迟。结合你的硬件（i5-10600KF，6核12线程，单NUMA节点）、Ubuntu环境和基准数据，我给你梳理几个分层的优化方向，这些都是低延迟领域的常规操作，从代码小调整到OS深度配置都有：

一、先验证：确认是不是RT Throttling在搞鬼 #

你怀疑RT Throttling是核心问题，这方向是对的，先做验证再动手优化：

1. 检查系统RT调度带宽限制：
   Ubuntu默认对RT线程有带宽控制，通过sysctl查看当前参数：

   sysctl kernel.sched_rt_period_us kernel.sched_rt_runtime_us
   

   默认值通常是period=100000（100ms周期），runtime=95000（95ms内RT线程可运行，剩下5ms必须让给非RT线程）。如果你的两个RT线程占满了CPU时间，就会被强制休眠5ms左右，这刚好能解释你看到的13ms级尾延迟。
2. 临时关闭带宽限制做测试：
   执行以下命令临时关闭限制（仅用于测试，生产环境谨慎）：

   sudo sysctl -w kernel.sched_rt_runtime_us=-1
   

   再跑一次基准测试，如果延迟回到之前的水平，就坐实了RT Throttling的问题。

二、优化方向：从软件小调整到OS深度配置 #

（一）代码/应用层：小改动，快速见效 #

1. 调整RT调度策略与优先级
   • 试试用SCHED_RR（轮转调度）代替SCHED_FIFO：SCHED_FIFO下高优先级线程一旦拿到CPU，除非主动放弃或被更高优先级线程抢占，否则会一直占用CPU。如果你的生产者线程长时间霸占核心，消费者线程会被阻塞很久。SCHED_RR会给同优先级的RT线程分配时间片，避免单线程独占CPU。
   • 合理设置优先级：不需要把优先级设到70这么高，Ubuntu默认允许的RT优先级范围是1-99，给你的两个线程设置中等优先级（比如30、31）即可，避免和系统可能存在的高优先级RT线程（比如某些硬件驱动）冲突。
2. 精细化线程亲和性
   你已经做了核心绑定，但可以更精准：
   • 把生产者、消费者分别绑定到不同的物理核心（避免超线程核心，先关闭超线程更稳妥），且优先选同一socket内的核心（你的CPU是单socket，所以所有核心共享L3缓存，能减少缓存一致性开销）。
   • 绑定后用taskset或perf验证：比如taskset -p <pid>查看线程实际绑定的核心。
3. 无锁队列本身的迭代优化
   虽然你要的是方向，但可以关注这些低延迟队列的通用优化点：
   • 避免伪共享：把队列的读写指针、缓冲区分别用alignas(64)做缓存行对齐，防止不同线程的变量挤在同一个缓存行里导致频繁缓存失效。
   • 弱化内存序：把原子操作的内存序从std::memory_order_seq_cst降到std::memory_order_release（生产者写指针）和std::memory_order_acquire（消费者读指针）——SPSC场景下不需要全局内存顺序，只需要保证生产者和消费者之间的可见性，弱化内存序能减少内存屏障的开销。
   • 批量处理：如果业务允许，改成批量生产/批量消费（比如一次处理100个元素），能摊薄调度和内存访问的固定开销，显著降低平均延迟和尾延迟。
4. 基准测试的精度优化
   确保你用的是高精度、无跳变的时钟：用clock_gettime(CLOCK_MONOTONIC_RAW, &ts)代替CLOCK_REALTIME，前者不受系统时间调整影响，精度能到纳秒级，避免时间戳跳变导致的错误延迟计算。

（二）OS层面：低延迟环境的标配操作 #

这些配置在高频交易、实时数据处理等低延迟场景中非常普遍，属于“必须做”的基础优化：

1. CPU核心隔离（Isolated CPUs）
   把用于运行SPSC线程的核心从系统全局调度器中隔离出来，不让内核把其他线程（包括内核线程如ksoftirqd、watchdog）调度到这些核心上：
   • 编辑GRUB启动配置：sudo nano /etc/default/grub，修改GRUB_CMDLINE_LINUX参数，比如要隔离核心2和3：

     GRUB_CMDLINE_LINUX="isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3"
     

     • nohz_full：让隔离核心进入“无滴答”模式，减少时钟中断的干扰
     • rcu_nocbs：不让RCU（内核同步机制）在隔离核心上运行
   • 更新GRUB并重启：

     sudo update-grub
     sudo reboot
     

   • 重启后把你的生产者、消费者线程绑定到隔离的核心2、3上。
2. 关闭不必要的系统功能
   • 关闭超线程（HT）：超线程会让两个逻辑核心共享物理核心的执行资源，大幅增加延迟抖动，直接在BIOS中关闭即可。
   • 关闭透明大页（THP）：THP会导致突发的页分配延迟，执行：

     echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
     

   • 关闭Swap：Swap页交换会导致毫秒级的突发延迟，执行swapoff -a并注释/etc/fstab中的Swap条目。
   • 设置CPU为性能模式：避免CPU动态降频导致的延迟波动：

     echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
     

3. 中断亲和性调整
   把系统的硬件中断（比如磁盘、网络、时钟）绑定到非隔离核心，避免中断抢占隔离核心上的RT线程：
   • 用cat /proc/interrupts查看所有中断号
   • 把目标中断绑定到非隔离核心（比如核心0、1）：

     echo 0,1 | sudo tee /proc/irq/<中断号>/smp_affinity_list
     

   • 可以用irqbalance工具自动优化，但低延迟场景建议手动配置更精准。
4. 使用大页内存（HugeTLB）
   给SPSC队列分配2MB/1GB的大页内存，减少TLB（页表缓存） miss的开销：
   • 提前预留大页：

     sudo sysctl -w vm.nr_hugepages=1024  # 预留1024个2MB大页，共2GB
     

   • 在C++代码中用mmap分配大页：

     void* queue_buf = mmap(nullptr, QUEUE_SIZE, PROT_READ | PROT_WRITE,
                           MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);
     

三、验证与监控：每一步优化都要量化 #

低延迟调优是迭代过程，每做一个调整都要跑基准测试，同时用工具监控效果：

1. 用perf分析调度与缓存
   • 分析调度延迟：perf sched record ./your_benchmark，然后perf sched report查看线程被阻塞的原因
   • 分析缓存命中率：perf stat -e cache-misses,cache-references ./your_benchmark，缓存命中率低的话要调整线程亲和性或队列内存布局
2. 用top/htop监控隔离核心
   确保隔离核心上只有你的两个SPSC线程在运行，没有其他线程占用。
3. 用schedtool查看线程状态
   确认线程的调度策略和优先级是否符合预期：

   schedtool -p <your_thread_pid>
   

最后总结 #

你提到的OS层面配置（核心隔离、中断亲和性等）在低延迟环境中是标准操作，甚至是“入门级”要求——低延迟系统的性能瓶颈往往不在代码本身，而在OS的默认调度、中断、内存管理等机制的干扰。

建议你按这个顺序迭代优化：

1. 验证并解决RT Throttling问题
2. 优化线程亲和性与调度策略
3. 逐步推进OS层面的核心隔离、关闭不必要功能等配置
4. 最后迭代优化无锁队列的内存布局与原子操作细节

每一步都跑基准测试，重点关注尾延迟（p99、p999）的变化——低延迟场景下，尾延迟比平均延迟重要得多。