docs: record p2p 500 load test bottleneck

docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md

@@ -374,3 +374,43 @@ Run ID：`p2p-200-20260927-05`。本轮已将 `im.message.persist` 和 `im.group
 结论：三分区已由三个 Pod 实际并行消费，单 Pod 峰值 lag 从第四轮的 2946 降至 676，最慢消费者在 60 秒门槛内归零。消息正确性、最终落库、会话内顺序、CPU 限流和登录审计死锁均通过。
 
 报告仍因 ACK P95 门禁显示失败。直方图只能给出 1000ms 上界，按 4000 条 ACK 原始时间戳和 nearest-rank 口径计算的实际 P95 为 547.516ms。A 机已经低于 500ms，而 B 机为 594.533ms，且 B 机存在 2.845s 最大长尾；两台机器使用相同公共入口和相同服务端版本，因此继续修改服务端前，应先采集 B 机到 `api.118im.com` 的 DNS、TCP、TLS、WebSocket RTT 与时钟偏差，并使用定向 Pod 入口做 A/B 对照，区分公网链路长尾和服务端处理耗时。
+
+## 15. 500 对第一轮容量测试
+
+Run ID：`p2p-500-20260927-01`。A/B 各建立 500 条 WebSocket，共 500 对、1000 条连接和 10000 次 Publish。正式发压前补齐了第 201–500 对中缺失的 9 对好友权限，两端预检和 Ready 均通过。
+
+| 指标 | 结果 |
+|---|---:|
+| WS Ready | 1000/1000 |
+| Publish 尝试 / ACK | 10000 / 9946 |
+| Publish 失败 | 54（44 条服务端 500/other，10 条 socket error） |
+| Publish 成功率 | 99.46% |
+| ACK 后应到达 / 实际到达 | 9946 / 9936 |
+| 实时丢失 / 重复 / 乱序 / 断连 | 10 / 0 / 0 / 1 |
+| 实时到达率 | 99.8995% |
+| 总体精确 ACK P95 / Max | 2429.954 / 3636.045 ms |
+| 压测期历史回查 | 8580/9946 |
+| Kafka 完全排空后 MySQL 精确匹配 | 9946/9946 |
+| MySQL 缺失 / 错配 / 重复 / 非 ACK 落库 | 0 / 0 / 0 / 0 |
+| Pod 0/1/2 Kafka 峰值 lag | 2490 / 3234 / 2745 |
+| Kafka 归零时间 | 发送结束后约 4 分钟 |
+| Pod 0/1/2 峰值内存 | 148.1 / 130.5 / 122.4 MiB |
+| Pod 0/1/2 CPU throttled 增量 | 0 / 0 / 0 |
+| Pod 重启 | 0 |
+
+本轮不通过，不得升级到 1000 对。根因是 MySQL 连接容量与 IM Server 连接池上限不匹配：
+
+- MySQL `max_connections=170`，本轮 `Max_used_connections=172`，`Connection_errors_max_connections=27`。
+- IM Server 每 Pod `max_open_conns=64`，3 个 Pod 的理论连接池上限已达 192，还未计入 admin server、其他服务和运维连接。
+- 本轮 Pod 0/1 分别记录 153/19 次 `Error 1040: Too many connections`，包括 50 次 `failed to save message`和 44 次 P2P 关系检查失败；这些错误与 44 条服务端 500 同时出现。
+- A 机用户 190 的 WebSocket 断开，产生 10 次 socket error，并导致对端已 ACK 的 10 条消息未能实时投递到该连接。
+- 压测结束阶段 Pod 2 记录 282 次群 Topic broadcast queue full，发生在大量会话同时清理期，需要与消息发送链路分开处理。
+
+压测阶段的 `history_found=8580`不是最终丢库：历史回查结束时 Kafka 仍在积压，等 lag 归零后从 Pod 内使用 ACK ledger 独立查询 `im_008_messages`，9946 条全部精确匹配。因此当前是“已接受消息最终零丢失，但持久化延迟超标”。
+
+下一轮 500 对复测前必须先完成：
+
+1. 统一规划 MySQL 全局连接预算，覆盖 IM Server、admin server 及其他共库服务；单个服务的连接池上限不能独立设置到总库容量。
+2. 修正 IM Server 每 Pod 的 `max_open_conns/max_idle_conns`，或在验证 MySQL CPU、内存、线程和 PXC 限制后提高 `max_connections`；必须保留至少 20% 全局余量。
+3. 压测中增加 DB pool `OpenConnections/InUse/Idle/WaitCount/WaitDuration`和 MySQL `Threads_connected/Threads_running/Max_used_connections/Connection_errors_max_connections` 指标。
+4. 复测要求 Publish ACK 10000/10000、实时丢失和断连为 0、Kafka 60 秒内归零、MySQL 1040 和清理期 queue full 为 0，然后才能进入 1000 对。