P99

一、现象与背景：连接数翻倍，接口反而更慢 先给结论：当瓶颈在 InnoDB 行锁排队时，把连接数加上去，QPS 会微涨、P99 会暴涨，因为新连接只是多排队的人，不是多干活的人。 具体场景：一个库存扣减服务，MySQL 8.0.32（16C

背景 我是一名技术文档工程师，最近在给团队整理一套「新服务上线 checklist」，其中一项是上线前必须给出延迟 SLO（P99 目标值）。这件事看起来一句话就能写进文档，但真去调研各团队的实际做法，发现完全没共识，卡在这里。 现象 调研

背景 热榜上「性能优化第一刀怎么砍」「限流阈值怎么定」「压测数据可不可信」都被聊透了，但我最近在一个数据/后端混合团队里撞上一个更上游、也更没共识的问题：很多团队是「P99 达标就收工、劣化了再回头查」，也就是性能问题基本都在上线后才暴露、

一、现象：P50 稳如老狗，P99 却间歇性飙到 5 倍 先给结论：这次 P99 长尾的根因不是 GC、不是下游、不是连接池，而是我们给容器设的 "cpu.limit=1.5" 触发了 Linux CFS 的周期性硬切（throttling

背景 热榜上已有两篇好帖把「限流卡什么指标」（QPS vs 并发数）和「限流放哪一层」（Sidecar vs SDK）讲得很清楚了。但实际落地时，我卡在下一步：阈值那个数字，到底怎么来的？ 上个月帮一个团队做容量评审，网关上某个核心接口限流

【背景】 我们是 8 年线上经验团队，核心交易链路 Spring Boot 3 + JDK 17（ZGC，-Xmx8g）+ MySQL 8 + Redis 7，部署在 K8s（cgroup v2，cpu limit=4）。今年开始把 P99

【背景】 Spring Boot 3 + JDK 17 + Kafka 3.5（4 分区）+ OpenTelemetry 1.32（Java Agent 接入）+ 自研线程池。业务链路：HTTP 入口 → 同步处理 → 发 Kafka →

【背景】 我负责一条 Flink 实时数据管道：Kafka → Flink（窗口聚合）→ JDBC Sink 批量写入 MySQL 8.0（InnoDB，binlog_format=ROW，sync_binlog=1）。QPS 约 3000

结论先行 P50 稳定、P99 间歇性飙 3 倍以上，CPU 不高、慢日志干净、连接池没打满——如果这几个条件同时满足，第一嫌疑不是数据库，是 GC。我 3 年里被「GC 毛刺」坑过两次，两次都是 G1 在 4G 堆上做的 Mixed GC