एक पायथन एप्लिकेशन में समस्या निवारण मेमोरी लीक

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

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

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

औपचारिक रूप से, परिपत्र लिंक को लीक नहीं कहा जा सकता है: कचरा संग्रह ऐसी वस्तुओं को जल्द या बाद में नष्ट कर देगा। एकमात्र परेशानी यह है कि पायथन यह निर्धारित नहीं कर सकता है कि यह बहुत जल्दी है, लेकिन जब बहुत देर हो चुकी है। मेरे मामले में, सिस्टम ने केवल पायथन के साथ प्रक्रिया को रोक दिया, अगर कचरा संग्रह समय पर शुरू नहीं हुआ।

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

 class Node(object): parent = None def __init__(self, *children): self.children = list(children) for node in self.children: node.parent = self @classmethod def tree(cls, depth=1, children=1): if depth == 0: return [] return [cls(*cls.tree(depth-1, children)) for _ in range(children)] import gc from time import time for n in range(1, 21): for _ in range(n): #   . Node.tree(depth=5, children=6) start = time() print('{1} objects collected for n={0} in {2:3.6} msec'.format( n, gc.collect(), (time() - start) * 1000)) 

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

मेरे आवेदन में वास्तव में यही हुआ है। समस्या का स्थानीयकरण करने वाला कोड इस तरह देखा गया:

 from tornado import web, ioloop, gen ioloop = ioloop.IOLoop.current() class IndexHandler(web.RequestHandler): megabyte_string = "0123456789abcdef" * 64 * 1024 @web.asynchronous @gen.engine def get(self): self.write("Hello, world<br>") yield gen.Task(self.some_task, self.megabyte_string * 20) self.finish() def some_task(self, bigdata, callback): self.write("some task<br>") callback() application = web.Application([(r'/', IndexHandler)], debug=True) if __name__ == "__main__": print("Start on 8888") application.listen(8888) ioloop.start() 

यह IndexHandler.get() पद्धति में url "/" को हैंडल करने वाला सर्वर बनाता है। विधि अतुल्यकालिक है और यह उस कार्य को सेट करती है जिसमें यह डेटा के एक बड़े टुकड़े को स्थानांतरित करता है - 20 मेगाबाइट। जो कार्य करता है वह इतना महत्वपूर्ण नहीं है, क्योंकि पहले से ही इस उदाहरण में एक समस्या है: प्रत्येक अनुरोध के साथ, पायथन प्रक्रिया द्वारा कब्जा की गई मेमोरी की मात्रा इन 20 मेगाबाइट्स से बढ़ जाती है, और किसी भी तरह से प्रत्येक के साथ घटती नहीं है। परिणाम एक साधारण बेंचमार्क है ab -n 100 -c 4 localhost:8888/ ab -n 100 -c 4 localhost:8888/ कुछ बिंदुओं पर मेमोरी की गीगाबाइट खाने में सक्षम है। लेकिन यह एक कॉलबैक के साथ डायरेक्ट कॉल के लिए yield gen.Task() का उपयोग करके टास्क कॉल को बदलने के लायक है, क्योंकि सर्वर आसानी से लोड को yield gen.Task() शुरू कर देता है ab -n 1000 -c 100 localhost:8888/ ab -n 1000 -c 100 localhost:8888/ , 50 एमबी से अधिक मेमोरी का उपभोग नहीं करता है।

  @web.asynchronous @gen.engine def get(self): self.write("Hello, world<br>") self.some_task(self.megabyte_string * 20, self.finish) 

ऐसे मामलों को कैसे डीबग करें? यह देखना अच्छा होगा कि वास्तव में क्या जारी नहीं किया जा रहा है। इसके लिए आपको पहली चीज जो कचरा संग्रह शुरू करने की क्षमता प्रदान करना है, वह यह सुनिश्चित करने के लिए है कि यह कॉलिंग वास्तव में मेमोरी को मुक्त कर दे। मैंने एक और अनुरोध हैंडलर बनाया, जिसे gc.collect() कहा गया और एकत्रित वस्तुओं की संख्या प्रदर्शित की।

 class HealthHandler(web.RequestHandler): def get(self): self.write('{} objects collected'.format(gc.collect())) application = web.Application([(r'/', IndexHandler), (r'/health/', HealthHandler)], debug=True) 

दूसरा - आपको स्वचालित कचरा संग्रह को अक्षम करने की आवश्यकता है। यह प्रयोगों के दौरान एक स्थिर परिणाम प्रदान करेगा। तीसरा - आपको एकत्रित वस्तुओं के बारे में जानकारी चाहिए। जीसी मॉड्यूल में पहले से ही इसके लिए एक तैयार उपकरण है - सूचना को कॉल में gc.collect() दौरान कंसोल में प्रदर्शित किया जाएगा।

 import gc gc.disable() gc.set_debug(gc.DEBUG_LEAK) 

अब इस रिसाव में शामिल वस्तुओं को प्राप्त करना काफी सरल है: आपको उस विधि को चलाना होगा जो बहती है और पते /health/ पर एकत्रित वस्तुओं की सूची प्राप्त करें। फिर एक विधि चलाएं जो प्रवाह नहीं करता है, इसके लिए एक सूची प्राप्त करें। पहली सूची से ऐसी वस्तुएं खोजें जो दूसरी में न हों। यहाँ वे हैं:

 gc: collectable <cell> × 4 gc: collectable <dict> × 3 gc: collectable <function> × 2 gc: collectable <generator> gc: collectable <instancemethod> gc: collectable <Runner> gc: collectable <set> gc: collectable <Task> gc: collectable <tuple> × 3 

स्पष्टता के लिए, मैंने उन्हीं तत्वों का समूह बनाया है। सबसे पहले, गैर-निर्मित प्रकार ब्याज के हैं। यहां यह Task और Runner । यह एक बार फिर साबित करता है कि समस्या कॉल करने के लिए yield gen.Task() लिए, और समस्या कचरा संग्रह में है। यह समझने के लिए बना हुआ है कि Runner क्या Runner और वे एक-दूसरे को Task से क्यों संदर्भित करते हैं। ओपन सोर्स कोड।

यह ध्यान दिया जाना चाहिए कि सभी उदाहरण मेरे शोध के समय टॉरनेडो संस्करण 3.1dev2 के लिए होंगे। @gen.engine डेकोरेटर में बहुत सारे कोड @gen.engine , लेकिन मुख्य बात यह है कि मूल कार्य कहा जाता है, और यदि इसके निष्पादन का परिणाम एक जनरेटर के रूप में निकलता है, तो इसे Runner वर्ग (पकड़ा) जाता है। हमारा Task वह है जो जेनरेटर लौटेगा। इसलिए, आपको Runner वर्ग में एक जगह की तलाश करने की आवश्यकता है जहां जनरेटर को पुनरावृत्त किया जाता है। यह लाइन yielded = self.gen.send(next) । ठीक है, फिर यह देखना बहुत आसान है कि self.yield_point में self.yield_point । और इसके अलावा, self.yield_point .start() विधि को कॉल करता है, जो Runner लिंक बचाता है। यह पता चला है कि Runner.run() विधि को निष्पादित करने के बाद, आपको लिंक को एक तरफ या दूसरे पर तोड़ने की आवश्यकता है। क्योंकि Runner.yield_point केवल अंतिम तत्व के लिए एक संकेतक है, और Task.runner माता-पिता का एक संदर्भ है, यह सूचक को तत्व को रीसेट करने के लिए तर्कसंगत है। यह केवल समझने के लिए बना हुआ है कि Runner.run() विधि अपने निष्पादन को कहां पूरा करती है। क्योंकि एक बवंडर अतुल्यकालिक है, और हम इसके बहुत दिल में स्रोत पर जाते हैं, यह समझना बहुत मुश्किल है कि शीर्ष कहां है और नीचे कहां है। .run() विधि .run() 5 निकास बिंदु हैं, और इसे सभी प्रकार के कॉलबैक से फिर से कॉल किया जाता है। कई प्रयासों के बाद, मुझे एहसास हुआ कि self.finished ऑब्जेक्ट का self.finished फ्लैग कोई self.finished नहीं self.finished , और जहां यह True पर सेट है, self.yield_point को self.yield_point करने की आवश्यकता है।

के साथ परिणाम की जाँच करें ab -n 1000 -c 100 localhost:8888/ ab -n 1000 -c 100 localhost:8888/ । सब ठीक है।

इसे समाप्त करना संभव होगा, लेकिन यह मुझे अजीब लगा। कोई भी अनुरोध स्मृति में असंबद्ध वस्तुओं को क्यों छोड़ता है? शायद इसके साथ कुछ किया जा सकता है। यह पता चला कि फिर भी कोई अनुरोध नहीं है, लेकिन केवल उन पर जो @web.asynchronous डेकोरेटर @web.asynchronous । और असंबंधित वस्तुओं की सूची इस तरह दिखती है:

 gc: collectable <dict> × 7 gc: collectable <list> × 16 gc: collectable <tuple> gc: collectable <instancemethod> gc: collectable <ChunkedTransferEncoding> gc: collectable <ExceptionStackContext> gc: collectable <HTTPHeaders> × 2 gc: collectable <HTTPRequest> gc: collectable <IndexHandler> 

पहले से ही 5 गैर-निर्मित वस्तुएं हैं, और यह स्पष्ट नहीं है कि कहां शुरू करना है। लेकिन मैंने IndexHandler.finish() पद्धति को IndexHandler.finish() करके शुरू किया, जिसमें मैंने उन सभी वस्तुओं के लिंक हटा दिए जो मुझे मिलीं।

 class IndexHandler(web.RequestHandler): @web.asynchronous def get(self): self.write("Hello, world<br>") self.finish() def finish(self, chunk=None): super(IndexHandler, self).finish(chunk) for k, v in self.__dict__.iteritems(): print '"{}":'.format(k), type(v) self.request = None self._headers = None self.application = None self._transforms = None 

इसने एक निश्चित परिणाम दिया, लेकिन समस्या को पूरी तरह से हल नहीं किया। IndexHandler ऑब्जेक्ट्स की संख्या घटकर दो हो गई: ExceptionStackContext IndexHandler और IndexHandler । ExceptionStackContext को self._stack_context_handle_exception तर्क के साथ @web.asynchronous डेकोरेटर के संचालन के दौरान बनाया गया है, जहां self सिर्फ एक IndexHandler । विपरीत दिशा में कोई लिंक नहीं है। ऐसा लगता है कि ExceptionStackContext खुद ExceptionStackContext जिक्र कर रहा है। हम कार्यान्वयन को देखते हैं और देखते हैं कि वास्तव में, .__enter__() विधि वहाँ एक पंक्ति self.new_contexts = (self.old_contexts[0], self) । इसलिए आपको self.new_contexts से .__exit__() तक रीसेट करने की आवश्यकता है, और बिंदु टोपी में है।

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

इस तरह के लीक को ढूंढना और ठीक करना काफी मुश्किल है, खासकर यदि वे स्वयं एप्लिकेशन के कोड में नहीं हैं, लेकिन उपयोग किए गए पुस्तकालयों में। फिर भी, यह कम से कम यह पता लगाने के लायक है कि क्या आपके पास उन्हें आवेदन में है और यह सुनिश्चित करें कि उनकी वजह से आपकी याद में कोई भारी वस्तु नहीं लटक रही है।