带宽只用了 30% 却大面积超时：云实例 PPS 上限被小包流量打满的定位与改造

结论先行：云实例的网络限速是「带宽 + PPS」双维度独立上限，小包场景下 PPS 几乎永远先打满——云监控里带宽曲线锯齿状没触顶、PPS 曲线却出现平顶（被限速），业务侧看到的却是「丢包 / 超时 / 设备离线」。这类故障 ping 正常、iperf 带宽能跑满、ethtool -S 无 rx_missed_errors，常规排障路径全部失效。

一、现象：带宽用了 30%，4.7% 设备心跳超时

去年 Q3 我们给一个 IoT 接入网关做扩容：单实例 4C8G，标称带宽 5 Gbit/s、PPS 上限 80 万/秒（云厂商规格页两个数字都明确写着）。业务是 32 万设备长连接，每台 30s 一次心跳（UDP 68B 包），峰值 QPS 约 1.1 万。

• 云监控面板：出方向带宽峰值 1.5 Gbit/s（占 30%）、收方向 0.9 Gbit/s（占 18%）——带宽维度远没到顶。
• 业务侧告警：32 万设备里，心跳超 10s 未 ACK 的占 4.7%（约 1.5 万设备），表现为「设备侧看到丢包」。
• 关键矛盾：带宽用了 30%，PPS 却已经 100% 打满。

二、根因：带宽和 PPS 是两条独立维度

云厂商对实例的网络限速是「双维度」，取先打满的那个生效：

• 带宽维度：单位时间 bit 数（Gbit/s）
• PPS 维度：单位时间 packet 数（packet/s）

小包场景下，PPS 几乎永远先打满。一个 68B UDP 心跳包 ≈ 68 × 8 = 544 bit，按 80 万 PPS 上限算：

800,000 pps × 544 bit = 435 Mbit/s

也就是说，PPS 上限 80 万 等价于 435 Mbit/s 的小包吞吐，远小于标称的 5 Gbit/s 带宽。

当时业务实际 PPS 构成（平均值）：

• 上行心跳：1.1 万 PPS
• 下行 ACK + 配置下发：0.8 万 PPS
• 内网转发（Kafka / DB，每次心跳拆 3~4 包）：4.2 万 PPS
• 控制面（监控 / 日志）：0.6 万 PPS
• 合计 ≈ 6.7 万 PPS

看着离 80 万还有余量——但这是平均值。凌晨设备重连风暴 + 配置批量下发时，峰值 PPS 冲到 92 万，直接打爆限速。

三、定位：4 条命令 + 1 个面板

# 1) 看网卡实时 pps（每秒采样）
sar -n DEV 1 5
# 关注 rxpck/s 和 txpck/s 两列，不要只看 rxkB/s

# 2) 看累计计数（差值即 PPS）
ip -s link show eth0 | grep -E 'RX|TX'

# 3) 抓 10 秒包，统计实际包长分布
tcpdump -i eth0 -s 96 -w /tmp/cap.pcap -c 100000
tshark -r /tmp/cap.pcap -q -z io,phs
# 看 "Average bytes per frame"，若 < 100B，PPS 维度基本就是瓶颈

# 4) 云监控面板：「网络收发包速率(PPS)」与「网络带宽(Mbps)」两条曲线并排看
#    谁先触顶谁就是瓶颈

当时的关键证据：

• sar -n DEV 峰值 rxpck/s = 912,340（超过 80 万上限）
• rxkB/s = 186,200（≈ 1.5 Gbit/s，占 30%）
• 云监控 PPS 曲线在 92 万处出现平顶（被限速），带宽曲线是锯齿状（没触顶）

四、改造：4 招，按落地成本从低到高

1. 合并小包（成本最低，收益最大）：把 30s 一次心跳改成 10s 一次 + 批量下发配置，QPS 直接降 3 倍，峰值 PPS 从 92 万 → 31 万，离上限 61% 余量。
2. 开启 GRO/TSO（零成本）：

   ethtool -K eth0 gro on gso on tso on
   

   注意：GRO 是收侧聚合（把多个小包合成一个大包给协议栈），能直接降低内核看到的 PPS；TSO 是发侧拆分，对云侧 PPS 上限没帮助（云侧看到的是拆分后的物理包）。
3. 换更大规格（中等成本）：同族 8C16G 规格 PPS 上限 160 万、带宽 10 Gbit/s，直接翻倍。
4. 多实例 + SLB 分摊（高成本但最稳）：3 台 4C8G + L4 SLB，每台 PPS 压力降到 30 万以内；SLB 本身 PPS 上限 200 万，不构成新瓶颈。

五、踩过的坑（反直觉之处）

1. NAT 网关 / SLB 有独立的 PPS 上限，且通常比后端实例更紧。我们第一次换大规格后，瓶颈从「实例 PPS」转移到「NAT 网关 PPS」，症状一模一样，监控要一路看到网关侧。
2. 抓包看到的 PPS ≠ 云侧限速看到的 PPS：VXLAN / Geneve 隧道封装会把 1 个内网包变成 2~3 个外层包，网关侧看到的 PPS 是客户端的 2~3 倍。
3. GRO 开 ≠ PPS 上限提升：GRO 降低的是「内核协议栈处理的 PPS」，云侧限速看的是「物理网卡看到的 PPS」，两者不是一回事。
4. 峰值 vs 均值：云厂商 PPS 限速是滑动窗口（通常 5s 或 60s），不是瞬时。「平均 6 万 PPS 没事，峰值 92 万 PPS 必炸」——监控要看 P99，不要看均值。
5. iperf 带宽能跑满 ≠ 实例没被限速：iperf 默认大包（1400B+），PPS 维度远没到顶，带宽维度能跑满；但换成 64B 小包，PPS 立刻打满。压测必须按业务真实包长。

六、结论 & 可复用清单

• 容量规划公式：pps_needed = qps × packets_per_req × (1 + 内网转发放大系数)，对比实例 PPS 上限，留 30% 余量。
• 监控双维度：带宽（bit/s）+ PPS（packet/s）两条曲线并排看，谁先触顶谁是瓶颈；告警阈值分别配，不要只配带宽。
• 小包业务（心跳 / 控制面 / IoT / 微服务 RPC）：优先合并请求、开启 GRO，其次再考虑升规格——合并请求的 ROI 远高于升规格。
• 抓包验证：tshark -q -z io,phs 看平均包长，< 100B 基本就是 PPS 维度瓶颈，别再去查带宽。
• 压测纪律：压测工具（iperf / wrk / locust）必须按业务真实包长跑，否则「带宽能跑满」的结论在 PPS 维度是无效的。

一句话总结：云实例的网络容量不是「带宽」一个数字，而是「带宽 × PPS」两条独立的上限曲线——你看到的带宽余量，可能只是 PPS 已经打满的烟雾弹。