한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

게임 렉 백서 › 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 스틸 (가상 머신)”
확인 수단
인프라 도구로 확인(게임 코드 불필요)

출처

  1. CFS Bandwidth Control Linux kernel
    주기마다 받은 할당량을 다 쓰면 다음 주기까지 스레드가 멈춤(스로틀링), 기본 주기 100ms, nr_throttled 통계
  2. Control Group v2 Linux kernel
    cpu.max는 “$MAX $PERIOD”(할당량, 주기) 형식이고 기본값은 “max 100000”(100ms 주기)
  3. Resource Management for Pods and Containers Kubernetes
    컨테이너의 CPU limit은 커널이 CPU 스로틀링으로 강제하는 하드 한도

함께 보면 좋은 원인

같은 층: L7 서버 OS (커널)

같은 증상(뚝뚝 끊김)의 다른 층 원인

그림과 실험이 있는 원본 카드 보기