Saltar para o conteúdo 
Com os tracepoints do kernel, consigo compreender os problemas de desempenho no Linux até ao nível do kernel e medir de forma específica onde se perde tempo. Utilizo estes Pontos de medição, para monitorizar os processos no agendador, na pilha de E/S e no caminho de rede – com um esforço adicional mínimo e dados de eventos claros.
Pontos centrais
Os seguintes aspetos fundamentais dão-te uma visão geral rápida do que tenho em atenção ao trabalhar com pontos de rastreio.
- Estático Os eventos fixados fornecem dados fiáveis em pontos específicos do código.
- Baixa sobrecarga torna o rastreio viável mesmo sob carga elevada.
- Um ecossistema abrangente com o ftrace, o perf, o LTTng e as ferramentas eBPF.
- Ativação seletiva e a filtragem evita o excesso de dados.
- Combinação com contadores de desempenho, mostra as cadeias de causas.
Mantenho a lista concisa e concentro-me no Prioridades da análise. Assim, não perco tempo com pormenores irrelevantes e mantenho o foco nos sinais mais importantes. Os pontos referidos orientam o meu trabalho prático, desde a primeira suspeita até à otimização verificada. Desta forma, consigo Transparência e reprodutibilidade. Continuo a basear-me nos dados e a controlar cada passo.
O que são pontos de rastreio do kernel?
Um ponto de rastreio é um ponto de instrumentação estático no código do kernel que desencadeia um evento com campos estruturados. Vejo aí, entre outras coisas, PID, carimbos de data/hora, CPU, códigos de estado ou informações de tamanho, consoante o evento. Através de macros como a TRACE_EVENT, o kernel define o local, o formato e os dados fornecidos. Estes eventos ocorrem em interfaces relevantes, como a agendamento, a E/S em bloco, os sistemas de ficheiros ou o caminho de rede. Posso ativá-los a qualquer momento, sem ter de aplicar patches ao kernel nem colocar em risco os sistemas de produção, o que me permite Planeamento da segurança ali.
Por que utilizar pontos de rastreio para medir o desempenho
Os pontos de rastreio permanecem praticamente sem custos quando inativos e só acrescentam um pequeno custo adicional quando são ativados. Mesmo com eventos ativados, normalmente registo apenas uma latência adicional na ordem das dezenas de nanossegundos – o que é suficiente para sistemas com requisitos rigorosos Objetivos de latência. Uma vez que estão firmemente integradas no kernel, posso repetir as análises de forma consistente em diferentes versões do kernel. A sua saída estruturada pode ser analisada e processada de forma fiável. Assim, obtenho fiável Medidas em vez de fragmentos de registo pouco claros.
Carimbos de data e hora, relógios e ordem cronológica
Para interpretar corretamente as latências, presto atenção à fonte de tempo utilizada. Os relógios monótonos (por exemplo, CLOCK_MONOTONIC) são mais fiáveis para medições do que o tempo real, porque as correções NTP não têm efeito retroativo. Em sistemas multicore, os buffers por CPU fornecem eventos cuja ordem está correta a nível local da CPU, mas que só podem ser comparados entre CPUs através dos carimbos de data/hora. Por isso, calibro a perspetiva: ou ordeno os eventos por CPU, ou utilizo ferramentas que sincronizam os buffers e resolvem corretamente os conflitos na linha temporal. Em caso de orçamentos muito apertados, verifico se a base TSC está estável, para que os desvios não sejam erroneamente interpretados como jitter. Assim, evito interpretações erradas quando, por exemplo, ocorrem «wakeups» na CPU 3 e mudanças de contexto na CPU 7.
Visão geral do ecossistema de rastreamento do Linux
Utilizo várias ferramentas, todas elas baseadas nos mesmos eventos de Tracepoint. O ftrace permite uma ativação rápida através do sistema de ficheiros de rastreio e é adequado para verificações pontuais com Imagem em direto. Com o perf, associo pontos de rastreio, contadores de hardware e amostragem para tornar visíveis as correlações. O LTTng suporta registos prolongados com elevada taxa de eventos e baixa sobrecarga, o que é essencial para análises aprofundadas. As ferramentas baseadas em eBPF lêem pontos de rastreio, realizam agregações no kernel e, assim, reduzem Tráfego de dados no espaço do utilizador.
Buffer circular e controlo de perdas
Por trás de cada evento ativo funciona um buffer circular por CPU. Dimensiono esses buffers de forma a amortecer os picos de carga sem que os eventos sejam descartados. São importantes os contadores de perdas e os avisos das ferramentas: No `perf`, presto atenção aos contadores de eventos perdidos; no `ftrace`, verifico as estatísticas de eventos descartados no `tracefs`. O `LTTng` também indica quando o percurso do consumidor não está a acompanhar. Se ocorrerem perdas, aumentei os buffers, aplico filtros mais rigorosos ou agrupo os dados mais cedo. Para cenários de „Flight Recorder“, utilizo instantâneos que preservam um período de tempo em torno de um gatilho. Desta forma, mantenho a qualidade dos dados elevada e evito hipóteses erradas com base em traços incompletos.
Escolha de ferramentas: ftrace, perf, LTTng, eBPF
Costumo começar com o `perf`, porque aí analiso em conjunto amostragens, valores de contagem e pontos de rastreio. Para inspeções rápidas de eventos, recorro ao `ftrace` e ativo de forma seletiva Eventos Livre. Gosto de executar sessões complexas e de longa duração com muitos processadores utilizando o LTTng, uma vez que este regista taxas elevadas de forma fiável. Se pretender fazer uma agregação prévia no kernel, utilizo rastreadores baseados em eBPF para exportar apenas métricas agregadas. Quem quiser aprofundar os seus conhecimentos sobre o perf encontrará dicas práticas no artigo sobre o ferramenta perf, o que ajuda tanto os principiantes como os avançados.
Reprodutibilidade e automatização das sessões
Registo as sessões bem-sucedidas como uma fórmula: eventos ativados, filtros, tamanhos dos buffers, taxas de amostragem e tempo de execução. Além disso, documento a versão do kernel, as versões das ferramentas, a topologia da CPU e as definições de energia, para que as medições posteriores sejam comparáveis. Desta forma, se necessário, posso repetir uma sessão sem alterações, transferi-la para outros anfitriões ou automatizá-la em pipelines de CI. Em análises mais longas, guardo os dados brutos e gerio resumos (histogramas, percentis, mapas de calor) imediatamente após a medição. Trabalho de forma iterativa: execuções curtas e específicas, avaliação, precisão das hipóteses – e nova medição. Desta forma, não me perco nos dados, mas chego a conclusões sólidas com um tempo de iteração mínimo.
Cenários de aplicação na prática
No agendador, observo as mudanças de contexto, os despertares e as interações com as filas, para identificar mudanças excessivas ou prioridades inadequadas. Na pilha de blocos, correlaciono o envio e a conclusão de pedidos com a profundidade e o tamanho das filas, o que me permite identificar Armazenamento-identifico pontos de estrangulamento. No percurso de rede, acompanho a entrada e saída de pacotes, bem como as filas, para compreender as cadeias de latência por fluxo. No que diz respeito às chamadas de sistema, analiso a frequência e a latência para identificar anomalias nos hotpaths. Se necessário, combino esta análise com contadores de hardware, para que as falhas de cache, as previsões erradas de ramificação e os eventos de E/S tenham um Cadeia de causas resultado.
Nomes concretos de eventos e interpretação dos campos
Escolho os eventos de forma a poder reconstruir completamente o percurso com poucos pontos de medição. Um conjunto básico que se tem revelado eficaz:
- Agendador: sched:sched_switch (prev/next_comm, prev_state), sched:sched_wakeup e sched:sched_wakeup_new (fonte de despertar, CPU de destino)
- E/S em bloco: block:block_rq_issue, block:block_rq_complete (setores, tamanho, dispositivo, latência via delta)
- Rede: net:net_dev_queue, net:netif_receive_skb (colocação em fila e receção), tcp:tcp_retransmit_skb (retransmissões)
- Chamadas ao sistema: syscalls:sys_enter_*, syscalls:sys_exit_* (duração por chamada, códigos de erro)
Verifico previamente os significados dos campos para garantir uma correlação correta: no campo «prev_state» identifico tarefas em suspensão e, nos campos da CPU, deteto movimentos entre sockets. No caso de eventos de rede, se estiverem disponíveis, incluo metadados de fluxo (por exemplo, portas) para agrupar as latências por ligação. Desta forma, obtenho percursos que correspondem efetivamente ao comportamento observado no serviço.
Passo a passo: da pergunta à sessão do Traces
Começo sempre com uma pergunta clara, como, por exemplo: „Por que razão os tempos de resposta aumentam nos picos de carga?“ Este passo obriga-me a identificar o Subsistema para escolher: Agendador, Rede, Bloco, Sistema de ficheiros ou Gestão de memória. Em seguida, listo os pontos de rastreio adequados com o comando „perf list“ ou no sistema de ficheiros de rastreio e anoto os campos relevantes. Configurarei a sessão, aplicarei filtros aos campos PID, CPU ou de eventos e definirei o buffer e a duração. Em seguida, executarei o cenário de carga e analisarei as distribuições de latência, as sequências e as correlações, antes de testar uma hipótese e voltar a medir a alteração, para determinar o Efeito para confirmar.
Filtragem e correlação: PIDs, TIDs, cgroups e fluxos
Os filtros precisos poupam-me tempo. Dependendo do objetivo, trabalho com filtros PID/TID, seleção de CPU ou filtros cgroup para respeitar os limites dos contentores ou dos serviços. Sempre que pretendo compreender a latência da rede, correlaciono eventos através de atributos de fluxo (por exemplo, porta de origem/destino), para separar o tráfego em massa dos fluxos sensíveis à latência. No caso dos ficheiros, organizo-os por endereço de dispositivo/bloco ou agrupo-os por ponto de montagem, dependendo da ferramenta utilizada. Na área do agendador, medo o tempo desde o despertar até ao primeiro «sched_switch» na CPU de destino; assim, consigo distinguir o tempo de espera nas filas de execução do tempo de CPU efetivo.
Gerir os custos indiretos: melhores práticas
Ativo apenas os pontos de rastreio de que realmente preciso, para manter os volumes de dados e a carga adicional ao mínimo. Os filtros por PID, CPU ou campos reduzem o ruído e poupam recursos Tampão. Ajusto o tamanho do buffer de acordo com a taxa de eventos, para não perder nenhum evento. Limito claramente a duração das sessões e só as repito quando pretendo testar uma hipótese. No caso de eventos extremamente frequentes, recorro à amostragem ou à agregação no kernel através do eBPF, para que a análise no espaço do utilizador magro restos.
Comparação: Tracepoints vs. Eventos de desempenho
Ambas as abordagens complementam-se. Os pontos de rastreio explicam eventos concretos nos subsistemas e fornecem informações significativas Campos. Os eventos de desempenho proporcionam-me uma visão estatística dos ciclos, das falhas de cache ou das ramificações. Ao analisar tudo em conjunto, consigo perceber quanto tempo se perde e em que etapa ocorre o problema. A tabela seguinte ajuda na escolha das ferramentas e centra-se no que preciso para a próxima sessão de medição. Serve-me como Lista de favoritos pelo planeamento da sessão.
| Aspeto | Pontos de rastreio | Eventos de desempenho (perf) |
|---|---|---|
| Estabilidade | Eventos estáticos em pontos do kernel, em grande parte compatíveis com as versões | Depende dos contadores de hardware e da implementação do kernel |
| Despesas gerais | Baixo, orientado por eventos | Muito baixo na amostragem |
| Foco | Eventos concretos do subsistema | Indicadores a nível do sistema |
| Formato de dados | Estruturado, legível por máquina | Valores de contagem, amostras, perfis |
| Utilização típica | „O “o quê„ e o “quando» de um percurso | „Quanto“ e „Quanto custa“ |
Gosto de começar por eventos de desempenho para localizar um gargalo geral e, em seguida, aprofundar os detalhes com pontos de rastreio. Por outro lado, ativo primeiro os pontos de rastreio quando quero compreender um percurso e, mais tarde, adiciono contadores para Quantização. Esta ordem poupa tempo e mantém a recolha de dados focada no objetivo. É importante manter-se atento à taxa de eventos, para que não se percam dados. Assim, mantenho-me a par de Disciplina de medição no bom caminho.
Limites, validação e verificações cruzadas
Nem todos os percursos do controlador estão totalmente monitorizados e algumas falhas raras não aparecem nos registos. Por isso, cruzo as medições com outras perspetivas: contadores, registos, testes sintéticos, mas também simples medições de tempo no próprio serviço. Quando os registos e os contadores não coincidem, verifico primeiro os filtros e as perdas de dados e, em seguida, a base de relógio. Presto também atenção a interferências: compilações de depuração, taxas elevadas de registo ou «security hooks» podem alterar as latências. Só através de verificações cruzadas é que confirmo com segurança que uma causa identificada é, de facto, o fator determinante para a otimização.
Exemplo: medir as latências de armazenamento
Ativo pontos de rastreio no Block-Stack para o envio e a conclusão de pedidos de E/S. Enquanto um teste de carga está a decorrer, registo os carimbos de data/hora, o tamanho do pedido, o dispositivo e o PID, para Latências tornar visíveis por cada processo. Em seguida, ordeno os resultados por duração e gerar histogramas que mostrem picos e valores atípicos. Numa segunda ronda, incluo também os contadores da CPU para verificar se existe uma relação entre a carga computacional e as latências de E/S. Por fim, ajusto o agendador de E/S, a profundidade da fila ou o backend de armazenamento e repito a medição até que a Objectivos tenham sido alcançados de forma fiável.
Exemplo: Compreender as latências do agendador e do despertar
Quando os threads apresentam um comportamento „spiky“, medo o tempo que decorre entre o «sched:sched_wakeup» e o primeiro «sched:sched_switch» na CPU de destino. É assim que separo o tempo de espera nas filas de execução do tempo de execução efetivo. Agrupo por CPU, prioridade e política (CFS/RT) para detetar anomalias — por exemplo, quando threads com elevado consumo de CPU são atribuídas a núcleos sobrecarregados, apesar de existirem núcleos livres. Se observar muitos «wakeups» entre CPUs, verifico as afinidades e a atribuição NUMA. Em combinação com os contadores Perf para falhas de LLC, comprovo se um posicionamento incorreto está a aumentar as latências da cache. Um pequeno ajuste na afinidade das threads ou nos parâmetros de agendamento traz, muitas vezes, melhorias imediatas e mensuráveis.
Dicas para ambientes produtivos
Só ativo o Tracing fora dos períodos de manutenção com filtros bem definidos e intervalos de tempo curtos. Antes disso, verifico as taxas de eventos, por exemplo, num sistema de teste, para que eu possa Tampão ajusto em conformidade. Em ambientes de produção, utilizo agregações no kernel para reduzir a carga no espaço do utilizador. Para diagnósticos rápidos e pontuais, vale a pena dar uma vista de olhos em bpftrace no alojamento, porque assim obtenho as primeiras respostas em poucos minutos. Registo imediatamente cada série de medições, para que eu Repetibilidade verdadeiro.
Segurança, direitos e limites de isolamento
O rastreamento no kernel requer as autorizações adequadas. Certifico-me de que o tracefs está montado corretamente e verifico opções a nível do sistema, como perf_event_paranoid ou kptr_restrict, que podem ocultar detalhes. Em ambientes sensíveis, limito quem pode ativar o rastreamento e estabeleço procedimentos para a sua autorização. Anonimizo nomes de processos ou endereços IP quando é necessário partilhar dados e defino regras claras de conservação para os registos de rastreamento. Nos contentores, aplica-se o seguinte: o utilizador root no contentor não está automaticamente autorizado a ler eventos do kernel do anfitrião. Por isso, prefiro efetuar o rastreio a partir do anfitrião ou trabalhar com filtros cgroup explícitos, para registar apenas a carga de trabalho alvo.
Lista de verificação e erros típicos
Primeiro defino a questão, depois os subsistemas e, por fim, os eventos – por esta ordem. Verifico se estou realmente a registar todos os campos necessários antes de iniciar a carga. Não te esqueças de definir filtros; as sessões não filtradas geram rapidamente um excesso de dados e sobrecarregam Memória. Verifico a versão do kernel, os nomes dos eventos e as opções da ferramenta, para evitar mal-entendidos. Para fluxos de trabalho eBPF mais complexos, amplio a configuração com as Ferramentas BCC, para pré-processar métricas complexas no kernel e exportar apenas sinais agregados, o que Clareza cria.
Rastreio em contentores e máquinas virtuais
Em configurações de contentores, o ideal é filtrar por cgroup para ver exatamente o serviço que me interessa. Assim, consigo efetuar medições em ambientes multi-tenant sem registar cargas de trabalho de terceiros. No caso das máquinas virtuais (VMs), vejo apenas o que acontece no kernel convidado. Os caminhos Virtio/vhost e o lado do hipervisor permanecem invisíveis sem o rastreio do anfitrião. Para latências de ponta a ponta, correlaciono, portanto, as medições do convidado e do anfitrião, quando pretendo ter ambas as áreas de influência sob controlo. Além disso, tenho em conta a sincronização temporal entre o anfitrião e o convidado, para poder sobrepor de forma significativa registos, métricas e rastreios. Com esta disciplina, as análises mantêm-se fiáveis mesmo em ambientes virtualizados.
Para levar consigo: principais lições aprendidas
Os tracepoints proporcionam-me pontos de referência estáveis no kernel e fornecem eventos estruturados sem grande sobrecarga. Utilizo-os para obter dados exatos Processos compreender, identificar pontos de estrangulamento e avaliar as alterações de forma mensurável. Com o ftrace, o perf, o LTTng e o eBPF, escolho a ferramenta adequada consoante o objetivo e combino-as, se necessário. Uma formulação clara do problema, filtros rigorosos e tamanhos de buffer adequados mantêm a carga baixa e os dados úteis. Assim, encontro as causas mais rapidamente, comprovo o efeito das minhas medidas e mantenho a Desempenho sempre sob controlo.
