बड़े डेटा क्वेरी कार्यों में सिस्टम स्थिरता की गारंटी क्या है? यह एक प्रभावी स्मृति आवंटन और निगरानी तंत्र है। इस तरह आप संगणना को गति देते हैं, मेमोरी हॉटस्पॉट से बचते हैं, अपर्याप्त मेमोरी पर तुरंत प्रतिक्रिया देते हैं, और OOM त्रुटियों को कम करते हैं।
डेटाबेस उपयोगकर्ता के परिप्रेक्ष्य से, वे खराब स्मृति प्रबंधन से कैसे पीड़ित हैं? यह उन चीज़ों की सूची है जो हमारे उपयोगकर्ताओं को परेशान करती थीं:
OOM त्रुटियाँ बैकएंड प्रक्रियाओं के क्रैश होने का कारण बनती हैं। हमारे समुदाय के सदस्यों में से एक को उद्धृत करने के लिए: हाय, अपाचे डोरिस, चीजों को धीमा करना या कुछ कार्यों को विफल करना ठीक है जब आपकी याददाश्त कम होती है, लेकिन डाउनटाइम फेंकना अच्छा नहीं है।
बैकएंड प्रक्रियाएं बहुत अधिक मेमोरी स्पेस का उपभोग करती हैं, लेकिन किसी एकल क्वेरी के लिए मेमोरी उपयोग को दोष देने या सीमित करने के लिए सटीक कार्य खोजने का कोई तरीका नहीं है।
प्रत्येक क्वेरी के लिए एक उचित मेमोरी आकार सेट करना कठिन है, इसलिए बहुत अधिक मेमोरी स्पेस होने पर भी एक क्वेरी रद्द होने की संभावना है।
उच्च-संगामिति प्रश्न असमान रूप से धीमे होते हैं, और मेमोरी हॉटस्पॉट का पता लगाना कठिन होता है।
हैशटेबल निर्माण के दौरान इंटरमीडिएट डेटा को डिस्क में फ़्लश नहीं किया जा सकता है, इसलिए OOM के कारण दो बड़ी तालिकाओं के बीच क्वेरीज़ में शामिल होना अक्सर विफल हो जाता है।
सौभाग्य से, वे काले दिन हमारे पीछे हैं क्योंकि हमने अपने स्मृति प्रबंधन तंत्र को नीचे से ऊपर तक सुधार लिया है। अब तैयार हो जाओ; चीजें गहन होने जा रही हैं।
अपाचे डोरिस में, हमारे पास स्मृति आवंटन के लिए एकमात्र इंटरफ़ेस है: आवंटक । यह स्मृति उपयोग को कुशल और नियंत्रण में रखने के लिए उपयुक्त समायोजन करेगा।
इसके अलावा, आवंटित या जारी किए गए मेमोरी आकार को ट्रैक करने के लिए मेमट्रैकर्स मौजूद हैं, और ऑपरेटर निष्पादन में बड़े मेमोरी आवंटन के लिए तीन अलग-अलग डेटा संरचनाएं जिम्मेदार हैं (हम उन्हें तुरंत प्राप्त करेंगे)।
चूंकि अलग-अलग प्रश्नों के निष्पादन में अलग-अलग मेमोरी हॉटस्पॉट पैटर्न होते हैं, अपाचे डोरिस तीन अलग-अलग इन-मेमोरी डेटा संरचनाएं प्रदान करता है: एरिना , हैशटेबल , और पॉडअरे । वे सभी आवंटक के शासन में हैं।
अखाड़ा एक मेमोरी पूल है जो चंक्स की एक सूची रखता है, जिसे आवंटक के अनुरोध पर आवंटित किया जाना है। चंक्स स्मृति संरेखण का समर्थन करते हैं। वे अखाड़े के पूरे जीवनकाल में मौजूद हैं और विनाश पर मुक्त हो जाएंगे (आमतौर पर जब क्वेरी पूरी हो जाती है)।
चंक्स का उपयोग मुख्य रूप से शफल, या हैशटेबल्स में क्रमबद्ध कुंजियों के दौरान क्रमबद्ध या अक्रमबद्ध डेटा को संग्रहीत करने के लिए किया जाता है।
चंक का प्रारंभिक आकार 4096 बाइट्स है। यदि वर्तमान चंक अनुरोधित मेमोरी से छोटा है, तो सूची में एक नया चंक जोड़ा जाएगा।
यदि वर्तमान चंक 128M से छोटा है, तो नया चंक अपने आकार को दोगुना कर देगा; यदि यह 128M से बड़ा है, तो नया चंक, अधिक से अधिक 128M जितना आवश्यक है, उससे बड़ा होगा।
पुराने छोटे हिस्से को नए अनुरोधों के लिए आवंटित नहीं किया जाएगा। आबंटित चंक्स और अआवंटित चंक्स के बीच विभाजन रेखा को चिह्नित करने के लिए एक कर्सर है।
हैशटेबल्स हैश जॉइन, एकत्रीकरण, सेट ऑपरेशंस और विंडो फ़ंक्शंस के लिए लागू होते हैं। PartitionedHashTable संरचना 16 से अधिक सब-हैशटेबल्स का समर्थन नहीं करती है। यह हैशटेबल्स के समांतर विलय का भी समर्थन करता है और प्रत्येक उप-हैश जॉइन को स्वतंत्र रूप से स्केल किया जा सकता है।
ये समग्र स्मृति उपयोग और स्केलिंग के कारण विलंबता को कम कर सकते हैं।
यदि वर्तमान हैशटेबल 8M से छोटा है, तो इसे 4 के कारक द्वारा बढ़ाया जाएगा;
यदि यह 8M से बड़ा है, तो इसे 2 के कारक द्वारा बढ़ाया जाएगा;
यदि यह 2G से छोटा है, तो इसे 50% पूर्ण होने पर बढ़ाया जाएगा;
और यदि यह 2G से बड़ा है, तो इसे 75% पूर्ण होने पर बढ़ाया जाएगा।
नए बनाए गए हैशटेबल्स में कितना डेटा होने वाला है, इसके आधार पर प्री-स्केल किया जाएगा। हम विभिन्न परिदृश्यों के लिए विभिन्न प्रकार के हैशटेबल्स भी प्रदान करते हैं। उदाहरण के लिए, एकत्रीकरण के लिए, आप PHmap लागू कर सकते हैं।
PODArray, जैसा कि नाम से पता चलता है, POD का एक गतिशील सरणी है। इसके और std::vector
के बीच का अंतर यह है कि PODArray तत्वों को प्रारंभ नहीं करता है। यह स्मृति संरेखण और std::vector
के कुछ इंटरफेस का समर्थन करता है।
इसे 2 के कारक द्वारा स्केल किया जाता है। विनाश में, प्रत्येक तत्व के लिए विनाशक फ़ंक्शन को कॉल करने के बजाय, यह संपूर्ण PODArray की स्मृति को रिलीज़ करता है। PODArray का उपयोग मुख्य रूप से कॉलम में स्ट्रिंग्स को बचाने के लिए किया जाता है और यह कई फ़ंक्शन कम्प्यूटेशंस और एक्सप्रेशन फ़िल्टरिंग में लागू होता है।
Arena, PODArray, और HashTable को समन्वित करने वाले एकमात्र इंटरफ़ेस के रूप में, एलोकेटर 64M से बड़े अनुरोधों के लिए मेमोरी मैपिंग (MMAP) आवंटन को निष्पादित करता है।
जो 4K से छोटे हैं उन्हें सिस्टम से malloc/free के माध्यम से सीधे आवंटित किया जाएगा; और बीच के लोगों को एक सामान्य-उद्देश्य कैशिंग चंकएलोकेटर द्वारा त्वरित किया जाएगा, जो हमारे बेंचमार्किंग परिणामों के अनुसार 10% प्रदर्शन में वृद्धि लाता है।
चंक एलोकेटर लॉक-फ्री तरीके से वर्तमान कोर की फ्रीलिस्ट से निर्दिष्ट आकार के एक हिस्से को पुनः प्राप्त करने का प्रयास करेगा; यदि ऐसा चंक मौजूद नहीं है, तो यह अन्य कोरों से लॉक-आधारित तरीके से प्रयास करेगा; यदि वह अभी भी विफल रहता है, तो यह सिस्टम से निर्दिष्ट मेमोरी आकार का अनुरोध करेगा और इसे एक चंक में इनकैप्सुलेट करेगा।
हमने उन दोनों का अनुभव करने के बाद TCMalloc पर Jemalloc को चुना। हमने अपने उच्च-संगामिति परीक्षणों में TCMalloc को आज़माया और देखा कि CentralFreeList में स्पिन लॉक ने कुल क्वेरी समय का 40% हिस्सा लिया।
"आक्रामक मेमोरी डिकॉमिट" को अक्षम करने से चीजें बेहतर हो गईं, लेकिन इससे मेमोरी का अधिक उपयोग हुआ, इसलिए हमें कैश को नियमित रूप से रीसायकल करने के लिए एक अलग थ्रेड का उपयोग करना पड़ा। दूसरी ओर, जेमलोक, उच्च-संगामिति प्रश्नों में अधिक प्रदर्शन करने वाला और स्थिर था।
अन्य परिदृश्यों के लिए फाइन-ट्यूनिंग के बाद, इसने TCMalloc के समान प्रदर्शन दिया लेकिन कम मेमोरी की खपत की।
अपाचे डोरिस की निष्पादन परत पर मेमोरी पुन: उपयोग को व्यापक रूप से निष्पादित किया जाता है। उदाहरण के लिए, क्वेरी के निष्पादन के दौरान डेटा ब्लॉक का पुन: उपयोग किया जाएगा। फेरबदल के दौरान, प्रेषक छोर पर दो ब्लॉक होंगे और वे वैकल्पिक रूप से काम करेंगे, एक डेटा प्राप्त करेगा और दूसरा आरपीसी परिवहन में।
टैबलेट को पढ़ते समय, डोरिस प्रेडिकेट कॉलम का पुन: उपयोग करेगा, चक्रीय रीडिंग लागू करेगा, फ़िल्टर करेगा, फ़िल्टर किए गए डेटा को ऊपरी ब्लॉक में कॉपी करेगा, और फिर साफ़ करेगा।
कुल कुंजी तालिका में डेटा अंतर्ग्रहण करते समय, एक बार मेमटेबल जो डेटा को कैश करता है, एक निश्चित आकार तक पहुंच जाता है, इसे पूर्व-एकत्रित किया जाएगा, और फिर अधिक डेटा लिखा जाएगा।
डेटा स्कैनिंग में भी मेमोरी का पुन: उपयोग किया जाता है। स्कैनिंग शुरू होने से पहले, स्कैनिंग कार्य के लिए कई मुफ्त ब्लॉक (स्कैनर और थ्रेड्स की संख्या के आधार पर) आवंटित किए जाएंगे।
प्रत्येक स्कैनर शेड्यूलिंग के दौरान, डेटा पढ़ने के लिए एक फ्री ब्लॉक स्टोरेज लेयर को पास किया जाएगा।
डेटा पढ़ने के बाद, बाद की गणना में ऊपरी ऑपरेटरों की खपत के लिए ब्लॉक को निर्माता कतार में रखा जाएगा। एक बार एक ऊपरी ऑपरेटर ने ब्लॉक से संगणना डेटा की प्रतिलिपि बना ली है, तो ब्लॉक अगले स्कैनर शेड्यूलिंग के लिए मुक्त ब्लॉक में वापस चला जाएगा।
मुक्त ब्लॉकों को पूर्व-आवंटित करने वाला थ्रेड डेटा स्कैनिंग के बाद उन्हें मुक्त करने के लिए भी जिम्मेदार होगा, इसलिए अतिरिक्त ओवरहेड्स नहीं होंगे। मुक्त ब्लॉकों की संख्या किसी तरह डेटा स्कैनिंग की संगामिति निर्धारित करती है।
मेमोरी हॉटस्पॉट का विश्लेषण करते समय अपाचे डोरिस मेमट्रैकर्स का उपयोग मेमोरी के आवंटन और रिलीज पर अनुवर्ती कार्रवाई के लिए करता है। MemTrackers प्रत्येक डेटा क्वेरी, डेटा अंतर्ग्रहण, डेटा संघनन कार्य और प्रत्येक वैश्विक वस्तु के मेमोरी आकार, जैसे कैशे और टैबलेटमेटा का रिकॉर्ड रखता है।
यह मैनुअल काउंटिंग और मेमहुक ऑटो-ट्रैकिंग दोनों का समर्थन करता है। उपयोगकर्ता वेब पेज पर डोरिस बैकएंड में रीयल-टाइम मेमोरी उपयोग देख सकते हैं।
Apache Doris 1.2.0 से पहले MemTracker सिस्टम एक पदानुक्रमित वृक्ष संरचना में था, जिसमें process_mem_tracker, query_pool_mem_tracker, query_mem_tracker, inst_mem_tracker, ExecNode_mem_tracker, इत्यादि शामिल थे।
दो पड़ोसी परतों के मेमट्रैकर्स माता-पिता के रिश्ते के होते हैं। इसलिए, चाइल्ड मेमट्रैकर में किसी भी गणना की गलतियाँ सभी तरह से जमा हो जाएँगी और बड़े पैमाने पर अविश्वसनीयता का परिणाम देंगी।
अपाचे डोरिस 1.2.0 और नए में, हमने मेमट्रैकर्स की संरचना को बहुत सरल बना दिया है। मेमट्रैकर्स को उनकी भूमिकाओं के आधार पर केवल दो प्रकारों में विभाजित किया गया है: मेमट्रैकर लिमिटर और अन्य।
मेमट्रैकर लिमिटर, स्मृति उपयोग की निगरानी, प्रत्येक क्वेरी/अंतर्ग्रहण/संघनन कार्य और वैश्विक वस्तु में अद्वितीय है; जबकि अन्य मेमट्रैकर्स क्वेरी निष्पादन में मेमोरी हॉटस्पॉट का पता लगाते हैं, जैसे हैशटेबल्स इन जॉइन/एग्रिगेशन/सॉर्ट/विंडो फ़ंक्शंस और क्रमांकन में इंटरमीडिएट डेटा, विभिन्न ऑपरेटरों में मेमोरी का उपयोग कैसे किया जाता है या स्मृति नियंत्रण के लिए एक संदर्भ प्रदान करने की तस्वीर देने के लिए डेटा निस्तब्धता।
मेमट्रैकर लिमिटर और अन्य मेमट्रैकर्स के बीच पैरेंट-चाइल्ड संबंध केवल स्नैपशॉट प्रिंटिंग में प्रकट होता है। आप ऐसे संबंध को एक प्रतीकात्मक कड़ी के रूप में सोच सकते हैं। एक ही समय में उनका उपभोग नहीं किया जाता है, और एक का जीवनचक्र दूसरे के जीवनचक्र को प्रभावित नहीं करता है।
इससे डेवलपर्स के लिए उन्हें समझना और उनका उपयोग करना बहुत आसान हो जाता है।
मेमट्रैकर्स (मेमट्रैकर लिमिटर और अन्य सहित) को मैप्स के एक समूह में रखा गया है। वे उपयोगकर्ताओं को समग्र मेमट्रैक प्रकार स्नैपशॉट, क्वेरी/लोड/संघनन कार्य स्नैपशॉट प्रिंट करने की अनुमति देते हैं, और सबसे अधिक मेमोरी उपयोग या सबसे अधिक मेमोरी ओवरसेज के साथ क्वेरी/लोड का पता लगाते हैं।
एक निश्चित निष्पादन के मेमोरी उपयोग की गणना करने के लिए, वर्तमान थ्रेड के थ्रेड लोकल में स्टैक में एक मेमट्रैकर जोड़ा जाता है। Jemalloc या TCMalloc में malloc/free/realloc को पुनः लोड करके, MemHook आवंटित या जारी की गई मेमोरी का वास्तविक आकार प्राप्त करता है और इसे वर्तमान थ्रेड के थ्रेड लोकल में रिकॉर्ड करता है।
जब निष्पादन पूरा हो जाता है, तो संबंधित मेमट्रैकर को स्टैक से हटा दिया जाएगा। स्टैक के निचले भाग में मेमट्रैकर है जो संपूर्ण क्वेरी/लोड निष्पादन प्रक्रिया के दौरान मेमोरी उपयोग को रिकॉर्ड करता है।
अब, मैं एक सरलीकृत क्वेरी निष्पादन प्रक्रिया के साथ समझाता हूँ।
डोरिस बैकएंड नोड शुरू होने के बाद, सभी थ्रेड्स का मेमोरी उपयोग प्रोसेस मेमट्रैकर में दर्ज किया जाएगा।
जब कोई क्वेरी सबमिट की जाती है, तो क्वेरी मेमट्रैकर को थ्रेड लोकल स्टोरेज (TLS) स्टैक में फ्रैगमेंट निष्पादन थ्रेड में जोड़ा जाएगा।
स्कैननोड निर्धारित होने के बाद, स्कैननोड मेमट्रैकर को फ्रैगमेंट निष्पादन थ्रेड में थ्रेड लोकल स्टोरेज (टीएलएस) स्टैक में जोड़ा जाएगा। फिर, इस थ्रेड में आवंटित या जारी की गई कोई भी मेमोरी क्वेरी मेमट्रैकर और स्कैननोड मेमट्रैकर दोनों में दर्ज की जाएगी।
स्कैनर निर्धारित होने के बाद, स्कैनर थ्रेड के टीएलएस स्टैक में एक क्वेरी मेमट्रैकर और एक स्कैनर मेमट्रैकर जोड़ा जाएगा।
जब स्कैनिंग पूरी हो जाती है, तो स्कैनर थ्रेड टीएलएस स्टैक के सभी मेमट्रैकर्स हटा दिए जाएंगे। जब स्कैननोड शेड्यूलिंग पूरी हो जाती है, तो स्कैननोड मेमट्रैकर को फ्रैगमेंट निष्पादन थ्रेड से हटा दिया जाएगा। फिर, इसी तरह, जब एक एकत्रीकरण नोड निर्धारित किया जाता है, तो एक एकत्रीकरण नोड मेमट्रैकर को फ्रैगमेंट निष्पादन थ्रेड टीएलएस स्टैक में जोड़ा जाएगा और शेड्यूलिंग पूरा होने के बाद हटा दिया जाएगा।
यदि क्वेरी पूरी हो जाती है, तो क्वेरी मेमट्रैकर को फ्रैगमेंट निष्पादन थ्रेड TLS स्टैक से हटा दिया जाएगा। इस बिंदु पर, यह ढेर खाली होना चाहिए। फिर, क्वेरीप्रोफाइल से, आप संपूर्ण क्वेरी निष्पादन के साथ-साथ प्रत्येक चरण (स्कैनिंग, एकत्रीकरण, आदि) के दौरान अधिकतम मेमोरी उपयोग देख सकते हैं।
डोरिस बैकएंड वेब पेज रीयल-टाइम मेमोरी उपयोग प्रदर्शित करता है, जिसे प्रकारों में बांटा गया है: क्वेरी/लोड/संघनन/ग्लोबल। वर्तमान मेमोरी खपत और पीक खपत दिखाई जाती है।
वैश्विक प्रकारों में कैशे और टैबलेटमेटा के मेमट्रैकर्स शामिल हैं।
क्वेरी प्रकारों से, आप वर्तमान मेमोरी खपत और वर्तमान क्वेरी की चोटी की खपत और इसमें शामिल ऑपरेटरों को देख सकते हैं (आप बता सकते हैं कि वे लेबल से कैसे संबंधित हैं)। ऐतिहासिक प्रश्नों की स्मृति आँकड़ों के लिए, आप डोरिस एफई ऑडिट लॉग या बीई इंफो लॉग की जाँच कर सकते हैं।
डोरिस बैकएंड में व्यापक रूप से कार्यान्वित मेमोरी ट्रैकिंग के साथ, हम ओओएम, बैकएंड डाउनटाइम के कारण, और बड़े पैमाने पर क्वेरी विफलताओं को खत्म करने के करीब एक कदम हैं। अगला कदम स्मृति उपयोग को नियंत्रण में रखने के लिए प्रश्नों और प्रक्रियाओं पर स्मृति सीमा को अनुकूलित करना है।
उपयोगकर्ता प्रत्येक क्वेरी पर स्मृति सीमा डाल सकते हैं। यदि निष्पादन के दौरान वह सीमा पार हो जाती है, तो क्वेरी रद्द कर दी जाएगी। लेकिन संस्करण 1.2 के बाद से, हमने मेमोरी ओवरकमिट की अनुमति दी है, जो कि अधिक लचीला मेमोरी लिमिट कंट्रोल है।
यदि पर्याप्त मेमोरी संसाधन हैं, तो कोई क्वेरी रद्द किए बिना सीमा से अधिक मेमोरी का उपभोग कर सकती है, इसलिए उपयोगकर्ताओं को मेमोरी उपयोग पर अतिरिक्त ध्यान नहीं देना पड़ता है; यदि नहीं हैं, तो क्वेरी तब तक प्रतीक्षा करेगी जब तक नई मेमोरी स्पेस आवंटित नहीं की जाती है, जब नई मुक्त मेमोरी क्वेरी के लिए पर्याप्त नहीं होती है तो क्वेरी को रद्द कर दिया जाएगा।
जबकि अपाचे डोरिस 2.0 में, हमने प्रश्नों के लिए अपवाद सुरक्षा को महसूस किया है। इसका मतलब है कि कोई भी अपर्याप्त मेमोरी आवंटन तुरंत क्वेरी को रद्द कर देगा, जो बाद के चरणों में "रद्द करें" स्थिति की जांच करने की परेशानी से बचाता है।
नियमित आधार पर, डोरिस बैकएंड प्रक्रियाओं की भौतिक मेमोरी और सिस्टम से वर्तमान में उपलब्ध मेमोरी आकार को पुनः प्राप्त करता है। इस बीच, यह सभी क्वेरी/लोड/संघनन कार्यों के मेमट्रैकर स्नैपशॉट एकत्र करता है।
यदि बैकएंड प्रक्रिया अपनी मेमोरी सीमा से अधिक हो जाती है या अपर्याप्त मेमोरी है, तो डोरिस कैश को साफ़ करके और कई प्रश्नों या डेटा अंतर्ग्रहण कार्यों को रद्द करके कुछ मेमोरी स्पेस को मुक्त कर देगी। इन्हें एक व्यक्तिगत जीसी थ्रेड द्वारा नियमित रूप से निष्पादित किया जाएगा।
यदि उपयोग की गई प्रक्रिया मेमोरी सॉफ्टमेमलिमिट (डिफ़ॉल्ट रूप से कुल सिस्टम मेमोरी का 81%) से अधिक है, या उपलब्ध सिस्टम मेमोरी चेतावनी वॉटर मार्क (3.2 जीबी से कम) से कम हो जाती है, तो माइनर जीसी ट्रिगर हो जाएगा।
इस समय, मेमोरी आवंटन कदम पर क्वेरी निष्पादन को रोक दिया जाएगा, डेटा अंतर्ग्रहण कार्यों में कैश्ड डेटा को बलपूर्वक फ़्लश किया जाएगा, और डेटा पेज कैश का हिस्सा और पुराना सेगमेंट कैश जारी किया जाएगा।
यदि नई जारी की गई मेमोरी 10% प्रक्रिया मेमोरी को कवर नहीं करती है, तो मेमोरी ओवरकमिट सक्षम होने के साथ, डोरिस 10% लक्ष्य पूरा होने तक या सभी प्रश्नों को रद्द करने तक सबसे बड़ी "ओवरकमिटर्स" क्वेरी को रद्द करना शुरू कर देगी।
फिर, डोरिस सिस्टम मेमोरी चेकिंग अंतराल और जीसी अंतराल को छोटा कर देगा। अधिक मेमोरी उपलब्ध होने के बाद क्वेरीज़ जारी रहेंगी।
यदि उपभोग की गई प्रक्रिया मेमोरी MemLimit (डिफ़ॉल्ट रूप से कुल सिस्टम मेमोरी का 90%) से अधिक है, या उपलब्ध सिस्टम मेमोरी लो वॉटर मार्क (1.6GB से कम) से नीचे चली जाती है, तो पूर्ण GC ट्रिगर हो जाएगा।
इस समय, डेटा अंतर्ग्रहण कार्य रोक दिए जाएंगे, और सभी डेटा पेज कैश और अधिकांश अन्य कैश जारी कर दिए जाएंगे।
यदि, इन सभी चरणों के बाद, नई जारी की गई मेमोरी में प्रोसेस मेमोरी का 20% शामिल नहीं होता है, तो डोरिस सभी मेमट्रैकर्स को देखेगा और सबसे अधिक मेमोरी-खपत प्रश्नों और अंतर्ग्रहण कार्यों को खोजेगा, और उन्हें एक-एक करके रद्द कर देगा।
20% लक्ष्य पूरा होने के बाद ही सिस्टम मेमोरी चेकिंग अंतराल और जीसी अंतराल बढ़ाया जाएगा, और प्रश्न और अंतर्ग्रहण कार्य जारी रहेंगे। (एक कचरा संग्रह ऑपरेशन में आमतौर पर सैकड़ों μs से दर्जनों ms लगते हैं।)
मेमोरी आवंटन, मेमोरी ट्रैकिंग और मेमोरी सीमा में अनुकूलन के बाद, हमने वास्तविक समय के विश्लेषणात्मक डेटा वेयरहाउस प्लेटफॉर्म के रूप में अपाचे डोरिस की स्थिरता और उच्च-संगामिति प्रदर्शन में काफी वृद्धि की है। बैकएंड में ओओएम क्रैश अब एक दुर्लभ दृश्य है।
यहां तक कि अगर कोई ओओएम है, तो उपयोगकर्ता लॉग के आधार पर समस्या की जड़ का पता लगा सकते हैं और फिर इसे ठीक कर सकते हैं। इसके अलावा, प्रश्नों और डेटा अंतर्ग्रहण पर अधिक लचीली मेमोरी सीमाओं के साथ, मेमोरी स्पेस पर्याप्त होने पर उपयोगकर्ताओं को मेमोरी की देखभाल करने के लिए अतिरिक्त प्रयास नहीं करना पड़ता है।
अगले चरण में, हम मेमोरी ओवरकमिटमेंट में प्रश्नों को पूरा करने की योजना बना रहे हैं, जिसका अर्थ है कि मेमोरी की कमी के कारण कम प्रश्नों को रद्द करना होगा।
हमने इस उद्देश्य को कार्य की विशिष्ट दिशाओं में विभाजित किया है: अपवाद सुरक्षा, संसाधन समूहों के बीच स्मृति अलगाव, और मध्यवर्ती डेटा का फ्लशिंग तंत्र।
यदि आप हमारे डेवलपर्स से मिलना चाहते हैं, तो आप हमें यहां ढूंढ सकते हैं ।