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,
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.
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?
Réponses:
La surcharge de mémoire peut être désactivée par
vm.overcommit_memory=20 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%).Cela ne survivra pas à un redémarrage. Pour la persistance, mettez ceci dans le
/etc/sysctl.conffichier:et courir
sysctl -p. Pas besoin de redémarrer.la source
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)
la source
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.
la source