Une petite zone de swap avec un swappiness faible réduit les destructions OOM du service principal sur des serveurs à mémoire tendue

Hypothèse

La documentation du noyau désigne le cache de pages et la mémoire anonyme comme les principaux types de pages récupérables, les pages anonymes n'étant récupérables qu'en les faisant passer sur le swap, et elle décrit l'OOM killer comme ce que le noyau invoque lorsqu'il ne peut pas récupérer assez de mémoire pour continuer ; vm.swappiness fixe le coût relatif que le noyau attribue au swap par rapport à l'abandon des pages adossées à des fichiers. L'hypothèse est que sur des hôtes exécutant un service principal plus des tâches auxiliaires (sauvegardes, expédition de journaux, mises à jour de paquets) dont la demande totale approche la RAM, une zone de swap représentant une fraction de la RAM, associée à une valeur de swappiness faible, donne au noyau un endroit où placer les pages anonymes rarement sollicitées, de sorte que les pics transitoires se terminent par un peu de swap plutôt que par une destruction OOM du processus le plus volumineux, qui est généralement le service principal. Sans swap, la mémoire anonyme n'a nulle part où aller et n'est pas récupérable, si bien que tout pic dépassant le cache de pages récupérable doit se terminer par une destruction.

Prédiction

Sur des périodes comparables, les hôtes dotés de la configuration de swap enregistreront moins d'événements « Out of memory: Killed process » pour le service principal que les hôtes sans swap, tout en présentant des compteurs de swap-in et swap-out non nuls autour des moments de pic. Les percentiles de latence du service principal seront moins bons pendant ces minutes sur les hôtes avec swap. Les hôtes dont la demande dépasse la RAM de façon persistante, et non transitoire, ne montreront aucune réduction des destructions et présenteront un swap soutenu et important.

Test proposé

1. Prendre des paires d'hôtes de taille identique exécutant le même service et la même charge de travail ; configurer l'un de chaque paire avec un swap dimensionné à une fraction définie de la RAM et un vm.swappiness à une valeur faible, l'autre sans swap.
2. Enregistrer les événements de destruction OOM issus du journal du noyau, les compteurs de swap de /proc/vmstat, MemAvailable, et la latence du service pendant plusieurs semaines.
3. Comparer les nombres de destructions par hôte, classer chaque destruction selon que le pic était transitoire ou non, et comparer la latence pendant l'activité de swap.
4. Répéter avec une limite de cgroup (MemoryMax= plus MemorySwapMax=) sur les tâches auxiliaires pour voir si le fait de limiter ces tâches obtient la même réduction sans swap.

Statut

Aucun résultat n'est avancé. La prédiction pourrait échouer lorsque les pics de la charge de travail dépassent toute zone de swap raisonnable, lorsque le stockage est assez lent pour que le swap provoque des échecs de vérification de santé, ou lorsque des limites de cgroup sur les tâches auxiliaires empêchent déjà la contention ; l'hypothèse ne concerne que la fréquence des destructions, pas la performance globale.