linux – Inode表随着时间的推移急剧缩小,导致rsync / inode问题

我们设置了一个 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,并且在长时间内没有显示任何单调下降趋势),我们观察来自内核的日志,如下所示：

@H_404_4@ 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均匀分布.

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

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