架构师问，为什么PG和另一个PG 压测，一个内存消耗多！怎么让PG节省内存

AustinDatabases 2025-10-15

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

在我们2025年调研，压测，业务测试，适配PolarDB for PG 后，以及成本核算后。我们已经准备全面往PolarDB for PG上去迁移。但在压测中，研发和软件架构师一个问题，让我必须解释一下为什么在压测PolarDB for PG 的时候明显的内存压不上去。

如果我记得没有错，当时同样的压力下，PostgreSQL的内存消耗达到了80%以上，而PolarDB for PG在同样的压力下，内存仅仅达到 60%不到，而且持续加压，内存也上不去。

公司研发和架构师，在追问我为什么，到底怎么回事PolarDB for PG 到底用了什么，内存使用率一直比较低。

其实这个问题，我早就预料到了，原因很明确，因为代理， PolarDB for PG的代理。

说到这个问题就得说PostgreSQL的一个周边工具，也是著名的代理，pgbouncer。其实很多人都知道，但在实际生产中很少用，我也问过一些人，为什么你们不用，他们说出两个字，麻烦。

哪里麻烦了，其实他们反馈是配置麻烦，开一个新库，加一个账号就要重新配置，还要配置免密，虽然在pgbouncer也是动态加载，但他们还是嫌弃麻烦。

那么关键为什么节省了内存，一句话链接的产生被遏制了，无论是PolarDB for PG 还是 PostgreSQL 每当一个客户建立链接的时候，PostgreSQL都会为这个链接产生一个fork，也就是我们熟悉的backend 后端进程。

PG是进程模式，每个链接的开启都会消耗客观的内存，且PG在客户端链接这块的默认配置和他对于长链接的支持让不少的链接的内存都能用到最大设置的内存的限制数。8MB，对于一些要对大sqL处理的，有设置到16MB等等。如果几千个链接上去，必然会损耗内存，这里我们还没有计算由于开出的一个个小块的内存回收后，分配不利的问题等等。所以PG要节省内存，要的就是连接复用。

pgbouncer中三种连接池的模式中statement是最有效节省内存的，但是基于业务逻辑，我们大部分情况都是使用transaction pooling 的模式，但是这样也能节省一些内存，相对于直连的模式。

而PolarDB for PostgreSQL 为什么能更省内存的核心秘籍就是直接使用了statement pooling 而且还避免了由于使用了此策略可能产生的业务语句业务逻辑由于拆分后的，语句执行先后次序混乱导致的业务逻辑错误的问题。

PolarDB for PG本身的代理本身加载了判断语句路由的功能，把事务里面的语句都打散后，会判断打散的语句路由的先后次序，放置出现和pgbouncer选择statement中容易出现的问题。

虽然PolarDB有多个节点，但提供最终一致性，如果发现数据在从节点的内存里面没有，代理就会将查询的语句导回到写节点中。

具体解决方案，

RO节点通过网络获取RW节点当前最大的CSN（Commit Sequence Number）。

RO节点根据RW节点的最大CSN构建强一致性只读视图，并等到RO节点事务状态回放到相应位点。

RO节点根据强一致性读视图判断数据可见性，给客户端返回结果。

通过上述的方案，大量的读都会被路由直接分离到读节点，当有多个读节点，会进行活跃链接数的判断，将读分散到多个RO节点，所以自然RW，也就是PG写库的内存在怎么压都上不去，因为根本用不到写库的内存，写库的内存持续维持低使用率，而通过serverless，PolarDB for PG还可以自动进行扩展RO节点，动态调整，读库的内存也上不去，这就是开发和架构询问为什么业务压测的时候，PG的内存达到80%以上的利用率，同样的配置PolarDB在标准一主一从的情况下，内存连60%都上不去的原因。

总结：要想PG在内存方面节省，不OOM

1 尽量加载pgbouncer的周边来化解postgresql的进程链接模式带来的内存消耗问题，减少分配过多的链接。

2 尽量有效的快速的回收不用的idle链接，这个可以写程序，或者通过PG的配置，或JAVA的JDBC部分来进行配置，都可以，但必须有效的进行idle链接的有效回收，释放被占用的链接内存。

3 如果在云上可以尝试通过polardb for PGl来化解，PG多节点的主从数据读取一致性，多RO节点的数据分配的问题，当然这里也需要说一句，RDS POSTGRESQL 现在直接支持pgboucner和duckdb从节点，来解决一部分PG对于OLAP问题的解决方案在云上的实现。