क्या बड़ी फ़ाइलों (~ 20 GB) की प्रतिलिपि बनाने के लिए cp का एक तेज़ विकल्प है?


40

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

cpफाइलरवर से स्थानीय डिस्क में से एक ~ 20 जीबी फ़ाइल को कॉपी करने के लिए उपयोग करने से औसतन (के अनुसार time) वास्तविक समय में लगभग 11.5 मिनट लगते हैं । मुझे पता है कि यह cpऑपरेशन बहुत कुशल नहीं है क्योंकि (1) timeमुझे बताता है कि इस तरह की प्रति के लिए सिस्टम का समय केवल ~ 45 सेकंड है; और क्योंकि (2) जब मैं topकॉपी के दौरान जांच करता हूं , तो % CPU काफी कम है (निरीक्षण द्वारा, औसतन लगभग 0-10% )।

cpस्थानीय डिस्क पर एक फ़ोल्डर से एक ही 20 जीबी फ़ाइल को कॉपी करने के लिए उपयोग करके उसी स्थानीय डिस्क पर दूसरे फ़ोल्डर में कम समय लगता है - वास्तविक समय में लगभग 9 मिनट (सिस्टम समय के अनुसार ~ 51 सेकंड time)। तो जाहिर है, फाइलरवर स्थानीय डिस्क की तुलना में कुछ धीमा है, जैसा कि अपेक्षित है, लेकिन शायद काफी धीमा नहीं है। मुझे आश्चर्य है कि स्थानीय से एक ही स्थानीय में कॉपी करना 9 मिनट से अधिक तेज नहीं है।

मुझे ~ 200 बड़ी फ़ाइलों की प्रतिलिपि बनाने की आवश्यकता है - प्रत्येक ~ 20 जीबी - फाइलरवर से स्थानीय डिस्क में से एक में। तो, मेरा सवाल है: क्या cpलिनक्स में बड़ी फ़ाइलों की प्रतिलिपि बनाने के लिए एक तेज़ विकल्प है ? (या उसके भीतर कोई झंडे हैं cpजो मैं उपयोग कर सकता हूं जो नकल करने में तेजी लाएगा?) भले ही मैं किसी भी तरह इस नकल समय से एक मिनट दूर कर सकता हूं, इससे बहुत मदद मिलेगी।

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


29
यदि आप मुझसे पूछें तो यह लगभग 29MB / s है, जो बहुत तेज़ है। मुझे नहीं लगता कि ऐसा कोई कमांड है जो इसे गति देगा, "अड़चन" सबसे अधिक संभावना है कि नेटवर्क या बी) फ़ाइल-सर्वर।
tink

5
tink 100% सही है। मैंने कभी ऐसा कुछ नहीं देखा जो इसे बेहतर बना सके। केवल एक चीज जो मैंने अतीत में की है, उसे भेजने से पहले डेटा को संपीड़ित करना है, लेकिन इसका मतलब है कि आप संपीड़न चरण और विघटन चरणों के साथ समय जोड़ रहे हैं, लेकिन कभी-कभी इसके लायक है यदि डेटा एक अच्छा उम्मीदवार है दबा हुआ!
स्लम

3
आप यह भी कोशिश कर सकते हैं ddऔर rsyncतुलना करने के लिए कि कौन आपके पर्यावरण में तेजी से काम करता है
रजा

@ सैलटन धन्यवाद मैंने अभी तक कोशिश नहीं की है dd, लेकिन मैंने अभी कोशिश की है rsync। वास्तविक समय लगभग 11.5 मिनट था और सिस्टम का समय लगभग 1.5 मिनट था, तदनुसार time
एंड्रयू

2
मुझे आश्चर्य है कि किसी ने भी ध्यान नहीं दिया है कि स्थानीय डिस्क की स्थानीय डिस्क को कई डिस्क माउंट किए जाने से अधिक कुशल बनाया जा सकता है। से कॉपी किया जा रहा /dev/sda1करने के लिए /dev/sdb1पर एक स्थान से कॉपी करने से भी तेज होने जा रहा है /dev/sda1पर किसी अन्य स्थान पर /dev/sda1या पर एक और विभाजन /dev/sdaक्योंकि हार्ड ड्राइव अतिरिक्त चाहता है के बीच पढ़ता है और क्या करना है नहीं होगा राईट (डिस्क कताई और सिर घूम रहा है के साथ पारंपरिक हार्ड ड्राइव संभालने; SSD स्पष्ट रूप से अलग है)।
ट्रिपल जू 27'13

जवाबों:


53

कॉपी के दौरान % CPU कम होना चाहिए । सीपीयू डिस्क कंट्रोलर को "Z पर सेक्टर्स X- Y से मेमोरी बफर में डेटा हड़पता है" बताता है। फिर यह जाता है और कुछ और करता है (या नींद, अगर कुछ और नहीं है)। जब डेटा मेमोरी में होता है तो हार्डवेयर एक बाधा उत्पन्न करता है। तब सीपीयू को इसे कुछ बार कॉपी करना पड़ता है, और नेटवर्क कार्ड को "मेमोरी स्थानों ए, बी और सी पर संचारित पैकेट" बताता है। फिर यह कुछ और करने के लिए वापस चला जाता है।

आप ~ 240mbps पुश कर रहे हैं। एक गीगाबिट लैन पर, आपको कम से कम 800mbps करने में सक्षम होना चाहिए, लेकिन:

  1. फ़ाइल सर्वर का उपयोग करके सभी के बीच साझा किया जाता है (और संभवतः स्विच, आदि के बीच एक कनेक्शन)
  2. यह फ़ाइल सर्वर की गति को सीमित कर सकता है, इसकी डिस्क I / O बैंडविड्थ को ध्यान में रखते हुए, इसका उपयोग करके सभी को साझा किया जाता है।
  3. आपने निर्दिष्ट नहीं किया कि आप फ़ाइल सर्वर (NFS, CIFS (सांबा), AFS, आदि) का उपयोग कैसे कर रहे हैं। आपको अपने नेटवर्क माउंट को ट्यून करने की आवश्यकता हो सकती है, लेकिन हाल ही में कुछ भी हाल ही में चूक आमतौर पर बहुत समझदार हैं।

अड़चन पर नज़र रखने के लिए, iostat -kx 10एक उपयोगी कमांड बनने जा रहा है। यह आपको आपके स्थानीय हार्ड डिस्क पर उपयोग दिखाएगा। यदि आप फ़ाइल सर्वर पर उसे चला सकते हैं, तो यह आपको बताएगा कि फ़ाइल सर्वर कितना व्यस्त है।

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

  • यदि फ़ाइलें संपीड़ित हैं, और आपके पास एक तेज़ सीपीयू है, तो कम से कम -ऑन-द-फ्लाई करने से तेज हो सकता है। जैसे कुछ lzopया शायद gzip --fastest
  • यदि आप केवल कुछ बिट्स को इधर-उधर बदल रहे हैं, और फिर फाइल को वापस भेज रहे हैं, केवल डेल्टास भेजने से बहुत तेजी से होगा। दुर्भाग्य से, rsyncवास्तव में यहाँ मदद नहीं करेगा, क्योंकि डेल्टा को खोजने के लिए दोनों तरफ की फ़ाइल को पढ़ने की आवश्यकता होगी। इसके बजाय, आपको कुछ ऐसा चाहिए जो फ़ाइल बदलते ही डेल्टा पर नज़र रखता हो ... यहाँ पर अधिकांश दृष्टिकोण ऐप-विशिष्ट हैं। लेकिन यह संभव है कि आप कुछ नया कर सकते हैं, उदाहरण के लिए, डिवाइस-मैपर (एकदम नया डीएम-युग लक्ष्य देखें ) या ट्रॉफ़्स।
  • यदि आप एक ही डेटा को कई मशीनों में कॉपी कर रहे हैं, तो आप एक ही बार में सभी मशीनों को भेजने के लिए udpcast जैसी किसी चीज़ का उपयोग कर सकते हैं।

और, जब से आप ध्यान दें कि आप sysadmin नहीं हैं, मैं अनुमान लगा रहा हूं कि आपके पास एक sysadmin है। या फ़ाइल सर्वर और नेटवर्क के लिए कम से कम कोई जिम्मेदार है। आपको शायद उससे / उसके बारे में पूछना चाहिए, उन्हें आपके सेटअप की बारीकियों से अधिक परिचित होना चाहिए। आपका sysadmin (s) कम से कम आपको यह बताने में सक्षम होना चाहिए कि आप किस स्थानांतरण दर से यथोचित अपेक्षा कर सकते हैं।


Iostat -kx 10 :-) के लिए +1
n611x007

16

यह संभवतः, एक तेज विकल्प हो सकता है, और आप दो दिनों के लिए नेटवर्क बंद नहीं करेंगे: एक या दो बड़े यूएसबी (यूएसबी 3 यदि आपके पास है) या फायरवायर डिस्क लें, इसे सर्वर से कनेक्ट करें और फ़ाइलों को कॉपी करें डिस्क। डिस्क को अपने स्थानीय मशीन पर ले जाएं। मशीन में फाइल कॉपी करें।


23
स्नीकरनेट ( en.wikipedia.org/wiki/Sneakernet ) बहुत तेज हो सकता है: कभी भी हाईवे को नीचे गिराते हुए टेपों से भरे स्टेशन वैगन की बैंडविड्थ को कम न समझें।
स्प्लिंटररेलिटी

10

कुशल की आपकी परिभाषा पीछे की ओर है। एक अधिक कुशल कार्यान्वयन कम सीपीयू समय बर्बाद करता है। स्थानीय प्रतिलिपि पर आप लगभग 74 एमबी / सेकेंड के थ्रूपुट (रीड + राइट) के लिए औसत हैं, जो लगभग उतना ही अच्छा है जितना एक हार्ड डिस्क प्राप्त करने जा रहा है।


1
उफ़। जब मैंने कहा "कुशल," मेरा मतलब था "उपवास।"
एंड्रयू

10

यदि आपके पास प्रत्यक्ष SSH (या SFTP) पहुंच है (अपने sysadmin से पूछें), तो आप scpसंपीड़न ( -C) के साथ उपयोग कर सकते हैं :

scp -C you@server:/path/to/yourfile .

बेशक, यह केवल उपयोगी है यदि फ़ाइल संपीड़ित है, और यह अधिक सीपीयू समय का उपयोग करेगा, क्योंकि यह एन्क्रिप्शन का उपयोग करेगा (क्योंकि यह एसएसएच से अधिक है), और संपीड़ित करना।


इस मामले में, एन्क्रिप्शन को अक्षम करना उपयोगी होगा। याद रखें कि हम प्रतिलिपि बनाने के लिए कोशिश कर रहे हैं तेजी से
लार्जेट

3
@lgeorget मुझे संदेह है कि एन्क्रिप्शन का ओवरहेड महत्वपूर्ण नहीं होगा, यह देखते हुए कि हार्ड ड्राइव कितनी धीमी है। मैंने कुछ के बारे में जोड़ने पर विचार किया -c none, लेकिन यह गैर-मानक प्रतीत होता है
मोनिका

1
हम ~ 20G फ़ाइलों के साथ हैं निपटने तो यह है सुंदर एन्क्रिप्शन का उपयोग करने के लिए यदि आवश्यक हो तो नहीं अक्षम।
लार्जेट

1
@lgeorget एन्क्रिप्शन वह प्राप्त कर रहे थ्रूपुट की तुलना में बहुत तेजी से किया जा सकता है, इसलिए यह कुछ भी धीमा नहीं करेगा। लेकिन यहाँ SSH के माध्यम से जाना अनावश्यक प्रतीत होता है। यदि आपको सिर्फ संपीड़न की आवश्यकता है तो निश्चित रूप से अन्य उपकरण हैं?
थॉमस

@ थोमस SSH का लाभ यह है कि यदि आपको दूरस्थ सर्वर तक पहुँच प्राप्त करनी है, तो यह लगभग निश्चित रूप से SSH चल रहा है। एक अन्य विकल्प यह होगा कि फ़ाइल को स्थानीय रूप से संपीड़ित करें, इसे सर्वर पर कॉपी करें, sshऔर फिर इसे
डिकम्प्रेस करें

8

cpकार्यान्वयन सबसे अधिक संभावना एक टोंटी नहीं है। iotopसर्वर और क्लस्टर नोड दोनों पर IO के उपयोग को देखने का प्रयास करें । यह आपको एक विचार देगा जहां आप प्रदर्शन में सुधार कर सकते हैं।

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

यदि उस 20G फ़ाइलों के भीतर, कुछ हिस्सा सामान्य है, और कुछ क्लस्टर नोड विशिष्ट हैं, तो इसे सामान्य और विशिष्ट भागों में विभाजित करने पर विचार करें, और फिर P2p तरीके से सामान्य भाग वितरित करें।


1
यदि आप एक लैन पर हैं, तो आपको पीयर-टू-पीयर के बजाय मल्टीकास्ट करने में सक्षम होना चाहिए। जो नेटवर्क पर तेज, और कम लोड होना चाहिए।
derobert

8

उन फ़ाइलों की प्रकृति / सामग्री कुछ अंतर ला सकती है। मैं समझ गया कि आपको एक कंप्यूटर से दूसरे कंप्यूटर में 200 फाइलें, ~ 20 जीबी प्रत्येक कॉपी करने की आवश्यकता है, क्या यह है?

यदि वे फ़ाइलें संपीड़ित हैं या समान / समान टुकड़ों के साथ, आपके पास दो दृष्टिकोण हैं:

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

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

संपादित करें

क्या आपको उन फ़ाइलों को कई बार कॉपी करने की आवश्यकता होगी ?? (जैसे एक प्रति -> उन फ़ाइलों का उपयोग करें -> कंप्यूटर में फ़ाइलों में कुछ को बदल दें A -> कॉपी फ़ाइलों को फिर से कंप्यूटर बी में)

यदि ऐसा है, तो rsync सहायक होगा, क्योंकि यह पता लगाने की कोशिश करेगा कि संस्करणों में क्या समान है और जो अपरिवर्तित है उसे कॉपी न करें।

और एक तीसरी विधि: यदि उपरोक्त सही है (फ़ाइल में परिवर्तन, तो सभी फ़ाइलों को फिर से दूसरे कंप्यूटर पर कॉपी करें) आप दूसरे कंप्यूटर में binary diffसिर्फ कंप्यूटर में जो कुछ बदला था उसे बदलने की कोशिश कर सकते हैं।


6

मैं यहाँ नीचे देख रहा हूँ, एन्क्रिप्शन एक अच्छा विचार नहीं है क्योंकि यह संभवतः हस्तांतरित किए जाने वाले डेटा की मात्रा बढ़ा सकता है।

यदि आप दो प्रणालियों के बीच नकल कर रहे हैं, तो टोंटी निश्चित रूप से सर्वरों के बीच संबंध है।

यदि आप स्थानीय रूप से कॉपी कर रहे हैं, तो देखें कि प्रक्रिया कैसे चलती है, यह सिंगल थ्रेडेड है, इस प्रकार मानक लिनक्स उपयोगिताओं का उपयोग करते हैं:

- for all blocks in a file
      read a block
      write a block

इस ऑपरेशन के लिए कोई सहमति नहीं है।

चीजों को गति देने के लिए आप कुछ इस तरह का उपयोग कर सकते हैं:

  buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte

अधिक जानकारी के लिए बफर (1) मैन पेज देखें।

बफ़र आदेश प्रतिलिपि प्रक्रिया को समवर्ती रूप से चलाने के लिए दो प्रक्रियाएँ सेट करता है: एक पढ़ने के लिए, और दूसरा लेखन के लिए, और यह दो प्रक्रियाओं के बीच डेटा को संप्रेषित करने के लिए एक साझा मेमोरी बफर का उपयोग करता है। साझा मेमोरी बफर आपका क्लासिक सर्कुलर बफर है जो अलिखित डेटा को ओवरराइट करने और पहले से लिखे गए डेटा को लिखने से रोकता है। मैंने इस कार्यक्रम का उपयोग डिस्क से टेप में स्थानांतरण में प्रतिलिपि समय के लगभग 10-20% को काटने के लिए किया है।


असल में, "एक ब्लॉक पढ़ने / एक ब्लॉक लिखने" में संगामिति है, क्योंकि "एक ब्लॉक लिखें" वास्तव में बस इसे कर्नेल के बफर में डालता है, और कर्नेल वास्तविक ब्लॉक राइट को पृष्ठभूमि में लिखता है (कम से कम, जब तक आप बाहर चलना शुरू नहीं करते हैं राम की)। या यदि आप किसी कारण से O_DSYNC / O_SYNC का उपयोग कर रहे हैं।
व्युत्पन्न

3

पी 2 पी प्रसार एल्गोरिथ्म की कोशिश क्यों न करें, यदि आपको एक ही समय में अपने पूरे क्लस्टर को अपडेट करने की आवश्यकता है?

https://github.com/lg/murder वह है जो ट्विटर उपयोग करता है

नहीं है BTSync है कि आप के रूप में अच्छी कोशिश कर सकते हैं।


1

यदि आप अपने स्थानीय कंप्यूटर से सर्वर पर फ़ाइलों के समान सेट को बार-बार यहां और वहां मामूली बदलाव के साथ सर्वर पर कॉपी कर रहे हैं। आप rsync या DVCS (जैसे hg या git) का उपयोग करके स्थानांतरण को गति दे सकते हैं।

git या hg ट्रैक रख सकते हैं और डेल्टास का पता लगा सकते हैं और केवल उन डेल्टास को स्थानांतरित कर सकते हैं। गिट का उपयोग करने के मामले में, चूंकि दोनों पक्षों के पास भंडार का पूरा इतिहास है, इसलिए यह पता लगाना कि डेल्टा बहुत सस्ता है।

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


1

आप सभी फ़ाइलों को एकल संग्रह में पैक करने का प्रयास कर सकते हैं (संकुचित होने की आवश्यकता नहीं है)। मेरे अनुभव में, एक संग्रह की नकल करना बड़ी संख्या में व्यक्तिगत फ़ाइलों की प्रतिलिपि बनाने से तेज है


3
अच्छा सामान्य अवलोकन, लेकिन जैसा कि सवाल कहता है "~ 200 बड़ी फाइलें - प्रत्येक ~ 20 जीबी", मेरा मानना ​​है कि यह इस समस्या का एक वास्तविक जवाब माना जा सकता है।
मैनटवर्क

@manatwork आह .. मैं स्पष्ट रूप से पढ़ा नहीं था। मुझे लगा कि उनके पास 200 फाइलें हैं जो कुल 20gb हैं
मुनीम

0

Bbcp को आज़माएं । हमारे वातावरण में परीक्षण से पता चला है कि cp में कुछ प्रकार के निर्मित गवर्नर थे। बस सावधान रहें क्योंकि जब आप गवर्नर को उतारते हैं, तो आप अपने सर्वर को लाल-लाइन कर सकते हैं और आक्रोश पैदा कर सकते हैं। हमारे मामले में हम सर्वर को कॉपी करने के लिए ऑफ़लाइन ले जा रहे थे, इसलिए तेजी से बेहतर था। इससे स्थानांतरण का समय कई घंटे सुधरा।


0

सुनिश्चित करें कि प्रतिलिपि बनाने से पहले लक्ष्य फ़ाइलें मौजूद नहीं हैं।

कभी-कभी आश्चर्य होता है कि एक ही मेजबान (कोई भी नेटवर्क शामिल नहीं) पर कॉपी करने में भी कितना समय लगता है।

देखें एक और सीपी प्रश्न यहाँ करने के लिए अपने जवाब । लंबी कहानी छोटी, एक मौजूदा फ़ाइल को ओवरराइट करना, इसे छोटा करने या पहले अनलिंक करने की तुलना में बहुत धीमा है, और फिर कॉपी करना। बाद वाला 1.2x फ़ाइल के लिए 8x तेज़ है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.