标签频道
P99
该标签下的文章、提问与讨论帖。
【背景】 MySQL 8.0.32 / InnoDB，单库 32C/128G，innodb_buffer_pool_size=48G。核心业务表 t_order 约 8000 万行，PK=id，联合索引 idx_user_status (u
背景：线上 MySQL 8.0 主从架构，业务侧反馈 P99 响应时间偶发抖动 20 倍 现象：通过 performance_schema.events_waits_history 表抓取到单条查询耗时分布异常，但无法精确拆解到 Buffe
一、现象或背景：双层连接池错位引发的 P99 毛刺 我维护一套 gRPC streaming 微服务平台（Go 1.22 + gRPC 1.60，K8s 1.28 + Istio 1.21 sidecar 模式），约 60 个无状态服务，核
背景 Go 1.22.7 无状态订单查询 API，K8s 部署（K8s 1.28.9 / containerd 1.7.13 / cgroup v2 / 内核 5.15.0-91），Pod spec "memory.request=4Gi
一、现象或背景：CPU 没打满，延迟却翻了 46 倍 我们一个 12 节点（8C16G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v1）的网关集群，跑着一个 Go 网关（单实例 4C limi
背景 我负责一个 Java 17 高并发服务（K8s 4C8G，G1 GC，-Xmx8g -XX:MaxGCPauseMillis=50 -XX:G1ReservePercent=15），日常 QPS 约 3k，对象分配率约 55MB/s，
背景 线上 Java 17 / Spring Boot 3 订单查询服务，K8s 1.28 部署（单 Pod 4C8G，节点 16C64G），G1 GC（-Xmx4g -XX:MaxGCPauseMillis=200），入口 QPS 稳定在
【背景】 K8s 1.28（containerd 1.7），Java 17 / Spring Boot 3，无状态订单查询服务。本地缓存用 Caffeine 做 L1（按 key 哈希散到各副本，稳态命中率约 92%），DB 用 Hikar
«结论先行：PostgreSQL 的「auto plan cache」机制（named prepared statement 执行满 5 次后自动比较 generic plan 与 custom plan 的代价并择优切换）在参数分布倾斜时
背景 K8s 1.28.9 + cgroup v2 + 内核 5.15，14 节点 16C64G 集群，Java 17 / Spring Boot 3 订单服务，HikariCP 4.0.3，连接池配置 "maximumPoolSize=2
背景 我维护一套 gRPC streaming 微服务平台（Go 1.22 + gRPC 1.60，K8s 1.28 + Istio 1.21 sidecar 模式），约 60 个无状态服务，核心链路是 server-streaming（一
背景 做了 15 年性能调优，最近在排查一个 K8s 1.29 集群（cgroup v2、内核 5.15.0-91、containerd 1.7）上的 Java 服务 P99 毛刺。 - 服务：JDK 17 + G1GC，单 Pod 单容器
背景 MySQL 8.0.36（InnoDB，16C64G，buffer_pool 48G），核心表 "t_order" 约 2 亿行，主键 "id"（bigint 自增）。业务是高频点查 + 点更新（按 PK），QPS 约 8k，隔离级别
结论先行 CPU 不饱和（55%~65%）+ 下游 P99 < 80ms + ZGC pause < 2ms + HikariCP pending ≈ 0，但本服务 P99 从 120ms 间歇性飙到 900ms——大概率是 carrier
«结论先行：实时管道的 P99 长尾，90% 不在 Flink 里，而在 Flink 的上下游。把 SLO 当成「Flink 算子 P99」去调，是这条链路最贵的认知错误。正确姿势是按段拆预算：Kafka 生产端攒批 ≤ 500ms、Kaf
«结论先行：「火焰图里 "pthread_mutex_lock" 飙到 9%」只能证明有用户在等锁，证明不了等的是哪把锁。堆外内存毛刺的三个高频嫌疑人——Netty "PooledByteBufAllocator" 的 arena 锁、JI
【背景】 做了 5 年前端，最近半年被绩效指标绑死在「核心页面端到端 P99 ≤ 300ms」上。但每次复盘对不上号：后端 APM（SkyWalking + 自研埋点）显示核心查询接口 P99 是 85ms，前端 RUM（自研 SDK 基于
背景 做了 10 年性能优化，最近复盘一个真实案例，卡在一个很具体的归因问题上（已脱敏）。 一个 Go 订单查询服务：Go 1.22，net/http + gorm + MySQL 8 + Redis 7，K8s 1.28 / cgroup
【背景】 我负责一个 B 端 SaaS 的聚合服务（JDK 17，Tomcat max-threads=200，8C16G 容器），同一个 Tomcat 工作线程池里混跑两类任务： - IO 型：一次请求扇出 3 个 RPC + 1 次 M
背景 Java 17 / Spring Boot 3，JVM 堆 8G，K8s 1.28，4 副本滚动发布（maxSurge=1 / maxUnavailable=0），核心接口 P99 SLO < 50ms、稳态约 25ms。社区里反复验
已经到底了
文
标题
摘要