CPU Limit과 CFS Throttling 관련 자료 정리

2019년 KubeCon 발표와 커뮤니티 이슈를 참고해 공유했던 CPU throttling 메모입니다. CPU 제한이 동작하는 원리와 당시 논의를 중심으로 정리했습니다.

당시 관심을 가졌던 문제는 멀티코어 환경에서 CPU Limit을 사용하는 프로세스가 예상보다 자주 실행을 제한받는 현상이었습니다.

CPU 할당량과 평균 사용률

Linux의 CFS bandwidth control은 일정 기간에 사용할 CPU 시간의 총량을 제한합니다. 여러 스레드가 여러 CPU에서 동시에 실행되면 각 CPU에서 쓴 시간이 합산됩니다.

짧은 구간에 할당량을 소진해 기다리는 시간과, 모니터링에서 몇 초 단위로 보는 평균 사용률은 다를 수 있습니다. 평균 사용률이 낮아 보인다는 이유만으로 throttling이 잘못 발생했다고 판단할 수는 없습니다.

CPU request와 limit도 역할이 다릅니다. 배치와 자원 분배를 위한 request를 늘렸다고 limit에 따른 시간 제한이 자동으로 없어지는 것은 아닙니다.

당시 자료는 CPU quota 구현과 커널 스케줄러의 문제, 수정된 커널 버전을 함께 소개했습니다. Kubernetes 이슈에서도 CPU 제한과 전용 CPU 배치의 관계를 논의했습니다.

다만 모든 CPU throttling을 그 버그 하나로 설명할 수는 없습니다. 애플리케이션의 스레드 수와 실제 부하, quota·period 설정, 사용 중인 커널에 수정이 포함됐는지를 확인해야 합니다.

bash


uname -r

커널 버전 번호는 확인의 출발점입니다. 배포판이 수정 사항을 기존 버전에 반영할 수 있어, 숫자만 보고 패치 포함 여부를 판단하기보다 벤더의 변경 이력도 봐야 합니다.

이후 Dave Chiluk이 2019년 12월 Indeed 기술 블로그에 공개한 설명에서는, quota의 만료 처리를 고친 뒤 불필요한 throttling이 드러난 과정과 후속 수정을 다룹니다. 당시 메모에 남긴 패치 버전도 이 글에서 확인할 수 있습니다.

이 표는 해당 문제의 수정 이력입니다. 지금 운영할 커널을 고르는 기준으로 쓰기보다는, 당시 환경에 이 수정이 포함됐는지 확인할 때 참고할 수 있습니다.

cgroup v1에서는 cpu.stat의 nr_periods, nr_throttled, throttled_time 등을 확인할 수 있습니다. 적용할 경로와 지표 이름은 cgroup 버전과 수집 도구에 맞춰야 합니다.

throttling이 발생한 횟수나 시간이 애플리케이션의 응답 지연과 정확히 일대일로 대응하는 것은 아닙니다. 같은 기간의 요청량과 지연, CPU 사용량을 함께 비교해야 합니다.

자료에는 CPU quota를 끄거나 높이는 우회도 제시돼 있었습니다. 하지만 limit 변경은 같은 노드의 다른 워크로드와 자원 격리에도 영향을 줄 수 있습니다.

일률적으로 limit을 몇 배 늘리기보다 현재 설정과 실행 패턴을 확인하고, 변경 전후를 같은 조건에서 비교해야 합니다. 커널 변경 역시 적용된 수정 사항과 실제 증상을 확인한 뒤 판단할 부분입니다.