कुछ असंबंधित बिंदु:
80K बहुत सारी फाइल्स है।
एक निर्देशिका में 80,000 फाइलें? कोई भी ऑपरेटिंग सिस्टम या ऐप उस स्थिति को डिफ़ॉल्ट रूप से अच्छी तरह से हैंडल नहीं करता है। आपको बस rsync के साथ इस समस्या पर ध्यान देना होगा।
अपने rsync संस्करण की जाँच करें
आधुनिक rsync अतीत की तुलना में बड़ी निर्देशिकाओं को बहुत बेहतर तरीके से संभालता है। सुनिश्चित करें कि आप नवीनतम संस्करण का उपयोग कर रहे हैं।
यहां तक कि पुरानी rsync उच्च विलंबता लिंक पर काफी अच्छी तरह से बड़ी निर्देशिकाओं को संभालती है ... लेकिन 80k फाइलें बड़ी नहीं हैं ... यह बहुत बड़ा है!
उस ने कहा, rsync की मेमोरी का उपयोग सीधे एक पेड़ में फ़ाइलों की संख्या के लिए आनुपातिक है। बड़ी निर्देशिका बड़ी मात्रा में रैम लेती है। सुस्ती दोनों तरफ रैम की कमी के कारण हो सकती है। मेमोरी का उपयोग करते समय एक परीक्षण चलाएं। लिनक्स किसी भी लेफ्ट-ओवर रैम का उपयोग डिस्क कैश के रूप में करता है, इसलिए यदि आप रैम पर कम चल रहे हैं, तो डिस्क कैशिंग कम है। यदि आप रैम से बाहर निकलते हैं और सिस्टम स्वैप का उपयोग करना शुरू कर देता है, तो प्रदर्शन वास्तव में खराब होगा।
सुनिश्चित करें कि - जाँच का उपयोग नहीं किया जा रहा है
--checksum(या -c) प्रत्येक फ़ाइल के प्रत्येक ब्लॉक को पढ़ने की आवश्यकता होती है। आप शायद केवल संशोधन समय (इनोड में संग्रहीत) को पढ़ने के डिफ़ॉल्ट व्यवहार से प्राप्त कर सकते हैं।
छोटे बैचों में नौकरी विभाजित करें।
गिगासुन्क जैसी कुछ परियोजनाएँ हैं जो "डायरेक्टरी ट्री को पुनर्जीवित करने के लिए पर्ल का उपयोग करके वर्कलोड को चोप करेंगे, rsync के साथ ट्रांसफर करने के लिए फ़ाइलों की स्मालिश सूचियों का निर्माण करेंगे।"
अतिरिक्त निर्देशिका स्कैन ओवरहेड की एक बड़ी मात्रा होने जा रही है, लेकिन शायद यह एक शुद्ध जीत होगी।
इस स्थिति के लिए OS डिफॉल्ट नहीं किए जाते हैं।
यदि आप सभी चूक के साथ लिनक्स / फ्रीबीएसडी / आदि का उपयोग कर रहे हैं, तो प्रदर्शन आपके सभी अनुप्रयोगों के लिए भयानक होगा। डिफॉल्ट छोटे निर्देशिकाओं को मान लेते हैं, ताकि ओवरसाइज़ किए गए कैश पर रैम बर्बाद न करें।
अपने फाइल सिस्टम को बड़ी निर्देशिकाओं को बेहतर ढंग से संभालने के लिए ट्यून करें: क्या बड़े फ़ोल्डर का आकार IO के प्रदर्शन को धीमा कर देता है?
"नाम कैश" देखें
बीएसडी जैसे ऑपरेटिंग सिस्टम में एक कैश होता है जो एक नाम को इनोड ("नामी" कैश ") की तलाश में तेजी लाता है। प्रत्येक निर्देशिका के लिए एक नामी कैश है। यदि यह बहुत छोटा है, तो यह अनुकूलन से अधिक बाधा है। चूंकि rsync प्रत्येक फ़ाइल पर एक lstat () कर रहा है, प्रत्येक 80k फ़ाइलों के लिए इनोड एक्सेस किया जा रहा है। यह आपके कैश को उड़ा सकता है। अपने सिस्टम पर फ़ाइल निर्देशिका प्रदर्शन को ट्यून करने के लिए अनुसंधान करें।
एक अलग फाइल सिस्टम पर विचार करें
XFS को बड़ी निर्देशिकाओं को संभालने के लिए डिज़ाइन किया गया था। एक ही डायरेक्टरी में बड़ी संख्या में फाइलसिस्टम देखें
शायद 5 मिनट सबसे अच्छा आप कर सकते हैं।
गणना करने पर विचार करें कि कितने डिस्क ब्लॉक पढ़े जा रहे हैं, और गणना करें कि आपको कितनी तेजी से उम्मीद करनी चाहिए कि हार्डवेयर कई ब्लॉक को पढ़ सकता है।
हो सकता है कि आपकी उम्मीदें बहुत अधिक हों। विचार करें कि कितने डिस्क ब्लॉक को बिना किसी परिवर्तित फ़ाइलों के साथ rsync करने के लिए पढ़ा जाना चाहिए: प्रत्येक सर्वर को निर्देशिका को पढ़ने और प्रति फ़ाइल एक इनोड को पढ़ने की आवश्यकता होगी। मान लें कि कुछ भी कैश नहीं है क्योंकि, अच्छी तरह से, 80k फाइलों ने आपके कैश को उड़ा दिया है। मान लीजिए कि गणित को सरल रखने के लिए यह 80k ब्लॉक है। यह लगभग 40M डेटा है, जिसे कुछ सेकंड में पढ़ा जाना चाहिए। हालाँकि अगर प्रत्येक ब्लॉक के बीच डिस्क की तलाश होनी चाहिए, तो इसमें अधिक समय लग सकता है।
तो आपको लगभग 80,000 डिस्क ब्लॉक पढ़ने की आवश्यकता है। आपका हार्ड ड्राइव कितनी तेजी से ऐसा कर सकता है? यह देखते हुए कि यह यादृच्छिक I / O है, एक लंबा रेखीय पढ़ा नहीं गया, 5 मिनट बहुत उत्कृष्ट हो सकते हैं। यह 1 / (80000/600), या एक डिस्क हर 7.5ms पढ़ा है। क्या यह तेज या आपकी हार्ड ड्राइव के लिए धीमा है? यह मॉडल पर निर्भर करता है।
कुछ इसी तरह के खिलाफ बेंचमार्क
इसके बारे में सोचने का एक और तरीका यह है। यदि कोई फ़ाइल नहीं बदली गई है, तो ls -Llrडिस्क गतिविधि की समान मात्रा करता है लेकिन कभी भी कोई फ़ाइल डेटा (सिर्फ मेटाडेटा) नहीं पढ़ता है। ls -Llrचलने में लगने वाला समय आपकी ऊपरी सीमा है।
क्या rsync (कोई फाइल नहीं बदली गई) की तुलना में काफी धीमी है ls -Llr? फिर rsync के लिए आपके द्वारा उपयोग किए जा रहे विकल्पों में सुधार किया जा सकता है। शायद -cसक्षम या कुछ अन्य ध्वज है जो सिर्फ निर्देशिका और मेटाडेटा (इनोड डेटा) से अधिक पढ़ता है।
क्या rsync (कोई फ़ाइल नहीं बदली गई) लगभग उतनी ही तेज़ है ls -Llr? फिर आपने rsync को जितना हो सके उतना अच्छा बनाया है। आपको ओएस को ट्यून करना होगा, रैम जोड़ना होगा, तेज ड्राइव प्राप्त करना होगा, फाइल सिस्टम बदलना होगा आदि।
अपने देवों से बात करो
80k फाइलें सिर्फ खराब डिजाइन है। बहुत कम फ़ाइल सिस्टम और सिस्टम टूल इतनी बड़ी निर्देशिकाओं को बहुत अच्छी तरह से संभालते हैं। यदि फ़ाइल नाम abcdefg.txt हैं, तो उन्हें abdc / abcdefg.txt (पुनरावृत्ति पर ध्यान दें) में संग्रहीत करने पर विचार करें। यह निर्देशिकाओं को छोटे लोगों में तोड़ता है, लेकिन कोड में एक बड़े बदलाव की आवश्यकता नहीं होती है।
इसके अलावा .... एक डेटाबेस का उपयोग करने पर विचार करें। यदि आपके पास एक निर्देशिका में 80k फाइलें हैं, तो शायद आपके डेवलपर्स इस तथ्य के आसपास काम कर रहे हैं कि वे वास्तव में क्या चाहते हैं एक डेटाबेस है। बड़ी मात्रा में डेटा संग्रहीत करने के लिए MariaDB या MySQL या PostgreSQL एक बेहतर विकल्प होगा।
अरे, 5 मिनट में क्या हुआ है?
अंत में, क्या 5 मिनट वास्तव में इतना बुरा है? यदि आप दिन में एक बार इस बैकअप को चलाते हैं, तो 5 मिनट बहुत समय नहीं है। हां, मुझे गति पसंद है। हालांकि अगर 5 मिनट आपके ग्राहकों के लिए "काफी अच्छा" है, तो यह आपके लिए काफी अच्छा है। यदि आपके पास एक लिखित SLA नहीं है, तो अपने उपयोगकर्ताओं के साथ अनौपचारिक चर्चा के बारे में यह पता लगाने के लिए कि वे बैकअप लेने की कितनी जल्दी उम्मीद करते हैं।
मुझे लगता है कि अगर आपने प्रदर्शन में सुधार करने की आवश्यकता नहीं थी, तो आपने यह सवाल नहीं पूछा। हालांकि, यदि आपके ग्राहक 5 मिनट से खुश हैं, तो जीत की घोषणा करें और उन अन्य परियोजनाओं पर आगे बढ़ें जिन्हें आपके प्रयासों की आवश्यकता है।
अद्यतन: कुछ चर्चा के बाद हमने निर्धारित किया कि टोंटी नेटवर्क है। मैं कुछ चीजों की सिफारिश करने जा रहा हूँ इससे पहले कि मैं छोड़ दूं :-)।
- संपीड़न के साथ पाइप से अधिक बैंडविड्थ को निचोड़ने का प्रयास करें। हालाँकि संपीड़न के लिए अधिक CPU की आवश्यकता होती है, इसलिए यदि आपका CPU अतिभारित है, तो यह प्रदर्शन को बदतर बना सकता है। साथ और बिना rsync की कोशिश करें
-z, और बिना संपीड़न के साथ अपने ssh को कॉन्फ़िगर करें। समय सभी 4 संयोजनों को देखने के लिए कि उनमें से कोई भी दूसरों की तुलना में बेहतर प्रदर्शन करता है।
- नेटवर्क ट्रैफ़िक देखें कि क्या कोई रुकावट है या नहीं। यदि रुके हुए हैं, तो आप पा सकते हैं कि उनके कारण क्या है और वहां अनुकूलन करें। यदि rsync हमेशा भेज रहा है, तो आप वास्तव में अपनी सीमा पर हैं। आपकी पसंद हैं:
- एक तेज़ नेटवर्क
- rsync के अलावा कुछ और
- स्रोत और गंतव्य को एक साथ पास ले जाएं। यदि आप ऐसा नहीं कर सकते हैं, तो क्या आप एक स्थानीय मशीन पर rsync कर सकते हैं तो वास्तविक गंतव्य पर rsync? ऐसा करने के लिए लाभ हो सकते हैं यदि सिस्टम को प्रारंभिक rsync के दौरान डाउन करना पड़ता है।