Microsoft MVP성태의 닷넷 이야기
스크립트: 53. 파이썬 - localhost 호출 시의 hang 현상 [링크 복사], [링크+제목 복사]
조회: 3369
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

파이썬 - localhost 호출 시의 hang 현상

localhost로의 호출, 즉 웹 사이트가 다시 자신의 사이트로 요청을 보내는 것은 간혹 여러 가지 문제를 발생시킵니다. 간단하게 재현을 해볼까요? ^^

django로 만든 웹 사이트에서 다음과 같은 코드를 만들어 두고,

# 18091 포트로 서비스하는 걸로 가정

def urlreqtest(request):
    import requests

    requests.get("http://192.168.100.50/")
    requests.get("http://localhost:18091/")

    return render(request, 'my/urlreqtest.html', None)

uwsgi로 이렇게만 호스팅하면,

$ uwsgi3 --http-socket :18091 --wsgi-file ./my/wsgi.py

urlreqtest 호출 시 첫 번째 requests.get 호출은 문제가 없지만, 두 번째 requests.get 호출에서는 블록킹, 무한 대기 현상이 나타나는 것을 볼 수 있습니다.

이때의 호출 스택을 뜨면 대충 다음과 같은 형태로 나오는데,

File "/home/testusr/.local/lib/python3.8/site-packages/django/core/handlers/wsgi.py", line 133, in __call__
    response = self.get_response(request)
  ...[생략]...
    response = get_response(request)
  File "/home/testusr/.local/lib/python3.8/site-packages/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/mnt/d/workshop2/python-agent/testprj/myapp/./bbs/views.py", line 820, in urlreqtest
    t = requests.get(external_url)
  File "/usr/lib/python3/dist-packages/requests/api.py", line 75, in get
    return request('get', url, params=params, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/api.py", line 60, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 535, in request
    resp = self.send(prep, **send_kwargs)
  File "/mnt/d/workshop2/python-agent/jennifer/hooks/external_requests.py", line 63, in handler
    ret = origin(self, request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 648, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 665, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 416, in _make_request
    httplib_response = conn.getresponse()
  File "/usr/lib/python3.8/http/client.py", line 1348, in getresponse
    response.begin()
  File "/usr/lib/python3.8/http/client.py", line 316, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.8/http/client.py", line 277, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib/python3.8/socket.py", line 669, in readinto
    return self._sock.recv_into(b)

결국 socket.py에서 localhost로 connect는 되었으나 recv 단계에서 hang 상태로 빠진 것입니다.

원인은 간단합니다. 위에서 실행한 uwsgi의 옵션에서는 기본 worker process가 1개라서 요청을 동시에 하나만 처리할 수 있는 것입니다. 그런데, 그 worker process가 현재의 요청을 처리하느라 점유된 상태에서 또 다른 요청, 그것이 설령 localhost에서 온 것이라 하더라도 더 이상 처리를 못 하는 현상이 발생하는 것입니다.

바로 이런 상황을 해결할 수 있는, 동시 요청을 처리하기 위한 옵션이 --processes 또는 --threads입니다. 따라서 아래의 명령어로 실행하면,

// 스레드를 늘리거나,
$ uwsgi3 --http-socket :18091 --wsgi-file ./my/wsgi.py --threads 2

// 프로세스를 늘리거나,
$ uwsgi3 --http-socket :18091 --wsgi-file ./my/wsgi.py --processes 2

이제는 2번째의 requests.get까지 잘 처리돼 운영이 됩니다.




그렇다면 과연 어느 정도의 threads, processes 옵션 값을 지정해야 하는 걸까요? 위에서처럼 2로 지정했다면, 현재 urlreqtest로 2개의 동시 요청이 온 상태에서 2개 모두 아직 2번째 requests.get("http://localhost:18091/") 코드를 실행하기 전이라면 역시나 마찬가지로 hang 현상에 빠지게 됩니다.

당연히 좀 더 수를 늘려야겠지요?

우선 threads의 경우에는 아쉽게도 GIL의 영향으로 인해 전체적인 성능 하락의 원인이 될 수 있습니다.

반면 processes를 늘리면, 그나마 GIL의 영향을 덜 받겠지만 어쨌든 TCB보다는 PCB 차원에서의 오버헤드와, 같은 프로세스의 주소 공간이 아님으로 인해 발생하는 오버헤드를 따져보면 무작정 많이 늘릴 수도 없습니다.

가령, 윈도우 같은 경우 닷넷 프로세스의 기본 스레드 풀이 늘릴 수 있는 최대 스레드 수는 (닷넷 7 Console의 경우) 32,766개로 설정돼 있습니다. 이것을 파이썬 환경과 비교해, --threads 옵션의 값을 32,766으로 설정하거나 --processes를 32,766으로 설정하는 것과 같다고 볼 수 있는데요, 그 2개의 옵션 모두 uwsgi에는 기본 적용이 애매합니다.




기왕 알아본 김에, 현실적인 수준으로 uwsgi의 옵션을 살펴보겠습니다. ^^

우선 간단하게 어떤 제약이 있는지 알아보기 위해, 수를 좀 줄여서 "--processes 10000"으로 적용해도 제가 가진 WSL 시스템에서 아래와 같은 오류와 함께 서비스가 안 됩니다.

mapped 729112904 bytes (712024 KB) for 10000 cores
socketpair()
: Too many open files [core/signal.c line 243]

마찬가지로 "--threads 10000"으로 해도 화면에 이런 오류가 발생하면서 정상적인 서비스가 안 됩니다.

epoll_create(): Too many open files [core/event.c line 507]
epoll_ctl(): Bad file descriptor [core/event.c line 524]
epoll_ctl(): Bad file descriptor [core/event.c line 524]
epoll_ctl(): Bad file descriptor [core/event.c line 524]

위의 제약을 벗어나려면 file descriptor에 대한 max 설정을 변경해야 합니다.

// Ubuntu 20.04 + WSL 환경

$ cat /proc/sys/fs/file-max
6546427

$ ulimit -n
1024

위의 경우 1024 제약에 걸리는데요, 따라서 다음과 같이 실행해야 합니다.

// Ubuntu 20.04 + WSL 환경

$ ulimit -n 10000

$ uwsgi3 --threads 9500 --http-socket :18091 --wsgi-file ./my/wsgi.py

최댓값 10,000개로, uwsgi에서는 (안전하게) 9500개의 스레드를 생성하게 됩니다. 그런데, 이렇게 해도 닷넷이나 JVM의 스레드 풀과 비교해 불합리한 부분이 있습니다. 왜냐하면 uwsgi의 경우에는 아예 처음부터 시작 시점에 9500개의 스레드를 생성해 놓기 때문입니다.

또한, 위에서는 "--threads"로 했지만 "--processes"로 바꾸면 여전히 "Too many open files" 오류가 발생합니다.

// Ubuntu 20.04 + WSL 환경

$ ulimit -n 10000

$ uwsgi3 --processes 9500 --http-socket :18091 --wsgi-file ./my/wsgi.py
...[생략]...
Python main interpreter initialized at 0x55def52bfb80
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 692660904 bytes (676426 KB) for 9500 cores
socketpair()
: Too many open files [core/signal.c line 243]

왜냐하면 "--threads" 옵션의 경우 같은 프로세스 내에서 스레드 생성 후 (내부적으로는 파일 자원에 속하는) 소켓만 생성하는 것이기 때문에 9500개가 가능했지만, "--processes"의 경우에는 프로세스 공간이 분리되면서 더 많은 파일들이 프로세스마다 열리는 것으로 인해 문제가 발생합니다.

게다가, 설령 "--processes 1000"으로 낮춰서 실행해도 (스레드와 마찬가지로) 시작 시점에 1,000개의 프로세스를 한꺼번에 실행시켜 두기 때문에 이것 역시 불합리한 면이 있습니다. (게다가 1,000개의 프로세스를 띄우느라 시작이 느리고, 종료도 그것을 차례로 삭제하느라 느려 '재시작' 과정이 불편해집니다.)

바로 이럴 때 (닷넷이나 JVM의 스레드 풀처럼) 동적으로 worker 스레드/프로세스를 관리할 수 있는 "--cheaper" 옵션을 쓰게 됩니다. 따라서 이렇게 해주면,

$ uwsgi3 --cheaper 4 --processes 9500 --http-socket :18091 --wsgi-file ./my/wsgi.py

최대 프로세스는 9,500개까지 늘어날 수 있지만 최초에는 4개의 worker 프로세스만 생성해 동적 관리를 하게 됩니다. 관련해서 다음의 옵션들이 있으니 참고하시고,

--cheaper                               set cheaper mode (adaptive process spawning)
--cheaper-initial                       set the initial number of processes to spawn in cheaper mode
--cheaper-algo                          choose to algorithm used for adaptive process spawning
--cheaper-step                          number of additional processes to spawn at each overload
--cheaper-overload                      increase workers after specified overload
--cheaper-algo-list                     list enabled cheapers algorithms
--cheaper-algos-list                    list enabled cheapers algorithms
--cheaper-list                          list enabled cheapers algorithms

하지만 동적 관리가 된다고 해도 프로세스가 9,500개까지 늘어날 정도로 설정해 두는 것은 별로 바람직한 것 같지는 않습니다. 글쎄요, 제가 전문적인 파이썬 프로그래머가 아니라서 잘 모르겠는데, 보통 어느 정도의 값을 설정하는지 저도 궁금하군요. ^^




참고로, 위의 내용을 잘 이해하셨다면, 이런 localhost로의 호출에 대한 hang 문제가 꼭 파이썬에서만 발생하는 것은 아님을 알 수 있을 것입니다. ^^ 실제로 전에 닷넷 사이트에서 발생한 사례를 설명한 적이 있습니다.

제니퍼 닷넷 적용 사례 (2) - 웹 애플리케이션 hang의 원인을 알려주다.
; https://www.sysnet.pe.kr/2/0/1117




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/12/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  6  7  [8]  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13426정성태10/13/20233294스크립트: 59. 파이썬 - 비동기 호출 함수(run_until_complete, run_in_executor, create_task, run_in_threadpool)
13425정성태10/11/20233105닷넷: 2149. C# - PLinq의 Partitioner<T>를 이용한 사용자 정의 분할파일 다운로드1
13423정성태10/6/20233085스크립트: 58. 파이썬 - async/await 기본 사용법
13422정성태10/5/20233226닷넷: 2148. C# - async 유무에 따른 awaitable 메서드의 병렬 및 예외 처리
13421정성태10/4/20233260닷넷: 2147. C# - 비동기 메서드의 async 예약어 유무에 따른 차이
13420정성태9/26/20235371스크립트: 57. 파이썬 - UnboundLocalError: cannot access local variable '...' where it is not associated with a value
13419정성태9/25/20233111스크립트: 56. 파이썬 - RuntimeError: dictionary changed size during iteration
13418정성태9/25/20233792닷넷: 2146. C# - ConcurrentDictionary 자료 구조의 동기화 방식
13417정성태9/19/20233360닷넷: 2145. C# - 제네릭의 형식 매개변수에 속한 (매개변수를 가진) 생성자를 호출하는 방법
13416정성태9/19/20233161오류 유형: 877. redis-py - MISCONF Redis is configured to save RDB snapshots, ...
13415정성태9/18/20233643닷넷: 2144. C# 12 - 컬렉션 식(Collection Expressions)
13414정성태9/16/20233412디버깅 기술: 193. Windbg - ThreadStatic 필드 값을 조사하는 방법
13413정성태9/14/20233606닷넷: 2143. C# - 시스템 Time Zone 변경 시 이벤트 알림을 받는 방법
13412정성태9/14/20236879닷넷: 2142. C# 12 - 인라인 배열(Inline Arrays) [1]
13411정성태9/12/20233391Windows: 252. 권한 상승 전/후 따로 관리되는 공유 네트워크 드라이브 정보
13410정성태9/11/20234898닷넷: 2141. C# 12 - Interceptor (컴파일 시에 메서드 호출 재작성) [1]
13409정성태9/8/20233758닷넷: 2140. C# - Win32 API를 이용한 모니터 전원 끄기
13408정성태9/5/20233739Windows: 251. 임의로 만든 EXE 파일을 포함한 ZIP 파일의 압축을 해제할 때 Windows Defender에 의해 삭제되는 경우
13407정성태9/4/20233499닷넷: 2139. C# - ParallelEnumerable을 이용한 IEnumerable에 대한 병렬 처리
13406정성태9/4/20233453VS.NET IDE: 186. Visual Studio Community 버전의 라이선스
13405정성태9/3/20233872닷넷: 2138. C# - async 메서드 호출 원칙
13404정성태8/29/20233399오류 유형: 876. Windows - 키보드의 등호(=, Equals sign) 키가 눌리지 않는 경우
13403정성태8/21/20233235오류 유형: 875. The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB3E94ADBE1229CF
13402정성태8/20/20233301닷넷: 2137. ILSpy의 nuget 라이브러리 버전 - ICSharpCode.Decompiler
13401정성태8/19/20233540닷넷: 2136. .NET 5+ 환경에서 P/Invoke의 성능을 높이기 위한 SuppressGCTransition 특성 [1]
13400정성태8/10/20233380오류 유형: 874. 파이썬 - pymssql을 윈도우 환경에서 설치 불가
1  2  3  4  5  6  7  [8]  9  10  11  12  13  14  15  ...