प्राइमेटियस के साथ प्रोमेथियस 2.6.0 स्टार्टअप समय का अनुकूलन

प्रोमेथियस 2.6.0 ने वाल लोडिंग को अनुकूलित किया, जो स्टार्टअप प्रक्रिया को गति देता है।

प्रोमेथियस 2.x TSDB विकसित करने का अनौपचारिक लक्ष्य लॉन्च को गति देना है ताकि एक मिनट से अधिक समय न लगे। हाल के महीनों में, ऐसी खबरें आई हैं कि प्रक्रिया में थोड़ा अधिक समय लग रहा है, और अगर किसी कारण से प्रोमेथियस फिर से शुरू होता है, तो यह पहले से ही एक समस्या है। लगभग इस समय, वाल (प्री-रिकॉर्डिंग रिकॉर्डिंग) भरी हुई है, जिसमें पिछले कुछ घंटों के नमूने शामिल हैं जिन्हें अभी तक एक ब्लॉक में संकुचित किया जाना है। अक्टूबर के अंत में, मैंने आखिरकार इसका पता लगाने में कामयाबी हासिल की; परिणाम PR # 440 है , जो CPU समय को 6.5 गुना और गणना समय को 4 गुना कम कर देता है। आइए देखें कि मैंने ये सुधार कैसे किए।

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

 f, err := os.Create("cpu.prof") if err != nil { log.Fatal(err) } pprof.StartCPUProfile(f) defer pprof.StopCPUProfile() 

सीपीयू प्रोफाइल हमें सीधे हमारे लिए ब्याज की गणना का समय निर्धारित करने की अनुमति नहीं देता है, हालांकि, एक महत्वपूर्ण सहसंबंध है। नतीजतन, मेरे डेस्कटॉप कंप्यूटर (16 जीबी रैम और सॉलिड स्टेट ड्राइव के साथ i7-3770 प्रोसेसर) पर, डाउनलोड में लगभग 4 मिनट लगे और अपने चरम पर 6 जीबी से थोड़ा कम रैम:

 1727.50user 16.61system 4:01.12elapsed 723%CPU (0avgtext+0avgdata 5962812maxresident)k 23625165inputs+95outputs (196major+2042817minor)pagefaults 0swaps 

यह एक चर्चा नहीं है, तो चलिए प्रोफाइल को लोड go tool pprof cpu.prof का उपयोग करके लोड करते go tool pprof cpu.prof और देखते हैं कि यदि आप top कमांड का उपयोग करते हैं तो प्रक्रिया को कितना समय लगेगा।

यहाँ flat किसी दिए गए फ़ंक्शन पर खर्च किए गए समय की राशि है, और cum इस फ़ंक्शन और इसके द्वारा बुलाए गए सभी कार्यों पर खर्च किया गया समय है। प्रश्न का अंदाजा लगाने के लिए इस डेटा को ग्राफ में देखना भी उपयोगी हो सकता है। मैं इसके लिए web कमांड का उपयोग करना पसंद करता हूं, लेकिन svg, png और pdf फ़ाइलों सहित अन्य विकल्प हैं।

यह देखा जा सकता है कि हमारे सीपीयू का लगभग एक तिहाई हिस्सा आंतरिक डेटाबेस में नमूनों को जोड़ने पर खर्च किया जाता है, सामान्य रूप से वाल प्रोसेसिंग पर दो-तिहाई और स्मृति ( runtime.scanobject ) की सफाई पर एक चौथाई। आइए list memSeries.*append का उपयोग करके इन प्रक्रियाओं में से पहली के लिए कोड list memSeries.*append :

निम्नलिखित निम्नलिखित है: 1443 लाइन पर श्रृंखला के लिए डेटा का मुख्य टुकड़ा प्राप्त करने में आधे से अधिक समय व्यतीत होता है। इसके अलावा, लाइन 1449 पर डेटा के इस टुकड़े में नमूनों की संख्या निर्धारित करने में बहुत कम समय नहीं खर्च होता है। लाइन 1465 को पूरा करने में लगने वाला समय - उम्मीद है, क्योंकि यह इस समारोह की कार्रवाई का मूल है। तदनुसार, मुझे उम्मीद थी कि ऑपरेशन में अधिकांश समय लगेगा।

memSeries.head तत्व पर एक नज़र डालें: यह हर बार लौटाए गए डेटा के एक टुकड़े की गणना करता है। प्रत्येक 120 परिवर्धन के बाद ही डेटा का टुकड़ा बदलता है, और इस प्रकार, हम श्रृंखला के डेटा संरचना में वर्तमान सिर के टुकड़े को बचा सकते हैं। यह कुछ रैम लेता है ( जो मैं बाद में लौटूंगा ), लेकिन सीपीयू की एक महत्वपूर्ण राशि बचाता है। और कुल मिलाकर, यह प्रोमेथियस को भी गति देता है।

तो फिर चलिए एक नज़र Head.processWALSamples :

यह ऐड-ऑन पहले से ही ऊपर अनुकूलित किया गया है, इसलिए अगली स्पष्ट अपराधी को देखें, getByID ऑन लाइन 252:
(कोड)

ऐसा लगता है कि किसी प्रकार का अवरोधक संघर्ष है, और समय दो-स्तरीय मानचित्र खोज कर रहा है। प्रत्येक पहचानकर्ता के लिए कैश इस सूचक को काफी कम कर देता है।

यह Head.processWALSamples पर दूसरी नज़र डालने के लायक है, और आपको आश्चर्य है कि लाइन 249 पर कितना समय बिताया गया था। आइए हम थोड़ा सा सवाल करते हैं कि कैसे वॉक लोडिंग कार्य करता है: Head.processWALSamples Head.processWALSamples प्रत्येक उपलब्ध सीपीयू के लिए बनाया गया है, पढ़ने के लिए एक और के अलावा। डिकोडिंग वाल से डिस्क। पंक्तियों को इन गोरोइंट्स द्वारा खंडित किया जाता है, इसलिए संगामिति एक फायदा हो सकता है। कार्यान्वयन विधि इस प्रकार है: सभी नमूनों को पहले गोरुटिन में भेजा जाता है, जो उन तत्वों को संसाधित करता है जिनकी उसे आवश्यकता होती है। फिर वह सभी नमूनों को दूसरे गोरूटिन के पास भेजती है, जो उसके लिए आवश्यक तत्वों को संसाधित करता है, और इसी तरह, अंतिम गोरूटिन तक, Head.processWALSamples सभी डेटा वापस नियंत्रण गोरुटिन को भेजता है।

इस बीच, ऐड-ऑन को गुठली के पार वितरित किया जाता है - जो कि आपकी आवश्यकता है - और प्रत्येक गोरुटिन में कई डुप्लिकेट कार्य किए जाते हैं, जो सभी नमूनों को संसाधित करते हैं और मॉड्यूल की गणना करते हैं। वास्तव में, अधिक कोर, अधिक काम दोहराया जाता है। मैंने डेटा को कंट्रोलर गॉरुटिन में विभाजित करने के लिए बदलाव किए, ताकि हेड.प्रोसेसवुस्लेम्पन्स के प्रत्येक गोरूटिन को केवल वे नमूने Head.processWALSamples उसे जरूरत है । मेरे कंप्यूटर पर - 8 रनिंग गोरूटिन - गणना का समय थोड़ा बचा था, लेकिन सीपीयू की मात्रा सभ्य थी। बड़ी संख्या में कोर वाले कंप्यूटरों के लिए, लाभ अधिक पर्याप्त होना चाहिए।

और फिर से हम इस सवाल पर लौटते हैं: स्मृति को खाली करने का समय। हम इसे (आमतौर पर) सीपीयू प्रोफाइल के माध्यम से निर्धारित नहीं कर सकते हैं। इसके बजाय, उन तत्वों को खोजने के लिए गतिशील मेमोरी प्रोफाइल पर ध्यान दें जो बाहर खड़े हैं। इस कार्यक्रम के अंत में कुछ कोड विस्तार की आवश्यकता है:

 runtime.GC() hf, err := os.Create("heap.prof") if err != nil { log.Fatal(err) } pprof.WriteHeapProfile(hf) 

औपचारिक स्मृति सफाई गतिशील स्मृति में कुछ जानकारी के साथ जुड़ी हुई है, जिसका संग्रह और सफाई केवल स्मृति सफाई के दौरान की जाती है।

हम फिर से एक ही टूल का उपयोग करते हैं, लेकिन -alloc_space लेबल को निर्दिष्ट करते हैं, क्योंकि हम सभी मेमोरी आवंटन कार्यों में रुचि रखते हैं, और न कि केवल ऐसे ऑपरेशन जो किसी विशेष क्षण में मेमोरी का उपयोग करते हैं; इस प्रकार, रन go tool pprof -alloc_space heap.prof । यदि आप ऊपरी वितरक को देखते हैं, तो अपराधी स्पष्ट है:

कोड पर एक नज़र डालें:

एक्स्टेंसिबल samples ऐरे एक समस्या लगती है। यदि हम RecordDecoder.Samples को कॉल करने के साथ ही एक ही समय में सरणी का पुन: उपयोग कर सकते हैं, तो यह महत्वपूर्ण मात्रा में मेमोरी को बचाएगा। यह पता चला है कि कोड इस तरह से बनाया गया था, लेकिन एक छोटी सी कोडिंग त्रुटि इस तथ्य की ओर ले गई कि यह काम नहीं करता था। यदि आप इसे ठीक करते हैं , तो मेमोरी को 151 सेकंड के बजाय सीपीयू के 8 सेकंड में साफ़ किया जाता है।

समग्र परिणाम काफी मूर्त हैं:

 269.18user 10.69system 1:05.58elapsed 426%CPU (0avgtext+0avgdata 3529556maxresident)k 23174929inputs+70outputs (815major+1083172minor)pagefaults 0swap 

हमने न केवल गणना समय को 4 गुना कम किया है, और सीपीयू समय - 6.5 गुना तक, लेकिन कब्जे वाली मेमोरी की मात्रा भी 2 जीबी से कम हो गई है।

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