पार्सिंग: कुबेरनेट्स पर ओओएम

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

केस एक

शनिवार, 15 जून, 2019 5:12 बजे।

ब्लू मैटाडोर (हाँ, हम खुद पर नज़र रखते हैं!) एक अलर्ट उत्पन्न करता है: कुबेरनेट्स उत्पादन क्लस्टर में एक नोड पर एक घटना - सिस्टमओम।

17:16

ब्लू मैटाडोर एक चेतावनी उत्पन्न करता है: नोड की मूल मात्रा में कम ईबीएस बर्स्ट बैलेंस - जहां सिस्टमओम इवेंट हुआ था। हालांकि सिस्टमस्टॉम के बारे में एक अधिसूचना के बाद बर्स्ट बैलेंस के बारे में एक चेतावनी आई, वास्तविक क्लाउडवेच डेटा से पता चलता है कि बर्स्ट बैलेंस न्यूनतम स्तर 17:02 पर पहुंच गया है। देरी का कारण यह है कि ईबीएस मैट्रिक्स लगातार 10-15 मिनट पीछे हैं, और हमारा सिस्टम वास्तविक समय में सभी घटनाओं को नहीं पकड़ता है।

17:18

अभी मैंने एक चेतावनी और चेतावनी देखी। मैं जल्दी से चलाता हूं कि कुबेटेल को यह देखने के लिए कि हमें क्या नुकसान हुआ है, और मुझे यह जानकर आश्चर्य हुआ कि आवेदन में फली की मृत्यु ठीक 0. हुई थी। मैं कुबेकत्ल शीर्ष नोड्स का प्रदर्शन करता हूं , लेकिन यह जांच यह भी दिखाती है कि संदिग्ध नोड में मेमोरी समस्या है; सच है, यह पहले से ही लगभग 60% मेमोरी को पुनर्प्राप्त और उपयोग करता है। यह शाम 5 बजे है, और शिल्प बियर पहले से ही गर्म है। यह सुनिश्चित करने के बाद कि नोड चालू था और एक भी फली क्षतिग्रस्त नहीं हुई थी, मैंने फैसला किया कि एक दुर्घटना हुई थी। कुछ भी हो, मैं सोमवार को इसका पता लगाऊंगा।

उस शाम स्लैक में सर्विस स्टेशन के साथ हमारा पत्राचार है:

केस दो

शनिवार, 16 जून, 2019 शाम 6:02 बजे।

ब्लू मैटाडोर एक अलर्ट उत्पन्न करता है: घटना पहले से ही दूसरे नोड पर भी है, सिस्टमओम भी। यह रहा होगा कि उस समय सेवा स्टेशन सिर्फ स्मार्टफोन की स्क्रीन को देख रहा था, क्योंकि इसने मुझे लिखा था और मुझे तुरंत घटना को अंजाम देने के लिए बनाया था, मैं खुद कंप्यूटर चालू नहीं कर सकता (क्या यह फिर से विंडोज को पुनर्स्थापित करने का समय है?)। और फिर, सब कुछ सामान्य लगता है। एक भी फली नहीं मारी जाती है, और नोड में शायद ही 70% मेमोरी होती है।

18:06

ब्लू मैटाडोर फिर से एक चेतावनी उत्पन्न करता है: ईबीएस बर्स्ट बैलेंस। एक दिन में दूसरी बार, जिसका अर्थ है कि मैं इस समस्या को ब्रेक पर जारी नहीं कर सकता। क्लाउडवॉच के अपरिवर्तित होने से, समस्या की पहचान होने से पहले बर्स्ट बैलेंस 2 घंटे या उससे अधिक समय के मानदंड से भटक गया।

18:11

मैं Datalog पर जाता हूं और मेमोरी खपत के डेटा को देखता हूं। मुझे लगता है कि SystemOOM इवेंट से ठीक पहले, संदिग्ध नोड ने वास्तव में बहुत सारी मेमोरी ले ली थी। निशान हमारी धाराप्रवाह-शिखरवादी फली की ओर जाता है।

आप मेमोरी खपत में एक तेज विचलन को स्पष्ट रूप से देख सकते हैं, उसी समय जब सिस्टमओम घटनाएँ हुईं। मेरा निष्कर्ष: यह इन पॉड्स थे जो सभी मेमोरी ले गए, और जब सिस्टमऑम हुआ, तो कुबेरनेट्स ने महसूस किया कि इन पॉड्स को मार दिया जा सकता है और मेरी अन्य पॉड्स को प्रभावित किए बिना आवश्यक मेमोरी वापस करने के लिए पुनः आरंभ किया जा सकता है। अच्छा किया, कुबेरनेट्स!

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

निष्कर्ष 1: पुनरारंभ किए गए पॉड्स की तलाश करते समय, सभी नामस्थानों की जांच करें।

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

23:00

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

मरम्मत

सोमवार को, मैंने इस समस्या के लिए समय दिया। यह हर रात उसके साथ शिकार करने से आहत नहीं होता है। फिलहाल मुझे क्या पता:

• फ्लुंटेड-समोलोगिक कंटेनरों ने एक टन मेमोरी को टटोला;
• SystemOOM घटना उच्च डिस्क गतिविधि से पहले है, लेकिन मुझे नहीं पता कि कौन सा है।

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

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

env: - name: RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR value: "0.9" 

धाराप्रवाह-शिखर वार्ता के माध्यम से देखते हुए, मैंने देखा कि मैंने संसाधन अनुरोधों और प्रतिबंधों को परिभाषित नहीं किया है। मुझे संदेह होने लगा है कि RUBY_GCP_HEAP फिक्स किसी प्रकार का चमत्कार कर देगा, इसलिए अब यह मेमोरी मेमोरी लिमिट सेट करने के लिए समझ में आता है। यहां तक ​​कि अगर मैं मेमोरी समस्या को ठीक नहीं करता हूं, तो कम से कम पॉड्स के इस सेट तक इसकी खपत को सीमित करना संभव होगा। कुब्तेल टॉप पॉड्स का उपयोग करना | grep fluentd-sumologic , मुझे पहले से ही पता है कि अनुरोध करने के लिए कितने संसाधन हैं:

 resources: requests: memory: "128Mi" cpu: "100m" limits: memory: "1024Mi" cpu: "250m" 

निष्कर्ष 2: संसाधन सीमाएँ निर्धारित करें, विशेष रूप से तृतीय-पक्ष अनुप्रयोगों के लिए।

निष्पादन सत्यापन

कुछ दिनों के बाद, मैं पुष्टि करता हूं कि उपरोक्त विधि काम करती है। मेमोरी की खपत स्थिर थी, और कुबेरनेट्स, ईसी 2 और ईबीएस के किसी भी घटक के साथ कोई समस्या नहीं थी। अब यह स्पष्ट है कि मेरे द्वारा चलाए गए सभी पॉड्स के लिए संसाधन अनुरोधों और प्रतिबंधों को परिभाषित करना कितना महत्वपूर्ण है, और यहां क्या करना है: डिफ़ॉल्ट संसाधन सीमाओं और संसाधन कोटा का संयोजन लागू करें।

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

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

निष्कर्ष 3: जहां एक अवसर है, जड़ के कारणों का विश्लेषण करते समय गहरी खुदाई करें, जो भी समस्या हो।

निष्कर्ष

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