Requests: मेमोरी लीक का अनुरोध करता है

कृपया हमें का आउटपुट प्रदान करें

python -m requests.help

यदि वह आपके अनुरोधों के संस्करण पर उपलब्ध नहीं है, तो कृपया अपने सिस्टम (पायथन संस्करण, ऑपरेटिंग सिस्टम, आदि) के बारे में कुछ बुनियादी जानकारी प्रदान करें।

@sigmavirus24 हो गया

अरे @munroc , आपके थ्रेडिंग कार्यान्वयन के बारे में कुछ त्वरित प्रश्न क्योंकि यह छद्म कोड में शामिल नहीं है।

• क्या आप प्रत्येक थ्रेड के लिए एक नया सत्र बना रहे हैं और आप किस थ्रेडपूल का उपयोग कर रहे हैं?

• रिसाव कहाँ से आ रहा है यह निर्धारित करने के लिए आप किस उपकरण का उपयोग कर रहे हैं? क्या आप परिणाम साझा करना चाहेंगे?

हमें कुछ समय के लिए सत्रों के आसपास मेमोरी लीक के संकेत मिले हैं, लेकिन मुझे यकीन नहीं है कि हमें एक धूम्रपान बंदूक या वास्तव में पुष्टि प्रभाव मिला है।

@nateprewitt हैलो, हाँ, मैं हर धागे के लिए एक नया सत्र बना रहा हूँ। थ्रेड पूल 30 है। मैंने वैसे भी 2 - 200 धागे और मेमोरी लीक के साथ प्रयास किया है। मैं एक उपकरण का उपयोग नहीं कर रहा हूं, मैंने अभी फ़ंक्शन में यह परिवर्तन किया है:
लॉगिन = session.get से पहले वापसी 0 डालें और कोई स्मृति रिसाव नहीं। अगर मैं लॉगिन = सत्र के बाद वापसी 0 डालता हूं। स्मृति प्राप्त करना शुरू हो जाता है। अगर आप चाहें तो मैं आपको भेज सकता हूं मेरा स्रोत कोड बहुत बड़ा नहीं है।

@Munroc अगर हमारे पास पूरा कोड है, तो मुझे लगता है कि वास्तविक कारण को अलग करना आसान होगा। लेकिन प्रदान किए गए कोड सार के आधार पर, मुझे लगता है कि यह निष्कर्ष निकालना बहुत कठिन है कि स्मृति रिसाव है।

जैसा कि आपने उल्लेख किया है, यदि आप return तुरंत कॉल करने से पहले session.get , तो केवल proxies और session ऑब्जेक्ट मेमोरी में मौजूद रहेंगे (ओवरसिम्प्लीफाइड.. लेकिन मैं आशा है कि आपको यह विचार मिल गया होगा: मुस्कान :)। हालांकि, अगर आप एक बार फोन session.get(url, proxies=proxies) , के एचटीएमएल url और पुनः प्राप्त किया जाएगा स्थानीय स्तर पर करने के लिए सहेजा login चर। जिसका अर्थ है, प्रत्येक session.get कॉल "ऐसा लगेगा" कि वे स्मृति को लीक कर रहे हैं, लेकिन वे वास्तव में (स्मृति) द्वारा सामान्य रूप से व्यवहार कर रहे हैं जो url परिणाम के आकार से रैखिक रूप से बढ़ रहा है।

हालांकि, मान लें कि आप तुरंत बाद में थ्रेड्स और .join() का उपयोग कर रहे थे। उस स्थिति में, मुझे लगता है कि हमें यह देखने की जरूरत है कि आपके धागे कैसे प्रबंधित किए गए - और क्या वे ठीक से बंद/साफ किए गए थे।

@LeoSZN मुझे लगता है कि आपके विशिष्ट उदाहरण में, आप कई Process प्रति urls तत्वों को उत्पन्न करने के बाद केवल अंतिम Process ऑब्जेक्ट को बंद कर रहे हैं।

क्या आप p.daemon = True का उपयोग करके उन्हें डिमोनाइज़ करने का प्रयास कर सकते हैं और उन्हें चला सकते हैं (ताकि एक बार मुख्य धागा समाप्त हो जाए, सभी उत्पन्न बाल प्रक्रियाएं भी मर जाती हैं)? अन्यथा, उत्पन्न प्रक्रियाओं को एक अलग सरणी में संग्रहीत करें और लूप का उपयोग करके उन सभी को बंद करना सुनिश्चित करें।

@initbar

क्या मुझे p.daemon = True लूप में या लूप के बाहर p.join() से पहले चलाने की आवश्यकता है? वैसे क्या मुझे p.join() लागू करने के बाद भी p.daemon = True ?

_ठीक है, मुझे नए विषय से इस विषय पर लाया गया था, इसलिए मुझे आपके साथ शामिल होने दें।
हो सकता है कि यह समस्या अधिक जानकारी प्रदान करे और समस्या को हल करने के लिए कदम उठाए..._

मैं टेलीग्राम बॉट चला रहा हूं और लंबे समय तक बॉट चलाते समय फ्री मेमोरी डिग्रेडेशन देखा। सबसे पहले, मुझे अपने कोड पर संदेह है; तब मुझे बॉट पर संदेह हुआ और अंत में मैं अनुरोधों पर आया। :)
मैंने उस समस्या की पहचान करने के लिए len(gc.get_objects()) का उपयोग किया। मैंने संचार दिनचर्या का पता लगाया, फिर सभी बॉट कोड को साफ़ कर दिया और उदाहरण के लिए आता है जो प्रत्येक पुनरावृत्ति पर जीसी ऑब्जेक्ट्स की गिनती बढ़ाता है।

अपेक्षित परिणाम

लेन (gc.get_objects ()) प्रत्येक लूप पुनरावृत्ति पर एक ही परिणाम देना चाहिए

वास्तविक परिणाम

प्रत्येक लूप पुनरावृत्ति पर len(gc.get_objects()) का मान बढ़ता है।

Test N2
GetObjects len: 27959
Test N3
GetObjects len: 27960
Test N4
GetObjects len: 27961
Test N5
GetObjects len: 27962
Test N6
GetObjects len: 27963
Test N7
GetObjects len: 27964

प्रजनन कदम

token = "XXX:XXX"
chat_id = '111'
proxy = {'https':'socks5h://ZZZ'} #You may need proxy to run this in Russia

from time import sleep
import gc, requests

def garbage_info():
    res = ""
    res += "\nGetObjects len: " + str(len(gc.get_objects()))
    return res

def tester():
    count = 0
    while(True):
        sleep(1)
        count += 1
        msg = "\nTest N{0}".format(count) + garbage_info()
        print(msg)

        method_url = r'sendMessage'
        payload = {'chat_id': str(chat_id), 'text': msg}

        request_url = "https://api.telegram.org/bot{0}/{1}".format(token, method_url)
        method_name = 'get'

        session = requests.session()
        req = requests.Request(
            method=method_name.upper(),
            url=request_url,
            params=payload
        )
        prep = session.prepare_request(req)

        settings = session.merge_environment_settings(
            prep.url, None, None, None, None)
#            prep.url, proxy, None, None, None)  #Change the line to enable proxy
        send_kwargs = {
            'timeout': None,
            'allow_redirects': None,
        }
        send_kwargs.update(settings)
        resp = session.send(prep, **send_kwargs)

        # For more clean output
        gc.collect()

tester()

व्यवस्था जानकारी

{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.3.1"
  },
  "idna": {
    "version": "2.7"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.6"
  },
  "platform": {
    "release": "4.15.0-36-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1010009f",
    "version": "17.5.0"
  },
  "requests": {
    "version": "2.19.1"
  },
  "system_ssl": {
    "version": "1010007f"
  },
  "urllib3": {
    "version": "1.23"
  },
  "using_pyopenssl": true
}

_वही व्यवहार जो मैंने विंडोज 10 पर पायथन 3.5.3 पर किया था।_

@LeoSZN

@initbar

क्या मुझे p.daemon = True लूप में या लूप के बाहर p.join() से पहले चलाने की आवश्यकता है? वैसे क्या मुझे p.join() लागू करने के बाद भी p.daemon = True ?

# ..
     for i in urls:
        p = Process(target=main, args=(i,))
        p.daemon = True  # before `.start`
        p.start()
# ..

एक छोटी सी टिप्पणी के रूप में, आप अभी भी कर सकते हैं .join प्रक्रियाओं डेमॉन - लेकिन वे लगभग गारंटी मारे जाने के लिए कर रहे हैं जब उनके माता पिता प्रक्रिया समाप्त (जब तक कि वे किसी भी तरह बन अनजाने अनाथ, जो मामले में, तो कृपया मुझे पता है कि मैं! इसके बारे में और जानने के लिए प्यार है)।

अन्यथा, आप Process ऑब्जेक्ट्स को एक सरणी के रूप में अलग से स्टोर कर सकते हैं और अंत में शामिल हो सकते हैं:

# ..
processes = [ 
  Process(target=main, args=(i,))
  for i in urls
]
# start the process activity.

अपेक्षित परिणाम

लेन (gc.get_objects ()) प्रत्येक लूप पुनरावृत्ति पर एक ही परिणाम देना चाहिए

इस व्यवहार का कारण "अनुरोध" कैश तंत्र में पाया गया था।

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

इसी तरह का मुद्दा। थ्रेड में चलते समय अनुरोध स्मृति खाता है। यहां पुन: पेश करने के लिए कोड:

import gc
from concurrent.futures import ThreadPoolExecutor, as_completed
import requests
from memory_profiler import profile

def run_thread_request(sess, run):
    response = sess.get('https://www.google.com')
    return

<strong i="6">@profile</strong>
def main():
    sess = requests.session()
    with ThreadPoolExecutor(max_workers=1) as executor:
        print('Starting!')
        tasks = {executor.submit(run_thread_request, sess, run):
                    run for run in range(50)}
        for _ in as_completed(tasks):
            pass
    print('Done!')
    return

<strong i="7">@profile</strong>
def calling():
    main()
    gc.collect()
    return

if __name__ == '__main__':
    calling()

ऊपर दिए गए कोड में मैं एक सत्र ऑब्जेक्ट पास करता हूं, लेकिन अगर मैं इसे केवल requests.get चलाने के साथ बदलता हूं तो कुछ भी नहीं बदलता है।

आउटपुट है:

➜  thread-test pipenv run python run.py
Starting!
Done!
Filename: run.py

Line #    Mem usage    Increment   Line Contents
================================================
    10     23.2 MiB     23.2 MiB   <strong i="13">@profile</strong>
    11                             def main():
    12     23.2 MiB      0.0 MiB       sess = requests.session()
    13     23.2 MiB      0.0 MiB       with ThreadPoolExecutor(max_workers=1) as executor:
    14     23.2 MiB      0.0 MiB           print('Starting!')
    15     23.4 MiB      0.0 MiB           tasks = {executor.submit(run_thread_request, sess, run):
    16     23.4 MiB      0.0 MiB                       run for run in range(50)}
    17     25.8 MiB      2.4 MiB           for _ in as_completed(tasks):
    18     25.8 MiB      0.0 MiB               pass
    19     25.8 MiB      0.0 MiB       print('Done!')
    20     25.8 MiB      0.0 MiB       return


Filename: run.py

Line #    Mem usage    Increment   Line Contents
================================================
    22     23.2 MiB     23.2 MiB   <strong i="14">@profile</strong>
    23                             def calling():
    24     25.8 MiB      2.6 MiB       main()
    25     25.8 MiB      0.0 MiB       gc.collect()
    26     25.8 MiB      0.0 MiB       return

और पिपफाइल इस तरह दिखता है:

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[requires]
python_version = "3.6"

[packages]
requests = "==2.21.0"
memory-profiler = "==0.55.0"

एफडब्ल्यूआईडब्ल्यू मैं भी इसी तरह की स्मृति रिसाव का अनुभव कर रहा हूं क्योंकि

https://github.com/nicolargo/glances/issues/1447

मेरे पास एक ही समस्या है जहां अनुरोधों का उपयोग करना। थ्रेडिंग के साथ प्राप्त करना वास्तव में स्मृति को लगभग 0.1 - 0.9 प्रति अनुरोधों से खाता है और यह अनुरोधों के बाद स्वयं को "समाशोधन" नहीं कर रहा है बल्कि इसे बचाता है।

यहाँ वही, कोई कामकाज?

संपादित करें
मेरी समस्या अनुरोधों में verify=False का उपयोग करने के कारण प्रतीत होती है, मैंने #5215 के अंतर्गत एक बग उठाया है

एक ही मुद्दा होना। मेरे पास एक साधारण स्क्रिप्ट है जो एक थ्रेड को जन्म देती है, यह थ्रेड एक फ़ंक्शन को कॉल करता है जो थोड़ी देर के लूप को चलाता है, यह लूप एक एपीआई को स्थिति मान की जांच करने के लिए पूछता है और फिर 10 सेकंड के लिए सोता है और फिर स्क्रिप्ट बंद होने तक लूप फिर से चलेगा।

requests.get फ़ंक्शन का उपयोग करते समय मैं स्पॉन्ड प्रक्रिया को देखकर कार्य प्रबंधक के माध्यम से स्मृति उपयोग को धीरे-धीरे रेंगता हुआ देख सकता हूं।

लेकिन अगर मैं लूप से requests.get कॉल को हटा देता हूं या अनुरोध प्राप्त करने के लिए सीधे urllib3 उपयोग करता हूं, तो स्मृति उपयोग के किसी भी रेंगने पर बहुत कम है।

मैंने इसे दोनों मामलों में दो घंटे की अवधि में देखा है और requests.get का उपयोग करते समय स्मृति उपयोग दो घंटे के बाद 1GB+ पर होता है जबकि urllib3 का उपयोग करते समय स्मृति उपयोग लगभग होता है। दो घंटे के बाद 20mb।

पायथन 3.7.4 और अनुरोध 2.22.0

ऐसा लगता है कि अनुरोध अभी भी बीटा चरण में है जिसमें स्मृति रिसाव है। चलो, दोस्तों, इसे पैच अप करें! मैं

इस पर किसी भी अद्यतन? फ़ाइल अपलोड के साथ साधारण POST अनुरोध भी स्मृति रिसाव के समान मुद्दे को बनाता है।

मेरे लिए वही ... थ्रेडपूल निष्पादन पर रिसाव विंडोज पायथन 38 पर भी है।
अनुरोध 2.22.0

मेरे लिए भी ऐसा

यहाँ मेरी मेमोरी लीकिंग समस्या है, कोई भी मदद कर सकता है? https://stackoverflow.com/questions/59746125/memory-keep-growth-when-using-mutil-thread-download-file

मेमोरी लीक से बचने के लिए Session.close() और Response.close() कॉल करें।
और ssl अधिक मेमोरी की खपत करेगा इसलिए https urls का अनुरोध करने पर मेमोरी लीक अधिक उल्लेखनीय होगी।

पहले मैं 4 टेस्ट केस करता हूं:

1. अनुरोध + एसएसएल (https://)
2. अनुरोध + गैर-एसएसएल (http://)
3. aiohttp + ssl (https://)
4. aiohttp + गैर-एसएसएल (http://)

छद्म कोड:

def run(url):
    session = requests.session()
    response = session.get(url)

while True:
    for url in urls:  # about 5k urls of public websites
        # execute in thread pool, size=10
        thread_pool.submit(run, url)

# in another thread, record memory usage every seconds

मेमोरी उपयोग ग्राफ (y-अक्ष: MB, x-अक्ष: समय), अनुरोध बहुत अधिक मेमोरी का उपयोग करते हैं और मेमोरी बहुत तेज़ी से बढ़ती है, जबकि aiohttp मेमोरी उपयोग स्थिर है:

फिर मैं Session.close() जोड़ता हूं और फिर से परीक्षण करता हूं:

def run(url):
    session = requests.session()
    response = session.get(url)
    session.close()  # close session !!

स्मृति उपयोग में उल्लेखनीय कमी आई है, लेकिन स्मृति उपयोग अभी भी समय के साथ बढ़ता है:

अंत में मैं Response.close() जोड़ता हूं और फिर से परीक्षण करता हूं:

def run(url):
    session = requests.session()
    response = session.get(url)
    session.close()  # close session !!
    response.close()  # close response !!

मेमोरी का उपयोग फिर से कम हो गया, और समय के साथ नहीं बढ़ा:

aiohttp की तुलना करें और अनुरोध दिखाता है कि स्मृति रिसाव ssl के कारण नहीं है, यह कनेक्शन संसाधनों के बंद न होने के कारण होता है।

उपयोगी स्क्रिप्ट:

class MemoryReporter:
    def __init__(self, name):
        self.name = name
        self.file = open(f'memoryleak/memory_{name}.txt', 'w')
        self.thread = None

    def _get_memory(self):
        return psutil.Process().memory_info().rss

    def main(self):
        while True:
            t = time.time()
            v = self._get_memory()
            self.file.write(f'{t},{v}\n')
            self.file.flush()
            time.sleep(1)

    def start(self):
        self.thread = Thread(target=self.main, name=self.name, daemon=True)
        self.thread.start()


def plot_memory(name):
    filepath = 'memoryleak/memory_{}.txt'.format(name)
    df_mem = pd.read_csv(filepath, index_col=0, names=['t', 'v'])
    df_mem.index = pd.to_datetime(df_mem.index, unit='s')
    df_mem.v = df_mem.v / 1024 / 1024
    df_mem.plot(figsize=(16, 8))

व्यवस्था जानकारी:

$ python -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.8"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.4"
  },
  "platform": {
    "release": "18.0.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.22.0"
  },
  "system_ssl": {
    "version": "1010104f"
  },
  "urllib3": {
    "version": "1.25.6"
  },
  "using_pyopenssl": false
}

एसएसएल रिसाव समस्या को विंडोज़ और ओएसएक्स पर ओपनएसएसएल <= 3.7.4 पैक किया गया है, यह संदर्भ से स्मृति को ठीक से जारी नहीं कर रहा है

https://github.com/VeNoMouS/cloudscraper/issues/143#issuecomment -613092377