3、延迟监控实战：网卡/交换机/操作系统层面的延迟打点
延迟，是高频交易系统的命门。
我见过太多团队，花大价钱买了最好的硬件，结果延迟反而比隔壁用普通设备的团队还高。为什么？因为延迟不是买来的，是「测」出来的。你不去监控它，它就躲在角落里给你使绊子。
这一章，咱们就聊聊延迟监控怎么落地。从网卡到交换机，再到操作系统内核，一层一层扒开来看。
3.1 网卡层面的延迟打点
网卡是数据进入服务器的第一道门。我习惯在网卡驱动层面就打上时间戳，而不是等到数据到了应用层再算。为什么？因为应用层的时间戳已经被操作系统调度、中断处理、上下文切换污染过了。
核心思路：在网卡收到数据包的瞬间，由硬件或驱动打上时间戳。这个时间戳越靠近物理层，越真实。
具体怎么做？
- 硬件时间戳（PTP）：支持IEEE 1588的网卡，可以直接在MAC层打时间戳。精度在纳秒级。
- 驱动层打点：在网卡驱动的中断处理函数中，用
ktime_get_ns()记录时间。虽然比硬件时间戳慢一点，但比应用层准得多。 - Solarflare/Exablaze 网卡：这些专为低延迟设计的网卡，提供了用户态直接访问时间戳的能力。我建议优先用这个。
我的经验：曾经有个项目，应用层延迟波动很大。我们怀疑是网卡问题，但应用层时间戳看不出来。后来在驱动层加了打点，发现是网卡中断亲和性没配好，导致中断在不同CPU之间漂移。调整之后，延迟抖动直接降了60%。
3.2 交换机层面的延迟打点
交换机是另一个容易被忽视的延迟来源。很多人觉得交换机就是「透传」，其实不然。交换机的转发延迟、队列延迟、甚至端口协商速度，都会影响整体延迟。
怎么监控交换机延迟？
- 交换机内置的延迟统计：像Cisco Nexus、Arista这些高端交换机，都支持基于流的延迟统计。开启
show latency之类的命令，可以看到每个端口的转发延迟。 - 双向时间戳对比：在发送端和接收端同时打时间戳，然后计算差值。这需要两端的时间同步（PTP或GPS）。
- 带内网络遥测（INT）：这是比较新的技术。数据包经过每个交换机时，都会被打上时间戳。最终接收端可以拿到完整的路径延迟。
注意：交换机的延迟统计通常是毫秒级的，对于高频交易来说不够细。我建议把交换机延迟作为「趋势监控」指标，而不是「实时告警」指标。真正要盯的，还是网卡和操作系统层面的纳秒级延迟。
3.3 操作系统层面的延迟打点
操作系统是延迟的「重灾区」。中断处理、上下文切换、锁竞争、内存分配……每一个环节都可能引入微秒甚至毫秒级的延迟。
我常用的操作系统延迟打点方法：
- ftrace：Linux内核自带的追踪工具。可以追踪函数调用、中断、调度等。精度在微秒级。
- perf：性能分析工具。可以统计CPU周期、缓存命中率、分支预测失败等。对定位延迟根因很有帮助。
- eBPF：这是目前最强大的延迟追踪工具。可以动态注入探针，采集纳秒级的时间戳。后面会详细讲。
关键点：操作系统层面的延迟打点，一定要区分「用户态」和「内核态」。因为用户态的时间戳和内核态的时间戳，精度和含义都不一样。
3.4 用户态与内核态的时间戳差异
这个问题我踩过坑。有一次，我发现用户态统计的延迟比内核态统计的延迟大了整整2微秒。排查了半天，才发现是时间戳来源不同。
用户态常用的时间戳函数：
clock_gettime(CLOCK_MONOTONIC, &ts)：精度在几十纳秒到几百纳秒之间。受系统调用开销影响。rdtsc：读取CPU的时间戳计数器。精度最高，但需要处理CPU频率变化和不同核心之间的偏移。gettimeofday：精度在微秒级。不推荐用于高频交易。
内核态常用的时间戳函数：
ktime_get_ns()：直接读取内核的时间管理模块。精度在纳秒级，且不受系统调用开销影响。jiffies：精度在毫秒级。太粗糙，不推荐。
| 时间戳来源 | 精度 | 开销 | 适用场景 |
|---|---|---|---|
| 用户态 clock_gettime | ~100ns | 中等 | 应用层延迟统计 |
| 用户态 rdtsc | ~10ns | 低 | 高频交易核心路径 |
| 内核态 ktime_get_ns | ~1ns | 低 | 驱动层/内核追踪 |
| 硬件时间戳 | ~1ns | 极低 | 网卡/交换机延迟监控 |
我的建议：如果你在做延迟对比，一定要确保用户态和内核态用的是同一个时间源。否则，你看到的「差异」可能只是时间戳函数本身的误差。
3.5 使用eBPF进行纳秒级延迟追踪
eBPF是近年来Linux内核最强大的观测工具。它可以让你在不修改内核代码、不重启系统的情况下，动态注入探针，采集任意内核函数的执行时间。
我常用的eBPF延迟追踪场景：
- 追踪系统调用延迟：比如
sendto、recvfrom这些高频交易常用的系统调用。 - 追踪中断处理延迟：网卡中断来了之后，内核花了多久才处理完。
- 追踪调度延迟：一个线程被唤醒后，等了多久才真正获得CPU。
- 追踪锁竞争延迟：一个线程在等待锁的时候，花了多少时间。
下面是一个简单的eBPF程序，用于追踪sendto系统调用的延迟：
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__uint(max_entries, 1024);
__type(key, __u32);
__type(value, __u64);
} start_map SEC(".maps");
SEC("kprobe/__x64_sys_sendto")
int trace_sendto_entry(struct pt_regs *ctx) {
__u32 pid = bpf_get_current_pid_tgid() >> 32;
__u64 start_time = bpf_ktime_get_ns();
bpf_map_update_elem(&start_map, &pid, &start_time, BPF_ANY);
return 0;
}
SEC("kretprobe/__x64_sys_sendto")
int trace_sendto_return(struct pt_regs *ctx) {
__u32 pid = bpf_get_current_pid_tgid() >> 32;
__u64 *start_time = bpf_map_lookup_elem(&start_map, &pid);
if (start_time == 0) {
return 0;
}
__u64 delta = bpf_ktime_get_ns() - *start_time;
bpf_printk("sendto latency: %lld ns\n", delta);
bpf_map_delete_elem(&start_map, &pid);
return 0;
}
char LICENSE[] SEC("license") = "GPL";这段代码做了什么？
- 在
sendto系统调用入口处，记录当前时间戳和进程ID。 - 在
sendto系统调用返回处，计算时间差，并打印出来。 - 精度在纳秒级，而且开销极低（微秒级别）。
注意：eBPF虽然强大，但也不是万能的。它不能追踪所有内核函数（有些函数被内联了），而且在高频调用场景下，eBPF程序本身的开销也会累积。我建议只在关键路径上使用eBPF，不要全量开启。
3.6 延迟监控的整体架构
说了这么多，咱们来画一张图，把整个延迟监控的体系串起来。
这张图展示了延迟监控的四个层次：
- 物理层：最底层，精度最高。网卡硬件时间戳和交换机延迟统计是核心。
- 内核层：中间层，eBPF是主力工具。可以追踪驱动、中断、系统调用等。
- 用户态：最上层，应用层延迟统计。rdtsc是精度最高的选择。
- 监控与告警层：把前三层的数据汇总，形成趋势图和告警。
我的经验：不要试图用一个工具解决所有问题。物理层用硬件时间戳，内核层用eBPF，用户态用rdtsc。各司其职，才能把延迟监控做到极致。
3.7 避坑指南
最后，分享几个我踩过的坑：
- 时间不同步：多台机器之间做延迟对比，一定要确保时间同步。我建议用PTP，精度在亚微秒级。NTP太粗糙，不推荐。
- 时间戳函数选择不当：用户态用
gettimeofday，精度只有微秒级，而且可能受NTP调整影响。用clock_gettime(CLOCK_MONOTONIC)或者rdtsc。 - eBPF探针过多：eBPF虽然开销低，但探针多了也会影响性能。我建议只追踪关键路径，比如
sendto、recvfrom、网卡中断处理函数。 - 忽略CPU频率变化：用
rdtsc时，要注意CPU频率可能动态变化（比如Intel的Turbo Boost）。需要用cpufreq或者acpi来校准。
曾经有一次：我在生产环境上开启了全量eBPF追踪，结果导致系统延迟增加了5%。排查了半天，才发现是eBPF程序在频繁调用bpf_printk，把日志写到了/sys/kernel/debug/tracing/trace_pipe里。这个操作是同步的，而且会触发锁竞争。从那以后，我都是把数据写到BPF map里，然后定期读取，而不是实时打印。
嗯，延迟监控这块，说白了就是「测准了才能调准」。从网卡到交换机，再到操作系统内核，每一层都不能放过。eBPF是当前最强大的工具，但也要用得巧，不能滥用。
下一章，咱们聊聊「内存延迟监控」。别以为内存很快，在高频交易的世界里，一次Cache Miss就可能让你损失几微秒。到时候见。
公众号:蓝海资料掘金营，微信deep3321