No se pueden aumentar db_shared_buffers (0,1% de la RAM total) y db_work_mem (0,03% de la RAM total)

[markersocial]

Esto es un poco desconcertante

Tengo una instancia de Discourse recién migrada en un servidor nuevo.

Estoy recibiendo el siguiente error en los registros: PG::DiskFull (ERROR: no se pudo redimensionar el segmento de memoria compartida "/PostgreSQL.1759815625" a 8388608 bytes: No queda espacio en el dispositivo)

Es extraño porque el servidor anterior (64 GB de RAM) no tenía este problema y tenía configurados estos valores:

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

En el nuevo servidor (128 GB de RAM), no puedo aumentar por encima de los valores predeterminados (intenté triplicar los valores a continuación y obtuve el mismo error PG DiskFull):

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

La máquina anterior tiene Docker 27.x (instalado automáticamente a través del instalador de Discourse). La nueva máquina instaló docker.io según las instrucciones (por lo tanto, 26.x). Intenté cambiar a Docker 27.x para ver si estaba relacionado, pero no cambió nada. Ambas están en la rama estable de Discourse, versión 3.3.2.

Parece que shm_size podría ser el principal culpable:

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 …

Aunque no tengo idea de por qué no fue un problema en el servidor anterior y sí lo es en el nuevo. La única otra diferencia importante es que el servidor antiguo usa Ubuntu 22.04 LTS y el nuevo servidor está en 24.04 LTS.

También intenté esto, pero los cambios se sobrescriben cuando el contenedor se inicia de nuevo.

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 en el lanzador:

launcher

launcher

launcher

¡Cualquier información o ayuda sería apreciada!

[pfaffman (Jay Pfaffman)]

@markersocial

: No space left on device

Se refiere al espacio en el disco duro, no a la memoria RAM.

[markersocial]

@pfaffman

Se refiere al espacio en el disco duro, no a la RAM.

Gracias @pfaffman. Yo también lo pensé al principio, pero luego leí este hilo:

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 …

También hay mucho espacio libre

[markersocial]

Una solución rápida con cinta adhesiva es simplemente editar el archivo del lanzador así:

cd /var/discourse
vi launcher

Luego, reemplace las 3 ocurrencias de
--shm-size=512m
con la cantidad de RAM deseada (yo elegí el 50% de la RAM del sistema).

Luego, reconstruya. Deberá editarlo nuevamente cada vez que se actualice el lanzador.

Parece que está funcionando por el momento.

[markersocial]

@mcdanlj

Configuración del kernel

Redis (uno de los componentes clave en los que se basa Discourse) recomienda encarecidamente deshabilitar las páginas grandes transparentes cuando se utiliza persistencia en disco (lo que hace Discourse), y yo también permito la sobreasignación de memoria.

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

Así que, para dar seguimiento en caso de que alguien más se enfrente a este problema: lo anterior lo resolvió para mí. Ya no necesito editar shm-size en el lanzador.

Esto se encontró después de notar esta advertencia durante la reconstrucción:
ADVERTENCIA ¡La sobreasignación de memoria debe estar habilitada! Sin ella, un guardado en segundo plano o la replicación pueden fallar en condiciones de poca memoria. Al estar deshabilitada, también puede causar fallos sin condiciones de poca memoria, ver https://github.com/jemalloc/jemalloc/issues/1328. Para solucionar este problema, agregue 'vm.overcommit_memory = 1' a /etc/sysctl.conf y luego reinicie o ejecute el comando 'sysctl vm.overcommit_memory=1' para que esto tenga efecto.