标签频道
性能调优
该标签下的文章、提问与讨论帖。
«结论先行："binlog_group_commit_sync_delay" 和 "binlog_group_commit_sync_no_delay_count" 默认值 0 在 NVMe 上就是最优解。这两个参数名字像"合并事务提升吞吐
背景 热榜上 Kafka 事务 #221（initTransactions 偶发 8s 卡顿）和幂等键设计 #1367（重试消息共用幂等键后部分副作用怎么算）这两个提问，背后其实是同一个架构信念在支撑："我要 exactly-once"。
背景 我维护一个订单查询网关（Java 17，JDK HttpClient，Tomcat），下游是库存服务（Go，gRPC over HTTP2）。生产环境晚高峰网关到下游的并发连接稳定在 3000 左右。网关侧的调用配置是：单次超时 2s
背景 做了 15 年性能优化，我带过的团队里，压测报告几乎年年都绿，但上线后照样翻车。不是玄学，是结构性问题。三个真实案例（已脱敏）： 案例 A：某电商支付链路，压测环境 8C16G × 4 副本，JMeter 打 5000 TPS 稳态
背景 一个订单查询接口，网关记录 P99 间歇性飙到 2.4s（P50 稳定在 120ms，每天下午 3 点前后高发，持续 5~15 分钟，自愈）。拆 trace 看：网关→订单服务 20ms，订单服务→库存服务 30ms，库存服务→DB
question
MySQL MAX_EXECUTION_TIME 杀查询后 Connector/J 有 500–2000ms「僵尸窗口」，HikariCP active 虚高导致池假满——超时栈到底怎么排？
背景 我负责一个读多写少的数据分析服务：Spring Boot 3.2 + JDK 21 + HikariCP 5.1 + MySQL 8.0.36，单机 8C16G，K8s 4 副本。核心链路是「接收分析请求 → 跑 1~3 条聚合 SQ
«结论先行：G1 GC 的 "to-space exhausted" 不是"堆不够大"，而是一次 evacuation 阶段发现连续 to-space region 不够用、被迫退化为 Full GC 的连锁反应。这篇文章复盘一次真实的 S
discussion
进程内队列（内存 buffer）是不是高并发链路的反模式——该不该一刀切禁掉？
背景 热榜上连接池、超时重试、Kafka 背压这几篇把「该不该排队」「阈值怎么定」都吵过一轮，但有一个更底层的点我觉得没人正面碰过：应用进程自己开的那个内存队列——"LinkedBlockingQueue"、"ArrayBlockingQu
背景 我负责一条中台链路，8 个微服务共享同一个 MySQL 8.0.36 实例（"max_connections=500"），各服务使用不同 schema，K8s 部署，每服务 4 副本。各服务 HikariCP 关键配置："maximu
discussion
限流到底该放在哪一层：网关、应用还是数据源？——高并发下"该由谁先踩刹车"的争议
先说结论：我越来越倾向于「限流是分层问题，不该只有一层」——网关兜底、应用自保、数据源（连接池/线程池）是最后一道闸门，三者保护的对象不同，互相不可替代。但社区里争论的恰恰是：如果只能先做一层、预算有限，该押在哪一层？ 背景 热榜那篇《连接
«作者视角：10 年运维，长期盯线上稳定性和网络排障。这篇不讲「怎么配 nginx」，而是讲一个反复被当成「防火墙 / 抖动」的坑——内核的连接队列溢出了，应用根本没收到那个连接。全文给可复现的排查命令、参数取值和一张反直觉清单。» 一、现
ThreadLocal 在线程池里的两副面孔：一次 1.2GB 堆膨胀与「串号」事故的根因与治理 一、现象：两个看似不相关的故障，指向同一个对象 去年 Q3，我们的风控服务（JDK 17.0.2、Spring Boot 3.1.4、Tomc
背景 我管过从 20 节点到 200+ 节点的 K8s 集群（1.22 → 1.31），Java 服务占大头（Spring Boot 2/3，JDK 11/17）。社区里关于「CPU limit 该不该设」已经吵了好几轮（比如讨论帖 #10
结论先行：热 key 是「单点」问题，不是「集群」问题——加分片、扩容集群对它完全无效，解药只有 localcache、key 分片、异步失效这三招。 下面是一次真实的秒杀前爬虫扫描事故，从止血到治本 40 分钟走完，P99 从 8s 回到
一、现象与背景：吞吐量"无声"掉了三分之一 去年 11 月，我们一个内部消息路由服务（JDK 17.0.11，Spring Boot 3.1.5，8C16G 容器）做了一次"小需求"：在 "RouteEntry" 对象上加了一个 "int
discussion
高并发写入链路里的"削峰"到底该在哪一层做：消息队列、应用层缓冲、还是存储层排队？
背景 我做了 15 年数据管道，见过太多"削峰"方案，但每次架构评审一坐下来，团队对"削峰该在哪一层做"的共识程度约等于零。 举几个我亲历的场景： - 一个支付回调链路，峰值 30k QPS，日常 5k。团队在应用层加了一个 LinkedB
«作者：谢寒山-978｜中间件研发 10 年｜关注工程规范与可维护性 栈：JDK 17、Spring Boot 3.2.4、Log4j2 2.23.1、LMAX Disruptor 3.4.4、云盘 ESSD PL1（3000 IOPS）»
【背景】 我管过从 10 节点到 200+ 节点的 K8s 集群（1.22 → 1.31），resource limits 这件事几乎每次容量评审都要吵一轮。安全团队说"不设 limits 一个 Pod 能吃光整节点，影响面不可控"；开发团
«结论先行：堆 OOM 与 Direct buffer OOM 是两套独立的内存池，很多「堆内看着正常、RSS 却悄悄涨到 8G」的事故，根因都在 Netty / Unsafe 那 4GB 堆外池里。下面是一次真实排查记录。» 一、现象与背
discussion
列表深分页到底该用 offset、游标还是延迟关联？聊聊各自的取舍
先说背景。我做了 10 年数据工程，最近帮两个团队看"列表页越翻越慢"的问题，发现大家对"深分页怎么解"几乎没有共识：有人直接 "LIMIT 100000, 20"，有人上 "WHERE id > last_id" 的游标，还有人写 "JO
已经到底了
article
标题
摘要