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

서버 전원 관리(C-state·주파수 조절)로 지연 튐 CPU power management latency (C-states, frequency scaling)

원인 ID so-cstate · 주 담당 인프라팀·서버 인프라

쉬는 CPU 코어는 전기를 아끼려고 깊은 절전 상태(C-state)로 들어가고 주파수도 낮춥니다. 패킷이나 타이머가 오면 깨어나고 주파수를 올리는 데 시간이 걸려, 작은 패킷 처리에 지연이 더해집니다.

왜 OS의 주파수 조절 정책(governor)이나 BIOS 전원 설정이 깊은 C-state와 낮은 주파수를 허용 → 그러면 쉬던 코어가 깊은 절전 상태에서 깨어날 때마다 최대 수백 µs 늦고 주파수가 낮게 묶여 있으면 틱 계산 자체가 느려짐 → 화면에서는 대개 체감하기 어렵지만 서버 간 호출이 많으면 쌓여 한산할 때 오히려 응답이 늦는 입력 지연. 주파수가 낮게 묶이면 사람이 몰릴 때 틱이 밀려 슬로우모션

증상: 입력 지연, 슬로우모션
요인: 지연, 지터, 정체
누가 겪나: 서버 전체
언제: 항상, 가끔 무작위로
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: BIOS 전원 설정을 성능 쪽으로, OS governor를 performance로(cpufreq의 scaling_governor), 지연에 민감한 서버는 깊은 C-state 제한(tuned latency-performance 프로필, PM QoS의 /dev/cpu_dma_latency, 커널 파라미터 intel_idle.max_cstate), 바꾼 뒤 같은 데이터센터 안 왕복 시간·틱 시간 지터와 전력 사용을 함께 비교.
수치 감각: 리눅스 6.12의 intel_idle 드라이버 표 기준으로 인텔 서버 CPU의 얕은 C1은 깨어나는 데 1~2µs, 깊은 C6는 133µs(Skylake-SP)~290µs(Sapphire Rapids)입니다. 한 번은 작지만 요청 하나가 서버 여러 대를 거치면 그만큼 쌓입니다. 커널은 예상 유휴 시간이 길수록 깊은 상태를 고르므로 패킷이 드문드문 오는 한산한 서버에서 더 자주 나타납니다. 범용 cpufreq의 powersave governor는 허용 범위의 가장 낮은 주파수로 고정합니다(intel_pstate의 같은 이름 알고리즘은 부하에 따라 조절).
그래프에서는: 처음부터 늘 높음 · 같은 데이터센터 안 왕복 시간, 코어 주파수
확인할 곳: cpupower monitor로 코어별 C-state에 머문 비율과 실제 주파수를 보고, /sys/devices/system/cpu/cpu0/cpuidle/ 아래 state마다 name·latency(깨어나는 데 걸리는 µs)·usage, cpufreq의 scaling_governor, tuned-adm active로 현재 프로필을 확인
이러면 맞음: 코어가 한산할 때 가장 깊은 C-state에 오래 머물거나 주파수가 최저 근처에 묶여 있고, performance governor·얕은 C-state로 바꾸면 작은 요청의 왕복 시간과 지터가 줄어듦
이러면 아님: 바꿔도 차이가 수십 µs 안쪽이면 이 원인은 무시해도 됨. ms 단위로 튀면 “CPU 스틸 (가상 머신)”이나 다른 층
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 베어메탈 IDC 서버는 BIOS(펌웨어)의 전원 설정과 OS 설정을 함께 봅니다. 클라우드에서는 일부 인스턴스 종류만 OS가 C-state·주파수를 바꿀 수 있고, AWS는 기본 설정이 최대 성능 쪽이라 대부분 그대로 두어도 됩니다. Red Hat 계열의 tuned latency-performance 프로필은 governor를 performance로 두고 PM QoS로 얕은 C-state만 쓰게 합니다. 절전을 끄면 전력 소비가 늘어나니 지연에 민감한 서버에만 적용합니다.

출처

CPU Idle Time Management Linux kernel
절전 상태마다 깨어나는 시간(exit latency)과 최소 머무름 시간(target residency)이 있고, 예상 유휴 시간에 맞춰 깊은 상태를 고름, sysfs의 state별 latency·usage·time, PM QoS(/dev/cpu_dma_latency)와 intel_idle.max_cstate로 깊은 상태 제한
drivers/idle/intel_idle.c (Linux v6.12) Linux kernel
인텔 서버 CPU의 C-state별 깨어나는 시간: Skylake-SP C1 2µs·C1E 10µs·C6 133µs, Ice Lake C6 170µs, Sapphire Rapids C1 1µs·C6 290µs
CPU Performance Scaling Linux kernel
scaling_governor로 governor 확인·변경, performance는 허용 범위의 가장 높은 주파수, powersave는 가장 낮은 주파수를 요청
intel_pstate CPU Performance Scaling Driver Linux kernel
intel_pstate의 powersave 알고리즘은 범용 powersave governor와 다르게 부하에 따라 조절(schedutil·ondemand와 비슷)
Chapter 2. Getting started with TuneD Red Hat
latency-performance 프로필은 절전 기능을 끄고 governor를 performance로, PM QoS로 얕은 C-state만 쓰게 함, tuned-adm active로 현재 프로필 확인
tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12) Linux kernel
cpupower monitor: 코어별 주파수와 절전 상태 통계
Processor state control for Amazon EC2 Linux instances AWS
일부 인스턴스 종류만 OS가 C-state·P-state를 제어할 수 있고 지연을 줄이려고 바꿀 수 있음, 기본 설정은 최대 성능이라 대부분의 작업에 알맞음, Graviton은 고정 주파수라 OS가 제어하지 않음

서버 전원 관리(C-state·주파수 조절)로 지연 튐 CPU power management latency (C-states, frequency scaling)

출처

함께 보면 좋은 원인

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

같은 증상(입력 지연)의 다른 층 원인