requests.async ?

아니요, 모든 요청은 합리적으로 일반 requests.get / requests.post였습니다.

$ lsof | grep localhost | wc -l
110

4/5를 제외하고 모두 형식입니다.

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

솔직히 말해서 조금 당황 스럽습니다.

Hah ill 다시 한 번 찍어 안정적으로 재현 할 수 없다면

나는 이것이 나에게 일어나는 것을 보았지만 200 개 이상의 동시 연결이있는 비동기 모듈을 사용할 때만 가능합니다.

안녕하세요,
gevent와 함께 요청 및 원숭이 패치를 사용하여 정확히 동일한 문제가 발생했습니다. 일부 연결은 CLOSE_WAIT에 있습니다.
gevent에 문제가있을 수 있습니다.

ulimit -n 문제 일 수 있습니다. 더 높은 값으로 시도하십시오.

"열린 파일이 너무 많음"은 소켓이 CLOSE_WAIT에 머물러서 발생하는 버그의 결과입니다.
그래서 ulimit는 해결하지 않습니다.

@tamiel 이 문제를 어떻게 해결합니까?

최대한 빨리 더 많은 테스트를 수행하고 수정하려고합니다.

나는 그것을 조사했고 httplib.HTTPSConnection을 사용하는 모든 라이브러리에 문제가있는 것 같습니다.

여기에 예를 게시했습니다.

https://gist.github.com/1512329

HTTP 연결 만있는 비동기 풀을 사용하여 매우 유사한 오류가 발생했습니다. 아직 조사 중이지만 풀 크기를 async.map에 전달하면 오류가 빠르게 재현됩니다.

이것에 대한 수정 사항이 있습니까? 이로 인해 gevent에서 요청을 사용할 수 없습니다.

CLOSE_WAIT 에 관한 모든 것입니다. 닫아야합니다. 그래도 왜 여전히 열려 있는지 모르겠습니다.

urllib3 문제입니까? 이것들을 스스로 닫는 것은 좋은 생각이 아닙니다.

더 일반적인 문제입니다. 여기서 대화를 계속할 수 있습니다.

당신에게 관점을 제공하기 위해 우리는 httplib2에서 요청으로 이동하려고 시도하고 있으며 httplib2에서는이 문제를 보지 못했습니다. 따라서 일반적인 문제는 아닙니다.

일반적으로 관련된 모든 사람에게 영향을 미치는 매우 심각한 문제라는 것을 의미합니다.

그래서 우리는 이것을 어떻게 해결합니까? 우리는 정말로 요청 + 수면을 사용하고 싶습니다.

이에 대한 답을 알고 싶습니다.

누수는 내부 리디렉션 처리로 인한 것으로 보이며 보류중인 응답이 사용되기 전에 새 요청이 생성됩니다. 테스트에서 acdha @ 730c0e2e2bef77968a86962f9d5f2bebba4d19ec 는 계속하기 전에 각 응답을 사용하도록 강제함으로써 만족스럽지 않지만 효과적인 수정

이것은 인터페이스를 약간 리팩토링하고 싶게 만드는 두 곳에서 변경이 필요했지만 현재 계속할 시간이 없습니다.

399에는 수천 개의 요청과 낮은 fd ulimit가있는 비동기로드 생성기 (https://github.com/acdha/webtoolbox/blob/master/bin/http_bench.py)에서 잘 작동하는 수정 사항이 있습니다.

async를 사용할 때 동일한 문제가 발생했습니다. 청크 요청 및 응답 삭제 /gc.collect 호출로 해결 방법을 찾았습니다.

저는 오늘 5 개의 연결 만 허용하는 라이선스 서버에 연결하는 중이라고 생각합니다.

비동기를 사용하면 60 초 동안 일시 중지되기 전에 4 가지 항목 만 가져올 수 있습니다.

소비와 함께 일반 GET을 사용하면 40 초 이내에 약 150 개의 항목을 연속적으로 가져올 수 있습니다.

이 문제를 본 이후로 아직 내 실수를하지 않았습니다.

ipython을 사용하는 동안이 오류가 발생하고이 메시지가 나타납니다. 이것은 각 요청을 한 번에 하나씩 만드는 것이지만 비동기를 사용할 때 비슷한 것이 있다고 생각합니다.

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.

이상하게도 일반 Python 인터프리터 만 사용할 때 "Max Retries Error"가 발생한다고 생각하지만 동일한 도메인에서 요청을 수행하는 또 다른 문제라고 생각하지만 확실하지 않습니다.

나는 allow_redirects가 True 인 첫 번째 프로젝트에서 이것을 만났다. 이는 prefetch = 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 이상의 간단한 루프를 사용하여 더 안정적이되는 것으로 _appears_ :

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()

@acdha

나는 URL 목록을 통해 for 루프를 사용하고 내 설정 등으로 각각에 request.get을 수행했습니다.

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

붙여 넣기를 사용해 보았고 나머지는 "최대 재시도 오류가 url을 초과했습니다"라는 메시지가 표시 될 때까지 900 개 길이 목록에있는 약 50 개의 요청에 대해 작동합니다. 그래도 동일한 도메인을 반복적으로 공격하는 것은 꽤 표준적인 오류입니다.

이봐, 나는 35k의 거대한 URL 목록을 크롤링하고 있었고 _some_의 요청에서 이와 동일한 오류가 발생했습니다.

다음과 같이 10 개 단위로 URL이 표시됩니다.

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로 이동하는 것을 고려할 수 있습니다.

좋아, 고마워. 문서에서 이것을 언급하는 것이 좋을 것입니다.

Pull Requests와 문서 작성에 관해서는 일종의 멍청한 일이지만 나는 그것을 찔러 보냈습니다. 의견이나 비판 부탁드립니다 :)

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

좋아, 이것은 6K 요청 후 requests.get만으로 비동기를 사용하지 않고도 발생합니다.

나는 그것을 의심했다.

나에게 정확히 1k 파일을 다운로드 한 후 '너무 많은 파일 열기'오류가 발생했습니다. 내 해결책은 Keep-alive 속성을 비활성화하고 청크 단위로 요청을받는 것입니다 ( @acdha 힌트에 감사드립니다). 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()

[1] 청킹 : http://stackoverflow.com/a/312464

urllib3 수정을 연기하는 동안 닫기.

@kennethreitz urllib3의 발행 번호는 무엇입니까?

이것이 문제인 것 같습니다 http://bugs.python.org/issue16298

@silvexis 는 urllib3 버그와 매우 관련이있을 수 있습니다. 이제 누군가 @ piotr-dobrogost에 대답했으면합니다.

다른 사람이 여전히이 문제를 겪고 있습니까?

나는 그것에 대한보고를들은 적이 없다. 당신은?

프레임 워크가 아닌 박스 구성의 문제입니다. OS의 커널 구성을 살펴보십시오. BSD에서는 kern.maxfiles 합니다. Linux 시스템에는 ulimit 에 대한 스레드가 있습니다. http://stackoverflow.com/questions/34588/how-do-i-change-the-number-of-open-files-limit-in-linux
도움이되기를 바라며 Windows에서이 매개 변수를 변경하는 방법을 모르겠습니다.

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가 요청의 응답 객체라고 생각합니다)

흠, 닫는 사슬은 어디에서 끊어 졌나요? release_conn() 를 호출하는 Response.close() 메서드가 있습니다.이 작업을 수행하려면 release_conn() 에서 어떤 일이 발생해야합니까?

@Lukasa 이것은 토론의 일부 였기 때문에 urllib3에서 확실히 수정되었습니다. 내 추정치에서 보수적 인 경향이 있으므로 1.1.x가 아니라면 1.2.x를 요청하기 때문에 거기에 있다고 말할 것입니다.

네,이게 고쳐 졌다고 생각 했어요. 1.2.3에서 무언가를 보지 않는 한 계속해서 이것이 수정되었다고 가정 할 것입니다.

2.0.2에서 CLOSE_WAIT 누출이 발생했습니다. 주제에 대한 회귀가 없는지 확인하는 단위 테스트가 있습니까?

아니, 그렇지 않습니다. AFAIK urllib3도 마찬가지입니다. 누출을 쉽게 재현 할 수 있습니까?

월요일부터 내부 앱에서 요청을 사용했으며 오늘은 1024 개의 maxfiles에 도달했습니다.

재부팅 후 2 시간이 지나면 lsof에서 말한대로 40 개의 CLOSE_WAIT가 있습니다.

그래서 저는 우리가 개발 환경에서 재현 할 수있을 것이라고 생각합니다. 계속 연락 할게

@tardyp 도 요청을 어떻게 설치 했습니까? 모든 OS 패키지 관리자가 urllib3을 제거한다고 생각합니다. 최신 상태로 유지하지 않고 이전 버전을 사용하고 있다면 그 원인이 될 수 있습니다. pip를 사용하는 경우이 문제에 토론을 추가하는 대신 새 문제를 열어 추적 할 수 있습니다.

pip로 설치했지만 python 2.6을 사용하고 있습니다.
이 버그. 이전 버전을위한 monkeypatch입니까?

피에르

2013 년 11 월 29 일 금요일 오후 5시 33 분 Ian Cordasco [email protected]

@tardyp https://github.com/tardyp 도 요청을 어떻게 설치 했나요? 나는
모든 OS 패키지 관리자가 urllib3을 제거한다고 생각하십시오. 그렇지 않다면
최신 상태로 유지하고 이전 버전을 사용하고 있습니다.
대신 원인. pip를 사용하는 경우 언제든지 새로운 문제를 열어
이것에 토론을 추가하는 대신에 이것을 추적하십시오.

—
이 이메일에 직접 회신하거나 Gi tHub에서 확인하십시오.
.

@tardyp 요청에 리디렉션이 있는지 여부와 gevent를 사용 중인지 여부를 포함하여 가능한 한 자세한 내용으로 새 문제를여십시오. 또한 운영 체제에 대한 세부 정보와이를 재현하는 방법에 대한 예도 환상적 일 것입니다.

참고로 https://github.com/shazow/urllib3/issues/291 은 버그로 인해 되돌 렸습니다.

다시 열어 볼까요?
나는 같은 문제가 있습니다!

@polvoazul 이것이 2011 년에 처음보고 된 것과 같은 문제 일

@Lukasa 나는 당신이 도움이 필요합니다。 나는 항상 프로토콜을 식별 할 수없는 너무 많은 양말을 만드는 eventlet + 요청을 사용합니다. 내 요청은 2.4.3입니다. eventlet + 요청 이이 문제를 유발합니까?

@mygoda 미안하지만 알 수 없습니다. 한 번에 처리 할 수있는 요청의 수를 제한하지 않는 경우 확실히 가능하지만 이는 요청을 제외한 아키텍처 문제입니다.

@Lukasa 감사합니다. 내 문제가 이것과 비슷하다고 생각 합니다 . 내 프로젝트는 pyvmomi 입니다. 그 연결은 긴 연결입니다. 왜 그렇게 많은 사람들이 프로토콜 양말을 식별 할 수 없는지 항상 혼란 스러웠습니다.

지금 같은 문제가 발생하여 120 개의 스레드를 실행하면 10 만 개 이상의 열린 파일이 발생합니다. 지금 당장 해결 방법이 있습니까?

@mygoda 당신은 멋진 기간을 사용합니다.

@ 1a1a11a _What_ 파일이 열려 있습니까? 이 문제를 이해하는 데 유용한 첫 번째 단계입니다.

@ 1a1a11a 어떤 버전의 요청을 사용하고 있습니까? 어떤 버전의 파이썬? 어떤 운영 체제? 정보를 얻을 수 있습니까?

요청 2.9.1, python 3.4, 우분투 14.04를 사용하고 있으며 기본적으로 30 개의 스레드를 프록시와 함께 사용하여 일부 웹 사이트를 크롤링하는 크롤러를 작성하고 있습니다. 현재 프로세스 당 파일 제한을 655350으로 조정했습니다. 그렇지 않으면 오류가보고됩니다.

requests.packages.urllib3.connection.VerifiedHTTPSConnection에서 "Failed to set a new connection : [Errno 24] Too many open files"라는 오류 메시지가 계속 나타납니다. Python 3.4, 요청 2.11.1 및 requests-futures를 사용하고 있습니다. 0.9.7. requests-futures는 별도의 라이브러리라는 점에 감사하지만 요청에서 오류가 발생한 것 같습니다. SSL을 통해 180k 비동기 요청을 시도하고 있습니다. 이러한 요청을 1000 개의 세그먼트로 나누었습니다. 미래의 모든 개체가 해결 된 후에 만 ​​다음 1000 개로 이동합니다. Ubuntu 16.04.2를 실행 중이고 기본 열린 파일 제한은 1024입니다.이 오류의 근본적인 원인을 이해하는 것이 좋습니다. 요청 라이브러리가 생성합니까? 각 개별 요청에 대해 열린 파일입니까? 그렇다면 그 이유는 무엇입니까? SSL 인증서 파일입니까? 그리고 요청 라이브러리는 향후 개체가 해결 될 때 열린 파일을 자동으로 닫습니까?

요청은 많은 파일을 엽니 다. 이러한 파일 중 일부는 인증서 용으로 열리지 만 요청이 아닌 OpenSSL에 의해 열리므로 유지되지 않습니다. 또한 요청은 필요한 경우 .netrc 파일, 호스트 파일 및 기타 여러 파일도 엽니 다.

strace 와 같은 도구를 사용하여 어떤 파일이 열려 있는지 확인하는 것이 가장 좋습니다. 파일 디스크립터가 할당되도록하는 시스템 호출의 엄격한 목록이 있으므로 합리적으로 신속하게 열거 할 수 있어야합니다. 또한 문제가 있는지 여부를 알려줍니다. 하지만 예, HTTPS를 통해 1000 개의 연결을 적극적으로 수행 하는 경우 최대로드시 1000 개 이상의 FD를 쉽게 사용할 수있을 것으로 예상합니다.

나는이 문제로도 어려움을 겪었고 OS X에서 opensnoop 를 사용하는 것이 같은 문제에 부딪히면 어떤 일이 벌어지고 있는지 알 수 있다는 것을 알게되었습니다.

또한 HTTP (HTTPS 아님) 서버에 requests.post(url, data=data) 을 반복해서 호출 할 때이 오류가 자주 표시됩니다. Ubuntu 16.04.3, Python 3.5.2에서 실행, 2.9.1 요청

data 무엇입니까?

수백 kb 텍스트

파일 객체가 아닙니까?

아니요, 메모리에 큰 쿼리를 작성합니다.

이 코드를 여러 스레드에서 실행하고 있습니까?

아니요, 단일 스레드, localhost에 게시

그렇게 많은 FD를 유출하는 것은 거의 불가능 해 보입니다. 동일한 TCP 연결을 반복적으로 사용 하거나 공격적으로 닫아야합니다. 서버의 성능을 확인하고 싶으십니까?

이 문제가 있습니다. Python 2.7, 요청 2.18.4, urllib3 1.22.
다중 스레드 코드 실행 (다중 처리 아님). 한 번에 최대 6 개의 URL에 연결하고 각 URL에 대해 수동으로 새 세션을 만들고 닫습니다.

Python 3.5 , requests==2.18.4 에서 같은 문제가 있습니다.

@mcobzarenco 응답의 기본 연결을 (암시 적으로) 닫고 있습니까? 응답을 반환한다고해서 연결이 끊어지지는 않습니다. response.content를 읽을 때 데이터는 실제로 읽히고 그 후에 소켓은 CLOSE_WAIT에 머물지 않습니다.