Merci pour tous les détails. C’est bien que vous ayez fait cela
mais je pense que faire cela ne durera que jusqu’au prochain redémarrage. Après le redémarrage, vous devrez le refaire. Voir MKJ’s Opinionated Discourse Deployment Configuration pour des conseils sur la façon de rendre cela permanent.
Il est possible que vous ayez trop peu de mémoire (j’entends par là RAM+swap) et pourtant 2+4 devraient suffire. Veuillez exécuter les diagnostics rapides suivants et poster les résultats :
cat /etc/lsb-release
uptime
df -h /
free
swapon
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
Veuillez également partager votre fichier app.yml ici - mais pas les mots de passe et les jetons secrets qu’il contient !
Si vous êtes en mesure d’établir deux connexions SSH, vous pouvez en utiliser une pour reconstruire une application et utiliser l’autre pour voir ce que la machine fait. J’aime alterner
vmstat 5 5
ps auxrc
Il est possible que vous utilisiez un disque distant pour le swap - un stockage attaché au réseau - et cela est connu pour être un problème. Ce sera très lent. Peut-être que cela provoque un délai d’attente et que c’est le problème. Peut-être qu’il y a un moyen d’ajuster le délai d’attente.
J’ai trouvé ceci - peut-être que cela aide ?
(Le délai d’attente système par défaut est de 90 secondes, du moins dans certaines versions de systemd, donc cela correspond assez bien).
Vous pourriez essayer de contourner cela en augmentant TimeoutStartSec dans l’unité systemd de postgresql (ou même globalement), ce qui ne fait peut-être que masquer le problème jusqu’à ce que le prochain service ne démarre plus soudainement.
Modifier : si c’est le cas, alors ce conseil pourrait être bon :
Vous pouvez décommenter dans
/etc/systemd/system.confles lignes :DefaultTimeoutStartSec=90s DefaultTimeoutStopSec=90sEt changer la valeur à ce que vous jugez approprié.