हम एक लिनक्स (यह अमेज़ॅन एडब्ल्यूएस पर है, एक सेंटोस जैसी प्रणाली है, हालांकि हम निश्चित रूप से इस पर किए गए कस्टमाइज़ेशन नहीं हैं) सिस्टम एलवीएम पर एक्सएफएस वॉल्यूम के रूप में 4 टीबी स्टोरेज के साथ सिस्टम है (अंततः एनएफएस 4 पर सेवा देने के लिए उपयोग किया जाता है, लेकिन यह है अभी तक उपयोग में नहीं है), और हम अपने उत्पादन NFS सर्वर से XFS वॉल्यूम (यानी हम स्थानीय रूप से माउंट किए गए XFS- आधारित LVM वॉल्यूम पर NFS के स्रोत से rsync करते हैं) से फ़ाइलों को सिंक करने के लिए rsync का उपयोग करने की प्रक्रिया में हैं। हालांकि, हमने पाया कि मध्य rsync में कुछ बिंदु पर तेजी से सुस्त (थ्रूपुट तेजी से कम) होना शुरू हो गया और लोड औसत और मेमोरी खपत दोनों काफी हद तक बढ़ गए (और सीपीयू का आयोवाइट में बहुत बड़ा अनुपात है)। आखिरकार मैंने XFS सिस्टम को रिबूट किया और सिस्टम स्पष्ट रूप से फिर से शुरू हो गया, अधिक सामान्य rsync प्रदर्शन के साथ, कम से कम पिछले 24 घंटों के लिए।
हमने मुनिन मॉनिटरिंग ग्राफ़ की जाँच की और कुछ भी स्पष्ट नहीं देखा, लेकिन हमने पाया कि "इनोड टेबल साइज़" और "ओपन इनोड" मेट्रिक्स (मुइन प्लगइन कार्यान्वयन की जाँच की गई है जो मान / पॉइंट / sys / से पढ़े जा रहे मानों की ओर इशारा करता है) fs / inode-nr) समय के साथ कम होते रहे। कुछ समय पहले जब हमने rsync को अटकते हुए देखा, तो हमने देखा कि दोनों मेट्रिक्स कई सौ से कुछ हजारों के मूल्य तक नीचे थे (हमारे गैर-एक्सएफएस सर्वर अधिकांश समय लगभग 500k पर रहते हैं और विस्तारित अवधि में घटते हुए कोई भी मोनोटोनिक नहीं दिखाते हैं ), और हमने इस तरह से कर्नेल से लॉग देखे:
ip-XX-XXX-XXX-XXX लॉगिन: [395850.680006] hrtimer: इंटरप्ट में 200007373s सितम्बर 18 17:19:58 आईपी-एक्सएक्सएक्स-एक्सएक्सएक्स-एक्सएक्सएक्स-एक्सएक्सएक्स कर्नेल: [395850.680006] हर्टिमर: रुकावट 20000573 एनएस [४०० ९ २१.६००४६] जानकारी: कार्य rsync: for ९ १ ९ १२० से अधिक सेकंड के लिए अवरुद्ध। [४०० ९ २१.६६००६६] "प्रतिध्वनि ०> / proc / sys / कर्नेल / Hung_task_timeout_secs" इस संदेश को निष्क्रिय करता है। [400921.660077] rsync डी ffff880002fe4240 0 7919 7918 0x00000000 [400921.660093] ffff8800683e5638 00000000000002828 ffff880000000000 0000000000014240 [400921.660131] ffff8800683e5fd8 0000000000014240 ffff8800683e5fd8 ffff88000726da40 [400921.660153] 0000000000014240 0000000000014240 ffff8800683e5fd8 0000000000014240 [400921.660176] कॉल ट्रेस: [४०० ९ २१.६६०२०२] [] शेड्यूल_टाइम + ० एक्स १ एफडी / ० एक्स २ .० [400921.660220] []? pvclock_clocksource_read + 0x58 / 0xd0 [४०० ९ २१.६६०२३४] []? __raw_callee_save_xen_irq_enable + 0x11 / 0x26 [400921.660247] [] __down + 0x76 / 0xc0 [400921.660262] [] नीचे + 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 / xx] [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 / xx] [400921.660467] [] xfs_ialloc_ag_select + 0x12b / 0x280 [xfs] [400921.660485] [] xfs_dialloc + 0x3c7 / 0x870 [xo] [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] [४०० ९ २१.६६०६०६] []? xfs_log_reserve + 0xe2 / 0xf0 [xfs] [400921.660623] [] xfs_create + 0x3f7 / 0x600 [xfs] [४०० ९ २१.६६०६३]] []? __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
हमने "लुकअप" ऑपरेशन में भारी वृद्धि देखी, जैसा कि स्रोत एनएफएस पर हुआ था जब ऐसा हुआ था, जो कि उक्त rsync समस्या का अनुभव करने से पहले शुरू होने से पहले स्थिर बना हुआ था।
हमने अपने उत्पादन संस्करणों पर समान व्यवहार नहीं देखा है जो एक्स 3-आधारित हैं और वास्तव में वे बड़े वॉल्यूम आकारों के साथ थे। फाइलसिस्टम अंतर के अलावा, फाइल सर्वर एक समान तरीके से मशीन वर्ग और सेटअप पर हैं। जैसा कि हमने पाया कि एक्सएफएस सर्वर पर अभी इनोड टेबल मेट्रिक्स अभी भी हमारे पहले के अवलोकन के समान घटती प्रवृत्ति पर हैं, भले ही हमने कल ही इसे रिबूट किया हो, मुझे चिंता है कि एक ही मुद्दा जल्द ही हमें फिर से परेशान करेगा, और शायद यह प्रतिबिंबित करेगा हमारे सेटअप, कर्नेल या जो कुछ के साथ कुछ समस्याएँ।
जब हम यह अनुभव करते हैं तो हम x86_64 आर्किटेक्चर मशीनों पर इनोड64-माउंटेड एक्सएफएस वॉल्यूम पर होते हैं। अभी हमने XFS वॉल्यूम में लगभग 1.3TB डेटा कॉपी किया है, जिसकी क्षमता लगभग 4TB है और पूरी तरह से कॉपी किए जाने पर हमारे पास लगभग 3TB डेटा उस वॉल्यूम में होना चाहिए। वॉल्यूम नए सिरे से बनाया गया था इसलिए शुरू से ही इनोड64-माउंटेड रहा है जब अंदर कोई डेटा नहीं था, इसलिए फाइल सिस्टम साफ होना चाहिए और समान रूप से वितरित किया जाना चाहिए।
क्या कारण हो सकते हैं?
(पी एस वास्तव में हमने कुछ घंटों पहले से इसे फिर से देखना शुरू कर दिया था!)