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!)