Les tables d'inode rétrécissent fortement au fil du temps, ce qui provoque des problèmes de synchronisation / inode

Nous avons configuré un système Linux (c'est sur Amazon AWS, un système de type CentOS bien que nous ne soyons pas exactement sûrs des personnalisations qui y sont faites) avec un stockage de 4 To en tant que volume XFS sur LVM (finalement à utiliser pour servir sur NFS4, mais c'est pas encore utilisé), et nous sommes en train d'utiliser rsync pour synchroniser les fichiers d'un de nos serveurs de production NFS vers le volume XFS (c'est-à-dire que nous rsyncons d'une source via NFS vers un volume LVM basé sur XFS monté localement). Cependant, nous avons observé qu'à un moment donné au milieu, la synchronisation a commencé à devenir de plus en plus lente (débit fortement réduit) et la charge moyenne et la consommation de mémoire ont augmenté dans une large mesure (et le processeur a une très grande proportion dans iowait). Finalement, j'ai redémarré le système XFS et le système est apparemment revenu à la normale, avec des performances rsync plus normales depuis, au moins pour les dernières 24 heures.

Nous avons vérifié les graphiques de surveillance de munin et n'avons rien remarqué d'évident, mais nous avons constaté que les métriques "Taille de la table d'inode" et "open inode" (vérifié l'implémentation du plugin munin qui pointe vers les valeurs lues dans / proc / sys / fs / inode-nr) a continué de diminuer au fil du temps. Peu de temps avant que nous observions le blocage de rsync, nous avons observé que les deux mesures étaient réduites à la valeur de quelques milliers sur plusieurs centaines de milliers (nos serveurs non-XFS restent à environ 500k la plupart du temps et ne montrent aucune tendance à la baisse monotone sur des périodes prolongées). ), et nous avons observé des journaux du noyau comme ceux-ci:

connexion ip-XX-XXX-XXX-XXX: [395850.680006] hrtimer: l'interruption a pris 20000573 ns
18 septembre 17:19:58 noyau ip-XX-XXX-XXX-XXX: [395850.680006] hrtimer: l'interruption a pris 20000573 ns
[400921.660046] INFO: tâche rsync: 7919 bloquée pendant plus de 120 secondes.
[400921.660066] "echo 0> / proc / sys / kernel / hung_task_timeout_secs" désactive ce message.
[400921.660077] rsync D ffff880002fe4240 0 7919 7918 0x00000000
[400921.660093] ffff8800683e5638 0000000000000282 ffff880000000000 0000000000014240
[400921.660131] ffff8800683e5fd8 0000000000014240 ffff8800683e5fd8 ffff88000726da40
[400921.660153] 0000000000014240 0000000000014240 ffff8800683e5fd8 0000000000014240
[400921.660176] Trace d'appel:
[400921.660202] [] Schedule_timeout + 0x1fd / 0x270
[400921.660220] []? pvclock_clocksource_read + 0x58 / 0xd0
[400921.660234] []? __raw_callee_save_xen_irq_enable + 0x11 / 0x26
[400921.660247] [] __down + 0x76 / 0xc0
[400921.660262] [] vers le bas + 0x3b / 0x50
[400921.660274] []? _raw_spin_unlock_irqrestore + 0x19 / 0x20
[400921.660314] [] xfs_buf_lock + 0x2b / 0x80 [xfs]
[400921.660338] [] _xfs_buf_find + 0x139 / 0x230 [xfs]
[400921.660360] [] xfs_buf_get + 0x5b / 0x160 [xfs]
[400921.660378] [] xfs_buf_read + 0x13 / 0xa0 [xfs]
[400921.660401] [] xfs_trans_read_buf + 0x197 / 0x2c0 [xfs]
[400921.660422] [] xfs_read_agi + 0x6f / 0x100 [xfs]
[400921.660443] [] xfs_ialloc_read_agi + 0x29 / 0x90 [xfs]
[400921.660467] [] xfs_ialloc_ag_select + 0x12b / 0x280 [xfs]
[400921.660485] [] xfs_dialloc + 0x3c7 / 0x870 [xfs]
[400921.660500] []? pvclock_clocksource_read + 0x58 / 0xd0
[400921.660509] []? __raw_callee_save_xen_restore_fl + 0x11 / 0x1e
[400921.660531] [] xfs_ialloc + 0x60 / 0x6a0 [xfs]
[400921.660550] []? xlog_grant_log_space + 0x39c / 0x3f0 [xfs]
[400921.660566] []? xen_spin_lock + 0xa5 / 0x110
[400921.660583] [] xfs_dir_ialloc + 0x7d / 0x2d0 [xfs]
[400921.660606] []? xfs_log_reserve + 0xe2 / 0xf0 [xfs]
[400921.660623] [] xfs_create + 0x3f7 / 0x600 [xfs]
[400921.660638] []? __raw_callee_save_xen_restore_fl + 0x11 / 0x1e
[400921.660655] [] xfs_vn_mknod + 0xa2 / 0x1b0 [xfs]
[400921.660678] [] xfs_vn_create + 0xb / 0x10 [xfs]
[400921.660689] [] vfs_create + 0xa7 / 0xd0
[400921.660701] [] do_last + 0x529 / 0x650
[400921.660714] []? get_empty_filp + 0x75 / 0x170
[400921.660728] [] do_filp_open + 0x213 / 0x670
[400921.660744] []? xen_spin_lock + 0xa5 / 0x110
[400921.660753] []? __raw_callee_save_xen_restore_fl + 0x11 / 0x1e
[400921.660769] []? alloc_fd + 0x102 / 0x150
[400921.660780] [] do_sys_open + 0x64 / 0x130
[400921.660792] []? __raw_callee_save_xen_irq_disable + 0x11 / 0x1e
[400921.660804] [] sys_open + 0x1b / 0x20
[400921.660815] [] system_call_fastpath + 0x16 / 0x1b

Nous avons également observé une augmentation drastique de l'opération de "recherche" comme cela a été vu sur le NFS source lorsque cela s'est produit, qui était auparavant resté stable avant que nous commencions à rencontrer ledit problème rsync.

Nous n'avons pas observé de comportement similaire sur nos volumes de production basés sur ext3 et en fait ceux-ci étaient avec des volumes encore plus grands. À part la différence du système de fichiers, les serveurs de fichiers se trouvent sur une classe de machine similaire et sont configurés de manière similaire. Comme nous avons constaté que les mesures de la table d'inode sur le serveur XFS viennent tout juste de suivre une tendance à la baisse similaire à notre observation précédente même si nous venons de la redémarrer hier, je crains que le même problème ne nous hante à nouveau bientôt, et pourrait probablement refléter quelques problèmes avec notre configuration, notre noyau ou autre.

Nous sommes sur des volumes XFS montés sur inode64 sur des machines à architecture x86_64 lorsque nous avons vécu cela. À l'heure actuelle, nous avons copié environ 1,3 To de données sur le volume XFS dont la capacité est d'environ 4 To et nous devrions avoir environ 3 To de données dans ce volume si elles sont entièrement copiées. Le volume a été recréé et a donc été monté sur inode64 dès le début lorsqu'il n'y avait pas de données à l'intérieur, donc le système de fichiers doit être propre et les inodes uniformément distribués.

Avez-vous une idée de ce qui pourrait être la cause?

(ps en fait on a recommencé à voir ça il y a quelques heures!)

L'activation de la journalisation différée XFS ( delaylogoption de montage) peut aider (voir http://en.wikipedia.org/wiki/XFS#Disadvantages ). CentOS est (in) célèbre pour utiliser un noyau corrigé, une mise à niveau du noyau peut donc être nécessaire.

polynôme et AndreasM ont dit ce qui vient naturellement à l'esprit: cela ressemble à une situation de raclée, vous n'aviez pas assez de mémoire.

Rsync recueille la liste des fichiers à transférer dans un premier passage, et 1 / traverser une grande hiérarchie sur NFS est lent ( lstat()traduit localement comme NFS distant getattrsont lents et non cachable car vous ne parcourez qu'une seule fois), 2 / ce problème dépend de la nombre d'inodes (utilisation df -i), pas sur la quantité totale de données à transférer.

Notez que l'utilisation rsync -H|--hard-linksest encore plus coûteuse, rsync doit construire une table de hachage complète de tous les inodes pour trouver des dupes.

Essayez d'utiliser rsync directement à partir du système de fichiers exporté par le serveur NFS, en contournant complètement NFS. Selon votre latence NFS, cela peut être un bon coup de pouce.

Dans certains cas extrêmes où la traversée d'une grande collection d'inodes était en fait plus coûteuse que la simple copie des données, j'ai utilisé quelque chose comme ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/destqui est une simple copie en streaming qui a une utilisation constante de la mémoire. En fonction de la configuration de votre CPU + réseau, l'ajout de compression peut accélérer toute l'opération - ou non (ajoutez -zles deux appels tar).