PostgreSQL调高shared_buffer有哪些弊端？只读实例能否单独调优？

• 破坏双缓存协同的内存效率。PostgreSQL本身采用双层缓存架构：shared_buffer负责存储高频访问的热数据页、管理数据页一致性锁、承载WAL校验逻辑，剩余的OS内存交由Page Cache，负责缓存最近读过的磁盘块、加速顺序读、支撑大查询的临时排序缓存。如果把shared_buffer设置得过大（比如超过OS内存的30%），会直接压缩OS可支配的缓存空间，让两层缓存的覆盖范围出现无效重叠，整体内存利用率反而下降，甚至出现比25%配置下更差的顺序读性能。
• 抬升高负载下的IO抖动风险。shared_buffer中的脏页需要通过后台刷盘进程、checkpoint流程批量写入磁盘，缓冲区容量越大，常驻内存里允许缓存的脏页总量上限越高。一旦触发强制checkpoint或者写压力突增，需要落盘的脏页规模会陡增，很容易把磁盘IO打满，造成查询响应延迟无规律抖动，这种问题在写负载较高的读写实例上表现尤其明显。
• 拉长实例启动与故障恢复时长。当shared_buffer配置到几十甚至上百GB规模时，数据库实例崩溃恢复阶段需要遍历整个缓冲区的页面标记，对齐重做日志的位置，缓冲区容量越大，这部分扫描的耗时越长，极端场景下会把故障切换的恢复时间从几十秒拉长到十几分钟，抬高业务中断的风险。
• 挤占会话级内存的分配空间。PostgreSQL的会话级内存（包括复杂查询用的work_mem、建索引/批量清理用的maintenance_work_mem等）都是从OS剩余内存中动态分配的，如果shared_buffer占用过多内存，一旦出现多连接并发运行大查询的场景，单连接能拿到的排序、哈希运算内存就会不足，直接导致大量中间结果落盘，查询性能反而大幅下滑。

和承载写操作的主实例相比，只读实例没有WAL写入、频繁脏页刷盘的压力，调高shared_buffer的部分弊端会显著削弱，但依然存在不可忽视的负面影响：

• 这类场景下，只读实例因为不存在写相关的缓存开销，之前提到的脏页刷盘引发的IO抖动问题基本不会出现，崩溃恢复的耗时也因为缓冲区里基本都是干净页面而大幅缩短，不存在主实例上的那类高风险问题。
• 但内存挤占的核心问题依然存在：如果把shared_buffer配置到超过OS内存的40%，依然会挤压OS Page Cache的可用空间。而只读实例通常会承载大量全表扫描、大结果集聚合的顺序读任务，这类任务的加速高度依赖OS Page Cache的预读能力，缓存空间被压缩后，顺序扫描的性能反而会不升反降。
• 同时，只读实例往往会承接大量并发的临时分析查询，如果shared_buffer占了过多内存，分配给各会话work_mem的内存就会被压缩，很容易出现排序、哈希聚合操作落盘的情况，最终的查询整体性能反而低于25%~30%的常规配置。
• 观察到的磁盘直读与shared_buffer命中100倍的性能差，基本是冷启动场景下未被任何缓存承接的随机读极端情况——当OS Page Cache能接住这类读请求时，哪怕数据不在shared_buffer里，访问延迟的差距通常也只有2_{3倍，远达不到100倍的量级，这也是官方推荐把部分内存留给OS缓存的核心原因。从实操经验来看，只读实例没有必要追求100%热数据全部命中`shared_buffer`，通常最多把`shared_buffer`调到OS内存的30%}40%就足够了，剩余内存留给OS缓存和会话工作内存，整体的查询性价比最高。

内容的提问来源于stack exchange，提问作者WindMemory