Microsoft MVP성태의 닷넷 이야기
스크립트: 43. uwsgi의 --processes와 --threads 옵션 [링크 복사], [링크+제목 복사]
조회: 4707
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

uwsgi의 --processes와 --threads 옵션

지난 글에서,

파이썬 - uwsgi의 --enable-threads 옵션
; https://www.sysnet.pe.kr/2/0/12886

uwsgi의 prefork/worker 방식에 대해 언급했하면서 테스트를 했는데, 뭘 좀 몰랐던 시기라 테스트가 제대로 안 되었습니다. ^^; 그래서 이참에 다시 정리해 봅니다.




uwsgi 테스트를 위해 최소 구현 코드만을 만족하는 다음의 파이썬 코드로,

import os
import time
from datetime import datetime

HELLO_WORLD = b"Hello world!\n"


def simple_app(environ, start_response):
    status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    print(os.getpid(), os.getppid(), environ['REQUEST_URI'], "called", datetime.now().strftime("%H:%M:%S"))
    time.sleep(10)
    start_response(status, response_headers)
    return [HELLO_WORLD]


application = simple_app

uwsgi를 기본 옵션만을 사용해 호스팅해보겠습니다.

$ uwsgi --http :18000  --wsgi-file ./main.py

이 상태에서 웹 브라우저를 통해 (식별을 위해 sleep1, sleep2를 경로에 추가해) 2번 동시에 방문해 보면 화면에 다음과 같은 출력을 볼 수 있습니다.

// 2개의 동시 요청, http://localhost:18000/sleep1, http://localhost:18000/sleep2

22053 19712 /sleep1 called 11:38:46
22053 19712 /sleep2 called 11:38:56

즉, 2개의 요청이 직렬화돼 하나의 프로세스(22053)에서 차례대로 실행되었습니다. 이때의 uwsgi 프로세스 구조를 보면,

├─init(19710)───init(19711)───bash(19712)───uwsgi(22053)

단일하게 실행 중인 1개의 uwsgi를 볼 수 있습니다. 그러니까, uwsgi 프로세스 한 개당 1개의 동시 요청만 처리하고 있는 것입니다. 이러한 동시성을 개선하기 위해 줄 수 있는 옵션이 prefork/worker 프로세스 방식일 텐데요, 재미있게도 uwsgi의 경우 이 옵션이 각각 --processes, --workers로 나뉘어 있지만 정작 약식 옵션으로는 "-p"로 통일이 되므로,

    -p|--processes                          spawn the specified number of workers/processes
    -p|--workers                            spawn the specified number of workers/processes

사실상 2개의 옵션은 완전히 같은 역할을 합니다. 또한, 기본값은 모두 1인데요, 즉 기본적으로 떠 있는 uwsgi 프로세스가 하나의 worker/process에 해당합니다. 따라서 다음과 같이 workers/processes를 3으로 주면,

$ uwsgi --http-socket :18000 --wsgi-file ./main.py --workers 3
...[생략]...
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (pid: 22079, cores: 1)
spawned uWSGI worker 2 (pid: 22080, cores: 1)
spawned uWSGI worker 3 (pid: 22081, cores: 1)

$ uwsgi --http-socket :18000 --wsgi-file ./main.py --processes 3
...[생략]...
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (pid: 22081, cores: 1)
spawned uWSGI worker 2 (pid: 22082, cores: 1)
spawned uWSGI worker 3 (pid: 22083, cores: 1)

예상할 수 있듯이 프로세스의 구조도 같습니다.

// worker/processes 총 3개: 22081, 22082, 22083

 ├─init(19710)───init(19711)───bash(19712)───uwsgi(22081)─┬─uwsgi(22082)
 │                                                        └─uwsgi(22083)

더욱 재미있는 건, uwsgi에도 --threads 옵션이 있다는 점입니다. 실제로 다음과 같은 식으로 실행해 보면,

$ uwsgi --http :18000  --wsgi-file ./main.py --processes 3 --threads 4

이때의 프로세스 결과는 이렇게 나옵니다.

// processes 3개 == 22111, 22112, 22113

// 프로세스 당 threads 4개
// 22111(프로세스이면서 스레드), 22116, 22119, 22122
// 22112(프로세스이면서 스레드), 22114, 22117, 22121
// 22113(프로세스이면서 스레드), 22115, 22118, 22120

├─init(19710)───init(19711)───bash(19712)───uwsgi(22111)─┬─uwsgi(22112)─┬─{uwsgi}(22114)
│                                                        │              ├─{uwsgi}(22117)
│                                                        │              └─{uwsgi}(22121)
│                                                        ├─uwsgi(22113)─┬─{uwsgi}(22115)
│                                                        │              ├─{uwsgi}(22118)
│                                                        │              └─{uwsgi}(22120)
│                                                        ├─{uwsgi}(22116)
│                                                        ├─{uwsgi}(22119)
│                                                        └─{uwsgi}(22122)

출력 결과를 보면, "uwsgi"라고 나오는 것과 "{uwsgi}"라고 나오는 것이 있습니다. 중괄호가 없는 것이 프로세스이고, 있는 것이 스레드입니다.

당연히, 이런 경우 동시 처리가 됩니다. 위의 예제 코드에 대한 요청을 다시 재현해 보면,

$ uwsgi --http-socket :18000 --wsgi-file ./main.py --processes 3

// 2개 동시 요청: http://localhost:18000/sleep1, http://localhost:18000/sleep2

22126 22124 /sleep1 called 13:51:20
22125 22124 /sleep2 called 13:51:21
22124 19712 /favicon.ico called 13:51:30
22126 22124 /favicon.ico called 13:51:41

// 프로세스 구조
├─init(19710)───init(19711)───bash(19712)───uwsgi(22124)─┬─uwsgi(22125)
│                                                        └─uwsgi(22126)

/sleep1과 /sleep2가 함께 처리되고 있는 것을 볼 수 있고, (웹 브라우저로 인해 부가적으로 발생한) favicon.ico 요청까지 처리하는 프로세스 ID까지 고려하면 3개의 uwsgi 프로세스가 요청을 협업해서 처리하고 있습니다.

--processes와 --threads의 또 다른 차이점은, --enable-threads의 활성 유무입니다. 단순히 --processes로만 fork를 한 경우에는 해당 옵션이 활성화되지 않습니다. 따라서 사용자 스레드의 활동이 필요하다면 --processes와 함께 --enable-threads도 명시해야 합니다.




아마도, uwsgi의 prefork와 worker가 사실상 fork 방식으로만 처리하는 데에는 GIL의 영향으로 인해 프로세스를 나누는 것이 최선의 방식이라고 생각했던 것 같습니다.

참고로, uwsgi로 호스팅하면 app framework에 따라 초기 프로세스의 상태가 다릅니다.

// 이 글의 예제를 호스팅한 경우
├─init(19710)───init(19711)───bash(19712)───uwsgi(22053)

// Django를 호스팅한 경우
├─init(19710)───init(19711)───bash(19712)───uwsgi(22067)───uwsgi(22068)

아마도 Django 내부에서 fork를 하는 프로세스가 하나 있는 듯한데 저 프로세스가 요청을 처리하는 uwsgi 프로세스 역할은 하지 않습니다. 또한, 이 상태에서 --py-autoreload=3 옵션을 넣으면 다시 이렇게 바뀝니다.

// 이 글의 예제를 호스팅한 경우
├─init(19710)───init(19711)───bash(19712)───uwsgi(22061)───uwsgi(22062)───{uwsgi}(22063) // --py-autoreload 옵션으로 자식 프로세스 1개와 그것에서 다시 스레드 1개

// Django를 호스팅한 경우
├─init(19710)───init(19711)───bash(19712)───uwsgi(22070)─┬─uwsgi(22071)───{uwsgi}(22072) // --py-autoreload 옵션으로 자식 프로세스 1개와 그것에서 다시 스레드 1개
│                                                        └─uwsgi(22073) // Django로 인한 1개의 자식 프로세스




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/9/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)
13553정성태2/14/20241736닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241696닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242018닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242108Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242480개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242309개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242058개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241898Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241830닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241846오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241828Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241876오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241922VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242051Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242146개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242215닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242269닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20242375닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20242208닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
13534정성태1/21/20242043닷넷: 2207. C# - SQL Server DB를 bacpac으로 Export/Import파일 다운로드1
13533정성태1/18/20242246닷넷: 2206. C# - TCP KeepAlive의 서버 측 구현파일 다운로드1
13532정성태1/17/20242150닷넷: 2205. C# - SuperSimpleTcp 사용 시 주의할 점파일 다운로드1
13531정성태1/16/20242031닷넷: 2204. C# - TCP KeepAlive에 새로 추가된 Retry 옵션파일 다운로드1
13530정성태1/15/20242012닷넷: 2203. C# - Python과의 AES 암호화 연동파일 다운로드1
13529정성태1/15/20241895닷넷: 2202. C# - PublishAot의 glibc에 대한 정적 링킹하는 방법
13528정성태1/14/20242033Linux: 68. busybox 컨테이너에서 실행 가능한 C++, Go 프로그램 빌드
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...