分类频道
性能调优
该分类下的文章、提问与讨论帖。
背景：我们正在评估分布式事务中间件的写入性能，需要对比PostgreSQL 16与MySQL 8.0在高并发场景下的表现 现象： 1. MySQL 8.0在MaxPoolSize=100时P99仍达1.2s（参考问题id=3277） 2.
【背景】 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
【背景】线上 MySQL 8.0 主从架构，业务高峰时段出现慢查询 P99 抖动放大 20 倍的异常，通过 performance_schema 的 events_waits_history 表抓包发现部分查询耗时突然激增。 【现象】 1.
背景：我们服务在双十一流量峰值时，发现部分写入请求在服务端被异常取消，导致数据丢失且无报错日志。 现象： 1. MySQL Connector/J 8.0.33 在 QPS 5000+ 时出现 3% 的写入失败率，抛出 "java.sql.
【背景】 在高并发场景下，JDBC驱动服务端取消SQL（如调用cancel()）是避免资源浪费的关键操作。但MySQL Connector/J与PostgreSQL JDBC在实现机制上存在显著差异，可能导致性能抖动或资源泄漏。 【常见分歧
背景：我们服务单机 QPS 2.3 万时，发现 MySQL 8.0 驱动 8.0.33 在长连接池中会出现 SQL 被服务端取消的现象，而 PostgreSQL JDBC 42.6.0 无此问题。 现象： 1. MySQL 会抛出 java
背景：我们服务在双十一流量峰值时，发现部分写入请求在服务端被异常取消，导致数据丢失且无报错日志。 现象： 1. MySQL Connector/J 08.0.29 在高并发下出现 3% 的写入失败率 2. PostgreSQL JDBC 4
背景 我负责一个 Java 17 高并发服务（K8s 4C8G，G1 GC，-Xmx8g -XX:MaxGCPauseMillis=50 -XX:G1ReservePercent=15），日常 QPS 约 3k，对象分配率约 55MB/s，
现象或背景 在日常运维和性能优化中，我们经常需要排查线上服务的性能瓶颈。然而，由于缺乏一套统一的排查清单，每次排查都需要从零开始，效率低下。为了提高排查效率，本文整理了一份 Linux 生产环境性能瓶颈排查 Checklist，覆盖 CPU
背景 我负责一个 Go 1.22 的订单网关（K8s 8C16G × 6 副本，QPS 峰值 ~5.2w，P99 SLO 80ms）。请求路径以 JSON 编解码（~12% CPU）+ 下游 HTTP 调用（~55% 耗时）+ 业务逻辑（~
«结论先行：「火焰图里 "pthread_mutex_lock" 飙到 9%」只能证明有用户在等锁，证明不了等的是哪把锁。堆外内存毛刺的三个高频嫌疑人——Netty "PooledByteBufAllocator" 的 arena 锁、JI
«结论先行：连接池（poolSize）是一个「阀门」，不是一个「容量池」。它的正确取值不是正向算「应用想发多少并发」，而是反向算「下游 DB 健康能服务多少并发」，两者取小。社区里流传的「poolSize = CPU 核数 × 10」之所以
背景 我在给一个 Java IO 型聚合服务做容量评审：单 Pod 8C，入口稳态 500 QPS、峰值 ~1000 QPS，单请求链路是「Tomcat 工作线程 → 并行调 3 个下游（MySQL P99 12ms、Redis P99 2
背景 8 年性能调优，最近在复盘一个「不是事故、但让人坐立不安」的退化模式。 核心服务：Java 17（OpenJDK 17.0.9）+ G1 GC，"-Xmx8g -XX:MaxGCPauseMillis=50 -XX:G1Reserve
【背景】 一个订单查询服务，4C8G 容器（K8s，limit 4C / 8G），JDK 17，堆 -Xms6g -Xmx6g，-XX:MaxGCPauseMillis=50，RegionSize 自动（4M）。日常 QPS 2-3k，对象
用 Little's Law 给连接池定大小：从"拍脑袋 200"到"8 核算出 17 个"的推导与三次验证 一、现象与背景 社区里聊连接池调参，我最常见的两种姿势：一是"默认 10 太小，生产直接 100/200"；二是"按 DB 核数
«结论先行：在双路（2 NUMA node）服务器上，「CPU 没打满、P99 却周期性抖动」的根因，常常不是软件里的锁，而是物理拓扑——线程被调度到了 A 路，却去访问分配在 B 路的内存，每访问一次都要走 UPI 跨节点总线。这次一个内
«结论先行：G1 GC 的 "to-space exhausted" 不是"堆不够大"，而是一次 evacuation 阶段发现连续 to-space region 不够用、被迫退化为 Full GC 的连锁反应。这篇文章复盘一次真实的 S
一、现象与背景：吞吐量"无声"掉了三分之一 去年 11 月，我们一个内部消息路由服务（JDK 17.0.11，Spring Boot 3.1.5，8C16G 容器）做了一次"小需求"：在 "RouteEntry" 对象上加了一个 "int
已经到底了
文
标题
摘要