Consommation excessive de mémoire due à la précompilation des assets

[Ed_S]

Il est toujours recommandé d’avoir une zone d’échange (swap). Il est très judicieux d’autoriser le noyau à effectuer une sur-engagement (overcommit). Cela peut considérablement réduire vos besoins en mémoire de pointe.

Je réglerais ces deux points, puis je réessaierais. Pour le sur-engagement, consultez

MKJ's Opinionated Discourse Deployment Configuration

I have been running a Discourse forum with a substantial amount of content and plenty of images over the past few years. Maker Forums has over 100GB of images and over 400,000 posts, of which a substantial amount was imported, primarily from Google+, and the rest was created on the site. This post describes elements of how I eventually configured Maker Forums and, later, a few other Discourse instances. This is what I wish I knew when I got started, and which I’ve used to help others avoid some …

En termes de diagnostic, il pourrait être utile de vérifier dmesg pour des événements OOM, ce que vous pouvez faire après coup, et également d’exécuter vmstat au moment du blocage.

vmstat 5 5

Voici mon conseil général en matière de diagnostic :

@Ed_S

Au fait, si quelque chose ne fonctionne pas sans preuve évidente de la raison, et surtout si vous soupçonnez un manque de mémoire, il vaut la peine de vérifier le tueur de mémoire insuffisante, également appelé OOM-killer. Je recommande

dmesg|egrep -i "memory|oom|kill"

Édition : pour plus de commodité, je l’ajouterai à ma liste de diagnostics instantanés standard :

cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc