Kami menyiapkan sistem Linux (ada di Amazon AWS, sistem mirip-CentOS walaupun kami tidak yakin dengan kustomisasi yang dilakukan pada sistem itu) dengan penyimpanan 4TB sebagai volume XFS di atas LVM (akhirnya akan digunakan untuk melayani lebih dari NFS4, tetapi itu adalah belum digunakan), dan kami sedang dalam proses menggunakan rsync untuk menyinkronkan file dari server NFS produksi kami ke volume XFS (yaitu kami rsync dari sumber melalui NFS ke volume LVM berbasis XFS yang dipasang secara lokal). Namun, kami mengamati bahwa di beberapa titik di rsync tengah mulai menjadi semakin lamban (throughput berkurang tajam) dan baik rata-rata memuat dan konsumsi memori meningkat sebagian besar (dan CPU memiliki proporsi yang sangat besar di iowait). Akhirnya saya reboot sistem XFS dan sistem tampaknya kembali normal, dengan kinerja rsync yang lebih normal sejak, setidaknya selama 24 jam terakhir.
Kami memeriksa grafik pemantauan munin dan tidak melihat sesuatu yang jelas, tetapi kami menemukan bahwa metrik "Inode table size" dan "open inode" (memeriksa implementasi plugin munin yang menunjuk ke nilai yang dibaca dari / proc / sys / fs / inode-nr) terus menurun dari waktu ke waktu. Sesaat sebelum kami mengamati rsync macet, kami mengamati kedua metrik turun ke nilai beberapa ribu dari beberapa ratus ribu (server non-XFS kami bertahan sekitar 500k sebagian besar waktu dan tidak menunjukkan tren penurunan monotonik selama periode yang diperpanjang ), dan kami mengamati log dari kernel seperti ini:
login ip-XX-XXX-XXX-XXX: [395850.680006] hrtimer: interrupt took 20000573 ns 18 Sep 17:19:58 ip-XX-XXX-XXX-XXX kernel: [395850.680006] hrtimer: interrupt took 20000573 ns [400921.660046] INFO: tugas rsync: 7919 diblokir selama lebih dari 120 detik. [400921.660066] "echo 0> / proc / sys / kernel / hung_task_timeout_secs" menonaktifkan pesan ini. [400921.660077] rsync D ffff880002fe4240 0 7919 7918 0x00000000 [400921.660093] ffff8800683e5638 0000000000000282 ffff88000000000000 0000000000014240 [400921.660131] ffff8800683e5fd8 0000000000014240 ffff8800683e5fd8 ffff88000726da40 [400921.660153] 0000000000014240 0000000000014240 ffff8800683e5fd8 0000000000014240 [400921.660176] Jejak Panggilan: [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] [] turun + 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] []? dialokasikan_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
Kami juga mengamati peningkatan drastis dalam operasi "pencarian" seperti yang terlihat pada NFS sumber ketika itu terjadi, yang sebelumnya tetap stabil sebelum kami mulai mengalami masalah rsync tersebut.
Kami belum mengamati perilaku serupa pada volume produksi kami yang berbasis ext3 dan bahkan mereka dengan ukuran volume yang lebih besar. Selain perbedaan sistem file, server file berada pada kelas mesin yang sama dan pengaturan dengan cara yang sama. Saat kami menemukan bahwa metrik tabel inode pada server XFS sekarang masih dalam tren menurun yang mirip dengan pengamatan kami sebelumnya meskipun kami baru saja mem-boot ulang kemarin, saya khawatir masalah yang sama akan menghantui kami lagi segera, dan mungkin mencerminkan beberapa masalah dengan pengaturan kami, kernel atau apa pun.
Kami menggunakan volume XFS yang terpasang di inode64 pada mesin arsitektur x86_64 ketika kami mengalami hal ini. Saat ini kami telah menyalin sekitar 1,3TB data ke volume XFS yang kapasitasnya sekitar 4TB dan kami harus memiliki sekitar 3TB data dalam volume itu jika disalin sepenuhnya. Volume dibuat lagi sehingga telah inode64-mount dari awal ketika tidak ada data di dalamnya, sehingga sistem file harus bersih dan inode didistribusikan secara merata.
Adakah wawasan tentang apa yang mungkin menjadi penyebabnya?
(ps sebenarnya kami mulai melihat ini lagi sejak beberapa jam yang lalu!)