Restic: पुनर्स्थापना और भी तेज़ हो सकती है

160mbit/sec वास्तव में धीमा दिखता है। मुझे एक मैकबुक प्रो पर एक ड्राइव ओवर (तेजी से दी गई) 1 जीबीपीएस फीट कनेक्शन से डाउनलोड करने पर 200 एमबीपीएस के करीब मिल रहा था। मैं वास्तव में आपके सिस्टम और भंडार तक पहुंच के बिना कुछ भी विशिष्ट नहीं कह सकता, लेकिन यहां कुछ चीजें हैं जिन्हें मैं समस्या को कम करना चाहता हूं, किसी विशेष क्रम में:

• सिंगल थ्रेड पर सिंगल पैक फ़ाइल को डाउनलोड करने में लगने वाले समय का अनुमान लगाएं। आप अपने rclone 32x डाउनलोड टेस्ट से इसकी गणना कर सकते हैं, लेकिन मुझे कर्ल के साथ अलग-अलग पैक डाउनलोड करने का समय जानने के लिए भी उत्सुकता होगी ताकि हम http अनुरोध ओवरहेड का भी अनुमान लगा सकें।
• मैं OS आँकड़ों की जाँच करूँगा कि पुनर्स्थापना के दौरान S3 से वास्तव में कितना रेस्टिक डाउनलोड होता है। यह हमें बताएगा कि क्या डाउनलोड अलग-अलग पैक फ़ाइलों को कई बार पुनर्स्थापित करता है (जो संभव है, लेकिन बहुत बार नहीं होना चाहिए, जब तक कि मैंने कुछ अनदेखा नहीं किया)।
• S3 संगामिति स्तर केवल 5 कनेक्शनों तक सीमित प्रतीत होता है। क्या यह ऊपर से दिए गए सिंगल-थ्रेडेड स्पीड अनुमान के अनुसार आपके द्वारा देखी जाने वाली पुनर्स्थापना गति की व्याख्या कर सकता है? यदि आप S3 बैकएंड कनेक्शन की सीमा को पुनर्स्थापक से मिलान करने के लिए बढ़ाते हैं तो क्या होगा?
• यह देखने के लिए कि क्या कोई अंतराल या धीमापन है, पुनर्स्थापना के दौरान ग्राफ़ नेटवर्क उपयोग।
• उस 364GB फ़ाइल को पुनर्स्थापना से बाहर निकालें और देखें कि क्या होता है। व्यक्तिगत फ़ाइलें वर्तमान में क्रमिक रूप से पुनर्स्थापित की जाती हैं, इसलिए यह एक फ़ाइल औसत डाउनलोड गति को महत्वपूर्ण रूप से कम कर सकती है।

नमस्ते!

उत्तर के लिए धन्यवाद। यह खोदना दिलचस्प था

tl; dr: s3 कनेक्शन को ऊपर उठाना महत्वपूर्ण है, लेकिन यह जो प्रदर्शन प्रदान करता है वह अस्थायी है, अजीब तरह से।

1. एकल निर्देशिका के मूल्य के पैक (3062 फ़ाइलें कुल 13GB) को स्थानांतरित करना / rclone --transfers 1 के साथ 233mbit/sec पर चलता है। lsof के साथ पुष्टि की गई कि यह केवल एक थ्रेड और उस मोड में एक एकल https कनेक्शन के साथ चल रहा है। चरम गति --transfers 32 (8.5 gbit/sec, अनिवार्य रूप से इस i3.8xlarge ec2 उदाहरण के लिए लाइन गति) के साथ प्राप्त की जाती है। दोनों ही मामलों में हम स्ट्राइप्ड nvme ऐरे को लिख रहे हैं।
2. कुछ आँकड़े एकत्रित करने में प्रसन्नता हो रही है, लेकिन आप विशेष रूप से क्या देखना चाहेंगे? (लेकिन इसकी आवश्यकता नहीं हो सकती है, कृपया नीचे देखें)
3. यहां एक पत्थर से दो पक्षियों को मारने जा रहे हैं! यहां पुनर्स्थापना के दौरान नेटवर्क उपयोग

• इस पीआर विलय के साथ स्टॉक स्टॉक रेस्टिक (कमिट c0572ca15f946c622d9c4009347dc4d6c31cba4c)
• वर्करकाउंट के साथ रेस्टिक 32 पर पहुंच गया और फाइलवाइटरकाउंट 128 पर पहुंच गया
• पिछले परिवर्तनों के साथ रेस्टिक + s3 कनेक्शन बढ़कर 32 हो गए।
• पिछले परिवर्तनों के साथ resitc + s3 कनेक्शन बढ़कर 64 हो गए।
• rclone --transfers 32 के साथ डेटा/निर्देशिका को स्थानांतरित करना

बैंडविड्थ संख्या केबीपीएस में है और 10 मिनट में 3 सेकंड के अंतराल पर ली गई थी। रेस्टिक रन के लिए, हमने डेटा एकत्र करना शुरू कर दिया था _after_ रेस्टिक ने वास्तव में फाइलों को पुनर्स्थापित करना शुरू कर दिया था (यानी, इसमें स्टार्टअप समय और वह समय शामिल नहीं है जो रेस्टिक ने डायरेक्टरी पदानुक्रम को फिर से बनाने के लिए रन की शुरुआत में खर्च किया। सभी रनों के दौरान, सीपीयू का उपयोग उदाहरण 25% से अधिक नहीं था।

हमें वर्करकाउंट बढ़ाने से थोड़ी टक्कर मिलती है, लेकिन S3 कंसीडर ऐसा दिखता है जहां असली जीत है। लेकिन जब यह मजबूत शुरू होता है (कभी-कभी rclone गति के करीब!), दरें अचानक गिर जाती हैं और बाकी दौड़ के लिए नीचे रहती हैं। रेस्टिक भी त्रुटियों को फेंकता है जो "[पथ redacted] के लिए त्रुटि को अनदेखा कर रहा है: पर्याप्त कैश क्षमता नहीं: 2148380 का अनुरोध किया गया, 872640 उपलब्ध है" कि यह कम एस 3 समरूपता के साथ नहीं फेंकता है।

जैसा कि आप देख सकते हैं, rclone प्रदर्शन उच्च शुरू होता है और उच्च रहता है, इसलिए यह ऐसी स्थिति नहीं है जहां लेखन इंस्टेंस के बफर कैश में जा रहे हैं और जब वे डिस्क पर फ़्लश हो जाते हैं तो रुक जाते हैं। nvme सरणी नेटवर्क पाइप, थ्रूपुट-वार से तेज है।

1. मुझे नहीं लगता कि एकल बड़ी फ़ाइल एक कारक है, क्योंकि मैं पुनर्स्थापना के दौरान डिस्क/नेटवर्क IO को माप रहा हूं, इसलिए तथ्य यह है कि उस एकल फ़ाइल को पूरी तरह से पुनर्स्थापित करने में कुछ समय लग सकता है, हम संख्याओं को प्रभावित नहीं करेंगे यहाँ देख रहे हैं।

उपरोक्त को देखते हुए, ऐसा लगता है कि S3 समरूपता को बढ़ाने के लिए यहां उचित दर प्राप्त करने की आवश्यकता है, लेकिन यह पता लगाने की आवश्यकता है कि प्रदर्शन क्यों गिर रहा है (और यह कैश त्रुटियों से संबंधित है या नहीं)।

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

1. 233mbit/sec गुना 32 7456 है और 8.5 gbit/sec से काफी कम है। जो अजीब है। मुझे उम्मीद थी कि सिंगल-थ्रेडेड डाउनलोड मल्टी-थ्रेडेड डाउनलोड के प्रति-स्ट्रीम थ्रूपुट से तेज होगा। सुनिश्चित नहीं है कि इसका क्या मतलब है, हालांकि, अगर कुछ भी।

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

3. क्या आप ग्राफ पैमाने की पुष्टि कर सकते हैं? rclone "1000000" के रूप में लेबल की गई रेखा के चारों ओर मंडराता है, यदि वह "1,000,000 kbps" है, जो मुझे लगता है कि "1gbps" का अर्थ है और आपके द्वारा पहले उल्लेखित "8.5 gbit/sec" संख्या के साथ संरेखित नहीं है।

4. जैसा मैंने कहा, अलग-अलग फाइलों को क्रमिक रूप से बहाल किया जाता है। 233mbit/s पर 364 GB डाउनलोड में लगभग 3.5 घंटे लगेंगे, और संभवत: प्रति-पैक ओवरहेड और डिक्रिप्शन के कारण अधिक समय लगेगा, जो सभी क्रमिक रूप से होता है। यह नहीं बता सकता कि क्या 3.5 घंटे कुछ ऐसा है जिसे आप बिना यह जाने कि बाकी की पुनर्स्थापना में कितना समय लगता है, इसे महत्वहीन के रूप में त्याग सकते हैं।

not enough cache capacity त्रुटि के लिए, अपने भंडार में सबसे बड़ी पैक फ़ाइल के आकार में औसत पैक आकार बढ़ाएं (यह कितना बड़ा है, बीटीडब्ल्यू?) और मुझे यह सोचने की ज़रूरत है कि कैश को बेहतर तरीके से कैसे आकार दिया जाए, तैयार नहीं है उत्तर अभी तक।

नमस्ते!

वूप्स, आई एम सॉरी। ग्राफ़ में पैमाना KB/सेकंड kbit/sec नहीं है। तो पहली पंक्ति में 1,012,995 8.1gbit/sec है।

मैं समझ गया था कि फ़ाइलों को क्रमिक रूप से पुनर्स्थापित किया गया था, लेकिन यह नहीं समझा कि एक फ़ाइल के लिए पैक पुनर्प्राप्ति के लिए कोई समानता नहीं है। बड़ी फ़ाइलों के साथ बैकअप के लिए यह निश्चित रूप से एक ठोकर है, क्योंकि यह आपका सीमित कारक बन जाता है। उस कारण से यहाँ कुछ समानता होना शानदार होगा।

10 रैंडम बकेट का नमूना लेते हुए, हमारा अधिकतम पैक आकार 12MB से ठीक नीचे है और हमारा औसत पैक आकार 4.3MB है।

शायद अधिक श्रमिकों और S3 कनेक्शन के साथ, हम (workerCount + 5) * औसतपैकसाइज़ की packCacheCapacity को पार कर रहे हैं। मैं इसे ऊपर उठाने की कोशिश करूंगा और देख सकता हूं कि त्रुटियां दूर हो जाती हैं या नहीं।

शायद अधिक श्रमिकों और S3 कनेक्शन के साथ, हम (workerCount + 5) * औसतपैकसाइज़ की packCacheCapacity को पार कर रहे हैं। मैं इसे ऊपर उठाने की कोशिश करूंगा और देख सकता हूं कि त्रुटियां दूर हो जाती हैं या नहीं।

कैश आकार की गणना 5MB पैक फ़ाइल आकार और workerCount आधार पर की जाती है। workerCount बढ़ाने से कैश का आकार बढ़ जाता है। तो या तो स्मृति रिसाव है या शुद्ध संयोग से कई 12MB फ़ाइलों को कैश करने की आवश्यकता है। averagePackSize को 12MB तक

औसतपैकसाइज़ के साथ कोई कैश त्रुटियाँ 12 पर सेट नहीं हैं।

अगर कोई अन्य जानकारी है जो हम प्रदान कर सकते हैं जो सहायक होगी, तो मुझे बताएं! एक बार फिर धन्यवाद।

ऐसा लगता है कि हम समानता खो रहे हैं क्योंकि पुनर्स्थापना आगे बढ़ रही है और यह बड़ी फ़ाइलों से संबंधित नहीं लगती है। मैं एक परीक्षण मामला एक साथ रखूंगा और वापस रिपोर्ट करूंगा।

नमस्ते!

मैंने अपने उत्पादन फ़ाइल मिश्रण के साथ तीन अलग-अलग कृत्रिम फ़ाइल मिश्रणों के साथ प्रदर्शन ड्रॉप ऑफ को पुन: पेश करने का प्रयास किया।

सभी परीक्षणों के लिए, मैंने c0572ca15f946c622d9c4009347dc4d6c31cba4c का उपयोग S3 कनेक्शन के साथ 128 तक बढ़ाया, वर्करकाउंट 128 तक बढ़ गया, फाइलवाइटरकाउंट 128 तक बढ़ गया और औसतपैकसाइज 12 * 1024 * 1024 तक बढ़ गया।

डुप्लीकेशन के किसी भी प्रभाव से बचने के लिए सभी परीक्षणों में यादृच्छिक डेटा वाली फ़ाइलों का उपयोग किया गया।

पहले परीक्षण के लिए, मैंने 4,000 100 एमबी फाइलें बनाई और उनका बैकअप लिया, 100 निर्देशिकाओं (~ 400 जीबी कुल) में समान रूप से विभाजित। बैकअप और पुनर्स्थापना को i3.8xबड़ा उदाहरण पर स्ट्राइप्ड nvme वॉल्यूम से चलाया गया था। बैकअप बकेट इंस्टेंस (us-west-1) के समान क्षेत्र में स्थित था।

इस फ़ाइल मिश्रण के साथ, मैंने 9.7gbit/sec (!) की औसत गति देखी, जिसमें पूर्ण पुनर्स्थापना के दौरान समानता या गति का कोई नुकसान नहीं हुआ। ये नंबर rclone नंबरों के बराबर या उससे ऊपर हैं और अनिवार्य रूप से लाइन स्पीड हैं, जो शानदार है।

मैंने बाद में 400,000 1MB फ़ाइलों का निर्माण और बैकअप लिया, 100 निर्देशिकाओं में समान रूप से विभाजित किया (फिर से, ~ 400GB कुल)।

उपरोक्त के समान (उत्कृष्ट) परिणाम।

अंत में, मैंने प्रति निर्देशिका 1 10GB फ़ाइल के साथ 40 निर्देशिकाएँ बनाईं। इधर, चीजें दिलचस्प हो गईं।

मुझे उम्मीद थी कि यह पुनर्स्थापना थोड़ी धीमी होगी, क्योंकि रेस्टिक केवल 40 कनेक्शन के साथ S3 के साथ 40 एक साथ पुनर्स्थापना करने में सक्षम होगा।

इसके बजाय, हालांकि, जबकि रेस्टिक एक साथ सभी 40 फाइलों को लिखने और लिखने के लिए सभी 40 फाइलें खोलता है, यह केवल एक समय में S3 के लिए एक ही टीसीपी कनेक्शन खुला रखता है, 40 नहीं।

मुझे बताएं कि आप कौन से आंकड़े या उपकरण देखना चाहते हैं।

क्या आप पुष्टि कर सकते हैं कि "तेज़" परीक्षणों के दौरान 128 S3 कनेक्शन थे?

हाँ वहाँ थे।

जिज्ञासु... ईमानदार होने के लिए मेरी प्राथमिकता सूची में बड़ी फ़ाइल समर्थन अधिक नहीं है, लेकिन मुझे अगले कुछ हफ्तों में इसे देखने के लिए कुछ समय मिल सकता है। अगर कोई मेरे करने से पहले इसमें खुदाई करना चाहता है, तो कृपया मुझे बताएं।

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

4 निर्देशिकाओं में 128 10 एमबी फाइलों के साथ, रेस्टिक केवल एडब्ल्यूएस के लिए 6 कनेक्शन खोलता है, भले ही यह सभी 128 फाइलों को लिख रहा हो।

Wtih 512 10 एमबी फाइलें 4 निर्देशिकाओं में, रेस्टिक अपने जीवनकाल में 18 कनेक्शन खोलता है, भले ही इसमें एक बार में 128 फाइलें खुली हों।

4 निर्देशिकाओं में 5,120 10 एमबी फाइलों के साथ, रेस्टिक अपने जीवनकाल में एडब्ल्यूएस के लिए केवल 75 कनेक्शन खोलता है, एक बार में फिर से 128 फाइलें खोलता है।

अजीब!

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

वर्तमान समवर्ती पुनर्स्थापक के दो गुण हैं जो कार्यान्वयन जटिलता के थोक के लिए जिम्मेदार हैं और बहुत संभावित रूप से यहां रिपोर्ट की गई मंदी का कारण हैं:

• अलग-अलग फाइलों को स्टार्ट-टू-फिनिश बहाल किया जाता है
• इन-प्रोग्रेस फाइलों की संख्या न्यूनतम रखी जाती है

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

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

@ fd0 क्या आपको लगता है कि वर्तमान स्टार्ट-टू-फिनिश पुनर्स्थापना में सुधार करना उचित है? व्यक्तिगत रूप से, मैं यह स्वीकार करने के लिए तैयार हूं कि यह मेरी ओर से इंजीनियरिंग से अधिक था और यदि आप सहमत हैं तो सरल आउट-ऑफ-ऑर्डर कार्यान्वयन प्रदान कर सकते हैं।

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

@ifedorenko मैं व्यक्तिगत रूप से सरलीकरण के पक्ष में हूं, आम तौर पर, खासकर अगर यह प्रदर्शन को बढ़ावा देने के साथ आता है। मैं हालांकि ट्रेडऑफ को समझने की कोशिश कर रहा हूं:

नकारात्मक पक्ष, यह बताना संभव नहीं होगा कि किसी भी फ़ाइल में पुनर्स्थापना के अंत तक कितना डेटा पहले से ही पुनर्स्थापित किया गया था।

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

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

मुझे नहीं लगता कि यह करता है - यह सुनिश्चित नहीं है कि यह वैसे भी कैसे काम करेगा, क्योंकि पुनर्स्थापित कई फाइलें हैं, आपको उन्हें किसी भी तरह एन्कोड करना होगा और उन्हें किसी भी तरह से अलग करना होगा।

अगर हम यहां हजारों समवर्ती-लिखित फाइलों की बात नहीं कर रहे हैं, तो शायद बाइट्स के लिए फ़ाइल नाम का नक्शा लिखा जा सकता है?

अलग-अलग ब्लॉब्स लिखने के लिए फाइलों को खोलना और बंद करना सबसे आसान कार्यान्वयन है। यदि यह बहुत धीमा साबित होता है, तो हमें कई ब्लॉब राइट्स के लिए फाइलों को खुला रखने का एक तरीका खोजना होगा, उदाहरण के लिए ओपन फाइल हैंडल को कैशिंग करके और पहले से खुली फाइलों के पक्ष में पैक डाउनलोड का आदेश देना।

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

और बाधित होने वाले पुनर्स्थापना को फिर से शुरू करने के लिए, शायद गैर-शून्य बाइट्स के लिए फ़ाइल के ब्लॉब्स और ऑफ़सेट की जांच कर रहे हैं, शायद?

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

@pmkane आश्चर्य है कि क्या आप # 2101 कोशिश कर सकते हैं? यह आउट-ऑफ-ऑर्डर रिस्टोर को लागू करता है, हालांकि अलग-अलग फाइलों को लिखना अभी भी क्रमबद्ध है और बड़ी फाइलों का रिस्टोर परफॉर्मेंस अभी भी उप-इष्टतम हो सकता है। और आपको पहले की तरह श्रमिकों की संख्या में बदलाव करने की आवश्यकता है।

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

@ifedorenko मैंने इस पीआर की कोशिश की और यह

भार(, 3172070, 0) त्रुटि लौटाई, 12.182749645 के बाद पुन: प्रयास करना: ईओएफ

मास्टर ठीक पुनर्स्थापित करता है।

मेरा पुनर्स्थापना आदेश है:

/usr/local/bin/restic.outoforder -r s3:s3.amazonaws.com/[redacted] -p /root/.restic_pass restore [snapshotid] -t।

मुझे बताएं कि डीबग करने में सहायता के लिए मैं कौन सी अतिरिक्त जानकारी प्रदान कर सकता हूं।

आप कितने समवर्ती S3 डाउनलोड अनुरोधों की अनुमति देते हैं? अगर यह 128 है, तो क्या आप इसे 32 तक सीमित कर सकते हैं (जिसे हम जानते हैं काम करता है)?

अर्ध-संबंधित ... क्या आप जानते हैं कि आपके वास्तविक भंडार में कितनी अनुक्रमणिका फ़ाइलें हैं? यह अनुमान लगाने की कोशिश की जा रही है कि कितनी मेमोरी रिस्टोरर की जरूरत है।

मैंने कनेक्शन सीमा निर्दिष्ट नहीं की, इसलिए मुझे लगता है कि यह डिफ़ॉल्ट रूप से 5 था।

मुझे -o s3.connections=2 और -o s3.connections=1 के साथ समान त्रुटियां मिलती हैं।

मेरे पास वर्तमान में इंडेक्स/फोल्डर में 85 इंडेक्स ब्लॉब्स हैं। वे कुल आकार में 745MB हैं।

हम्म। जब मैं आज बाद में अपने कंप्यूटर पर पहुंचूंगा तो मेरी एक और नज़र होगी। बीटीडब्ल्यू, "लौटाई गई त्रुटि, पुनः प्रयास करना" एक चेतावनी है, त्रुटि नहीं, इसलिए यह पुनर्स्थापना विफलता से संबंधित हो सकता है या यह सिर्फ एक लाल हेरिंग हो सकता है।

सुनिश्चित नहीं है कि मैंने इसे कैसे याद किया ... पुनर्स्थापक ने ज्यादातर मामलों में बैकएंड से सभी पैक फ़ाइलों को पूरी तरह से नहीं पढ़ा। अब ठीक किया जाना चाहिए। @pmkane क्या आप फिर से अपना परीक्षण कर सकते हैं?

मैं इसे एक चक्कर दूंगा!

पुष्टि की कि फ़ाइलें इस फिक्स के साथ सफलतापूर्वक पुनर्स्थापित हो जाती हैं। अब परीक्षण प्रदर्शन।

दुर्भाग्य से ऐसा लगता है कि यह मास्टर से धीमा है। सभी परीक्षण ऊपर वर्णित i3.8xlarge उदाहरण पर चलते हैं।

वर्करकाउंट 8 (डिफ़ॉल्ट) के साथ, आउट ऑफ ऑर्डर शाखा 86mbit/sec पर बहाल हो गई।

एक वर्करकाउंट के साथ 32 से टकराकर, इसने थोड़ा बेहतर किया - औसतन 160mbit/sec।

इस शाखा के साथ सीपीयू का उपयोग मास्टर की तुलना में काफी अधिक है, लेकिन यह किसी भी मामले में सीपीयू के उदाहरण को अधिकतम नहीं कर रहा है।

अनजाने में, पुनर्स्थापना UI ऐसा लगता है जैसे कुछ "चिपका हुआ" है, लगभग ऐसा लगता है जैसे यह कहीं लॉक के लिए प्रतिस्पर्धा कर रहा है।

अधिक विवरण, प्रोफाइलिंग या दोहराने के लिए एक परीक्षण उदाहरण प्रदान करने में प्रसन्नता हो रही है।

बस पुष्टि करने के लिए, आपके पास पुनर्स्थापक और s3 बैकएंड कार्यकर्ता दोनों की संख्या 32 पर सेट थी, है ना?

कुछ विचार जो आपके द्वारा देखे गए व्यवहार की व्याख्या कर सकते हैं:

• अलग-अलग फाइलों को लिखना अभी भी क्रमबद्ध है। मुझे लगता है कि यह तेज़ लक्ष्य फ़ाइल सिस्टम के साथ कोई समस्या नहीं होगी, लेकिन इसे कभी मापा नहीं गया।
• प्रत्येक ब्लॉब के आस-पास फ़ाइल खोलना/बंद करना निश्चित रूप से पुनर्स्थापक ओवरहेड में योगदान देता है। जब मैंने इसे मैकोज़ पर मापा तो मैं ~ 70 सेकेंड में 100K बार "फ़ाइल खोलें; एक बाइट लिखें; फ़ाइल बंद करें" में सक्षम था, जो 100K ब्लॉब्स लिखने के ऊपरी हिस्से का अनुमान लगाता है। परीक्षण वास्तव में सरल था और वास्तविक जीवन का ओवरहेड काफी अधिक हो सकता है।
• मेरे पास वर्तमान में उच्च CPU उपयोग के लिए व्यावहारिक स्पष्टीकरण नहीं है। आउट-ऑफ-ऑर्डर कार्यान्वयन प्रत्येक ब्लॉब को केवल एक बार डिक्रिप्ट करता है (मास्टर प्रत्येक लक्ष्य फ़ाइल के लिए ब्लॉब्स को डिक्रिप्ट करता है), और मास्टर की तुलना में बहुत कम बहीखाता है। हो सकता है कि "विरल" फ़ाइल लेखन वास्तव में विरल न हो और इसके लिए Go या OS को CPU-भारी कुछ करने की आवश्यकता हो। सच में नहीं पता।

सुनो!

ये सही है। वर्करकाउंट को आंतरिक/पुनर्स्थापनाकर्ता/filerestorer.go में 8 या 32 पर सेट किया गया था और -o s3.connections=32 दोनों मामलों में रेस्टिक क्ली के माध्यम से पारित किया गया था।

यहां ट्रेस डेटा का एक शीर्ष-स्तरीय दृश्य दिया गया है, जबकि आउट ऑफ ऑर्डर शाखा 8 कर्मचारियों के साथ फाइलों को पुनर्स्थापित कर रही है।

ऐसा लगता है कि ऐसे महत्वपूर्ण (>500-1000ms) ठहराव हैं जो श्रमिकों को बार-बार आते हैं।

मैंने इस पर कुछ और समय बिताने का फैसला किया और सरल स्टैंडअलोन परीक्षण लिखकर शुरू किया जो 4KiB ब्लॉकों में 10GiB यादृच्छिक बाइट्स उत्पन्न करता है। मेरा लक्ष्य यह आकलन करना था कि मेरा सिस्टम कितनी तेजी से बाइट्स को इधर-उधर कर सकता है। मेरे आश्चर्य की बात यह है कि इस परीक्षण को मेरे मैकबुक प्रो (2018, 2.6 गीगाहर्ट्ज़ इंटेल कोर i7) पर निष्पादित करने में 18.64 सेकंड का समय लगा। जो ~4.29 गीगाबिट/सेकेंड या 10जी ईथरनेट जितना कर सकता है उसका लगभग आधा है। और यह बिना किसी क्रिप्टो या नेट या डिस्क i/o के है। और मैं Xoshiro256** prng का उपयोग कर रहा था, math/rand लगभग 2x धीमा था, जो निश्चित रूप से बिंदु के बगल में है। मुद्दा यह है कि, 10G नेटवर्क को संतृप्त करने के लिए पुनर्स्थापक को कई थ्रेड्स पर ब्लॉब्स को संसाधित करना पड़ता है, मल्टीथ्रेडेड नेट i/o अपने आप में पर्याप्त नहीं है।

और केवल मनोरंजन के लिए, तुलनीय रस्ट इम्प्लांट 3.1 सेकंड में 10GiB रैंडम बाइट्स और 10.77s में जावा उत्पन्न करता है। जाओ पता लगाओ :-)

दिलचस्प परीक्षा!

मैं समझता हूं कि वर्तमान में सबसे बड़ी फ़ाइल को पुनर्स्थापित करने में लगने वाले समय के अनुसार रेस्टिक की दर-सीमित होगी।

अभी, हालांकि, यह हमारा अवरोधक नहीं है, जैसा कि मुझे पता है कि रेस्टिक एक फ़ाइल को 160mbit/sec की तुलना में बहुत तेज़ी से पुनर्स्थापित कर सकता है जो हम यहां देखते हैं।

मास्टर और इस शाखा में वर्तमान सर्वोत्तम स्थिति प्राप्त करने के लिए, मैं तेजी से एसएसडी और एस 3 में 10 एमबी फाइलों से युक्त 100 जीबी टेस्ट रेपो को एक साथ रखूंगा और कुछ नंबर चलाऊंगा।

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

धन्यवाद!

@robvalca आप किस बैकएंड का उपयोग करते हैं? कितनी तेजी से rclone आपके रेपो को लक्ष्य प्रणाली में कॉपी करता है? रेस्टिक रिस्टोर स्पीड क्या है?

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

@ifedorenko हम S3 (ceph+radosgw) को बैकएंड (हमारे द्वारा प्रबंधित) के रूप में उपयोग कर रहे हैं। मैंने rclone का उपयोग करके रेपो को कॉपी करने का प्रयास किया है और ये परिणाम हैं:

आरक्लोन कॉपी -पी रिमोट: cboxback-aabbcc/ /var/tmp/restic/aabbcc/
स्थानांतरित: 127.309G / 127.309 GBytes, 100%, 45.419 MBytes/s, ETA 0s
त्रुटियाँ: 0
चेक: 0 / 0, -
स्थानांतरित: 25435 / 25435, 100%
बीता हुआ समय: 47m50.2s

"स्टॉक" रेस्टिक 0.9.4 का उपयोग करके रेपो को पुनर्स्थापित करने में ~8 घंटे लगे। दोनों ही मामलों में मैं 32 S3 कनेक्शन और एक ही लक्ष्य होस्ट का उपयोग कर रहा हूं। मैंने इस फोरम थ्रेड में थोड़ी और जानकारी डाली है।

मैं आपके परीक्षण के लिए एक रेपो तैयार करूंगा और तैयार होने पर आपको बता दूंगा,
आपकी मदद के लिए बहुत बहुत धन्यवाद!

@robvalca क्या आप मेरी आउट-ऑर्डर-पुनर्स्थापना शाखा का उपयोग करके पुनर्स्थापित करने का प्रयास कर सकते हैं? शाखा को बहुत बड़ी फ़ाइलों के पुनर्स्थापना प्रदर्शन में सुधार करना चाहिए, जो आपके सामने आने वाली समस्या प्रतीत होती है।

यदि शाखा आपके लिए पुनर्स्थापना प्रदर्शन में सुधार नहीं करती है, तो कृपया परीक्षण रेपो को सार्वजनिक s3 बकेट में अपलोड करें और बकेट नाम और रेपो पासवर्ड पोस्ट करें।

@pmkane क्या यह संभव है कि आप बड़ी संख्या में समान या लगभग समान फ़ाइलों को पुनर्स्थापित करें? मुझे लगता है कि यह श्रमिकों के बीच विवाद की व्याख्या करेगा।

संपादित करें: वास्तव में, क्या आप नवीनतम #2101 का उपयोग करके अपने पुनर्स्थापना पूर्ण परीक्षण का पुनः प्रयास कर सकते हैं? इसे एक ही फ़ाइल में समवर्ती लेखन को संभालना चाहिए और एक ही ब्लॉब को कई फाइलों में अब बेहतर तरीके से संभालना चाहिए।

@ifedorenko वास्तव में, आउट-ऑर्डर संस्करण के साथ अब बहुत बेहतर है! इसमें एक घंटे से भी कम समय लगा, जो मुझे rclone के साथ मिला है। कुछ टिप्पणियां जो मैं अपने परीक्षणों से निकाल सकता हूं ताकि आप उन्हें उपयोगी पा सकें (संलग्न भूखंड भी देखें!):

• सामान्य रेस्टिक 0.9.4 पर प्रक्रिया तेजी से शुरू होती है, 200MB/sec शिखर के साथ और हमें S3 की तरफ लगभग 50 requests प्रति सेकंड मिल रहा है। कुछ ही मिनटों के बाद, गिरावट होती है और अनुरोध 1 या उससे भी कम हो जाते हैं और शेष प्रक्रिया के दौरान गति ~ 5MB/sec हो जाती है।
• "Ooo" संस्करण के साथ, स्थानांतरण की गति 40MB/sec जैसी है और ~ 8 S3 सभी प्रक्रिया के दौरान स्थिर अनुरोध करता है।
• एक और बात जो मैंने देखी है वह यह है कि मुझे S3 कनेक्शन बढ़ाने में लगभग कोई सुधार नहीं दिख रहा है, क्या यह अपेक्षित है?

32 कनेक्शन:

Created 2197 directories, listed 171.141 GiB in 20930 files
Restored 171.136 GiB in 170258 files

real    57m54.588s
user    229m25.229s
sys 6m51.763s

64 कनेक्शन

real    53m13.876s
user    242m57.081s
sys 7m12.455s

• अंत में एक और अलग रिपॉजिटरी (51G, 1.3M छोटी फाइलें, बहुत सारे डुप्लिकेट) के साथ एक परीक्षण किया और अभी भी एक अच्छे अंतर से 0.9.4 से तेज है:

0.9.4

real    16m6.966s
user    25m4.116s
sys 4m19.424s

0.9.4-ऊ:

real    8m14.375s
user    14m30.107s
sys 3m41.538s

तो न केवल बड़ी फाइलों के साथ सुधार हो रहा है, यह सभी मामलों में सुधार करता है !!

और बीटीडब्ल्यू, पुनर्स्थापना का नया प्रगति दृश्य अच्छा है !! 8)

मुझे बताएं कि क्या आप चाहते हैं कि मैं कुछ अन्य परीक्षण करूँ।

धन्यवाद!

प्रतिक्रिया के लिए धन्यवाद, @robvalca , यह बहुत उपयोगी है।

• एक और बात जो मैंने देखी है वह यह है कि मुझे S3 कनेक्शन बढ़ाने में लगभग कोई सुधार नहीं दिख रहा है, क्या यह अपेक्षित है?

क्षमा करें, यह उल्लेख करना भूल गया कि समवर्ती पुनर्स्थापना कर्मियों की संख्या बढ़ाने के लिए आपको कोड बदलने की आवश्यकता है। यह इस समय 8 पर हार्डकोड किया गया है:
https://github.com/ifedorenko/restic/blob/099f51c01c189a84b96be86ce6be61a45e3705fc/internal/restorer/filerestorer.go#L22

मुझे बताएं कि क्या आप चाहते हैं कि मैं कुछ अन्य परीक्षण करूँ।

हम अभी भी नहीं जानते हैं कि इस मुद्दे में पहले बताए गए आउट-ऑफ-ऑर्डर पुनर्स्थापना के दौरान स्पष्ट कार्यकर्ता विवाद का कारण क्या है https://github.com/restic/restic/issues/2074#issuecomment -443759511। क्या आप इस विशिष्ट प्रतिबद्धता का परीक्षण कर सकते हैं
https://github.com/ifedorenko/restic/commit/d410668ce3a8c7284d86a2b06bf42a0e654d43bc? यदि आप अपने भंडारों के साथ विवाद देखते हैं, तो इसका मतलब यह होगा कि यह pmkane के डेटा के लिए विशिष्ट नहीं है और मेरे हालिया परिवर्तन विवाद को ठीक करते हैं।

आपकी मदद के लिए पुनः शुक्रिया।

हाय सब - अभी भी इसकी निगरानी कर रहे हैं, लेकिन पूरी तरह से बह गए हैं। मैं इस सप्ताह के अंत में पकड़ लूंगा और देखूंगा कि क्या हम अभी भी ifedorenko@d410668 के साथ पुन: पेश कर सकते हैं

@ifedorenko धन्यवाद, 32 श्रमिकों के साथ प्रक्रिया 30 मिनट तक बहुत तेजी से नीचे जा रही है जो एक अच्छा परिणाम है। मैंने श्रमिकों/s3.connections को 64/64, 128/128 तक बढ़ाने की भी कोशिश की है, लेकिन मुझे कोई सुधार नहीं दिख रहा है, लगभग समान परिणाम मिल रहे हैं। वैसे भी, मैं वर्तमान परिणामों से खुश हूं।

मैंने https://github.com/ifedorenko/restic/commit/d410668 के साथ संस्करण की भी कोशिश की आपने मुझे बताया और यहां ट्रेस का एक स्क्रीनशॉट है। मुझे इस तरह के टूल्स के साथ बहुत अधिक अनुभव नहीं है लेकिन @pmkane परिणामों के समान लगता है। मैंने इसे 8 कर्मचारियों के साथ और -o s3.connections=32 साथ चलाया है

@robvalca so ifedorenko@d410668 शाखा के प्रमुख की तुलना में काफी धीमा था, है ना? यह एक अच्छी खबर है, इसका मतलब है कि हमने सभी ज्ञात समस्याओं का समाधान कर लिया है। अपडेट के लिए धन्यवाद।

@ifedorenko नहीं, मैं उल्लेख करना भूल गया, प्रदर्शन कमोबेश शाखा के प्रमुख (आउट-ऑफ-ऑर्डर) की तुलना में समान संख्या में श्रमिकों (8) और S3.connections (32) के समान है। दोनों ने ~55m लिया, जो कि rclone (~47m) के साथ रेपो को स्थानांतरित करने के समय के अनुरूप है

मुझे बताएं कि क्या आप चाहते हैं कि मैं अन्य मापदंडों के साथ परीक्षण करूं;)

मुझे अपने उपयोग के मामले में प्रदर्शन समस्याओं के लिए ट्रिगर मिला। बड़ी फ़ाइलों के लिए पुनर्स्थापना प्रदर्शन एक निश्चित फ़ाइल आकार से परे गैर-रैखिक है।

परीक्षण करने के लिए, मैंने S3 में एक नया रेपो बनाया और फिर रेपो में यादृच्छिक डेटा वाली 6 फ़ाइलों का बैकअप लिया। फाइलें 1, 5, 10, 20, 40 और 80GB आकार की थीं।

पिछले परीक्षणों की तरह, परीक्षण i3.8xबड़े उदाहरणों पर चलाए गए थे जिनमें बैकअप और पुनर्स्थापना तेज, धारीदार एसएसडी पर हो रहे थे।

उम्मीद के मुताबिक बैकअप समय रैखिक था (8, 25, 46, 92, 177 और 345 सेकंड)।

हालाँकि, पुनर्स्थापना समय नहीं थे:

1 जीबी, 5 एस
5 जीबी, 17 एस
10जीबी, 33एस
20जीबी, 85एस
40 जीबी, 256 एस
80GB, 807s

तो बड़ी फ़ाइलों के साथ कुछ अजीब चल रहा है और प्रदर्शन बहाल कर रहा है।

बकेट को pmk-large-restic-test नाम दिया गया है और बकेट और उसकी सामग्री सार्वजनिक है। यह us-west-1 में है और बाकी रेपो पासवर्ड पासवर्ड है

फ़ाइलों के लिए स्नैपशॉट आईडी हैं:

1 जीबी: 0154ae25
5 जीबी: 3013e883
10जीबी: 7463ईएफए8
20जीबी: 292650सी6
40GB: 5acb4bee
80GB: d1b7e323

मुझे बताएं कि क्या और डेटा है जो मैं प्रदान कर सकता हूं!

@pmkane क्या आप पुष्टि कर सकते हैं कि आपने https://github.com/ifedorenko/restic/tree/out-order-restore शाखा के नवीनतम प्रमुख का उपयोग किया है (https://github.com/ifedorenko/restic/commit/ead78b375f2efed6de57c99b6766edbe9322e009 विशिष्ट होने के लिए) ?

हाँ मैंने किया। इसका उल्लेख नहीं करने के लिए खेद है।

(सभी रन w/ead78b3 में 32 श्रमिकों और 32 s3 कनेक्शनों का इस्तेमाल किया)

क्या आप जानते हैं कि उस बकेट तक पहुँचने के लिए मुझे कुछ विशेष करने की आवश्यकता है या नहीं? मैंने पहले कभी सार्वजनिक बकेट का उपयोग नहीं किया, इसलिए मुझे यकीन नहीं है कि मैं कुछ गलत कर रहा हूं या उपयोगकर्ता के पास पहुंच नहीं है। (मैं अपनी टीम की बकेट को ठीक से एक्सेस कर सकता हूं, इसलिए मुझे पता है कि मेरा सिस्टम सामान्य रूप से s3 तक पहुंच सकता है)

अरे @ifedorenko , रुको, मुझे किसी जगह से

इसके बारे में क्षमा करें, मैंने सार्वजनिक बाल्टी नीति लागू की थी, लेकिन वस्तुओं को बाल्टी में ही अपडेट नहीं किया था। आपको इसे अभी एक्सेस करने में सक्षम होना चाहिए। ध्यान दें कि आपको --no-lock का उपयोग करना होगा, क्योंकि मैंने केवल पढ़ने की अनुमति दी है।

हाँ। मैं अब रेपो तक पहुंच सकता हूं। इसके साथ आज रात बाद में खेलेंगे।

और अगर यह परीक्षण करने में मददगार/आसान है, तो हम समान प्रदर्शन विशेषताओं को देखते हैं जब तेज एसएसडी पर रेपो से/उसी फाइलों को पुनर्स्थापित करते समय, एस 3 को समीकरण से बाहर ले जाते हैं।

@pmkane मैं स्थानीय रूप से समस्या को पुन: उत्पन्न कर सकता हूं और अब उस बाल्टी तक पहुंच की आवश्यकता नहीं है। यह बहुत उपयोगी था, धन्यवाद।

@ifedorenko , शानदार। मैं बाल्टी हटा दूंगा।

@pmkane कृपया नवीनतम आउट-ऑर्डर-रिस्टोर शाखा दें जब आपके पास समय हो तो एक और प्रयास करें। मेरे पास ec2 में इसका परीक्षण करने का समय नहीं था, लेकिन मेरी मैकबुक पर पुनर्स्थापना डिस्क लिखने की गति और अब rclone से मेल खाती है।

@ifedorenko , यह बहुत ही आशाजनक लगता है। मैं अब एक परीक्षण फायरिंग कर रहा हूँ।

@ifedorenko , बिंगो।

फ़ाइल आकार के मिश्रण का प्रतिनिधित्व करने वाले 133GB मूल्य के ब्लॉब्स को पुनर्स्थापित किया, सबसे बड़ा 78GB, केवल 16 मिनट से कम समय में। पहले, यह पुनर्स्थापना एक दिन का बेहतर हिस्सा लेती। मुझे संदेह है कि हम इसे अभी भी बहाल करने वालों की संख्या के साथ खेलकर तेजी से प्राप्त कर सकते हैं, लेकिन यह बहुत तेज है क्योंकि यह खड़ा है।

इस पर आपकी कड़ी मेहनत के लिए धन्यवाद!

और भावी पीढ़ी के लिए: हमारा पुनर्स्थापना प्रदर्शन 8->16 से दोगुना हो जाता है और फिर से 16->32 बहाल कर्मियों से। 32> 64 केवल 32 के शीर्ष पर ~ 50% टक्कर के लिए अच्छा है, जिस बिंदु पर हम लगभग 3जीबिट/सेकंड पर बहाल कर रहे हैं। लगभग rclone के बराबर।

मुझे पता है कि रेस्टिक से सर्वश्रेष्ठ प्रदर्शन निकालने के लिए आवश्यक कॉन्फ़िगरेशन की मात्रा को कम करने की इच्छा है, लेकिन यह एक बड़ी छलांग है, खासकर बड़े फ़ाइल सेट वाले उपयोगकर्ताओं के लिए, यह निर्दिष्ट करने में सक्षम होना अच्छा होगा रनटाइम पर श्रमिकों की संख्या।

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

मै उसे करने की एक कोशिश तो करूंगा।

हाय सब, मैंने नवीनतम पुल अनुरोध #2195 का उपयोग करके कुछ परीक्षण चलाए और प्रदर्शन में सुधार जारी है!

(20k छोटी फ़ाइलें, 2x70G फ़ाइलें, कुल 170G)

8w_32c

real    27m46.185s
user    24m31.290s
sys 3m55.153s

32w_32c

real    15m30.904s
user    24m1.982s
sys 4m55.128s

64w_32c

real    18m37.566s
user    23m33.684s
sys 5m3.024s

64w_64c

real    17m12.314s
user    23m44.318s
sys 4m43.090s

32w से 64w तक प्रदर्शन ड्रॉप के बारे में निश्चित नहीं है (कई बार परीक्षण किया गया और वैध लगता है)। मैं प्रक्रिया के दौरान कुछ ग्राफ संलग्न करता हूं, ऐसा लगता है कि कुछ गिरावट या सीमा है, ऐसा होना चाहिए? उदाहरण के लिए, 64 कर्मचारियों के साथ प्रक्रिया 6gbit/sec से शुरू होती है, लेकिन उसके बाद प्रक्रिया के अंत तक 1gbit/sec से कम हो जाती है (जो मुझे लगता है कि उन बड़ी फ़ाइलों को संसाधित करने के समय के अनुरूप है)। पहला स्क्रीनशॉट 32w, 32c और दूसरा 64w, 32c के साथ है।

मैं @pmkane से भी सहमत

वैसे भी मैं किए गए सुधारों से वास्तव में प्रभावित हूं! बहुत बहुत धन्यवाद @ifedorenko

++। धन्यवाद @ifedorenko , यह

विस्तृत रिपोर्ट @robvalca के लिए धन्यवाद। किसी भी मौके पर आप एक परीक्षण भंडार प्रदान कर सकते हैं जो मैं या तो एडब्ल्यूएस (या जीसीपी या एज़ूर) या स्थानीय रूप से कर सकता हूं? मैंने अपने परीक्षणों में बड़ी फ़ाइल पुनर्स्थापना गति ड्रॉप नहीं देखी और यह समझना चाहूंगा कि वहां क्या हो रहा है।

@pmkane मैं भी इन चीजों को रन टाइम पर कॉन्फ़िगर करना चाहता हूं। मेरा सुझाव उन्हें --option विकल्प बनाना था ताकि वे नियमित झंडे या आदेशों को अव्यवस्थित न करें, लेकिन 'उन्नत' उपयोगकर्ताओं के लिए हैं जो अपनी असामान्य स्थिति का प्रयोग या ट्यून करना चाहते हैं। उन्हें प्रलेखित करने की भी आवश्यकता नहीं है और उन्हें ऐसे नाम दिए जा सकते हैं जो यह स्पष्ट करते हैं कि आप उन पर भरोसा नहीं कर सकते, जैसे --option experimental.fooCount=32 ।

हाय @ifedorenko , मैंने जंक डेटा के साथ s3.cern.ch/restic-testrepo पर एक सार्वजनिक रेपो बनाया है। यह कमोबेश उसी आकार का है जैसा मैं कोशिश कर रहा था (बहुत सारी छोटी फाइलें और कुछ बहुत बड़ी) और साथ ही मैं इस (संलग्न प्लॉट) पर उसी व्यवहार को पुन: पेश कर सकता था। रेपो का पासवर्ड है restic । अगर आपको इसे एक्सेस करने में कोई परेशानी हो तो मुझे बताएं।

@robvalca मैं आपके परीक्षण भंडार का उपयोग करके समस्या को पुन: उत्पन्न करने में असमर्थ हूं। AWS (us-east-2, s3 repo, i3.4xlarge 2x nvme Raid0 target) में मुझे 32 श्रमिकों और 32 कनेक्शनों (कुल पुनर्स्थापना समय 6m20s) का उपयोग करते समय स्थिर 0.68 GB/s पुनर्स्थापना गति दिखाई देती है। आपका लक्ष्य प्रणाली लंबे समय तक 10GB/s को बनाए नहीं रख सकता है, अगर मुझे लगता है, तो कम से कम मैं यही जांच करूंगा कि अगर मैं इसे और अधिक समस्या निवारण करता हूं।

@pmkane दिलचस्प बात यह है कि मैं आपकी टिप्पणियों की पुष्टि नहीं कर सकता। जैसा कि मैंने ऊपर उल्लेख किया है, मुझे नवीनतम out-of-order-restore-no-progress शाखा का उपयोग करके 0.68 जीबी/एस की पुनर्स्थापना गति दिखाई देती है (पुनर्स्थापित सीपीयू-बाउंड दिखता है), और 0.81 जीबी/एस अगर मैं अनावश्यक ब्लॉब हैश चेक अक्षम करता हूं (पुनर्स्थापित सीपीयू नहीं दिखता है- बाध्य)। मुझे नहीं पता कि "10 जीबीपीएस तक" नेटवर्क कितनी तेजी से जा सकता है, लेकिन मुझे लगता है कि हम पहले से ही "कम रिटर्न" क्षेत्र में हैं।

@ifedorenko मैं तहे दिल से सहमत हूं: कम रिटर्न। यह हमारे लिए काफी तेज है जैसा कि यह है।

@ifedorenko दिलचस्प है, मैं अपनी तरफ से इसकी जांच करूंगा। वैसे भी यह हमारे लिए भी काफी तेज है, आपके प्रयास के लिए बहुत-बहुत धन्यवाद।

इसे मर्ज करने की स्थिति के बारे में उत्सुक। यह शाखा, @cbane के प्रून स्पीड पर काम के साथ

जल्द ही...

इसे बंद करते हुए अब #2195 को मर्ज कर दिया गया है। यदि इस मुद्दे के बारे में विशिष्टताओं का समाधान नहीं किया गया है, तो इसे फिर से खोलने के लिए पूरी तरह से स्वतंत्र महसूस करें। यदि अभी भी ऐसे सुधार किए जाने हैं जो इस मुद्दे में चर्चा किए गए प्रकार के नहीं हैं, तो कृपया एक नया मुद्दा खोलें। धन्यवाद!