Saltar para o conteúdo 
A Kernel sem cócegas reduz os despertares desnecessários da CPU e, assim, diminui ativamente os requisitos de energia do seu servidor sem perder a capacidade de resposta sob carga. Vou mostrar-lhe, passo a passo, como minimizar os Kernel configurar, ler os valores medidos e planear as cargas de trabalho de forma a que o desempenho e os custos de eletricidade sejam visivelmente harmonizados.
Pontos centrais
Os pontos seguintes descrevem os passos e as correlações mais importantes.
- Sem cócegas Temporizador: Interrupções controladas pela procura em vez de ticks periódicos
- Energia guardar: Manter os estados C profundos durante mais tempo, reduzir os despertares
- NO_HZ Opções: Utilizar CONFIG_NO_HZ_IDLE e CONFIG_NO_HZ_FULL
- agendador Afinação fina: carga de pacotes, definir afinidade de interrupção
- Monitorização Primeiro: Medição antes/depois para efeitos claros
Breve explicação do modo Tickless
Um clássico LinuxKernel acorda cada CPU em intervalos fixos, frequentemente 100 a 1000 vezes por segundo. Isto custa mensuravelmente Energia, mesmo que nenhuma tarefa esteja pendente. O modo Tickless substitui essa periodicidade por interrupções de temporizador controladas por demanda. Como resultado, a CPU permanece em estados de sono profundo durante mais tempo até que ocorra efetivamente um evento. De acordo com [1], é precisamente este comportamento que aumenta a eficiência, porque são eliminados os despertares desnecessários e a carga térmica é reduzida. Eu uso o Tickless quando os sistemas têm cargas muito flutuantes e precisam de alternar claramente entre atividade e repouso.
Porque é que o Tickless aumenta a eficiência energética
Se uma CPU permanecer inativa, os ticks rígidos utilizados para evitar que a Estados C e despertava os núcleos a toda a hora. Isto gerou mais Calor residual e forçou as ventoinhas a funcionar a velocidades mais elevadas. O Tickless elimina este despertador permanente e prolonga as fases de inatividade. Observei um menor consumo de energia no modo inativo e curvas de temperatura mais suaves para anfitriões Web e API com cargas de trabalho flutuantes. Em grandes parques de servidores, as pequenas poupanças por nó somam valores notáveis em euros na fatura da eletricidade. A plataforma permanece mais silenciosa e os picos de carga podem ser amortecidos de forma mais fiável.
Modos e opções do kernel num relance
Distingo duas abordagens principais: Tickless Idle e Tickless Full. O Tickless Idle faz uma pausa no periódico enquanto não houver tarefas pendentes e reproduz o seu Força especialmente nas fases de inatividade. O Tickless Full (NO_HZ_FULL) reduz os ticks para núcleos selecionados, mesmo durante o funcionamento, o que pode reduzir as latências e as alternâncias de contexto. As distribuições modernas activam frequentemente o NO_HZ_IDLE por predefinição, enquanto o NO_HZ_FULL requer uma afinação específica. Note que os modos estendidos requerem um ajuste fino da afinidade de interrupção e isolamento para garantir que o Vantagens não se desvanece devido a despertares aleatórios.
| Modo/Opção | Efeito | Adequado para | Notas |
|---|---|---|---|
| CONFIG_NO_HZ_IDLE | Suspender ticks em modo inativo | Carga geral do servidor com fases de inatividade | Frequentemente ativo por defeito, baixo Riscos |
| CONFIG_NO_HZ_FULL | Minimizar os tiques por núcleo durante o funcionamento | Baixa latência, HPC, núcleos selecionados | Limpar o isolamento do núcleo e a afinidade de IRQ Plano |
| isolcpus, rcu_nocbs | Núcleos de baixo ruído, menos despertares da UCR | Cargas de trabalho em tempo real | Apenas alguns núcleos isolam, os restantes transportam carga do sistema |
| Kernel ≥ LTS atual | Novos caminhos de poupança de energia, correcções | Todos os sistemas produtivos | Correcções e ganhos de eficiência de acordo com [1] utilizar |
Passo a passo: Definir o kernel e os parâmetros de arranque
Vou começar com um inventário das capacidades do kernel. Pode saber se o kernel suporta o tickless através das flags de configuração:
grep NO_HZ /boot/config-$(uname -r)
grep HIGH_RES_TIMERS /boot/config-$(uname -r)
grep -E 'CPU_IDLE|INTEL_IDLE' /boot/config-$(uname -r)
Para NO_HZ_IDLE, o kernel de distribuição é normalmente suficiente. Para NO_HZ_FULL, eu defino especificamente CPUs housekeeping que assumem as tarefas do sistema, IRQs e callbacks da RCU. Tipicamente, eu deixo a CPU 0-1 como housekeeping e defino os núcleos restantes para o modo DyTick:
# Exemplo de GRUB-CMDLINE (adaptar ao hardware):
GRUB_CMDLINE_LINUX="nohz_full=2-15 isolcpus=2-15 rcu_nocbs=2-15 irqaffinity=0-1 nmi_watchdog=0"
Importante: Pelo menos um núcleo deve permanecer em housekeeping, caso contrário, há o risco de paradas da RCU. Depois de atualizar a configuração do GRUB e reiniciar, verifico as definições activas:
cat /sys/devices/system/cpu/nohz_full # lista as CPUs NO_HZ_FULL
cat /sys/devices/system/cpu/isolated # lista CPUs isoladas
cat /proc/cmdline # verifica os parâmetros de arranque
Também ativo os temporizadores de alta resolução e os controladores específicos de inatividade (por exemplo, intel_idle). Ambos melhoram a granularidade fina dos temporizadores e a profundidade dos estados de suspensão. Se você usar o irqbalance, configure núcleos bloqueados para que a afinidade não migre de volta para CPUs isoladas:
# Exemplo: IRQBALANCE_BANNED_CPUS em /etc/irqbalance/irqbalance.env
IRQBALANCE_BANNED_CPUS=0x0003 # CPUs 0-1 permitidas, resto bloqueado (formato da máscara por sistema)
Em seguida, verifico se os ticks estão realmente ausentes, observando os próximos despertares por CPU:
sudo cat /proc/timer_list | grep -A2 'next event' | sed -n '1,60p'
Nas fases de silêncio, os eventos seguintes devem estar claramente no futuro ou completamente ausentes se não houver temporizadores.
Disciplina da medição: instrumentos e números-chave
Sem medição, qualquer otimização permanece cega. Registo os valores de base e comparo-os após cada alteração. Eles provaram o seu valor:
- topo de gama: Wakeups-from-idle/s, originador de topo, residência em estado C
- turbostatFrequências, pacote e núcleo C-states, desempenho RAPL
- estatística perfeitaComutações de contexto, interrupções de temporizador, ciclos, instruções
- /proc/interrupçõesDistribuição de IRQ por CPU
- pidstat/iostatCaraterísticas do processo e de E/S
# Captura 10 minutos de linha de base em modo inativo
sudo turbostat --Summary --intervalo 5 --quiet --show PkgWatt,BUS,CPU,CPU,CPU,MHz
sudo powertop --time=600 --html=/tmp/powertop_baseline.html
Mapa de calor de interrupções do #
watch -n2 'cat /proc/interrupts | sed -n "1,30p"'
# Mudanças de contexto e eventos de temporizador
perf stat -a --delay 5000 --timeout 60000 -e cs,task-clock,cpu-clock,irq_vectors:local_timer
Documentei em cada caso: Consumo de energia em repouso (PkgWatt), quotas de estado C, wakeups/s e métricas de latência (p95/p99) da minha carga de trabalho relevante. Mesmo as pequenas diferenças tornam-se visíveis ao longo das semanas.
Virtualização, contentores e tickless na pilha
O hipervisor e os convidados, em conjunto, geram muitos Temporizador e despertares, por exemplo, através do cron, do registo e dos agentes. Reduzo esta cadeia activando o Tickless no hipervisor e nos sistemas convidados. Isso elimina os despertares duplos e as CPUs virtuais ficam quietas por mais tempo. Em ambientes Kubernetes ou de microsserviços, o nível de ruído de fundo cai de forma mensurável. Também sincronizo os tempos de pod e lote para que sejam criadas janelas de inatividade mais longas e o Poupança subir.
Em ambientes KVM, eu planejo a fixação de vCPU e a afinidade de IRQs juntas: eu vinculo IRQs de vNICs ou vBlocks barulhentos a CPUs de manutenção, cargas de trabalho silenciosas a núcleos isolados. No lado do convidado, eu desativo fontes de timer supérfluas, reduzo as frequências do cron e uso timers systemd com precisão generosa (AccuracySec) para que os eventos sejam agrupados mais naturalmente. Isso torna as fases ociosas mais longas - o hipervisor se beneficia duplamente, pois há menos saídas e entradas de VMs.
Configuração prática: Perfis de potência, regulador, interrupções
Normalmente, utilizo o governador para reacções rápidas programador porque intercepta dinamicamente os saltos de carga. Deixo os C-States activos, a menos que as latências extremamente curtas tenham prioridade. Atribuo IRQs ruidosas a núcleos selecionados e mantenho outros núcleos livres para que possam dormir profundamente. Programo trabalhos em lote, backups e actualizações em blocos para agrupar fases tranquilas. Se você quiser saber mais sobre isso, pode encontrar informações básicas em Escalonamento da frequência da CPU, que coordeno em estreita colaboração com o Tickless, a fim de utilizar as dicas com moderação.
Além disso, ajusto a tendência de preferência energética (EPP/EPB) das CPUs modernas para que os impulsos só sejam activados quando necessário e as residências inactivas permaneçam elevadas. Os serviços com latência tolerante recebem valores de folga de temporizador maiores (systemd: TimerSlackNSec=), controlo os trabalhos periódicos através de temporizadores systemd com AccuracySec e RandomisedDelaySec. Isto reduz as cargas de borda e cria janelas de inatividade mais longas e contíguas.
# Exemplo: Atribuir IRQ especificamente (Atenção: verificar o número do IRQ)
echo 0-1 | sudo tee /proc/irq/XX/smp_affinity_list # bind IRQ to housekeeping
# set systemd timer cooperatively (extrato de uma unidade .timer)
AccuracySec=5min
RandomisedDelaySec=30min
Persistente=verdadeiro
Utilizar NUMA e load bundling de forma sensata
Em hosts multi-core e NUMA, eu aumento o Eficiência, concentrando deliberadamente a carga em apenas alguns núcleos. Como resultado, os núcleos livres caem mais e mais no estado C. Certifico-me de manter os acessos à memória NUMA-local para evitar aumentos desnecessários. O agendador do Linux ajuda, mas a fixação manual de threads quentes é muitas vezes o toque final. Com o Tickless, essa fixação é mais eficaz porque os núcleos isolados não são despertados por periódicos e, portanto, a Descanso têm.
Na prática, eu prefiro atribuir threads pesadas de E/S ao mesmo nó NUMA e isolar serviços intensivos de CPU para alguns núcleos deste nó. Os cgroups (cpuset, cpu) ajudam a traçar limites claros. Eu verifico o Transparent Huge Pages e o AutoNUMA numa base específica de carga de trabalho: eles podem ajudar, mas neutralizam o jitter de latência. É importante que pelo menos um nó retenha capacidade de manutenção suficiente para evitar que as tarefas do sistema sejam sobrecarregadas em núcleos críticos.
Equilíbrio e medição dos requisitos de latência
Algumas cargas de trabalho em tempo real ou de negociação exigem o menor tempo possível Tempos de resposta. Por isso, realizo testes com amostras próximas da produção e comparo os percentis de latência antes e depois das alterações sem cócegas. O NO_HZ_FULL pode reduzir as trocas de contexto e o ruído do temporizador, mas os estados C profundos ocasionalmente prolongam os caminhos de despertar. Com a telemetria para C-states, frequência, latências de pacotes e jitter, eu tomo decisões informadas. Se também faz a manutenção do kernel, beneficia de várias formas - a afinação do desempenho e as correcções de segurança andam de mãos dadas, como mostra a prática; a minha referência a Otimização do kernel, que integro sistematicamente nas janelas de manutenção.
Testei especificamente cenários de burst (fases curtas e intensas) e correlacionei os picos de latência com a frequência e os traços de estado C. As medições com um EPP fixo são úteis aqui, em alternativa, um teste curto com C-states limitados para visualizar a proporção da latência de despertar. Se forem utilizados núcleos NO_HZ_FULL, certifico-me de que as CPUs de manutenção não são insuficientes - caso contrário, existe o risco de avisos da RCU ou de jitter esporádico.
Segurança: Os kernels actuais pagam duas vezes
Tenho sistemas atual, porque os novos kernels não só aperfeiçoam os caminhos de poupança de energia, como também colmatam lacunas. Os relatórios sobre as vulnerabilidades do kernel mostram que os atacantes têm ocasionalmente sido capazes de alargar os direitos com pouco esforço. Com as actualizações, reduzo este risco e, ao mesmo tempo, asseguro os ganhos de eficiência dos mecanismos modernos [2]. Em suma, a segurança operacional aumenta e os períodos de inatividade não planeados não são um peso para os nervos nem para o orçamento. É precisamente esta combinação de segurança e Eficiência torna as actualizações regulares uma decisão fácil.
Efeito do centro de dados: PUE, ventiladores, unidades de fornecimento de energia
Menos despertares reduzem o Carga na refrigeração e distribuição de energia pode ser medida. Os picos da CPU são mais suaves, as ventoinhas funcionam com menos frequência no seu limite e as unidades de fornecimento de energia funcionam de forma mais eficiente. Este efeito dominó tem um impacto direto na PUE de um local. Se quiser saber mais, consulte o tópico centro de dados ecológico e utiliza o Tickless como um elemento de base num sistema holístico de gestão de energia. Planeio sempre as medidas em conjunto, porque o hardware, o sistema operativo e a carga de trabalho contribuem para a Poupança com.
Recorte prático de WordPress, PHP e bases de dados
Em pilhas CMS com muitos Pedidos de informação Eu me beneficio muito das camadas de cache e do ajuste limpo do PHP-FPM. Mantenho a opcache quente, fecho os plugins Chatty e minimizo o ruído do cron empilhando janelas de tarefas. As bases de dados têm períodos de manutenção claros, para que não empurrem picos de I/O para a carga diária. Juntamente com o Tickless, o ruído de fundo diminui e o servidor fica inativo mais rapidamente. Desta forma, a plataforma combina o desempenho por watt sem que os utilizadores sintam qualquer ruído percetível. Perdas ver.
Especificamente, reduzo os accionadores cron do WordPress, transfiro o trabalho recorrente para temporizadores systemd com coalescência e mantenho os trabalhadores PHP FPM dimensionados de forma a que ondas de carga curtas sejam servidas sem manter uma base permanente elevada de trabalhadores abertos. Os bancos de dados se beneficiam de janelas claras de autovácuo (acelerar/mover quando necessário) e "blocos de manutenção" consistentes. Prefiro agrupar todas as tarefas regulares, mas não críticas em termos de tempo, de uma forma grosseira, em vez de as disparar em segundos.
BIOS/UEFI e caminhos de hardware
Já defini a base na BIOS/UEFI: ativar os estados C profundos do pacote, utilizar substratos ASPM/PCIe L1 e não desativar as funções de poupança de energia em toda a linha. Só limito a profundidade do estado C numa base de teste se os objectivos especiais de latência o exigirem. As placas de rede e os controladores NVMe beneficiam dos modos de poupança de energia; no entanto, verifico se a gestão agressiva da energia gera picos de latência. Vale a pena fazer um balanço sensível: uma mudança a menos na economia máxima de energia pode ter um grande efeito na faixa de latência de 99p.
Rede e armazenamento: continuar a pressionar os wakeups
A pilha de rede frequentemente dispara muitos IRQs. Aumento cuidadosamente os parâmetros de coalescência para suavizar as tempestades de interrupções sem piorar desnecessariamente a latência:
Exemplo # (ajustar os valores especificamente para a carga de trabalho!)
sudo ethtool -C eth0 rx-usecs 16 rx-frames 16 tx-usecs 16 tx-frames 16
Dimensiono o GRO/LRO e o RSS para corresponder à topologia da CPU, de modo a que alguns núcleos suportem a maior parte do ruído de interrupção. No lado do armazenamento, verifico se as propriedades do dispositivo (por exemplo, NVMe-APST) já estão optimizadas e se os picos de carga não se prolongam para picos diários devido a trabalhos em segundo plano (scrubs, rebuilds). O objetivo é empurrar as explosões de E/S planeáveis para janelas definidas.
Imagens de erros e resolução de problemas
As configurações sem carraças raramente falham devido à mecânica de base, mais frequentemente devido à afinação:
- A UCR bloqueiaSe isto ocorrer após NO_HZ_FULL, a causa é normalmente um número demasiado reduzido de CPUs de housekeeping ou demasiada carga de IRQ em núcleos isolados. Planeie para ter mais capacidade de housekeeping.
- Despertares inesperadosO Powertop mostra os culpados. As fontes frequentes são agentes de telemetria, intervalos curtos de tempo ou registos de conversação.
- Distribuição desigual de IRQVerificar o /proc/interrupts e reajustar as afinidades; configurar corretamente o irqbalance.
- Jitter de latênciaA profundidade do estado C, o EPP e a coalescência variam gradualmente e observam p99; pequenos ajustes são frequentemente suficientes.
Para obter resultados reprodutíveis, trabalho com janelas de mudança, pontos de reversão claros e parâmetros documentados com precisão. Cada alteração é objeto de uma ronda de medição - só depois se segue o passo seguinte.
Passos concretos para o seu arranque
Começarei com uma corrente Kernel e verificar se NO_HZ_IDLE está ativo. Em seguida, meço as linhas de base: consumo de energia no modo inativo, temperatura, estados C, taxa de IRQ e latência. Em seguida, ativo as opções tickless e repito as medições. Se eu encontrar economia, salvo a configuração nos repositórios de código e documentação. Se necessário, testo o NO_HZ_FULL para núcleos selecionados e isolo-os com uma atribuição cuidadosa de IRQ para que o Efeito permanece visível.
O meu procedimento pragmático:
- Recolher a linha de base (10-15 minutos de inatividade + pequeno teste de carga, guardar as métricas)
- Verificar NO_HZ_IDLE, validar o temporizador de alta resolução e o controlador de inatividade
- Ajustar a afinidade e o equilíbrio de IRQs, IRQs altos em manutenção
- Aumentar a coalescência do temporizador (temporizador do systemd, TimerSlack, intervalos do cron)
- Opcional: NO_HZ_FULL nos núcleos selecionados + rcu_nocbs, deixar pelo menos 1-2 CPUs de manutenção livres
- Ajustar a fixação de NUMA e CPU, limites de Cgroup e janelas de lote
- Comparar antes/depois, documentar decisões
O meu breve resumo
O Tickless traz resultados mensuráveis Energia- e vantagens térmicas, especialmente para cargas de trabalho flexíveis com fases de inatividade mais longas. Começo com NO_HZ_IDLE e combino-o com perfis de potência sensatos. Em seguida, trabalho com afinidades de IRQ, agrupamento de cargas e disciplina de medição. Para cenários particularmente críticos em termos de latência, utilizo NO_HZ_FULL em doses e avalio o compromisso com testes realistas [1]. Se combinar a tecnologia, a conceção da carga de trabalho e a monitorização, pode utilizar o Potenciais desta função kernel de forma permanente.
