OOM Killer causé par les E/S disque lors du transfert de fichiers
Bonjour, c'est Munou.
Quelques jours se sont écoulés depuis que j'ai monté un serveur domestique à bas prix dans ma nouvelle maison. Un problème qui me préoccupait depuis un certain temps est survenu, même avec une grande quantité de mémoire.
Que s'est-il passé ?
Mon environnement actuel est un peu particulier, ou plutôt, la capacité de la mémoire est un peu étrange, 16 Go + 8 Go, mais veuillez comprendre que je l'ai construite avec des pièces de rechange.
C'est pourquoi, avec 24 Go de RAM, ce qui est peut-être courant de nos jours mais que je considère personnellement comme une configuration assez riche, je pensais qu'une OOM ne se produirait pas, mais une OOM, comme une réprimande du noyau Linux, est survenue.
Quant aux applications, il n'y a qu'Apache, php-fpm, Redis, etc., et la mémoire que chacun d'eux alloue est insignifiante...
Les transferts de fichiers me donnent du fil à retordre
C'est arrivé lorsque j'essayais de récupérer des fichiers via scp depuis mon serveur domestique encore chez mes parents, ou lorsque j'effectuais une opération de sauvegarde en masse avec aria2c vers un disque dur de 2 To pour stocker des images.
Alors, pourquoi une OOM se produit-elle avec ce seul processus d'écriture ? Eh bien, c'est parce que les fichiers sont d'abord reçus en mémoire, puis écrits dans la zone de stockage. Pour accélérer le processus, ils doivent être temporairement acceptés par la mémoire comme cache.
Il semble que l'utilisation de scp -r pour des fichiers de plusieurs centaines de Go, surtout si ces fichiers impliquent des opérations d'E/S aléatoires, consomme vraiment beaucoup de ressources.
De plus, comme cela ne correspond pas à l'utilisation de la mémoire par processus, même en vérifiant avec top, on ne peut pas le voir comme un processus unique ; c'est une affaire du côté du noyau Linux, ce qui rend le diagnostic assez difficile.
En bref, il semble que la quantité de données temporairement stockées en mémoire en attente d'E/S ne puisse pas suivre les écritures, ce qui entraîne une dégradation progressive de la mémoire.
Paramètres du noyau modifiables
En ce qui concerne ce que le noyau peut faire, il semble possible de configurer la quantité de cache, etc. J'ai essayé d'ajuster ces paramètres, mais je n'ai pas ressenti beaucoup d'effet.
2.2. Options de réglage VFS : Recherche et expérimentation Documentation produit Red Hat
Note sur le réglage des E/S d'écriture en modifiant les paramètres du cache de pages Linux - YOMON8.NET
Le phénomène est similaire à celui décrit par cette personne.
OOM Killer invoked due to slow disk I/O - #17 by Whis-key - troubleshooting - Storj Community Forum (official)
J'ai revu le mot Storj après un long moment... bien que mon quota gratuit ait été supprimé sans mon consentement...
Qui aurait cru que je me casserais la tête avec l'épuisement de la mémoire juste en écrivant sur un disque dur...
C'est aussi là que s'applique le dicton courant concernant la mémoire : "Linux est optimiste quant à la RAM, Windows est pessimiste". Bien que je comprenne l'intention d'utiliser pleinement la mémoire pour des performances plus efficaces, j'aimerais vraiment trouver un moyen de résoudre ce problème causé par l'attente d'E/S.