Je constate qu'à l'occasion, ma boîte Linux manque de mémoire et commence à détruire des processus aléatoires pour y faire face.
Je suis curieux de savoir ce que les administrateurs font pour éviter cela ? La seule vraie solution est-elle d'augmenter la quantité de mémoire (est-ce que le fait d'augmenter le swap seul va aider ?), ou y a-t-il de meilleures façons de configurer la boîte avec des logiciels pour éviter cela ? (par exemple, des quotas ou autre ?).
Par défaut, Linux a un concept de gestion de la mémoire quelque peu détraqué : il vous laisse allouer plus de mémoire que votre système n'en a, puis termine aléatoirement un processus lorsqu'il a 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 sur le fait que c'est une bonne ou une mauvaise chose).
Pour restaurer un semblant de bon sens dans votre gestion de la mémoire :
vm.oom-kill = 0 dans /etc/sysctl.conf)vm.overcommit_memory = 2 dans /etc/sysctl.conf)Ces paramètres feront en sorte que Linux se comporte de manière traditionnelle (si un processus demande plus de mémoire que celle qui est disponible, malloc() échouera et le processus demandant la mémoire est censé faire face à cet échec).
Redémarrez votre machine pour qu'elle se recharge /etc/sysctl.conf ou utilisez le bouton proc pour activer le système de fichiers tout de suite, sans redémarrage :
echo 2 > /proc/sys/vm/overcommit_memory
Vous pouvez désactiver l'overcommit, voir http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514
La réponse courte, pour un serveur, est d'acheter et d'installer plus de RAM.
Un serveur qui, de manière routinière, a suffisamment d'expérience OOM (Out-Of-Memory), alors, outre l'option sysctl overcommit du gestionnaire de VM (mémoire virtuelle) dans les noyaux Linux, ce n'est pas une bonne chose.
Augmenter la quantité de swap (mémoire virtuelle qui a été paginée sur le disque par le gestionnaire de mémoire du noyau) sera utile si les valeurs actuelles sont faibles, et si l'utilisation implique de nombreuses tâches nécessitant chacune de grandes quantités de mémoire, plutôt qu'un ou quelques processus demandant chacun une énorme quantité de la mémoire virtuelle totale disponible (RAM + swap).
Pour de nombreuses applications, l'allocation de plus de deux fois (2x) la quantité de RAM en tant que swap offre un rendement décroissant sur l'amélioration. Dans certaines grandes simulations de calcul, cela peut être acceptable si le ralentissement de la vitesse est supportable.
La RAM (ECC ou non) étant tout à fait abordable pour des quantités modestes, par exemple 4-16 GB, je dois admettre que je n'ai pas rencontré ce problème moi-même depuis longtemps.
Les bases pour examiner la consommation de mémoire, y compris l'utilisation de free y top triées 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 la signification de chaque champ dans la sortie de ces commandes.
En l'absence de précisions sur les applications (par exemple, base de données, serveur de services réseau, traitement vidéo en temps réel) et sur l'utilisation du serveur (quelques utilisateurs expérimentés, 100 à 1000 connexions d'utilisateurs/clients), je ne peux pas formuler de recommandations générales pour résoudre le problème de l'OOM.
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 qui s'emballent et font planter 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 :
Réduisez la mémoire utilisée par votre services en limitant les caches et les similaires
Créez une zone d'échange plus grande. Cela vous coûtera vous coûtera en performance, mais peut vous faire un peu de temps.
Acheter plus de mémoire
L'augmentation de la quantité de mémoire physique peut ne pas être une réponse efficace dans toutes les circonstances.
Une façon de le vérifier est la commande "atop". En particulier ces deux lignes.
C'est notre serveur quand il était en bonne santé :
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 |Lorsqu'il fonctionnait mal (et avant que nous ajustions overcommit_memory de 50 à 90, nous observions un comportement avec vmcom dépassant largement 50G, oom-killer faisant sauter des processus toutes les quelques secondes, et la charge rebondissait radicalement à cause des processus enfants NFSd qui sautaient et étaient recréés continuellement.
Nous avons récemment reproduit des cas où des serveurs de terminaux Linux multi-utilisateurs sur-commit l'allocation de mémoire virtuelle mais où très peu des pages demandées sont effectivement consommées.
Bien qu'il ne soit pas conseillé de suivre cette voie exacte, nous avons ajusté overcommit-memory de 50 à 90 par défaut, ce qui a atténué une partie du problème. Nous avons dû déplacer tous les utilisateurs vers un autre serveur de terminal et redémarrer pour en tirer tous les avantages.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
