Não é possível aumentar db_shared_buffers (0,1% da RAM total) e db_work_mem (0,03% da RAM total)

[markersocial]

Isso é um pouco complicado

Tenho uma instância Discourse recém-migrada em um novo servidor.

Estou recebendo o seguinte erro nos logs: PG::DiskFull (ERROR: não foi possível redimensionar o segmento de memória compartilhada "/PostgreSQL.1759815625" para 8388608 bytes: Sem espaço no dispositivo)

É estranho porque o servidor anterior (64 GB de RAM) não tinha esse problema e eu tinha estas configurações:

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

No novo servidor (128 GB de RAM), não consigo aumentar acima dos padrões básicos (tentei triplicar os valores abaixo e recebo o mesmo erro PG DiskFull):

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

A máquina anterior tem o Docker 27.x instalado (instalado automaticamente pelo instalador do Discourse). A nova máquina instalou o docker.io conforme as instruções (portanto, 26.x). Tentei mudar para o Docker 27.x para ver se isso estava relacionado, mas não mudou nada. Ambos estão no branch Stable do Discourse, versão 3.3.2.

Parece que shm_size pode ser o principal culpado:

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 …

Embora eu não entenda por que não era um problema no servidor anterior e é no novo. A única outra diferença principal é que o servidor antigo usa Ubuntu 22.04 LTS e o novo servidor está no 24.04 LTS.

Eu também tentei isso, mas as alterações são sobrescritas quando o contêiner é iniciado novamente

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 parece estar codificado no launcher:

launcher

launcher

launcher

Qualquer insight ou ajuda seria apreciado!

[pfaffman (Jay Pfaffman)]

@markersocial

: No space left on device

Refere-se ao espaço no disco rígido, não à RAM.

[markersocial]

@pfaffman

Refere-se ao espaço no disco rígido, não à RAM.

Obrigado @pfaffman - Eu pensei nisso inicialmente também, mas então li este tópico:

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 …

Há muito espaço livre também

[markersocial]

Então, uma solução rápida com fita adesiva é simplesmente editar o arquivo do lançador como:

cd /var/discourse
vi launcher

Em seguida, substitua todas as 3 ocorrências de
--shm-size=512m
pela quantidade de RAM desejada (eu usei 50% da RAM do sistema).

Em seguida, reconstrua. Será necessário editá-lo novamente toda vez que o lançador for atualizado.

Parece estar funcionando por enquanto.

[markersocial]

@mcdanlj

Configuração do Kernel

O Redis (um dos componentes chave nos quais o Discourse é construído) recomenda fortemente desabilitar páginas grandes transparentes ao usar persistência em disco (o que o Discourse faz), e eu também permito o overcommit de memória.

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

Então, para dar seguimento caso outra pessoa enfrente este problema - o acima resolveu para mim. Não preciso mais editar o shm-size no launcher.

Isso foi encontrado após notar este aviso durante a reconstrução:
AVISO O *overcommit* de memória deve estar habilitado! Sem ele, um salvamento em segundo plano ou replicação pode falhar em condições de pouca memória. Estando desabilitado, ele também pode causar falhas sem condição de pouca memória, veja https://github.com/jemalloc/jemalloc/issues/1328. Para corrigir este problema, adicione 'vm.overcommit_memory = 1' a /etc/sysctl.conf e então reinicie ou execute o comando 'sysctl vm.overcommit_memory=1' para que isso tenha efeito.