👨🏽‍🚒 🏩 👐🏽 प्लम्बर प्रोग्रामर, या एक लीक की कहानी और इससे निपटने की मुश्किलें 👙 🧔 🥫

25 फरवरी मंगलवार था। शनिवार, 22 फरवरी को संस्करण की मुश्किल रिलीज पहले से ही थी। ऐसा लगता था कि सभी सबसे खराब पीछे थे, और कुछ भी परेशान नहीं था। लेकिन सब कुछ एक समय में बदल गया जब एक निगरानी त्रुटि एक्सेस कंट्रोल सेवा के समन्वयक प्रक्रिया पर एक स्मृति रिसाव के बारे में आई।

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

पहले हम एक छोटा सा विषयांतर करते हैं। अन्य बातों के अलावा, वीएलएसआई आपको काम के घंटों का ट्रैक रखने और फेस मॉडल, फिंगरप्रिंट या एक्सेस कार्ड द्वारा पहुंच की निगरानी करने की अनुमति देता है । उसी समय, वीएलएसआई समापन बिंदु नियंत्रकों (ताले, टर्नस्टाइल, एक्सेस टर्मिनल, आदि) के साथ संचार करता है। उपकरणों के साथ एक अलग सेवा संचार करती है। यह निष्क्रिय है, HTTP (एस) पर लागू अपने स्वयं के प्रोटोकॉल के आधार पर अभिगम नियंत्रण उपकरणों के साथ सहभागिता करता है। यह हमारी कंपनी में सेवाओं के लिए मानक स्टैक के आधार पर लिखा गया है: PostgreSQL डेटाबेस, पायथन 3 का उपयोग व्यावसायिक तर्क के लिए किया जाता है, हमारे मंच से C / C ++ विधियों के साथ विस्तारित किया जाता है।

एक सामान्य वेब सेवा नोड में निम्नलिखित प्रक्रियाएँ होती हैं:

मॉनिटर रूट प्रक्रिया है।
एक समन्वयक एक मॉनिटर की एक बच्चे की प्रक्रिया है।
काम की प्रक्रिया।

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

किसे दोष देना है और क्या करना है?

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

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

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

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

ऐसा लगता था कि हमारे पास पायथन में आवंटित मेमोरी पर ट्रेसमैलोक के काम के परिणाम थे, अब हम उन पर गौर करेंगे और लीक के दोषी को ढूंढेंगे, लेकिन यह वहां नहीं था - एकत्र किए गए आंकड़ों में कोई 5.5 इंच की चोटियां नहीं हैं जो हमने निगरानी ग्राफ़ पर देखी थीं। अधिकतम इस्तेमाल की जाने वाली मेमोरी केवल 250MB है, और यहां तक कि ट्रेसमॉलोक उनमें से 130MB खाती है। यह आंशिक रूप से व्याख्या करने योग्य है - ट्रेसमैलोक आपको पायथन में मेमोरी डायनेमिक्स देखने की अनुमति देता है, लेकिन यह सी और सी ++ पैकेज में मेमोरी आवंटन के बारे में नहीं जानता है जो हमारे मंच द्वारा कार्यान्वित किए जाते हैं। प्राप्त आंकड़ों में कुछ दिलचस्प खोजना संभव नहीं था, स्मृति को साधारण वस्तुओं जैसे कि धाराओं, तारों और शब्दकोशों में स्वीकार्य मात्रा में आवंटित किया जाता है - सामान्य तौर पर, कुछ भी संदिग्ध नहीं है। तब हमने डेटा से सभी चीज़ों को हटाने का फैसला किया, जो केवल कुल मेमोरी खपत और समय को छोड़ कर कल्पना करता है।हालांकि विज़ुअलाइज़ेशन ने "क्या हो रहा है" और "क्यों" सवालों के जवाब देने में मदद नहीं की, इसकी मदद से हमने निगरानी से डेटा के साथ एक संबंध देखा - जिसका अर्थ है कि हमें निश्चित रूप से कहीं समस्या है, और हमें इसकी तलाश करने की आवश्यकता है।

उस समय, हमारी प्लम्बर टीम एक लीक की तलाश करने के लिए विचारों से बाहर भाग गई। सौभाग्य से, पक्षी ने हमारे लिए गाया कि मंच से एक बड़ा बदलाव हुआ - पायथन संस्करण 3.4 से 3.7 तक बदल गया, और यह एक बहुत बड़ा खोज क्षेत्र है।

हमने इंटरनेट पर पायथन 3.7 में मेमोरी लीक से संबंधित समस्याओं को देखने का निर्णय लिया, क्योंकि निश्चित रूप से किसी को इस व्यवहार का सामना करना पड़ा था। फिर भी, पाइथन 3.7 को बहुत पहले प्रकाशित किया गया था, हमने इसे केवल वर्तमान अपडेट के साथ बदल दिया। सौभाग्य से, हमारे सवाल का जवाब जल्दी से मिल गया था, और समस्या को ठीक करने के लिए मुद्दा और पुल-अनुरोध भी था , और वह खुद पायथन डेवलपर्स द्वारा किए गए परिवर्तनों में थी।
क्या हुआ?

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

यहाँ यह एक बड़ा छेद के साथ पायथन मॉड्यूल का कपटी कोड है (पायथन 3.5 में कोड को बाईं ओर परिवर्तन से पहले दिखाया गया है, दाईं ओर - 3.7 में, बाद में):

कारण का पता लगाते हुए, हमने आसानी से रिसाव को समाप्त कर दिया: हमारे उत्तराधिकारी वर्ग में, हमने पुराने व्यवहार को वापस करने वाले ध्वज का मूल्य बदल दिया, और यह सब - एक जीत है! धाराओं को पहले की तरह बनाया जाता है, वर्ग चर को लिखे बिना, लेकिन हम मॉनिटरिंग ग्राफ़ पर एक सुखद तस्वीर का निरीक्षण करते हैं - रिसाव को ठीक कर दिया गया है!

जीत के बाद इस बारे में लिखना अच्छा है। हम शायद पहले पायथन 3.7 पर स्विच करने के बाद इस समस्या का सामना करने वाले नहीं हैं, लेकिन सबसे अधिक संभावना आखिरी नहीं है। अपने लिए, हमने निष्कर्ष निकाला कि हमें आवश्यकता है:

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

खैर, मैं उन सभी के प्रति अपना आभार व्यक्त करना चाहता हूं, जिन्होंने आपातकालीन प्लंबिंग कार्य का सामना करने में मदद की और एक बार फिर अपनी पूर्व कार्य क्षमता के लिए हमारी सेवा में वापस लौटे!

प्लम्बर प्रोग्रामर, या एक लीक की कहानी और इससे निपटने की मुश्किलें

किसे दोष देना है और क्या करना है?

More articles: