이 문제를 제기하고 자세한 정보를 제공해 주셔서 감사합니다!

말해 봐요, 어떤 시점에서 메모리 사용량이 감소하는 것을 본 적이 있습니까?

메모리 사용량이 줄어드는 것을 보지 못했습니다. 나는 그것이 파이썬의 가비지 수집기와 관련이 있는지 궁금했고 아마도 시작할 기회가 없었을 것이므로 다운로드 할 때마다 gc.collect() 에 대한 호출을 추가했습니다. 그것은 아무런 차이가 없었습니다.

이 문제가 종결 된 이유를 물어봐도 될까요?

우리 회사는 pypy를 사용할 때 더욱 강화 된 이와 동일한 문제를 경험했습니다. 우리는 코드베이스에서이 문제의 원인을 파이썬 요청으로 추적하는 데 며칠을 보냈습니다.

이 문제의 심각성을 강조하기 위해 다음은 메모리 프로파일 러를 실행할 때 서버 프로세스 중 하나가 어떻게 생겼는지 보여주는 스크린 샷입니다.
http://cl.ly/image/3X3G2y3Y191h

이 문제는 일반 cpython에서 여전히 존재하지만 눈에 띄지 않습니다. 아마도 이것이 오랜 프로세스에이 라이브러리를 사용하는 사람들에게 심각한 결과를 가져 왔음에도 불구하고이 문제가보고되지 않은 이유 일 것입니다.

이 시점에서 우리는 하위 프로세스와 함께 curl을 사용하는 것을 고려할만큼 절실합니다.

귀하의 생각과 이것이 철저히 조사 될 경우 알려주십시오. 그렇지 않으면 python-requests가 미션 크리티컬 애플리케이션 (예 : 의료 관련 서비스)에 사용하기에는 너무 위험하다고 생각합니다.

감사,
-매트

활동이 없어 폐쇄되었습니다. 올바른 방향으로 안내하는 데 유용한 진단 정보를 제공 할 수 있다고 생각하시면 기꺼이 다시 열어 드리겠습니다.

그럼 제가 도와 드리겠습니다.

이 문제를 쉽게 조사 할 수 있도록 작은 git repo를 만들었습니다.
https://github.com/mhjohnson/memory-profiling-requests

다음은 생성되는 그래프의 스크린 샷입니다.
http://cl.ly/image/453h1y3a2p1r

도움이 되었기를 바랍니다! 내가 잘못한 일이 있으면 알려주세요.

-매트

고마워 Matt! 지금부터 살펴 보겠습니다. 처음 몇 번 스크립트를 실행했고 (그리고 내가 시도한 변형) 이것이 쉽게 재현 할 수 있음을 보여주었습니다. 이제 이걸 가지고 놀아야 겠어요.

따라서 이것은 요청 당 약 0.1MB로 증가합니다. 낮은 수준의 메서드에 profile 데코레이터를 사용하려고 시도했지만 출력이 원격으로 유용하기에는 너무 길고 0.1보다 높은 간격을 사용하는 것은 전체 사용량을 추적하는 데만 사용되는 것 같습니다. 라인 사용. mprof보다 더 나은 도구가 있습니까?

그래서 대신 출력을 | ag '.*0\.[1-9]+ MiB.*' 로 파이프하여 메모리가 추가 된 줄을 가져오고 profile 데코레이터를 Session#send 로 옮겼습니다. 당연히 대부분은 HTTPAdapter#send 호출에서 비롯됩니다. 나는 토끼 구멍 아래로

이제는 L355 및 HTTPAdapter#get_connection conn.urlopen 호출에서 모두 발생합니다. get_connection 꾸미면 PoolManager#connection_from_url 호출 할 때 메모리를 7 번 할당합니다. 이제 대다수가 urllib3에서 반환 된 HTTPResponse 에 의해 트리거되는 경우, 사실 이후에 메모리가 해제되지 않도록해야하는 일이 있는지 살펴 보겠습니다. 이를 처리하는 좋은 방법을 찾을 수 없다면 urllib3을 파헤 치기 시작할 것입니다.

@ sigmavirus24 와우. 훌륭한 일! 코드에서 핫스팟을 정확히 찾아낸 것 같습니다.
메모리 누수를 담당하는 객체를 추적하려면 다음과 같이 objgraph를 사용하여 추가 힌트를 얻을 수 있습니다.

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

Lemme는 내가 어떤 식 으로든 도울 수 있는지 알고 있습니다.

-매트

범인에 대한 첫 번째 추측은 소켓 객체입니다. 그것은 PyPy에서 더 나쁜 이유를 설명 할 것입니다.

나는 지금 공항에 앉아 있고 곧 몇 시간 동안 평야에있을 것입니다. 나는 아마도 오늘 밤 또는 잠재적으로 이번 주 후반까지 (다음 주말 / 주가 아니라면)이 작업을 수행 할 수 없을 것입니다. 지금까지 우리가 돌려받는 HTTPResponse 에 release_conn 를 사용해 보았습니다. 나는 gc.get_referents 로 GC에 실패 할 수있는 Response 객체가 무엇인지 확인했습니다. 원본 httplib HTTPResponse ( _original_response 로 저장되고 get_referents 가보고 한 내용에서)에만 이메일 메시지 (헤더 용) 만 있고 나머지는 모두 문자열이나 사전 (또는 소켓이라면 어디에서 가비지 수집되지 않을지 알 수 없습니다.

또한 Session#close (코드에서 먼저 기능 API 대신 세션을 사용하도록했습니다)를 사용하는 것은 도움이되지 않습니다 (연결 풀을 지우는 PoolManager를 지워야합니다). 그래서 흥미로운 점은 PoolManager#connection_from_url 가 처음 몇 번 호출 될 때 ~ 0.8MB (0.1을 주거나 가져가는)를 추가한다는 것입니다. 그래서 그것은 ~ 3MB를 추가하지만 나머지는 HTTPAdapter#send conn.urlopen 에서 나옵니다. 이상한 점은 gc.set_debug(gc.DEBUG_LEAK) 를 사용하면 gc.garbage 에 이상한 요소가 있다는 것입니다. [[[...], [...], [...], None], [[...], [...], [...], None], [[...], [...], [...], None], [[...], [...], [...], None]] 와 같은 것이 있고 예상대로 gc.garbage[0] is gc.garbage[0][0] 이므로 정보는 전혀 쓸모가 없습니다. 기회가 생기면 objgraph를 실험해야합니다.

그래서 저는 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 보면 이것이 원인이되는 줄은 다른 HTTPConnection 메서드 인 conn.connect() 입니다. connect 는 거의 확실하게 소켓이 생성되는 곳입니다. 메모리 프로파일 링을 비활성화하고 print(old_pool) 에 HTTPConnectionPool#close print(old_pool) 를 붙이면 아무것도 인쇄되지 않습니다. 세션이 파괴됨에 따라 실제로 풀을 닫지 않는 것 같습니다. 내 생각 엔 이것이 메모리 누수의 원인이라는 것입니다.

이 문제를 디버그하는 데 도움을 드리고자합니다. 오늘과 내일 IRC에 들어오고 나갈 것입니다.

따라서 이것을 추가로 추적하면 _make_request 여전히 장식 된 ( profile )으로 python 를 열고 세션을 생성 한 다음 10 초 또는 20 초마다 동일한 URL도), conn이 삭제 된 것으로 간주되어 VerifiedHTTPSConnection 가 닫히고 재사용되는 것을 볼 수 있습니다. 이것은 connection 클래스가 기본 소켓이 아니라 재사용됨을 의미합니다. close 메서드는 httplib.HTTPConnection (L798)에있는 메서드입니다. 소켓 객체를 닫은 다음 None으로 설정합니다. 그런 다음 가장 최근의 httplib.HTTPResponse 닫고 None으로 설정합니다. VerifiedHTTPSConnection#connect 도 프로파일하면 생성 / 누수 된 모든 메모리가 urllib3.util.ssl_.ssl_wrap_socket 합니다.

따라서 이것을 보면 memory_profiler가 메모리 사용량을보고하는 데 사용하는 것은 프로세스의 상주 세트 크기 (rss)입니다. 이것은 RAM의 프로세스 크기 (VM 또는 가상 메모리 크기는 mallocs와 관련이 있음)이므로 가상 메모리가 누출되는지 또는 페이지가 할당되었는지 확인하려고합니다. 우리가 잃지 않는 기억.

따라서 지금까지 사용했던 모든 URL이 확인 된 HTTPS를 사용하고 있다는 점을 감안할 때 http://google.com 를 사용하도록 전환했으며 여전히 메모리가 지속적으로 증가하고 있지만 11-14MiB 더 적게 소비하는 것 같습니다. 전체적으로. 여전히 모든 것이 conn.getresponse 라인으로 돌아옵니다 (그리고 지금은 conn.request ).

흥미로운 점은 VMS가 repl에서 검사 할 때 많이 성장하지 않는 것 같습니다. RSS 값 대신 해당 값을 반환하도록 mprof를 아직 수정하지 않았습니다. 꾸준히 증가하는 VMS는 확실히 메모리 누수를 가리키며 RSS는 단순히 많은 수의 malloc 일 수 있습니다 (가능함). 대부분의 운영 체제 (내가 올바르게 이해 한 경우)는 RSS를 열심히 회수하지 않으므로 다른 응용 프로그램 페이지에 오류가 발생하고이를 할당 할 다른 위치가 없을 때까지 RSS는 축소되지 않습니다 (가능하더라도). 즉, 정상 상태에 도달하지 않고 지속적으로 증가하는 경우 요청 / urllib3인지 아니면 인터프리터인지 확신 할 수 없습니다.

나는 이것이 우리의 문제가 아니라고 생각하기 시작했기 때문에 urllib2 / httplib를 직접 사용할 때 어떤 일이 발생하는지 볼 것입니다. 내가 알 수있는 한, Session#close 모든 소켓을 올바르게 닫고 GC가 될 수 있도록 해당 소켓에 대한 참조를 제거합니다. 또한 소켓을 연결 풀로 교체해야하는 경우에도 마찬가지입니다. SSLSocket조차도 가비지 수집을 제대로 처리하는 것 같습니다.

따라서 urllib2는 13.3MiB 주변에서 일관되게 평평한 것처럼 보입니다. 차이점은 잠시 후 URLError와 함께 지속적으로 충돌하기 때문에 try / except로 래핑해야한다는 것입니다. 그래서 아마도 잠시 후에 실제로 아무것도하지 않을 것입니다.

@ sigmavirus24 당신은 그것을 분쇄하고 있습니다! :)

흠 ... Python은 자체적으로 다시 사용할 수 있도록 메모리 만 해제하고 프로세스가 종료 될 때까지 시스템은 메모리를 다시 가져 오지 않습니다. 따라서 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 개 있지만 수집 할 수없는 것은 없습니다. @mhjohnson이 제공 한 스크립트에 이것을 추가하고 도달 할 수없는 행에 대한 출력을 필터링하면 도달 할 수없는 개체가 300 개가 훨씬 넘는 경우가 많다는 것을 알 수 있습니다. 나는 아직 도달 할 수없는 개체의 중요성을 알지 못합니다. 항상 그렇듯이 모두 게시하겠습니다.

테스트 urllib3에 @mhjohnson, 그냥에 전화를 대체 requests.get 와 urllib2.urlopen (또한 내가 아마 일을 했어야 r.read() 하지만 난하지 않았다).

그래서 @mhjohnson 의 이전 제안을 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

안녕하세요.
그래, 마지막 그래픽으로 좀 잃어 버렸어. 아마도 내가 코드베이스를 잘 모르기 때문이거나 메모리 누수 디버깅에 능숙하지 않기 때문일 것이다.

이 그래픽 스크린 샷에서 빨간색 화살표로 가리키는 물체가 무엇인지 아십니까?
http://cl.ly/image/3l3g410p3r1C

천천히 증가하는 메모리 사용량을 보여주는 코드를 얻을 수있었습니다.
urllib3 / requests를 urllib.request.urlopen으로 대체하여 python3에서.

수정 된 코드 : https://gist.github.com/kevinburke/f99053641fab0e2259f0

케빈 버크
전화 : 925.271.7005 | twentymilliseconds.com

2014 년 11 월 3 일 월요일 오후 9:28, Matthew Johnson [email protected]
썼다 :

@ sigmavirus24 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

2014 년 11 월 3 일 월요일 오후 9시 43 분에 Kevin Burke [email protected] 은 다음과 같이 썼습니다.

천천히 증가하는 메모리 사용량을 보여주는 코드를 얻을 수있었습니다.
urllib3 / requests를 urllib.request.urlopen으로 대체하여 python3에서.

여기에 수정 된 코드 :
https://gist.github.com/kevinburke/f99053641fab0e2259f0

케빈 버크
전화 : 925.271.7005 | twentymilliseconds.com

2014 년 11 월 3 일 월요일 오후 9:28, Matthew Johnson [email protected]
썼다 :

@ sigmavirus24 https://github.com/sigmavirus24
그래, 마지막 그래픽으로 좀 잃어 버렸어. 아마 내가
코드베이스를 잘 모르거나 디버깅에 능숙하지 않습니다.
메모리 누수.

내가 빨간색 화살표로 가리키는 물체가 무엇인지 아십니까?
이 그래픽 스크린 샷에서?
http://cl.ly/image/3l3g410p3r1C

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kennethreitz/requests/issues/1685#issuecomment -61595362
.

@mhjohnson 은 type 유형의 object 의한 메타 유형 type 에 대한 참조 수인 것 같습니다. 즉, object 또는 type 의 모든 참조라고 생각하지만 확실하지 않습니다. 어느 쪽이든 제외하려고하면 그래프는 2 개의 노드와 같은 모양이됩니다.

또한 프로세스가 보통 며칠 동안 실행되는 웹 크롤링 시스템에서 요청을 사용하기 때문에이 메모리 누수 문제에 대해 매우 염려합니다. 이 문제에 대한 진전이 있습니까?

@mhjohnson 과 함께 이것에 대해 시간을 보낸 후, GC가 PyPy에서 소켓을 처리하는 방식과 관련된 @kevinburke 이론을 확인할 수 있습니다.

3c0b94047c1ccfca4ac4f2fe32afef0ae314094e 커밋은 흥미로운 것입니다. 특히 https://github.com/kennethreitz/requests/blob/master/requests/models.py#L736 라인

콘텐츠를 반환하기 전에 self.raw.release_conn() 를 호출하면 PyPy에서 사용 된 메모리가 크게 줄어들었지만 여전히 개선의 여지가 있습니다.

또한 @ sigmavirus24에서도 언급했듯이 세션 및 응답 클래스와 관련된 .close() 호출을 문서화하면 더 좋을 것이라고 생각합니다. 대부분의 경우 메서드가 암시 적으로 호출되지 않기 때문에 요청 사용자는 이러한 메서드를 알고 있어야합니다.

이 프로젝트의 QA와 관련된 질문과 제안이 있습니다. 테스트의 무결성을 보장하기 위해 CI를 사용하지 않는 이유를 관리자에게 물어봐도 될까요? CI가 있으면 성능 / 메모리 회귀를 프로파일 링하고 추적 할 수있는 벤치 마크 테스트 케이스를 작성할 수도 있습니다.

이러한 접근 방식의 좋은 예는 pq 프로젝트에서 찾을 수 있습니다.
https://github.com/malthe/pq/blob/master/pq/tests.py#L287

이것에 뛰어 들고 도움을 주기로 결정한 모든 사람에게 감사드립니다!
우리는 이것을 일으키는 다른 이론을 계속 조사 할 것입니다.

@stas 한 가지를 다루고 싶습니다.

대부분의 경우 메서드가 암시 적으로 호출되지 않기 때문에 요청 사용자는 이러한 메서드를 알고 있어야합니다.

PyPy를 잠시 놔두고, 이러한 메서드를 명시 적으로 호출 할 필요가 _ 안됩니다 _. CPython에서 소켓 객체에 도달 할 수 없게되면 자동 gc'd를 받게되며, 여기에는 파일 핸들 닫기가 포함됩니다. 이것은 이러한 메서드를 문서화하지 않는다는 주장은 아니지만 지나치게 집중하지 말라는 경고입니다.

우리는 CI를 사용하도록되어 있지만, 현재 상태가 좋지 않은 것 같으며 @kennethreitz 만이 문제를 해결할 수있는 위치에 있습니다. 그는 시간이있을 때 그것을 얻을 것입니다. 그러나 벤치 마크 테스트는 매우 시끄럽지 않은 방식으로 제대로 작동하기가 매우 어렵습니다.

PyPy를 잠시 놔두면 이러한 메서드를 명시 적으로 호출 할 필요가 없습니다. CPython에서 소켓 객체에 도달 할 수 없게되면 자동 gc'd를 받게되며, 여기에는 파일 핸들 닫기가 포함됩니다. 이것은 이러한 메서드를 문서화하지 않는다는 주장은 아니지만 지나치게 집중하지 말라는 경고입니다.

여기서 파이썬에 대해 논의하는 부분을 제외하고는 여러분이 말하는 것에 동의합니다. 나는 논쟁을 시작하고 싶지 않지만 _The Zen of Python_을 읽고, 파이썬적인 방법은 _Explicit가 implicit_ 접근 방식보다 낫습니다. 나는 또한이 프로젝트 철학에 익숙하지 않으므로 requests 적용되지 않으면 내 생각을 무시하십시오.

기회가있을 때마다 CI 또는 벤치 마크 테스트를 도와 드리겠습니다! 현재 상황을 설명해 주셔서 감사합니다.

그래서 기능 API를 사용할 때 문제의 원인을 찾은 것 같습니다. 만약 당신이

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 에 연결 풀을 가리키는 속성을 포함합니다. 연결 풀에는 닫히지 않은 소켓이있는 큐에 Connection이 있습니다. 기능적 API의 문제는 requests/api.py 같이하면 해결됩니다.

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

그러면 r.raw._pool 은 (는) 여전히 연결 풀이지만 r.raw._pool.pool 은 (는) None 입니다.

까다로운 부분은 사람들이 세션을 사용할 때 일어나는 일이됩니다. 모든 요청 후에 세션을 close 갖는 것은 말도 안되며 세션의 목적에 위배됩니다. 실제로 세션 (스레드 없음)을 사용하고 세션을 사용하여 동일한 도메인 (및 동일한 스키마 (예 : https ))에 100 개의 요청을 수행하면 메모리 누수가 확인하기가 훨씬 더 어렵습니다. 새 소켓이 생성 될 때까지 약 30 초 동안 기다리십시오. 문제는 우리가 이미 보았 듯이 r.raw._pool 는 매우 가변적 인 객체라는 것입니다. 요청에서 풀 관리자가 관리하는 연결 풀에 대한 참조입니다. 따라서 소켓이 교체되면 여전히 도달 할 수있는 (범위 내) 모든 응답의 참조로 교체됩니다. 더 많은 작업을 수행해야하는 것은 연결 풀을 닫은 후에도 소켓에 대한 참조가 여전히 유지되는지 확인하는 것입니다. 참조를 붙잡고있는 것을 찾을 수 있다면 _real_ 메모리 누수를 발견 할 것이라고 생각합니다.

그래서 내가 가진 것을 하나 개의 아이디어는 실제로 참조 알아낼 objgraph 사용하는 것이 었습니다 SSLSocket 를 호출 한 후 requests.get 나는이있어 :

흥미로운 점은 SSLSocket 대한 참조가 7 개가 분명하지만 objgraph가 찾을 수있는 역 참조는 2 개뿐이라는 것입니다. 참조 중 하나는 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() 명시 적으로 호출해야합니다!

TL; DR; 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.'

처음에 우리 모두가 혼란스러워하는 이유 중 하나는 벤치 마크를 실행하려면 GC가 한 구현에서 다른 구현으로 작동하는 방식을 제외하기 위해 더 큰 세트가 필요하기 때문이라고 생각합니다.

또한 스레드 환경에서 요청을 실행하려면 스레드가 작동하는 방식으로 인해 더 많은 호출 세트가 필요합니다 (여러 스레드 풀을 실행 한 후 메모리 사용량에 큰 변화가 없음).

JIT를 사용하는 PyPy와 관련하여 동일한 수의 호출에 대해 gc.collect() 를 호출하면 메모리가 ~ 30 % 절약됩니다. 이것이 모든 사람들이 VM을 조정하고 JIT에 대한 코드를 최적화하는 방법의 주제이기 때문에 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 개의 컴파일 된 경로는 사용중인 200MB 이상의 RAM을 설명하지 않습니다.

실행할 프로그램에 무언가를 넣을 수 있습니까?
gc.dump_rpy_heap('filename.txt') 매우 높은 메모리에있을 때
용법? (한 번만 실행하면됩니다. 이렇게하면 모든
GC가 알고있는 메모리).

그런 다음 PyPy 소스 트리를 확인하고 ./pypy/tool/gcdump.py filename.txt 실행하고 결과를 보여줍니다.

감사!

2014 년 11 월 8 일 토요일 오후 3:20:52 Stas Sușcov [email protected]
썼다 :

도움이 되었기를 바랍니다:

라인 번호 메모리 사용량 증가 라인 콘텐츠

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.'

[2cbb7c1bbbb8] {jit-summary
추적 : 41 0.290082
백엔드 : 30 0.029096
합계 : 1612.933400
작전 : 79116
기록 된 작전 : 23091
전화 : 2567
경비원 : 7081
선택 작업 : 5530
옵트 가드 : 1400
강제력 : 198
중단 : 추적이 너무 김 : 2
중단 : 컴파일 : 0
abort : vable escape : 9
abort : 잘못된 루프 : 0
abort : 강제 유사 불변 : 0
nvirtuals : 9318
nvholes : 1113
nvreused : 6666
총 루프 수 : 23
총 교량 수 : 8
해제 된 루프 수 : 0
해제 된 브리지 수 : 0
[2cbb7c242e8b] jit-summary}

나는 최신 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를 차지합니다. 두 곳이 휴식
그 중 "예비 메모리"에서 GC는 다양한 작업을 수행 할 수 있습니다.
비 GC 할당에서-이는 OpenSSL의 내부
할당. OpenSSL 구조인지 확인하는 좋은 방법이 있는지 궁금합니다.
유출되고 있습니다. 여기서 TLS로 테스트중인 것이 있습니까? 그렇다면
TLS가 아닌 사이트로 시도해보고 재현되는지 확인하십시오.

2014 년 11 월 8 일 토요일 오후 5:38:04 Stas Sușcov [email protected]
썼다 :

로그:

라인 번호 메모리 사용량 증가 라인 콘텐츠

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] {jit-summary
추적 : 41 0.293192
백엔드 : 30 0.026873
합계 : 1615.665337
작전 : 79116
기록 된 작전 : 23091
전화 : 2567
경비원 : 7081
선택 작업 : 5530
옵트 가드 : 1400
강제력 : 198
중단 : 추적이 너무 김 : 2
중단 : 컴파일 : 0
abort : vable escape : 9
abort : 잘못된 루프 : 0
abort : 강제 유사 불변 : 0
nvirtuals : 9318
nvholes : 1113
nvreused : 6637
총 루프 수 : 23
총 교량 수 : 8
해제 된 루프 수 : 0
해제 된 브리지 수 : 0
[3fd756c29302] jit-summary}

여기 덤프 : https://gist.github.com/stas/ad597c87ccc4b563211a

시간을내어 도와 주셔서 감사합니다!

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kennethreitz/requests/issues/1685#issuecomment -62277822
.

@alex ,

@stas 가이 벤치 마크를 위해 일반 http (비 SSL / TLS) 연결을 사용했다고 생각합니다. 혹시라도 @stas 의 벤치 마크 스크립트를 사용하고 일반 http 연결을 사용하여 Mac (OSX 10.9.5 2.5GHz i5 8GB 1600MHz DDR3)에서 미리 작성했습니다.

도움이된다면 다음과 같은 결과를 비교할 수 있습니다 (귀하의 지침 사용).
https://gist.github.com/mhjohnson/a13f6403c8c3a3d49b8d

당신이 무슨 생각을하는지 제게 알려주세요.

감사,

-매트

GitHub의 정규식이 너무 느슨합니다. 나는 그것이 완전히 수정되었다고 생각하지 않기 때문에 이것을 다시 여는 것입니다.

안녕하세요, 문제가 있음을 지적하는 데 도움이 될 수 있습니다. 요청을 사용하는 크롤러가 있고 다중 처리를 사용하는 프로세스가 있습니다. 둘 이상의 인스턴스가 동일한 결과를 받고 있습니다. 결과 버퍼 또는 소켓 자체에 누수가있을 수 있습니다.

코드 샘플을 보낼 수 있는지 또는 정보의 어느 부분이 "공유"(유출)되는지 식별하기 위해 참조 트리를 생성하는 방법을 알려주십시오.

감사

@barroca 는 다른 문제입니다. 스레드간에 세션을 사용하고 stream=True 사용하고있을 가능성이 높습니다. 읽기를 마치기 전에 응답을 닫는 경우 소켓은 해당 데이터가 여전히있는 연결 풀에 다시 배치됩니다 (올바르게 기억하는 경우). 그렇지 않은 경우 가장 최근의 연결을 선택하고 서버에서 캐시 된 응답을 수신하는 것도 그럴듯합니다. 어느 쪽이든 이것은 메모리 누수를 나타내는 것이 아닙니다.

@ sigmavirus24 감사합니다 Ian, 말씀하신대로 스레드 전체에서 세션을

@barroca 걱정

이 문제에 대해 더 이상 불만이 없었으며 이에 대해 최선을 다했다고 생각합니다. 나는 그것을 다시 열고 필요한 경우 다시 조사하게되어 기쁩니다

그렇다면이 문제의 해결책은 무엇입니까?

@Makecodeeasy 나도 알고 싶어

지금까지 requests 내 문제는 스레드로부터 안전하지 않다는 것입니다.
다른 스레드에 대해 별도의 세션을 사용하는 것이 가장 좋습니다.

캐시 응답을 확인하기 위해 수백만 개의 URL을 걸어가는 작업이 여기로 연결됩니다.

requests 가 ThreadPoolExecutor 또는 threading 과 상호 작용할 때 메모리 사용량이 합리적 이상으로 증가한다는 것을 알게되면서,
결국 저는 multiprocessing.Process 를 사용하여 작업자를 격리하고 각 작업자에 대해 독립적 인 세션을 갖습니다.

@AndCycle 그러면 문제가 여기에 없습니다. 이 특정 메모리 누수 사례를 수정하기 위해 병합 된 PR이 있습니다. 주위에 테스트가 있기 때문에 회귀하지 않았습니다. 그리고 귀하의 문제는 완전히 다른 것 같습니다.