मेमोरी लीक के तीन प्रकार

नमस्कार साथियों!

कोड ऑप्टिमाइज़ेशन पर टाइमलेस बेस्ट-सेलिंग किताबों की हमारी लंबी खोज से केवल पहले परिणाम मिले हैं, लेकिन हम आपको यह बताने के लिए तैयार हैं कि बेन वॉटसन की पौराणिक पुस्तक " राइटिंग हाई परफॉर्मेंस .NET कोड " का अनुवाद अभी पूरा हुआ है। दुकानों में - अप्रैल में अस्थायी रूप से, विज्ञापन के लिए देखें।

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

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

प्रकार (1): अनुपलब्ध स्मृति खंड आवंटित

यह C / C ++ में एक क्लासिक मेमोरी लीक है। किसी ने new या malloc का उपयोग करके मेमोरी आवंटित की, और इसके साथ काम करने के बाद मेमोरी को फ्री करने के लिए मुफ्त कॉल या delete नहीं किया।

 void leak_memory() { char *leaked = malloc(4096); use_a_buffer(leaked); /* ,   free() */ } 

यह कैसे निर्धारित किया जाए कि कोई रिसाव इस श्रेणी का है

• यदि आप C या C ++ में लिखते हैं, विशेष रूप से C ++ स्मार्ट पॉइंटर्स के व्यापक उपयोग के बिना मेमोरी सेगमेंट के जीवन काल को नियंत्रित करने के लिए, तो यह वह विकल्प है जिस पर हम पहले विचार कर रहे हैं।
• यदि प्रोग्राम कचरे के संग्रह के साथ एक वातावरण में चल रहा है, तो संभव है कि इस प्रकार का रिसाव देशी कोड एक्सटेंशन द्वारा उकसाया जाता है, हालांकि, प्रकारों के लीक (2) और (3) को पहले समाप्त करना होगा।

ऐसे लीक को कैसे खोजा जाए

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

टाइप (2): अनियोजित लंबे समय तक स्मृति आवंटन

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

• एक वैश्विक संरचना में राज्य का अज्ञात संचय; उदाहरण के लिए, HTTP सर्वर वैश्विक सूची में प्रत्येक को Request प्राप्त वस्तु को लिखता है।
• एक सुविचारित अप्रचलन नीति के बिना कैश। उदाहरण के लिए, एक ORM कैश जो हर एक लोडेड ऑब्जेक्ट को कैश करता है, माइग्रेशन के दौरान सक्रिय रहता है, जिसमें टेबल में मौजूद सभी रिकॉर्ड बिना किसी अपवाद के लोड होते हैं।
• सर्किट में बहुत अधिक ज्वालामुखी की स्थिति होती है। यह मामला विशेष रूप से जावा स्क्रिप्ट में आम है, लेकिन यह अन्य वातावरणों में भी हो सकता है।
• एक व्यापक अर्थ में, किसी सरणी या स्ट्रीम के प्रत्येक तत्व के अनजाने प्रतिधारण, जबकि यह माना गया था कि इन तत्वों को ऑनलाइन स्ट्रीमिंग संसाधित किया जाएगा।

यह कैसे निर्धारित किया जाए कि कोई रिसाव इस श्रेणी का है

• यदि प्रोग्राम कचरा संग्रह के साथ पर्यावरण में चलता है, तो यह वह विकल्प है जिसे हम पहले मान रहे हैं।
• ऑपरेटिंग सिस्टम द्वारा उत्पन्न मुक्त मेमोरी के आकार के साथ कचरा कलेक्टर आँकड़ों में प्रदर्शित ढेर के आकार की तुलना करें। यदि कोई रिसाव इस श्रेणी में आता है, तो संख्या तुलनीय होगी और, सबसे महत्वपूर्ण बात, समय के साथ एक दूसरे का पालन करेंगे।

ऐसे लीक को कैसे खोजा जाए

अपने वातावरण में उपलब्ध प्रोफाइलर्स या हीप डंप टूल्स का उपयोग करें। मुझे पता है कि रूबी में पायथन या मैमोरी_प्रोफाइलर में गप्पी है, और मैंने रूबी में सीधे ऑब्जेक्टस्पेस भी लिखा था।

प्रकार (3): मुक्त लेकिन अप्रयुक्त या अनुपयोगी स्मृति

इस श्रेणी को चिह्नित करना सबसे कठिन है, लेकिन इसे समझना और ध्यान में रखना सबसे महत्वपूर्ण है।

इस प्रकार की लीक स्मृति के बीच ग्रे ज़ोन में होती है, जिसे वीएम या रनटाइम वातावरण के अंदर आवंटनकर्ता के दृष्टिकोण से "मुक्त" माना जाता है, और स्मृति, जो ऑपरेटिंग सिस्टम के दृष्टिकोण से "मुक्त" है। इस घटना का सबसे आम (लेकिन एकमात्र नहीं) कारण ढेर विखंडन है । कुछ आवंटनकर्ता बस ले जाने के बाद ऑपरेटिंग सिस्टम को मेमोरी नहीं लेते हैं और वापस नहीं करते हैं।

इस तरह के एक मामले को पायथन में लिखे एक छोटे कार्यक्रम के उदाहरण के साथ माना जा सकता है:

 import sys from guppy import hpy hp = hpy() def rss(): return 4096 * int(open('/proc/self/stat').read().split(' ')[23]) def gcsize(): return hp.heap().size rss0, gc0 = (rss(), gcsize()) buf = [bytearray(1024) for i in range(200*1024)] print("start rss={} gcsize={}".format(rss()-rss0, gcsize()-gc0)) buf = buf[::2] print("end rss={} gcsize={}".format(rss()-rss0, gcsize()-gc0)) 

हम 200,000 1-केबी बफ़र आवंटित करते हैं, और फिर प्रत्येक बाद में बचाते हैं। हर सेकंड, हम ऑपरेटिंग सिस्टम के दृष्टिकोण से और अपने स्वयं के पायथन कचरा कलेक्टर के दृष्टिकोण से मेमोरी स्टेट प्रदर्शित करते हैं।

मेरे लैपटॉप पर, मुझे कुछ ऐसा मिलता है:

start rss=232222720 gcsize=11667592
end rss=232222720 gcsize=5769520

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

स्मृति के ऐसे मुक्त लेकिन अप्रयुक्त टुकड़े समस्याग्रस्त और हानिरहित दोनों हो सकते हैं। यदि एक पायथन कार्यक्रम इस तरह से कार्य करता है और फिर 1kb टुकड़े का आवंटन करता है, तो यह स्थान बस पुन: उपयोग किया जाता है, और सब कुछ ठीक है।

लेकिन, अगर हमने प्रारंभिक सेटअप के दौरान ऐसा किया है, और बाद में एक न्यूनतम को मेमोरी आवंटित की है, या यदि बाद में आवंटित किए गए सभी टुकड़े 1.5kb हैं और इन बफ़र्स में पहले से फिट नहीं होते हैं, तो इस तरह से आवंटित सभी मेमोरी हमेशा निष्क्रिय रहेंगी बर्बाद हो जाएगा।

रूबी या पाइथन जैसी भाषाओं के साथ काम करने के लिए मल्टीप्रोसेस सर्वर सिस्टम में इस तरह की समस्याएं विशेष रूप से एक विशिष्ट वातावरण में प्रासंगिक हैं।

मान लीजिए कि हमने एक प्रणाली स्थापित की है जिसमें:

• प्रत्येक सर्वर पर, एन एकल-थ्रेडेड श्रमिकों को सक्षम रूप से अनुरोधों को पूरा करने के लिए उपयोग किया जाता है। सटीकता के लिए N = 10 लेते हैं।
• एक नियम के रूप में, प्रत्येक कर्मचारी के पास लगभग स्थिर मात्रा में मेमोरी होती है। सटीकता के लिए, आइए 500MB लें।
• कुछ कम आवृत्ति के साथ, हमें अनुरोध प्राप्त होते हैं, जिसमें माध्यिका अनुरोध की तुलना में बहुत अधिक मेमोरी की आवश्यकता होती है। सटीकता के लिए, मान लें कि एक बार एक मिनट के लिए हमें एक अनुरोध मिलता है, जिसके निष्पादन समय के लिए अतिरिक्त 1GB मेमोरी की आवश्यकता होती है, और जब अनुरोध संसाधित होता है, तो यह मेमोरी फ़्री हो जाती है।

एक बार एक मिनट के लिए, इस तरह के "सिटासियन" अनुरोध आता है, जिसके प्रसंस्करण को हम 10 श्रमिकों में से एक को सौंपते हैं, उदाहरण के लिए, यादृच्छिक रूप से: ~random । आदर्श रूप से, इस अनुरोध के प्रसंस्करण के दौरान, इस कर्मचारी को 1 जीबी रैम आवंटित करना चाहिए, और काम खत्म होने के बाद, इस मेमोरी को ऑपरेटिंग सिस्टम पर लौटाएं ताकि बाद में इसका पुन: उपयोग किया जा सके। इस सिद्धांत द्वारा असीमित रूप से अनुरोधों को संसाधित करने के लिए, सर्वर को केवल 10 * 500MB + 1GB = 6GB RAM की आवश्यकता होगी।

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

जब आप सर्वर शुरू करते हैं, तो आप देखेंगे कि उपयोग की जाने वाली मेमोरी की मात्रा 10 * 500MB = 5GB है। जैसे ही पहला बड़ा अनुरोध आता है, पहले कार्यकर्ता 1GB मेमोरी लेता है, और फिर उसे वापस नहीं देता है। उपयोग की जाने वाली मेमोरी की कुल मात्रा 6GB तक बढ़ जाएगी। निम्नलिखित आवक अनुरोधों को कभी-कभी उस प्रक्रिया पर पुनर्निर्देशित किया जा सकता है जो पहले "व्हेल" संसाधित करता था, जिस स्थिति में उपयोग की जाने वाली स्मृति की मात्रा नहीं बदलेगी। लेकिन कभी-कभी इतने बड़े अनुरोध को किसी अन्य कर्मचारी को वितरित किया जाएगा, जिसके कारण मेमोरी को 1GB के लिए और फुलाया जाएगा, और तब तक जब तक कि प्रत्येक कर्मचारी को कम से कम एक बार इतने बड़े अनुरोध को संसाधित करने का अवसर न हो। इस स्थिति में, आप इन ऑपरेशनों के साथ 10 * (500MB + 1GB) = 15GB RAM लेंगे, जो आदर्श 6GB से बहुत अधिक है! इसके अलावा, यदि आप देखते हैं कि समय के साथ सर्वर बेड़े का उपयोग कैसे किया जाता है, तो आप देख सकते हैं कि उपयोग की गई मेमोरी धीरे-धीरे 5GB से 15GB तक कैसे बढ़ जाती है, जो एक "वास्तविक" लीक की बहुत याद दिलाता है।

यह कैसे निर्धारित किया जाए कि कोई रिसाव इस श्रेणी का है

• ऑपरेटिंग सिस्टम द्वारा उत्पन्न मुक्त मेमोरी के आकार के साथ कचरा कलेक्टर आँकड़ों में प्रदर्शित ढेर के आकार की तुलना करें। यदि रिसाव इस (तृतीय) श्रेणी का है, तो समय के साथ संख्या में परिवर्तन होगा।
• मैं अपने एप्लिकेशन सर्वर को कॉन्फ़िगर करना पसंद करता हूं ताकि ये दोनों संख्याएं समय-समय पर मेरी समय श्रृंखला के बुनियादी ढांचे में बंद हो जाएं, इसलिए उन पर रेखांकन प्रदर्शित करना सुविधाजनक है।
• लिनक्स पर, ऑपरेटिंग सिस्टम की स्थिति 24 /proc/self/stat क्षेत्र में देखें, और किसी भाषा या वर्चुअल कंप्यूटर विशिष्ट API के माध्यम से मेमोरी एलोकेटर देखें।

ऐसे लीक को कैसे खोजा जाए

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

• अपनी प्रक्रियाओं को अधिक बार पुनरारंभ करें। यदि समस्या धीरे-धीरे बढ़ती है, तो शायद हर 15 मिनट या प्रति घंटे एक बार सभी आवेदन प्रक्रियाओं को फिर से शुरू करना मुश्किल नहीं हो सकता है।
• एक और भी अधिक कट्टरपंथी दृष्टिकोण: आप सभी प्रक्रियाओं को स्वतंत्र रूप से पुनरारंभ करने के लिए सिखा सकते हैं, जैसे ही वे जिस स्थान पर स्मृति में रहते हैं वह एक निश्चित सीमा मूल्य से अधिक हो जाता है या पूर्व निर्धारित मूल्य से बढ़ता है। हालाँकि, यह पूर्वाभास करने की कोशिश करें कि आपके सर्वर का पूरा बेड़ा एक सहज तुल्यकालिक पुनः आरंभ नहीं कर सकता है।
• मेमोरी एलोकेटर बदलें। लंबे समय में, tcmalloc और jemalloc आम तौर पर विखंडन को डिफ़ॉल्ट आवंटनकर्ता से बेहतर तरीके से संभालते हैं, और LD_PRELOAD चर का उपयोग करके उनके साथ प्रयोग करना बहुत सुविधाजनक होता है।
• पता लगाएँ कि क्या आपके पास अलग-अलग प्रश्न हैं जो बाकी की तुलना में बहुत अधिक मेमोरी का उपभोग करते हैं। स्ट्राइप पर, हमारे एपीआई सर्वर प्रत्येक एपीआई अनुरोध की सेवा करने से पहले और डेल्टा लॉग करने के बाद (निरंतर मेमोरी खपत) को मापते हैं। फिर, हम आसानी से अपने लॉग एकत्रीकरण प्रणालियों को यह निर्धारित करने के लिए क्वेरी करते हैं कि क्या ऐसे टर्मिनल और उपयोगकर्ता (और पैटर्न) हैं जिनका उपयोग मेमोरी खपत के फटने को लिखने के लिए किया जा सकता है।
• कचरा संग्रहकर्ता / मेमोरी एलोकेटर को समायोजित करें। उनमें से कई में अनुकूलन योग्य पैरामीटर हैं जो आपको यह निर्दिष्ट करने की अनुमति देते हैं कि इस तरह के तंत्र सक्रिय रूप से मेमोरी को कैसे लौटाएगा, विखंडन को खत्म करने के लिए यह कितना अनुकूलित है; अन्य उपयोगी विकल्प हैं। यहां सब कुछ भी काफी जटिल है: सुनिश्चित करें कि आप वास्तव में वही समझ रहे हैं जो आप माप रहे हैं और अनुकूलन कर रहे हैं, और उपयुक्त आभासी मशीन पर एक विशेषज्ञ को खोजने और उसके साथ परामर्श करने का भी प्रयास करें।