From 704c65a7a4ebe2c73578383059caf0576cd7ac06 Mon Sep 17 00:00:00 2001 From: richjohnrambo Date: Sun, 27 Sep 2026 16:14:22 +0800 Subject: [PATCH] docs: record post-GitOps p2p pressure results --- ...压测Pod日志根因分析与改进方案-20260927.md | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md b/docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md index 2b8e3be..17e3dcf 100644 --- a/docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md +++ b/docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md @@ -322,3 +322,30 @@ Run ID：`p2p-200-20260927-03`。压测前修复了压测工具复用固定 `Ide 资源采样显示，三个 Pod 峰值内存低于 94MiB，但 Pod 0/1/2 在本轮窗口内的 CPU throttled 增量约为 7.62s / 0.78s / 8.51s。实际 StatefulSet 仍是 `request 100m/128Mi`、`limit 500m/256Mi`，且 liveness 仍是 `/healthz`。因此延迟和 Kafka 追平速度尚不能作为扩容到 500 对的验收基线。 已增加 `deploy/argocd/im-server-test/statefulset-performance-patch.yaml`，要求 ArgoCD 声明源固化 `request 1C/512Mi`、`limit 2C/1Gi`和 `/livez` liveness。部署流水线改为等待 ArgoCD 回写后严格校验，如果再被回滚则直接失败。压测工具保留乱序为失败门禁，并新增最多 100 条 `receiver/topic_hash/previous_seq/current_seq/client_mid` 明细，用于下轮精确定位。 + +## 13. GitOps 资源生效后的第四轮复测 + +Run ID：`p2p-200-20260927-04`。ArgoCD Application `im-server-test` 的真实配置仓库已固化 `request 1C/512Mi`、`limit 2C/1Gi` 和 `/livez`，三个 Pod 完成滚动后均为 Ready、零重启。 + +| 指标 | 结果 | +|---|---:| +| WS Ready | 400/400 | +| Publish 尝试 / ACK | 4000 / 4000 | +| Publish 拒绝 / 403 / 502 / 503 | 0 / 0 / 0 / 0 | +| ACK 后应到达 / 实际到达 | 4000 / 4000 | +| 实时丢失 / 重复 / 乱序 / 断连 | 0 / 0 / 0 / 0 | +| 历史查询 | 4000/4000 | +| MySQL 精确匹配 | 4000/4000 | +| MySQL 缺失 / 错配 / 重复 / 非 ACK 落库 | 0 / 0 / 0 / 0 | +| 精确 ACK P50 / P95 / P99 / Max | 368.189 / 566.683 / 725.654 / 1600.975 ms | +| 投递 P95 直方图上界 | 1000 ms | +| Cluster 队列采样最大值 | 0 | +| Kafka message persist 峰值 lag / 归零耗时 | 2946 / 发送结束后 113s | +| Pod 0/1/2 CPU throttled 增量 | 0 / 0 / 0 usec | +| Pod 0/1/2 峰值内存 | 87.86 / 80.80 / 85.18 MiB | + +结论：消息正确性全部通过，第三轮出现的 1 条 seq 回退没有复现。资源扩容完全消除了本轮 CPU throttling，证明旧的 500m CPU limit 是延迟放大因素之一；精确 ACK P95 从第三轮的 1006.288ms 降至 566.683ms，下降约 43.7%，但仍比 500ms 门槛高约 13.3%，因此报告只因 ACK 延迟门禁判定失败。 + +Kafka `im-server.message_persist` lag 在发送后峰值为 2946，并在发送结束后约 113 秒归零，超过 60 秒目标。历史 API 和 MySQL 最终均确认 4000 条完整落库，说明这是落库延迟而不是消息丢失。进入 500 对测试前，应优先检查 message persist consumer 的批量写入、worker/partition 并行度和 MySQL 写入耗时。 + +连接集中关闭期间，三个 Pod 分别记录 10、14、22 次 `failed to close login audit ... Deadlock found`，共 46 次。该问题未影响消息表，但会导致登录审计结束状态不完整。登录审计关闭更新应增加 MySQL 1213/1205 有界重试，并检查更新条件和索引以缩小锁范围。