同事甩 10–40% 截图让你升 Go 1.26？先量自己的 GC 占比

Fri, 17 Jul 2026 02:40:00 +0800

值班群里有人贴了 Go 官方的截图：Green Tea 能把 GC 开销降 10–40%。

下一句往往是：那下周就升 1.26，服务应该能快不少。

我会先去看一条监控：GC CPU 在总 CPU 里占多少。没有这个数，截图再漂亮，也不能替你做性能判断。

网上的 10–40% 说的是 GC 自己的 CPU，不是你的服务；先量自己的 GC 占比，再决定要不要为 Green Tea 做 A/B。

先把 10–40% 的分母说清

官方的说法有边界：对 GC 压力很重的真实程序，GC 开销预计可下降约 10–40%。多数程序接近 10%，少数可以接近 40%。这里减少的是垃圾回收本身消耗的 CPU 时间，不是 QPS 一定上涨，也不等于 p99 一定下降。

官方给过一个很实用的换算。如果一个程序有 10% 的 CPU 时间花在 GC，上述改善折算到总 CPU，大致是 1–4%。这个数字不小，但它和“服务快了 40%”是两回事。

你的服务里 GC 若只占 5% 的总 CPU，即便 GC 自身少花 40%，总 CPU 的变化也很有限。反过来，GC 在 CPU 性能分析里长期占着明显一段，或者分配频繁、堆里有大量小的指针对象，Green Tea 才值得认真对比。

这里没有玄学，先看两个数：GC CPU 占比，以及 GC 自身能少花多少。前者很低时，升级后业务指标没有明显变化，本来就是可能出现的结果。

Wed, 08 Jul 2026 10:00:00 +0800

PG 大版本升级，过去一直有两件烦心事：

一是升完了统计信息丢光，优化器两眼一抹黑，ANALYZE 跑完之前查询崩好几天。二是折腾半天，性能提升不明显，不值得冒这个险。

PG 18 把这两件事都动了。

而且这次不是小步迭代——几个改动直接改了 PG 用了二十年的工作方式。

PG 以前读数据是这样的：发一个 I/O 请求，进程挂起等数据回来，再发下一个。这在机械硬盘时代是自然的——磁盘自己就是串行的。但在 NVMe SSD 面前，CPU 等磁盘的时间越来越不值。

PG 18 引入了异步 I/O 子系统。一次发一堆请求，谁先回来谁先处理，CPU 不再空等。

官方数据：顺序扫描在某些场景下能到 3 倍。不是 30%，是 3 倍。

怎么开？一行配置：

io_method = 'io_uring'

io_uring 是 Linux 5.1+ 的高性能异步接口。内核版本不够也可以用 worker 模式——走工作线程模拟异步，差一点但比老模式强。

这个改动最值钱的地方： 不是跑测试快 3 倍，而是你那些吃顺序扫描的场景——数仓 ETL、全表报表、大表 vacuum、bitmap 扫描——都能吃上。如果业务 IO 密集，升了立竿见影。

UUID 做分布式主键的好处不用多说：全局唯一、不依赖自增。但 UUIDv4 是纯随机的，往 B-tree 里写的时候，每个新值可能落在任何位置。结果是什么？索引页频繁分裂，写入性能崩得比不用 UUID 还惨。

好多团队因为这个原因又退回自增了。

PG 18 原生支持 UUIDv7——时间戳在前，保证新生成的 UUID 大致有序。B-tree 写入不再分裂。