जहाँ आप requests.async का उपयोग कर रहे हैं?

नहीं, सभी अनुरोध यथोचित सादे अनुरोध थे

$ lsof | grep localhost | wc -l
110

सभी लेकिन उनमें से 4/5 प्रारूप के हैं

Python    82117 daleharvey  123u    IPv4 0xffffff800da304e0       0t0      TCP localhost:61488->localhost:http (CLOSE_WAIT)

मैं थोड़ा सा चकित हूँ, ईमानदार होने के लिए।

अगर मैं बीमार नहीं हूँ तो Hah बीमार इसे मज़बूती से दोबारा तैयार करने के लिए एक और शॉट लेते हैं

मैंने अपने साथ ऐसा होते देखा है, लेकिन केवल तब जब मैं async मॉड्यूल w / 200+ एक साथ कनेक्शन का उपयोग कर रहा हूँ।

नमस्ते,
मुझे अनुरोध और जेंट के साथ बंदर पैचिंग का उपयोग करने में बिल्कुल समस्या थी: CLOSE_WAIT में रहने वाले कुछ कनेक्शन।
हो सकता है कि जियोवेंट के साथ कोई समस्या हो।

यह ulimit -n की समस्या हो सकती है। एक उच्च मूल्य के साथ प्रयास करें।

"बहुत अधिक खुली फाइलें" CLOSE_WAIT में रहने वाले सॉकेट्स के कारण बग का परिणाम है।
तो ulimit सिर्फ एक समाधान बनाने के लिए ठीक नहीं होगा।

@tamiel हम इसे कैसे ठीक करते हैं?

मैं और अधिक परीक्षण करूँगा और ठीक करने की कोशिश करूँगा।

मैंने इस पर ध्यान दिया है, और सभी पुस्तकालयों के साथ एक समस्या के साथ समस्या का उपयोग कर लगता है।

यहाँ एक उदाहरण पोस्ट किया है:

https://gist.github.com/1512329

मुझे केवल HTTP कनेक्शन के साथ एक async पूल का उपयोग करके एक बहुत ही समान त्रुटि का सामना करना पड़ा - मैं अभी भी जांच कर रहा हूं लेकिन एक पूल आकार को async.map में पास करने से त्रुटि जल्दी से पुन: उत्पन्न होती है।

इसके लिए कोई सुधार? यह अनुरोधों को अनुपयोगी बनाता है।

यह सब CLOSE_WAIT s के बारे में है। बस उन्हें बंद करना होगा। मुझे यकीन नहीं है कि वे अभी भी खुले क्यों हैं।

यह एक urllib3 मुद्दा है? अपने आप से इन को बंद करने के बाद मुझे लगता है कि एक महान विचार नहीं है।

यह एक सामान्य मुद्दे से अधिक है। हम यहां बातचीत रख सकते हैं।

ठीक है, बस आपको एक परिप्रेक्ष्य देने के लिए, हम रिफ़्लेप्स 2 से रिक्वेस्ट पर जाने की कोशिश कर रहे हैं, और हम इस मसले को सिप्लाब 2 के साथ नहीं देखते हैं। तो यह सुनिश्चित करने के लिए एक सामान्य मुद्दा नहीं है।

सामान्य तौर पर मेरा मतलब है कि यह बहुत गंभीर मुद्दा है जो सभी को प्रभावित करता है।

तो हम इसे कैसे हल करते हैं? हम वास्तव में अनुरोधों का उपयोग करना चाहते हैं

मुझे इसका उत्तर जानना अच्छा लगेगा।

रिसाव आंतरिक पुनर्निर्देशन हैंडलिंग के कारण प्रतीत होता है, जिसके कारण लंबित प्रतिक्रियाओं का उपभोग करने से पहले नए अनुरोध उत्पन्न होते हैं। परीक्षण में acdha @ 730c0e2e2bef77968a86962f9d5f2bebba4d19ec जारी रखने से पहले उपभोग की जाने वाली प्रत्येक प्रतिक्रिया के लिए मजबूर करके केवल एक संतोषजनक लेकिन प्रभावी सुधार है।

यह दो स्थानों में आवश्यक बदलाव करता है जो मुझे इंटरफ़ेस को थोड़ा सुधारना चाहता है लेकिन मैं वर्तमान में जारी रखने के लिए समय से बाहर हूं।

399 में एक फिक्स है जो हजारों अनुरोधों और कम fd ulitit के साथ मेरे async लोड जनरेटर (https://github.com/acdha/webtoolbox/blob/master/bin/http_bench.py) में अच्छा काम करता है।

मैं async का उपयोग करते समय एक ही मुद्दे में चला गया है - अनुरोधों को मंथन और प्रतिक्रियाएं / कॉलिंग हटाने आदि द्वारा एक हल निकाला गया

मेरा मानना ​​है कि मैं आज एक लाइसेंस प्राप्त सर्वर से जुड़ रहा था जो केवल 5 कनेक्शन की अनुमति देता है।

इससे पहले कि मैं 60 सेकंड के लिए रुका हुआ हो, async का उपयोग करके मैं केवल 4 चीजें प्राप्त कर सका।

खपत के साथ सामान्य GET का उपयोग करके मैं 40 सेकंड के भीतर धारावाहिक के बारे में 150 चीजें प्राप्त कर सकता था।

जब से मैंने इस मुद्दे को देखा है तब से मेरी कीचड़ नहीं बना है।

बस ipython का उपयोग करते समय यह त्रुटि हुई और यह संदेश मिला। यह बस एक बार में प्रत्येक अनुरोध कर रहा है, लेकिन मुझे लगता है कि मुझे async का उपयोग करते समय कुछ ऐसा ही मिला।

ERROR: Internal Python error in the inspect module.
Below is the traceback from this internal error.
Traceback (most recent call last):
    File "/Library/Python/2.7/site-packages/IPython/core/ultratb.py", line 756, in structured_traceback
    File "/Library/Python/2.7/site-packages/IPython/core/ultratb.py", line 242, in _fixed_getinnerframes
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 1035, in getinnerframes
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 995, in getframeinfo
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 456, in getsourcefile
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 485, in getmodule
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 469, in getabsfile
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 347, in abspath
OSError: [Errno 24] Too many open files

Unfortunately, your original traceback can not be constructed.

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

मैं इस परियोजना में भाग गया था, जहां मेरे पास allow_redirects True था; ऐसा लगता है कि रिडायरेक्शन श्रृंखला के कारण प्रतिक्रिया ऑब्जेक्ट लीक हो रहे हैं जो प्रीफ़ेच = ट्रू के साथ भी रिलीज़ नहीं हुए हैं। यह मेरे प्रारंभिक परीक्षण में तय किया:

        [i.raw.release_conn() for i in resp.history]
        resp.raw.release_conn()

हम्मम ।।

@acdha सेटिंग:

requests.defaults.defaults['allow_redirects'] = False

इससे पहले कि मैं कोई भी अनुरोध करता हूं अभी भी उसी त्रुटि का परिणाम है, लेकिन मुझे लगता है कि यह मेरे कार्यान्वयन के लिए कोई विकल्प नहीं है क्योंकि मैं जो भी अनुरोध कर रहा हूं उसके लिए एक पुनर्निर्देशन = / की आवश्यकता होगी

@dalanmiller आप अपनी प्रतिक्रियाओं को कैसे संसाधित कर रहे हैं? मैं पहले एक प्रतिक्रिया हुक के साथ async.map का उपयोग कर रहा था और यह async.imap से अधिक सरल लूप का उपयोग करके अधिक स्थिर होना था।

for resp in requests.async.imap(reqs, size=8):
    try:
        print resp.status_code, resp.url
    finally:
        [i.raw.release_conn() for i in resp.history]
        resp.raw.release_conn()

@ आकद

मैं बस एक यूआरएल सूची के माध्यम से लूप के लिए उपयोग कर रहा था और अपनी सेटिंग्स और इस तरह के प्रत्येक के साथ एक request.get कर रहा था।

for u in urls:
    response_list.append(requests.get(u))

मैंने आपके पेस्ट का उपयोग करने की कोशिश की और यह मेरी 900 लंबाई की सूची में लगभग 50 अनुरोधों के लिए काम करता है, जब तक कि मुझे बाकी के लिए "url के साथ अधिकतम रिट्रिट त्रुटियों को पार करना" शुरू न हो जाए। यह एक बहुत ही मानक त्रुटि है, हालांकि एक ही डोमेन को बार-बार हिट करने के लिए हालांकि, नहीं?

अरे, मैं 35k url की एक विशाल सूची को क्रॉल कर रहा था, और अनुरोधों के _some_ पर यही त्रुटि मिली।

मुझे इस तरह से 10 की मात्रा में पेशाब मिल रहा है:

responses = requests.async.map([requests.async.get(u, params=self.params()) for u in chunk]) # chunk is a list of 10

कहीं 20k रेंज में मुझे 24 त्रुटि मिलनी शुरू हो गई, तो यह ठीक 30k और फिर फिर से शुरू हो गई।

किसी भी अधिक जानकारी आप इसे नीचे संकीर्ण करने में रुचि होगी?

requests.async चला गया है। आप grequests पर जाने पर विचार करना चाह सकते हैं।

सब ठीक है, धन्यवाद। डॉक्स में इसका उल्लेख करना अच्छा रहेगा।

एक नोब की तरह जब यह पुल अनुरोधों और दस्तावेज लेखन की बात आती है, लेकिन मैंने इस पर एक छुरा लिया और इसे भेजा। कृपया टिप्पणी करें या आलोचना करें :)

https://github.com/kennethreitz/requests/pull/665

ठीक है, यह 6k अनुरोधों के बाद, केवल अनुरोधों के साथ, async का उपयोग किए बिना भी खुश है।

मुझे उस पर शक हुआ।

मेरे लिए 'बहुत खुली हुई फाइलें' त्रुटि 1k फ़ाइलों को डाउनलोड करने के बाद हुई। मेरा समाधान यह था कि जीवित-जीवित संपत्ति को निष्क्रिय कर दिया जाए, कभी भी चंक्स में अनुरोध प्राप्त किया जाए ( lsof -p PID | wc -l निष्पादन के दौरान कनेक्शन की गैर-बढ़ती संख्या को दर्शाता है।

rsess = requests.session()
rsess.config['keep-alive'] = False

rs = [grequests.get(l, session=rsess) for l in links]

for s in chunks(rs,100):
    responses = grequests.map(s, size=concurrency)
    for r in responses:
        try:
            print(r.status_code, r.url)
        finally:
            r.raw.release_conn()

[१] चौका लगाना: http://stackoverflow.com/a/312464

Urllib3 को ठीक करते समय बंद करना।

@kennethreitz urllib3 की अंक संख्या क्या है?

ऐसा लगता है कि यह मुद्दा है http://bugs.python.org/issue16298

@silvexis बहुत अच्छी तरह से urllib3 बग से संबंधित हो सकता है, अब मैं चाह रहा हूं कि कोई व्यक्ति @ piotr-dobrogost: P का जवाब दे।

क्या अब भी किसी और को इस मुद्दे का सामना करना पड़ रहा है?

मैंने इसकी कोई रिपोर्ट नहीं सुनी है। हे ना तू?

यह बॉक्स कॉन्फ़िगरेशन की समस्या है, फ्रेमवर्क की नहीं। अपने OS के कर्नेल कॉन्फ़िगरेशन को देखें। बीएसडी में इसे kern.maxfiles कहा जाता है। लिनक्स सिस्टम में लगभग ulimit का धागा है: http://stackoverflow.com/questions/34588/how-do-i-change-the-number-of-open-files-limit-in-linux
आशा है कि यह मदद करता है, और मुझे नहीं पता कि विंडोज पर इस पैरामीटर को कैसे बदलना है।

http://stackoverflow.com/questions/18024285/big-requests-issue-get-doesnt-release-reset-tcp-connections-loop-crashes

इस चेतावनी के साथ कि हम अभी भी अनुरोधों का पुराना संस्करण चला रहे हैं, हमारे पास इसे संभालने के लिए निम्न, भयानक, कोड हैं:

    if self._current_response is not None:
            # Requests doesn't have a clean API to actually close the
            # socket properly. Dig through multiple levels of private APIs
            # to close the socket ourselves. Icky.
            self._current_response.raw.release_conn()
            if self._current_response.raw._fp.fp is not None:
                sock = self._current_response.raw._fp.fp._sock
                try:
                    logger.debug('Forcibly closing socket')
                    sock.shutdown(socket.SHUT_RDWR)
                    sock.close()
                except socket.error:
                    pass

(मुझे लगता है कि self._current_response अनुरोधों की प्रतिक्रिया वस्तु है)

हम्म, बंद होने की श्रृंखला कहाँ टूटी हुई है? हमारे पास Response.close() पद्धति है, जो release_conn() कॉल करती है, इसलिए इस कार्य के लिए release_conn() होने की क्या आवश्यकता है?

@ लुकासा यह निश्चित रूप से urllib3 में तय किया गया था क्योंकि मैं चर्चा का हिस्सा था। अपने अनुमान में रूढ़िवादी होने के प्रति झुकाव के साथ, मैं कहूंगा कि यह अनुरोध 1.2.x के बाद से है अगर 1.1.x नहीं।

हाँ, मुझे लगता है कि यह तय हो गया था। जब तक हम 1.2.3 पर कुछ नहीं देखते हैं, मैं यह तय करना जारी रखूंगा।

मैं 2.0.2 के साथ CLOSE_WAIT लीक देख रहा हूं, क्या आपके पास यह सुनिश्चित करने के लिए इकाई परीक्षण हैं कि विषय पर कोई प्रतिगमन नहीं है?

नहीं, हम नहीं। AFAIK urllib3 या तो नहीं करता है। क्या आप आसानी से अपने रिसाव को पुन: उत्पन्न कर सकते हैं?

हम सोमवार से हमारे आंतरिक ऐप में अनुरोध का उपयोग करते हैं, और आज 1024 अधिकतमफ़ाइलों को हिट करते हैं।

रिबूट के 2 घंटे बाद, हमारे पास 40 CLOSE_WAIT है जैसा कि lsof द्वारा बताया गया है।

इसलिए मुझे लगता है कि हम देव माहौल में प्रजनन कर पाएंगे, हां। आप से संपर्क बना रहेगा

@tardyp भी, आपने अनुरोध कैसे स्थापित किया? मुझे लगता है कि सभी OS पैकेज मेंटेनर्स urllib3 को स्ट्रिप करते हैं। यदि वे अप-टू-डेट नहीं रखते हैं और आप एक पुराने संस्करण का उपयोग कर रहे हैं, तो इसके बजाय इसका कारण हो सकता है। यदि आप पाइप का उपयोग कर रहे हैं, तो इस पर चर्चा जोड़ने के बजाय इसे ट्रैक करने के लिए एक नया मुद्दा खोलने के लिए स्वतंत्र महसूस करें।

मैंने पाइप के साथ स्थापित किया है, लेकिन मैं अजगर 2.6 का उपयोग करता हूं, मैंने इसके लिए python2.7 पर फिक्स देखा है
यह बग। क्या आप पुराने संस्करण के लिए मंकीपैक करते हैं?

पियरे

शुक्र पर, 29 नवंबर, 2013 को शाम 5:33 बजे, इयान कॉर्डैस्को सूचनाएं @github.comwrote:

@tardyp https://github.com/tardyp भी, आपने अनुरोध कैसे स्थापित किया? मैं
लगता है कि सभी OS पैकेज अनुरक्षकों ने urllib3 को अलग कर दिया है। यदि वे नहीं करते हैं
उस अप-टू-डेट रखें और आप एक पुराने संस्करण का उपयोग कर रहे हैं, यह हो सकता है
इसके बजाय कारण। यदि आप पाइप का उपयोग कर रहे हैं, तो बेझिझक एक नया मुद्दा खोलें
इस पर चर्चा जोड़ने के बजाय इसे ट्रैक करें।

-
इस ईमेल का उत्तर सीधे दें या Gi tHubhttps पर
।

@tardyp कृपया एक नया मुद्दा जितना संभव हो सके उतने विवरण सहित खोलें, जिसमें आपके द्वारा किए जा रहे अनुरोधों को पुनर्निर्देशित किया गया है और क्या आप जियोवेंट का उपयोग कर रहे हैं। साथ ही, ऑपरेटिंग सिस्टम के बारे में कोई भी विवरण और इसे कैसे पुन: पेश किया जाए इसका एक उदाहरण शानदार होगा।

FYI करें https://github.com/shazow/urllib3/issues/291 बग के कारण वापस कर दिया गया है।

क्या हमें इसे फिर से खोलना चाहिए?
मुझे भी वही समस्या हो रही है!

@polvoazul कोई रास्ता नहीं है यह वही मुद्दा है, जो मूल रूप से 2011 में रिपोर्ट किया गया था, इसलिए मुझे नहीं लगता कि फिर से खोलना सही है। हालाँकि, यदि आप अनुरोधों की वर्तमान रिलीज़ (2.4.3) को चला रहे हैं और समस्या को पुन: उत्पन्न कर सकते हैं, तो एक नया मुद्दा खोलना सही होगा।

@Lukasa मुझे आपकी ज़रूरत है

मुझे क्षमा करें @mygoda , लेकिन यह जानना असंभव है। यदि आप किसी भी एक समय में बकाया हो सकने वाले अनुरोधों की संख्या में कमी नहीं कर रहे हैं, तो यह निश्चित रूप से संभव है, लेकिन यह अनुरोधों के पुनरीक्षण के बाहर एक वास्तुशिल्प समस्या है।

@Lukasa आपको धन्यवाद my मुझे लगता है कि मेरा मुद्दा इस you के साथ समान है, मेरी परियोजना

अब एक ही समस्या है, 120 धागे चल रहे हैं, 100000+ खोली गई फ़ाइलों का कारण है, अभी कोई समाधान?

@mygoda आप कमाल के पीरियड का इस्तेमाल करते हैं use

@ 1a1a11a _What_ फाइलें आपके पास क्या हैं? इस समस्या को समझने के लिए यह एक उपयोगी पहला कदम होगा।

@ 1a1a11a आप किस संस्करण का अनुरोध कर रहे हैं? अजगर का क्या संस्करण? क्या ऑपरेटिंग सिस्टम? क्या हमें कोई जानकारी मिल सकती है?

मैं अनुरोध का उपयोग कर रहा हूँ 2.9.1, अजगर 3.4, ubuntu 14.04, मूल रूप से मैं कुछ वेबसाइट क्रॉल करने के लिए परदे के पीछे 30 धागे का उपयोग करके एक क्रॉलर लिख रहा हूं। वर्तमान में मैंने फ़ाइल की सीमा प्रति प्रक्रिया को 655350 पर समायोजित कर दिया है, अन्यथा यह त्रुटि की रिपोर्ट करेगा।

मुझे अभी भी "नया कनेक्शन स्थापित करने में विफल" त्रुटि प्राप्त हो रही है: [Errno 24] बहुत सारी खुली फाइलें "request.packages.urllib3.connection.VerifiedHTTPSConnection से।" मैं Pyth 3.4 का उपयोग कर रहा हूं, 2.11.1 और अनुरोधों-वायदा का उपयोग कर रहा हूं। 0.9.7। मैं अनुरोधों की सराहना करता हूं-वायदा एक अलग पुस्तकालय है, लेकिन ऐसा लगता है कि त्रुटि अनुरोधों से आ रही है। मैं SSL पर 180k अतुल्यकालिक अनुरोध करने का प्रयास कर रहा हूं। मैंने उन अनुरोधों को 1000 के खंडों में विभाजित किया है, इसलिए मैं। भविष्य की सभी वस्तुओं के हल हो जाने के बाद ही अगले 1000 पर जाएं। मैं Ubuntu 16.04.2 चला रहा हूं और मेरी डिफ़ॉल्ट खुली फ़ाइलों की सीमा 1024 है। इस त्रुटि के अंतर्निहित कारण को समझना अच्छा होगा। प्रत्येक व्यक्तिगत अनुरोध के लिए एक खुली फ़ाइल? और यदि ऐसा है, तो क्यों? यह एक एसएसएल प्रमाणपत्र फ़ाइल है? और क्या अनुरोध पुस्तकालय भविष्य की वस्तु को हल करने पर स्वचालित रूप से उन खुली फाइलों को बंद कर देता है?

अनुरोध कई फाइलें खोलता है। उन फ़ाइलों में से कुछ प्रमाण पत्र के लिए खोले जाते हैं, लेकिन वे OpenSSL द्वारा खोले जाते हैं और अनुरोधों द्वारा नहीं, इसलिए वे बनाए नहीं रखे जाते हैं। इसके अतिरिक्त, अनुरोध भी खुलेगा, यदि आवश्यक हो, तो .netrc फ़ाइल, होस्ट्स फ़ाइल, और कई अन्य।

आपको strace जैसे टूल का उपयोग करके सबसे अच्छा काम किया जाएगा जो कि फाइलें खोलते हैं। सिस्टम कॉल की एक सख्त सूची है जो फ़ाइल डिस्क्रिप्टर को आवंटित करने की ओर ले जाती है, इसलिए आपको यथोचित रूप से तेजी से इनकी गणना करनी चाहिए। इससे आपको यह भी पता चल जाएगा कि कोई समस्या है या नहीं। लेकिन, हाँ, मुझे उम्मीद है कि अगर आप सक्रिय रूप से HTTPS पर 1000 कनेक्शन

मैंने इस मुद्दे के साथ भी संघर्ष किया और पाया कि OS X पर opensnoop का उपयोग करने से मुझे यह देखने में बहुत खुशी हुई कि अगर कोई भी समान मुद्दों पर चलता है तो क्या हो रहा है।

मैं भी बार-बार requests.post(url, data=data) से HTTP (न कि HTTPS) सर्वर पर कॉल करते समय इस त्रुटि को अक्सर देख रहा हूँ। Ubuntu 16.04.3, पायथन 3.5.2 पर चल रहा है, 2.9.1 अनुरोध करता है

data क्या है?

कुछ सौ केबी पाठ

फ़ाइल ऑब्जेक्ट नहीं है?

नहीं, मैं स्मृति में एक बड़ी क्वेरी बनाता हूं।

क्या आप इस कोड को कई थ्रेड में चला रहे हैं?

नहीं, एकल धागा, लोकलहोस्ट के लिए पोस्टिंग

हमें लगता है कि कई एफडी को लीक करना लगभग असंभव है: हमें बार-बार एक ही टीसीपी कनेक्शन का उपयोग करना चाहिए या आक्रामक तरीके से इसे बंद करना चाहिए। जांचना चाहते हैं कि आपका सर्वर क्या है?

मुझे यह समस्या हो रही है। पायथन 2.7, अनुरोध 2.18.4, urllib3 1.22।
बहु-थ्रेडेड कोड (बहु-संसाधित नहीं) चलाना। एक समय में अधिकांश 6 URL से कनेक्ट करना, मैन्युअल रूप से प्रत्येक के लिए एक नया सत्र बनाना और बंद करना।

मुझे Python 3.5 , requests==2.18.4 पर एक ही समस्या हो रही है

@mcobzarenco क्या आप सुनिश्चित हैं कि आप (अंतर्निहित) प्रतिक्रिया के अंतर्निहित कनेक्शन को बंद कर रहे हैं? बस प्रतिक्रिया वापस करने से कनेक्शन बंद नहीं होगा। प्रतिक्रिया पढ़ते समय। डेटा वास्तव में पढ़ा जाता है और उसके बाद सॉकेट CLOSE_WAIT में नहीं रहेगा।