# 无法增加 db\_shared\_buffers（总内存的0.1%）和 db\_work\_mem（总内存的0.03%）

**URL:** <https://meta.discourse.org/t/cant-increase-db-shared-buffers-0-1-of-total-ram-and-db-work-mem-0-03-of-total-ram/339404>\
**Category:** Support\
**Created:** [2024年十一月29日 22:02 UTC](https://meta.discourse.org/t/cant-increase-db-shared-buffers-0-1-of-total-ram-and-db-work-mem-0-03-of-total-ram/339404 "2024-11-29T22:02:27Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)\
**Post date:** [2024年十一月29日 22:02 UTC](https://meta.discourse.org/t/cant-increase-db-shared-buffers-0-1-of-total-ram-and-db-work-mem-0-03-of-total-ram/339404/1 "2024-11-29T22:02:27Z")

</div>

这真让人费解 🙃

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

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

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

```plaintext
db_shared_buffers: "25632MB"
db_work_mem: "160MB"

```

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

```plaintext
db_shared_buffers: "128MB"
db_work_mem: "40MB"

```

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

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

> [@PG throws could not resize shared memory segment error](https://meta.discourse.org/t/pg-throws-could-not-resize-shared-memory-segment-error/84744/3?u=markersocial):
>
> This is due to the fact that docker by default [restricts shared memory size](https://www.postgresql.org/message-id/CAEepm%3D2wXSfmS601nUVCftJKRPF%3DPRX%2BDYZxMeT8M2WwLSanVQ%40mail.gmail.com) 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](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/10?u=markersocial):
>
> 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, HTH Caveat: Some people have posted that y…

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

> <https://github.com/discourse/discourse_docker/blob/40169e87630008d00dcc559606eecebca2d82e78/launcher#L600>

> <https://github.com/discourse/discourse_docker/blob/40169e87630008d00dcc559606eecebca2d82e78/launcher#L616>

> <https://github.com/discourse/discourse_docker/blob/40169e87630008d00dcc559606eecebca2d82e78/launcher#L659>

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

![](https://media.tenor.com/TsJCldWFq3IAAAAC/troubleshooting-it-admin.gif)

---

<div class="post-metadata">

**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
**Post date:** [2024年十一月29日 22:51 UTC](https://meta.discourse.org/t/cant-increase-db-shared-buffers-0-1-of-total-ram-and-db-work-mem-0-03-of-total-ram/339404/2 "2024-11-29T22:51:00Z")

</div>

> [@markersocial](#):
>
> : 设备空间不足

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

---

<div class="post-metadata">

**Author:** ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)\
**Post date:** [2024年十一月29日 23:40 UTC](https://meta.discourse.org/t/cant-increase-db-shared-buffers-0-1-of-total-ram-and-db-work-mem-0-03-of-total-ram/339404/3 "2024-11-29T23:40:16Z")

</div>

> [@pfaffman](#):
>
> 指的是硬盘空间，而不是内存。

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

> [@PG throws could not resize shared memory segment error](https://meta.discourse.org/t/pg-throws-could-not-resize-shared-memory-segment-error/84744?u=markersocial):
>
> 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 …

还有很多可用空间 😕

---

<div class="post-metadata">

**Author:** ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)\
**Post date:** [2024年十一月30日 03:30 UTC](https://meta.discourse.org/t/cant-increase-db-shared-buffers-0-1-of-total-ram-and-db-work-mem-0-03-of-total-ram/339404/4 "2024-11-30T03:30:52Z")

</div>

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

```plaintext
cd /var/discourse
vi launcher

```

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

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

目前似乎能解决问题。

![water leaking fix with flex tape](https://media.tenor.com/u8ukYJDixewAAAAC/leaking-water-leaking.gif)

---

<div class="post-metadata">

**Author:** ![markersocial](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markersocial/32/170136_2.png) [@markersocial](https://meta.discourse.org/u/markersocial)\
**Post date:** [2024年十二月5日 08:10 UTC](https://meta.discourse.org/t/cant-increase-db-shared-buffers-0-1-of-total-ram-and-db-work-mem-0-03-of-total-ram/339404/5 "2024-12-05T08:10:20Z")

</div>

> [@mcdanlj](#):
>
> ## Kernel configuration
> 
> Redis（Discourse 构建所依赖的关键组件之一）[强烈建议在使用磁盘持久化时禁用透明大页](https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages)（Discourse 就是这样做的），我也允许内存超额分配。
> 
> ```plaintext
> 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' 使其生效。`