Chúng tôi thiết lập Linux (trên Amazon AWS, một hệ thống giống như CentOS mặc dù chúng tôi không chắc chắn chính xác các tùy chỉnh được thực hiện trên hệ thống đó) với bộ lưu trữ 4TB dưới dạng khối lượng XFS trên LVM (cuối cùng được sử dụng để phục vụ trên NFS4, nhưng nó là chưa được sử dụng) và chúng tôi đang trong quá trình sử dụng rsync để đồng bộ hóa các tệp từ máy chủ NFS sản xuất của chúng tôi với khối lượng XFS (tức là chúng tôi rsync từ một nguồn qua NFS sang âm lượng LVM dựa trên XFS được gắn cục bộ). Tuy nhiên, chúng tôi đã quan sát thấy rằng tại một số điểm trong rsync giữa bắt đầu trở nên chậm chạp (thông lượng giảm mạnh) và cả mức trung bình tải và mức tiêu thụ bộ nhớ đều tăng ở mức độ lớn (và CPU có tỷ lệ rất lớn trong iowait). Cuối cùng, tôi đã khởi động lại hệ thống XFS và hệ thống dường như hoạt động trở lại bình thường, với hiệu suất rsync bình thường hơn kể từ, ít nhất là trong 24 giờ qua.
Chúng tôi đã kiểm tra các biểu đồ theo dõi munin và không nhận thấy bất cứ điều gì rõ ràng, nhưng chúng tôi thấy rằng các số liệu "Kích thước bảng Inode" và "inode mở" (đã kiểm tra việc triển khai plugin munin chỉ ra các giá trị được đọc từ / Proc / sys / fs / inode-nr) tiếp tục giảm theo thời gian. Ngay trước khi chúng tôi quan sát thấy rsync bị kẹt, chúng tôi đã quan sát thấy cả hai số liệu đều giảm giá trị của vài nghìn từ vài trăm nghìn (các máy chủ không phải XFS của chúng tôi ở mức khoảng 500 nghìn trong hầu hết thời gian và không hiển thị bất kỳ xu hướng giảm đơn điệu nào trong thời gian dài ) và chúng tôi đã quan sát các bản ghi từ kernel như sau:
đăng nhập ip-XX-XXX-XXX-XXX: [395850,680006] hrtimer: ngắt mất 20000573 ns Ngày 18 tháng 9 17:19:58 ip-XX-XXX-XXX-XXX kernel: [395850,680006] hrtimer: ngắt mất 20000573 ns [400921.660046] INFO: task rsync: 7919 bị chặn trong hơn 120 giây. [400921.660066] "echo 0> / Proc / sys / kernel / hung_task_timeout_secs" vô hiệu hóa thông báo này. [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] Dấu vết cuộc gọi: [400921.660202] [] calendar_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] [] xuống + 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
Chúng tôi cũng quan sát thấy sự gia tăng mạnh mẽ trong hoạt động "tra cứu" như đã thấy trên NFS nguồn khi điều đó xảy ra, trước đây vẫn ổn định trước khi chúng tôi bắt đầu gặp sự cố rsync nói trên.
Chúng tôi đã không quan sát hành vi tương tự trên khối lượng sản xuất của chúng tôi dựa trên ext3 và trên thực tế là những khối lượng có kích thước âm lượng thậm chí còn lớn hơn. Khác với sự khác biệt về hệ thống tệp, các máy chủ tệp nằm trên lớp máy tương tự và thiết lập theo cách tương tự. Vì chúng tôi thấy rằng các số liệu bảng inode trên máy chủ XFS hiện vẫn đang có xu hướng giảm tương tự như quan sát trước đây của chúng tôi mặc dù chúng tôi mới khởi động lại nó ngày hôm qua, tôi lo ngại vấn đề tương tự sẽ sớm ám ảnh chúng tôi và có thể sẽ phản ánh một số vấn đề với thiết lập, kernel hoặc bất cứ điều gì của chúng tôi.
Chúng tôi đang sử dụng các khối XFS được gắn inode64 trên các máy kiến trúc x86_64 khi chúng tôi trải nghiệm điều này. Ngay bây giờ chúng tôi đã sao chép khoảng 1,3TB dữ liệu vào ổ XFS có dung lượng xấp xỉ 4TB và chúng tôi sẽ có khoảng 3TB dữ liệu trong ổ đó nếu được sao chép hoàn toàn. Âm lượng được tạo ra một lần nữa vì vậy đã được gắn vào inode64 ngay từ đầu khi không có dữ liệu bên trong, vì vậy hệ thống tập tin phải sạch sẽ và phân bổ đều.
Bất kỳ hiểu biết về những gì có thể là nguyên nhân?
(thực tế là chúng tôi đã bắt đầu thấy điều này một lần nữa từ vài giờ trước!)