Не удается увеличить 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 ).

Это странно, потому что на предыдущем сервере (64 ГБ ОЗУ) этой проблемы не было, и у меня были установлены следующие значения:

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

На новом сервере (128 ГБ ОЗУ) я не могу увеличить значения выше базовых по умолчанию (я пытался утроить указанные ниже значения, но получаю ту же ошибку PG DiskFull):

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

На предыдущей машине установлен Docker 27.x (автоматически установлен через установщик Discourse). На новой машине, следуя инструкциям, установлен docker.io (версия 26.x). Я пробовал переключиться на Docker 27.x, чтобы проверить, связано ли это с этим, но это ничего не изменило. Оба сервера работают на стабильной ветке 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

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]

@Michael K Johnson

Настройка ядра

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 Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.