Saltar para o conteúdo 
Com perf top No Linux, consigo identificar em segundos quais as funções do kernel que, neste momento, consomem mais tempo de CPU e onde se formam os pontos de estrangulamento. Neste guia, mostro, através de passos claros, como identifico os pontos críticos em tempo real, interpreto a saída de forma fiável e, a partir daí, deduzo otimizações rápidas para o agendador, a rede e a memória.
Pontos centrais
Considero que a visualização em direto de perfeito É ideal para um bom ponto de partida, porque revela imediatamente os principais fatores que consomem mais tempo. As percentagens por símbolo mostram-me se o gargalo está no Kernel ou se está no espaço do utilizador. A partir de padrões recorrentes, deduzo se são os bloqueios, as IRQs, a rede ou a memória que predominam. Em seguida, delimito o ponto crítico com ferramentas mais avançadas e verifico as alterações diretamente sob carga. É assim que vou melhorando, passo a passo, o CPU- otimizar a utilização da capacidade e reduzir as latências de forma sustentável.
- Pontos de acesso em direto identificar e priorizar
- percentagens interpretar corretamente em função de cada caso
- Foco principal definir: IRQs, bloqueios, memória
- Fluxo de trabalho: topo → registo → relatório
- Otimizações verificar de forma específica
O que é o Perf Top e para que serve?
Eu uso perf top, para ver imediatamente, enquanto a carga está em execução, quais os símbolos que consomem a maior parte do tempo da CPU. A ferramenta acede aos contadores de desempenho do hardware e apresenta-me, em intervalos curtos, uma lista atualizada das funções mais dispendiosas. Segundo a revista Linux-Magazin, o perf domina tanto a análise de desempenho como o rastreio, o que faz com que a Visualização em direto combina de forma harmoniosa com análises mais aprofundadas. No procedimento habitual, complemento o instantâneo com o «perf record» e o «perf report» para analisar gráficos de chamadas e percursos exatos. É assim que respondo à questão central: onde é que a CPU exatamente o seu momento – na pilha de rede, no subsistema de memória, no agendador ou num controlador?
Instalar e iniciar o perf top
Após a instalação através do pacote de distribuição, executo perfeito O „top“ é normalmente executado com direitos de acesso alargados, para que os símbolos do kernel e os eventos do sistema fiquem visíveis. Basta um simples comando «perf top» para criar uma primeira visualização em tempo real e identificar as funções dominantes. Se precisar de me concentrar em processos específicos, adiciono o PID com a opção -p; para CPUs específicas, utilizo a opção -C com uma lista ou um intervalo. Defino os eventos com a opção -e, como, por exemplo, ciclos de CPU, instruções ou falhas de ramificação, dependendo da questão que pretendo esclarecer. Para obter resultados reproduzíveis, inicio a medição durante uma carga real, para que Pontos de acesso ser claramente visíveis e não se perderem no ruído de fundo.
É assim que interpreto corretamente esta edição
Na lista, avalio primeiro o Valores percentuais por símbolo, porque refletem as proporções relativas de tempo. Proporções elevadas nas funções do sistema indicam um estrangulamento no kernel, enquanto símbolos dominantes no espaço do utilizador apontam mais para a lógica da aplicação. Se observar muitas rotinas do agendador, penso em demasiados threads ativos, afinidades desfavoráveis ou prioridades inadequadas. Se aparecerem funções de memória no topo, verifico os padrões de alocação, as falhas de página, a localidade NUMA e as caches. No caso dos percursos de rede, analiso a distribuição de IRQ, as configurações de Gro/TSO e o comportamento dos controladores, porque esses detalhes são os Latência influenciar significativamente.
Causas típicas dos pontos de congestionamento do kernel
Muitos pontos críticos surgem porque muitos pequenos custos se somam, formando um grande Carga acumular. Frequentemente, as mudanças excessivas de contexto, a concorrência por bloqueios e a distribuição desigual de IRQs aumentam o tempo de CPU. Da mesma forma, estruturas de memória fragmentadas, a utilização ineficiente de slabs ou o paging constante consomem ciclos desnecessários. Se um determinado controlador me chamar a atenção, estabeleço uma correlação com a carga de trabalho, o hardware e a versão, para limitar os efeitos colaterais. Em sistemas multicore, verifico também o «false sharing», porque, de acordo com a documentação do kernel, as linhas de cache partilhadas podem rapidamente resultar em Despesas gerais podem causar preocupações.
Análise exemplar de um ponto crítico
Se o Perf Top me mostrar, durante um período prolongado, proporções elevadas em funções relacionadas com a rede, a primeira coisa que faço é separar os tipos de carga: pacotes pequenos vs. grandes, TLS vs. texto simples, muitas ligações vs. poucas sessões de longa duração, para identificar a Causa delimitar. Em seguida, aprofundo a análise com o «perf record» e o «perf report», ativo os gráficos de chamadas (-g) e comparo os percursos ao longo de várias execuções. Se, em vez disso, o problema estiver relacionado com a gestão de memória, verifico o alocador, as Huge Pages, as definições do THP e a afinidade NUMA, pois é aqui que rapidamente surgem percursos desnecessários. Muitas vezes, interpreto os pontos críticos do agendador como um sinal de que há demasiados threads executáveis ou de uma atribuição inadequada à CPU. Altero sempre apenas um Parâmetros por ciclo, para que eu possa atribuir corretamente o efeito.
O melhor em ambientes de alojamento
Em cenários de alojamento, vejo frequentemente como pequenos custos do kernel afetam a Latência de vários serviços. Os contentores, máquinas virtuais e instâncias de bases de dados em execução paralela deslocam significativamente o perfil para a rede, o armazenamento e o agendador. Com o `perf top`, consigo identificar se os pontos de estrangulamento se situam mais no tratamento de IRQ, no processamento de SoftIRQ ou nos percursos de bloqueio. Em seguida, incluo na análise a versão do kernel, o layout NUMA, as afinidades de IRQ e as profundidades das filas, uma vez que estes fatores interagem entre si. Quem quiser aprofundar o assunto encontrará neste guia sobre Analisar os pontos de estrangulamento da CPU outros pontos de partida práticos que utilizo regularmente na prática.
Guia prático para a análise
Começo por um cenário de carga reproduzível, para que as medições se mantenham comparáveis e Pontos de acesso aparecer de forma estável. Depois, inicio o perf top e anoto os símbolos dominantes ao longo de várias atualizações. Condenso este instantâneo com o perf record/report para obter uma imagem clara dos gráficos de chamadas, de modo a identificar o caminho até ao ponto mais dispendioso. Em seguida, alterei de forma específica apenas um aspeto, por exemplo, uma afinidade de IRQ ou a profundidade de uma fila, e voltei a medir. Só quando o efeito ficou claro é que passei para o próximo Etapa analisar e documentar as conclusões para futuras janelas de manutenção.
Quando é que outras ferramentas são mais adequadas
Para uma perspetiva histórica, gráficos de chamadas mais detalhados ou cadeias de eventos específicas, recorro a perfeito record/report, ftrace ou eBPF. Os pontos de rastreio ajudam-me a analisar percursos específicos, enquanto os programas BPF permitem-me obter métricas flexíveis. Quando pretendo analisar mais profundamente os percursos do kernel, estes fornecem Ferramentas de análise eBPF sinais valiosos diretamente no local do problema. Para problemas de cache e partilha, o perf-c2c e o pahole são úteis, desde que o ponto crítico seja claramente identificado. É assim que passo da análise da visualização em tempo real para a causa, sem me perder em detalhes irrelevantes pormenores para perder.
Opções de amostragem e filtros na prática
Eu passo a Amostragem-Aplico uma estratégia específica à questão, em vez de medir tudo de forma generalizada. Em caso de picos esporádicos, aumento a frequência de amostragem e reduzo os intervalos de exibição para captar picos passageiros. Para focar num processo, defino -p no PID relevante; para focar na CPU, defino -C nos núcleos mais ativos. Com -e, controlo o evento, por exemplo, cpu-cycles para uma análise abrangente ou cache-misses, se houver suspeita de problemas de memória. Utilizo os gráficos de chamadas (-g) assim que tiver localizado aproximadamente um ponto crítico e o Causa que pretenda encontrar na pilha.
A tabela seguinte apresenta botões práticos que costumo combinar no dia a dia, bem como as utilizações típicas de cada opção:
| Opção | Efeito | Utilização |
|---|---|---|
| -p PID | Limita a medição a um processo | Específicas da aplicação Pontos de acesso delimitar |
| -C Lista de CPUs | Foco em áreas-chave selecionadas | Verificar a distribuição NUMA/IRQ |
| -e Evento | Seleciona um evento de hardware ou de software | ciclos, instruções, falhas de cache |
| -g | Ativa a amostragem do Callgraph | Caminhos dispendiosos no Pilha Reconhecer |
| –kernel/–user | Filtra no espaço do kernel ou no espaço do utilizador | Separar a fonte do tempo de CPU |
| –ordenar | Ordenado por símbolo, DSO, dso:symbol | Legibilidade da Classificação aumentar |
Costumo testar brevemente as configurações antes de iniciar medições mais longas, para que a Mostrar permaneça estável e não surjam efeitos secundários. Especialmente com frequências de amostragem elevadas, presto atenção à sobrecarga, para não sobrecarregar desnecessariamente o sistema. No caso de hosts de contentores, verifico adicionalmente se os limites de namespace e cgroup restringem a visibilidade. Para obter benchmarks reproduzíveis, documento todas as opções, incluindo as versões do kernel e dos controladores. Esta disciplina poupa-me muito trabalho mais tarde Tempo na classificação das alterações.
Interpretação do subsistema: rede, memória, agendador
Quando os caminhos de rede estão no topo, verifico primeiro as afinidades de IRQ, o RSS (Receive-Side-Scaling) e os offloads como o GRO/TSO, porque estes parâmetros de ajuste são os Rendimento-Alterar o equilíbrio de latência. Quando as funções de memória apresentam anomalias, analiso os padrões de alocação, as Huge Pages, as estatísticas do Slab e as taxas de falhas de página. Frequentemente, associo a carga do agendador a um número excessivo de threads, à falta de afinidade da CPU ou a uma priorização injusta. Para eventos específicos do kernel, defino adicionalmente pontos de rastreio ou utilizo bpftrace no alojamento, para confirmar hipóteses. Assim, associo a visualização em tempo real do «perf top» a pontos de medição mais detalhados e chego mais rapidamente ao resultado final Causa.
Requisitos e visibilidade dos símbolos
Portanto, isso perf top Ao resolver todos os símbolos relevantes do kernel, presto atenção a duas coisas: as permissões adequadas e as informações disponíveis sobre os símbolos. Em sistemas de produção, é kernel.perf_event_paranoid muitas vezes definido num valor elevado. Para análises aprofundadas do kernel, reduzo temporariamente este valor ou trabalho como utilizador root com as permissões necessárias (CAP_PERFMON/CAP_SYS_ADMIN). Se os endereços do kernel estiverem ocultos (kptr_restrict), na maioria das vezes vejo os nomes, mas não os endereços brutos – isso é suficiente para eu estabelecer prioridades. No espaço do utilizador, instalo os pacotes de informação de depuração correspondentes, para que o `perf top` mostre os nomes das funções em vez dos deslocamentos. Isso reduz as suposições e acelera a identificação da causa.
Valores percentuais e armadilhas da amostragem
Interpreto os valores percentuais da lista como percentagens relativas das amostras medidas, e não como a utilização exata da CPU no domínio do tempo. Se selecionar vários eventos, é possível Multiplexagem aplicar: o Perf distribui os contadores ao longo do tempo e normalizado o gráfico. Para obter um quadro claro, começo por fazer uma medição abrangente com ciclos de CPU ou instruções e, só mais tarde, incluo eventos especiais. Deteto picos momentâneos com uma frequência mais elevada (-F) e intervalos mais curtos; em sistemas estáveis, a frequência padrão é suficiente. Além disso, tenho em conta que Inativo-As fases e as alterações de frequência (Turbo, Governor) podem distorcer a perceção. Por isso, para medições comparativas, uniformizo as definições de ritmo e energia.
Callgraphs em profundidade
Quando identifico um ponto crítico, aprofundo a análise através de gráficos de chamadas. Com -g e, com um método de desenrolamento adequado, consigo obter o caminho para o ponto dispendioso. Os ponteiros de frame ou o desenrolamento DWARF proporcionam-me pilhas estáveis; sempre que disponível, utilizo o buffer de retorno suportado por hardware (LBR) para cadeias muito precisas. Aumento os buffers mmap apenas o necessário para manter a sobrecarga baixa. Se a pilha apresentar muitas funções auxiliares, presto atenção a inclusive vs. exclusivo Custos: O que é determinante é saber se a função em si é dispendiosa ou se apenas predomina como via de trânsito. Esta distinção poupa-me frequentemente horas na investigação das causas.
Trabalhar em contentores e máquinas virtuais
Em ambientes de contentores, verifico se a minha visualização de cgroups e os namespaces estão corretos. Concentro as medições nos PIDs e CPUs relevantes, para que os «vizinhos barulhentos» não distorçam o quadro. No caso das máquinas virtuais, verifico se a PMU virtual está ativada; caso contrário, faltam-me eventos de hardware precisos e vejo principalmente sinais de software. Reconheço frequentemente os anfitriões KVM pelos símbolos à volta de kvm_vcpu ou vmx/svm. Nesses cenários, separo claramente as análises do anfitrião e do convidado, para não confundir causa e efeito.
Padrões identificáveis e hipóteses rápidas
No dia-a-dia, há certos padrões que se revelaram eficazes e que verifico imediatamente:
- Concorrência da Lock: Mergulho queued_spin_lock_slowpath ou mutex_spin_on_owner No topo, as estruturas de dados estão demasiado amplas ou as filas de trabalho são demasiado restritas. Reduzo a contenção através do sharding, de uma granularidade de bloqueio mais precisa ou da alteração dos tamanhos dos lotes.
- Impressão do agendador: Estão a multiplicar-se schedule(), pick_next_task_fair ou percursos de despertar, ajusto o número de threads, as afinidades e as prioridades. Muitas vezes, basta acalmar os threads “faladores” ou definir corretamente as configurações da CPU.
- Softirqs de rede: Picos em net_rx_action, napi_poll ou as descargas de soma de verificação indicam picos de tráfego ou uma distribuição subótima de RSS e IRQ. Atribuo as IRQ aos núcleos adequados e ajusto o GRO/TSO para o perfil de débito/latência pretendido.
- Caminhos de armazenamento: Muito tempo em do_page_fault, copy_user_* ou as funções Slab permitem-me verificar os padrões de alocação, THP/Huge Pages e a localidade NUMA. Uma localização incorreta acaba por custar, sem que se perceba, um grande número de ciclos.
- RCU e temporizadores: Dominar rcu_core ou callbacks de temporizador, estou a rever as estratégias de polling e de processamento em lote dos meus serviços, para garantir um funcionamento mais estável do sistema.
Aprofundar os conhecimentos sobre a rigor na medição e a reprodutibilidade
Para garantir execuções comparáveis, mantenho constantes os fatores ambientais: regulador da CPU, estados Turbo, tarefas em segundo plano e até mesmo a temperatura ambiente no caso de nós densos. Atribuo cargas de teste a núcleos definidos e, opcionalmente, isolo as CPUs mais ativas, para que as decisões do agendador se mantenham estáveis. Documento todas as alterações, incluindo as versões do kernel, dos controladores e do firmware. No caso de ajustes mais arriscados, prevejo pontos de retorno e volto a medir imediatamente após a intervenção. Desta forma, obtenho um resultado fiável Antes/Depois-Uma história que ainda consigo compreender meses depois.
Dicas práticas: comandos que utilizo frequentemente
Dependendo da questão, recorro a fórmulas concisas:
- Análise abrangente sob carga: perf top -e cpu-cycles –kernel –user
Uma visão geral rápida para saber se é o kernel ou o espaço do utilizador que dita as regras. - Foco no processo com o Callgraph: perf top -p PID -g –kernel –user
Mostra-me os percursos em tempo real da aplicação relevante, sem ruído do sistema. - Foco na CPU: perf top -C 2-5 -e ciclos da CPU -g
Ajuda a resolver pontos críticos de NUMA ou IRQ quando apenas alguns núcleos estão a “sobrecargar-se”. - Suspeita de armazenamento: perf top -e cache-misses -e cycles -g –kernel
Mostra os percursos de memória em relação aos ciclos. - Fixar picos soltos: perf top -F 999 -I 1000 -e ciclos
Uma frequência mais elevada e intervalos de exibição mais curtos permitem captar picos de curta duração.
Orientações de interpretação para subsistemas específicos
Em Rede Além do NAPI e dos percursos RX/TX, observo também as partes relacionadas com TLS/criptografia, que podem vir a dominar quando há um elevado volume de handshakes. Verifico se o Zero-Copy ou o coalescing estão a funcionar de forma eficaz e se segmentos de grande dimensão (TSO/GSO) estão a exceder os meus limites de latência. No Memória-Nesta área, analiso o THP: ajuda a minha carga ou os eventos de divisão/fusão causam interferências? No caso de Armazenamento interpreto blk_mq-Símbolos e percursos io_uring como indicação das profundidades das filas e das estratégias de fusão. No agendador Associo as avalanches de wakeup a cadeias de bloqueio ou de E/S e otimizo os percursos através da contrapressão, em vez de “mais threads”.
Limites do «perf top» e quando mudo de estratégia
Porque perf top Como se baseia em amostragem, consigo perceber melhor os padrões médios do que os eventos individuais. Para cadeias de execução determinísticas, recorro a tracepoints, ftrace ou eBPF, a fim de comprovar causalidades precisas. Se precisar de uma quantificação exata (por exemplo, instruções por pedido), combino com estatística perfeita ou análises offline a partir do «perf record/report». Se me deparar com pilhas pouco claras (símbolos em falta, desenrolamento incorreto), começo por corrigir a visibilidade – tudo o resto seria andar às cegas.
Brevemente resumido
Com perf top Consigo identificar em tempo real onde a CPU está a perder tempo no kernel e quais os símbolos que devo analisar em primeiro lugar. A partir dos valores percentuais, dos padrões recorrentes e da separação entre o espaço do kernel e o espaço do utilizador, deduzo os próximos passos a tomar. Em seguida, sintetizo as conclusões com o `perf record/report`, verifico as alterações sob carga e documento a minha cadeia de medição. Em ambientes de alojamento, esta abordagem compensa particularmente, porque muitos serviços e contentores beneficiam uns dos outros assim que os percursos do kernel funcionam de forma mais eficiente. Quem interiorizar este processo poupa dias de diagnóstico e reduz Latências e alcança tempos de resposta visivelmente mais estáveis sob carga real.
