Microsoft MVP성태의 닷넷 이야기
스크립트: 53. 파이썬 - localhost 호출 시의 hang 현상 [링크 복사], [링크+제목 복사]
조회: 2745
글쓴 사람
정성태 (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)
13494정성태12/20/20231653Linux: 64. Linux 응용 프로그램의 (C++) so 의존성 줄이기(ReleaseMinDependency) - 두 번째 이야기
13493정성태12/19/20231738닷넷: 2185. C# - object를 QueryString으로 직렬화하는 방법
13492정성태12/19/20231509개발 환경 구성: 699. WSL에 nopCommerce 예제 구성
13491정성태12/19/20231389Linux: 63. 리눅스 - 다중 그룹 또는 사용자를 리소스에 권한 부여
13490정성태12/19/20231432개발 환경 구성: 698. Golang - GLIBC 의존을 없애는 정적 빌드 방법
13489정성태12/19/20231207개발 환경 구성: 697. GoLand에서 ldflags 지정 방법
13488정성태12/18/20231202오류 유형: 884. HTTP 500.0 - 명령행에서 실행한 ASP.NET Core 응용 프로그램을 실행하는 방법
13487정성태12/16/20231424개발 환경 구성: 696. C# - 리눅스용 AOT 빌드를 docker에서 수행 [1]
13486정성태12/15/20231235개발 환경 구성: 695. Nuget config 파일에 값 설정/삭제 방법
13485정성태12/15/20231236오류 유형: 883. dotnet build/restore - error : Root element is missing
13484정성태12/14/20231368개발 환경 구성: 694. Windows 디렉터리 경로를 WSL의 /mnt 포맷으로 구하는 방법
13483정성태12/14/20231525닷넷: 2184. C# - 하나의 resource 파일을 여러 프로그램에서 (AOT 시에도) 사용하는 방법파일 다운로드1
13482정성태12/13/20231861닷넷: 2183. C# - eFriend Expert OCX 예제를 .NET Core/5+ Console App에서 사용하는 방법 [2]파일 다운로드1
13481정성태12/13/20231568개발 환경 구성: 693. msbuild - .NET Core/5+ 프로젝트에서 resgen을 이용한 리소스 파일 생성 방법파일 다운로드1
13480정성태12/12/20231615개발 환경 구성: 692. Windows WSL 2 + Chrome 웹 브라우저 설치
13479정성태12/11/20231593개발 환경 구성: 691. WSL 2 (Ubuntu) + nginx 환경 설정
13477정성태12/8/20231766닷넷: 2182. C# - .NET 7부터 추가된 Int128, UInt128 [1]파일 다운로드1
13476정성태12/8/20231573닷넷: 2181. C# - .NET 8 JsonStringEnumConverter의 AOT를 위한 개선파일 다운로드1
13475정성태12/7/20231595닷넷: 2180. .NET 8 - 함수 포인터에 대한 Reflection 정보 조회파일 다운로드1
13474정성태12/6/20231511개발 환경 구성: 690. 닷넷 코어/5+ 버전의 ilasm/ildasm 실행 파일 구하는 방법 - 두 번째 이야기
13473정성태12/5/20231629닷넷: 2179. C# - 값 형식(Blittable)을 메모리 복사를 이용해 바이트 배열로 직렬화/역직렬화파일 다운로드1
13472정성태12/4/20231495C/C++: 164. Visual C++ - InterlockedCompareExchange128 사용 방법
13471정성태12/4/20231543Copilot - To enable GitHub Copilot, authorize this extension using GitHub's device flow
13470정성태12/2/20231771닷넷: 2178. C# - .NET 8부터 COM Interop에 대한 자동 소스 코드 생성 도입파일 다운로드1
13469정성태12/1/20231590닷넷: 2177. C# - (Interop DLL 없이) CoClass를 이용한 COM 개체 생성 방법파일 다운로드1
13468정성태12/1/20231540닷넷: 2176. C# - .NET Core/5+부터 달라진 RCW(Runtime Callable Wrapper) 대응 방식파일 다운로드1
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...