Skip to main content

rulr-4 / rulr-5 的问题拆解

下面我按**“conntrack异常 + 网络路径 + Docker/iptables结构 + 差异对比”**四个层面，把 rulr-4 / rulr-5 的问题拆解清楚，并给出结论。

一、核心结论（先说重点）

两台机器的共同问题是：

1）conntrack “命中正常但插入完全失败”

两台都有典型特征：

  • insert=0

  • insert_failed 极高

  • drop == insert_failed 完全一致

👉 说明不是“丢包问题”，而是：

conntrack 表处于高压/冲突/不可插入状态（典型：hash冲突 + 表竞争 + bucket/GC压力）

2）流量结构是“Docker NAT + 高并发短连接”

特征：

  • eth0 PPS：1300~3500 pps

  • Docker bridge 转发活跃

  • conntrack found 数量极高（十亿级累计）

  • TIME_WAIT / Established 很低（说明短连接或代理转发）

👉 本质是：

L4 NAT代理（nginx tcp / docker DNAT）+ 高频连接建立/释放

3）CPU级 conntrack drop 在8核上均匀爆炸

例如 rulr-5：

  • cpu0~cpu7 drop：1,000万~2,100万级

  • search_restart大量存在

👉 说明：

不是单核问题，是全局 hash table 争用 / bucket 冲突 / lock竞争

二、关键异常点拆解

1. conntrack insert_failed = drop（100%一致）

rulr-4

insert_failed=7390187
drop=7390187

rulr-5

insert_failed=14861324
drop=14861324

👉 结论非常关键：

conntrack 新连接“完全无法建立状态记录”

但：

  • found 极高 → 查询是正常的

  • 说明：已有连接还能用，但新流状态创建失败

2. nf_conntrack 参数异常点

rulr-4

nf_conntrack_tcp_timeout_established = 3600

rulr-5

nf_conntrack_tcp_timeout_established = 86400

👉 rulr-5 风险更高：

  • 86400 = 24小时

  • 连接表保留时间过长

影响：

conntrack table “存活连接暴涨 + hash压力持续累积”

3. NAT/iptables结构问题（非常关键）

两台都有：

DNAT + MASQUERADE + Docker bridge

例如 rulr-5：

POSTROUTING MASQUERADE (172.18.0.0/16)
DNAT 80/443/6100-6109 → 172.18.0.200

👉 这是典型：

“Docker NAT + 端口代理 + 二次转发”结构

问题在于：

❗ 双重NAT路径

Client → eth0 → PREROUTING DNAT → Docker bridge → container
                       ↓
                conntrack 记录创建

再叠加：

  • nginx tcp proxy

  • 多端口转发（6011-6109）

  • RabbitMQ / Redis / ZK

👉 结果：

conntrack entry 数量爆炸 + hash冲突概率指数级上升

4. eth0 TX queue backlog（重要信号）

两台都看到：

tx_send_full: 88000~94000+

含义：

NIC TX ring 有阻塞 / 发送队列曾经满过

👉 说明：

  • CPU侧处理不过来 or softirq拥塞

  • 或 conntrack/iptables路径延迟导致回压

5. RPS / IRQ 分布异常

/sys/class/net/eth0/queues/rx-*/rps_cpus = 00

👉 这是非常关键问题：

RPS（Receive Packet Steering）完全未启用

结果：

  • 所有流量集中在少数 CPU softirq

  • conntrack lock contention 加剧

  • hash table 并发冲突更严重

三、两台机器差异对比

项目 rulr-4 rulr-5 结论
conntrack timeout 3600 86400 rulr-5更危险
insert_failed 739万 1486万 rulr-5更严重
网络PPS ~1300 ~3500 rulr-5负载更高
docker网络 2个bridge 1个bridge rulr-5更集中
CPU drop 均衡 更高 rulr-5更拥塞
RPS 未启用 未启用 两台共同瓶颈

四、根因总结（核心3点）

根因1：conntrack hash table 进入高冲突状态

表现：

  • insert_failed暴涨

  • search_restart大量

  • drop == insert_failed

👉 本质：

bucket冲突 + 竞争锁 + CPU并发访问

根因2：Docker NAT + 高端口映射放大状态表压力

你现在是：

  • nginx tcp proxy

  • 10+端口区间映射

  • redis/rabbit/zookeeper

  • 统一 NAT

👉 典型放大效应：

每个连接 = 2~3个 conntrack entry

根因3：没有RPS/RFS，CPU softirq 单点瓶颈

导致：

  • conntrack lock 争用加剧

  • packet processing 串行化

  • insert失败概率上升

五、优化建议（按优先级）

⭐ P0（必须做）

1. 开启 RPS（立刻见效）

for i in /sys/class/net/eth0/queues/rx-*/rps_cpus; do
    echo ff > $i
done

2. 调整 conntrack hashsize（如果允许）

sysctl -w net.netfilter.nf_conntrack_max=2097152

并确认：

/sys/module/nf_conntrack/parameters/hashsize

⭐ P1（结构优化）

3. 缩短 conntrack 生命周期（rulr-5必须改）

net.netfilter.nf_conntrack_tcp_timeout_established=3600

或更低（代理场景建议 600~1800）

4. 减少 Docker NAT 层级

建议：

  • host network（关键服务）

  • 或减少 DNAT 端口范围

⭐ P2（架构级）

5. nginx tcp proxy 优化

  • 减少长连接 NAT

  • 开启 upstream keepalive

  • 减少 conntrack churn

6. 考虑 bypass conntrack（高级）

对纯转发流量：

iptables -t raw -A PREROUTING -j NOTRACK

⚠️ 需谨慎（会影响 NAT/stateful firewall）

六、最终判断

两台机器的本质问题不是“性能不够”，而是：

❗ conntrack + Docker NAT + 高PPS流量 + RPS未开启 → 状态表锁竞争崩溃

如果你下一步想继续深入

我可以帮你做三件更关键的分析：

1）判断是否 conntrack hash bucket 已经“爆桶”

2）计算你当前 conntrack 实际容量 vs 使用率

3）给出一套“代理服务器最优内核参数模板（8C/16C通用）”

只要你说一句“继续深入”，我可以把瓶颈定位到更精确的 kernel 层级。

Back to top