Cent OS: Comment puis-je désactiver ou réduire le sur-engagement de mémoire, et est-ce sûr de le faire?


20

De temps en temps, "mon" serveur se bloque car il manque de mémoire et d'espace de swap. (il continue de répondre au ping mais rien de plus, pas même ssh).

On me dit que Linux fait un sur-engagement de mémoire, ce qui, autant que je sache, est le même que celui des banques avec de l'argent: il accorde aux processus plus de mémoire que ce qui est réellement disponible, en supposant que la plupart des processus n'utilisent pas réellement toute la mémoire qu'ils demandent, à du moins pas tous en même temps.

Veuillez supposer que c'est en fait la raison pour laquelle mon système se bloque parfois, ne discutons pas ici si c'est le cas (voir Qu'est - ce qui peut provoquer la panne de TOUS les services sur un serveur, tout en répondant au ping? Et comment le comprendre ) .

Donc,

  1. Comment puis-je désactiver ou réduire considérablement le sur-engagement de mémoire dans CentOS? J'ai lu qu'il y a deux paramètres appelés vm.overcommit_memory (valeurs 0, 1 ou 2) et vm.overcommit_ratiom mais je n'ai aucune idée où je dois les trouver et les modifier (certains fichiers de configuration, espérons-le), quelles valeurs dois-je essayer et si je dois redémarrer le serveur pour que les modifications soient effectives.

  2. et est-ce sûr? À quels effets secondaires puis-je m'attendre? En cherchant sur overcommit_memory, je trouve des choses effrayantes comme des gens qui disent que leur serveur ne peut plus démarrer ....

Étant donné que ce qui provoque l'augmentation soudaine de l'utilisation de la mémoire est mysql en raison des requêtes effectuées par php qui à son tour est appelé lors du traitement des requêtes http, je m'attendrais à ce que certains scripts php ne se terminent pas et donc quelque 500 réponses de temps en temps lorsque le serveur est trop occupé, ce qui est un risque que je peux prendre (certainement mieux que tout le serveur devienne inaccessible et doive le redémarrer).

Ou peut-il vraiment empêcher mon serveur de redémarrer si je choisis les mauvais paramètres?


1
La désactivation de la surcharge ne va pas vous aider lorsque vous manquez vraiment de mémoire. Cependant, l'ajout de RAM au serveur peut aider.
Michael Hampton

2
La désactivation de la surcharge ne sera pas la solution finale, mais cela aidera beaucoup, si à chaque fois que le serveur manque de mémoire (ce qui n'est que de temps en temps pendant quelques secondes), je n'ai que quelques demandes http rejetées (ou mal servi), au lieu de laisser mon serveur mourir complètement et pour toujours (jusqu'à ce que je le redémarre)
matteo

Réponses:


30

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 heuristiquement l'allocation en calculant la mémoire libre par rapport à la demande d'allocation en cours. Et le mettre à 1 active le mode sorcellerie, où le noyau annonce toujours qu'il a suffisamment de mémoire libre pour toute allocation. La valeur 2 signifie que les processus peuvent uniquement allouer jusqu'à une quantité configurable ( overcommit_ratio) de RAM et commenceront à recevoir des messages d'échec d'allocation ou de MOO lorsqu'il dépassera cette quantité.

Est-ce sûr de le faire, non. Je n'ai vu aucun cas d'utilisation approprié où la désactivation de la surcharge de la 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 le kernel-docspackage et accédez à /Documentation/sysctl/vm.txten savoir plus, ou lisez-le en ligne .

Si vous la définissez, vm.overcommit_memory=2elle se surchargera jusqu'au pourcentage de RAM physique configuré 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 le /etc/sysctl.conffichier:

vm.overcommit_memory=X

et courir sysctl -p. Pas besoin de redémarrer.


la partie à laquelle vous n'avez pas répondu est dans quel fichier je modifie ce paramètre vm.memory_overcommit et surtout si je dois redémarrer (ou quoi d'autre) pour qu'il prenne effet
matteo

2
echo 0/1/2> / proc / sys / vm / overcommit_memory Cela ne survivra pas à un redémarrage. Pour la persistance, placez-le dans le fichier /etc/sysctl.conf vm.overcommit_memory = X et exécutez sysctl -p. Pas besoin de redémarrer
Soham Chakraborty

Merci beaucoup. Je vous prie de bien vouloir l'ajouter au corps de la réponse afin que je puisse officiellement l'accepter.
matteo

1
Ajout de la nouvelle pièce.
Soham Chakraborty

4
"overcommit_ratio" a un effet important lors de l'utilisation de overcommit_memory = 2 - il détermine le pourcentage de RAM physique qui peut être alloué! Donc, si le ratio <100, vous laisserez de la RAM non allouée, peut-être pour le cache disque ou similaire. Le rapport par défaut est de 50%, vous n'utiliserez donc que 50% de la RAM physique si vous ne changez pas cela!
David Gardner

6

Déclaration totalement non qualifiée: la désactivation de la surcharge de mémoire est certainement "plus sûre" que son activation.

Le client l'a installé sur quelques centaines de serveurs Web et cela a beaucoup aidé avec les problèmes de stabilité. Il y a même un chèque Nagios appelant le feu très fort s'il n'est jamais désactivé.

D'un autre côté, les gens pourraient ne pas considérer comme «sûr» de perdre leurs processus en mémoire lorsqu'ils voudraient simplement surcharger un petit bélier et ne l'auraient jamais vraiment utilisé. (ie 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 êtes déjà en train de vous pencher pour vous débarrasser des problèmes connexes - je pense que cela pourrait vous aider.

(Je sais que je vais risquer un downvote par une personne grincheuse)


3

Je suis d'accord que la désactivation de la surcharge est plus sûre que de l'activer dans certaines circonstances. Si le serveur n'exécute que quelques gros travaux de mémoire (comme les simulations de circuits dans mon cas), il est beaucoup plus sûr de refuser à l'application la demande de mémoire à l'avance plutôt que d'attendre un événement OOM (qui ne manquera pas de suivre sous peu) Assez souvent, nous voyons des serveurs avoir des problèmes après que le tueur OOM a fait son travail.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.