Rsync a déclenché le killer OOM de Linux sur un seul fichier de 50 Go

Quelques éléments...

Ma règle d'or pour l'espace d'échange a été d'avoir au moins deux fois la quantité de RAM physique. Cela permet au démon page/swap de réorganiser la mémoire efficacement.

Le Serveur_B a 32GB de ram, essayez donc de le configurer pour 64GB de swap. IMO, les 2 Go d'espace swap dont dispose votre serveur sont chemin trop faible, surtout pour un serveur.

Si vous n'avez pas de partition supplémentaire que vous pouvez transformer en partition d'échange, vous pouvez tester cela en créant un fichier et en le montant comme une partition d'échange [cela sera lent]. Voir https://www.maketecheasier.com/swap-partitions-on-linux/

Puisque le serveur_B dispose de beaucoup d'espace disque, l'option --inplace n'est pas nécessaire, et peut être indésirable car elle peut être la cause de l'utilisation de 32 Go par rsync. L'option --inplace n'est vraiment utile que si vous manquez d'espace sur le système de fichiers [ce qui n'est pas le cas] ou si vous avez des exigences particulières en matière de performances.

Je pense que rsync voudra utiliser 50 Go de RAM [la taille du fichier] avec vos options actuelles. Normalement, rsync n'a pas besoin de tant de mémoire pour faire son travail, donc une ou plusieurs de vos options peuvent être le problème. Je transfère régulièrement des fichiers de 200 Go sans problème.

Faites quelques tests en n'utilisant aucune option. Faites-le avec des fichiers plus petits, disons 10 Go - cela devrait empêcher la panique du noyau, mais vous permettre de surveiller le comportement qui cause le problème. Surveillez l'utilisation de la mémoire par rsync.

Progressivement, ajoutez des options, une par une, pour voir quelle option [ou combinaison d'options] fait que rsync commence à consommer beaucoup de RAM (par exemple, pendant le transfert, l'utilisation de la RAM par rsync augmente proportionnellement à la quantité de données transférées, etc ).

Si vous avez vraiment besoin des options qui font que rsync conserve une image de fichier in-ram, vous aurez besoin de l'espace swap supplémentaire et la taille maximale de vos fichiers sera limitée en conséquence.

Quelques éléments supplémentaires [MISE À JOUR] :

(1) La trace de la pile du noyau montre que rsync présentait un défaut de page sur une zone mmap. Il est probablement en train de mettre en mémoire le fichier. mmap n'offre aucune garantie de vidage sur le disque. jusqu'à le fichier est fermé [contrairement à la lecture/écriture] qui va immédiatement dans le cache de bloc du FS [où il sera effacé].

(2) Le crash/panique du noyau se produit lorsque la taille du transfert atteint la taille de la RAM. Il est clair que rsync s'empare de cette quantité de mémoire non cache via malloc ou mmap. Une fois encore, avec les options que vous avez spécifiées, rsync allouera 50 Go de mémoire pour transférer un fichier de 50 Go.

(3) Transférez un fichier de 24 Go. Cela va probablement fonctionner. Ensuite, démarrez le noyau avec mem=16G et refaites le test du fichier de 24 Go. Il s'éteindra à 16 Go plutôt qu'à 32 Go. Cela confirmera que rsync a vraiment besoin de mémoire.

(4) Avant de dire que l'ajout de swap est ridicule, essayez d'en ajouter [via la méthode swap-to-file]. C'est beaucoup plus facile à faire et à tester que tous les arguments académiques sur le fait que le swap n'est pas nécessaire. Même si ce n'est pas la solution, vous pouvez apprendre quelque chose de cette expérience. Je parie que le test mem=16G réussira sans panique/crash.

(5) Il y a de fortes chances que rsync es frappant l'échange, mais cela se produit trop rapidement pour être vu avec top avant que OOM ne se déclenche et ne tue rsync. Le temps que rsync atteigne 32 Go, d'autres processus ont déjà été forcés de sortir en swap, en particulier s'ils sont inactifs. Peut-être qu'une combinaison de "free" et "top" vous donnera une meilleure image.

(6) Après que rsync soit tué, il faut du temps pour vider mmap dans le FS. Pas assez vite pour l'OOM et cela commence à tuer d'autres choses [certaines sont évidemment critiques]. C'est-à-dire que le flush mmap et OOM sont en compétition. Ou, OOM a un bug. Sinon, il n'y aurait pas de crash.

(7) D'après mon expérience, une fois qu'un système "frappe le mur de la mémoire", Linux met beaucoup de temps à se rétablir complètement. Et, parfois, il ne se rétablit jamais vraiment correctement et la seule façon d'y remédier est un redémarrage. Par exemple, j'ai 12 Go de RAM. Lorsque je lance un travail qui utilise 40 Go de mémoire [j'ai 120 Go de swap pour les gros travaux] et que je l'arrête, il faut environ 10 minutes pour que le système retrouve une réactivité normale [avec la lumière du disque allumée en permanence].

(8) Exécuter rsync sans options. Cela va fonctionner. Obtenez un exemple de base pour travailler. Puis rajoutez --inplace et testez à nouveau. Puis faites --append-verify à la place. Ensuite, essayez les deux. Trouvez quelle option permet à rsync de faire l'énorme mmap. Puis décidez si vous pouvez vivre sans. Si --inplace est le coupable, c'est une évidence, puisque vous avez beaucoup d'espace disque. Si vous devez avoir l'option, vous devrez obtenir l'espace d'échange pour accommoder le malloc/mmap que rsync fera.

DEUXIÈME MISE À JOUR :

Veuillez faire les tests mem= et smaller file à partir de ce qui précède.

Les questions centrales : Pourquoi rsync est tué par OOM ? Qui/qui ronge la mémoire ?

J'ai lu [mais oublié] que le système était en 32 bits. Donc, je suis d'accord, rsync n'est peut-être pas directement responsable (via malloc/mmap - la glibc implémente de gros mallocs via des mmaps anonymes/privés), et le défaut de page mmap de rsync déclenche OOM par coïncidence. Ensuite, OOM calcule la mémoire totale consommée par rsync directement et indirectement [cache FS, tampons de socket, etc. Donc, surveiller l'utilisation totale de la mémoire peut être utile. Je soupçonne qu'elle augmente au même rythme que le transfert de fichiers. Évidemment, ça ne devrait pas.

Vous pouvez surveiller certaines choses dans /proc ou /proc/rsync_pid via un script perl ou Python dans une boucle rapide [un script bash ne sera probablement pas assez rapide pour l'événement de fin du monde] qui peut surveiller tout ce qui suit plusieurs centaines de fois/sec. Vous pouvez exécuter ceci à une priorité plus élevée que rsync afin qu'il se maintienne en RAM et en cours d'exécution, de sorte que vous puissiez surveiller les choses juste avant le crash et, si possible, pendant l'OOM afin que vous puissiez voir pourquoi l'OOM devient fou :

/proc/meminfo -- pour obtenir des informations plus précises sur l'utilisation de l'espace de pagination au "point d'impact". En fait, il peut être plus utile d'obtenir le chiffre final de la quantité totale de RAM utilisée. Bien que top fournisse cela, il n'est peut-être pas assez rapide pour montrer l'état de l'univers juste avant le "big bang" (par exemple, les 10 dernières millisecondes).

Répertoire /proc/rsync_pid/fd. La lecture des liens symboliques vous permettra d'identifier quel fd est ouvert sur le fichier cible (par exemple, readlink de /proc/rsync_pid/fd/5 --> fichier_cible). Ceci n'a probablement besoin d'être fait qu'une seule fois pour obtenir le numéro de fd [il devrait rester fixe].

Connaissant le numéro de fd, regardez dans /proc/rsync_pid/fdinfo/fd. C'est un fichier texte qui ressemble à :

pos: <file\_position>
flags: blah\_blah
mnt\_id: blah\_blah

Surveiller la valeur "pos" peut être utile car la "dernière position du fichier" peut être utile. Si vous effectuez plusieurs tests avec des tailles et des options mem= différentes, la dernière position du fichier suit-elle l'une d'entre elles [et comment] ? Le suspect habituel : position du fichier == RAM disponible

Mais, le plus simple est de commencer par "rsync local_file server:remote_file" et de vérifier que cela fonctionne. Vous pouvez obtenir des résultats similaires [mais plus rapides] en faisant "ssh server rsync file_a file_b" [vous devrez d'abord créer un fichier_a de 50 Go]. Une façon simple de créer le fichier_a est scp local_system:original_file server:file_a et cela pourrait être intéressant en soi (par exemple, est-ce que cela fonctionne lorsque rsync se plante ? Si scp fonctionne, mais que rsync échoue, cela pointe vers rsync. Si scp échoue, cela indique quelque chose d'autre comme le pilote de la carte réseau). En effectuant le ssh rsync, vous éliminez également la carte réseau de l'équation, ce qui peut être utile. Si cela bloque le système, alors quelque chose ne va vraiment pas. Si cela réussit, [comme je l'ai mentionné] commencez à ajouter les options une par une.

Je n'aime pas insister sur ce point, mais l'ajout de swap via swap-to-file peut modifier/retarder le comportement du crash et peut être utile comme outil de diagnostic. Si le fait d'ajouter, disons 16 Go, de swap retarde le plantage [mesuré par l'utilisation de la mémoire ou la position du fichier cible] de 32 à 46 Go, cela signifie quelque chose.

Il ne s'agit peut-être pas d'un processus particulier, mais d'un pilote de noyau errant qui consomme de la mémoire. Le vmalloc interne du noyau alloue de la mémoire et peut être supprimé. IIRC, il n'est pas lié par l'adressabilité dans toutes les circonstances.

Il est clair que l'OOM est en train de s'embrouiller. C'est-à-dire qu'il tue rsync, mais ne voit pas la mémoire libérée en temps voulu et part à la recherche d'autres victimes. Certaines d'entre elles sont probablement critiques pour le fonctionnement du système.

malloc/mmap mis à part, cela pourrait être causé par un cache FS non nettoyé qui prend beaucoup de temps (par exemple, avec 30 Go de données non nettoyées, en supposant un taux de disque de 300 Mo/sec, cela pourrait prendre 100 secondes pour le nettoyer). Même à ce rythme, OOM peut être trop impatient. Ou bien, l'OOM qui tue rsync ne lance pas la purge du FS assez rapidement [ou pas du tout]. Ou encore, le flush FS se produit assez rapidement, mais il y a une libération "paresseuse" des pages vers le pool libre. Il y a quelques options /proc que vous pouvez définir pour contrôler le comportement du cache FS [je ne me souviens pas de ce qu'elles sont].

Essayez de démarrer avec mem=4G ou un autre petit nombre. Cela pourrait réduire le cache du FS et raccourcir son temps de vidange pour empêcher OOM de chercher d'autres choses à tuer (par exemple, le temps de vidange est réduit de 100 sec à < 1 sec). Cela pourrait aussi démasquer un bug d'OOM qui ne peut pas gérer une RAM physique > 4GB sur un système 32 bit ou autre.

Aussi, un point important : Exécuter en tant que non-root. Les utilisateurs root ne sont pas censés consommer des ressources, ils bénéficient donc de limites plus indulgentes (par exemple, 99% de la mémoire contre 95% pour les utilisateurs non-root). Cela peut expliquer pourquoi OOM est dans un tel état. De plus, cela donne à OOM et al. plus de marge de manœuvre pour faire son travail de récupération de la mémoire.

Clamd ? Il semble que vous utilisiez ClamAV et que l'analyse à l'accès soit activée, le moteur antivirus tentant de rechercher les virus dans les fichiers ouverts, en chargeant en mémoire, l'intégralité du contenu de tout fichier ouvert par un autre processus .

En fonction de votre position de sécurité et de la nécessité de ce transfert, vous devriez envisager de désactiver l'analyse à l'accès de ClamAV pendant que vous effectuez le transfert.