我们设置了一个 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 …