Tratamento de interrupções em servidores: como as interrupções da CPU afectam o desempenho

As interrupções da CPU controlam a rapidez com que o meu servidor responde a pacotes de rede, eventos de armazenamento e temporizadores - interrupções incorretamente distribuídas ou demasiado frequentes tornam as aplicações mais lentas de forma mensurável. Um servidor de tratamento de interrupções limpo reduz as trocas de contexto, diminui as latências e estabiliza os tempos de resposta durante picos de carga.

Pontos centrais

Antes de entrar em pormenores, vou resumir os seguintes aspectos fundamentais:

• Carga de interrupções compreender: Quando os valores percentuais se tornam críticos
• Paralelismo gerir: Interrupções simultâneas e latências no pior dos casos
• MSI-X utilização: Mais notícias, melhor distribuição
• RSS & Affinity: Colocar as interrupções da NIC nos núcleos
• Monitorização estabelecer: Ler os números, agir com determinação

O que desencadeia as interrupções da CPU nos servidores

Uma interrupção é uma Sinal, que imediatamente retira a CPU da sua tarefa atual e inicia um manipulador. As placas de rede comunicam novos pacotes, os controladores de armazenamento assinalam E/S concluídas, os temporizadores accionam os relógios - cada uma destas interrupções custa tempo de CPU. Com alta atividade, esses eventos somam muitas trocas de contexto e falhas de cache. Portanto, eu monitoro a frequência e o tempo que a CPU no kernel gasta em ISRs e DPCs. Se compreender esta dinâmica, pode controlar os tempos de resposta de forma fiável e manter as aplicações a funcionar de forma visivelmente mais suave.

Porque é que tempos de interrupção elevados custam desempenho

Em ambientes saudáveis, as interrupções do sistema são normalmente entre 0,1-2% CPU, 3-7% são possíveis a curto prazo. Se o tempo de interrupção se mantiver regularmente acima de 5-10%, existe frequentemente um problema de driver, hardware defeituoso ou afinação incorrecta. A partir de 30% a situação torna-se grave e, para além de 50%, existe a ameaça de Estrangulamentos e tempos de resposta lentos. As aplicações perdem rendimento, as latências aumentam e a previsibilidade é afetada. Começo por verificar as versões dos controladores, o firmware, as afinidades e a moderação das interrupções nas placas de rede.

Interrupções simultâneas: Compreender as latências

Uma única interrupção raramente permanece um Problema; A situação torna-se difícil quando vários eventos colidem. Se uma interrupção de alta prioridade ocorrer durante uma interrupção de baixa prioridade, o seu processamento é prolongado por mais interrupções. Um exemplo: se o caminho de alta prioridade requer 75 ciclos e o caminho de baixa prioridade 50, a latência do caminho de baixa prioridade aumenta facilmente para 125 ciclos - outras sobreposições aumentam a latência. Na pior das hipóteses-A latência aumenta rapidamente. Este comportamento torna os sistemas imprevisíveis. Por isso, planeio as afinidades e prioridades do núcleo de modo a que os hotpaths não se bloqueiem uns aos outros.

MSI e MSI-X na utilização quotidiana

Os hosts modernos usam MSI ou MSI-X, em vez de enviar sinais de linha clássicos (linhas IRQ). A MSI transmite a mensagem como uma escrita na memória, reduzindo assim a latência e a suscetibilidade a interferências. O MSI-X alarga o conceito: mais mensagens, filas separadas, distribuição mais precisa pelos núcleos. Isto reduz as colisões de interrupções e melhora a Escalonamento com alta taxa de transferência. Eu ativo o MSI-X para NICs e controladores NVMe, desde que os controladores e o firmware suportem isto de forma estável.

mecanismo	Max. Mensagens	Endereçamento	Distribuição por núcleos	Efeito típico
IRQ herdado	1 por dispositivo/linha	Sinal de linha	Restrito	Mais alto Latência, mais colisões
MSI	Até ~32	Escrita na memória (16 bits)	Bom	Menos despesas gerais, trajectos mais estáveis
MSI-X	Até 2048	Escrita de memória (32 bits)	Muito bom	Mais fino Distribuição, maior paralelismo

DMA, DPCs e o caminho de dados correto

Com o DMA, os dispositivos podem armazenar dados diretamente no Memória A CPU apenas acciona as rotinas de processamento. Isso economiza interrupções porque menos estados intermediários precisam ser sinalizados. Certifico-me de que os DPCs agrupam o trabalho real em vez de fazerem demasiado na ISR. Isto mantém o tempo na secção crítica curto e a Latência mais previsível. Em geral, a CPU ganha mais tempo para a lógica da aplicação.

Configurar especificamente o RSS e a afinidade com a CPU

O Receive Side Scaling distribui as filas de rede e as suas interrupções por vários núcleos. Eu vinculo todas as filas, incluindo a interrupção, o DPC e a thread do utilizador ao mesmo núcleo ou cluster de núcleos para evitar despertares entre núcleos. Se diferentes núcleos estiverem envolvidos num fluxo, os erros de cache e as trocas de contexto aumentam. Um plano de afinidade estruturado evita visivelmente essas perdas por atrito. Se quiser aprofundar o assunto, pode encontrar um Afinidade com a CPU-Visão geral das configurações de alojamento.

Desativar as interrupções de armazenamento e os caminhos de E/S

O armazenamento também gera muitos Interrupções, especialmente com muitos IOPS pequenos. Utilizo o MSI-X em controladores NVMe e atribuo filas a núcleos fixos para que a entrada e a saída permaneçam locais. Além disso, um Programador de E/S, para suavizar a carga por fila. As variantes Deadline, BFQ ou MQ reagem de forma muito diferente consoante a carga de trabalho. Se testar corretamente aqui, reduz o jitter e aumenta o Rendimento.

Tempestades na rede, inundações SYN e moderação de interrupções

As inundações súbitas de encomendas levam a ISR-e tirar o fôlego da CPU. Eu ativo a moderação de interrupções na placa de rede para que os pacotes cheguem em rajadas razoáveis sem gerar picos de latência. Para cenários de DoS, uma rede resiliente Defesa contra inundações SYN a tabela de ligação numa fase inicial. Ao mesmo tempo, avalio se a própria moderação reage demasiado lentamente - depois ajusto os valores. O objetivo é conseguir um fluxo de pacotes suave que distribua uniformemente os DPCs. alimentos.

Controlo: ler e agir com base nos números

Começo com alguns, claros MétricasUtilização total da CPU, tempo de interrupção, tempo de DPC, troca de contexto e fila do processador. Se a CPU se mantiver normalmente abaixo de 50%, reajo com calma; entre 50 e 80% observo picos e hotspots; acima de 80% planeio o escalonamento ou a afinação. Se o tempo de interrupção subir acima de 30%, verifico o driver, o firmware e as afinidades. Uma verificação de latência para áudio/vídeo mostra indiretamente como o kernel reage de forma determinística. Importante: só altero um Variável por ensaio e, em seguida, medir novamente.

Topologia NUMA e localidade PCIe

Em hosts com vários soquetes, eu sempre decido as afinidades de interrupção no contexto do NUMA-topologia. Uma NIC ou um controlador NVMe está fisicamente conectado a um complexo raiz PCIe e, portanto, a um nó NUMA. Se eu definir as filas e suas interrupções para distante núcleos, os dados viajam através de ligações UPI/QPI - as latências aumentam, a largura de banda diminui. Por isso, verifico a que nó NUMA está atribuído um dispositivo, atribuo as suas filas aos núcleos locais e asseguro que as threads de utilizador associadas utilizam o mesmo nó. No Windows, presto atenção aos grupos de processadores e à definição do dispositivo para o nó NUMA preferido; no Linux, ligo consistentemente IRQs, softirqs e threads de aplicações ao nó local. O resultado: menos tráfego entre nós, mais estável Jitter-e latências calculáveis no pior dos casos.

Utilizar corretamente os offloads, a NAPI e a coalescência

As descargas são poderosas alavancas contra inundações de interrupções - mas devem ser utilizadas para Carga de trabalho em forma. Resumido grosseiramente: TSO/GSO deslocam a segmentação para a NIC, LRO/GRO resumem os segmentos que chegam, RSC no anfitrião tem um efeito semelhante ao de LRO. Para transferências em massa (cópia de segurança, replicação), estas caraterísticas aumentam o débito e reduzem significativamente a taxa de ISR. No entanto, para fluxos críticos em termos de latência (RPCs, negociação, VoIP), as grandes agregações podem ter um impacto negativo na taxa de ISR. Tempos de resposta estender. Por isso, opto por definições moderadas: GRO sim, mas não exagere; LRO apenas se não houver dispositivos a meio do caminho ou firewalls a causar problemas; deixe o TSO/GSO ativo como regra.

A NAPI no Linux muda do modo de interrupção pura para o modo de sondagem a partir do carregamento. Isto suaviza os picos e mantém a CPU ocupada no caminho do DPC em vez de acionar milhares de ISRs curtas. Juntamente com Interromper a moderação (coalescência), é criado um plano: temporizadores curtos para perfis interactivos, temporizadores mais longos para perfis em massa. Testo os intervalos em incrementos de microssegundos, observo as quedas, os níveis de preenchimento dos anéis e as latências para encontrar o ponto ideal. Na pilha de armazenamento, os parafusos de ajuste analógicos (profundidade da fila, NCQ, optimizações blk-mq) produzem o mesmo efeito: menos staccato, mais Eficiência.

Equilíbrio de IRQ vs. pinagem estática

O balanceamento automático de IRQ distribui a carga de forma aceitável - mas não perfeitamente. Em ambientes web homogéneos, deixo-o frequentemente a funcionar e controlo apenas os hotspots. Em configurações de latência crítica ou assimétricas Fixação estática superior: Eu defino conjuntos fixos de CPU para cada fila e dispositivo, mantenho-os consistentes através de reinicializações e minimizo a migração de softirqs. Além disso, reservo núcleos de „manutenção“ para trabalho em segundo plano (temporizadores, Kthreads) para que os núcleos de desempenho permaneçam livres. No Windows, utilizo especificamente direcionamento de interrupções e máscaras de afinidade para cada fila; no Linux, trabalho com afinidade por IRQ e controlo Softirq. O lema: tanta automação quanto necessário, tanto quanto Determinismo o mais possível.

Virtualização e SR-IOV/virtio

Os custos adicionais surgem nas VMs: as interrupções virtuais significam Saídas de VM, atrasos de programação e filas partilhadas. Eu conecto vCPUs de E/S intensiva a PCUs adequadas, evito o comprometimento excessivo em hosts de E/S e separo os threads do plano de dados da carga de gerenciamento. Sempre que possível, utilizo SR-IOVAs funções virtuais trazem o MSI-X para a VM convidada e reduzem a carga no caminho do hipervisor. Para cargas de trabalho genéricas, o virtio com aceleração vhost oferece resultados sólidos; em cenários de alto rendimento, mapeio filas 1:1 para vCPUs e mantenho as afinidades consistentes de convidado para host. Importante: As mesmas regras para RSS, coalescência e NUMA também se aplicam às VMs - apenas a Transparência é mais baixa, pelo que meço mais de perto.

Gestão de energia e latências determinísticas

As funções de poupança de energia são boas para o balanço, mas más para o trabalho Orçamentos de latência. Os C-states profundos prolongam o tempo de despertar e as alterações agressivas de frequência causam instabilidade. Em hosts com SLOs rigorosos, defino perfis de desempenho, limito os estados C profundos do pacote e só permito o turbo quando a reserva térmica é grande o suficiente. As decisões sobre o temporizador (temporizadores de alta resolução vs. menor frequência de interrupção) também influenciam a quantidade e a taxa de trabalho do kernel. Em configurações quase em tempo real, os modos sem cócegas e os núcleos isolados ajudam: threads de aplicação em núcleos isolados, trabalho do sistema em núcleos dedicados de „manutenção“ - para que os núcleos críticos Caminho quente livre de fogos interferentes.

Ferramentas e metodologia de medição por SO

Mantenho a minha Cadeia de diagnóstico simples e reproduzíveis. No Linux, começo com o /proc/interrupts e o /proc/softirqs, verifico os contadores por fila através do ethtool e analiso as definições de coalescência e descarga. O mpstat, o vmstat e o sar mostram tendências macro; o perf revela pontos críticos em ISRs/DPCs. Eu correlaciono os contadores de pacotes e de quedas com os tempos do kernel e as métricas de fluxo. No Windows, os indicadores de desempenho sobre o tempo de interrupção/DPC, interrupções/seg. e DPCs/seg. fornecem uma imagem clara; os traços mostram quais os controladores que estão a marcar o tempo. Importante é o facto de Escala de tempoRegisto tudo sincronizado para que os picos, as quedas e os saltos de latência coincidam.

Manual de resolução de problemas e antipadrões

O meu procedimento é coerente: primeiro Observar, depois uma hipótese, depois uma alteração. Causas típicas: uma fila ou um dispositivo com uma taxa de ISR crescente, firmware defeituoso, valores de coalescência demasiado altos (sistema resistente) ou demasiado baixos (tempestade de ISR), descargas que agrupam demasiado grandes ou threads que puxam filas através de nós NUMA. Eu isolo o dispositivo afetado, testo os padrões conservadores, ajusto os drivers/BIOS e distribuo a carga de forma limpa. Anti-padrão: mover tudo ao mesmo tempo, rollbacks confusos, nenhuma linha de base ou leituras sem contexto. Se você usar persistentemente um Variável após o outro, acabará rapidamente por obter uma configuração estável.

Projetos para hosts 10/25/100G e NVMe

Para placas de rede 10G, calculo 4-8 filas RSS, dependendo da geração da CPU e do perfil dos pacotes. Começo a coalescência moderadamente (por exemplo, microssegundos baixos de dois dígitos), GRO ligado, LRO com cuidado. Em 25G, eu escalono para 8-16 filas e mantenho a afinidade estritamente NUMA-local. A partir de 40/100G, a arquitetura das filas torna-se o Tarefa principalMuitas filas, alocação limpa por núcleo, offloads ativos, NAPI entra em vigor sob carga. Para o armazenamento NVMe, eu mapeio pelo menos uma fila por núcleo e mantenho a profundidade da fila adequada para a carga de trabalho - pequenas E/Ss se beneficiam de mais paralelismo, grandes transferências sequenciais de uma política de coalescência estável e um agendador que suaviza as explosões. O objetivo continua a ser o mesmo: latências constantes, sem núcleos quentes, sem anéis a transbordar.

Lista de controlo prática para um sucesso rápido

Eu actualizo primeiro Condutores e BIOS/firmware, porque os estados defeituosos muitas vezes aumentam a carga de interrupção. Então, se possível, eu mudo para o MSI-X e distribuo as filas de forma limpa para os núcleos. Configuro o RSS para que as afinidades de fluxo estejam corretas e os hotpaths permaneçam consistentes. Na placa de rede, adapto a moderação ao perfil de tráfego e observo o efeito nas latências. Se continuar a encontrar valores anómalos, procuro hardware defeituoso, opções incorrectas ou dispositivos problemáticos utilizando o procedimento de exclusão e um Definição de perfis.

Avaliar de forma realista os custos e benefícios

Nem todos os sistemas necessitam do máximo Afinação fina. Dou prioridade a anfitriões com uma carga de pacotes elevada, muitos IOPS pequenos ou especificações de latência apertadas. Algumas horas de afinação compensam bastante, porque uma menor sobrecarga de interrupções liberta imediatamente CPU para a aplicação. Em servidores não críticos, uma configuração básica sólida com os drivers mais recentes e MSI-X é suficiente. Os valores medidos guiam-me, não a intuição ou Pressupostos.

Resumo: O que eu levo para a manutenção diária

Observo de forma consistente Interrupção- e os tempos de DPC, mantenho os controladores e o firmware actualizados e utilizo o MSI-X sempre que possível. Planeio RSS e afinidades por carga de trabalho para que os fluxos, DPCs e threads permaneçam locais. Adapto a moderação da placa de rede aos padrões do tráfego, distribuo as filas de armazenamento de forma limpa e utilizo caminhos de E/S adequados. Se a monitorização mostrar valores anómalos, trabalho diretamente nos controladores, no hardware e na configuração. Desta forma, o servidor de tratamento de interrupções permanece previsível e as minhas cargas de trabalho funcionam com estabilidade. Desempenho.