스레드 과다와 컨텍스트 스위칭 Thread oversubscription, context switching

원인 ID so-context · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

코어보다 훨씬 많은 스레드를 돌리면 OS가 번갈아 실행시키는 데만 CPU를 씁니다.

왜 연결마다 스레드를 만드는 등 스레드가 수백~수천 개 → 그러면 컨텍스트 스위칭(실행 스레드 교체) 비용과 캐시 미스 증가 → 화면에서는 CPU는 바쁜데 처리량은 낮고 틱이 들쭉날쭉해 뚝뚝 끊김·슬로우모션

증상: 뚝뚝 끊김, 슬로우모션
요인: 정체, 지터
누가 겪나: 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 코어 수에 맞춘 스레드, 비동기 I/O(epoll·IOCP).
인프라팀 할 일: 컨텍스트 스위칭 횟수와 실행 대기 스레드 수(vmstat의 cs·r) 모니터링.
수치 감각: 컨텍스트 스위칭 한 번에 수 µs, 그 뒤 캐시 미스 비용까지 합치면 더 큽니다.
그래프에서는: 인원·부하를 따라 오름 · 초당 컨텍스트 스위칭 수, 실행 대기 스레드 수
확인할 곳: vmstat 1의 cs(초당 컨텍스트 스위칭)·r(실행 중이거나 CPU를 기다리는 수)을 코어 수와 비교하고, pidstat -w -t로 게임 서버 스레드별 자발적(cswch/s)·비자발적(nvcswch/s) 컨텍스트 스위칭을 봄
이러면 맞음: 동접이 늘 때 r이 코어 수보다 훨씬 크게 오르고 cs도 따라 치솟으며 비자발적 컨텍스트 스위칭이 많은 스레드가 수백 개
이러면 아님: r이 코어 수 이하로 머물면 이 원인이 아님. 자발적 스위칭만 많으면 스레드가 락·I/O를 기다리는 것(“락 경합”, “블로킹 I/O 구조”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처

Quantifying The Cost of Context Switch (ExpCS 2007) ACM
컨텍스트 스위칭 직접 비용 약 3.8µs, 캐시 영향까지 합친 간접 비용은 수 µs~1,000µs 이상(측정 환경 기준)
vmstat(8) — Linux manual page procps-ng
cs(초당 컨텍스트 스위칭 수)와 r(실행 중이거나 실행을 기다리는 프로세스 수) 항목
I/O Completion Ports Microsoft
미리 만든 스레드 풀과 IOCP로 많은 비동기 I/O를 처리하고 동시에 도는 스레드 수를 CPU 동시성에 맞춤
pidstat(1) — Linux manual page sysstat
-w의 cswch/s는 자원을 기다리며 스스로 멈춘 자발적 컨텍스트 스위칭, nvcswch/s는 타임 슬라이스를 다 써서 강제로 바뀐 비자발적 컨텍스트 스위칭, -t로 스레드별