Saltar para o conteúdo 
CPU do servidor As classes de programadores controlam qual o processo que recebe tempo de computação e quando, e como as prioridades desencadeiam a deslocação de modo a que os tempos de resposta permaneçam baixos e o débito permaneça calculável. Eu mostro como as classes, Prioridades e as fatias de tempo interagem e como posso controlar a distribuição da carga com apenas algumas definições.
Pontos centrais
- Classes de programadores organizar os volumes de trabalho de acordo com regras e influenciar os tempos de resposta.
- Prioridades decidir quem tem tempo de CPU primeiro e quem espera.
- Preempção desloca as tarefas em execução quando estão pendentes tarefas mais importantes.
- Equidade impede que processos individuais se tornem permanentemente dominantes.
- Medição torna os efeitos visíveis e conduz a melhores definições.
Porque é que as classes de agendamento moldam o desempenho do servidor
Em ambientes produtivos, servidores Web, bases de dados e trabalhos competem pelo mesmo CPUs, e é por isso que a atribuição regulada é crucial. Confio em classes claras para que os pedidos interactivos não fiquem atrás dos trabalhos em lote e para que as acções dos utilizadores recebam respostas rápidas. Uma classificação clara dos serviços em classes reduz os tempos de espera, diminui os timeouts e torna o comportamento previsível, mesmo durante picos de carga. Sem essa categorização, há um risco maior de que um processo que consome muita CPU possa sobrecarregar o sistema de forma impercetível. Tempos de resposta de todos os outros. Por isso, dou prioridade aos caminhos críticos para o negócio, porque é aqui que cada milissegundo conta.
Noções básicas: Prioridade, classes, fatias de tempo
Cada programador combina Prioridade, A prioridade é definida por classes e fatias de tempo para atribuir tempo de computação e controlar a deslocação. Uma prioridade mais elevada reduz os tempos de espera, mas valores demasiado elevados bloqueiam outros processos, o que cria uma sensação de gagueira. As fatias de tempo limitam o tempo que um processo calcula de uma só vez antes de o processo seguinte ter a sua vez, o que promove a equidade. As classes também definem se uma tarefa é processada preferencialmente, uniformemente ou com regras de prazo. Avalio estas alavancas em conjunto porque só a combinação das mesmas pode otimizar o Planeamento reflectida de forma realista.
CFS em pormenor: vruntime, granularidade e janela de latência
Com o LinuxCFS não é o tempo real que conta, mas o tempo de execução virtual (vruntime) de uma tarefa. Quanto mais CPU uma tarefa tiver recebido, maior será o seu vruntime e mais tarde será agendada novamente. Este mecanismo cria Equidade, mas pode gerar latências muito diferentes, dependendo do número de threads activas. O Janela de latência (sched_latency) determina o período de tempo durante o qual o CFS atribui tempo „justo“ a todas as tarefas executáveis. Para muitas tarefas, o CFS encurta o Granularidade mínima por tarefa para que todos tenham a sua vez - com o efeito secundário de aumentar as mudanças de contexto. Com menos tarefas, os quanta e, portanto, o rendimento dos trabalhos pesados aumentam.
Faço apenas ajustamentos cautelosos: um pouco mais de min_granularidade suaviza as tempestades de mudança de contexto com milhares de threads de trabalho activas. Um pouco maior wakeup_granularity evita que as tarefas recém-acordadas e de curta duração antecipem os threads que são executados com muita frequência. Eu testo as alterações separadamente para os perfis de carga diurna e de pico, porque a mesma configuração de repente mostra efeitos completamente diferentes sob carga noturna.
Breve explicação das classes do Linux Scheduler
No Linux, as classes separam as tarefas típicas do servidor de acordo com Regras e expectativas para que as tarefas interactivas não sejam ofuscadas por trabalhos de computação longos. O CFS serve processos gerais de forma justa, enquanto as classes de tempo real abordam objectivos de reação difíceis e o DEADLINE assegura especificações de tempo mais precisas. As classes especializadas, como Idle ou Batch, cobrem o trabalho em segundo plano sem interferir com os serviços em primeiro plano. Para cada serviço, verifico qual a classe que corresponde ao seu padrão de comunicação, em vez de me limitar a ajustar os valores. Se quiser aprofundar o assunto, encontrará informações práticas sobre SFC e alternativas, que se revelaram eficazes no alojamento quotidiano.
| Classe | Utilização típica | Caraterística | Risco de configuração incorrecta |
|---|---|---|---|
| CFS (SCHED_OTHER) | Geral Serviços | Quota justa por maturidade | Esquiadores de fundo deslocam subtilmente empregos mais leves |
| Tempo real (SCHED_FIFO/RR) | Crítico em termos de latência Tarefas | Conceção preferida | Possibilidade de inanição para processos CFS |
| PRAZO | Prazos rigorosos | CPU reservada por orçamento/período | A falta de orçamento leva ao abandono escolar |
| Lote/Idle | Cópias de segurança, análises | Correr quando ainda há tempo | Maior tempo de funcionamento sob carga elevada |
Systemd, cgroups e ferramentas para implementação
Estabeleço prioridades não só numa base ad hoc, mas também em Unidades e cgroups para que as regras se mantenham estáveis: CPUSchedulingPolicy e CPUSchedulingPriority controlam a classe e a prioridade de um serviço, CPUWeight/CpuQuota atribuem núcleos de forma justa. No cgroup v2 eu uso cpu.max e cpu.weight, para combinar quadros rígidos (quota/burst) e ponderação suave. Isto mantém um caminho de resposta ágil, enquanto os backfills ou relatórios recebem de forma fiável o desempenho sem quebras.
Para correcções selectivas simpática/renice (ponderação CFS), chrt (atributos em tempo real/DEADLINE), conjunto de tarefas (afinidade com a CPU) e ionice (prioridade de E/S). Eu incorporo isso nos scripts de inicialização em vez de reajustar manualmente. Importante: Eu apenas defino sub-funções estritamente definidas para tempo real - por exemplo, um flusher de log - e deixo o resto no CFS para que o sistema geral não seja afetado. estável restos.
Estabelecer prioridades de forma sensata: Guia prático
Começo com uma dose moderada Prioridades e aumentar gradualmente os valores à medida que monitorizo a latência, o roubo de CPU e as trocas de contexto. Os trabalhadores do front-end têm uma prioridade ligeiramente superior para que os pedidos não fiquem à espera de relatórios, mas deixo espaço para as threads da base de dados. Desloco as tarefas de lote para horários fora de pico ou atribuo-as a classes de lote/ociosas para que os horários de pico permaneçam livres. Para objectivos de reação difíceis, verifico se uma parte pequena e claramente delimitada em classes de tempo real faz sentido sem colocar pressão no sistema global. Neste guia, apresento um procedimento estruturado para Otimização de prioridades, que descreve passo a passo as alterações e os pontos de medição.
Efeitos sobre a latência e o débito
As grandes prioridades reduzem a Latência pedidos interactivos, mas reduzem o tempo de computação dos trabalhos em segundo plano. As fatias de tempo equilibradas evitam que um único trabalhador ocupe a CPU durante demasiado tempo e que as filas de espera aumentem. Dependendo da carga de trabalho, os quanta curtos aumentam a capacidade de resposta, enquanto os quanta longos favorecem a taxa de transferência para streaming ou compressão. Por isso, meço ambos: os percentis 95 e 99 dos tempos de resposta e os pedidos processados por segundo. Utilizo estas métricas para reconhecer quando preciso de redefinir prioridades ou reafectar fatias de tempo. Calibrar.
NUMA, afinidade e controlo de interrupções
Em sistemas multi-socket, eu tomo uma decisão consciente sobre NUMA-filiação e Afinidade com a CPU. Eu associo serviços críticos de latência a núcleos dentro de um nó NUMA e asseguro que a sua memória é alocada localmente. Desta forma, evito acessos remotos com latência adicional. Com hosts com muitas bases de dados, separo as threads OLTP e a manutenção em segundo plano (por exemplo, ponteiros de verificação) em diferentes grupos de núcleos, para que as transacções de curta latência não concorram por núcleos com tarefas de longo prazo.
Também Interrupções Eu deixo o irqbalance funcionar, mas excluo núcleos de hot-path se necessário. Eu aloco interrupções de rede (RX/TX) para vários núcleos para que a pilha de rede não se torne um gargalo. Para serviços muito sensíveis à latência, subcontrato fontes de interrupção ruidosas a núcleos separados. Esta separação espacial complementa as prioridades e as classes - não as substitui.
Monitorização e métricas: tomar decisões com dados
Eu valorizo Métricas como carga da CPU, comprimento da fila de execução, troca de contexto e roubo de CPU, a fim de alocar claramente os gargalos. Filas de execução crescentes com rendimento decrescente indicam prioridades incorrectas ou fatias de tempo demasiado estreitas. Um número invulgarmente elevado de comutações de contexto revela que as threads estão a computar demasiado rapidamente e que a própria gestão está a consumir tempo. Para cargas mistas, verifico as medidas de equidade para que nenhuma classe de serviço perca permanentemente. Uma boa introdução às diretrizes e compromissos pode ser encontrada neste artigo sobre Políticas de programação, que utilizo como base para tomar decisões.
Rastreio, definição de perfis e testes reprodutíveis
Antes de corrigir a afinação, quero ver a causa e o efeito. Utilizo Definição de perfis e Rastreio, para visualizar hotpaths, tempos de espera de bloqueio e frequência de preempção. Testes de carga curtos e repetíveis com uma fase de aquecimento evitam interpretações erradas devido a caches frias ou JITs de aquecimento. Recolho percentis ao longo de vários minutos e várias execuções, em vez de comparar apenas os valores de pico. Uma separação clara é importante: primeiro uma linha de base, depois uma alteração e, em seguida, um teste idêntico. Eu documento as medições intermediárias com os parâmetros do host e do kernel para que eu possa recriar exatamente o mesmo ambiente semanas depois.
Armadilhas típicas e antipadrões
Aumento Prioridades nunca para serviços inteiros, pois isso apenas altera a hierarquia e cria novos estrangulamentos. Valores permanentemente altos em tempo real podem facilmente levar à paralisação de processos normais e criar efeitos colaterais imprevisíveis. As fatias de tempo demasiado pequenas conduzem a alterações de contexto e o desempenho diminui, apesar de a CPU estar obviamente a funcionar. Uma mistura de tarefas ligadas à CPU e tarefas pesadas de E/S sem uma escolha clara de classes desperdiça desempenho num banho alternado. Uma abordagem sistemática poupa tempo, evita regressões e mantém o Estabilidade elevado.
SMT, estados de energia e efeitos turbo
SMT/Hyper-Threading duplica núcleos lógicos, mas partilha unidades de execução físicas. Portanto, prefiro agendar threads de latência crítica em diferentes núcleos físicos antes de alocar seus núcleos irmãos SMT. Caso contrário, a lógica de computação partilhada pode aumentar os tempos de espera. Também observo Turbo- e Estados COs estados de sono profundo poupam energia, mas custam tempo de despertar. Nos caminhos de latência, reduzo os estados C profundos ou mantenho os núcleos „quentes“ se a política energética o permitir. Por outro lado, deixo deliberadamente as classes batch dormir mais profundamente - elas beneficiam da eficiência sem abrandar os utilizadores.
Exemplos de ajuste por tipo de carga de trabalho
Para os servidores Web, forneço luz prioridade-para os gerenciadores de pedidos e executar processos de cache logo abaixo deles. As bases de dados beneficiam de fatias de tempo equilibradas, de um número suficiente de threads de trabalho activas e de uma utilização restrita em tempo real apenas para os flushers de registo ou os ponteiros de verificação. Transfiro os trabalhos em lote para classes ociosas/batch para que utilizem ciclos livres sem abrandar os caminhos do frontend. Separo a análise e a ETL dos serviços interactivos, utilizando frequentemente uma classe separada ou um contentor com quotas de CPU. Isto permite-me manter a latência sob controlo sem Hardware a fornecer.
Rollouts, barreiras de proteção e caminhos de regresso
Realizo a afinação do agendador como uma libertação: com Canário-hosts, critérios de cancelamento claros e reversão rápida. Defino valores-limite para a latência do P99, a taxa de erro e o roubo de CPU. Se um valor ultrapassar o limite, reverto automaticamente para a última configuração estável. Limito as alterações por iteração: apenas prioridades ou apenas fatias de tempo - nunca as duas ao mesmo tempo. Mantenho versões de todas as configurações e documento as suposições e os resultados das medições. Desta forma, o caminho para uma boa configuração permanece rastreável, mesmo que as pessoas ou as plataformas mudem.
Virtualização e anfitriões partilhados
Em anfitriões partilhados, controlo CPU-cotas, fixação e afinidade NUMA antes de ajustar as prioridades. As máquinas virtuais partilham núcleos físicos, pelo que o roubo de CPU altera significativamente os tempos de espera medidos. Eu programo reservas para serviços críticos para que seus threads recebam tempo de computação previsível. Atribuo limites aos contentores para impedir o escalonamento por parte de clientes individuais. Somente quando essa base está em vigor é que eu ajusto a atribuição de classes e Prioridade por processo.
Resumo para a vida quotidiana
Em primeiro lugar, atribuo serviços a turmas definir prioridades moderadas e monitorizar especificamente a latência, o débito e as filas de espera. Pequenos passos produzem efeitos claros, grandes saltos obscurecem as causas e dificultam as reversões. Quando o tempo de resposta é importante, permito a definição de prioridades limitadas; quando o débito é importante, alargo os quanta e mantenho as prioridades estáveis. As métricas orientam todas as decisões, não o instinto, porque os programadores apresentam facilmente resultados pouco intuitivos. Com esta disciplina, utilizo o Servidor-CPU eficiente, manter as respostas rápidas e uma verdadeira equidade entre todos os serviços.
