4. 吞吐量波动现象：典型表现、影响范围

大家好，我是这次实战课程的主讲。

咱们开始讲第4章。你可能已经装好了环境，跑通了基础的SM4加解密。但当你试着加压、长时间跑性能测试时，一个让人头疼的问题就冒出来了——吞吐量不稳定。

不是说好每秒能处理XXX MB吗？为什么跑着跑着，数字忽高忽低？甚至有时候直接腰斩？

嗯，这一章我们就专门来聊聊这个现象。从典型表现入手，再看看它会影响到哪些地方。

4.1 典型表现：你真的看懂波动了吗？

我个人习惯先看数据，而不是凭感觉。吞吐量波动，说白了就是单位时间内处理的数据量不一致。咱们用几个场景来描述它。

4.1.1 波形特征：锯齿、尖刺与断崖

从监控工具上看，波动有三种常见的“波形”：

• 锯齿状波动：吞吐量在平均值的±10%到±20%之间来回振荡。频率较高，像锯齿一样。我在项目中遇到过，这通常是系统负载和某个后台任务（比如内存回收、中断处理）在争抢资源。
• 尖刺状波动：大部分时间稳定，但每隔几秒或几十秒，吞吐量突然掉到谷底（比如从1000 MB/s掉到200 MB/s），然后又迅速恢复。你想想看，这种“断崖式”下跌最吓人。我曾经排查过一个案例，发现是网络中断调度延迟导致的。
• 阶梯状波动：吞吐量不是平滑变化的，而是突然降低一个台阶，然后稳定在新的水平。这种往往跟缓存失效、线程池扩容或锁竞争升级有关。

4.1.2 时间维度上的表现：短期波动 vs 长期漂移

这里还要区分两个时间尺度：

1. 短期波动（秒级~分钟级）：这是最常见的。比如每10秒出现一次吞吐量下降。我排查过很多次，发现大部分跟操作系统层面的调度有关，比如 kswapd 内存回收线程被唤醒，或者cgroups的CPU限额被临时收紧。
2. 长期漂移（分钟级~小时级）：吞吐量缓慢下降，最后稳定在一个较低水平。这种情况，我在处理一个长期运行的加密服务时遇到过。原因是什么？ 内存碎片化。随着时间推移，大页内存被不断分配释放，TLB（快表）命中率下降，导致每次加解密操作变慢。

4.1.3 与负载和参数的关系

波动还不是固定的。它会随着你的输入参数变化。

• 数据包大小敏感：加密小包时（比如每个包64字节），波动更容易出现。因为小包场景下，函数调用开销、上下文切换成本占比大。
• 线程数敏感：某个线程数下表现稳定，增加或减少几个线程，波动就出来了。这通常跟CPU核心的缓存共享和超线程干扰有关。
• 密钥调度敏感：我用不同密钥测试时，发现有些密钥的轮函数展开会导致指令执行路径更长，产生微妙的速度差异。

4.2 影响范围：从一条线程到整个集群

别以为吞吐量波动只是“数据不好看”。它带来的实际影响，往往超出你的预期。

4.2.1 算法层：SM4 轮函数自身的不稳定性

首先，SM4算法的实现本身有锅可背。

我记得有一次排查，发现一个很奇怪的现象：同样的SM4实现，在 Intel 处理器上波动很小，但在 ARM 上波动非常明显。后来发现是S盒查表导致的。S盒是个256字节的查找表。如果S盒在L1缓存里，查找很快。但如果因为上下文切换导致该L1缓存被冲掉，下次查表就要从L2甚至内存里读，延迟直接翻倍。

这就是 查表延迟敏感 问题。在SM4的轮函数中，查找表操作会执行32次。任何一次缓存未命中，都会拖慢整个轮次。

// 伪代码：SM4 轮函数中的S盒查表
// 这是最关键的路径
for (int i = 0; i < 32; i++) {
    // 这行代码，如果SboxCacheLine 不在L1缓存中，就会产生 ~100ns 的延迟
    uint32_t temp = Sbox[(uint8_t)(x0 >> 0)] ^ 
                    Sbox[(uint8_t)(x1 >> 8)] ^ 
                    Sbox[(uint8_t)(x2 >> 16)] ^ 
                    Sbox[(uint8_t)(x3 >> 24)];
    // ...
}

说白了，S盒查表的缓存局部性，直接决定了SM4吞吐量的稳定性。

4.2.2 指令级：向量化指令的“不情愿”

现代CPU的向量化指令（比如Intel的AES-NI指令集虽然不直接支持SM4，但我们可以用SSE/AVX来并行化处理多个数据块）。然而，**向量化指令对数据对齐和依赖性非常敏感**。

• 数据对齐：如果传入的数据是不对齐的，CPU会触发额外的对齐访问开销。这会导致指令执行时间从1个周期变成几个周期。波动由此产生。
• 数据依赖：SM4算法本身是一个串行迭代的Feistel网络。虽然我们可以将4个数据块打包同时处理（CBC模式不行，但CTR模式可以），但指令之间的依赖性仍然存在。我实测过，当代码中的 movdqa 指令使用错误，导致寄存器压力过大时，吞吐量会下降30%以上。

4.2.3 缓存层：TLB 抖动与 LLC 污染

这是影响范围最广的一层。SM4在高并发场景下，每个线程或进程都会使用自己的密钥和数据。如果操作系统分配给不同线程的内存页在不同NUMA节点上，或者页表被频繁换出，TLB的命中率就会下降。

TLB未命中，意味着每次内存访问都要查页表。这意味着持续的吞吐量下降。我曾经在一个64核服务器上测试，发现随着并发线程数增多，TLB未命中率从0.1%飙升到5%，吞吐量直接打折扣。

还有LLC（最后一级缓存）污染。数据量一大，加密轮次产生的中间结果会污染LLC，导致其他核心的缓存数据被强制逐出。这会引发跨核的缓存一致性协议开销。你想想看，多个核心之间为了争夺缓存行，要频繁发送缓存一致性消息，带宽都被协议开销吃掉了。

4.2.4 系统层：从单机到集群的连锁反应

如果你的系统是分布式的，而且SM4是作为RPC或数据流的一部分嵌入的，那么吞吐量波动的影响范围会更大。

• 上游感知：你能看到吞吐量下降50ms，但上游客户端看到的可能是超时重试。一次波动小，多次波动累计，就会引发客户端的雪崩效应。
• 负载均衡器困惑：负载均衡器如果基于CPU利用率或吞吐量做决策，连续的波动会触发错误的扩容/缩容操作，导致资源浪费或服务降级。
• 性能SLA违约：如果你的系统有性能SLA（服务水平协议），比如承诺每100ms处理1万个加密请求。那么一次严重的尖刺波动，就可能让你违反SLA。

下图展示了吞吐量波动在不同层面的影响范围和表现形式。

4.3 你的系统正在经历哪一级波动？

如果你正在排查一个具体的SM4吞吐量问题，我建议你做这样一个判断：