tar + rsync + अनार। बस rsync पर कोई गति लाभ?

Question

मैं अक्सर खुद को 10K - 100K फाइलों के साथ एक रिमोट मशीन (एक ही नेटवर्क ऑन-कैंपस के भीतर) के लिए फ़ोल्डर्स भेजते हुए पाता हूं।

मैं सोच रहा था कि क्या इस पर विश्वास करने के कारण हैं,

 tar + rsync + untar

या केवल

 tar (from src to dest) + untar

अभ्यास में तेज़ हो सकता है

rsync 

पहली बार फाइल ट्रांसफर करते समय ।

मुझे ऐसे उत्तर में दिलचस्पी है जो उपरोक्त दो परिदृश्यों में संबोधित करता है: संपीड़न का उपयोग करना और इसका उपयोग नहीं करना।

अद्यतन करें

मैंने अभी हाल ही में 10,000 छोटी फ़ाइलों (कुल आकार = 50 एमबी) को स्थानांतरित करने वाले कुछ प्रयोग किए हैं, और सीधे tar+rsync+untarचलने की तुलना में लगातार तेज था rsync(दोनों बिना संपीड़न के)।

Comments

क्या आप दूसरे छोर पर डेमॉन मोड में rsync चला रहे हैं?

— JBRWilkinson

पुन। आपका सहायक प्रश्न:tar cf - . | ssh remotehost 'cd /target/dir && tar xf -'

— गिल्स एसओ- बुराई को रोकना '

नेट पर कम से कम एक डेटा पैकेट शुरू करने वाली प्रत्येक फ़ाइल में rsync या scp परिणाम के माध्यम से व्यक्तिगत रूप से छोटी फ़ाइलों को सिंक्रनाइज़ करना। यदि फ़ाइल छोटा है और पैकेट कई हैं, तो इसके परिणामस्वरूप प्रोटोकॉल ओवरहेड बढ़ जाता है। अब गणना करें कि rsync प्रोटोकॉल के माध्यम से प्रत्येक फ़ाइल के लिए एक से अधिक डेटा पैकेट हैं (चेकसम स्थानांतरित करना, तुलना करना ...), प्रोटोकॉल ओवरहेड जल्दी बनाता है। एमटीयू के आकार पर विकिपीडिया

— टाटजाना हेसर

धन्यवाद @TatjanaHeuser - यदि आप इसे अपने उत्तर में जोड़ते हैं और इस दावे का समर्थन करने में कोई आपत्ति नहीं करते हैं कि rsync प्रति फ़ाइल कम से कम एक पैकेट का उपयोग करता है, तो मैं इसे स्वीकार करूंगा।

— एमिलियो वाज़केज़-रीना

मुझे एक दिलचस्प पढ़ने में पता चला कि scp और rsync के साथ देरी को अलग-अलग कारणों से दोषी ठहराया जाना है: मूल रूप से बताए गए तरीके से scp बर्ताव करना, लेकिन rsync ने हैंडलिंग के लिए बड़ी डेटा संरचनाओं के निर्माण की बढ़ी हुई कीमत पर नेटवर्क पेलोड का अनुकूलन किया। मैंने इसे अपने उत्तर में शामिल कर लिया है और इस सप्ताह के अंत में इसकी जांच करूंगा।

— टाटजाना हेसर

Answer 1

जब आप फ़ाइलों का एक ही सेट भेजते हैं, rsyncतो बेहतर अनुकूल होता है क्योंकि यह केवल अंतर भेजेगा। tarहमेशा सबकुछ भेजेगा और यह संसाधनों की बर्बादी है जब बहुत सारा डेटा पहले से है। tar + rsync + untarइस मामले में यह लाभ है, साथ ही साथ में-सिंक फ़ोल्डरों रखने का लाभ खो देता है rsync --delete।

यदि आप पहली बार फाइलों को कॉपी करते हैं, पहले पैकेटिंग करते हैं, फिर भेजते हैं, तो अनपैकिंग (AFAIK rsyncपाइप्ड इनपुट नहीं लेता है) बोझिल है और हमेशा सिर्फ rsyncing की तुलना में खराब है, क्योंकि वैसे भी rsyncकिसी भी कार्य को अधिक नहीं करना होगा tar।

युक्ति: rsync संस्करण 3 या बाद में वृद्धिशील पुनरावृत्ति होती है, जिसका अर्थ है कि यह सभी फ़ाइलों को गिनने से पहले लगभग तुरंत कॉपी करना शुरू कर देती है।

टिप 2: यदि आप rsyncअधिक उपयोग करते हैं ssh, तो आप भी उपयोग कर सकते हैंtar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

या केवल scp

scp -Cr srcdir user@server:destdir

सामान्य नियम, इसे सरल रखें।

अद्यतन करें:

मैंने 59M डेमो डेटा बनाया है

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

और दोनों तरीकों का उपयोग करके कई बार फ़ाइल को दूरस्थ सर्वर (एक ही लैन में नहीं) में स्थानांतरित किया गया

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

भेजे गए ट्रैफ़िक पैकेट से अलग लॉग रखते हुए

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

इस स्थिति में, मैं rsync + टार का उपयोग करके कम नेटवर्क ट्रैफ़िक में कोई लाभ नहीं देख सकता, जो कि अपेक्षित है जब डिफ़ॉल्ट mtu 1500 और जब फाइलें 10k आकार की हों। rsync + tar में अधिक ट्रैफ़िक उत्पन्न हुआ था, 2-3 सेकंड के लिए धीमा था और दो कचरा फ़ाइलों को छोड़ दिया गया था जिन्हें साफ करना था।

मैंने एक ही लैन पर दो मशीनों पर एक ही परीक्षण किया, और वहां rsync + tar ने बहुत बेहतर समय और बहुत कम नेटवर्क ट्रैफ़िक किया। मैं जंबो फ्रेम का कारण मानता हूं।

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

Comments

वास्तव में। "केवल वही आवश्यक है" एक महत्वपूर्ण पहलू है, हालांकि यह कभी-कभी अनियंत्रित हो सकता है, जिसे जानवर कहा जाता है rsync;)

— 0xC0000022L

BTW यदि आप zrsync के साथ ध्वज का उपयोग करते हैं तो यह कनेक्शन को संपीड़ित करेगा। आजकल हमारे पास सीपीयू की मात्रा के साथ, संपीड़न आपके द्वारा सेव किए जाने वाले बैंडविड्थ की मात्रा की तुलना में तुच्छ है, जो पाठ फ़ाइलों के लिए ~

— 1/10

@ पोपुलस, आप देखेंगे कि मैं अपने मूल उत्तर पर संपीड़न का उपयोग कर रहा हूं। हालाँकि बाद में मैंने जो परीक्षण किए, उनमें यह बात नहीं थी कि, उर्जेनम से डेटा बहुत कम नहीं होता है ... यदि बिल्कुल भी।

— फ़ोर्सफ़स्क

Answer 2

rsyncसंपीड़न भी करता है। -zझंडे का इस्तेमाल करें । यदि चल रहा है ssh, तो आप ssh के कम्प्रेशन मोड का भी उपयोग कर सकते हैं। मेरी भावना यह है कि बार-बार संपीड़न का स्तर उपयोगी नहीं है; यह सिर्फ महत्वपूर्ण परिणाम के बिना चक्र जला देगा। मैं rsyncसंपीड़न के साथ प्रयोग करने की सलाह दूंगा । यह काफी प्रभावी लगता है। और मैं सुझाव दूंगा कि आप tarया किसी अन्य प्री / पोस्ट कम्प्रेशन के उपयोग को छोड़ दें ।

मैं आमतौर पर rsync का उपयोग करता हूं rsync -abvz --partial...।

Comments

ध्यान दें कि rsyncडिफ़ॉल्ट रूप से .gzऔर कुछ .tgzअन्य सहित प्रत्यय के साथ फ़ाइलों को संकुचित करना ; खोज rsyncके लिए आदमी पेज --skip-compressपूरी सूची के लिए।

— वाइल्डकार्ड

Answer 3

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

पर्यावरण: एसएसडी हार्ड ड्राइव का उपयोग करके स्रोत मशीन i7 डेस्कटॉप। गंतव्य मशीन Synology NAS DS413j स्रोत मशीन के लिए एक गीगाबिट लैन कनेक्शन पर।

इसमें शामिल किट का सटीक नमूना स्वाभाविक रूप से प्रदर्शन को प्रभावित करेगा, और मैं प्रत्येक छोर पर नेटवर्क हार्डवेयर की गुणवत्ता के संबंध में मेरे सटीक सेटअप का विवरण नहीं जानता।

स्रोत फाइलें मेरी ~ / .cache फ़ोल्डर हैं जिसमें ज्यादातर बहुत छोटी फाइलों का 1.2Gb होता है।

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

मैंने केवल 1 ए और 1 बी को पूरी तरह से अलग चरणों के रूप में रखा ताकि केवल कार्य को चित्रित किया जा सके। व्यावहारिक अनुप्रयोगों के लिए, मैं सुझाव दूंगा कि रिसीवर पर एक अनगढ़ प्रक्रिया के लिए ssh के माध्यम से टार्स आउटपुट को शामिल करने से ऊपर गाइल्स ने क्या पोस्ट किया है।

समय:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

यह बहुत स्पष्ट है कि rsync ने एक टार ऑपरेशन की तुलना में आश्चर्यजनक रूप से खराब प्रदर्शन किया, जो संभवतः ऊपर वर्णित दोनों नेटवर्क के लिए जिम्मेदार ठहराया जा सकता है।

मैं ऐसे किसी भी व्यक्ति की सलाह दूंगा जो ज्यादातर छोटी फाइलों का बैकअप लेना चाहता हो, जैसे कि होम डाइरेक्टरी बैकअप, टार दृष्टिकोण का उपयोग करें। rsync बहुत खराब विकल्प लगता है। अगर मुझे लगता है कि मैं अपनी किसी भी प्रक्रिया में गलत हूँ, तो मैं इस पोस्ट पर वापस आऊंगा।

छेद

Comments

-zRsync का उपयोग सम्पीडन के बिना , यह परीक्षण अधूरा लगता है।

— वाइल्डकार्ड

अपने स्वयं के zतर्क के बिना टार , जैसा कि मैंने इसका उपयोग किया था, डेटा को संपीड़ित नहीं करता है (देखें unix.stackexchange.com/questions/127169/… ), जहां तक ​​मैं बिना संपीड़न के rsync का उपयोग करते हुए देख सकता हूं, एक निष्पक्ष तुलना है। अगर मैं bzip2 या gzip जैसी कम्प्रेशन लाइब्रेरी के माध्यम से टार आउटपुट पास कर रहा था, तो हाँ, -zसमझदार होगा।

— नेक

Answer 4

टार आर्काइव भेजने के लिए rsync का उपयोग करना, जैसा कि वास्तव में पूछा गया है कि यह बेकार या पुन: स्रोत होगा, क्योंकि आप प्रक्रिया में एक सत्यापन परत जोड़ देंगे। रुपेक्स सही होने के लिए टार फाइल को चेक करेगा, जब आपके पास व्यक्तिगत फाइलों पर चेक होगा। (यह जानने में मदद नहीं करता है कि टार फ़ाइल जो भेजने वाले पक्ष पर दोषपूर्ण हो सकती है, पहले से ही प्राप्त अंत पर समान प्रभाव दिखाती है)। यदि आप एक संग्रह भेज रहे हैं, ssh / scp आप सभी की जरूरत है।

संग्रह भेजने का चयन करने का एक कारण यह हो सकता है कि यदि आपकी पसंद का टार फाइल सिस्टम विशेष के अधिक संरक्षित करने में सक्षम था, जैसे कि एक्सेस कंट्रोल लिस्ट या अन्य मेटाडेटा अक्सर विस्तारित गुण (सोलारिस) या रेज़र प्रोक्स (MacOS) में संग्रहीत किया जाता है )। इस तरह की चीजों से निपटने के दौरान, आपकी मुख्य चिंता यह होगी कि कौन से उपकरण स्रोत फाइल सिस्टम पर फाइल से जुड़ी सभी सूचनाओं को संरक्षित करने में सक्षम हैं, बशर्ते लक्ष्य फाइलसिस्टम के साथ-साथ उन पर भी नजर रखने की क्षमता हो।

जब गति आपकी मुख्य चिंता है, तो यह आपकी फ़ाइलों के आकार पर बहुत कुछ निर्भर करता है। सामान्य तौर पर, छोटी फ़ाइलों की एक भीड़ rsync या scp पर बुरी तरह से स्केल हो जाएगी, क्योंकि सभी व्यक्तिगत नेटवर्क पैकेट प्रत्येक को बर्बाद कर देंगे, जहां एक टार फ़ाइल में एकल नेटवर्क पैकेट के डेटा लोड के भीतर उनमें से कई शामिल होंगे। यहां तक ​​कि अगर टार फ़ाइल संपीड़ित थी, तो भी बेहतर है क्योंकि छोटी फाइलें व्यक्तिगत रूप से समग्र रूप से बेहतर संपीड़ित करेंगी। जहाँ तक मुझे पता है, rsync और scp दोनों एक ही फाइल को प्रारंभिक हस्तांतरण में भेजते समय ऑप्टिमाइज़ करने में विफल हो जाते हैं, प्रत्येक फाइल के पास इसके पूरे प्रोटोकॉल ओवरहेड (और आगे और पीछे की जाँच करने पर अधिक बर्बाद) के साथ एक संपूर्ण डेटा फ़्रेम होता है। हालांकि जेनसेकयह केवल एससीपी के लिए सही है, यह बताता है कि rsync नेटवर्क ट्रैफ़िक का अनुकूलन करेगा लेकिन स्मृति में विशाल डेटा संरचनाओं के निर्माण की लागत पर। लेख कुशल फ़ाइल स्थानांतरण, जेनसेक 2006 देखें । तो उनके अनुसार यह अभी भी सच है कि छोटी फाइलों पर बुरी तरह से scp और rsync दोनों पैमाने हैं, लेकिन पूरी तरह से अलग कारणों से। लगता है कि मुझे इस सप्ताह के अंत में सूत्रों का पता लगाना होगा।

व्यावहारिक प्रासंगिकता के लिए, यदि आप जानते हैं कि आप ज्यादातर बड़ी फाइलें भेज रहे हैं, तो गति में बहुत अंतर नहीं होगा, और rsync का उपयोग करने से जोड़ा गया लाभ उठाया जा सकता है जहां बाधित होने पर इसे छोड़ दिया जाता है।

अनुलेख: इन दिनों, rdist oblivition में डूब रहा है, लेकिन rsync के दिनों से पहले, यह एक बहुत सक्षम उपकरण था और व्यापक रूप से इस्तेमाल (सुरक्षित रूप से जब अन्यथा, ssh पर इस्तेमाल किया असुरक्षित)। मैं rsync के रूप में उतना अच्छा प्रदर्शन नहीं करूंगा, क्योंकि यह सिर्फ उस सामग्री को स्थानांतरित करने के लिए अनुकूलित नहीं था जो बदल गई थी। Rsync में इसका मुख्य अंतर उस तरीके से निहित है जिस तरह से इसे कॉन्फ़िगर किया गया है, और फ़ाइलों को अपडेट करने के नियमों को कैसे वर्तनी दी गई है।

Comments

Rsync एक सत्यापन परत नहीं जोड़ता है। यह केवल मौजूदा फाइलों पर अंतर खोजने के लिए चेकसम का उपयोग करता है, न कि परिणाम को सत्यापित करने के लिए। ऐसे मामले में जहां कॉपी ताज़ा है, कोई चेकसम नहीं बनाया गया है। ऐसे मामले में जहां कॉपी ताज़ा नहीं है, चेकसम आपको बैंडविड्थ बचाते हैं।

— फोर्सफस्क

Answer 5

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

मैं वास्तव में के आंतरिक पता नहीं है rsync। क्या फ़ाइल आँकड़े कारण अंतराल पर निर्भर करता है कि rsyncडेटा कैसे स्थानांतरित होता है - यदि फ़ाइल आँकड़े एक-एक करके स्थानांतरित किए जाते हैं, तो RTT टार + rsync + अनटार अधिक तेज़ बना सकता है।

लेकिन अगर आपके पास डेटा का 1 GiB है, तो rsync तेजी से, अच्छी तरह से कहेगा, जब तक कि आपका कनेक्शन वास्तव में तेज न हो!

Answer 6

मुझे देश भर में कुछ टेराबाइट डेटा को स्थानांतरित करना था, ठीक एक बार। एक प्रयोग के रूप में, मैंने दो हस्तांतरणों का उपयोग करके भाग लिया rsyncऔर ssh/tarयह देखने के लिए कि वे कैसे तुलना करते हैं।

परिणाम:

• rsync औसतन 2.76 मेगाबाइट प्रति सेकंड की दर से फाइलों को हस्तांतरित किया।
• ssh/tar 4.18 मेगाबाइट प्रति सेकंड की औसत दर से फ़ाइलों को स्थानांतरित किया।

विवरण: मेरे डेटा में लाखों .gz संपीड़ित फ़ाइलें हैं, जिनका औसत आकार 10 मेगाबाइट है, लेकिन कुछ एक गीगाबाइट से अधिक हैं। एक निर्देशिका संरचना है, लेकिन यह फ़ाइलों के अंदर डेटा के आकार से बौना है। अगर मेरे पास करने के लिए लगभग कुछ और था, तो मैं केवल उपयोग करूंगा rsyncलेकिन इस मामले में, ssh/tarएक कार्यात्मक समाधान है।

मेरे काम में rsyncनिम्न शामिल हैं:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

जहाँ fileList.txt दूसरी तरफ फ़ाइलों के सापेक्ष पथनामों की एक बड़ी लंबी सूची है। (मैंने देखा कि --compressमैं शुरू होने के बाद संपीड़ित फ़ाइलों के लिए उत्पादक नहीं हूं लेकिन मैं फिर से शुरू करने वाला नहीं था।)

मैंने ssh और tar के साथ एक और शुरुआत की है:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

आप इस प्रतियों को सब कुछ देख लेंगे, क्षमा करें कि यह सेब की तुलना में 100% सेब नहीं है।

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

मध्यस्थ के माध्यम से एसएसएल कनेक्शन ~/.ssh/configप्रविष्टि के माध्यम से पूरा किया जाता है :

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Comments

अद्यतन: ssh / tar हस्तांतरण में छह घंटे, मेरी प्रणाली ने उस SAN डिवाइस से कनेक्शन को छोड़ने का फैसला किया जिसे मैं डेटा स्थानांतरित कर रहा था। अब मुझे यह पता लगाना है कि क्या स्थानांतरित किया गया था और क्या नहीं था, जो मैं शायद rsync के साथ करूंगा। कभी-कभी, यह समय बचाने के लिए खर्च करने के लिए आपके पास नहीं है।

— user1683793

Answer 7

यह समय:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"