Solution 1 :
La surcharge de mémoire peut être désactivée par vm.overcommit_memory=2
0 est le mode par défaut, où le noyau détermine de manière heuristique l'allocation en calculant la mémoire libre par rapport à la demande d'allocation en cours. Et le définir sur 1 active le mode magique, où le noyau annonce toujours qu'il a suffisamment de mémoire libre pour toute allocation. Le réglage sur 2 signifie que les processus ne peuvent allouer que jusqu'à un montant configurable (overcommit_ratio ) de RAM et commencera à recevoir des messages d'échec d'allocation ou OOM lorsqu'il dépassera ce montant.
Est-ce sécuritaire de le faire, non. Je n'ai vu aucun cas d'utilisation approprié où la désactivation de la surcharge de mémoire a réellement aidé, à moins que vous ne soyez sûr à 100% de la charge de travail et de la capacité matérielle. Si vous êtes intéressé, installez kernel-docs package et aller à /Documentation/sysctl/vm.txt pour en savoir plus, ou lisez-le en ligne.
Si vous définissez vm.overcommit_memory=2 alors il surengagera jusqu'au pourcentage de RAM physique configuré dans vm.overcommit_ratio (la valeur par défaut est 50 %).
echo 0/1/2 > /proc/sys/vm/overcommit_memory
Cela ne survivra pas à un redémarrage. Pour la persistance, mettez ceci dans /etc/sysctl.conf fichier :
vm.overcommit_memory=X
et lancez sysctl -p . Pas besoin de redémarrer.
Solution 2 :
Déclaration totalement sans réserve :la désactivation de la surcharge de mémoire est définitivement "plus sûre" que son activation.
$customer l'a installé sur quelques centaines de serveurs Web et cela a beaucoup aidé avec des problèmes de stabilité.
D'un autre côté, les gens pourraient ne pas considérer qu'il est "sûr" que leurs processus sortent de la mémoire alors qu'ils aimeraient simplement surengager un peu de RAM et ne l'utiliseraient jamais vraiment (c'est-à-dire que SAP serait un très bon exemple)
Donc, vous êtes de retour pour voir si cela améliore les choses pour vous. Puisque vous y réfléchissez déjà pour vous débarrasser des problèmes connexes, je pense que cela pourrait vous aider.
(Je sais que je risquerai un vote négatif de la part d'une personne grincheuse)
Solution 3 :
Je suis d'accord que la désactivation de l'overcommit est plus sûre que de l'activer dans certaines circonstances. Si le serveur n'exécute que quelques travaux de mémoire volumineux (comme des simulations de circuits dans mon cas), il est beaucoup plus sûr de refuser à l'application la demande de mémoire plutôt que d'attendre un événement OOM (qui suivra certainement sous peu). Très souvent, nous voyons des serveurs avoir des problèmes après que le tueur OOM a fait son travail.