Linux（それはAmazon AWS、CentOSのようなシステム上にありますが、カスタマイズは正確には行われていません）を、LVM上のXFSボリュームとして4TBストレージでセットアップします（最終的にはNFS4経由での提供に使用されますが、まだ使用されていません）、rsyncを使用してファイルを本番のNFSサーバーからXFSボリュームに同期しています（つまり、NFS経由のソースからローカルにマウントされたXFSベースのLVMボリュームにrsyncを実行しています）。ただし、中間のある時点でrsyncがますます遅くなり始め（スループットが大幅に低下）、負荷平均とメモリ消費の両方が大幅に増加しました（そしてCPUはiowaitで非常に大きな割合を占めています）。最終的に私はXFSシステムをリブートし、システムは通常の状態に復帰したようです。少なくとも24時間はrsyncのパフォーマンスがより正常でした。
muninのモニタリンググラフを確認したところ、明らかなことは何もわかりませんでしたが、「Inode table size」および「open inode」メトリック（/ proc / sys /から読み取られる値を指すmuninプラグインの実装を確認しました） fs / inode-nr）は時間とともに減少し続けました。rsyncがスタックするのを観察する少し前に、両方のメトリックが数十万から数千の値に下がっているのを観察しました（非XFSサーバーはほとんどの場合ほぼ500,000のままで、長期間にわたって単調な減少傾向を示しません） ）、次のようなカーネルからのログを観察しました：
ip-XX-XXX-XXX-XXXログイン：[395850.680006] hrtimer：割り込みは20000573 nsかかりました Sep 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 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 + 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サーバー上のiノードテーブルのメトリックは、昨日再起動したばかりですが、以前の観測と同様に減少傾向にあることがわかりました。セットアップ、カーネルなど、いくつかの問題。
これを経験したのは、x86_64アーキテクチャマシン上のinode64にマウントされたXFSボリュームです。現在、約1.3 TBのデータを容量が約4 TBのXFSボリュームにコピーしました。完全にコピーした場合、そのボリュームには約3 TBのデータが必要です。ボリュームは新たに作成されたため、内部にデータが存在しない最初からiノード64でマウントされているため、ファイルシステムはクリーンでiノードが均等に分散されている必要があります。
何が原因であるかについての洞察はありますか？
（実際、私たちは数時間前から再びこれを見始めました！）