我们设置了一个 Linux（它在 Amazon AWS 上，一个类似 CentOS 的系统，尽管我们不确定在它上面完成的自定义）系统具有 4TB 存储作为 LVM 上的 XFS 卷（最终用于通过 NFS4 提供服务，但它是尚未使用），并且我们正在使用 rsync 将文件从我们的生产 NFS 服务器同步到 XFS 卷（即我们从 NFS 上的源 rsync 到本地安装的基于 XFS 的 LVM 卷）。但是我们观察到中间的某个时候rsync开始变得越来越迟钝（吞吐量急剧下降），并且平均负载和内存消耗都有很大程度的上升（CPU在iowait中的比例非常大）。最终我重新启动了 XFS 系统，系统显然恢复了正常，至少在过去的 24 小时内，rsync 性能更加正常。
我们检查了 munin 监控图并没有注意到任何明显的东西，但我们发现“inode table size”和“open inode”指标（检查了指向从 /proc/sys/ 读取的值的 munin 插件实现） fs/inode-nr）随着时间的推移不断减少。在我们观察到 rsync 卡住之前不久，我们观察到这两个指标都从几十万下降到了几千（我们的非 XFS 服务器大部分时间保持在大约 500k，并且在很长一段时间内没有表现出任何单调下降的趋势） )，我们从内核中观察到日志如下：
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]“echo 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 均匀分布。
关于可能是什么原因的任何见解？
（实际上我们从几个小时前开始再次看到这个！）
启用XFS 延迟日志记录（delaylog挂载选项）可能会有所帮助（请参阅http://en.wikipedia.org/wiki/XFS#Disadvantages）。CentOS 因使用修补内核而闻名，因此可能需要升级内核。