NFS की तुलना में rsync अधिक तेज़ क्यों है?

Question

कुछ दिन पहले मैंने कुछ अजीब देखा (कम से कम मेरे लिए)। मैं उसी डेटा की प्रतिलिपि बनाकर rsync चला गया और बाद में इसे NFS माउंट तक हटा दिया गया, जिसे कहा जाता है /nfs_mount/TEST। इससे /nfs_mount/TESTहोस्ट / निर्यात किया जाता है nfs_server-eth1। दोनों नेटवर्क इंटरफेस पर MTU 9000 है, बीच में स्विच जंबो फ्रेम का समर्थन करता है। अगर मुझे rsync -av dir /nfs_mount/TEST/नेटवर्क ट्रांसफर स्पीड एक्स एमबीपीएस मिलती है। अगर मुझे rsync -av dir nfs_server-eth1:/nfs_mount/TEST/नेटवर्क ट्रांसफर स्पीड कम से कम 2X एमबीपीएस मिलती है। मेरे एनएफएस माउंट विकल्प हैं nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp।

नीचे पंक्ति: दोनों स्थानान्तरण एक ही नेटवर्क सबनेट, एक ही तार, एक ही इंटरफेस पर जाते हैं, एक ही डेटा को पढ़ते हैं, एक ही डायरेक्टरी को लिखते हैं, आदि केवल NFSv3 के माध्यम से अंतर है, दूसरा rsync पर।

ग्राहक उबंटू 10.04, सर्वर उबंटू 9.10 है।

कैसे आता है rsync इतना तेज़? NFS को उस गति से कैसे मेल करें?

धन्यवाद

संपादित करें: कृपया ध्यान दें कि मैं NFS शेयर या SSH को NFS सर्वर में लिखने के लिए rsync का उपयोग करता हूं और स्थानीय रूप से वहां लिखता हूं। दोनों बार मैं करता हूं rsync -av, स्पष्ट गंतव्य निर्देशिका के साथ शुरू। कल मैं सादे कॉपी के साथ कोशिश करूंगा।

Edit2 (अतिरिक्त जानकारी): फ़ाइल का आकार 1KB-15MB से लेकर है। फाइलें पहले से ही संपीड़ित हैं, मैंने उन्हें बिना किसी सफलता के साथ आगे संपीड़ित करने की कोशिश की। मैंने tar.gzउसी से फाइल बनाई dir। यहाँ पैटर्न है:

• rsync -av dir /nfs_mount/TEST/ = सबसे धीमा स्थानांतरण;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= जंबो फ्रेम सक्षम के साथ सबसे तेज rsync; जंबो फ्रेम के बिना थोड़ा धीमा है, लेकिन अभी भी सीधे एनएफएस की तुलना में काफी तेज है;
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = इसके गैर- tar.gz समकक्ष के समान;

के साथ टेस्ट cpऔर scp:

• cp -r dir /nfs_mount/TEST/= की तुलना में थोड़ा तेज rsync -av dir /nfs_mount/TEST/लेकिन फिर भी काफी धीमा है rsync -av dir nfs_server-eth1:/nfs_mount/TEST/।
• scp -r dir /nfs_mount/TEST/= सबसे तेजी से समग्र, थोड़ा काबू rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = इसके गैर- tar.gz समकक्ष के समान;

निष्कर्ष, इस परिणाम के आधार पर: इस परीक्षण के लिए महत्वपूर्ण अंतर नहीं है अगर टारगेट बड़ी फ़ाइल या कई छोटे का उपयोग किया जाए। जंबो फ्रेम ऑन या ऑफ भी लगभग कोई फर्क नहीं पड़ता। cpऔर scpउनके संबंधित rsync -avसमकक्षों की तुलना में तेज़ हैं । सीधे निर्यात किए गए NFS शेयर पर लिखना SSH के समान निर्देशिका में लिखने की तुलना में काफी कम (कम से कम 2 बार) उपयोग किए गए तरीके की परवाह किए बिना धीमा है।

इस मामले में अंतर cpऔर rsyncप्रासंगिक नहीं हैं। मैंने कोशिश की cpऔर scpयह देखने के लिए कि क्या वे एक ही पैटर्न दिखाते हैं और वे करते हैं - 2X अंतर।

जैसा कि मैं उपयोग करता हूं rsyncया cpदोनों मामलों में, मैं समझ नहीं पा रहा हूं कि एसएसएच पर समान कमांड के हस्तांतरण की गति तक पहुंचने के लिए एनएफएस को क्या रोकता है।

एनएफएस शेयर पर लिखना एसएसएक्स पर एक ही स्थान पर लिखने की तुलना में 2X धीमा है?

Edit3 (NFS सर्वर / आदि / निर्यात विकल्प) rw,no_root_squash,no_subtree_check,sync:। ग्राहक का / proc / mounts दिखाता है nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp:।

आप सभी को धन्यवाद!

Comments

क्या यह कई छोटी फ़ाइलों और एक बड़ी फ़ाइल के लिए समान परिणाम होना चाहिए?

— ग्यारहवें

@notpeter - मूल पोस्ट में विकल्प जोड़े। धन्यवाद!

— GRS

मुझे एहसास है कि यह एक पुराना सवाल है, लेकिन एससीपी और rsync के बीच एक बड़ा अंतर यह है कि ट्रांसफर के समय में थोड़ा सा अंतर होता है, यह दिखाने के लिए किया गया ऑटोमैटिक फाइल ट्रांसफर चेकसम है कि फाइल सही ट्रांसफर हुई है। यह rsync के -c विकल्प से भिन्न होता है जो कि होस्ट के बीच एक फाइल को अपडेट करने के लिए चेकसम का उपयोग करता है। यदि आप केवल नई फ़ाइलों का मुकाबला कर रहे हैं जो कि खेल में नहीं आती हैं।

— रोवन हॉकिन्स

Answer 1

हो सकता है कि यह धीमी गति से स्थानांतरण की गति न हो, लेकिन बढ़ा हुआ विलंबता लिखें। सिंक के बजाय NFS शेयर Async माउंट करने का प्रयास करें और देखें कि गति अंतराल बंद हो जाता है या नहीं। जब आप ss पर rsync करते हैं, तो दूरस्थ rsync प्रक्रिया अतुल्यकालिक (जल्दी) लिखती है। लेकिन जब तुल्यकालिक रूप से माउंट किए गए एनएफ़एस शेयर पर लिखते हैं, तो राइट्स तुरंत पुष्टि नहीं किए जाते हैं: एनएफएस क्लाइंट प्रतीक्षा करता है कि एनएफएस क्लाइंट को पुष्टिकरण भेजने से पहले डिस्क (या अधिक संभावना नियंत्रक कैश) मारा है कि राइट सफल था।

यदि 'async' आपकी समस्या को ठीक करता है, तो ध्यान रखें कि यदि NFS सर्वर के मध्य में कुछ होता है तो आप डिस्क पर असंगत डेटा के साथ बहुत अच्छी तरह से समाप्त हो सकते हैं। जब तक यह एनएफएस माउंट इस (या किसी अन्य) डेटा के लिए प्राथमिक भंडारण नहीं है, आप शायद ठीक हो जाएंगे। यदि आप rsync-over-ssh के दौरान (जैसे rsync रिटर्न 'समाप्त' हो रहे हैं, तो nfs सर्वर क्रैश होने के बाद, आप उसी नाव में होंगे, जैसे nsp सर्वर क्रैश हो जाता है, राइट कैश में अनक्मिटेड डेटा खो जाता है। डिस्क पर असंगत डेटा छोड़ना)।

हालाँकि, आपके परीक्षण (नए डेटा को रेनसिंग) के साथ कोई समस्या नहीं है, इस बात से अवगत रहें कि ssh पर rsync महत्वपूर्ण CPU बना सकता है और दूरस्थ बाइट से पहले दूरस्थ बाइट पर IO की माँगों को स्थानांतरित करता है, जबकि यह चेकसमों की गणना करता है और उन फ़ाइलों की सूची उत्पन्न करता है जिनकी आवश्यकता है अपडेट किया गया।

Comments

मुझे लगता है कि यह उत्तर सही है। यदि दो मशीनों पर मीडिया (डिस्क) तुलनीय हैं (एक ही RPM / बैंडविड्थ / RAID कॉन्फ़िगरेशन), तो आप एक अच्छा विचार प्राप्त कर सकते हैं कि क्या उलटा ऑपरेशन करके ऐसा हो सकता है: 'rsync -av / nfs_mount / TEST / dir 'अन्यथा, सिंक को बंद करना और इसे आज़माना परीक्षण का तरीका है।

— Slartibartfast

मैंने सिंक बनाम एसिंक्स के साथ त्वरित परीक्षण किया और मुझे लगता है कि इस उत्तर में सही होने की बहुत संभावना है। एसिंक्स को चुनना अंतर को काफी कम कर देता है, लेकिन यह एसएसएच एक की तुलना में थोड़ा धीमा है। मैं और परीक्षण करूंगा और आप लोगों को बताऊंगा। आपका बहुत बहुत धन्यवाद!

— GRS

अपडेट: मेरे नए परीक्षणों ने सिंक बनाम एसिंक्स एनएफएस निर्यात विकल्प की गति के मामले में महत्वपूर्ण अंतर का प्रदर्शन किया। NFS के साथ async के साथ आरोहित किया rsync -av dir.tar.gz /nfs_mount/TEST/गया और मुझे उसी के साथ अंतरण गति मिली rsync -av dir nfs_server-eth1:/nfs_mount/TEST/। मैं इस उत्तर को सही मानूंगा, लेकिन मैं उत्सुक हूं कि क्या मैं सेटअप में और सुधार कर सकता हूं। धन्यवाद! अच्छा किया नोटरी!

— GRS

Answer 2

एनएफएस एक साझाकरण प्रोटोकॉल है, जबकि रुपीक फ़ाइल स्थानांतरण के लिए अनुकूलित है; बहुत सारे अनुकूलन हैं जो तब किए जा सकते हैं जब आप एक प्राथमिकता जानते हैं कि आपका लक्ष्य उन तक साझा पहुंच प्रदान करने के बजाय जितनी जल्दी हो सके फाइलों को कॉपी करना है।

यह मदद करनी चाहिए: http://en.wikipedia.org/wiki/Rsync

Comments

यदि आप हाथ से पहले डेटा जानते हैं (जो आप आमतौर पर करते हैं), तो आप -e "ssh Compression=no"संभवतः तेज ट्रांसफर गति प्राप्त करने के लिए विकल्प के साथ चुनिंदा संपीड़न बंद कर सकते हैं । यह इसे संपीड़ित फ़ाइलों से रखेगा जो संभवतः पहले से संपीड़ित हैं। मैंने कई बार गति देखी है।

— lsd

@lsd - ssh सम्पीडन आमतौर पर डिफ़ॉल्ट रूप से बंद होता है, और rsync के लिए अनुशंसित नहीं है। की अनुमति दे rsync विकल्पों के साथ डेटा को संपीड़ित करने -z, --compress-levelऔर --skip-compressएक संकुचित परिवहन के साथ बेहतर प्रदर्शन था मिल जाएगा।

— जिमब

Answer 3

रुपीक्स एक फाइल प्रोटोकॉल है जो फाइलों के बीच केवल परिवर्तित बिट्स को स्थानांतरित करता है। एनएफएस एक दूरस्थ निर्देशिका फ़ाइल प्रोटोकॉल है जो हर बार सब कुछ संभालता है ... एक तरह से एसएमबी की तरह। दोनों अलग-अलग हैं और विभिन्न उद्देश्यों के लिए हैं। दो NFS शेयरों के बीच स्थानांतरण के लिए आप रु। का उपयोग कर सकते हैं।

Comments

मुझे थोड़ा बुरा लगता है कि आपको वोटिंग में कमी आई क्योंकि आपने तकनीकी रूप से कुछ भी गलत नहीं कहा, लेकिन ऐसा नहीं लगता कि आपने चर्चा में कुछ भी जोड़ा है, और आप बहुत अधिक विशिष्ट जानकारी उपलब्ध होने के बाद आए हैं। साथ ही, उनकी पोस्ट से ऐसा लग रहा है कि लेखक को इन बातों की जानकारी थी।

— Slartibartfast

मुझे लगा कि मैं दूसरी पोस्ट और पहली बार उल्लेख कर रहा हूं कि दोनों अलग-अलग लक्ष्यों को ध्यान में रखते हुए प्रोटोकॉल थे। ठीक है, मैंने सोचा था कि सवाल का पहला संपादन थोड़ा कठिन था।

— पीसीयूनाइट

Answer 4

यह दिलचस्प है। एक संभावना जिसे आपने नहीं माना है वह सामग्री / प्रकार की फ़ाइल है जिसे आप संचारित कर रहे हैं।

यदि आपके पास छोटी फ़ाइलों (जैसे व्यक्तिगत फ़ाइलों में ईमेल) के स्कैड हैं, तो पूर्ण एमटीयू का उपयोग नहीं करने के कारण एनएफएस दक्षता टैंकरिंग हो सकती है (शायद यह यूडीपी पर टीसीपी के साथ कम संभावना है)।

वैकल्पिक रूप से, यदि आपके पास अत्यधिक संपीड़ित फ़ाइलें / डेटा, तेज़ सीपीयू और एक नेटवर्क है जिसमें सीपीयू (*) की गति काफी नहीं है, तो आप ssh लिंक पर निहित प्रभाव से बस स्पीडअप प्राप्त कर सकते हैं।

एक तीसरी संभावना यह है कि फ़ाइलें (या एक संस्करण) पहले से ही गंतव्य में मौजूद हैं। इस स्थिति में स्पीडअप होगा क्योंकि rsync प्रोटोकॉल आपको फ़ाइलों को स्थानांतरित करने से बचाता है।

(*) इस मामले में 'स्पीड' द्वारा, मैं उस दर की बात कर रहा हूं, जिस दर पर नेटवर्क की तुलना में सीपीयू डेटा को संपीड़ित कर सकता है, जैसे कि डेटा को प्रसारित कर सकता है, उदाहरण के लिए तार पर 5 एमबी भेजने में 5 सेकंड लगते हैं, लेकिन सीपीयू 1 सेकंड में 1MB में 5MB सेक कर सकते हैं। इस स्थिति में आपके संपीड़ित डेटा का संचरित समय 1 सेकंड से थोड़ा अधिक होगा, जबकि असम्पीडित डेटा 5 सेकंड है।

Comments

बहुत अच्छा! जिन फ़ाइलों के साथ मैं परीक्षण करता हूं वे कई छोटी छवियां हैं। वे आकार में भिन्न होते हैं। अगर मुझे उन्हें और कम कर सकें तो मुझे दोबारा जांच करनी होगी। फाइलें निश्चित रूप से गंतव्य पर मौजूद नहीं हैं, क्योंकि मैं हर बार खरोंच से शुरू करता हूं। कल, मैं सरल cp -rबनाम के साथ परीक्षण करूंगा rsyncऔर फिर मैं एमटीयू से लाभ उठाने के लिए बड़ी फ़ाइलों को संपीड़ित करूंगा। धन्यवाद!

— GRS

Answer 5

मैं थ्रूपुट को बढ़ाने के लिए -e "ssh Ciphers = arcfour" का भी उपयोग करता हूं।

Comments

एक "-o" की आवश्यकता है। अर्थात: "rsync -va -e" ssh -o Ciphers = arcfour "स्रोत गंतव्य: / गंतव्य /"

— पीट एशडाउन

Answer 6

यदि आप लक्ष्य हैं कि सभी फाइलों को एक स्थान से दूसरे स्थान पर कॉपी करें, तो टार / नेटकैट सबसे तेज विकल्प होगा। यदि आप जानते हैं कि आपकी फ़ाइलों (शून्य) में बहुत सारे व्हाट्सएप हैं तो -i विकल्प का उपयोग करें।

स्रोत: tar cvif - / path / to / source | nc DESTINATION पोर्टल डस्टिनेशन: cd / path / to / source && nc -l PLNUM | टार ज़विफ़ -

यदि आप जानते हैं कि आपका डेटा संपीड़ित है, तो अपने टार कमांड -z -j -Ipixz पर कम्प्रेशन का उपयोग करें

मैं पिक्सज़ का प्रशंसक हूं .. समानांतर एक्सज़, यह महान संपीड़न प्रदान करता है और मैं सीपीयू की संख्या को ट्यून कर सकता हूं जो मुझे नेटवर्क बैंडविड्थ के लिए है। अगर मेरे पास धीमी बैंडविड्थ है, तो मैं उच्च संपीड़न का उपयोग करूंगा, इसलिए मैं नेटवर्क से अधिक सीपीयू पर प्रतीक्षा कर रहा हूं .. अगर मेरे पास एक तेज नेटवर्क है तो मैं बहुत कम संपीड़न का उपयोग करूंगा:

स्रोत: tar cvif - / path / to / source | पिक्सज -2 -p12 | nc DESTINATION PORTNUM # टार, ज़ीरो को अनदेखा करें, 12 cpu कोर के उपयोग से स्तर 2 पिक्सज़ संपीड़न DESTINATION: nc -l PORTNUM | tar -Ipixz -xvif

यदि आप संपीड़न स्तर को ट्यून करते हैं और अपने डेटा सेट के आधार पर सही तरीके से कोर लगाते हैं, तो आपको नेटवर्क को संतृप्त रखने के लिए सक्षम होना चाहिए और पर्याप्त संपीड़न करना चाहिए जिससे आप अड़चन हो जाए (आमतौर पर लिखने और पढ़ने के लिए डिस्क सिस्टम लिखने पर साइड हो) वही)।

के रूप में rsync के लिए, मेरा मानना ​​है कि यह शून्य को उसी तरह से स्किप करता है जिस तरह से टार उस विकल्प के साथ करता है, इसलिए यह NFS की तुलना में कम डेटा संचारित कर रहा है। एनएफएस डेटा के बारे में धारणा नहीं बना सकता है इसलिए एनएफएस प्रोटोकॉल ओवरहेड के साथ हर बाइट को प्रसारित करना होगा। rsync में कुछ ओवरहेड है ..

netcat के पास मूल रूप से कोई नहीं है .. यह पूर्ण टीसीपी पैकेट भेजेगा जिसमें आपके द्वारा परवाह किए गए डेटा के अलावा कुछ भी नहीं है।

netcat के साथ, जैसे कि scp के साथ, आपको हर समय सभी स्रोत डेटा भेजने होंगे, आप rsync के साथ चयनात्मक नहीं हो सकते हैं, इसलिए यह वृद्धिशील बैकअप या उस तरह की चीज़ के लिए उपयुक्त नहीं है, लेकिन यह डेटा या संग्रह की प्रतिलिपि बनाने के लिए अच्छा है।

Answer 7

क्या आपके पास nfsshare पर फ़ाइल लॉकिंग सेटअप है? यदि आपको अक्षम किया गया था तो आपको बहुत अधिक सुधार हो सकता है।

Comments

मैं यह कैसे पता लगा सकता हूं कि यह सक्षम है या नहीं? यह यहाँ: docstore.mik.ua/orelly/networking_2ndEd/nfs/ch11_02.htm बताता है कि NFS v3 में फ़ाइल लॉकिंग क्षमताएं नहीं हैं।

— GRS

Answer 8

मुझे लगता है कि बढ़ी हुई गति कम से कम आंशिक रूप से "rsync src होस्ट: / पाथ" के कारण है, जो दूरस्थ मशीन पर एक स्थानीय प्रक्रिया को भेजने / प्राप्त करने के लिए, प्रभावी रूप से आपके I / O को आधे में काट कर देता है।