无法增加 db_shared_buffers（总内存的0.1%）和 db_work_mem（总内存的0.03%）

[markersocial]

这真让人费解

刚刚迁移了一个 Discourse 实例到新服务器。

在日志中看到这个错误：PG::DiskFull (ERROR: could not resize shared memory segment “/PostgreSQL.1759815625” to 8388608 bytes: No space left on device )

这很奇怪，因为我之前的服务器（64GB 内存）没有这个问题，而且我设置了：

db_shared_buffers: "25632MB"
db_work_mem: "160MB"

在新服务器（128GB 内存）上，我无法增加到默认值以上（我尝试将以下值增加三倍，但得到相同的 PG DiskFull 错误）：

db_shared_buffers: "128MB"
db_work_mem: "40MB"

之前的机器上安装了 Docker 27.x（通过 discourse 安装程序自动安装）。新机器按照说明安装了 docker.io（所以是 26.x）。我尝试切换到 Docker 27.x 看看是否有关联，但没有改变任何东西。两者都运行在 Stable Discourse 分支，版本是 3.3.2。

看起来 shm_size 可能是主要原因：

PG throws could not resize shared memory segment error

This is due to the fact that docker by default restricts shared memory size to 64MB which makes pg10 run afoul of this limitation when doing a number of scatter/gather jobs in parallel: Outside the container: supermathie@host: ~ $ df -h /dev/shm Filesystem Size Used Avail Use% Mounted on none 63G 1.2M 63G 1% /run/shm Inside the container: supermathie@host: ~ $ docker exec -it postgres-master df -h /dev/shm Filesystem Size Used Avail Use% Mounted on shm …

不过我不知道为什么前一台服务器没有这个问题，而新服务器却出现了。唯一的其他主要区别是旧服务器使用 Ubuntu 22.04 LTS，而新服务器使用的是 24.04 LTS。

我也尝试过这个，但更改在容器重新启动后被覆盖了

Docker shm_size Option in app.yml

Hey @Ghan In the meantime (for testing purposes, see caveat below), you can change this directly with docker after the container is built, as follows: Edit the /var/lib/docker/containers/$CONTAINER_ID/hostconfig.json file directly. For example, change the value for ShmSize in the file above. Stop and restart the container. In our docker container hostconfig file, it looks like this: "ShmSize":536870912, [Screen Shot 2020-12-29 at 12.39.17 PM] HTH Caveat: Some people have posted that y…

shm_size 似乎被硬编码到启动器中了：

launcher

launcher

launcher

任何见解或帮助都将不胜感激！

[pfaffman (Jay Pfaffman)]

@markersocial

: 设备空间不足

指的是硬盘空间，而不是内存。

[markersocial]

@pfaffman

指的是硬盘空间，而不是内存。

谢谢 @pfaffman - 我一开始也这么想，但后来我读了这个帖子：

PG throws could not resize shared memory segment error

After upgrading (with ‘launcher rebuild app’ times two) to Postgres 10, we’ve started seeing errors like this in /logs: Failed to handle exception in exception app middleware : PG::DiskFull: ERROR: could not resize shared memory segment "/PostgreSQL.682207201" to 283432 bytes: No space left on device : SELECT "topics"."id" AS t0_r0, "topics"."title" AS t0_r1, "topics"."last_posted_at" AS t0_r2, … Ideas? Looks like PG is unable to increase the size of a shared memory segment, can this be tuned …

还有很多可用空间

[markersocial]

一个快速的胶带修复方法是像这样编辑启动器文件：

cd /var/discourse
vi launcher

然后将所有 3 处出现的 --shm-size=512m 替换为您想要的内存量（我选择了系统内存的 50%）。

然后重新构建。每次启动器更新时都需要再次编辑它。

目前似乎能解决问题。

[markersocial]

@mcdanlj

Kernel configuration

Redis（Discourse 构建所依赖的关键组件之一）强烈建议在使用磁盘持久化时禁用透明大页（Discourse 就是这样做的），我也允许内存超额分配。

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system

所以，如果其他人遇到此问题，以上方法解决了我的问题。我不再需要在启动器中编辑 shm-size。

这是在重建过程中注意到此警告后发现的：
WARNING 必须启用内存超额分配！否则，在内存不足的情况下，后台保存或复制可能会失败。禁用它也可能在内存不足的情况下导致失败，请参阅 https://github.com/jemalloc/jemalloc/issues/1328。要解决此问题，请将 'vm.overcommit_memory = 1' 添加到 /etc/sysctl.conf，然后重新启动或运行命令 'sysctl vm.overcommit_memory=1' 使其生效。