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