{"id":20626,"date":"2026-08-14T08:35:54","date_gmt":"2026-08-14T06:35:54","guid":{"rendered":"https:\/\/webhosting.de\/perf-top-linux-hotspots-kernel-tools\/"},"modified":"2026-08-14T08:35:54","modified_gmt":"2026-08-14T06:35:54","slug":"perf-top-linux-hotspots-ferramentas-do-kernel","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/perf-top-linux-hotspots-kernel-tools\/","title":{"rendered":"perf top Linux: Detetar pontos de sobreaquecimento da CPU no kernel"},"content":{"rendered":"<p>Com <strong>perf top<\/strong> No Linux, consigo identificar em segundos quais as fun\u00e7\u00f5es do kernel que, neste momento, consomem mais tempo de CPU e onde se formam os pontos de estrangulamento. Neste guia, mostro, atrav\u00e9s de passos claros, como identifico os pontos cr\u00edticos em tempo real, interpreto a sa\u00edda de forma fi\u00e1vel e, a partir da\u00ed, deduzo otimiza\u00e7\u00f5es r\u00e1pidas para o agendador, a rede e a mem\u00f3ria.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Considero que a visualiza\u00e7\u00e3o em direto de <strong>perfeito<\/strong> \u00c9 ideal para um bom ponto de partida, porque revela imediatamente os principais fatores que consomem mais tempo. As percentagens por s\u00edmbolo mostram-me se o gargalo est\u00e1 no <strong>Kernel<\/strong> ou se est\u00e1 no espa\u00e7o do utilizador. A partir de padr\u00f5es recorrentes, deduzo se s\u00e3o os bloqueios, as IRQs, a rede ou a mem\u00f3ria que predominam. Em seguida, delimito o ponto cr\u00edtico com ferramentas mais avan\u00e7adas e verifico as altera\u00e7\u00f5es diretamente sob carga. \u00c9 assim que vou melhorando, passo a passo, o <strong>CPU<\/strong>- otimizar a utiliza\u00e7\u00e3o da capacidade e reduzir as lat\u00eancias de forma sustent\u00e1vel.<\/p>\n<ul>\n  <li><strong>Pontos de acesso em direto<\/strong> identificar e priorizar<\/li>\n  <li><strong>percentagens<\/strong> interpretar corretamente em fun\u00e7\u00e3o de cada caso<\/li>\n  <li><strong>Foco principal<\/strong> definir: IRQs, bloqueios, mem\u00f3ria<\/li>\n  <li><strong>Fluxo de trabalho<\/strong>: topo \u2192 registo \u2192 relat\u00f3rio<\/li>\n  <li><strong>Otimiza\u00e7\u00f5es<\/strong> verificar de forma espec\u00edfica<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpu-hotspots-linux-kernel-4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que \u00e9 o Perf Top e para que serve?<\/h2>\n\n<p>Eu uso <strong>perf top<\/strong>, para ver imediatamente, enquanto a carga est\u00e1 em execu\u00e7\u00e3o, quais os s\u00edmbolos 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\u00e7\u00f5es mais dispendiosas. Segundo a revista Linux-Magazin, o perf domina tanto a an\u00e1lise de desempenho como o rastreio, o que faz com que a <strong>Visualiza\u00e7\u00e3o em direto<\/strong> combina de forma harmoniosa com an\u00e1lises mais aprofundadas. No procedimento habitual, complemento o instant\u00e2neo com o \u00abperf record\u00bb e o \u00abperf report\u00bb para analisar gr\u00e1ficos de chamadas e percursos exatos. \u00c9 assim que respondo \u00e0 quest\u00e3o central: onde \u00e9 que a <strong>CPU<\/strong> exatamente o seu momento \u2013 na pilha de rede, no subsistema de mem\u00f3ria, no agendador ou num controlador?<\/p>\n\n<h2>Instalar e iniciar o perf top<\/h2>\n\n<p>Ap\u00f3s a instala\u00e7\u00e3o atrav\u00e9s do pacote de distribui\u00e7\u00e3o, executo <strong>perfeito<\/strong> O \u201etop\u201c \u00e9 normalmente executado com direitos de acesso alargados, para que os s\u00edmbolos do kernel e os eventos do sistema fiquem vis\u00edveis. Basta um simples comando \u00abperf top\u00bb para criar uma primeira visualiza\u00e7\u00e3o em tempo real e identificar as fun\u00e7\u00f5es dominantes. Se precisar de me concentrar em processos espec\u00edficos, adiciono o <strong>PID<\/strong> com a op\u00e7\u00e3o -p; para CPUs espec\u00edficas, utilizo a op\u00e7\u00e3o -C com uma lista ou um intervalo. Defino os eventos com a op\u00e7\u00e3o -e, como, por exemplo, ciclos de CPU, instru\u00e7\u00f5es ou falhas de ramifica\u00e7\u00e3o, dependendo da quest\u00e3o que pretendo esclarecer. Para obter resultados reproduz\u00edveis, inicio a medi\u00e7\u00e3o durante uma carga real, para que <strong>Pontos de acesso<\/strong> ser claramente vis\u00edveis e n\u00e3o se perderem no ru\u00eddo de fundo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpuhotspotslinux3746.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00c9 assim que interpreto corretamente esta edi\u00e7\u00e3o<\/h2>\n\n<p>Na lista, avalio primeiro o <strong>Valores percentuais<\/strong> por s\u00edmbolo, porque refletem as propor\u00e7\u00f5es relativas de tempo. Propor\u00e7\u00f5es elevadas nas fun\u00e7\u00f5es do sistema indicam um estrangulamento no kernel, enquanto s\u00edmbolos dominantes no espa\u00e7o do utilizador apontam mais para a l\u00f3gica da aplica\u00e7\u00e3o. Se observar muitas rotinas do agendador, penso em demasiados threads ativos, afinidades desfavor\u00e1veis ou prioridades inadequadas. Se aparecerem fun\u00e7\u00f5es de mem\u00f3ria no topo, verifico os padr\u00f5es de aloca\u00e7\u00e3o, as falhas de p\u00e1gina, a localidade NUMA e as caches. No caso dos percursos de rede, analiso a distribui\u00e7\u00e3o de IRQ, as configura\u00e7\u00f5es de Gro\/TSO e o comportamento dos controladores, porque esses detalhes s\u00e3o os <strong>Lat\u00eancia<\/strong> influenciar significativamente.<\/p>\n\n<h2>Causas t\u00edpicas dos pontos de congestionamento do kernel<\/h2>\n\n<p>Muitos pontos cr\u00edticos surgem porque muitos pequenos custos se somam, formando um grande <strong>Carga<\/strong> acumular. Frequentemente, as mudan\u00e7as excessivas de contexto, a concorr\u00eancia por bloqueios e a distribui\u00e7\u00e3o desigual de IRQs aumentam o tempo de CPU. Da mesma forma, estruturas de mem\u00f3ria fragmentadas, a utiliza\u00e7\u00e3o ineficiente de slabs ou o paging constante consomem ciclos desnecess\u00e1rios. Se um determinado controlador me chamar a aten\u00e7\u00e3o, estabele\u00e7o uma correla\u00e7\u00e3o com a carga de trabalho, o hardware e a vers\u00e3o, para limitar os efeitos colaterais. Em sistemas multicore, verifico tamb\u00e9m o \u00abfalse sharing\u00bb, porque, de acordo com a documenta\u00e7\u00e3o do kernel, as linhas de cache partilhadas podem rapidamente resultar em <strong>Despesas gerais<\/strong> podem causar preocupa\u00e7\u00f5es.<\/p>\n\n<h2>An\u00e1lise exemplar de um ponto cr\u00edtico<\/h2>\n\n<p>Se o Perf Top me mostrar, durante um per\u00edodo prolongado, propor\u00e7\u00f5es elevadas em fun\u00e7\u00f5es relacionadas com a rede, a primeira coisa que fa\u00e7o \u00e9 separar os tipos de carga: pacotes pequenos vs. grandes, TLS vs. texto simples, muitas liga\u00e7\u00f5es vs. poucas sess\u00f5es de longa dura\u00e7\u00e3o, para identificar a <strong>Causa<\/strong> delimitar. Em seguida, aprofundo a an\u00e1lise com o \u00abperf record\u00bb e o \u00abperf report\u00bb, ativo os gr\u00e1ficos de chamadas (-g) e comparo os percursos ao longo de v\u00e1rias execu\u00e7\u00f5es. Se, em vez disso, o problema estiver relacionado com a gest\u00e3o de mem\u00f3ria, verifico o alocador, as Huge Pages, as defini\u00e7\u00f5es do THP e a afinidade NUMA, pois \u00e9 aqui que rapidamente surgem percursos desnecess\u00e1rios. Muitas vezes, interpreto os pontos cr\u00edticos do agendador como um sinal de que h\u00e1 demasiados threads execut\u00e1veis ou de uma atribui\u00e7\u00e3o inadequada \u00e0 CPU. Altero sempre apenas um <strong>Par\u00e2metros<\/strong> por ciclo, para que eu possa atribuir corretamente o efeito.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cpu-hotspots-perf-top-7351.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O melhor em ambientes de alojamento<\/h2>\n\n<p>Em cen\u00e1rios de alojamento, vejo frequentemente como pequenos custos do kernel afetam a <strong>Lat\u00eancia<\/strong> de v\u00e1rios servi\u00e7os. Os contentores, m\u00e1quinas virtuais e inst\u00e2ncias de bases de dados em execu\u00e7\u00e3o 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\u00e1lise a vers\u00e3o 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\u00e1 neste guia sobre <a href=\"https:\/\/webhosting.de\/pt\/ferramenta-perf-do-linux-analise-de-gargalos-da-cpu-otimizacao-carga-do-servidor-analise-de-desempenho\/\">Analisar os pontos de estrangulamento da CPU<\/a> outros pontos de partida pr\u00e1ticos que utilizo regularmente na pr\u00e1tica.<\/p>\n\n<h2>Guia pr\u00e1tico para a an\u00e1lise<\/h2>\n\n<p>Come\u00e7o por um cen\u00e1rio de carga reproduz\u00edvel, para que as medi\u00e7\u00f5es se mantenham compar\u00e1veis e <strong>Pontos de acesso<\/strong> aparecer de forma est\u00e1vel. Depois, inicio o perf top e anoto os s\u00edmbolos dominantes ao longo de v\u00e1rias atualiza\u00e7\u00f5es. Condenso este instant\u00e2neo com o perf record\/report para obter uma imagem clara dos gr\u00e1ficos de chamadas, de modo a identificar o caminho at\u00e9 ao ponto mais dispendioso. Em seguida, alterei de forma espec\u00edfica apenas um aspeto, por exemplo, uma afinidade de IRQ ou a profundidade de uma fila, e voltei a medir. S\u00f3 quando o efeito ficou claro \u00e9 que passei para o pr\u00f3ximo <strong>Etapa<\/strong> analisar e documentar as conclus\u00f5es para futuras janelas de manuten\u00e7\u00e3o.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/TechOffice_Nacht_CPUs_3421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando \u00e9 que outras ferramentas s\u00e3o mais adequadas<\/h2>\n\n<p>Para uma perspetiva hist\u00f3rica, gr\u00e1ficos de chamadas mais detalhados ou cadeias de eventos espec\u00edficas, recorro a <strong>perfeito<\/strong> record\/report, ftrace ou eBPF. Os pontos de rastreio ajudam-me a analisar percursos espec\u00edficos, enquanto os programas BPF permitem-me obter m\u00e9tricas flex\u00edveis. Quando pretendo analisar mais profundamente os percursos do kernel, estes fornecem <a href=\"https:\/\/webhosting.de\/pt\/ebpf-linux-ferramentas-de-analise-monitorizacao-de-servidores-insights\/\">Ferramentas de an\u00e1lise eBPF<\/a> sinais valiosos diretamente no local do problema. Para problemas de cache e partilha, o perf-c2c e o pahole s\u00e3o \u00fateis, desde que o ponto cr\u00edtico seja claramente identificado. \u00c9 assim que passo da an\u00e1lise da visualiza\u00e7\u00e3o em tempo real para a causa, sem me perder em detalhes irrelevantes <strong>pormenores<\/strong> para perder.<\/p>\n\n<h2>Op\u00e7\u00f5es de amostragem e filtros na pr\u00e1tica<\/h2>\n\n<p>Eu passo a <strong>Amostragem<\/strong>-Aplico uma estrat\u00e9gia espec\u00edfica \u00e0 quest\u00e3o, em vez de medir tudo de forma generalizada. Em caso de picos espor\u00e1dicos, aumento a frequ\u00eancia de amostragem e reduzo os intervalos de exibi\u00e7\u00e3o para captar picos passageiros. Para focar num processo, defino -p no PID relevante; para focar na CPU, defino -C nos n\u00facleos mais ativos. Com -e, controlo o evento, por exemplo, cpu-cycles para uma an\u00e1lise abrangente ou cache-misses, se houver suspeita de problemas de mem\u00f3ria. Utilizo os gr\u00e1ficos de chamadas (-g) assim que tiver localizado aproximadamente um ponto cr\u00edtico e o <strong>Causa<\/strong> que pretenda encontrar na pilha.<\/p>\n\n<p>A tabela seguinte apresenta bot\u00f5es pr\u00e1ticos que costumo combinar no dia a dia, bem como as utiliza\u00e7\u00f5es t\u00edpicas de cada op\u00e7\u00e3o:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Op\u00e7\u00e3o<\/th>\n      <th>Efeito<\/th>\n      <th>Utiliza\u00e7\u00e3o<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>-p<\/strong> PID<\/td>\n      <td>Limita a medi\u00e7\u00e3o a um processo<\/td>\n      <td>Espec\u00edficas da aplica\u00e7\u00e3o <strong>Pontos de acesso<\/strong> delimitar<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-C<\/strong> Lista de CPUs<\/td>\n      <td>Foco em \u00e1reas-chave selecionadas<\/td>\n      <td>Verificar a distribui\u00e7\u00e3o NUMA\/IRQ<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-e<\/strong> Evento<\/td>\n      <td>Seleciona um evento de hardware ou de software<\/td>\n      <td>ciclos, instru\u00e7\u00f5es, falhas de cache<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-g<\/strong><\/td>\n      <td>Ativa a amostragem do Callgraph<\/td>\n      <td>Caminhos dispendiosos no <strong>Pilha<\/strong> Reconhecer<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>\u2013kernel\/\u2013user<\/strong><\/td>\n      <td>Filtra no espa\u00e7o do kernel ou no espa\u00e7o do utilizador<\/td>\n      <td>Separar a fonte do tempo de CPU<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>\u2013ordenar<\/strong><\/td>\n      <td>Ordenado por s\u00edmbolo, DSO, dso:symbol<\/td>\n      <td>Legibilidade da <strong>Classifica\u00e7\u00e3o<\/strong> aumentar<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Costumo testar brevemente as configura\u00e7\u00f5es antes de iniciar medi\u00e7\u00f5es mais longas, para que a <strong>Mostrar<\/strong> permane\u00e7a est\u00e1vel e n\u00e3o surjam efeitos secund\u00e1rios. Especialmente com frequ\u00eancias de amostragem elevadas, presto aten\u00e7\u00e3o \u00e0 sobrecarga, para n\u00e3o 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\u00edveis, documento todas as op\u00e7\u00f5es, incluindo as vers\u00f5es do kernel e dos controladores. Esta disciplina poupa-me muito trabalho mais tarde <strong>Tempo<\/strong> na classifica\u00e7\u00e3o das altera\u00e7\u00f5es.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpuhotspots_kernel1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interpreta\u00e7\u00e3o do subsistema: rede, mem\u00f3ria, agendador<\/h2>\n\n<p>Quando os caminhos de rede est\u00e3o no topo, verifico primeiro as afinidades de IRQ, o RSS (Receive-Side-Scaling) e os offloads como o GRO\/TSO, porque estes par\u00e2metros de ajuste s\u00e3o os <strong>Rendimento<\/strong>-Alterar o equil\u00edbrio de lat\u00eancia. Quando as fun\u00e7\u00f5es de mem\u00f3ria apresentam anomalias, analiso os padr\u00f5es de aloca\u00e7\u00e3o, as Huge Pages, as estat\u00edsticas do Slab e as taxas de falhas de p\u00e1gina. Frequentemente, associo a carga do agendador a um n\u00famero excessivo de threads, \u00e0 falta de afinidade da CPU ou a uma prioriza\u00e7\u00e3o injusta. Para eventos espec\u00edficos do kernel, defino adicionalmente pontos de rastreio ou utilizo <a href=\"https:\/\/webhosting.de\/pt\/bpftrace-detetar-mais-rapidamente-problemas-no-servidor-de-alojamento-e-realizar-o-diagnostico\/\">bpftrace no alojamento<\/a>, para confirmar hip\u00f3teses. Assim, associo a visualiza\u00e7\u00e3o em tempo real do \u00abperf top\u00bb a pontos de medi\u00e7\u00e3o mais detalhados e chego mais rapidamente ao resultado final <strong>Causa<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-kernel-hotspots-7894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Requisitos e visibilidade dos s\u00edmbolos<\/h2>\n\n<p>Portanto, isso <strong>perf top<\/strong> Ao resolver todos os s\u00edmbolos relevantes do kernel, presto aten\u00e7\u00e3o a duas coisas: as permiss\u00f5es adequadas e as informa\u00e7\u00f5es dispon\u00edveis sobre os s\u00edmbolos. Em sistemas de produ\u00e7\u00e3o, \u00e9 <em>kernel.perf_event_paranoid<\/em> muitas vezes definido num valor elevado. Para an\u00e1lises aprofundadas do kernel, reduzo temporariamente este valor ou trabalho como utilizador root com as permiss\u00f5es necess\u00e1rias (CAP_PERFMON\/CAP_SYS_ADMIN). Se os endere\u00e7os do kernel estiverem ocultos (<em>kptr_restrict<\/em>), na maioria das vezes vejo os nomes, mas n\u00e3o os endere\u00e7os brutos \u2013 isso \u00e9 suficiente para eu estabelecer prioridades. No espa\u00e7o do utilizador, instalo os pacotes de informa\u00e7\u00e3o de depura\u00e7\u00e3o correspondentes, para que o `perf top` mostre os nomes das fun\u00e7\u00f5es em vez dos deslocamentos. Isso reduz as suposi\u00e7\u00f5es e acelera a identifica\u00e7\u00e3o da causa.<\/p>\n\n<h2>Valores percentuais e armadilhas da amostragem<\/h2>\n\n<p>Interpreto os valores percentuais da lista como <strong>percentagens relativas<\/strong> das amostras medidas, e n\u00e3o como a utiliza\u00e7\u00e3o exata da CPU no dom\u00ednio do tempo. Se selecionar v\u00e1rios eventos, \u00e9 poss\u00edvel <strong>Multiplexagem<\/strong> aplicar: o Perf distribui os contadores ao longo do tempo e <em>normalizado<\/em> o gr\u00e1fico. Para obter um quadro claro, come\u00e7o por fazer uma medi\u00e7\u00e3o abrangente com ciclos de CPU ou instru\u00e7\u00f5es e, s\u00f3 mais tarde, incluo eventos especiais. Deteto picos moment\u00e2neos com uma frequ\u00eancia mais elevada (-F) e intervalos mais curtos; em sistemas est\u00e1veis, a frequ\u00eancia padr\u00e3o \u00e9 suficiente. Al\u00e9m disso, tenho em conta que <strong>Inativo<\/strong>-As fases e as altera\u00e7\u00f5es de frequ\u00eancia (Turbo, Governor) podem distorcer a perce\u00e7\u00e3o. Por isso, para medi\u00e7\u00f5es comparativas, uniformizo as defini\u00e7\u00f5es de ritmo e energia.<\/p>\n\n<h2>Callgraphs em profundidade<\/h2>\n\n<p>Quando identifico um ponto cr\u00edtico, aprofundo a an\u00e1lise atrav\u00e9s de gr\u00e1ficos de chamadas. Com <strong>-g<\/strong> e, com um m\u00e9todo de desenrolamento adequado, consigo obter o caminho para o ponto dispendioso. Os ponteiros de frame ou o desenrolamento DWARF proporcionam-me pilhas est\u00e1veis; sempre que dispon\u00edvel, utilizo o buffer de retorno suportado por hardware (LBR) para cadeias muito precisas. Aumento os buffers mmap apenas o necess\u00e1rio para manter a sobrecarga baixa. Se a pilha apresentar muitas fun\u00e7\u00f5es auxiliares, presto aten\u00e7\u00e3o a <strong>inclusive<\/strong> vs. <strong>exclusivo<\/strong> Custos: O que \u00e9 determinante \u00e9 saber se a fun\u00e7\u00e3o em si \u00e9 dispendiosa ou se apenas predomina como via de tr\u00e2nsito. Esta distin\u00e7\u00e3o poupa-me frequentemente horas na investiga\u00e7\u00e3o das causas.<\/p>\n\n<h2>Trabalhar em contentores e m\u00e1quinas virtuais<\/h2>\n\n<p>Em ambientes de contentores, verifico se a minha visualiza\u00e7\u00e3o de <strong>cgroups<\/strong> e os namespaces est\u00e3o corretos. Concentro as medi\u00e7\u00f5es nos PIDs e CPUs relevantes, para que os \u00abvizinhos barulhentos\u00bb n\u00e3o distor\u00e7am o quadro. No caso das m\u00e1quinas virtuais, verifico se a PMU virtual est\u00e1 ativada; caso contr\u00e1rio, faltam-me eventos de hardware precisos e vejo principalmente sinais de software. Reconhe\u00e7o frequentemente os anfitri\u00f5es KVM pelos s\u00edmbolos \u00e0 volta de <em>kvm_vcpu<\/em> ou <em>vmx<\/em>\/<em>svm<\/em>. Nesses cen\u00e1rios, separo claramente as an\u00e1lises do anfitri\u00e3o e do convidado, para n\u00e3o confundir causa e efeito.<\/p>\n\n<h2>Padr\u00f5es identific\u00e1veis e hip\u00f3teses r\u00e1pidas<\/h2>\n\n<p>No dia-a-dia, h\u00e1 certos padr\u00f5es que se revelaram eficazes e que verifico imediatamente:<\/p>\n<ul>\n  <li><strong>Concorr\u00eancia da Lock<\/strong>: Mergulho <em>queued_spin_lock_slowpath<\/em> ou <em>mutex_spin_on_owner<\/em> No topo, as estruturas de dados est\u00e3o demasiado amplas ou as filas de trabalho s\u00e3o demasiado restritas. Reduzo a conten\u00e7\u00e3o atrav\u00e9s do sharding, de uma granularidade de bloqueio mais precisa ou da altera\u00e7\u00e3o dos tamanhos dos lotes.<\/li>\n  <li><strong>Impress\u00e3o do agendador<\/strong>: Est\u00e3o a multiplicar-se <em>schedule()<\/em>, <em>pick_next_task_fair<\/em> ou percursos de despertar, ajusto o n\u00famero de threads, as afinidades e as prioridades. Muitas vezes, basta acalmar os threads \u201cfaladores\u201d ou definir corretamente as configura\u00e7\u00f5es da CPU.<\/li>\n  <li><strong>Softirqs de rede<\/strong>: Picos em <em>net_rx_action<\/em>, <em>napi_poll<\/em> ou as descargas de soma de verifica\u00e7\u00e3o indicam picos de tr\u00e1fego ou uma distribui\u00e7\u00e3o sub\u00f3tima de RSS e IRQ. Atribuo as IRQ aos n\u00facleos adequados e ajusto o GRO\/TSO para o perfil de d\u00e9bito\/lat\u00eancia pretendido.<\/li>\n  <li><strong>Caminhos de armazenamento<\/strong>: Muito tempo em <em>do_page_fault<\/em>, <em>copy_user_*<\/em> ou as fun\u00e7\u00f5es Slab permitem-me verificar os padr\u00f5es de aloca\u00e7\u00e3o, THP\/Huge Pages e a localidade NUMA. Uma localiza\u00e7\u00e3o incorreta acaba por custar, sem que se perceba, um grande n\u00famero de ciclos.<\/li>\n  <li><strong>RCU e temporizadores<\/strong>: Dominar <em>rcu_core<\/em> ou callbacks de temporizador, estou a rever as estrat\u00e9gias de polling e de processamento em lote dos meus servi\u00e7os, para garantir um funcionamento mais est\u00e1vel do sistema.<\/li>\n<\/ul>\n\n<h2>Aprofundar os conhecimentos sobre a rigor na medi\u00e7\u00e3o e a reprodutibilidade<\/h2>\n\n<p>Para garantir execu\u00e7\u00f5es compar\u00e1veis, mantenho constantes os fatores ambientais: regulador da CPU, estados Turbo, tarefas em segundo plano e at\u00e9 mesmo a temperatura ambiente no caso de n\u00f3s densos. Atribuo cargas de teste a n\u00facleos definidos e, opcionalmente, isolo as CPUs mais ativas, para que as decis\u00f5es do agendador se mantenham est\u00e1veis. Documento todas as altera\u00e7\u00f5es, incluindo as vers\u00f5es do kernel, dos controladores e do firmware. No caso de ajustes mais arriscados, prevejo pontos de retorno e volto a medir imediatamente ap\u00f3s a interven\u00e7\u00e3o. Desta forma, obtenho um resultado fi\u00e1vel <strong>Antes\/Depois<\/strong>-Uma hist\u00f3ria que ainda consigo compreender meses depois.<\/p>\n\n<h2>Dicas pr\u00e1ticas: comandos que utilizo frequentemente<\/h2>\n\n<p>Dependendo da quest\u00e3o, recorro a f\u00f3rmulas concisas:<\/p>\n<ul>\n  <li><strong>An\u00e1lise abrangente sob carga<\/strong>: perf top -e cpu-cycles \u2013kernel \u2013user<br\/>Uma vis\u00e3o geral r\u00e1pida para saber se \u00e9 o kernel ou o espa\u00e7o do utilizador que dita as regras.<\/li>\n  <li><strong>Foco no processo com o Callgraph<\/strong>: perf top -p PID -g \u2013kernel \u2013user<br\/>Mostra-me os percursos em tempo real da aplica\u00e7\u00e3o relevante, sem ru\u00eddo do sistema.<\/li>\n  <li><strong>Foco na CPU<\/strong>: perf top -C 2-5 -e ciclos da CPU -g<br\/>Ajuda a resolver pontos cr\u00edticos de NUMA ou IRQ quando apenas alguns n\u00facleos est\u00e3o a \u201csobrecargar-se\u201d.<\/li>\n  <li><strong>Suspeita de armazenamento<\/strong>: perf top -e cache-misses -e cycles -g \u2013kernel<br\/>Mostra os percursos de mem\u00f3ria em rela\u00e7\u00e3o aos ciclos.<\/li>\n  <li><strong>Fixar picos soltos<\/strong>: perf top -F 999 -I 1000 -e ciclos<br\/>Uma frequ\u00eancia mais elevada e intervalos de exibi\u00e7\u00e3o mais curtos permitem captar picos de curta dura\u00e7\u00e3o.<\/li>\n<\/ul>\n\n<h2>Orienta\u00e7\u00f5es de interpreta\u00e7\u00e3o para subsistemas espec\u00edficos<\/h2>\n\n<p>Em <strong>Rede<\/strong> Al\u00e9m do NAPI e dos percursos RX\/TX, observo tamb\u00e9m as partes relacionadas com TLS\/criptografia, que podem vir a dominar quando h\u00e1 um elevado volume de handshakes. Verifico se o Zero-Copy ou o coalescing est\u00e3o a funcionar de forma eficaz e se segmentos de grande dimens\u00e3o (TSO\/GSO) est\u00e3o a exceder os meus limites de lat\u00eancia. No <strong>Mem\u00f3ria<\/strong>-Nesta \u00e1rea, analiso o THP: ajuda a minha carga ou os eventos de divis\u00e3o\/fus\u00e3o causam interfer\u00eancias? No caso de <strong>Armazenamento<\/strong> interpreto <em>blk_mq<\/em>-S\u00edmbolos e percursos io_uring como indica\u00e7\u00e3o das profundidades das filas e das estrat\u00e9gias de fus\u00e3o. No <strong>agendador<\/strong> Associo as avalanches de wakeup a cadeias de bloqueio ou de E\/S e otimizo os percursos atrav\u00e9s da contrapress\u00e3o, em vez de \u201cmais threads\u201d.<\/p>\n\n<h2>Limites do \u00abperf top\u00bb e quando mudo de estrat\u00e9gia<\/h2>\n\n<p>Porque <strong>perf top<\/strong> Como se baseia em amostragem, consigo perceber melhor os padr\u00f5es m\u00e9dios do que os eventos individuais. Para cadeias de execu\u00e7\u00e3o determin\u00edsticas, recorro a tracepoints, ftrace ou eBPF, a fim de comprovar causalidades precisas. Se precisar de uma quantifica\u00e7\u00e3o exata (por exemplo, instru\u00e7\u00f5es por pedido), combino com <strong>estat\u00edstica perfeita<\/strong> ou an\u00e1lises offline a partir do \u00abperf record\/report\u00bb. Se me deparar com pilhas pouco claras (s\u00edmbolos em falta, desenrolamento incorreto), come\u00e7o por corrigir a visibilidade \u2013 tudo o resto seria andar \u00e0s cegas.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Com <strong>perf top<\/strong> Consigo identificar em tempo real onde a CPU est\u00e1 a perder tempo no kernel e quais os s\u00edmbolos que devo analisar em primeiro lugar. A partir dos valores percentuais, dos padr\u00f5es recorrentes e da separa\u00e7\u00e3o entre o espa\u00e7o do kernel e o espa\u00e7o do utilizador, deduzo os pr\u00f3ximos passos a tomar. Em seguida, sintetizo as conclus\u00f5es com o `perf record\/report`, verifico as altera\u00e7\u00f5es sob carga e documento a minha cadeia de medi\u00e7\u00e3o. Em ambientes de alojamento, esta abordagem compensa particularmente, porque muitos servi\u00e7os 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\u00f3stico e reduz <strong>Lat\u00eancias<\/strong> e alcan\u00e7a tempos de resposta visivelmente mais est\u00e1veis sob carga real.<\/p>","protected":false},"excerpt":{"rendered":"<p>O perf top Linux mostra em tempo real os pontos de maior carga da CPU no kernel. Isto permite uma r\u00e1pida an\u00e1lise do desempenho da CPU e uma an\u00e1lise precisa dos pontos de estrangulamento.<\/p>","protected":false},"author":1,"featured_media":20619,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-20626","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"148","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"perf top","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20619","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20626","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=20626"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20626\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20619"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20626"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20626"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20626"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}