IM 2000 人群聊 r5 复测分析

日期：2026-09-28

Run ID：group2k-r5-20260928-01

1. 结论

本轮再次证明服务端对稳定客户端的群消息可靠性没有丢失，失败集中在机器 A 的本地代理/TUN 链路：

B：1000 次发送全部 ACK，1426000 次 ACK 台账内投递全部到达，断线、重复、乱序和实时缺失均为 0。
A：574 次发布结果未知、657 次统计窗口内断线、464596 次 ACK 台账内实时缺失。
A 的 broken pipe 全部写向 198.18.0.81:443；本机 DNS 也将 api.118im.com 解析为 198.18.0.81，路由经 utun19827 -> 172.19.0.1。198.18.0.0/15 是代理/TUN 常用 Fake-IP 网段，不是 API 的真实公网地址。
机器 A 压测进程 CPU 平均占用不高、内存峰值约 150MB，B 在同一服务端负载下完全稳定，不支持“服务端全局过载”解释。
新增观测台账生效：574 条结果未知中，241 条被实时观测并加入历史核验，241 条全部找到。
历史总核验 1667/1667，持久化丢失为 0。
历史回查仍产生 1197 次 topic broadcast queue full，但全部发生在历史阶段，不在实时发送阶段。

总体结论：群消息落库通过，B 侧实时可靠性通过；A 侧 TUN/Fake-IP 链路失败；历史查询限速仍需继续降低。

2. 汇总结果

指标	A	B	合计
READY	1000	1000	2000
发送尝试	1000	1000	2000
ACK	426	1000	1426
明确拒绝	0	0	0
ACK 超时	444	0	444
socket 结果未知	130	0	130
断线	657	0	657
ACK 台账内应收	1426000	1426000	2852000
ACK 台账内实收	961404	1426000	2387404
ACK 台账内实时缺失	464596	0	464596
ACK 台账外额外投递	185738	241000	426738
历史核验	1667/1667	0/0	1667/1667
未 ACK 观测消息核验	241/241	0/0	241/241

服务端实际处理消息至少为 1426 + 241 = 1667 条。其余 333 条结果未知既没有 ACK，也没有任何实时观测证据，不能证明服务端接受。

3. A 机器故障证据

3.1 网络路径

测试结束后的本机检查结果：

api.118im.com -> 198.18.0.81
route: 198.18.0.81 -> gateway 172.19.0.1, interface utun19827
broken pipe remote: 198.18.0.81:443

A 的错误构成为：

ctrl_timeout=444
websocket_closed=103
broken_pipe=27
其他 1

连接从 17:05:12 UTC 开始下降，随后从 1000 持续降至约 333；B 同期保持 1000 连接。下一轮前必须关闭该代理/TUN，或至少将 api.118im.com 设置为 DIRECT，并确认 DNS 不再返回 198.18.0.0/15 Fake-IP。

3.2 本机资源

进程 RSS 峰值约 150MB。
压测期间累计 CPU 增量约 75 秒，对约 625 秒窗口而言不构成 CPU 饱和。
open FDs 在连接大量断开后仍约为 1011。WSClient.readLoop 在读失败返回时没有立即关闭底层连接，虽然进程结束时会统一关闭，但应修复运行期 FD 滞留。

4. 服务端和历史核验

实时发送和 drain 阶段没有新增以下错误：

sub.broadcast channel full
cluster: proxy channel full
topic's broadcast queue is full
Redis fanout publish failure

历史核验约在 17:13:15 UTC 开始。im-server-2 从 17:13:22 到 17:14:14 记录 1197 次群 Topic broadcast queue full。当前 1 worker、每页 50 条、100ms 间隔仍会让单次历史回放快速灌入容量为 64 的 Topic 队列。

尽管重试后 1667 条全部找到，历史核验不应持续制造队列丢弃。建议调整为：

history_page_size=20
history_query_interval=500ms
history_workers=1
历史超时保持 3 分钟；1667 条约需 42 秒完成首轮查询。

5. 下一步

修复 WSClient.readLoop 退出时未关闭底层连接的问题。
将历史分页调整为 20 条、查询间隔 500ms。
在 A 机关闭 TUN/代理，或配置 api.118im.com DIRECT；起压前检查 DNS 和路由不再进入 198.18.0.0/15、utun*。
测试环境尚未应用 metrics RBAC，kubectl auth can-i list pods.metrics.k8s.io 仍返回 no，因此本轮没有 Pod CPU/内存数据。需要将 backend-debug-metrics-rbac.yaml 加入实际 ArgoCD overlay。
完成上述三项后再运行同规模 r6。若 A/B 都稳定，再根据 B 本轮 ACK P95 约 1.14s、同机投递 P95 位于 2s 桶的结果继续做服务端延迟优化。

4.4 KiB Raw Blame History Unescape Escape