跳转到内容
Aeron Tuning

传输性能影响因素及其作用

有十个因素会影响 Aeron Transport 的性能。它们构成一个层级栈——从顶层的协议到底层的硬件——你应当大致按照这个顺序进行调优。本页将每个因素映射到它真正撬动的那个指标：吞吐量、p50（中位数）或 p99（尾延迟）。

按层级划分的十大因素

Section titled “按层级划分的十大因素”

这些因素从协议层向下堆叠至硬件层。在动用上层旋钮之前，先把底层基础打牢。

协议与缓冲区调优

Section titled “协议与缓冲区调优”
  1. Initial Window Size——控制在需要 ACK 之前可以有多少数据处于在途（in-flight）状态。
  2. NAK / 重传定时器——接收方在为间隙发出 NAK 之前等多久（以及发送方在再次重传之前等多久）。 在组播语义的流上（IP 组播、MDC、Cluster 日志通道），默认 10 ms 退避让 每一次 残余丢包 都变成 10–20 ms 的尾部事件——见 NAK 定时器调优。
  3. Term Buffer Size——每次 term 轮换的日志缓冲区大小。

操作系统与驱动层

Section titled “操作系统与驱动层”
  1. OS Network Send/Receive Buffer Size——即内核套接字缓冲区 SO_SNDBUF / SO_RCVBUF。
  2. ENA Send/Receive Buffer Size——AWS Elastic Network Adapter 的环形缓冲区深度。

硬件亲和性

Section titled “硬件亲和性”
  1. CPU Near the NIC Card——处理核心与网络接口之间的 NUMA 局部性。
  2. Term Buffer Fits into the CPU’s L3 Cache——让热点数据驻留在缓存中，而非溢出到 DRAM。

系统层

Section titled “系统层”
  1. Kernel Overhead / Bypass——消除内核网络协议栈（高级方案：ef_vi / DPDK / VMA）。
  2. Thread Pinning / Core Isolation——把 CPU 核专用于 Aeron 线程，防止调度器干扰——见 核心隔离与线程绑定。
  3. Resource Utilization (CPU / Bandwidth)——将利用率保持在饱和点以下，以便吸收抖动。

利用率之所以如此重要，原因在于响应时间曲线的形状。对单服务器排队模型，响应时间大致按 1 / (1 − ρ) 增长：低利用率时平缓，随后在 约 70% 处出现拐点（解析值 ≈71.5%）。并不存在某个神奇的”安全”数值—— 到 80% 时延迟已是空载基线的 约 5 倍（50% → 2×，70% → 3.3×，90% → 10×，95% → 20×）。对延迟敏感的系统应当运行在 拐点 以下——通常 50–70%——从而保留吸收突发的余量；若贴近饱和”高负荷”运行，尾部就会爆炸式恶化。

这是一条经验法则，而非常量。它适用于 单队列 / 每核 / 每流的热路径 且到达呈突发性的场景。有两点会抬高安全上限： 多核 / 多服务器池（更多并行服务器使队列在更晚才形成，因此一个集群可运行在 80–90%）， 以及 确定性或批处理的服务（固定成本的工作其排队惩罚只有随机时长工作的一半——这正是 Aeron 的 智能批处理 能在不抬高尾部的前提下维持高利用率的原因）。 要同时做到”高利用率 且 低尾延迟”，真正的解法是通过批处理消除到达的随机性，而非追逐某个固定百分比。

单服务器排队模型下响应时间与利用率的关系（∝ 1/(1−ρ)）：约 70–85% 的拐点区间，其下方是推荐的低延迟运行区；在 80% 时延迟已约为基线的 5 倍

每个因素如何撬动各项指标

Section titled “每个因素如何撬动各项指标”

下面这张星级评分矩阵展示了每个调优参数对吞吐量、p50 和 p99 延迟的相对影响。星越多，意味着这个杠杆越大。

ParameterThroughputp50 Latencyp99 / Tail Latency
Initial Window Size⭐⭐⭐⭐⭐
NAK / 重传定时器⭐⭐⭐⭐⭐ †
Term Buffer Size⭐⭐⭐⭐⭐
OS Network Send/Receive Buffer Size⭐⭐⭐⭐⭐
ENA Send/Receive Buffer Size⭐⭐⭐⭐⭐
CPU Near the NIC Card (NUMA-local)⭐⭐⭐⭐⭐⭐⭐
Term Buffer Fits into L3 Cache⭐⭐⭐⭐⭐⭐⭐
Kernel Bypass⭐⭐⭐⭐⭐⭐⭐⭐⭐
Thread Pinning / Core Isolation⭐⭐⭐⭐⭐⭐⭐
JVM Prewarm (JIT Warmup)⭐⭐⭐⭐⭐⭐

† 限组播语义的流（MDC、IP 组播、Cluster 日志通道）且存在残余丢包 时。实测：相同种子的 0.01% 丢包，默认定时器 → p99.9 为 8,286 µs；推导后的定时器 → 105 µs（约 79 倍）。零丢包时 定时器毫无作用——它们封顶的是丢包的 代价，不是丢包的概率。

这张矩阵告诉你什么

Section titled “这张矩阵告诉你什么”

从评分中可以归纳出五条规律：

  1. 内核旁路是唯一在三列上都拿到 ⭐⭐⭐ 的因素。 它是撬动整体性能的最大单一杠杆。
  2. 硬件亲和性对 p99 的影响格外突出。 NUMA 局部性、L3 驻留和线程绑定在尾延迟上都拿到了 ⭐⭐⭐——因为尾延迟主要由缓存未命中、上下文切换和 NUMA 惩罚所主导。
  3. 协议参数主要影响吞吐量和 p99。 窗口、NAK 和缓冲区对 p50 的影响微乎其微；它们在高负载下才最为关键。 而且缓冲区拆成两根职责不同的杠杆：杠杆 A（缓冲区）预防丢包；杠杆 B（NAK 定时器）给丢包的代价封顶。 实测 A/B：一旦缓冲覆盖 BDP，16 倍大的缓冲逐百分位毫无变化——而在有丢包的流上，NAK 配置把 p99.9 拉动了约 79 倍。不要用更大的缓冲去买尾延迟；先把链路配够， 再用定时器调优去买。
  4. p50 相对容易优化；p99 才是真正费功夫的地方。 大多数 ⭐⭐⭐ 评分都落在 p99 这一列。
  5. JVM 预热是 p99 问题，而非吞吐量问题。 冷启动的 JIT 意味着最初的请求会命中解释执行的字节码和未编译的代码路径，在热点方法被编译完成之前会产生严重的尾延迟尖峰。

为什么尾延迟占主导

Section titled “为什么尾延迟占主导”

这一规律在每个参数上都反复出现：

  • p99 始终关乎规避方差——缓存未命中、队列深度、上下文切换、NUMA 惩罚。
  • p50 关乎降低每次操作的基线成本。
  • 吞吐量关乎让管道始终满载。

不同的参数撬动不同的杠杆，但硬件层面的那些——NUMA、缓存、内核旁路、绑定——对尾延迟的影响最为显著。

若想了解每个旋钮为什么会撬动吞吐量、p50 和 p99 的逐参数剖析，以及如何确定其取值，请继续阅读参数参考。