我们设置了一个Linux（在Amazon AWS上，它是一个类似CentOS的系统，尽管我们不确定是否对其进行了自定义），将系统具有4TB存储作为LVM上的XFS卷（最终用于通过NFS4进行服务），但是尚未使用），并且我们正在使用rsync将文件从我们生产的NFS服务器同步到XFS卷（即，从NFS上的源rsync到本地安装的基于XFS的LVM卷）。但是，我们观察到，在中间的某个时刻，rsync开始变得越来越迟钝（吞吐量急剧下降），并且平均负载和内存消耗都大大增加了（并且在iowait中CPU所占的比例非常大）。最终，我至少在过去的24小时内重新启动了XFS系统，并且该系统显然恢复了正常运行，并且rsync性能更加正常。
我们检查了munin监视图，没有发现任何明显的问题，但是我们发现“ Inode表大小”和“打开inode”度量标准（检查了munin插件实现，该实现指向从/ proc / sys /中读取的值fs / inode-nr）随时间持续下降。在我们观察到rsync陷入僵局之前不久，我们观察到两个指标都从数十万降到了几千（我们的非XFS服务器大部分时间都保持在大约50万，并且在长期内没有任何单调下降的趋势） ），我们观察到了来自内核的日志，如下所示：
ip-XX-XXX-XXX-XXX登录：[395850.680006] hrtimer：中断花费了20000573 ns 9月18日17:19:58 ip-XX-XXX-XXX-XXX内核：[395850.680006] hrtimer：中断花费了20000573 ns [400921.660046]信息：任务rsync：7919被阻止超过120秒。 [400921.660066]“回显0> / proc / sys / kernel / hung_task_timeout_secs”禁用此消息。 [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]呼叫跟踪： [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] []下+ 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
我们还观察到发生这种情况时，在源NFS上看到的“查找”操作急剧增加，在我们开始遇到上述rsync问题之前，它一直保持稳定。
我们在基于ext3的生产量上并没有观察到类似的行为，实际上，它们的生产量甚至更大。除了文件系统差异之外，文件服务器在相似的计算机类上，并且以相似的方式进行设置。尽管我们发现昨天XFS服务器上的inode表指标仍处于下降趋势，与我们先前的观察相似，尽管我们昨天刚刚重新启动它，但我担心同一问题很快就会再次困扰我们，并且可能反映出我们的设置，内核或其他任何问题。
遇到这种情况时，我们在x86_64体系结构机器上的inode64挂载XFS卷上。现在，我们已经将大约1.3TB的数据复制到容量约为4TB的XFS卷中，如果完全复制，则该卷中应该有大约3TB的数据。该卷是重新创建的，因此从一开始就在内部没有数据的情况下将其安装在inode64上，因此文件系统应该是干净的，并且inode均匀分布。
关于可能是什么原因的任何见解？
（ps实际上，自几个小时前我们又开始看到这种情况！）