Chaque distribution Linux® contient le processus Out-of-Memory (OOM) Killer, mais qu'est-ce que c'est ? En termes simples, il s'agit du processus d'auto-préservation du serveur. Pour bien comprendre ce que cela signifie, réfléchissez à la façon dont Linux alloue la mémoire.
Allocation de mémoire Linux
Le noyau Linux alloue de la mémoire à la demande pour toutes les applications en cours d'exécution sur le serveur. Étant donné que cela se produit généralement en amont, les applications n'utilisent généralement pas toute la mémoire attribuée. Cela permet au noyau de surcharger la mémoire, ce qui rend la mémoire plus efficace. Cet engagement excessif permet au noyau d'engager plus de mémoire qu'il n'en a réellement de disponible physiquement. En règle générale, ce n'est pas un problème. Le problème se produit lorsque trop d'applications commencent à utiliser la mémoire qui leur est allouée en même temps. Le serveur court le risque de planter car il manque de mémoire. Pour empêcher le serveur d'atteindre cet état critique, le noyau contient également un processus appelé OOM Killer . Le noyau utilise ce processus pour commencer à tuer les processus non essentiels afin que le serveur puisse rester opérationnel.
Bien que vous puissiez penser que cela ne devrait pas être un problème, les processus OOM Killerkills que le serveur a jugés non essentiels, pas l'utilisateur. Par exemple, les deux applications que OOM Killer tue généralement en premier sont Apache® et MySQL® car elles utilisent une grande quantité de mémoire. Quiconque possède un site Web sait immédiatement que c'est un gros problème. Si l'OOM Killer tue l'un ou l'autre, un site Web plante souvent immédiatement.
Pourquoi un processus spécifique a-t-il été tué ?
Lorsque vous essayez de découvrir pourquoi le tueur OOM a tué une application ou un processus, vous pouvez rechercher quelques éléments qui peuvent aider à révéler comment et pourquoi le processus a été tué. Le premier endroit à regarder est dans le syslog en exécutant la commande suivante :
$ grep -i kill /var/log/messages*
host kernel: Out of Memory: Killed process 5123 (exampleprocess)
Vous devriez obtenir une sortie similaire à l'exemple précédent. La capitale K danstué vous indique que le processus a été tué avec un -9 signal, et c'est généralement un bon indicateur que le tueur d'OOM est à blâmer.
De plus, vous pouvez exécuter la commande suivante pour vérifier les statistiques de mémoire haute et basse du serveur :
$ free -lh
Le -l le commutateur affiche des statistiques de mémoire haute et basse, et le -h Le commutateur place la sortie en gigaoctets pour une lisibilité humaine plus facile. Vous pouvez changer ceci en -m basculez si vous préférez la sortie en mégaoctets. Un avantage supplémentaire de cette commande est qu'elle vous donne également les informations d'utilisation de la mémoire d'échange. Une mise en garde est que le free La commande ne fournit qu'un instantané de ce moment, vous devez donc la vérifier plusieurs fois pour avoir une idée de ce qui se passe.
Heureusement, le vmstat La commande obtient une sortie mémoire sur une période de temps, et elle a même une option pour un tableau facile à lire :
$ vmstat -SM 10 20
La commande précédente génère vingt fois des informations sur la mémoire système à des intervalles de 10 secondes. C'est ce que signifient 10 et 20 dans l'exemple précédent. Vous pouvez modifier ces deux nombres pour adapter une fréquence et un total qui correspondent mieux à vos besoins. Le -S switch affiche la sortie dans un format de table, et le -M commutateur affiche la sortie en mégaoctets. Utilisez cette commande pour montrer ce qui se passe activement tout au long des paramètres de temps que vous spécifiez.
Un autre bon outil à utiliser est, bien sûr, le top commande. top ordonne la sortie par la variable CPU par défaut, mais si vous cliquez sur shift + M après avoir exécuté le top commande, vous pouvez obtenir des mises à jour en temps réel pour l'utilisation de la mémoire au lieu de l'utilisation du processeur.
Configurer le tueur OOM
Étant donné que OOM Killer est un processus, vous pouvez le configurer pour qu'il réponde mieux à vos besoins. En fait, OOM Killer dispose déjà de plusieurs options de configuration intégrées qui permettent aux administrateurs de serveur et aux développeurs de choisir comment ils souhaitent que le processus OOM Killer se comporte face à un situation de mémoire-devient-dangereusement-faible. N'oubliez pas que ces options peuvent varier en fonction de facteurs tels que l'environnement et les applications en cours d'exécution.
Comme pour tout ce qui implique des modifications de configurations, il est toujours préférable de tester les modifications proposées dans un environnement de développement ou de préproduction avant d'apporter ces modifications dans un environnement de production en direct. De cette façon, vous savez comment le système réagit à ces changements. Enfin, même si vous êtes sûr de votre plan, faites toujours une sauvegarde avant d'apporter des modifications. Pour les options de configuration suivantes, vous devez être le root utilisateur.
Option 1 :Redémarrer
La première option consiste à modifier le sysctl configuration(/etc/sysctl.conf ), ce qui permet à vos modifications de persister entre les redémarrages :
sysctl vm.panic_on_oom=1
sysctl kernel.panic=X
echo “vm.panic_on_oom=1” >> /etc/sysctl.conf
echo “kernel.panic=X” >> /etc/sysctl.conf
Le X dans la commande précédente est le nombre de secondes pendant lesquelles le système doit attendre avant de redémarrer.
Dans la plupart des situations, il n'est pas possible de redémarrer chaque fois que le système manque de mémoire. Bien que cette approche puisse être nécessaire dans certaines situations, la plupart ne nécessitent pas ou ne justifient pas un redémarrage complet du système pour résoudre le problème.
Option 2 :Protéger ou sacrifier des processus
Cette option particulière nécessite une approche plus affinée. Vous pouvez soit (a) protéger certains processus en les rendant moins susceptibles d'être tués par OOM Killer, soit (b) définir certains processus comme étant plus susceptibles d'être tués. Vous pouvez accomplir cela avec les commandes suivantes :
echo -15 > /proc/(PID)/oom_adj (less likely)
echo 10 > /proc/(PID)/oom_adj (more likely)
Remplacez le (PID) espace réservé dans l'exemple de commande avec l'ID (ou PID) du processus particulier qui vous intéresse. Pour protéger ou sacrifier un processus, vous devez trouver le processus parent (l'original). Utilisez la commande suivante pour localiser le PPID (ou ID de processus parent), où vous remplacez le processus par votre processus (tel qu'Apache, MySQL, etc.) :
pstree -p | grep "process" | head -1
Vous pouvez voir que cette option est un peu meilleure que l'option nucléaire d'un redémarrage complet du système. Cependant, que se passe-t-il si vous avez un processus qui est crucial et qui ne peut pas être tué ?
Option 3 :Exempter un processus
Cette option est accompagnée d'une mise en garde. Les processus d'exemption peuvent, dans certaines circonstances, entraîner des changements de comportement involontaires, qui dépendent largement des configurations du système et des ressources. Si le noyau ne peut pas tuer un processus utilisant une grande quantité de mémoire, il commencera à tuer les autres processus disponibles. Cela peut inclure des processus qui peuvent également être des processus importants du système d'exploitation. En conséquence, le système pourrait potentiellement tomber complètement en panne. Qu'il suffise de dire, utilisez cette option avec une extrême prudence.
Parce que la plage valide pour les ajustements OOM Killer est comprise entre -16 et +15 , un réglage de -17 exempte entièrement un processus parce qu'il n'entre pas dans le cadre des nombres entiers acceptables pour l'échelle d'ajustement de l'OOM Killer. La règle générale est la suivante :plus la valeur numérique est élevée, plus un processus est susceptible d'être tué. Par conséquent, la commande pour exempter complètement un processus est :
echo -17 > /proc/(PID)/oom_adj
Option 4 :L'option risquée
Avertissement :Rackspace ne le recommande pas pour les environnements de production.
Si les redémarrages et les processus de protection, de sacrifice ou d'exemption ne suffisent pas, il existe la dernière option risquée :désactiver complètement OOM Killer option.
Cette option peut entraîner l'un des résultats suivants :
- une grave panique du noyau
- un système raccroche
- un plantage complet du système
Pourquoi? Il empêche le serveur d'éviter de manquer de ressources. Si vous désactivez complètement OOM Killer, rien ne protège le serveur d'un manque de mémoire. Faites preuve d'une extrême retenue et de prudence lorsque vous envisagez cette option.
Pour exercer cette option, exécutez la commande suivante :
sysctl vm.overcommit_memory=2
echo “vm.overcommit_memory=2” >> /etc/sysctl.conf
Maintenant que vous connaissez OOM Killer, vous savez comment adapter le processus à votre environnement et aux besoins de votre système. En règle générale, faites preuve de prudence lorsque vous éditez des processus du noyau. Le OOM Killer ne fait pas exception à cette règle.