Impossibile aumentare db_shared_buffers (0,1% della RAM totale) e db_work_mem (0,03% della RAM totale)

[markersocial]

Questo è un vero rompicapo

Ho un’istanza Discourse appena migrata su un nuovo server.

Ricevo l’errore nei log: PG::DiskFull (ERROR: could not resize shared memory segment \"/PostgreSQL.1759815625\" to 8388608 bytes: No space left on device )

È strano perché il server precedente (64 GB di RAM) non aveva questo problema e avevo impostato:

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

Sul nuovo server (128 GB di RAM), non riesco ad aumentare oltre i valori predefiniti di base (ho provato a triplicare i valori sottostanti e ottengo lo stesso errore PG DiskFull):

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

La macchina precedente ha Docker 27.x (installato automaticamente tramite l’installer di Discourse). La nuova macchina ha installato docker.io come da istruzioni (quindi 26.x). Ho provato a passare a Docker 27.x per vedere se fosse correlato, ma non ha cambiato nulla. Entrambi sono sul ramo Stable di Discourse, versione 3.3.2.

Sembra che shm_size possa essere il colpevole principale:

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 …

Anche se non ho idea del perché non fosse un problema sul server precedente e lo sia sul nuovo server. L’unica altra differenza principale è che il vecchio server utilizza Ubuntu 22.04 LTS e il nuovo server è su 24.04 LTS.

Ho provato anche questo, ma le modifiche vengono sovrascritte quando il container viene riavviato

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 sembra essere codificato nel launcher:

launcher

launcher

launcher

Qualsiasi intuizione o aiuto sarebbe apprezzato!

[pfaffman (Jay Pfaffman)]

@markersocial

: No space left on device

Si riferisce allo spazio sul disco rigido, non alla RAM.

[markersocial]

@pfaffman

Si riferisce allo spazio su disco rigido, non alla RAM.

Grazie @pfaffman - l’avevo pensato anch’io inizialmente, ma poi ho letto questa discussione:

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 …

C’è anche molto spazio libero

[markersocial]

Quindi una rapida soluzione con nastro adesivo consiste semplicemente nell’modificare il file del launcher come:\n\n\ncd /var/discourse\nvi launcher\n\n\nQuindi sostituire tutte e 3 le occorrenze di\n--shm-size=512m\ncon la quantità di RAM desiderata (io sono andato con il 50% della RAM di sistema).\n\nQuindi ricompilare. Sarà necessario modificarlo di nuovo ogni volta che il launcher si aggiorna.\n\nSembra fare il suo lavoro per il momento.\n\n

[markersocial]

@mcdanlj

Configurazione del kernel

Redis (uno dei componenti chiave su cui si basa Discourse) raccomanda vivamente di disabilitare le pagine trasparenti di grandi dimensioni quando si utilizza la persistenza su disco (cosa che Discourse fa), e io consento anche il memory overcommit.

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

Quindi, per dare seguito nel caso in cui qualcun altro riscontri questo problema: quanto sopra lo ha risolto per me. Non ho più bisogno di modificare shm-size nel launcher.

Questo è stato trovato dopo aver notato questo avviso durante la ricostruzione:
ATTENZIONE Il memory overcommit deve essere abilitato! Senza di esso, un salvataggio in background o la replica potrebbero fallire in condizioni di memoria insufficiente. Essendo disabilitato, può anche causare fallimenti senza condizioni di memoria insufficiente, vedi https://github.com/jemalloc/jemalloc/issues/1328. Per risolvere questo problema, aggiungi 'vm.overcommit_memory = 1' a /etc/sysctl.conf e quindi riavvia o esegui il comando 'sysctl vm.overcommit_memory=1' affinché ciò abbia effetto.