# Exigences élevées en mémoire pour la reconstruction : édition avril 2025 **URL:** \ **Category:** Self-hosting\ **Tags:** hosting\ **Created:** [Mars 31, 2025, 12:37 UTC](https://meta.discourse.org/t/high-rebuild-memory-requirements-april-2025-edition/360419 "2025-03-31T00:37:29Z")\ **Posts on this page:** 1\ **Showing post:** 14
**Author:** ![mpalmer](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mpalmer/32/45740_2.png) [@mpalmer](https://meta.discourse.org/u/mpalmer)\ **Post date:** [Avril 5, 2025, 11:01 UTC](https://meta.discourse.org/t/high-rebuild-memory-requirements-april-2025-edition/360419/14 "2025-04-05T23:01:50Z")
Le surallocation est sans objet ici, car le problème n’est pas que les processus soient tués prématurément par OOM, il s’agit simplement d’essayer de mettre dix livres de mémoire allouée dans un sac de cinq livres. Il n’est pratiquement pas possible d’exécuter une reconstruction de Discourse avec overcommit\_memory=2, car ember (entre autres, sans aucun doute) pré-alloue des masses de mémoire virtuelle (si ma mémoire est bonne, environ 80 Go, c’est ce que j’ai vu), donc cela échouera toujours à tout réglage raisonnable de overcommit\_ratio. Définir overcommit\_memory=1 n’aidera pas non plus, car, encore une fois, le problème n’est pas un VMM trop zélé qui tue des processus, mais une gestion de la mémoire hideusement médiocre de la part du compilateur ember. --- _[View the full topic](https://meta.discourse.org/t/high-rebuild-memory-requirements-april-2025-edition/360419)._