Kann db_shared_buffers (0,1% des Arbeitsspeichers) und db_work_mem (0,03% des Arbeitsspeichers) nicht erhöhen

[markersocial]

Das ist ein ziemliches Rätsel

Habe eine frisch migrierte Discourse-Instanz auf einem neuen Server.

Erhalte die Fehlermeldung in den Logs: PG::DiskFull (ERROR: could not resize shared memory segment „/PostgreSQL.1759815625“ to 8388608 bytes: No space left on device )

Es ist seltsam, denn der vorherige Server (64 GB RAM) hatte dieses Problem nicht und ich hatte diese Werte eingestellt:

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

Auf dem neuen Server (128 GB RAM) kann ich die Werte nicht über die Standardwerte hinaus erhöhen (ich habe versucht, die unten stehenden Werte zu verdreifachen, und erhalte dieselbe PG DiskFull-Fehlermeldung):

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

Die vorherige Maschine hat Docker 27.x darauf (automatisch über den Discourse-Installer installiert). Die neue Maschine hat Docker.io gemäß den Anweisungen installiert (also 26.x). Ich habe versucht, auf Docker 27.x zu wechseln, um zu sehen, ob das damit zusammenhängt – aber es hat nichts geändert. Beide befinden sich auf dem stabilen Discourse-Zweig, Version 3.3.2.

Es scheint, als wäre shm_size der Hauptschuldige:

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 …

Ich habe jedoch keine Ahnung, warum es auf dem vorherigen Server kein Problem war und auf dem neuen Server schon. Der einzige andere Hauptunterschied ist, dass der alte Server Ubuntu 22.04 LTS verwendet und der neue Server auf 24.04 LTS läuft.

Ich habe auch dies versucht, aber die Änderungen werden überschrieben, wenn der Container erneut gestartet wird

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 scheint fest im Launcher kodiert zu sein:

launcher

launcher

launcher

Jede Einsicht oder Hilfe wäre willkommen!

[pfaffman (Jay Pfaffman)]

@markersocial

Kein Speicherplatz mehr auf dem Gerät

Bezieht sich auf den Festplattenspeicher, nicht auf den RAM.

[markersocial]

@pfaffman

Bezieht sich auf den Festplattenspeicher, nicht auf den RAM.

Danke @pfaffman - das dachte ich anfangs auch, aber dann habe ich diesen Thread gelesen:

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 …

Es gibt auch viel freien Speicherplatz

[markersocial]

Eine schnelle Klebebandlösung besteht darin, die Launcher-Datei wie folgt zu bearbeiten:

cd /var/discourse
vi launcher

Ersetzen Sie dann alle 3 Vorkommen von
--shm-size=512m
durch die gewünschte RAM-Menge (ich habe 50 % des Systemspeichers verwendet).

Bauen Sie dann neu. Sie müssen sie jedes Mal erneut bearbeiten, wenn der Launcher aktualisiert wird.

Scheint vorerst seinen Zweck zu erfüllen.

[markersocial]

@mcdanlj

Kernel-Konfiguration

Redis (eine der Schlüsselkomponenten, auf denen Discourse aufbaut) empfiehlt dringend, transparente riesige Seiten zu deaktivieren, wenn die Persistenz auf der Festplatte verwendet wird (was Discourse tut), und ich erlaube auch 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

Um dies zu klären, falls jemand anderes auf dieses Problem stößt – das oben Genannte hat es für mich gelöst. Ich muss die shm-size im Launcher nicht mehr bearbeiten.

Dies wurde festgestellt, nachdem diese Warnung während des Rebuilds bemerkt wurde:
WARNUNG Memory overcommit muss aktiviert sein! Ohne ihn kann ein Hintergrundspeichern oder eine Replikation unter geringen Speicherbedingungen fehlschlagen. Wenn es deaktiviert ist, kann es auch ohne geringe Speicherbedingungen zu Fehlern kommen. Siehe https://github.com/jemalloc/jemalloc/issues/1328. Um dieses Problem zu beheben, fügen Sie 'vm.overcommit_memory = 1' zu /etc/sysctl.conf hinzu und starten Sie dann neu oder führen Sie den Befehl 'sysctl vm.overcommit_memory=1' aus, damit er wirksam wird.