我们用4TB存储作为LVM上的XFS卷来设置一个Linux（它在Amazon AWS上，一个类似于CentOS的系统，尽pipe我们并不完全确定它已经完成了自定义），最终用于通过NFS4服务，目前还没有使用），而且我们正在使用rsync将文件从我们的NFS服务器上的文件同步到XFS卷（即我们的rsync从NFS源到本地安装的基于XFS的LVM卷）。 然而，我们观察到rsync在某一时刻开始变得越来越迟缓（吞吐量急剧下降），并且负载平均和内存消耗都在很大程度上上升（而且CPU在iowait中的比例非常高）。 最后，我重新启动了XFS系统，系统显然恢复了正常，至less在过去的24小时里，更正常的rsync性能。
我们检查了munin监视图并没有注意到任何明显的东西，但是我们发现“inode表大小”和“open inode”度量（检查了指向从/ proc / sys / fs / inode-nr）随时间不断下降。 不久之前，我们观察到rsync卡住了，我们观察到这两个度量值从几十万降低到几千（我们的非XFS服务器大多数时间停留在大约500k，并且在长时间内没有显示任何单调下降的趋势），我们从内核中观察到这样的日志：
ip-XX-XXX-XXX-XXXlogin：[395850.680006] hrtimer：中断了20000573 ns Sep 18 17:19:58 ip-XX-XXX-XXX-XXX kernel：[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 + 0×11/0×26 [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 + 0×11 / 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 + 0×11 / 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 + 0×11 / 0X1E [400921.660769] []？ alloc_fd + 0x102 /量0x150 [400921.660780] [] do_sys_open + 0x64 / 0x130 [400921.660792] []？ __raw_callee_save_xen_irq_disable + 0×11 / 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的数据。 卷是重新创build的，所以从一开始就没有数据，所以文件系统应该是干净的，inode均匀分布。
任何有关可能是什么原因的见解？
（ps实际上我们几个小时前就开始看到这个了！）
启用XFS延迟日志logging （ delaylog挂载选项）可能有帮助（请参阅http://en.wikipedia.org/wiki/XFS#Disadvantages ）。 CentOS因使用补丁内核而出名，所以可能需要内核升级。
多项式和安德烈亚斯M说，自然会想到：它看起来像一个颠簸的情况，你没有足够的记忆。
Rsync收集文件列表以便在第一遍中传输，而且在NFS上遍历大的层次结构是很慢的（本地lstat()翻译为远程NFS getattr很慢并且由于只遍历一次而不可以）2 / this问题取决于inode的数量（使用df -i ），而不是要传输的数据总量。
请注意，使用rsync -H|--hard-links成本更高，rsync必须构build一个包含所有inode的完整哈希表来查找重复。
尝试从NFS服务器导出的文件系统中使用rsync，完全绕过NFS。 根据您的NFS延迟，这可能是一个很好的提升。
在一些边缘情况下，遍历大量inode实际上更加昂贵，只是复制数据，我使用了ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/dest ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/dest ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/dest这是一个简单的stream式拷贝，具有不变的内存使用。 根据您的CPU +networking设置，添加压缩可能会加速整个操作 – 或者不要（在两个tar调用中都添加-z ）。