我们设置了一个 Linux(它在Amazon AWS上,一个类似CentOS的系统,虽然我们并不完全确定在其上进行的自定义)系统将4TB存储作为LVM上的XFS卷(最终用于通过NFS4服务,但它是尚未使用),我们正在使用rsync将文件从我们的生产NFS服务器同步到XFS卷(即我们从基于NFS的源rsync到本地安装的基于XFS的LVM卷).然而,我们观察到在中间的某些时候,rsync开始变得越来越迟缓(吞吐量急剧下降),并且负载平均值和内存消耗都在很大程度上上升(并且cpu在iowait中具有非常大的比例).最终我重新启动了XFS系统,系统显然已恢复正常,至少在过去的24小时内具有更正常的rsync性能.

我们检查了munin监控图并没有发现任何明显的情况,但是我们发现了“Inode表大小”和“open inode”指标(检查了munin插件实现,它指向从/ proc / sys /读取的值) fs / inode-nr)随着时间的推移不断减少.在我们观察到rsync卡住之前不久,我们观察到两个指标都降低到数十万的数千(我们的非XFS服务器大部分时间保持在大约500k,并且在长时间内没有显示任何单调下降趋势),我们观察来自内核的日志,如下所示：

ip-XX-XXX-XXX-XXX login: [395850.680006] hrtimer: interrupt took 20000573 ns
Sep 18 17:19:58 ip-XX-XXX-XXX-XXX kernel: [395850.680006] hrtimer: interrupt took 20000573 ns
[400921.660046] INFO: task rsync:7919 blocked for more than 120 seconds.
[400921.660066] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 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] Call Trace:
[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]  [] down+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均匀分布.

关于可能是什么原因的任何见解？

(事实上​​,几个小时前我们又开始看到这个！)