Éviter le démontage des applications Linux en manque de mémoire

Solution 1 :

Par défaut, Linux a un concept de gestion de la mémoire quelque peu endommagé par le cerveau :il vous permet d'allouer plus de mémoire que votre système n'en a, puis de terminer aléatoirement un processus lorsqu'il rencontre des problèmes. (La sémantique réelle de ce qui est tué est plus complexe que cela - Google "Linux OOM Killer" pour de nombreux détails et arguments pour savoir si c'est une bonne ou une mauvaise chose).

Pour redonner un semblant de bon sens à votre gestion de la mémoire :

1. Désactiver le OOM Killer (Mettez vm.oom-kill = 0 dans /etc/sysctl.conf)
2. Désactiver la surcharge mémoire (Mettre vm.overcommit_memory = 2 dans /etc/sysctl.conf)
   Notez qu'il s'agit d'une valeur trinaire :0 ="estimer si nous avons assez de RAM", 1 ="Toujours dire oui", 2 ="dire non si nous n'avons pas la mémoire")

Ces paramètres feront en sorte que Linux se comporte de manière traditionnelle (si un processus demande plus de mémoire que ce qui est disponible, malloc() échouera et le processus demandant la mémoire devrait faire face à cet échec).

Redémarrez votre machine pour la faire recharger /etc/sysctl.conf , ou utilisez le proc système de fichiers à activer immédiatement, sans redémarrage :

echo 2 > /proc/sys/vm/overcommit_memory 

Solution 2 :

Vous pouvez désactiver le surengagement, voir http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514

Solution 3 :

La réponse courte, pour un serveur, est d'acheter et d'installer plus de RAM.

Un serveur qui a suffisamment expérimenté OOM (Out-Of-Memory), alors en plus de l'option overcommit sysctl du gestionnaire de VM (mémoire virtuelle) dans les noyaux Linux, ce n'est pas une bonne chose.

L'augmentation de la quantité de swap (mémoire virtuelle qui a été paginée sur le disque par le gestionnaire de mémoire du noyau) aidera si les valeurs actuelles sont faibles et que l'utilisation implique de nombreuses tâches, chacune de ces grandes quantités de mémoire, plutôt qu'une ou quelques-unes. traite chacun demandant une énorme quantité de la mémoire virtuelle totale disponible (RAM + swap).

Pour de nombreuses applications, allouer plus de deux fois (2x) la quantité de RAM en tant que swap offre un retour sur amélioration décroissant. Dans certaines grandes simulations informatiques, cela peut être acceptable si le ralentissement de la vitesse est supportable.

Avec la RAM (ECC ou non) être tout à fait abordable pour des quantités modestes, par ex. 4-16 Go, je dois admettre que je n'ai pas rencontré ce problème moi-même depuis longtemps.

Les bases de l'examen de la consommation de mémoire, y compris l'utilisation de free et top , triés par utilisation de la mémoire, comme les deux évaluations rapides les plus courantes des modèles d'utilisation de la mémoire. Assurez-vous donc de comprendre au moins la signification de chaque champ dans la sortie de ces commandes.

En l'absence de spécificités des applications (par exemple, base de données, serveur de service réseau, traitement vidéo en temps réel) et de l'utilisation du serveur (peu d'utilisateurs expérimentés, 100 à 1 000 connexions utilisateur/client), je ne peux pas penser à des recommandations générales concernant la gestion des le problème OOM.

Solution 4 :

Vous pouvez utiliser ulimit pour réduire la quantité de mémoire qu'un processus est autorisé à réclamer avant d'être tué. C'est très utile si votre problème est un ou quelques processus en fuite qui bloquent votre serveur.

Si votre problème est que vous n'avez tout simplement pas assez de mémoire pour exécuter les services dont vous avez besoin, il n'y a que trois solutions :

1. Réduisez la mémoire utilisée par vos services en limitant les caches et similaires

2. Créez une zone d'échange plus grande. Cela vous coûtera en performance, mais peut vous faire gagner du temps.

3. Achetez plus de mémoire

Solution 5 :

Augmenter la quantité de mémoire physique peut ne pas être une réponse efficace dans toutes les circonstances.

Une façon de vérifier cela est la commande 'atop'. Particulièrement ces deux lignes.

Il s'agit d'un serveur hors service lorsqu'il était sain :

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

Quand il fonctionnait mal (et avant que nous ayons ajusté overcommit_memory de 50 à 90, nous verrions un comportement avec vmcom fonctionnant bien au-dessus de 50G, oom-killer faisant exploser des processus toutes les quelques secondes, et la charge continuait à rebondir radicalement en raison des processus enfants NFSd soufflés et recréé continuellement.

Nous avons récemment dupliqué des cas où les serveurs de terminaux Linux multi-utilisateurs surchargent massivement l'allocation de mémoire virtuelle, mais très peu de pages demandées sont réellement consommées.

Bien qu'il ne soit pas conseillé de suivre cette route exacte, nous avons ajusté la mémoire de surcharge de la valeur par défaut de 50 à 90, ce qui a atténué une partie du problème. Nous avons fini par devoir déplacer tous les utilisateurs vers un autre serveur de terminaux et redémarrer pour en tirer pleinement parti.