Saltar para o conteúdo 
Mostro como Métricas do servidor como CPU ociosa, carga e iowait de forma que eu possa separar gargalos reais de picos inofensivos e tomar contramedidas direcionadas. Explico quais os valores-limite que fazem sentido, como é que os índices interagem e como obtenho passos específicos a partir dos valores medidos.
Pontos centrais
- CPU inativamostra o tempo de computação livre e as fases de espera ocultas
- Média de cargamede as filas de espera e a utilização do núcleo
- iowaitexpõe os travões de armazenamento e de rede
- InteraçãoReconhecer padrões em vez de ver os valores individuais de forma isolada
- AlertasDefinir limiares e tendências significativos
Interpretar corretamente o estado de inatividade da CPU
Eu leio CPU inativa como a proporção de tempo em que a CPU não está a executar nada ou à espera de E/S, e avalio-o sempre no contexto das cargas de trabalho actuais. Se a inatividade se mantiver frequentemente acima dos 60 a 80 por cento, programo mais tarefas ou reduzo os serviços porque existem reservas não utilizadas. Se a inatividade descer abaixo dos 20 por cento durante um longo período de tempo, procuro primeiro processos com CPU bloqueada, loops ineficientes e falta de paralelização. Se a ociosidade cai enquanto o tempo do usuário (us) e o tempo do sistema (sy) estão altos, há muito a ser dito sobre a pura fome computacional; se a ociosidade cai enquanto o iowait aumenta, por outro lado, isso indica bloqueios fora da CPU. Para servidores Web, considero saudável um intervalo de 20 a 40 por cento de inatividade numa média diária, desde que os tempos de resposta se mantenham estáveis e os utilizadores não sejam visivelmente afectados por quaisquer valores atípicos.
Compreender a carga do servidor
Eu avalio o Média de carga como o número médio de processos que querem calcular ou estão à espera de tempo de CPU, e compará-lo diretamente com o número de núcleos. Se a carga de 1 minuto exceder repetidamente o número de núcleos, são criadas filas de espera, o que se reflecte em atrasos no agendamento e em pedidos de execução mais longos. Para as decisões quotidianas, presto especial atenção à carga de 5 e 15 minutos porque suaviza as horas de ponta e evita falsos alarmes causados por picos curtos. Num servidor de 4 núcleos, interpreto valores de carga até cerca de 3,2 como uma utilização sólida; para valores superiores a 4,0, examino ativamente os processos, bloqueios e caminhos de E/S. Se quiser evitar as típicas interpretações incorrectas da carga, pode encontrar dicas práticas em Interpretar corretamente a média de carga, onde torno tangíveis os casos limite e os exemplos de cálculo.
Delimitar claramente a espera de E/S (espera da CPU)
Faço a distinção entre iowait O iowait é estritamente diferente da utilização real, porque a CPU está pronta, mas não pode calcular porque está à espera de operações de memória ou de rede. Se o iowait se mantiver permanentemente acima dos 10%, verifico primeiro as latências do suporte de dados, as profundidades das filas, os estrangulamentos do sistema de ficheiros e os caminhos da rede. Se muitos processos com status D (sono ininterrupto) aparecerem no topo, isso solidifica minha suspeita de bloqueio de acessos de E/S. Nesses casos, SSDs NVMe, mais IOPS, opções de montagem otimizadas ou um cache de página maior aceleram o processamento antes que eu pense em escalar. O guia fornece uma introdução compacta com imagens de exemplo típicas Entender a espera de E/S, para me ajudar com o diagnóstico inicial.
Classificar corretamente a pressão da memória
Eu separo Impressão de memória ciente dos gargalos de CPU e E/S, porque a falta de memória tem suas próprias assinaturas. Se a atividade de recuperação de página aumenta, eu vejo as colunas si/so (swap in/out) no vmstat ou as taxas de falha de página no sar, e correlaciono isso com iowait e tempos de resposta. A utilização moderada de swap não é automaticamente ruim com um cache de página grande, mas a troca persistente diminui a velocidade de qualquer CPU. Em tais situações, a parte ociosa não necessariamente diminui, enquanto a carga pode aumentar - os processos então esperam por páginas recuperadas e bloqueiam a fila de execução. Verifico especificamente a proporção da cache de páginas (livre/buffers/cache), as principais falhas dos processos afectados e a definição de swap antes de aumentar a RAM ou ajustar as caches. No Linux, também uso o PSI (Pressure Stall Information) em /proc/pressure/memory para ver se as tarefas estão a esperar visivelmente pela memória. Se o PSI mostrar um aumento de stalls em janelas de tempo significativas, eu aumento o espaço do cache de página, alivio a carga com caches de objeto/consulta no aplicativo ou movo trabalhos em lote para janelas mais silenciosas para que as cargas de trabalho interativas não sufoquem devido à pressão da memória.
Interação de inatividade, carga e espera
Eu classifico o Interação dos índices, porque os padrões revelam mais do que os valores individuais. Uma carga elevada combinada com um tempo de inatividade elevado indica frequentemente bloqueios de E/S. Muitos processos estão à espera, a própria CPU está aborrecida: Muitos processos estão à espera, a própria CPU está aborrecida. Um tempo ocioso baixo com uma carga baixa, por outro lado, indica processos individuais de computação intensiva que ocupam a CPU por um longo tempo sem causar grandes filas. Se o tempo de roubo (st) nas VMs também aumentar, informo o anfitrião de um potencial overbooking ou considero a possibilidade de mudar de anfitrião. Só quando a interação está a funcionar corretamente é que decido sobre medidas como o escalonamento vertical, a distribuição horizontal ou a otimização específica do código.
Considerar a frequência da CPU, o turbo e o estrangulamento
Eu controlo Frequências da CPU e Turbo Boost, porque os valores percentuais (us/sy) podem ser enganadores se a frequência de relógio for escalada dinamicamente. Se a frequência cair (economia de energia, estrangulamento térmico), o poder de computação absoluto cai, embora ocioso e a carga possam parecer inalterados. Leio o MHz atual por núcleo (por exemplo, através do turbostat ou do cpupower) paralelamente à utilização e avalio os picos com vista à temperatura e ao regulador (poupança de energia, desempenho). Se houver picos de latência durante fases curtas de inatividade, os estados C baixos (C6+) podem aumentar o tempo de despertar - para serviços críticos de latência, defino limites de estado C mais conservadores ou o regulador de desempenho, enquanto a carga em lote beneficia da poupança de energia. Eu descubro Aceleração térmica sob carga contínua, planeio melhorias de arrefecimento, reduzo as tarefas em segundo plano não críticas nas fases quentes ou distribuo as cargas de trabalho de modo a que os núcleos não se acelerem e as métricas forneçam uma imagem mais realista.
NUMA, interrupções e afinidade
Presto atenção a Zonas NUMA e distribuição de interrupções, porque o tráfego cruzado distorce as métricas. Se uma thread acessa repetidamente a memória no nó NUMA „errado“, as latências aumentam visivelmente, enquanto o load e o iowait mostram padrões como „muita coisa acontecendo, mas pouco progresso“. Eu verifico os hotspots com o numactl/numastat, atribuo cargas de trabalho aos nós (CPU e memória) conforme necessário e presto atenção ao tamanho do buffer pool por socket para bancos de dados. Eu distribuo a carga da rede via RSS/RPS/XPS e verifico /proc/interrupts para que um único núcleo não carregue todas as interrupções da NIC e aja como um gargalo. Se eu detecto altas taxas de sy% com pouco trabalho do usuário, interpreto isso como um indicador de impressão de IRQ, caminhos de cópia do kernel ou checksumming - nesses casos, drivers atualizados, opções de descarregamento personalizadas e um equilíbrio justo de IRQ entre os núcleos ajudam.
Fluxo de trabalho de diagnóstico rápido no terminal
Começo por topo ou htop para ver imediatamente a divisão da CPU (us, sy, ni, id, wa, hi, si, st), valores de carga e processos conspícuos. Em seguida, verifico o tempo de atividade para a carga de três valores e comparo as tendências de 1, 5 e 15 minutos com o tempo do evento. Com o vmstat, obtenho uma visão de fluxo da fila de execução, trocas de contexto, atividade de troca e históricos de iowait. Para o suporte de dados, utilizo o iostat, leio tps, await, svctm e identifico picos de latência por dispositivo ou LUN. Se o pidstat e o perf mostrarem pontos de acesso no código, dou prioridade aos caminhos afectados antes de pensar no hardware, porque muitas vezes consigo ganhos rápidos com uma pequena correção no sítio certo.
Contentores e Cgroups: reconhecer o estrangulamento
Eu avalio Limites dos contentores como uma possível causa se as imagens de carga não corresponderem. Se as cotas de CPU (CFS) reduzirem o tempo do processo, vejo o aumento da carga com um tempo us% surpreendentemente baixo, porque as tarefas estão aguardando a próxima janela de fatia de tempo. No Kubernetes, certifico-me de que pedidos e limites são realistas: Limites muito apertados levam a estrangulamento, solicitações muito baixas levam a gargalos de agendamento no nó. Verifico os contadores de estrangulamento do cgroup, observo os contêineres com uma alta taxa de troca de contexto e fecho a afinidade de fixação da CPU e primeiro dimensiono as cotas antes de atualizar os nós. Limites de memória sem headroom podem levar a mortes OOM - eu posso reconhecer isso pelo término abrupto de processos, falhas importantes visíveis com antecedência e picos de latência erráticos. As contramedidas são a existência de limites sensatos, a distribuição horizontal e a existência de buffers para as tarefas em segundo plano, de modo a que os caminhos produtivos não sejam abrandados pelos limites.
Selecionar valores-limite e alertas de forma sensata
Eu fixo Valores de limiar para que comuniquem os riscos reais e para que os picos de curto prazo não accionem constantemente os alarmes. Para o CPU inativo, planeio avisos a partir de cerca de 20%, para o iowait a partir de 10% e para a carga a partir de 80% dos núcleos, em cada caso com um pequeno atraso. Uma segunda fase com um limiar mais elevado desencadeia o escalonamento ou o redimensionamento automático para me dar tempo para atuar. Para monitorizar as tendências, utilizo a carga de 15 minutos e comparo-a com os padrões diários e semanais para reconhecer os picos sazonais. Envio alertas num pacote para me manter concentrado em situações de incidente e não me perder nas notificações.
| Métricas | Orientação | Aviso | Crítico | Causa possível | Ação rápida |
|---|---|---|---|---|---|
| CPU inativa | > 60 % | < 20 % | < 10 % | Forte caminho de código, demasiado poucos núcleos | Definição de perfis e paralelização de hotspots |
| Carga | < Número de núcleos | > 0,8 × núcleos | > 1,0 × núcleos | Filas de espera, bloqueios, congestionamento de E/S | Verificar os processos de topo, reduzir o bloqueio |
| iowait | < 5 % | > 10 % | > 20 % | Disco/rede lento, pistas demasiado pequenas | NVMe/RAID, aumentar a profundidade da fila |
Planeamento de capacidades com SLOs e linhas de base
Ligação I Capacidade com SLOs (por exemplo, tempo de resposta 95%) em vez de apenas valores médios. Para a CPU, estabeleço objectivos de margem de manobra (por exemplo, P95 ocioso não inferior a 20%) para que os picos de carga curtos não se transformem imediatamente em filas de espera. Para a carga, utilizo linhas de base históricas por hora do dia e estação do ano para criar limiares dinâmicos que têm em conta o crescimento ou as campanhas. Defino os alertas como um composto: Só quando, por exemplo, Carga > núcleos, iowait > 10 por cento e a latência P95 aumenta, a fase 2 é acionada. Em ambientes de nuvem, planeio reservas de fase (por exemplo, +25% de núcleos, +x IOPS) e tenho playbooks prontos sobre a forma como as regras de auto-escalonamento entram em vigor sem gerar um thrash. Testo as alterações com medições A/B, documento as métricas antes/depois e asseguro que as optimizações não se limitam a deslocar a carga, mas eliminam os estrangulamentos a longo prazo.
Causas e soluções típicas
Vejo frequentemente valores elevados de iowait para pequenos volumes de nuvem com garantias insuficientes de IOPS, razão pela qual mudo especificamente para armazenamento NVMe ou volumes maiores com garantias mais elevadas e reduzo significativamente os tempos de espera. Se ocorrer uma carga elevada com iowait normal, encontro frequentemente regex ineficientes, caches em falta ou ORMs tagarelas, que atenuo com índices, afinação de consultas e cache de resposta. Se o tempo do sistema for dominante, analiso as interrupções de rede, os estados do driver e os recursos de descarregamento da NIC, porque as tempestades de IRQ sobrecarregam a CPU. Se houver quedas esporádicas com tempo de roubo simultâneo em VMs, verifico a alocação do host e mudo uma janela de realocação para uma vizinhança mais silenciosa. Se a aplicação for escalonada horizontalmente, eu fecho os gargalos com caches centrais, filas assíncronas e elimino os tempos limite para que os outliers individuais não bloqueiem todo o nó.
Virtualização: Note o tempo do roubo
Eu meço roubar tempo (st) em ambientes virtualizados porque mostra quanto tempo de computação o hipervisor está a desviar. Se o st subir regularmente acima de alguns por cento, envio o bilhete ao fornecedor com documentos de métricas e peço a relocalização ou recursos dedicados. Em cenários multilocatário, também planeio buffers para a carga, de modo a que pequenos estrangulamentos causados por vizinhos não conduzam diretamente a alarmes. No que respeita ao anfitrião, reduzo os trabalhos em segundo plano desnecessários para criar mais espaço para a carga produtiva em janelas sensíveis. Para sistemas críticos, prefiro núcleos dedicados ou instâncias bare-metal para garantir latências previsíveis.
Painéis de controlo e práticas de acompanhamento
Eu construo Painéis de controlo para que mostrem os valores da CPU, carga, iowait, memória, disco e rede em conjunto e me forneçam cadeias de causas em segundos. Pequenos intervalos de amostragem de cinco segundos revelam picos, enquanto as visualizações resumidas tornam visíveis as tendências. Formulo alertas em função da sazonalidade e da hora do dia, para que os turnos noturnos não sejam activados em todos os picos. Os manuais, nos quais guardo testes padrão e caminhos de escalonamento, ajudam-me na análise para que ninguém comece do zero. Se quiser começar de uma forma estruturada, pode dar uma vista de olhos ao meu artigo Análise dos dados de monitorização que resume os painéis mais importantes e as figuras-chave.
Testes de desempenho sem ângulos mortos
Eu controlo Estrangulamentos não só sob carga total, mas também em fases de inatividade, porque as cópias de segurança, as tarefas cron e as execuções de índices interferem frequentemente durante a noite. Para aplicações com tráfego intenso, crio perfis de carga realistas que incluem caches frias e fases de aquecimento. Registo consistentemente comparações A/B antes e depois das alterações, para poder separar os efeitos reais das flutuações aleatórias. Para os caminhos de memória, correlaciono a latência, as profundidades das filas e o rendimento para reconhecer a causa e o efeito. Ao nível da rede, utilizo seletivamente a captura de pacotes se as métricas, por si só, não explicarem porque é que os pedidos estão bloqueados.
Receitas práticas: Amostras para medidas
- Carga elevada, inatividade elevada, iowait elevado: verificar os caminhos de E/S, aumentar a profundidade da fila, armazenar em cache antes do disco.
- Pouco tempo de inatividade, pouca carga: Um único hot thread - criação de perfis, paralelização ou batching.
- Sy% elevado, us% normal: Otimizar o hotpath IRQ/kernel, o driver/offloading e a distribuição de interrupções.
- Carga próxima da contagem de núcleos, picos de latência apenas sob aceleração turbo: verificar o arrefecimento/governação, evitar a aceleração.
- Contentores com vias de estrangulamento: aumentar as quotas de CPU, harmonizar pedidos/limites, reduzir a co-tenancy.
- Memória - PSI aumentada, iowait moderado: ajustar a cache de páginas/conjunto de trabalho, adicionar RAM ou mover trabalhos em lote.
Brevemente resumido
Eu leio CPU inativa, O Load e o iowait trabalham sempre em conjunto porque o padrão fornece as conclusões e torna claros os meus próximos passos. Com limites claros, intervalos curtos e painéis de controlo significativos, evito voos cegos e reajo em tempo útil. Procuro pontos de acesso no código para a carga da CPU, melhores caminhos de E/S e armazenamento em cache para o iowait, e simplifico as filas e a sincronização para cargas elevadas. Nas VMs, incluo o tempo de roubo para que os limites da infraestrutura não apareçam como um problema da aplicação. A manutenção desta disciplina reduz as falhas, utiliza os recursos de forma sensata e mantém os tempos de resposta baixos e fiáveis.
