postgresql - 增加 shared_buffer > 25% 的 RAM 会使 Postgres 崩溃，Ubuntu 报告大量 "available"内存

Question

我有一个流量非常低(几百个用户)的非营利网站，但它由一个相当繁忙的 PostGIS 数据库提供支持。大部分数据库事件来自从政府 API 收集降雨量和流量数据，然后汇总这些数据(过去 3、6、12 小时等每个雨量计的降雨量等)。因为我不对网站收费，所以我尽量降低托管成本。我正在将它迁移到具有 1GB RAM 的新 Ubuntu VPS。因此，我遵循一般经验法则将 Postgres 的 shared_memory 设置为 250MB(总 RAM 的 25%)。当然，此服务器并非完全专用于 Postgres，但我的网络流量非常低。

这是此服务器上相当典型的 RAM 情况(目前事件较少)

              total        used        free      shared  buff/cache   available
Mem:           1024         228           0         379         795         656
Swap:          1024         676         347
Total:         2048         905         347

所有被频繁使用的索引都具有非常高的命中率 (>0.945)，但一些表数据要低得多:一些低于 0.5，但它们并没有被大量使用，我怀疑最近的和查询最多的数据。所以还没有表演障碍。当我查询 pg_buffercache 时，它​​显示缓冲区中有 247MB。这是服务器上唯一的数据库。所以我认为它可以从更多的 shared_buffers 中受益。

所以我将 share_buffer 增加到 350MB 并重新启动了服务器。不只是 Postgres，而是整个 Ubuntu 服务器。重新启动后，我无法通过 PgAdmin 4(它在我的桌面 Ubuntu 上运行，而不是在服务器上运行)连接到 Postgres。然后，我的某些 map 层(PostGIS 表)不会显示在我的 OpenLayers map 上。当我通过 php 脚本粘贴 OL 对 PG 的一些调用时，它返回 505 Internal Server Error。所以我将缓冲区改回 250MB 并重新启动了服务器。一切都恢复正常了。我尝试了 300MB，但得到了完全相同的症状。

所以我查看了 PG 日志:

2017-10-10 19:22:50.855 EDT [3485] FATAL:  could not map anonymous shared memory: Cannot allocate memory
2017-10-10 19:22:50.855 EDT [3485] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 562085888 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

我是 Linux 的新手，在 Linux 管理员方面绝对是新手(我以前的主机管理数据库和服务器)。据我所知，Linux 将缓存大量内部文件以提高性能，但它应该在应用程序需要时放弃一些缓存。那是“增益/缓存”，对吧？应该有 656MB 的“可用空间”，对吧？那么，为什么 PG 不能获得其中的 50 或 100MB？

Answer 1

您的内核共享内存设置需要使用 sysctl 更新。以下将允许最多 16gb 的共享内存，这可能就足够了。

 sysctl -w kernel.shmmax=17179869184
 sysctl -w kernel.shmall=4194304

有关这些参数的更多信息，请参阅以下内容: https://www.postgresql.org/docs/9.0/static/kernel-resources.html https://serverfault.com/questions/341680/postgresql-performance-adjusting-shmmax-and-shmall