Impossible d'augmenter db_shared_buffers (0,1 % de la RAM totale) et db_work_mem (0,03 % de la RAM totale)

[markersocial]

C’est un peu déroutant

J’ai une instance Discourse fraîchement migrée sur un nouveau serveur.

Je reçois l’erreur dans les logs : PG::DiskFull (ERROR: could not resize shared memory segment \"/PostgreSQL.1759815625\" to 8388608 bytes: No space left on device )

C’est étrange car le serveur précédent (64 Go de RAM) n’avait pas ce problème et j’avais configuré ceci :

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

Sur le nouveau serveur (128 Go de RAM), je ne peux pas augmenter au-delà des valeurs par défaut (j’ai essayé de tripler les valeurs ci-dessous et j’obtiens la même erreur PG DiskFull) :

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

La machine précédente a Docker 27.x (installé automatiquement via l’installeur Discourse). La nouvelle machine a installé docker.io conformément aux instructions (donc 26.x). J’ai essayé de passer à Docker 27.x pour voir si c’était lié, mais cela n’a rien changé. Les deux sont sur la branche Stable Discourse, version 3.3.2.

Il semble que shm_size soit le principal coupable :

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 …

Bien que je ne comprenne pas pourquoi ce n’était pas un problème sur le serveur précédent et qu’il le soit sur le nouveau. L’autre principale différence est que l’ancien serveur utilise Ubuntu 22.04 LTS et le nouveau serveur est sur 24.04 LTS.

J’ai aussi essayé ceci, mais les modifications sont écrasées lorsque le conteneur est redémarré.

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 semble être codé en dur dans le lanceur :

launcher

launcher

launcher

Toute idée ou aide serait appréciée !

[pfaffman (Jay Pfaffman)]

@markersocial

: No space left on device

Fait référence à l’espace du disque dur, pas à la RAM.

[markersocial]

@pfaffman

Fait référence à l’espace disque dur, pas à la RAM.

Merci @pfaffman - j’ai pensé la même chose au début, mais ensuite j’ai lu ce fil de discussion :

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 …

Il y a aussi beaucoup d’espace libre

[markersocial]

Une solution rapide avec du ruban adhésif consiste simplement à modifier le fichier launcher comme suit :

cd /var/discourse
vi launcher

Remplacez ensuite les 3 occurrences de
--shm-size=512m
par la quantité de RAM souhaitée (j’ai choisi 50 % de la RAM système).

Puis reconstruisez. Il faudra le modifier à nouveau chaque fois que le launcher sera mis à jour.

Cela semble faire l’affaire pour le moment.

[markersocial]

@mcdanlj

Configuration du noyau

Redis (l’un des composants clés sur lesquels Discourse est construit) recommande fortement de désactiver les pages transparentes volumineuses lors de l’utilisation de la persistance sur disque (ce que fait Discourse), et j’autorise également le sur-allocation de mémoire.

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

Pour faire suite au cas où quelqu’un d’autre rencontrerait ce problème, ce qui précède l’a résolu pour moi. Je n’ai plus besoin de modifier shm-size dans le lanceur.

Cela a été découvert après avoir remarqué cet avertissement lors de la reconstruction :
AVERTISSEMENT La sur-allocation de mémoire doit être activée ! Sans elle, une sauvegarde en arrière-plan ou une réplication peut échouer dans des conditions de faible mémoire. Étant désactivée, elle peut également causer des échecs sans condition de faible mémoire, voir https://github.com/jemalloc/jemalloc/issues/1328. Pour résoudre ce problème, ajoutez 'vm.overcommit_memory = 1' à /etc/sysctl.conf, puis redémarrez ou exécutez la commande 'sysctl vm.overcommit_memory=1' pour que cela prenne effet.