Configuration de l'Out-Of-Memory Killer sous Linux pour PostgreSQL

Lorsque le serveur de base de données Linux se ferme de manière inattendue, il est important de comprendre la cause. Il peut y avoir plusieurs raisons. Par exemple, SIGSEGV — une défaillance due à un bug dans le serveur backend. Mais c'est rare. Le plus souvent, c'est simplement l'espace disque ou la mémoire qui s'épuise. Si l'espace disque est plein, la seule solution est de libérer de l'espace et de redémarrer la base de données.

Out-Of-Memory Killer

Lorsque la mémoire de de serveurs ou d'un processus est épuisée, Linux propose deux solutions : faire tomber tout le système ou terminer le processus (application) qui consomme la mémoire. Il est préférable de terminer le processus et de sauver l'OS d'un arrêt brutal. En résumé, l'Out-Of-Memory Killer est un processus qui termine une application pour préserver le noyau d'un échec. Il sacrifie une application pour maintenir le fonctionnement de l'OS. Discutons d'abord du fonctionnement de l'OOM et de son contrôle, puis voyons comment l'OOM Killer décide quelle application terminer.

L'une des principales tâches de Linux est d'allouer de la mémoire aux processus lorsqu'ils en font la demande. En général, un processus ou une application demande de la mémoire à l'OS, mais l'utilise rarement entièrement. Si l'OS attribue de la mémoire à tous ceux qui en font la demande sans intention de l'utiliser, la mémoire sera rapidement épuisée, et le système échouera. Pour éviter cela, l'OS réserve de la mémoire pour le processus sans réellement la distribuer. La mémoire n'est allouée que lorsque le processus a besoin de l'utiliser. Il arrive que l'OS n'ait pas de mémoire libre, mais qu'il réserve de la mémoire pour un processus, et lorsque le processus en a besoin, l'OS l'alloue s'il le peut. Le problème est que parfois l'OS réserve de la mémoire, mais à ce moment-là, il n'y a pas de mémoire libre, entraînant un échec du système. L'OOM joue un rôle crucial dans ce scénario et termine les processus pour protéger le noyau de la panique. Lorsque le processus PostgreSQL est terminé de force, un message apparaît dans le journal :

Out of Memory: Killed process 12345 (postgres).

Si le système manque de mémoire et qu'il est impossible de la libérer, la fonction est appelée out_of_memory. À ce stade, il ne reste qu'une chose à faire : terminer un ou plusieurs processus. L'OOM-killer doit-il terminer le processus immédiatement ou peut-il attendre ? Évidemment, lorsque l'out_of_memory est appelé, cela est lié à l'attente d'une opération d'entrée-sortie ou à l'écriture d'une page sur le disque. Par conséquent, l'OOM-killer doit d'abord effectuer des vérifications et, sur cette base, décider quel processus doit être terminé. Si tous les contrôles ci-dessous sont positifs, OOM terminera le processus.

Sélection du processus

Lorsque la mémoire est épuisée, la fonction est appelée out_of_memory(). Elle contient une fonction select_bad_process(), qui reçoit une évaluation de la fonction badness(). Le processus le 'pire' sera sélectionné. La fonction badness() choisit un processus selon certaines règles.

1. Le noyau a besoin d'un minimum de mémoire pour lui-même.
2. Il faut libérer beaucoup de mémoire.
3. Il n'est pas nécessaire de terminer les processus qui utilisent peu de mémoire.
4. Il faut terminer un minimum de processus.
5. Des algorithmes complexes augmentent les chances de terminaison pour les processus que l'utilisateur souhaite lui-même terminer.

Après avoir effectué toutes ces vérifications, OOM examine l'évaluation (oom_score). OOM attribue oom_score à chaque processus, puis multiplie cette valeur par la quantité de mémoire. Les processus avec des valeurs élevées ont plus de chances de devenir des victimes de l'OOM Killer. Les processus associés à un utilisateur privilégié ont une évaluation plus basse et moins de chances d'être terminés de force.

postgres=# SELECT pg_backend_pid();
pg_backend_pid 
----------------
    3813
(1 row)

L'identifiant du processus Postgres est 3813, donc dans un autre shell, vous pouvez obtenir l'évaluation en utilisant ce paramètre du noyau oom_score:

vagrant@vagrant:~$ sudo cat /proc/3813/oom_score
2

Si vous ne souhaitez absolument pas que l'OOM-Killer termine le processus, il existe un autre paramètre du noyau : oom_score_adj. Ajoutez une grande valeur négative pour réduire les chances de terminaison de votre processus important.

sudo echo -100 > /proc/3813/oom_score_adj

Pour définir une valeur oom_score_adj, définissez OOMScoreAdjust dans le bloc du service :

[Service]
OOMScoreAdjust=-1000

Ou utilisez oomprotect dans la commande rcctl.

rcctl set servicename oomprotect -1000

Terminaison forcée du processus

Lorsque un ou plusieurs processus ont déjà été sélectionnés, l'OOM-Killer appelle la fonction oom_kill_task(). Cette fonction envoie un signal de terminaison au processus. En cas de manque de mémoire, oom_kill() appelle cette fonction pour envoyer le signal SIGKILL au processus. Un message est enregistré dans le journal du noyau.

Mémoire insuffisante : processus tué [pid] [nom].

Comment contrôler l'OOM-Killer

Sous Linux, il est possible d'activer et de désactiver l'OOM-Killer (bien que cela ne soit pas recommandé). Pour l'activer ou le désactiver, utilisez le paramètre vm.oom-kill. Pour activer l'OOM-Killer en mode d'exécution, exécutez la commande sysctl.

sudo -s sysctl -w vm.oom-kill = 1

Pour désactiver l'OOM-Killer, spécifiez la valeur 0 dans cette même commande :

sudo -s sysctl -w vm.oom-kill = 0

Le résultat de cette commande ne sera pas permanent, il durera seulement jusqu'au prochain redémarrage. Si vous avez besoin de plus de permanence, ajoutez cette ligne au fichier /etc/sysctl.conf:

echo vm.oom-kill = 1 >> /etc/sysctl.conf

Une autre façon d'activer et de désactiver est d'écrire la variable panic_on_oom. La valeur peut toujours être vérifiée dans /proc.

$ cat /proc/sys/vm/panic_on_oom
0

Si vous définissez la valeur 0, lorsqu'il n'y a plus de mémoire, il n'y aura pas de panique du noyau.

$ echo 0 > /proc/sys/vm/panic_on_oom

Si vous définissez la valeur 1, lorsqu'il n'y a plus de mémoire, une panique du noyau se produira.

echo 1 > /proc/sys/vm/panic_on_oom

L'OOM-Killer peut être activé et désactivé. Nous avons déjà mentionné que Linux peut réserver plus de mémoire pour les processus qu'il n'en dispose, sans l'allouer réellement, et ce comportement est contrôlé par un paramètre du noyau Linux. Cela est géré par la variable vm.overcommit_memory.

Pour cela, vous pouvez spécifier les valeurs suivantes :

0: le noyau décide lui-même s'il faut réserver trop de mémoire. C'est la valeur par défaut dans la plupart des versions de Linux.
1: le noyau réservera toujours de la mémoire supplémentaire. Cela est risqué, car la mémoire peut s'épuiser, car il est probable qu'un jour les processus en demanderont beaucoup.
2: le noyau ne réserve pas plus de mémoire que ce qui est spécifié dans le paramètre overcommit_ratio.

Dans ce paramètre, vous spécifiez le pourcentage de mémoire pour lequel un sur-réservement est acceptable. S'il n'y a pas de place pour cela, la mémoire ne sera pas allouée et la demande sera refusée. C'est l'option la plus sécurisée, recommandée pour PostgreSQL. Un autre élément qui influence l'OOM-Killer est la possibilité de swap, qui est contrôlée par la variable cat /proc/sys/vm/swappiness. Ces valeurs indiquent au noyau comment gérer la pagination des pages. Plus la valeur est élevée, moins il est probable que l'OOM termine le processus, mais en raison des opérations d'E/S, cela nuit à la base de données. Inversement, plus la valeur est basse, plus il y a de chances que l'OOM-Killer intervienne, mais la performance de la base de données est également meilleure. La valeur par défaut est de 60, mais si l'intégralité de la base de données tient en mémoire, il est préférable de définir la valeur à 1.

Résultats

Ne laissez pas le mot « tueur » dans OOM-Killer vous effrayer. Dans ce cas, le tueur sera le sauveur de votre système. Il « tue » les processus les plus indésirables et préserve le système d'un arrêt brutal. Pour éviter d'avoir à utiliser l'OOM-Killer pour terminer PostgreSQL, définissez vm.overcommit_memory la valeur à 2. Cela ne garantit pas que l'OOM-Killer n'aura pas à intervenir, mais cela réduit la probabilité de termination forcée du processus PostgreSQL.

Source : habr.com