我注意到在查询 PostgreSQL 时没有将数据加载到 shared_buffer 时性能会显着下降，差异可能接近 100 倍。所以在优化查询的过程中，我想知道是否有办法通过增加shared_buffer来提高性能。
然后我开始研究 PostgreSQL 中的shared_buffer。我发现推荐值是操作系统内存的25%，PostgreSQL 将利用操作系统缓存来加速查询。但是从我自己的数据库中看到的情况来看，从磁盘读取与shared_buffer 有很大的不同，所以我最想从shared_buffer 查询。
所以我想知道，如果我在 PostgreSQL 中增加 shared_buffer 有什么缺点？如果我只在我的只读实例中增加shared_buffer 怎么办？
【问题讨论】：
标签： postgresql performance database-administration
增加缓冲区高速缓存的一个缺点是双缓冲。当您需要将一个页面读入 shared_buffers 时，它可能首先需要驱逐一个现有页面为其腾出空间。但是随后操作系统缓存可能也需要从自身中逐出一个页面，以便为其从实际磁盘读取页面腾出空间。然后你最终会在两个地方都找到相同的页面，这会浪费缓存空间。因此，您更有可能需要从实际磁盘读取页面，而不是从操作系统缓存中读取页面，这要慢得多。从双缓冲的角度来看，您可能希望 shared_buffers 远小于系统 RAM 的一半（使用 OS 缓存作为主缓存）或远大于一半（使用 shared_buffers 作为主缓存）
另一个缺点是，如果它太大，您可能会开始出现内存不足错误或调用 OOM 杀手或以其他方式破坏系统的稳定性。
另一个问题是，在某些操作后，如 DROP TABLE、TRUNCATE 或在某些情况下结束 COPY，PostgreSQL 需要使大量缓冲区无效，并选择通过搜索整个缓冲区缓存来实现。如果你做了很多这样的操作，那段时间真的可以加起来很大的缓冲区缓存设置。
【讨论】：
一些工作负载（我知道DROP TABLE，但可能还有其他工作负载）使用较小的shared_buffers 性能更好。但本质上，这是一个反复试验的问题（或者更好的是：可重现的性能测试）。
如果您可以使shared_buffers 足够大，可以容纳您需要的数据库中的所有内容，那可能是一个不错的选择。
【讨论】：