Qu'est-ce que vm.min_free_kbytes et comment le régler ?

Comment fonctionne vm.min_free_kbytes

Des allocations de mémoire peuvent être nécessaires par le système afin d'assurer le bon fonctionnement du système lui-même. Si le noyau permet à toute la mémoire d'être allouée, il peut avoir des difficultés à avoir besoin de mémoire pour des opérations régulières afin que le système d'exploitation fonctionne correctement. C'est pourquoi le noyau fournit le paramètre ajustable vm.min_free_kbytes. Le réglage forcera le gestionnaire de mémoire du noyau à conserver au moins X quantité de mémoire libre. Voici la définition officielle du documentation du noyau Linux : Ceci est utilisé pour forcer la machine virtuelle Linux à garder un nombre minimum de kilo-octets libres. La VM utilise ce nombre pour calculer une valeur de filigrane[WMARK_MIN] pour chaque zone lowmem du système. Chaque zone lowmem obtient un nombre de pages gratuites réservées en fonction de sa taille. Une quantité minimale de mémoire est nécessaire pour satisfaire les allocations PF_MEMALLOC ; si vous le définissez sur une valeur inférieure à 1024 Ko, votre système deviendra subtilement cassé et sujet aux blocages sous des charges élevées. Un réglage trop élevé OOM votre machine instantanément.

Validation des travaux de vm.min_free_kbytes

Afin de tester que le paramètre de min_free_kbytes fonctionne comme prévu, j'ai créé une instance virtuelle Linux avec seulement 3,75 Go de RAM. Utilisez la commande gratuite ci-dessous pour analyser le système :

En regardant l'utilitaire de mémoire libre ci-dessus, utilisez l'indicateur -m pour que les valeurs soient imprimées en Mo. La mémoire totale est de 3,5 à 3,75 Go de mémoire. 121 Mo de mémoire sont utilisés, 3,3 Go de mémoire sont libres, 251 Mo sont utilisés par le cache tampon. Et 3,3 Go de mémoire sont disponibles.

Nous allons maintenant modifier la valeur de vm.min_free_kbytes et voir quel est l'impact sur la mémoire système. Nous ferons écho à la nouvelle valeur dans le système de fichiers virtuel proc pour modifier la valeur du paramètre du noyau comme ci-dessous :

Vous pouvez voir que le paramètre a été modifié à 1,5 Go environ et a pris effet. Utilisons maintenant le libre commande à nouveau pour voir tous les changements reconnus par le système.

La mémoire libre et le cache tampon sont inchangés par la commande, mais la quantité de mémoire affichée comme disponible a été réduit de 3327 à 1222 Mo. Ce qui est une réduction approximative de la modification du paramètre à 1,5 Go min de mémoire libre.

Créons maintenant un fichier de données de 2 Go, puis voyons ce que la lecture de ce fichier dans le cache tampon fait aux valeurs. Voici comment créer un fichier de données de 2 Go en 2 lignes de script bash ci-dessous. Le script générera un fichier aléatoire de 35 Mo à l'aide de la commande dd, puis le copiera 70 fois dans un nouveau fichier de données sortir:

Lisons le fichier et ignorons le contenu en lisant et en redirigeant le fichier vers /dev/null comme ci-dessous :

Ok, qu'est-il arrivé à notre mémoire système avec cet ensemble de manœuvres, vérifions-le maintenant :

Analyser les résultats ci-dessus. Nous avons encore 1,8 Go de mémoire libre, donc le noyau a protégé une grande partie de la mémoire comme réservée à cause de notre paramètre min_free_kbytes. Le cache tampon a utilisé 1691 Mo, ce qui est inférieur à la taille totale de notre fichier de données qui est de 2,3 Go. Apparemment l'ensemble fichier de données n'a pas pu être stocké dans le cache en raison du manque de mémoire disponible à utiliser pour le cache tampon. Nous pouvons valider que l'intégralité du fichier n'est pas stocké dans le cache mais chronométrer les tentatives répétées de lecture du fichier. S'il était mis en cache, il faudrait une fraction de seconde pour lire le fichier. Essayons.

La lecture du fichier a pris près de 20 secondes, ce qui implique qu'il n'est presque certainement pas tout mis en cache.

En guise de validation finale, réduisons le vm.min_free_kbytes pour permettre au cache de page d'avoir plus d'espace pour fonctionner et nous pouvons nous attendre à voir le cache fonctionner et la lecture du fichier beaucoup plus rapide.

Avec la mémoire supplémentaire disponible pour la mise en cache, le temps de lecture du fichier est passé de 20 secondes avant à 0,364 seconde avec le tout dans le cache.

Je suis curieux de faire une autre expérience. Que se passe-t-il avec les appels malloc pour allouer de la mémoire à partir d'un programme C face à ce paramètre vm.min_free_kbytes vraiment élevé. Va-t-il échouer le malloc? Le système va-t-il mourir ? Réinitialisez d'abord le paramètre vm.min_free_kbytes à la valeur très élevée pour reprendre nos expériences :

Regardons à nouveau notre mémoire libre :

Théoriquement, nous avons 1,9 Go d'espace libre et 515 Mo disponibles. Utilisons un programme de test de stress appelé stress-ng afin d'utiliser de la mémoire et de voir où nous échouons. Nous allons utiliser le testeur vm et essayer d'allouer 1 Go de mémoire. Comme nous n'avons réservé que 1,5 Go sur un système de 3,75 Go, je suppose que cela devrait fonctionner.

Essayons à nouveau avec plus de travailleurs, nous pouvons essayer 1, 2, 3, 4 travailleurs et à un moment donné, cela devrait échouer. Dans mon test, il a réussi avec 1 et 2 travailleurs mais a échoué avec 3 travailleurs.

Réinitialisons le vm.min_free_kbytes à un nombre faible et voyons si cela nous aide à exécuter 3 stresseurs de mémoire avec 1 Go chacun sur un système de 3,75 Go.

Cette fois, il a fonctionné avec succès sans erreur, je l'ai essayé deux fois sans problème. Je peux donc conclure qu'il existe une différence de comportement d'avoir plus de mémoire disponible pour malloc, lorsque la valeur vm.min_free_kbytes est définie sur une valeur inférieure.

Paramètre par défaut pour vm.min_free_kbytes

La valeur par défaut du paramètre sur mon système est 67584, ce qui représente environ 1,8% de la RAM sur le système ou 64 Mo. Pour des raisons de sécurité sur un système fortement sollicité, j'aurais tendance à l'augmenter un peu peut-être à 128 Mo pour permettre plus de mémoire libre réservée, mais pour une utilisation moyenne, la valeur par défaut semble assez raisonnable. La documentation officielle met en garde contre une valeur trop élevée. Le définir sur 5 ou 10 % de la RAM système n'est probablement pas l'utilisation prévue du paramètre et est trop élevé.

Configuration de vm.min_free_kbytes pour survivre aux redémarrages

Afin de garantir que le paramètre puisse survivre aux redémarrages et ne soit pas restauré aux valeurs par défaut lors du redémarrage, assurez-vous de rendre le paramètre sysctl persistant en mettant la nouvelle valeur souhaitée dans le fichier /etc/sysctl.conf.

Conclusion

Nous avons vu que le paramètre de noyau Linux vm.min_free_kbytes peut être modifié et peut réserver de la mémoire sur le système afin de garantir que le système est plus stable, en particulier lors d'une utilisation intensive et d'allocations de mémoire importantes. Les paramètres par défaut peuvent être un peu trop bas, en particulier sur les systèmes à mémoire élevée et doivent être considérés comme étant augmentés avec précaution. Nous avons vu que la mémoire réservée par ce paramètre ajustable empêche le cache du système d'exploitation d'utiliser toute la mémoire et empêche également certaines opérations malloc d'utiliser également toute la mémoire.