Vielen Dank für all die Details. Es ist gut, dass Sie das getan haben
aber ich denke, das wird wahrscheinlich nur bis zum nächsten Neustart dauern. Nach dem Neustart müssten Sie es erneut tun. Sehen Sie sich MKJs Opinionated Discourse Deployment Configuration für Tipps an, wie Sie dies dauerhaft machen können.
Es scheint möglich, dass Sie zu wenig Speicher haben (wobei ich RAM+Swap meine) und dennoch sollten 2+4 ausreichen. Bitte führen Sie die folgenden schnellen Diagnosen durch und posten Sie die Ergebnisse:
cat /etc/lsb-release
uptime
df -h /
free
swapon
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
Bitte teilen Sie auch Ihre app.yml-Datei hier mit – aber nicht die Passwörter und geheimen Token darin!
Wenn Sie zwei SSH-Verbindungen einrichten können, können Sie eine verwenden, um einen Anwendungsneustart durchzuführen, und die andere verwenden, um zu sehen, was die Maschine tut. Ich wechsle gerne ab
vmstat 5 5
ps auxrc
Es ist möglich, dass Sie auf eine Remote-Festplatte swappen – einen netzwerkgebundenen Speicher – und dies ist bekannt als ein Problem. Es wird sehr langsam sein. Vielleicht verursacht es ein Timeout und das ist das Problem. Vielleicht gibt es eine Möglichkeit, das Timeout anzupassen.
Ich habe dieses gefunden – vielleicht hilft es?
(Das Standard-Systemd-Timeout beträgt 90 Sekunden, zumindest in einigen Versionen von Systemd, passt also ganz gut.)
Sie könnten versuchen, dies zu umgehen, indem Sie TimeoutStartSec in der Systemd-Einheit von postgresql (oder sogar global) erhöhen, was vielleicht nur das Problem verbirgt, bis der nächste Dienst plötzlich nicht mehr startet.
Bearbeiten: Wenn ja, dann könnte dieser Rat gut sein:
Sie können in
/etc/systemd/system.confdie Zeilen auskommentieren:DefaultTimeoutStartSec=90s DefaultTimeoutStopSec=90sUnd den Wert auf das ändern, was Sie für angemessen halten.