게임 렉 백서 › L7 서버 OS (커널)
컨테이너 CPU 스로틀링 (CFS 쿼터) Container CPU throttling (CFS quota)
원인 ID so-cpu-quota · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
그림과 실험이 있는 원본 카드로 열기 →
컨테이너에 CPU 한도를 걸면, 정해진 주기(보통 100ms) 안에 할당량을 다 쓴 순간 남은 시간 동안 강제로 멈춥니다(스로틀링).
왜 쿠버네티스 등에서 게임 서버 컨테이너에 CPU 한도(limit)를 걸어 둠 → 그러면 틱 계산이 몰린 순간 할당량을 다 써서 다음 주기까지 수십 ms 정지 → 화면에서는 평균 CPU는 낮은데 틱이 주기적으로 튀어 뚝뚝 끊김·슬로우모션
- 증상
- 뚝뚝 끊김, 슬로우모션
- 요인
- 정체, 지터
- 누가 겪나
- 서버 전체
- 언제
- 사람이 몰릴 때, 가끔 무작위로
- 담당
- 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
- 게임개발팀 할 일
- 워커 스레드 수를 CPU 한도에 맞추기(런타임이 호스트 전체 코어 수만큼 스레드를 만들지 않게).
- 인프라팀 할 일
- CPU 한도를 넉넉히 두거나 빼고 전용 코어 배정, 스로틀링된 횟수(nr_throttled) 감시.
- 수치 감각
- 한도 2코어인 서버에서 스레드 8개가 동시에 일하면, 100ms 주기의 할당량을 25ms 만에 다 쓰고 75ms를 멈춥니다.
- 그래프에서는
- 인원·부하를 따라 오름 · 스로틀링 횟수(nr_throttled), 서버 틱 시간
- 확인할 곳
- 컨테이너 cgroup의 cpu.stat에서 nr_throttled·throttled_usec(cgroup v1은 nr_throttled·throttled_time) 증가량을 서버 틱 시간과 함께 봄
- 이러면 맞음
- 평균 CPU 사용률은 한도보다 낮은데 nr_throttled·throttled_usec가 계속 늘고, 틱이 튄 시각과 겹침
- 이러면 아님
- nr_throttled가 늘지 않으면 이 원인이 아님. 가상 머신 자체가 밀리면 “CPU 스틸 (가상 머신)”
- 확인 수단
- 인프라 도구로 확인(게임 코드 불필요)
출처
- CFS Bandwidth Control Linux kernel
주기마다 받은 할당량을 다 쓰면 다음 주기까지 스레드가 멈춤(스로틀링), 기본 주기 100ms, nr_throttled 통계 - Control Group v2 Linux kernel
cpu.max는 “$MAX $PERIOD”(할당량, 주기) 형식이고 기본값은 “max 100000”(100ms 주기) - Resource Management for Pods and Containers Kubernetes
컨테이너의 CPU limit은 커널이 CPU 스로틀링으로 강제하는 하드 한도
함께 보면 좋은 원인
같은 층: L7 서버 OS (커널)
같은 증상(뚝뚝 끊김)의 다른 층 원인
그림과 실험이 있는 원본 카드 보기