hyper-v 70万nat会话数流量分析

结合你前面提供的所有数据（Hyper-V、sar、conntrack、iptables NAT），已经基本可以定位问题方向了。 

 一、当前流量路径 

 你的架构大概是： 

 互联网

 │

 ▼

rulr-4 / rulr-5（NAT代理）

 │

 ├── rulr2-01

 ├── rulr2-02

 └── rulr2-03

 

 外部约 60 万 NAT 会话： 

 rulr-4 ≈ 36万

rulr-5 ≈ 34万

 

 合计： 

 ≈ 70万连接

 

 与描述的60万级连接基本一致。 

 

 二、最重要的发现 

 从 sar -n SOCK 看： 

 rulr-4 

 367779

365949

367271

369945

 

 约： 

 36~37万 Socket

 

 

 rulr-5 

 338756

341389

344627

344251

 

 约： 

 33~34万 Socket

 

 

 但是后端： 

 rulr2-01 

 803

810

 

 只有： 

 800个连接

 

 

 rulr2-02 

 118000

122000

 

 约： 

 12万连接

 

 

 rulr2-03 

 117000

123000

 

 约： 

 12万连接

 

 

 说明： 

 rulr2-02

rulr2-03

承担主要业务连接

rulr2-01

几乎没接到流量

 

 负载均衡根本没均匀。 

 

 三、iptables输出暴露的问题 

 你贴出的 NAT 表： 

 75M 3632M DNAT tcp dpt:6031

 

 这一条特别异常： 

 75M packets

3632M bytes

 

 而其它规则： 

 6100

6101

6102

...

 

 只有几千包。 

 

 说明： 

 6031端口承担了绝大部分业务。 

 例如： 

 6031

 ↓

172.18.0.200

 ↓

容器

 ↓

rulr2-02/rulr2-03

 

 

 因此真正热点在： 

 6031

 

 不是整个代理。 

 

 四、网络是否到瓶颈 

 根据你之前的 sar： 

 eth0 

 rxkB/s ≈ 200

txkB/s ≈ 180

 

 即： 

 200 KB/s

 

 换算： 

 ≈ 1.6 Mbps

 

 

 即便考虑采样误差： 

 < 10 Mbps

 

 

 而宿主机是： 

 Intel 82599

10G

 

 所以： 

 10Gbps

↓

实际只有几Mbps

 

 差了上千倍。 

 

 结论： 

 ❌ 不是带宽瓶颈 

 

 五、Hyper-V数据也证明不是网卡瓶颈 

 你抓到： 

 Packets Received/sec

3066

 

 仅： 

 3000 PPS

 

 

 10G网卡正常能承受： 

 100万 PPS以上

 

 

 当前： 

 3000 PPS

 

 连 1% 都不到。 

 

 六、CPU中断情况 

 你抓到： 

 % DPC Time

Total:

0.52%

 

 

 说明： 

 网卡中断压力极低

 

 如果真是网卡瓶颈： 

 DPC

20%

30%

40%

 

 都常见。 

 

 你这里只有： 

 0.5%

 

 非常健康。 

 

 七、真正可疑的地方 

 从目前证据看： 

 网络没满 

 网卡没满 

 CPU没满 

 conntrack没满 

 端口没满 

 

 最可疑的是： 

 NAT状态表查找开销 

 你目前： 

 rulr-4

≈37万连接

rulr-5

≈34万连接

 

 

 虽然： 

 nf_conntrack_max=1048576

 

 没到上限。 

 但是： 

 30~40万活跃连接

 

 已经足以让： 

 conntrack hash

NAT lookup

 

 消耗明显 CPU。 

 

 建议查看： 

 conntrack -S

 

 重点看： 

 insert_failed

drop

early_drop

search_restart

 

 

 八、进一步验证 

 在晚高峰（20:00~22:00）执行： 

 sar -n TCP,ETCP 60

 

 看： 

 active/s

passive/s

retrans/s

 

 

 特别关注： 

 retrans/s

 

 如果： 

 >100

>1000

 

 说明开始拥塞。 

 

 再看： 

 sar -n DEV 60

 

 重点： 

 %ifutil

 

 

 如果： 

 <10%

 

 则绝对不是带宽问题。 

 

 九、我目前的判断 

 综合所有证据： 

 

 

 

 项目 

 状态 

 

 

 

 

 10G物理网卡 

 正常 

 

 

 Hyper-V交换机 

 正常 

 

 

 宿主机CPU 

 正常 

 

 

 DPC中断 

 正常 

 

 

 虚拟机带宽 

 正常 

 

 

 nf_conntrack_max 

 充足 

 

 

 ip_local_port_range 

 充足 

 

 

 NAT连接数 

 偏高 

 

 

 后端负载均衡 

 明显不均衡 

 

 

 

 最大的异常反而是： 

 rulr2-01 ≈ 800连接

rulr2-02 ≈ 12万连接

rulr2-03 ≈ 12万连接

 

 这说明后端负载均衡没有真正做到 1:1:1 分流。 

 下一步我建议直接查看 rulr-4/rulr-5 上负责分流到 rulr2-01、02、03 的具体 iptables（或 haproxy/nginx）配置，包括： 

 iptables-save

 

 或者： 

 iptables -t nat -S

 

 中涉及 rulr2-01、rulr2-02、rulr2-03 的 DNAT 规则。 

 把这部分贴出来，我可以直接帮你计算实际流量命中比例，并判断为什么 rulr2-01 几乎没有接到会话。