一、硬件瓶颈定位：CPU架构与缓存影响、内存带宽与NUMA架构、网卡与中断亲和性、存储IO性能
做量化交易系统，说白了就是跟硬件打交道。你策略再牛，代码再优雅，硬件瓶颈一卡，延迟直接飙上去。我这些年踩过的坑，十有八九都跟硬件有关。今天咱们就把这四大硬件瓶颈掰开揉碎了聊。
1.1 CPU架构与缓存影响
CPU这东西，看着简单，其实门道很深。我刚开始做高频交易时，总觉得CPU主频越高越好。后来发现，缓存命中率才是真正的杀手锏。
现代CPU的缓存分三级：L1、L2、L3。L1最快，但只有几十KB；L3慢一些，但有几MB到几十MB。你的数据如果在L1里，访问延迟只有几个纳秒。如果跑到内存里去了，那就是几十甚至上百纳秒。你想想看，这差距有多大？
核心原则：量化交易的核心数据结构，必须尽量塞进L1/L2缓存。比如订单簿的深度数据、行情快照，能小就小，能紧凑就紧凑。
我在项目中遇到过一个问题：同一个订单簿数据，用结构体数组存，比用数组结构体存，性能差了3倍。为什么？因为结构体数组在内存里是连续存放的，CPU预取器能很好地工作。而数组结构体，各个字段分散在不同地方，缓存一miss，延迟就上去了。
// 推荐：结构体数组（SoA）
struct Order {
int64_t price;
int32_t volume;
int64_t timestamp;
};
Order orders[10000];
// 不推荐：数组结构体（AoS）
struct Orders {
int64_t price[10000];
int32_t volume[10000];
int64_t timestamp[10000];
};小技巧：用__builtin_prefetch手动预取数据。比如在遍历订单簿时，提前把下一层的数据拉到缓存里。我试过，能再降5-10%的延迟。
1.2 内存带宽与NUMA架构
内存带宽，说白了就是内存能多快地把数据喂给CPU。量化交易里，行情数据量巨大，尤其是全市场快照，一次可能就几十MB。如果内存带宽不够，CPU就得干等着。
NUMA架构，嗯，这里要注意。现代服务器都是多路CPU，每个CPU有自己的内存控制器。访问本地内存快，访问远端内存慢。我曾经在一个4路服务器上跑策略，结果发现延迟忽高忽低。查了半天，原来是内存分配到了远端节点上。
避坑指南：我曾经犯过一个错误——用默认的malloc分配内存，结果线程跑在CPU0上，内存却分配在CPU1上。每次访问都要跨NUMA节点，延迟直接翻倍。后来改用numa_alloc_local，问题就解决了。
怎么检查NUMA情况？用numactl --hardware看看节点分布。我建议把交易线程和内存绑定到同一个NUMA节点上。比如：
# 绑定到NUMA节点0
numactl --cpunodebind=0 --membind=0 ./trading_engine还有一个容易被忽略的点：内存带宽的峰值和实际可用带宽是两码事。我测过，DDR4-3200理论带宽是25.6GB/s，但实际跑满也就20GB/s左右。如果多个核心同时读写，带宽还会被争抢。所以，量化交易系统里，能少拷贝就少拷贝，能零拷贝就零拷贝。
1.3 网卡与中断亲和性
网卡是交易系统的入口。行情数据从网线进来，到应用层处理，中间经过的每一跳都可能是瓶颈。我见过最夸张的情况：一个网卡中断，把CPU0打满了，其他核心闲着，但行情就是处理不过来。
为什么会这样？因为默认情况下，网卡中断都发到CPU0上。如果CPU0忙着处理中断，就没空跑你的交易逻辑了。解决方案是中断亲和性——把中断分散到多个核心上。
核心做法：用set_irq_affinity脚本，把网卡队列的中断绑定到不同的CPU核心上。比如4队列的网卡，绑定到CPU0-3。这样每个核心处理自己的中断，互不干扰。
我记得有一次调优，把中断亲和性从默认改成手动绑定后，行情处理的吞吐量直接提升了30%。而且延迟的抖动也小了很多。嗯，这个优化几乎是零成本，但效果立竿见影。
# 查看网卡中断号
cat /proc/interrupts | grep eth0
# 绑定中断到CPU0-3
echo 1 > /proc/irq/中断号/smp_affinity
echo 2 > /proc/irq/中断号/smp_affinity
echo 4 > /proc/irq/中断号/smp_affinity
echo 8 > /proc/irq/中断号/smp_affinity进阶技巧：用DPDK或Solarflare的OpenOnload，把网卡驱动绕开内核，直接在用户态收发包。延迟能从几十微秒降到几微秒。当然，代价是代码复杂度上去了。
1.4 存储IO性能
存储IO，很多人觉得不重要。交易系统嘛，数据都在内存里，磁盘用得少。但别忘了，日志、回测数据、盘后清算，这些都得读写磁盘。如果IO性能不行，回测跑一天都出不来结果。
存储IO的瓶颈主要在两方面：延迟和吞吐量。机械硬盘延迟是毫秒级的，SSD是微秒级的，NVMe是几十微秒级的。做量化交易，我建议至少用NVMe SSD。如果预算够，上Intel Optane，延迟能压到10微秒以内。
我曾经用SATA SSD跑回测，一个月的行情数据要读好几个小时。换成NVMe后，同样的数据，十几分钟就读完了。你想想看，这效率差距有多大？
避坑指南：我曾经以为NVMe SSD随便用就行，结果发现写入放大效应严重。频繁的小块写入，会让SSD寿命急剧下降。后来改用顺序写入，并且把日志缓冲区调到1MB以上，问题才解决。
还有一个容易被忽略的点：文件系统的选择。我推荐用XFS或Ext4，不要用ZFS或Btrfs。为什么？因为后两者有写时复制（CoW）特性，小文件写入性能很差。量化交易里，日志文件都是追加写入，XFS的延迟更稳定。
# 查看磁盘IO性能
iostat -x 1
# 重点关注：
# %util - 磁盘利用率，超过80%说明有瓶颈
# await - IO平均延迟，NVMe应小于1ms
# svctm - IO服务时间，越小越好知识体系总览
下面这张图，是我总结的硬件瓶颈定位框架。你可以把它当成一个检查清单，遇到性能问题时，按图索骥。
这张图把四大硬件瓶颈串起来了。你从交易系统性能出发，沿着箭头往下找，就能定位到具体是哪个环节出了问题。我个人习惯是：先看CPU缓存命中率，再看内存带宽，然后查网卡中断，最后才看存储IO。按这个顺序排查，90%的问题都能找到根因。
好了，硬件瓶颈定位就聊到这儿。记住一句话：量化交易系统的性能，不是靠堆硬件堆出来的，而是靠对硬件的理解一点点抠出来的。下一章咱们聊聊软件层面的性能剖析，到时候见。