Picos de latência pelo gerenciamento de energia do servidor (C-states e ajuste de frequência) CPU power management latency (C-states, frequency scaling)
ID da causa so-cstate · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
Núcleos de CPU ociosos entram em estados profundos de economia de energia (C-states) e baixam a frequência para economizar eletricidade. Quando chega um pacote ou dispara um timer, o núcleo leva tempo para despertar e subir a frequência, e isso soma latência ao processamento de pacotes pequenos.
Por quê A política de ajuste de frequência do SO (governor) ou a configuração de energia do BIOS permite C-states profundos e frequências baixas → Efeito Cada vez que um núcleo ocioso desperta de um estado profundo, ele atrasa até centenas de µs. Se a frequência fica presa num valor baixo, o próprio cálculo do tick fica lento → Na tela Em geral imperceptível, mas com muitas chamadas entre servidores o atraso se acumula e vira input lag, pior justamente quando o servidor está vazio. Com a frequência presa num valor baixo, o tick atrasa quando junta muita gente: câmera lenta
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Pôr a configuração de energia do BIOS no modo desempenho e o governor do SO em performance (scaling_governor do cpufreq), limitar os C-states profundos nos servidores sensíveis à latência (perfil tuned latency-performance, /dev/cpu_dma_latency do PM QoS, parâmetro de kernel intel_idle.max_cstate), depois da mudança comparar o tempo de ida e volta dentro do mesmo data center, o jitter do tempo de tick e o consumo de energia.
Números de referência
Pela tabela do driver intel_idle do Linux 6.12, o C1 (raso) das CPUs Intel para servidor leva 1–2 µs para despertar, e o C6 (profundo), de 133 µs (Skylake-SP) a 290 µs (Sapphire Rapids). Uma vez só é pouco, mas, se um pedido passa por vários servidores, o atraso se soma em cada um. Quanto maior o tempo ocioso previsto, mais profundo o estado que o kernel escolhe, por isso o efeito aparece mais em servidores vazios, onde os pacotes chegam espaçados. O governor powersave do cpufreq genérico fixa a frequência mais baixa da faixa permitida (o algoritmo de mesmo nome do intel_pstate ajusta conforme a carga).
No gráfico
Sempre alto desde o início · Tempo de ida e volta dentro do mesmo data center, frequência dos núcleos
Onde olhar
Ver com cpupower monitor a proporção de tempo em cada C-state e a frequência real por núcleo, e conferir name, latency (µs para despertar) e usage de cada state em /sys/devices/system/cpu/cpu0/cpuidle/, o scaling_governor do cpufreq e o perfil atual com tuned-adm active
Confirma se
Com pouca carga, o núcleo passa muito tempo no C-state mais profundo ou a frequência fica presa perto do mínimo, e trocar para o governor performance e C-states rasos reduz o tempo de ida e volta e o jitter dos pedidos pequenos
Descarta se
Diferença de no máximo dezenas de µs depois da mudança: esta causa pode ser ignorada. Picos na casa dos ms: “CPU steal (máquina virtual)” ou outra camada
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Em servidores bare metal no data center, verifique juntas a configuração de energia do BIOS (firmware) e a do SO. Na nuvem, só alguns tipos de instância deixam o SO mudar C-state e frequência; na AWS, o padrão já é desempenho máximo, então na maioria dos casos dá para deixar como está. O perfil tuned latency-performance da família Red Hat põe o governor em performance e, via PM QoS, usa só C-states rasos. Desligar a economia de energia aumenta o consumo, então aplique isso só em servidores sensíveis à latência.
Fontes
CPU Idle Time ManagementLinux kernel Cada estado de economia de energia tem um tempo para despertar (exit latency) e um tempo mínimo de permanência (target residency), e o estado profundo é escolhido conforme o tempo ocioso previsto; latency, usage e time de cada state no sysfs; estados profundos limitados com PM QoS (/dev/cpu_dma_latency) e intel_idle.max_cstate
drivers/idle/intel_idle.c (Linux v6.12)Linux kernel Tempo para despertar por C-state das CPUs Intel para servidor: Skylake-SP C1 2 µs, C1E 10 µs e C6 133 µs; Ice Lake C6 170 µs; Sapphire Rapids C1 1 µs e C6 290 µs
CPU Performance ScalingLinux kernel Ver e mudar o governor com scaling_governor; performance pede a frequência mais alta da faixa permitida, powersave pede a mais baixa
intel_pstate CPU Performance Scaling DriverLinux kernel O algoritmo powersave do intel_pstate, diferente do governor powersave genérico, ajusta conforme a carga (parecido com schedutil e ondemand)
Chapter 2. Getting started with TuneDRed Hat O perfil latency-performance desliga recursos de economia de energia, põe o governor em performance e usa PM QoS para ficar só em C-states rasos; tuned-adm active mostra o perfil atual
Processor state control for Amazon EC2 Linux instancesAWS Só alguns tipos de instância deixam o SO controlar C-states e P-states, e isso pode ser mudado para reduzir a latência; o padrão é desempenho máximo, adequado à maioria das cargas; o Graviton tem frequência fixa e o SO não a controla