标签频道
性能调优
该标签下的文章、提问与讨论帖。
【背景】 做了 10 年性能优化，最常被 PM 和产品同学问的一句话是：「这个接口 P99 从 42ms 降到 41ms，用户能感知到吗？这 3 天的开发时间是不是浪费？」 我经历过两种极端： - 某电商大促前，一个商品列表接口 P99 是
«结论先行：抬 "cpu.limits" 解决的是「带宽不够」，而 CPU Manager "static" 解决的是「核被别人抢走」——这是两种完全不同的故障，用错了工具就是白调。我踩了整整一个迭代：先把 limit 从 2C 抬到 4C
【背景】 我负责一个订单查询服务：Spring Boot 3.2 + JDK 17 + HikariCP 5.1 + MySQL 8.0，K8s 部署 4 副本，单副本 4C8G，入口稳态 800 QPS、峰值 1500。每次连接池打满都是
«结论先行：InnoDB 的读退化不一定来自 I/O——当 undo history list 超过 100 万条时，即使 buffer pool 命中率 99.7%，一次简单的 PK 点查也要遍历 undo 版本链，P99 从 0.3ms
discussion
P99 悄悄从 200ms 爬到 800ms，没人投诉——这算不算事故？要不要触发复盘？
背景 上周复盘一个「看起来没事」的接口：订单详情查询，QPS 约 1200，业务方三个月没提过任何体验问题。但拉了 90 天 P99 曲线，从 3 月的 186ms 一路爬到上个月的 812ms，P50 基本没动（一直在 42ms 附近）。
discussion
P99 抖动时「网络锅 vs 应用锅」到底怎么分？我见过 5 种做法，没有一种是干净的
背景 干了 10 年网络，最常被拉进「P99 突然从 20ms 飙到 300ms」的排查群，然后第一句话永远是：「网络你们看下有没有问题。」 问题是——「网络有没有问题」这件事，在微服务架构里根本没有一个干净的度量。 TCP 没断、ping
discussion
服务拆分粒度之争：按业务域拆 vs 按流量特征拆，你站哪一边？
背景 我在做订单 + 履约中台，按 DDD 拆了 6 个服务，跑了 3 年。最近一次 P99 抖动复盘，根因是「读流量集中在 2 个服务，把写路径的 HikariCP 连接池和 JVM 老年代都挤爆了」——读 QPS 10 万、写 QPS
背景 做一个订单详情页聚合接口（Java/Spring Boot + HikariCP 5.1 + MySQL 8.0），一次业务请求要串行/并行发 5~7 条 DB 查询（订单主表、明细、库存、价格、风控、物流），下游还有 2 个 RPC
discussion
慢查询治理中，「加索引」是不是已经变成条件反射了？——写入放大与优化器误选这笔账谁在算？
背景 我做了 15 年大数据平台，前 5 年在 DBA 团队，后面一直做数据仓库与 OLTP 混合场景。一个观察：慢查询报警一响，开发同学（甚至不少 DBA）的第一反应就是"加个索引"。快、简单、当天下线、不用改代码。 但真实场景里，"加索
«结论先行：InnoDB Buffer Pool 的 LRU 淘汰不是"最久未用就踢"这么简单——它把 LRU 链拆成 young/old 两段，用 "innodb_old_blocks_time" 控制"新页在 old 链上待多久才能晋升
«结论先行："cpu.cfs_burst_us" 是 Linux 5.14（2021 年 4 月）在 cgroup v2 里新增的一个旋钮，允许一个 cgroup 在突发时向未来周期借 CPU 时间——本质是给 CFS 配额加了一个"透支额
discussion
告警阈值到底怎么定：固定值、动态基线、SLO 预算——你线上到底用哪种？
【背景】 干运维 10 年，oncall 手机响了不下几千次。我粗略统计过自己前 5 年的告警工单：大约 80% 的"翻车"集中在两头——要么"该告没告"（P99 已经飙了 3 倍，但没触达阈值，等用户投诉才查），要么"不该告也告了"（凌晨
【背景】 MySQL 8.0.32 / InnoDB，单库 32C/128G，innodb_buffer_pool_size=48G。核心业务表 t_order 约 8000 万行，PK=id，联合索引 idx_user_status (u
背景 在 K8s 集群里，"requests" / "limits" 怎么填，直接决定了调度器的 bin-packing 效率和 Pod 运行时的 QoS 等级。我见过太多团队在这件事上"一刀切"： - 有些团队（尤其金融、电商中台）直接
【背景】 JDK 21 把虚拟线程推成 LTS 默认能力，Spring Boot 3.2 之后 "spring.threads.virtual.enabled=true" 一行就能把 Tomcat 线程池换成虚拟线程。我这边一个订单聚合服务
question
混合负载节点上 batch job 写 50GB 后前台 P99 飙 16 倍：vm.dirty_*、ionice、cgroup v2 io.max 三层 I/O 控制到底谁压谁？线上到底怎么配？
背景 我维护一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，内核 5.15.0-91，cgroup v2）的自建集群，磁盘是 7200RPM SATA（不是 SSD，这点很关键）。节点
«结论先行：MySQL 8.0.3 起 "innodb_change_buffering" 默认从 "all" 改成了 "none"，绝大多数 8.0 新实例上「二级索引写合并」根本没开。对持续 INSERT 的流水表（非唯一二级索引、写入
背景 我负责一个订单结算服务（Spring Boot 3.2 + JDK 17 + HikariCP 5.1，K8s 部署，4 副本，单副本 8C16G）。一个典型请求的处理流程是： 1. 从 HikariCP 拿到 MySQL 连接（用于
«结论先行：在双路（2 NUMA node）服务器上，「CPU 没打满、P99 却周期性抖动」的根因，常常不是软件里的锁，而是物理拓扑——线程被调度到了 A 路，却去访问分配在 B 路的内存，每访问一次都要走 UPI 跨节点总线。这次一个内
背景 5 年运维，管一个 K8s 1.28.9 共享集群（containerd 1.7.13、cgroup v2、内核 5.15.0-91，节点 16C32G，混跑 10+ 个 Java/Go 微服务）。一个核心下单服务（JDK 17，G1
已经到底了
article
标题
摘要