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