इसे बढ़ाने और इतना विस्तार प्रदान करने के लिए धन्यवाद!

मुझे बताओ, क्या आपको कभी भी मेमोरी उपयोग किसी भी बिंदु पर नीचे जाता है?

मैंने स्मृति उपयोग को नीचे जाते नहीं देखा है। मैं सोच रहा था कि इसे पायथन के कचरा कलेक्टर के साथ क्या करना है और शायद यह सिर्फ किक करने का अवसर नहीं था, इसलिए मैंने प्रत्येक डाउनलोड के बाद gc.collect() कॉल जोड़ा। इससे कोई फर्क नहीं पड़ा।

क्या मैं पूछ सकता हूं कि यह मुद्दा क्यों बंद कर दिया गया है?

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

इस समस्या की गंभीरता को उजागर करने के लिए, यहाँ एक मेमोरी प्रॉइलर को चलाते समय हमारी सर्वर प्रक्रियाओं में से एक का स्क्रीनशॉट देखा गया है:
http://cl.ly/image/3X3G2y3Y191h

समस्या अभी भी नियमित रूप से मौजूद है, लेकिन कम ध्यान देने योग्य है। शायद, यही कारण है कि इस मुद्दे को अप्रतिबंधित किया गया है, लंबे समय से स्थायी प्रक्रियाओं के लिए इस पुस्तकालय का उपयोग करने वालों के लिए गंभीर परिणामों के बावजूद।

इस बिंदु पर, हम एक उपप्रकार के साथ कर्ल का उपयोग करने पर विचार करने के लिए पर्याप्त हताश हैं।

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

धन्यवाद,
-मैट

निष्क्रियता के कारण इसे बंद कर दिया गया था। यदि आपको लगता है कि आप हमें सही दिशा में इंगित करने के लिए उपयोगी निदान प्रदान कर सकते हैं, तो हमें फिर से खुश होना चाहिए।

खैर, मुझे तब मदद करने की अनुमति दें।

मैंने इस मुद्दे की परीक्षा में मदद करने के लिए छोटे git रेपो बनाए।
https://github.com/mhjohnson/memory-profiling-requests

यहाँ ग्राफ़ का एक स्क्रीनशॉट है जो इसे उत्पन्न करता है:
http://cl.ly/image/453h1y3a2p1r

उम्मीद है की यह मदद करेगा! अगर मैंने कुछ गलत किया है तो मुझे बताएं।

-मैट

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

तो यह लगभग 0.1MB / अनुरोध पर बढ़ता है। मैंने निचले स्तर के तरीकों पर profile डेकोरेटर को चिपकाने की कोशिश की, लेकिन वे सभी बहुत लंबे समय तक आउटपुट के लिए उपयोगी होते हैं और 0.1 से अधिक अंतराल का उपयोग करने से लगता है कि केवल समग्र उपयोग को ट्रैक करने के लिए सेवा करते हैं, न कि प्रति- लाइन का उपयोग। क्या मितली से बेहतर उपकरण हैं?

इसलिए मैंने पाइप के बजाय यह तय किया कि यह आउटपुट | ag '.*0\.[1-9]+ MiB.*' है जहां मेमोरी जोड़ी जाती है और profile डेकोरेटर को Session#send ले जाया जाता है। अप्रत्याशित रूप से, इसका अधिकांश भाग HTTPAdapter#send कॉल से आ रहा है। खरगोश के छेद के नीचे मैं जाता हूं

और अब यह सब L355 पर conn.urlopen कॉल और HTTPAdapter#get_connection कॉल से आ रहा है। यदि आप get_connection सजाते हैं, तो PoolManager#connection_from_url कॉल करने पर यह 7 बार मेमोरी आवंटित करता है। अब बहुमत को देखते हुए HTTPResponse urllib3 से लौटाए जा रहे हैं, मैं यह देखने जा रहा हूं कि क्या हम कुछ ऐसा कर रहे हैं जो _should_ उनके साथ कर रहा है कि हम यह सुनिश्चित नहीं कर पा रहे हैं कि मेमोरी फैक्ट के बाद रिलीज़ हुई है। अगर मुझे इसे संभालने का अच्छा तरीका नहीं मिल रहा है, तो मैं urllib3 में खुदाई शुरू करूँगा।

@ सिगमावायरस 24 वाह। अच्छा कार्य! ऐसा लगता है कि आपने कोड में गर्म स्थान को इंगित किया हो सकता है।
मेमोरी लीक के लिए कौन सी वस्तु जिम्मेदार है, इसका पता लगाने के लिए, आपको कुछ अतिरिक्त संकेत प्राप्त करने पड़ सकते हैं जैसे कि आप

import gc
import objgraph
# garbage collect first
gc.collect()  
# print most common python types
objgraph.show_most_common_types()

Lemme पता है कि क्या मैं किसी भी तरह से मदद कर सकता हूं।

-मैट

अपराधी के रूप में मेरा पहला अनुमान सॉकेट ऑब्जेक्ट होगा। यही कारण है कि यह PyPy पर बदतर क्यों है समझा जाएगा ...

मैं अभी एक हवाई अड्डे पर बैठा हूं और जल्द ही कई घंटों के लिए मैदान पर रहूंगा। मैं शायद आज रात या इस सप्ताह के अंत तक (यदि अगले सप्ताह / सप्ताह तक नहीं) तक नहीं जा पाऊँगा। हालांकि अब तक, मैंने release_conn HTTPResponse हम वापस प्राप्त करने का प्रयास किया। मैंने gc.get_referents साथ जाँच की कि रिस्पांस ऑब्जेक्ट में क्या GC'd होने में विफल हो सकता है। इसका मूल कैंपप्लिब HTTPResponse ( _original_response रूप में संग्रहीत है और जो get_referents रिपोर्ट किया गया है) से केवल एक ईमेल संदेश (हेडर के लिए) और बाकी सब या तो एक स्ट्रिंग या शब्दकोश (या हो सकता है) सूची)। यदि यह सॉकेट्स है, तो मैं नहीं देखता कि वे कहां से कचरा एकत्र नहीं किया जाएगा।

इसके अलावा, Session#close (मैंने पहले कार्यात्मक एपीआई के बजाय कोड उपयोग सत्र बनाया) मदद नहीं करता है (और इससे पूलमैन को साफ करना चाहिए जो कनेक्शन पूल को साफ करते हैं)। तो दूसरी बात जो दिलचस्प थी, वह यह थी कि PoolManager#connection_from_url ~ 0.8 MB (दे या 0.1 लें) को पहले कुछ समय कहा जाता था। इस तरह ~ 3MB जुड़ जाता है लेकिन इसका बाकी हिस्सा conn.urlopen HTTPAdapter#send । विचित्र बात यह है कि यदि आप gc.set_debug(gc.DEBUG_LEAK) उपयोग करते हैं तो gc.garbage में कुछ विषम तत्व हैं। यह [[[...], [...], [...], None], [[...], [...], [...], None], [[...], [...], [...], None], [[...], [...], [...], None]] तरह कुछ है और जैसा कि आप gc.garbage[0] is gc.garbage[0][0] उम्मीद करेंगे ताकि जानकारी बिल्कुल बेकार हो। मौका मिलने पर मुझे ओब्जैग्राफ के साथ प्रयोग करना होगा।

इसलिए मैंने urllib3 में खुदाई की और आज सुबह पहले खरगोश के छेद का पीछा किया। मैंने ConnectionPool#urlopen प्रोफाइल बनाया है जो मुझे ConnectionPool#_make_request । इस बिंदु पर, urllib3/connectionpool.py में लाइनों 306 और 333 से आवंटित बहुत सी मेमोरी है। L306 self._validate_conn(conn) और L333 conn.getresponse(buffering=True) । getresponse HTTPConnection पर httplib विधि है। उस में आगे की रूपरेखा बनाना आसान नहीं होगा। अगर हम _validate_conn लाइन को देखते हैं जो इस का कारण बनता है तो यह conn.connect() जो एक और HTTPConnor विधि है। connect लगभग निश्चित रूप से जहां सॉकेट बनाया जा रहा है। अगर मैं मेमोरी प्रोफाइलिंग को अक्षम करता हूं और मैं print(old_pool) HTTPConnectionPool#close चिपका देता हूं तो यह कभी भी प्रिंट नहीं करता है। ऐसा लगता है कि सत्र समाप्त होते ही हम वास्तव में पूल को बंद नहीं कर रहे हैं। मेरा अनुमान है कि यह स्मृति रिसाव का कारण है।

यह डिबग करने में मदद करना पसंद करेंगे, मैं आज और कल IRC से बाहर / बाहर रहूँगा।

तो इसे आगे ट्रेस करते हुए, यदि आप python _make_request अभी भी सजाए गए हैं ( profile ), और आप एक सत्र बनाते हैं, तो हर 10 या 20 सेकंड में अनुरोध करें (में समान URL) भी, आप देखेंगे कि कॉन को गिरा हुआ माना गया है, इसलिए VerifiedHTTPSConnection बंद है और फिर पुन: उपयोग किया गया है। इसका अर्थ है connection वर्ग का पुन: उपयोग किया गया है, न कि अंतर्निहित सॉकेट। close विधि वह है जो httplib.HTTPConnection (L798) पर रहती है। यह सॉकेट ऑब्जेक्ट को बंद कर देता है, फिर इसे कोई भी सेट नहीं करता है। तब यह बंद हो जाता है (और कोई भी सेट नहीं करता है) सबसे हाल ही में httplib.HTTPResponse । यदि आप VerifiedHTTPSConnection#connect प्रोफ़ाइल भी बनाते हैं, तो बनाई गई / लीक की गई सभी मेमोरी urllib3.util.ssl_.ssl_wrap_socket ।

तो इसको देखते हुए, जो मैमोरी_प्रफाइलर मैमोरी यूसेज को रिपोर्ट करने के लिए उपयोग कर रहा है, वह है 'रेजिडेंट सेट साइज (आरएसएस)। यह RAM में प्रक्रिया का आकार है (vms या वर्चुअल मेमोरी का आकार, मॉलकोक्स के साथ करना है), इसलिए मैं देख रहा हूं कि क्या हम वर्चुअल मेमोरी को लीक कर रहे हैं, या यदि हम सिर्फ पृष्ठों के लिए आवंटित कर रहे हैं स्मृति जो हम नहीं खो रहे हैं।

इसलिए यह देखते हुए कि हम जितने भी URLs का उपयोग कर रहे हैं, वे सभी सत्यापित HTTPS का उपयोग कर रहे हैं, मैंने http://google.com का उपयोग करने के लिए स्विच किया और अभी भी स्मृति में लगातार वृद्धि हुई है, ऐसा लगता है कि यह ~ 11-14MiB कम खपत करता है कुल मिलाकर। यह अभी भी सभी conn.getresponse लाइन पर आता है (और अब कुछ हद तक, conn.request )।

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

मैं यह भी देखने जा रहा हूं कि जब हम urllib2 / CANplib का उपयोग सीधे करते हैं तो क्या होता है क्योंकि मैं यह सोचना शुरू कर रहा हूं कि यह हमारी समस्या नहीं है। जहां तक ​​मैं बता सकता हूं, Session#close ठीक से सभी सॉकेट्स को बंद कर देता है और उन्हें GC'd होने की अनुमति देने के लिए उनके संदर्भ हटा देता है। इसके अलावा, यदि एक सॉकेट को कनेक्शन पूल द्वारा प्रतिस्थापित करने की आवश्यकता होती है, तो ऐसा ही होता है। यहां तक ​​कि एसएसएलएसकेट भी ठीक से इकट्ठा किए जा रहे कचरे को संभालने के लिए लगता है।

इसलिए urllib2 लगातार 13.3MiB के आसपास फ्लैटलाइन लगता है। अंतर यह है कि मुझे इसे एक कोशिश में लपेटना था / सिवाय इसके कि यह थोड़ी देर बाद URLError के साथ लगातार दुर्घटनाग्रस्त हो जाए। तो शायद यह कुछ समय के बाद वास्तव में कुछ भी नहीं कर रहा है।

@ sigmavirus24 आप इसे कुचल रहे हैं! :)

हम्म ... पायथन केवल फिर से पुन: उपयोग किए जाने के लिए मेमोरी को रिलीज़ करता है, और जब तक प्रक्रिया समाप्त नहीं होती है तब तक सिस्टम को मेमोरी वापस नहीं मिलती है। इसलिए, मुझे लगता है कि आप 13.3MiB पर जो फ्लैटलाइन देख रहे हैं वह शायद संकेत है कि urllib3 के साथ, urllib2 के साथ मौजूद मेमोरी लीक नहीं है।

यह पुष्टि करना अच्छा होगा कि समस्या को urllib3 में अलग किया जा सकता है। क्या आप उन स्क्रिप्ट को साझा कर सकते हैं जिनका आप urllib2 के साथ परीक्षण कर रहे हैं?

तो मुझे आश्चर्य है कि अगर यह HTTPConnection वस्तुओं के साथ कुछ करने के लिए नहीं है। यदि तुम करो

import sys
import requests

s = requests.Session()
r = s.get('https://httpbin.org/get')
print('Number of response refs: ', sys.getrefcount(r) - 1)
print('Number of session refs: ', sys.getrefcount(s) - 1)
print('Number of raw refs: ', sys.getrefcount(r.raw) - 1)
print('Number of original rsponse refs: ', sys.getrefcount(r.raw._original_response) - 1)

पहले तीन को 1 प्रिंट करना चाहिए, आखिरी 3. [1] मैंने पहले ही पहचान लिया था कि एक HTTPConnection में _HTTPConnection__response जो _original_response संदर्भ है। इसलिए मैं उम्मीद कर रहा था कि संख्या 3 होगी। मैं यह पता नहीं लगा सकता कि वह क्या है जो तीसरी प्रति के संदर्भ में है।

आगे के मनोरंजन के लिए, निम्नलिखित जोड़ें

import gc
gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_UNCOLLECTABLE)

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

परीक्षण urllib3 को @mhjohnson, बस करने के लिए अपने कॉल की जगह requests.get के साथ urllib2.urlopen (भी मैं शायद कर दिया जाना चाहिए था r.read() , लेकिन मैं नहीं था)।

इसलिए मैंने @mjohnson के पिछले सुझाव को लिया और objgraph का उपयोग यह जानने के लिए किया कि अन्य संदर्भ कहाँ था, लेकिन objgraph इसे खोजने के लिए प्रतीत नहीं हो सकता है। मैंने कहा:

objgraph.show_backrefs([r.raw._original_response], filename='requests.png')

स्क्रिप्ट 2 टिप्पणियों में ऊपर और निम्नलिखित मिला:
जो केवल यह दर्शाता है कि इसके 2 संदर्भ होंगे। मुझे आश्चर्य है कि अगर sys.getrefcount काम करता है तो यह अविश्वसनीय है।

तो यह एक लाल हेरिंग है। एक urllib3.response.HTTPResponse दोनों _original_response और _fp । _HTTPConection__response के साथ संयुक्त हमें तीन रेफरी देता है।

तो, urllib3.response.HTTPResponse में _pool विशेषता होती है जिसे PoolManager द्वारा भी संदर्भित किया जाता है। इसी तरह, HTTPAdapter अनुरोध करने के लिए उपयोग किया जाता है, Response अनुरोधों पर एक संदर्भ है। हो सकता है कि कोई और व्यक्ति यहां से कुछ पहचान सके:

कोड जो उत्पन्न करता है वह है: https://gist.github.com/sigmavirus24/bc0e1fdc5f248ba1201d

@ sigmavirus24
हाँ, मैं उस आखिरी ग्राफिक के साथ थोड़ा खो गया। शायद इसलिए कि मुझे कोड आधार बहुत अच्छी तरह से पता नहीं है, और न ही मैं डीबगिंग मेमोरी लीक पर बहुत अनुभवी हूं।

क्या आप जानते हैं कि यह कौन सी वस्तु है जो मैं आपके ग्राफिक के स्क्रीनशॉट में लाल तीर से इंगित कर रहा हूं?
http://cl.ly/image/3l3g410p3r1C

मैं धीरे-धीरे बढ़ती स्मृति उपयोग को दिखाने के लिए कोड प्राप्त करने में सक्षम था
python3 पर urllib.request.urlopen के साथ urllib3 / request को बदलकर।

यहां संशोधित कोड: https://gist.github.com/kevinburke/f99053641fab0e2252f0

केविन बर्क
फोन: 925.271.7005 | twentymilliseconds.com

सोम, 3 नवंबर, 2014 को 9:28 बजे, मैथ्यू जॉनसन सूचनाएं @ithub.com
लिखा था:

@ सिगमावायरस 24 https://github.com/sigmavirus24
हाँ, मैं उस आखिरी ग्राफिक के साथ थोड़ा खो गया। शायद इसलिए कि मैं नहीं
कोड बेस को अच्छी तरह से जानते हैं, और न ही मैं डीबगिंग मेमोरी पर बहुत अनुभवी हूं
लीक।

क्या आप जानते हैं कि यह कौन सी वस्तु है जो मैं लाल तीर से इंगित कर रहा हूं
अपने ग्राफिक के स्क्रीनशॉट में?
http://cl.ly/image/3l3g410p3r1C

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/1685#issuecomment -61595362
।

जहां तक ​​मैं एक वेबसाइट पर अनुरोध करने के बारे में बता सकता हूं जो एक रिटर्न देता है
कनेक्शन: नजदीकी हेडर (उदाहरण के लिए https://api.twilio.com/2010-04-01.json)
एक महत्वपूर्ण राशि से स्मृति उपयोग में वृद्धि नहीं करता है। कैवियट है
कई अलग-अलग कारक हैं और मैं इसे केवल एक सॉकेट मान रहा हूं
संबंधित मुद्दा।

केविन बर्क
फोन: 925.271.7005 | twentymilliseconds.com

सोम, 3 नवंबर, 2014 को 9:43 बजे, केविन बुर्के [email protected] ने लिखा:

मैं धीरे-धीरे बढ़ती स्मृति उपयोग को दिखाने के लिए कोड प्राप्त करने में सक्षम था
python3 पर urllib.request.urlopen के साथ urllib3 / request को बदलकर।

यहाँ संशोधित कोड:
https://gist.github.com/kevinburke/f99053641fab0e2259f0

केविन बर्क
फोन: 925.271.7005 | twentymilliseconds.com

सोम, 3 नवंबर, 2014 को 9:28 बजे, मैथ्यू जॉनसन सूचनाएं @ithub.com
लिखा था:

@ सिगमावायरस 24 https://github.com/sigmavirus24
हाँ, मैं उस आखिरी ग्राफिक के साथ थोड़ा खो गया। शायद इसलिए कि मैं
कोड आधार को अच्छी तरह से नहीं जानते हैं, और न ही मैं डीबगिंग पर बहुत अनुभवी हूं
स्म्रति से रिसाव।

क्या आप जानते हैं कि यह कौन सी वस्तु है जो मैं लाल तीर से इंगित कर रहा हूं
अपने ग्राफिक के स्क्रीनशॉट में?
http://cl.ly/image/3l3g410p3r1C

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/1685#issuecomment -61595362
।

@mhjohnson दिखाई देती है कि metatype के सन्दर्भ की संख्या होने के लिए type से object प्रकार का है जो type । दूसरे शब्दों में, मुझे लगता है कि यह सभी संदर्भ object या type , लेकिन मुझे पूरा यकीन है। किसी भी तरह, अगर मैं उन को बाहर करने की कोशिश करता हूं, तो ग्राफ 2 नोड्स की तरह बन जाता है।

मैं इस मेमोरी लीक समस्या से भी बहुत चिंतित हूं क्योंकि हम अपने वेब क्रॉलिंग सिस्टम में अनुरोधों का उपयोग करते हैं जिसमें एक प्रक्रिया आमतौर पर कई दिनों तक चलती है। क्या इस मुद्दे पर कोई प्रगति हुई है?

@Mhohnson के साथ इस पर कुछ समय बिताने के बाद, मैं @kevinburke सिद्धांत की पुष्टि कर सकता हूं कि GC जिस तरह से PyPy पर सॉकेट्स का व्यवहार करता है।

3c0b94047c1ccfca4ac4f2fe32afef0ae314094e कमिटमेंट एक दिलचस्प है। विशेष रूप से लाइन https://github.com/kennethreitz/requests/blob/master/requests/models.py#L736

सामग्री वापस करने से पहले self.raw.release_conn() कॉल करना PyPy पर उपयोग की गई मेमोरी को काफी कम कर देता है, हालांकि सुधार के लिए अभी भी जगह है।

इसके अलावा, मुझे लगता है कि यह बेहतर होगा यदि हम सत्र और प्रतिक्रिया वर्गों से संबंधित .close() कॉल का दस्तावेज़ दें, जैसा कि @ sigmavirus24 द्वारा भी उल्लेख किया गया है। अनुरोध उपयोगकर्ताओं को उन तरीकों के बारे में पता होना चाहिए, क्योंकि अधिकांश मामलों में विधियों को निहित नहीं कहा जाता है।

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

इस तरह के दृष्टिकोण का एक अच्छा उदाहरण pq प्रोजेक्ट में पाया जा सकता है:
https://github.com/malthe/pq/blob/master/pq/tests.py#L287

उन सभी के लिए धन्यवाद, जिन्होंने इस पर कूद कर मदद करने का फैसला किया!
हम ऐसा करने वाले अन्य सिद्धांतों की जांच करते रहेंगे।

@stas मैं एक बात को संबोधित करना चाहता हूं:

अनुरोध उपयोगकर्ताओं को उन तरीकों के बारे में पता होना चाहिए, क्योंकि अधिकांश मामलों में विधियों को निहित नहीं कहा जाता है।

PyPy को एक पल के लिए छोड़कर, उन तरीकों को _need_ को स्पष्ट रूप से नहीं कहा जाना चाहिए। यदि सॉकेट ऑब्जेक्ट CPython में पहुंच से बाहर हो जाते हैं, तो उन्हें ऑटो gc'd मिलेगा, जिसमें फ़ाइल हैंडल बंद करना शामिल है। यह उन विधियों को न करने का तर्क नहीं है, लेकिन यह उन पर ध्यान केंद्रित न करने के लिए एक चेतावनी है।

हम एक CI का उपयोग करने के लिए हैं, लेकिन यह इस समय अस्वस्थ प्रतीत होता है, और केवल @kennethreitz इसे ठीक करने की स्थिति में है। जब उसके पास समय होगा, वह उसके पास पहुंच जाएगा। ध्यान दें, हालाँकि, बेंचमार्क टेस्ट सही तरीके से कर पाना बेहद मुश्किल है, जो उन्हें बहुत शोर नहीं करता है।

PyPy को एक पल के लिए छोड़कर, उन तरीकों को स्पष्ट रूप से कहा जाना चाहिए। यदि सॉकेट ऑब्जेक्ट CPython में पहुंच से बाहर हो जाते हैं, तो उन्हें ऑटो gc'd मिलेगा, जिसमें फ़ाइल हैंडल बंद करना शामिल है। यह उन विधियों को न करने का तर्क नहीं है, लेकिन यह उन पर ध्यान केंद्रित न करने के लिए एक चेतावनी है।

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

जब भी कोई अवसर होगा, मैं CI या बेंचमार्क परीक्षणों में मदद करके खुश होऊंगा! वर्तमान स्थिति को समझाने के लिए धन्यवाद।

इसलिए, मुझे लगता है कि मैंने कार्यात्मक एपीआई का उपयोग करते समय समस्या का कारण पाया है। यदि तुम करो

import requests
r = requests.get('https://httpbin.org/get')
print(r.raw._pool.pool.queue[-1].sock)

सॉकेट अभी भी खुला दिखाई देता है। मेरे कहने का कारण _appears_ है क्योंकि यह अभी भी _sock विशेषता है क्योंकि यदि आप करते हैं

r.raw._pool.queue[-1].close()
print(repr(r.raw._pool.queue[-1].sock))

आपको None मुद्रित दिखाई देंगे। तो क्या हो रहा है कि urllib3 हर HTTPResponse एक विशेषता शामिल है जो कनेक्शन पूल को इंगित करता है जो यह आया था। कनेक्शन पूल में कतार में कनेक्शन होता है जिसमें अशुद्ध सॉकेट होता है। कार्यात्मक API के लिए समस्या, अगर requests/api.py हम करते हैं, तो तय हो जाएगी:

def request(...):
    """..."""
    s = Session()
    response = s.request(...)
    s.close()
    return s

तब r.raw._pool अभी भी कनेक्शन पूल होगा लेकिन r.raw._pool.pool None ।

मुश्किल हिस्सा तब बन जाता है जब लोग सत्रों का उपयोग कर रहे होते हैं। प्रत्येक अनुरोध के बाद close सत्र होना गैर-संवेदी है और सत्र के उद्देश्य को पराजित करता है। वास्तव में, यदि आप एक सत्र का उपयोग करते हैं (बिना थ्रेड्स) और एक ही डोमेन के लिए 100 अनुरोध करें (और एक ही योजना, उदाहरण के लिए, https ) एक सत्र का उपयोग करके स्मृति रिसाव को देखना बहुत कठिन है, जब तक कि आप नहीं एक नया सॉकेट बनने के लिए लगभग 30 सेकंड प्रतीक्षा करें। समस्या यह है कि जैसा कि हमने पहले ही देखा है, r.raw._pool एक बहुत ही परिवर्तनशील वस्तु है। यह कनेक्शन पूल का एक संदर्भ है जिसे पूल प्रबंधक द्वारा अनुरोधों में प्रबंधित किया जाता है। इसलिए जब सॉकेट को बदल दिया जाता है, तो इसे हर उस प्रतिक्रिया से संदर्भ के साथ बदल दिया जाता है जो अभी भी उपलब्ध है (स्कोप में)। अगर हम कनेक्शन पूल बंद करने के बाद भी कुछ सॉकेट्स के संदर्भ में रखते हैं, तो मुझे और अधिक करने की आवश्यकता है। अगर मुझे ऐसी कोई चीज़ मिल सकती है जो संदर्भों के लिए है, तो मुझे लगता है कि हम _real_ मेमोरी लीक पाएंगे।

तो एक विचार है कि मैं था क्या वास्तव में एक संदर्भ देता है यह पता लगाने की objgraph का इस्तेमाल किया गया SSLSocket के लिए एक कॉल के बाद requests.get और मैं यह मिल गया:

दिलचस्प बात यह है कि जाहिरा तौर पर SSLSocket 7 संदर्भ हैं लेकिन केवल दो बैक संदर्भ हैं जो objgraph पा सकते हैं। मुझे लगता है कि 1 संदर्भों में से एक है जो objgraph को पारित किया गया है और दूसरा वह बाइंडिंग है जिसे मैं स्क्रिप्ट में बनाता हूं जो इसे उत्पन्न करता है लेकिन फिर भी संदर्भों के लिए 3 या 4 को अस्वीकार्य छोड़ देता है, मुझे यकीन नहीं है कि वे कहां से आ रहे हैं।

इसे बनाने के लिए यहां मेरी स्क्रिप्ट है:

import objgraph
import requests

r = requests.get('https://httpbin.org/get')
s = r.raw._pool.pool.queue[-1].sock
objgraph.show_backrefs(s, filename='socket.png', max_depth=15, refcounts=True)

का उपयोग करते हुए

import objgraph
import requests

r = requests.get('https://httpbin.org/get')
s = r.raw._pool.pool.queue[-1].sock
objgraph.show_backrefs(s, filename='socket-before.png', max_depth=15,
                       refcounts=True)
r.raw._pool.close()
objgraph.show_backrefs(s, filename='socket-after.png', max_depth=15,
                       refcounts=True)

socket-after.png यह दिखाता है:

तो हम ssl सॉकेट के लिए एक संदर्भ को समाप्त करते हैं। उस ने कहा, जब मैं s._sock देखता हूं तो अंतर्निहित socket.socket बंद होता है।

लंबे समय तक चलने वाले बेंचमार्क का एक गुच्छा चलाने के बाद, यहाँ हमने जो पाया है:

• close() कॉल करने से स्पष्ट रूप से मदद मिलती है!
• कई अनुरोधों को चलाने वाले उपयोगकर्ताओं को Session उपयोग करना चाहिए और ठीक होने के बाद इसे ठीक से बंद कर देना चाहिए। कृपया # 2326 मर्ज करें
• PyPy उपयोगकर्ता JIT के बिना बेहतर हैं! या उन्हें स्पष्ट रूप से gc.collect() कॉल करना चाहिए!

टी एल; डॉ; requests अच्छा लग रहा है, नीचे आपको इस स्निपेट पर चलने वाले कुछ जोड़े मिलेंगे:

import requests
from memory_profiler import profile

<strong i="15">@profile</strong>
def get(session, i):
    return session.get('http://stas.nerd.ro/?{0}'.format(i))

<strong i="16">@profile</strong>
def multi_get(session, count):
    for x in xrange(count):
        resp = get(session, count+1)
        print resp, len(resp.content), x
        resp.close()

<strong i="17">@profile</strong>
def run():
    session = requests.Session()
    print 'Starting...'
    multi_get(session, 3000)
    print("Finished first round...")
    session.close()
    print 'Done.'

if __name__ == '__main__':
    run()

CPython:

Line #    Mem usage    Increment   Line Contents
================================================
    15      9.1 MiB      0.0 MiB   <strong i="23">@profile</strong>
    16                             def run():
    17      9.1 MiB      0.0 MiB       session = requests.Session()
    18      9.1 MiB      0.0 MiB       print 'Starting...'
    19      9.7 MiB      0.6 MiB       multi_get(session, 3000)
    20      9.7 MiB      0.0 MiB       print("Finished first round...")
    21      9.7 MiB      0.0 MiB       session.close()
    22      9.7 MiB      0.0 MiB       print 'Done.'

बिना JIT के PyPy:

Line #    Mem usage    Increment   Line Contents
================================================
    15     15.0 MiB      0.0 MiB   <strong i="29">@profile</strong>
    16                             def run():
    17     15.4 MiB      0.5 MiB       session = requests.Session()
    18     15.5 MiB      0.0 MiB       print 'Starting...'
    19     31.0 MiB     15.5 MiB       multi_get(session, 3000)
    20     31.0 MiB      0.0 MiB       print("Finished first round...")
    21     31.0 MiB      0.0 MiB       session.close()
    22     31.0 MiB      0.0 MiB       print 'Done.'

JIT के साथ PyPy:

Line #    Mem usage    Increment   Line Contents
================================================
    15     22.0 MiB      0.0 MiB   <strong i="35">@profile</strong>
    16                             def run():
    17     22.5 MiB      0.5 MiB       session = requests.Session()
    18     22.5 MiB      0.0 MiB       print 'Starting...'
    19    219.0 MiB    196.5 MiB       multi_get(session, 3000)
    20    219.0 MiB      0.0 MiB       print("Finished first round...")
    21    219.0 MiB      0.0 MiB       session.close()
    22    219.0 MiB      0.0 MiB       print 'Done.'

मेरा मानना ​​है कि शुरू में हम सभी भ्रमित होने वाले कारणों में से एक है क्योंकि जीसी को लागू करने के तरीके से दूसरे तरीके को बाहर करने के लिए बेंचमार्क चलाने के लिए एक बड़े सेट की आवश्यकता होती है।

थ्रेडेड वातावरण में अनुरोधों को चलाने के लिए थ्रेड्स के काम करने के तरीके के कारण बड़े कॉल की आवश्यकता होती है (हमने कई थ्रेड पूल चलाने के बाद मेमोरी उपयोग में कोई बड़ा बदलाव नहीं देखा)।

JIT के साथ PyPy के संबंध में, समान संख्या में कॉल के लिए gc.collect() कॉल करना, ~ 30% मेमोरी को सहेजता है। इसीलिए मेरा मानना ​​है कि JIT के परिणामों को इस चर्चा से बाहर रखा जाना चाहिए क्योंकि यह एक विषय है कि हर कोई VM को कैसे कहता है और JIT के लिए कोड का अनुकूलन करता है।

ठीक है, इसलिए समस्या स्पष्ट रूप से उस तरह से प्रतीत होती है जिस तरह से हम PyPy JIT के साथ इंटरेक्ट मेमोरी को हैंडल करते हैं। PyPy विशेषज्ञ: @alex को बुलाना एक अच्छा विचार हो सकता है?

मैं वास्तव में कल्पना नहीं कर सकता कि क्या अनुरोध (और कंपनी) संभवतः ऐसा कर रहे हैं जिससे ऐसा कुछ भी हो। क्या आप तेह एनव में PYPYLOG=jit-summary:- साथ अपना परीक्षण चला सकते हैं और परिणाम चिपका सकते हैं (जब प्रक्रिया समाप्त हो जाएगी तब कुछ सामान प्रिंट करेंगे)

उम्मीद है की यह मदद करेगा:

Line #    Mem usage    Increment   Line Contents
================================================
    15     23.7 MiB      0.0 MiB   <strong i="6">@profile</strong>
    16                             def run():
    17     24.1 MiB      0.4 MiB       session = requests.Session()
    18     24.1 MiB      0.0 MiB       print 'Starting...'
    19    215.1 MiB    191.0 MiB       multi_get(session, 3000)
    20    215.1 MiB      0.0 MiB       print("Finished first round...")
    21    215.1 MiB      0.0 MiB       session.close()
    22    215.1 MiB      0.0 MiB       print 'Done.'


[2cbb7c1bbbb8] {jit-summary
Tracing:        41  0.290082
Backend:        30  0.029096
TOTAL:              1612.933400
ops:                79116
recorded ops:       23091
  calls:            2567
guards:             7081
opt ops:            5530
opt guards:         1400
forcings:           198
abort: trace too long:  2
abort: compiling:   0
abort: vable escape:    9
abort: bad loop:    0
abort: force quasi-immut:   0
nvirtuals:          9318
nvholes:            1113
nvreused:           6666
Total # of loops:   23
Total # of bridges: 8
Freed # of loops:   0
Freed # of bridges: 0
[2cbb7c242e8b] jit-summary}

मैं https://launchpad.net/~pypy/+archive/ubuntu/ppa से नवीनतम PyPy का उपयोग करके भरोसेमंद 32 बिट पर हूं

31 संकलित पथ उपयोग में 200+ एमबी रैम की व्याख्या नहीं करते हैं।

क्या आप चलाने के लिए अपने कार्यक्रम में कोई चीज़ रख सकते हैं
gc.dump_rpy_heap('filename.txt') जबकि यह बहुत अधिक मेमोरी में है
उपयोग? (बस इसे एक बार चलाने की आवश्यकता है, यह सभी का एक डंप उत्पन्न करेगा
मेमोरी जीसी के बारे में जानता है)।

फिर PyPy source ट्री के चेकआउट के साथ, ./pypy/tool/gcdump.py filename.txt चलाएं और हमें परिणाम दिखाएं।

धन्यवाद!

Sat Nov 08 2014 को 3:20:52 PM स्टास सूकोव नोटिफिकेशन @github.com पर
लिखा था:

उम्मीद है की यह मदद करेगा:

लाइन # मेम उपयोग वृद्धि लाइन सामग्री

15     23.7 MiB      0.0 MiB   <strong i="20">@profile</strong>
16                             def run():
17     24.1 MiB      0.4 MiB       session = requests.Session()
18     24.1 MiB      0.0 MiB       print 'Starting...'
19    215.1 MiB    191.0 MiB       multi_get(session, 3000)
20    215.1 MiB      0.0 MiB       print("Finished first round...")
21    215.1 MiB      0.0 MiB       session.close()
22    215.1 MiB      0.0 MiB       print 'Done.'

[2cbb7c1bbb8] {जित-सारांश
ट्रेसिंग: 41 0.290082
बैकएंड: 30 0.029096
कुल: 1612.933400
ऑप्स: 79116
रिकॉर्डेड ऑप्स: 23091
कॉल: 2567
गार्ड: 7081
ऑप्ट ऑप्स: 5530
ऑप्ट गार्ड: 1400
forcings: 198
गर्भपात: बहुत लंबा ट्रेस: ​​२
गर्भपात: संकलन: ०
गर्भपात: व्यवहार्य बच: ९
गर्भपात: खराब लूप: 0
abort: बल quasi-immut: 0
nvirtuals: 9318
nvholes: 1113
nvreused: 6666
कुल # छोरों का: 23
पुलों का कुल #: 8
# छोरों की मुक्ति: 0
पुलों के # मुक्त: 0
[2cb77c242e8b] जित-सारांश}

मैं नवीनतम PyPy का उपयोग करके भरोसेमंद 32 बिट पर हूं
https://launchpad.net/~pypy/+archive/ubuntu/ppa
https://launchpad.net/%7Epypy/+archive/ubuntu/ppa

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/1685#issuecomment -62269627
।

लॉग इन करें:

Line #    Mem usage    Increment   Line Contents
================================================
    16     22.0 MiB      0.0 MiB   <strong i="6">@profile</strong>
    17                             def run():
    18     22.5 MiB      0.5 MiB       session = requests.Session()
    19     22.5 MiB      0.0 MiB       print 'Starting...'
    20    217.2 MiB    194.7 MiB       multi_get(session, 3000)
    21    217.2 MiB      0.0 MiB       print("Finished first round...")
    22    217.2 MiB      0.0 MiB       session.close()
    23    217.2 MiB      0.0 MiB       print 'Done.'
    24    221.0 MiB      3.8 MiB       gc.dump_rpy_heap('bench.txt')


[3fd7569b13c5] {jit-summary
Tracing:        41  0.293192
Backend:        30  0.026873
TOTAL:              1615.665337
ops:                79116
recorded ops:       23091
  calls:            2567
guards:             7081
opt ops:            5530
opt guards:         1400
forcings:           198
abort: trace too long:  2
abort: compiling:   0
abort: vable escape:    9
abort: bad loop:    0
abort: force quasi-immut:   0
nvirtuals:          9318
nvholes:            1113
nvreused:           6637
Total # of loops:   23
Total # of bridges: 8
Freed # of loops:   0
Freed # of bridges: 0
[3fd756c29302] jit-summary}

यहां डंप: https://gist.github.com/stas/ad597c87ccc4b563211a

इसके साथ मदद करने के लिए अपना समय निकालने के लिए धन्यवाद!

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

Sat Nov 08 2014 को शाम 5:38:04 PM स्टास सूकोव नोटिफिकेशन @github.com पर
लिखा था:

लॉग इन करें:

लाइन # मेम उपयोग वृद्धि लाइन सामग्री

16     22.0 MiB      0.0 MiB   <strong i="18">@profile</strong>
17                             def run():
18     22.5 MiB      0.5 MiB       session = requests.Session()
19     22.5 MiB      0.0 MiB       print 'Starting...'
20    217.2 MiB    194.7 MiB       multi_get(session, 3000)
21    217.2 MiB      0.0 MiB       print("Finished first round...")
22    217.2 MiB      0.0 MiB       session.close()
23    217.2 MiB      0.0 MiB       print 'Done.'
24    221.0 MiB      3.8 MiB       gc.dump_rpy_heap('bench.txt')

[3fd7569b13c5] {जित-सारांश
ट्रेसिंग: 41 0.293192
बैकएंड: 30 0.026873
कुल: 1615.665337
ऑप्स: 79116
रिकॉर्डेड ऑप्स: 23091
कॉल: 2567
गार्ड: 7081
ऑप्ट ऑप्स: 5530
ऑप्ट गार्ड: 1400
forcings: 198
गर्भपात: बहुत लंबा ट्रेस: ​​२
गर्भपात: संकलन: ०
गर्भपात: व्यवहार्य बच: ९
गर्भपात: खराब लूप: 0
abort: बल quasi-immut: 0
nvirtuals: 9318
nvholes: 1113
nvreused: 6637
कुल # छोरों का: 23
पुलों का कुल #: 8
# छोरों की मुक्ति: 0
पुलों के # मुक्त: 0
[3fd756c29302] जित-सारांश}

यहां डंप: https://gist.github.com/stas/ad597c87ccc4b563211a

इसके साथ मदद करने के लिए अपना समय निकालने के लिए धन्यवाद!

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/1685#issuecomment -62277822
।

@alex ,

मेरा मानना ​​है कि @stas ने इस बेंचमार्क के लिए नियमित http (गैर-एसएसएल / टीएलएस) कनेक्शन का उपयोग किया था। बस के मामले में, मैंने @stas की बेंचमार्क स्क्रिप्ट का भी उपयोग किया और इसे अपने मैक (OSX 10.9.5 2.5 GHz i5 8 GB 1600 MHz DDR3) पर नियमित http कनेक्शन के साथ प्रीफ़ॉर्म किया।

यदि यह मदद करता है, तो यहां आपके परिणामों की तुलना करने के लिए मेरे परिणाम हैं (आपके निर्देशों का उपयोग करते हुए):
https://gist.github.com/mhjohnson/a13f6403c8c3a3d49b8d

आप क्या सोचते हैं मुझे बताओ।

धन्यवाद,

-मैट

GitHub की नियमित अभिव्यक्ति बहुत ढीली है। मैं इसे फिर से खोल रहा हूं क्योंकि मुझे नहीं लगता कि यह पूरी तरह से तय है।

हैलो, शायद मैं इस मुद्दे को इंगित करने में मदद कर सकता हूं। मेरे पास एक क्रॉलर है जो अनुरोधों का उपयोग करता है और मल्टीप्रोसेसिंग का उपयोग करके प्रक्रिया करता है। ऐसा हो रहा है कि एक से अधिक उदाहरण एक ही परिणाम प्राप्त कर रहे हैं। हो सकता है कि परिणाम या सॉकेट के बफर पर कुछ रिसाव हो।

मुझे बताएं कि क्या मैं कोड का कुछ नमूना भेज सकता हूं या यह बताने के लिए कि संदर्भ का पेड़ कैसे उत्पन्न होता है, जानकारी के किस हिस्से को "साझा" (लीक) किया जा रहा है

धन्यवाद

@barroca यह एक अलग मुद्दा है। आप संभवतः थ्रेड्स में एक सत्र का उपयोग कर रहे हैं और stream=True का उपयोग कर रहे हैं। यदि आप इसे पढ़ने से पहले एक प्रतिक्रिया बंद कर रहे हैं, तो सॉकेट को उस डेटा के साथ कनेक्शन पूल में वापस रखा गया है (यदि मैं सही तरीके से काम करता हूं)। यदि ऐसा नहीं हो रहा है, तो यह भी प्रशंसनीय है कि आप सबसे हालिया कनेक्शन उठा रहे हैं और सर्वर से कैश्ड रिस्पांस प्राप्त कर रहे हैं। किसी भी तरह से, यह एक स्मृति रिसाव का संकेत नहीं है।

@ sigmavirus24 धन्यवाद इयान, जैसा कि आपने उल्लेख किया है कि यह थ्रेड्स में सत्र का कुछ मिस उपयोग था। स्पष्टीकरण के लिए धन्यवाद और गलत मुद्दे को अपडेट करने के लिए क्षमा करें।

कोई चिंता नहीं @barroca :)

इस उत्पन्न होने की कोई और शिकायत नहीं है और मुझे लगता है कि हमने इस पर अपना सर्वश्रेष्ठ प्रदर्शन किया है। मैं इसे फिर से खोलने और यदि आवश्यक हो तो फिर से संगठित करने के लिए खुश हूं

तो, इस मुद्दे का हल क्या है?

@ मैकोबेस्सी मैं यह भी जानना चाहता हूं

अब तक मेरा मुद्दा requests है, यह धागा-सुरक्षित नहीं है,
अलग धागे के लिए सबसे अच्छा अलग सत्र का उपयोग करें,

कैश प्रतिक्रिया को मान्य करने के लिए लाखों url के माध्यम से चलने के लिए मेरे काम ने मुझे यहां तक ​​पहुंचा दिया

जब मुझे पता चलता है कि मेमोरी का उपयोग उचित से अधिक बढ़ जाता है, जब requests ThreadPoolExecutor या threading ThreadPoolExecutor साथ सहभागिता करते हैं,
अंत में मैं कार्यकर्ता को अलग करने के लिए multiprocessing.Process का उपयोग करता हूं और प्रत्येक कार्यकर्ता के लिए स्वतंत्र सत्र होता है

@AndCycle तो आपकी समस्या यहाँ नहीं है। इस विशेष मेमोरी लीक मामले को ठीक करने के लिए एक PR मर्ज किया गया था। यह वापस नहीं आया है क्योंकि इसके चारों ओर परीक्षण हैं। और आपका मुद्दा पूरी तरह से अलग है।