我们设置了一个 Linux（它在 Amazon AWS 上，一个类似 CentOS 的系统，尽管我们不确定对其进行了哪些自定义）系统，该系统具有 4TB 存储空间，作为 LVM 上的 XFS 卷（最终将用于通过 NFS4 提供服务，但尚未使用），并且我们正在使用 rsync 将文件从我们的生产 NFS 服务器同步到 XFS 卷（即，我们从 NFS 上的源 rsync 到本地安装的基于 XFS 的 LVM 卷）。但是，我们观察到在中间的某个时刻，rsync 开始变得越来越迟缓（吞吐量急剧下降），平均负载和内存消耗都大幅上升（并且 CPU 在 iowait 中占很大比例）。最后我重新启动了 XFS 系统，系统显然恢复正常，从那时起，rsync 性能更加正常，至少在过去 24 小时内是这样。
我们检查了 munin 监控图，没有发现任何明显的异常，但我们发现“Inode 表大小”和“打开 inode”指标（检查了 munin 插件实现，该实现指向从 /proc/sys/fs/inode-nr 读取的值）随着时间的推移不断减少。在我们观察到 rsync 卡住之前不久，我们观察到这两个指标的值都从几十万下降到几千（我们的非 XFS 服务器大部分时间保持在大约 500k，并且在较长时间内没有显示任何单调下降趋势），并且我们观察到来自内核的日志如下：
ip-XX-XXX-XXX-XXX 登录：[395850.680006] hrtimer：中断耗时 20000573 纳秒 9 月 18 日 17:19:58 ip-XX-XXX-XXX-XXX 内核：[395850.680006] hrtimer：中断耗时 20000573 纳秒 [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 ffff88000000000 0000000000014240 [400921.660131] ffff8800683e5fd8 0000000000014240 ffff8800683e5fd8 ffff88000726da40 [400921.660153] 0000000000014240 000000000014240 ffff8800683e5fd8 0000000000014240 [400921.660176] 呼叫追踪: [400921.660202][]schedule_timeout+0x1fd/0x270 [400921.660220][]?pvclock_clocksource_read+0x58/0xd0 __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 __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.660583][]xfs_dir_ialloc+0x7d/0x2d0[xfs] [400921.660606][]?xfs_log_reserve+0xe2/0xf0[xfs] [400921.660623][]xfs_create+0x3f7/0x600[xfs] __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][]?获取空文件+0x75/0x170 [400921.660728][]do_filp_open+0x213/0x670 复制代码 __raw_callee_save_xen_restore_fl+0x11/0x1e 复制代码 [400921.660769][]?alloc_fd+0x102/0x150 [400921.660780][]do_sys_open+0x64/0x130 __raw_callee_save_xen_irq_disable+0x11/0x1e 复制代码 [400921.660804][]系统打开+0x1b/0x20 [400921.660815][]系统调用快速路径+0x16/0x1b
当发生这种情况时，我们还观察到源 NFS 上的“查找”操作急剧增加，而在我们开始遇到上述 rsync 问题之前，该操作一直保持稳定。
我们在基于 ext3 的生产卷上没有观察到类似的行为，事实上，这些卷的卷大小甚至更大。除了文件系统差异之外，文件服务器属于类似的机器类别，设置方式也类似。我们发现，尽管我们昨天刚刚重新启动了 XFS 服务器上的 inode 表指标，但它仍然呈下降趋势，与我们之前的观察结果类似，我担心同样的问题很快会再次困扰我们，并且可能反映出我们的设置、内核或其他方面存在一些问题。
当我们遇到这种情况时，我们使用的是 x86_64 架构机器上 inode64 挂载的 XFS 卷。目前，我们已将大约 1.3TB 的数据复制到容量约为 4TB 的 XFS 卷，如果完全复制，该卷中应该有大约 3TB 的数据。该卷是新创建的，因此从一开始就是 inode64 挂载的，当时里面没有数据，因此文件系统应该是干净的，inode 分布均匀。
对于可能的原因有什么见解？
（事实上我们从几个小时前就开始再次看到这种情况了！）
答案1
启用XFS 延迟日志记录（delaylogmount 选项）可能会有帮助（参见http://en.wikipedia.org/wiki/XFS#Disadvantages)。CentOS 因使用修补的内核而出名，因此可能需要升级内核。
答案2
多项式，AndreasM 说出了自然而然想到的话：这看起来像是一个混乱的情况，你没有足够的内存。
Rsync 在第一遍中收集要传输的文件列表，并且 1/ 遍历 NFS 上的大型层次结构很慢（本地lstat()转换为远程 NFSgetattr很慢并且不可缓存，因为您只遍历一次），2/ 这个问题取决于 inode 的数量（使用df -i），而不是要传输的总数据量。
请注意，使用rsync -H|--hard-links成本更高，rsync 必须构建所有 inode 的完整哈希表才能找到重复项。
尝试直接从 NFS 服务器导出的文件系统使用 rsync，完全绕过 NFS。根据您的 NFS 延迟，这可能是一个不错的提升。
在一些极端情况下，遍历大量 inode 实际上比简单地复制数据更昂贵，我使用了一种ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/dest简单的流式复制方法，它具有恒定的内存使用量。根据您的 CPU+网络设置，添加压缩可能会加速整个操作 - 或者不会（-z在两个 tar 调用上添加）。