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

[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.