标签频道
性能调优
该标签下的文章、提问与讨论帖。
背景 我负责一条埋点落库链路：Kafka → 自研消费者 → JDBC 批量 INSERT 写 MySQL 8.0（InnoDB，binlog_format=ROW，sync_binlog=1，innodb_flush_log_at_trx
discussion
慢查询到底该"杀掉"还是"放它跑完"？数据平台的资源治理你怎么选
背景： 我做了 8 年大数据平台，最近复盘一次事故：凌晨一个 BI 报表任务扫了 40GB 未命中的分区，把共享查询引擎的内存打爆，连带拖垮了两条在线服务链路。事后我们上了「查询级超时 + 资源配额 + 优先级队列」，但团队内部吵了一架：数
«结论先行："CallerRunsPolicy" 不是"兜底策略"，而是"把线程池问题转化为调用方阻塞"的转换器。当它出现在嵌套线程池（线程池 A 的任务里再提交到线程池 B）的场景里，队列一满，A 的工作线程会被 B 的拒绝策略"劫持"去
结论先行 给 "Thread.ofVirtual()" 换上虚拟线程的那一刻，你并没有换来「免费并发」——任何在同步块 / native 调用里做阻塞 I/O 的代码，都会把载体线程（carrier thread）钉死，最终把 "ForkJ
先抛背景。 我做过一个真实复盘：某订单中心一个异步落库任务，最初用固定 200 线程的线程池跑，CPU 一直不满 30%，看起来"很闲"。后来有人按"CPU 核数 × 10"的经验把池子扩到 2000 线程，结果 P99 从 180ms 飙
背景 我在一个 12 节点（4C8G，cgroup v2，K8s 1.28.9，containerd 1.7）的集群上跑一套电机控制闭环，控制周期 5ms，硬实时要求 P99 ≤ 10ms。业务 Pod 用 cpuset 静态绑定 2 核，
discussion
数据倾斜治理：「均匀化打散」和「热 key 隔离」到底谁先谁后？聊聊你的直觉与底线
背景 做数据工程 5 年，我几乎每个月都要和"倾斜"打交道：Flink 的 keyBy 热 key 让某个 subtask 的 RocksDB 写入 QPS 飙到均值的 30 倍、Kafka 消费组里某个分区被一条大商家消息拖到 5 分钟才
«结论先行：systemd 的 "CPUQuota" 不是「CPU 占用上限」，而是**「每 100ms 墙钟内最多给你多少 ms 的 CPU 时间」**。把 "CPUQuota=100%" 加给一个瞬时峰值要 2 个核的 Go 服务，平均
现象：P99 从 8ms 飙到 3200ms，CPU 却只有 35% 去年双十一前压测，我们一个 WebSocket 网关服务（4 台 ECS，每台 8C16G，Netty 4.1.100.Final）突然"集体变慢"： - 总长连接数约
结论先行：慢查询里有一类最「安静」的杀手，是隐式类型转换——它让 EXPLAIN 里的 "type" 从 "ref"/"range" 退化成 "ALL"、"key" 列直接变 "NULL"，而 SQL 里你根本看不出任何「错别字」。字段是
背景 我在给一个订单履约服务做容量评审，单 Pod 8C16G，业务侧 600 QPS 稳态，下游三类：MySQL 8（p99=12ms）、Redis 7（p99=2ms）、第三方 HTTP（p99=380ms，超时 800ms）。目前 H
discussion
慢查询日志到底是「治理入口」还是「噪音源」？聊聊你的取舍
背景 社区里关于「慢查询该加索引还是改写 SQL」的讨论已经很多了（id=49 的讨论帖、id=19 的三件套文章我都认真看过，方向基本认同）。但我想把问题再往前挪一步：在「定位」这一环，大家到底把慢查询日志（slow_query_log）
【背景】一个订单查询服务，Spring Boot 3.2 + JDK 21 + HikariCP 5.1，单实例 8C16G，前置 4 个实例，下游 MySQL 8.0 同机房。压测 QPS 稳在 1000 左右时，P50 始终 15ms
结论先行 Java 21 的虚拟线程（virtual thread）在遇到 "synchronized" 块内的阻塞调用时，会把它所属的 carrier 线程"钉住"（pin）；carrier 池默认只有 CPU 核数那么多，一旦大量虚拟线
«结论先行：「偶发 Connection reset by peer、重试一次就好、抓包看不到丢包」，十有八九不是网络，而是客户端与服务端的 keep-alive 空闲超时不一致——服务端先关，客户端不知情，复用旧连接发请求，撞上服务端 R
«结论先行："INSERT ... ON DUPLICATE KEY UPDATE"（下称 ODKU）是"写法上最方便"的幂等手段，但它把"唯一索引冲突检查"和"UPDATE"塞进同一个事务、同一把行锁里完成，在高 QPS + 高重复率场景
discussion
ZGC 都上了，GC 调参这件事是不是可以彻底退休了？
背景 做了 10 年性能优化，有一个观察越来越强烈：GC 调参这件事，正在从"必修课"变成"选修课"，甚至有人觉得可以直接"退役"。 我最近带团队把一个 4C8G 的 Java 服务从 JDK 11（G1，-Xmx4g）迁到 JDK 21（
【背景】 订单网关，JDK 21 虚拟线程（spring.threads.virtual.enabled=true）+ Spring Boot 3.2，下游用 OkHttp 4.12 调 3 个内部 HTTP 服务（已从 Feign 迁过来
«结论先行：RocksDB 的写毛刺，90% 不是「写慢」，而是「写被自己人卡住了」——前台写路径本身（memtable 追加 + WAL 落盘）在 NVMe 上稳定 1~3ms，真正让 P99 飙到 200ms 的，是后台 compact
背景 我负责一个核心查询服务：Spring Boot 3.2 + JDK 17.0.10（G1，"-Xmx4g -XX:MaxGCPauseMillis=50"）+ MySQL 8 + Redis 7，K8s 1.28.4 / contai