เราติดตั้งลินุกซ์ (มันอยู่ใน Amazon AWS ซึ่งเป็นระบบคล้าย CentOS ถึงแม้ว่าเราไม่แน่ใจว่าการปรับแต่งที่ทำกับมัน) ระบบที่มีพื้นที่จัดเก็บ 4TB เป็นปริมาณ XFS บน LVM (ในที่สุดจะใช้สำหรับการให้บริการผ่าน NFS4 แต่ ยังไม่ได้ใช้งานและเรากำลังใช้ rsync เพื่อซิงค์ไฟล์จากเซิร์ฟเวอร์ NFS ที่ใช้งานจริงของเราไปยังโวลุ่ม XFS (เช่นเรา rsync จากแหล่งที่มาเหนือ NFS ไปยังไดรฟ์ที่ใช้ XV บนโลคัล XFS) อย่างไรก็ตามเราสังเกตเห็นว่าในบางจุดใน rsync กลางเริ่มที่จะช้ามากขึ้น (ปริมาณงานลดลงอย่างมาก) และทั้งปริมาณการโหลดและการใช้หน่วยความจำเพิ่มขึ้นในระดับมาก (และ CPU มีสัดส่วนที่มากใน iowait) ในที่สุดฉันรีบูตระบบ XFS และระบบกลับมาทำงานได้ตามปกติโดยมีประสิทธิภาพการทำงานปกติของ rsync มากกว่าตั้งแต่อย่างน้อย 24 ชั่วโมงที่ผ่านมา
เราตรวจสอบกราฟการตรวจสอบ munin และไม่สังเกตเห็นอะไรชัดเจน แต่เราพบว่าตัวชี้วัด "ขนาดตาราง Inode" และ "open inode" (ตรวจสอบการใช้งานปลั๊กอิน munin ซึ่งชี้ไปที่ค่าที่อ่านจาก / proc / sys / fs / inode-nr) ลดลงเรื่อย ๆ เมื่อเวลาผ่านไป ไม่นานก่อนที่เราจะสังเกตว่า rsync ติดขัดเราสังเกตว่าตัวชี้วัดทั้งสองนั้นมีค่าไม่กี่พันจากหลายแสนคน (เซิร์ฟเวอร์ที่ไม่ใช่ XFS ของเรายังคงอยู่ที่ประมาณ 500k เกือบตลอดเวลาและไม่แสดงแนวโน้มที่ลดลงอย่างต่อเนื่อง) ) และเราสังเกตบันทึกจากเคอร์เนลดังนี้:
ip-XX-XXX-XXX-XXX ล็อกอิน: [395850.680006] hrtimer: อินเตอร์รัปต์ใช้ 20000573 ns 18 ก.ย. 17:19:58 ip-XX-XXX-XXX-XXX เคอร์เนล: [395850.680006] hrtimer: การขัดจังหวะใช้เวลา 20000573 ns [400921.660046] INFO: task 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 และในความเป็นจริงนั้นมีขนาดปริมาณที่ใหญ่กว่า นอกเหนือจากความแตกต่างของระบบไฟล์เซิร์ฟเวอร์ไฟล์จะอยู่ในคลาสเครื่องที่คล้ายกันและการตั้งค่าในลักษณะที่คล้ายกัน ตามที่เราพบว่าการวัดตาราง inode บนเซิร์ฟเวอร์ XFS ในขณะนี้ยังคงอยู่ในแนวโน้มที่ลดลงคล้ายกับการสังเกตก่อนหน้าของเราแม้ว่าเราเพิ่งจะรีบูตมันเมื่อวานนี้ฉันกังวลว่าปัญหาเดียวกันจะหลอกหลอนเราอีกครั้งในไม่ช้า ปัญหาบางอย่างกับการตั้งค่าเคอร์เนลของเราหรืออะไรก็ตาม
เราอยู่ในปริมาณ XFS ที่ติด inode64 บนเครื่องสถาปัตยกรรม x86_64 เมื่อเราพบสิ่งนี้ ตอนนี้เราได้คัดลอกข้อมูลประมาณ 1.3TB ไปยังปริมาณ XFS ซึ่งมีความจุประมาณ 4TB และเราควรมีข้อมูลประมาณ 3TB ในปริมาณนั้นถ้าคัดลอกทั้งหมด ไดรฟ์ข้อมูลถูกสร้างขึ้นใหม่ดังนั้นจึงได้รับการติดตั้ง inode64 ตั้งแต่เริ่มต้นเมื่อไม่มีข้อมูลอยู่ภายในดังนั้นระบบไฟล์ควรจะสะอาดและ inodes กระจายอย่างเท่าเทียมกัน
มีข้อมูลเชิงลึกเกี่ยวกับสิ่งที่อาจเป็นสาเหตุหรือไม่
(ที่จริงแล้วเราเริ่มเห็นสิ่งนี้อีกครั้งตั้งแต่ไม่กี่ชั่วโมงที่ผ่านมา!)