{"id":21507,"date":"2026-09-18T08:32:17","date_gmt":"2026-09-18T06:32:17","guid":{"rendered":"https:\/\/webhosting.de\/tickless-mode-linux-kernel-rhythmus\/"},"modified":"2026-09-18T08:32:17","modified_gmt":"2026-09-18T06:32:17","slug":"modo-sem-tique-do-kernel-do-linux-ritmo","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/tickless-mode-linux-kernel-rhythmus\/","title":{"rendered":"O modo \u00abTickless\u00bb do agendador do kernel explicado: vantagens, riscos e afina\u00e7\u00e3o"},"content":{"rendered":"<p>Vou explicar o <strong>modo sem rel\u00f3gio<\/strong> do kernel do Linux de forma compreens\u00edvel e mostro em que situa\u00e7\u00f5es este influencia positivamente o desempenho, a lat\u00eancia e o consumo de energia. Para tal, apresento oportunidades claras, poss\u00edveis riscos e passos concretos de otimiza\u00e7\u00e3o que aplico com base na minha experi\u00eancia pr\u00e1tica.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Resumo os mais importantes <strong>Temas centrais<\/strong> resumido de forma concisa, para que saibas imediatamente a que deves prestar aten\u00e7\u00e3o. O agendador do Linux e o \u00abtick\u00bb din\u00e2mico interagem diretamente entre si e determinam o comportamento do teu <strong>CPUs<\/strong>. Dependendo da carga de trabalho, decido se o \u00abTickless Idle\u00bb \u00e9 suficiente ou se devo utilizar o \u00abFull Tickless\u00bb com n\u00facleos isolados. Para obter resultados reproduz\u00edveis, planeio cuidadosamente as CPUs de manuten\u00e7\u00e3o, a afinidade de IRQ e os callbacks RCU. No final, o que conta s\u00e3o os valores medidos relativos \u00e0 lat\u00eancia, energia e d\u00e9bito no teu <strong>Configura\u00e7\u00e3o<\/strong> mostrar de verdade.<\/p>\n<ul>\n  <li><strong>Marcha lenta sem tique-taque<\/strong>: menos ru\u00eddos em marcha lenta<\/li>\n  <li><strong>NO_HZ_FULL<\/strong>: n\u00facleos tranquilos e isolados<\/li>\n  <li><strong>Afinidade de IRQ<\/strong>: Agrupar fontes de interfer\u00eancia<\/li>\n  <li><strong>Fixa\u00e7\u00e3o da CPU<\/strong>: Atribuir threads de forma fixa<\/li>\n  <li><strong>Valores medidos<\/strong>: Lat\u00eancia, energia, jitter<\/li>\n<\/ul>\n<p>A lista apresenta os alavancas de regula\u00e7\u00e3o que verifico e combino em primeiro lugar. Assim, consigo identificar rapidamente onde est\u00e1 o maior <strong>Alavanca<\/strong> depende e at\u00e9 que ponto personalizo o kernel.<\/p>\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\/09\/kernel-tickless-6359.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que o \u00abtick\u00bb do kernel faz, na pr\u00e1tica<\/h2>\n\n<p>Um tick peri\u00f3dico aciona, no kernel, a medi\u00e7\u00e3o do tempo, a gest\u00e3o dos temporizadores e novas <strong>Agendamento<\/strong>-Decis\u00f5es. \u00c9 simples, mas ativa os n\u00facleos mesmo quando n\u00e3o h\u00e1 nenhum trabalho relevante \u00e0 espera. Com o \u00abTickless\u00bb, o kernel planeia o pr\u00f3ximo despertar de acordo com as necessidades e evita <strong>Interrup\u00e7\u00f5es<\/strong>. Desta forma, as CPUs permanecem mais tempo em estados C profundos e geram menos instabilidade para tarefas em que a lat\u00eancia \u00e9 cr\u00edtica. Utilizo este mecanismo para criar janelas de execu\u00e7\u00e3o tranquilas para threads sens\u00edveis.<\/p>\n\n<h2>Variantes: Vis\u00e3o geral do Tickless Idle e do NO_HZ_FULL<\/h2>\n\n<p><strong>Marcha lenta sem tique-taque<\/strong> (CONFIG_NO_HZ_IDLE) suprime o tick regular assim que uma CPU fica inativa. Isto reduz o consumo de energia e a gera\u00e7\u00e3o de calor, uma vez que o processador \u00e9 acordado do modo de hiberna\u00e7\u00e3o com menos frequ\u00eancia. <strong>NO_HZ_FULL<\/strong> continua e reduz os ticks mesmo nos n\u00facleos ativos, quando apenas uma tarefa est\u00e1 a ser executada nesses n\u00facleos. Para tal, isolo rigorosamente esses n\u00facleos e transfiro o trabalho do sistema para CPUs dedicadas \u00e0 gest\u00e3o interna. Quem implementar um isolamento eficaz consegue n\u00facleos muito silenciosos e, consequentemente, uma melhor previsibilidade sob carga.<\/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\/09\/tickless_mode_vorteile_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tabela comparativa e cen\u00e1rios de aplica\u00e7\u00e3o<\/h2>\n\n<p>A seguinte s\u00edntese ajuda-me a encontrar o mais adequado <strong>Modo<\/strong> escolher em fun\u00e7\u00e3o do objetivo e preparar corretamente o ambiente necess\u00e1rio. Primeiro, analiso as caracter\u00edsticas da carga de trabalho, depois os objetivos energ\u00e9ticos e, por fim, a toler\u00e2ncia ao jitter. Por experi\u00eancia pr\u00f3pria, um isolamento claro da CPU compensa especialmente em trading, HPC e aplica\u00e7\u00f5es com lat\u00eancia muito baixa <strong>Rede<\/strong>-Stacks. No centro de dados com carga de trabalho vari\u00e1vel, o \u00abTickless Idle\u00bb proporciona, por outro lado, frequentemente a poupan\u00e7a mais r\u00e1pida. Reservo o \u00abFull Tickless\u00bb para hosts rigorosamente controlados, nos quais isolo de forma fi\u00e1vel o trabalho do sistema.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Modo<\/th>\n      <th>Quando est\u00e1 ativo<\/th>\n      <th>Vantagem<\/th>\n      <th>Risco<\/th>\n      <th>Adequado para<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Tick peri\u00f3dico<\/td>\n      <td>Sempre, frequ\u00eancia card\u00edaca constante<\/td>\n      <td>Simples <strong>Administra\u00e7\u00e3o<\/strong><\/td>\n      <td>Mais instabilidade e despertares<\/td>\n      <td>Servidores gerais<\/td>\n    <\/tr>\n    <tr>\n      <td>Marcha lenta sem tick (NO_HZ_IDLE)<\/td>\n      <td>Apenas em marcha lenta<\/td>\n      <td>Menos energia, mais fresco <strong>CPUs<\/strong><\/td>\n      <td>Ganhos limitados em termos de lat\u00eancia<\/td>\n      <td>Hosts de VM, Web, Misto<\/td>\n    <\/tr>\n    <tr>\n      <td>Totalmente sem ticks (NO_HZ_FULL)<\/td>\n      <td>Mesmo em caso de carga de tarefa \u00fanica<\/td>\n      <td>Zonas muito tranquilas, poucas <strong>Jitter<\/strong><\/td>\n      <td>\u00c9 necess\u00e1rio um isolamento complexo<\/td>\n      <td>HPC, Negocia\u00e7\u00e3o, Pr\u00f3ximo do tempo real<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Quando o modo \u00abtickless\u00bb se destaca<\/h2>\n\n<p>Ativo o Full Tickless em n\u00facleos isolados quando uma aplica\u00e7\u00e3o \u00e9 extremamente <strong>Baixa lat\u00eancia<\/strong> tem de reagir. Entre estes incluem-se a correspond\u00eancia de ordens, o processamento de pacotes com fila \u00fanica ou a localiza\u00e7\u00e3o NUMA restrita em c\u00f3digos cient\u00edficos. No caso de objetivos energ\u00e9ticos em hosts mistos, o \u00abTickless Idle\u00bb \u00e9 frequentemente suficiente para obter melhorias mensur\u00e1veis <strong>Poupan\u00e7a<\/strong>. Quem observa muitas fases de suspens\u00e3o beneficia bastante, porque os estados C s\u00e3o abandonados com menos frequ\u00eancia devido aos ticks. N\u00e3o hesites em ler o meu guia sobre <a href=\"https:\/\/webhosting.de\/pt\/servidor-tickless-kernel-eficiencia-energetica-optimizada-verde\/\">Efici\u00eancia energ\u00e9tica com a Tickless<\/a>, se o teu objetivo principal for reduzir os custos com a eletricidade.<\/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\/09\/tickless-mode-scheduler-explained-4785.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Benef\u00edcios e efeitos secund\u00e1rios no dia a dia<\/h2>\n\n<p>Menos ticks peri\u00f3dicos significam menos <strong>Mudan\u00e7a de contexto<\/strong> e, muitas vezes, tempos de execu\u00e7\u00e3o mais uniformes. Em configura\u00e7\u00f5es de isolamento, o ru\u00eddo do sistema operativo diminui, pelo que o c\u00f3digo sens\u00edvel reage de forma mais consistente. De acordo com a Linux Foundation e a documenta\u00e7\u00e3o do kernel, a op\u00e7\u00e3o NO_HZ_IDLE proporciona ganhos significativos em modo inativo, enquanto a op\u00e7\u00e3o NO_HZ_FULL reduz ainda mais os impulsos de interfer\u00eancia. Documenta\u00e7\u00e3o sobre HPC confirma o efeito em combina\u00e7\u00e3o com o \u00abpinning\u00bb e o agrupamento de IRQ em n\u00facleos de manuten\u00e7\u00e3o. Quem configurar as medi\u00e7\u00f5es de forma adequada reconhecer\u00e1 claramente estes efeitos nos perfis de lat\u00eancia e de energia dos <strong>Anfitri\u00f5es<\/strong>.<\/p>\n\n<h2>Riscos decorrentes de uma afina\u00e7\u00e3o incorreta<\/h2>\n\n<p>Prevejo problemas se as IRQs ou os callbacks RCU acabarem por ser processados em n\u00facleos isolados e o <strong>Descanso<\/strong> destruir. Nesse caso, a vantagem perde-se, porque a carga de interfer\u00eancia surge de forma descoordenada e gera jitter. Servi\u00e7os em segundo plano n\u00e3o planeados, temporizadores ou watchdogs em CPUs isoladas t\u00eam um efeito perturbador semelhante. Tamb\u00e9m as cargas de trabalho mistas, com muitas tarefas curtas, distribuem a instabilidade de forma t\u00e3o ampla que o \u00abFull Tickless\u00bb traz poucos benef\u00edcios. Por isso, planeio claramente n\u00facleos de manuten\u00e7\u00e3o e testo cada passo com cen\u00e1rios realistas <strong>Perfis<\/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\/09\/ticless_mode_tech_buer_1593.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Op\u00e7\u00f5es essenciais do kernel explicadas de forma compreens\u00edvel<\/h2>\n\n<p>Com <strong>CONFIG_NO_HZ_IDLE<\/strong> Desativo o \u00abtick\u00bb em modo inativo e consigo ganhos r\u00e1pidos sem grandes altera\u00e7\u00f5es. <strong>CONFIG_NO_HZ_FULL<\/strong> S\u00f3 o ativo quando isolo estritamente os n\u00facleos e defino CPUs de manuten\u00e7\u00e3o limpas. O par\u00e2metro de arranque \u00abnohz_full\u00bb determina quais os n\u00facleos que funcionam sem tick; o \u00abisolcpus\u00bb desacopla-os da programa\u00e7\u00e3o geral. O \u00abrcu_nocbs\u00bb desvia os callbacks RCU desses n\u00facleos, enquanto o \u00abirqaffinity\u00bb define a responsabilidade pelas interrup\u00e7\u00f5es. S\u00f3 em conjunto \u00e9 que esta configura\u00e7\u00e3o funciona de forma constante e, por isso, realmente <strong>\u00fatil<\/strong>.<\/p>\n\n<h2>Planear os n\u00facleos de limpeza<\/h2>\n\n<p>Vou reservar um ou dois <strong>n\u00facleos<\/strong> cada n\u00f3 NUMA funciona como zona de manuten\u00e7\u00e3o para IRQs, threads do kernel e RCU. Estes n\u00facleos suportam as tarefas inevit\u00e1veis do sistema e mant\u00eam os n\u00facleos isolados livres. Para tal, atribuo deliberadamente servi\u00e7os e filas de IRQ \u00e0s CPUs de manuten\u00e7\u00e3o e bloqueio-os nos n\u00facleos silenciosos. Quem quiser <a href=\"https:\/\/webhosting.de\/pt\/servidor-agendador-de-cpu-agendamento-de-classes\/\">Classes do agendador da CPU<\/a> compreende, gere prioridades e equidade de forma fi\u00e1vel. Desta forma, os caminhos de lat\u00eancia permanecem curtos e os n\u00facleos silenciosos proporcionam um desempenho previs\u00edvel <strong>Tempos de resposta<\/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\/09\/entwicklerdesk_kernel_7123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Guia pr\u00e1tico: Passo a passo<\/h2>\n\n<p>Come\u00e7o cada projeto com um objetivo claro <strong>Linha de base<\/strong>-Run: lat\u00eancia, energia, d\u00e9bito, jitter. Em seguida, verifico se NO_HZ_IDLE est\u00e1 ativo e se o kernel suporta NO_HZ_FULL. Em seguida, atribuo a afinidade de IRQ, defino o rcu_nocbs e planeio as CPUs de manuten\u00e7\u00e3o. S\u00f3 ent\u00e3o isolo alguns n\u00facleos, a t\u00edtulo de teste, com o nohz_full e comparo os resultados. Para a an\u00e1lise detalhada, este guia ajuda-me a <a href=\"https:\/\/webhosting.de\/pt\/medir-a-latencia-do-agendador-do-linux-e-otimizar-o-desempenho\/\">Medir a lat\u00eancia<\/a>, para que eu possa avaliar cada altera\u00e7\u00e3o de forma clara.<\/p>\n\n<h2>M\u00e9todos de medi\u00e7\u00e3o e KPIs<\/h2>\n\n<p>Eu fa\u00e7o medi\u00e7\u00f5es de ponta a ponta<strong>Lat\u00eancia<\/strong> com histogramas e quantiliza\u00e7\u00e3o de valores at\u00edpicos, em vez de me limitar a considerar apenas os valores m\u00e9dios. Avalio o PPS e a lat\u00eancia de cauda em conjunto, para que os n\u00facleos inativos n\u00e3o reduzam a taxa de transfer\u00eancia. Mede a energia atrav\u00e9s do RAPL, do IPMI ou de um contador ligado e calculo a poupan\u00e7a em <strong>Euro<\/strong> por m\u00eas. Exemplo: se um host poupar 12 W em funcionamento 24 horas por dia, 7 dias por semana, a um custo de 0,30 \u20ac\/kWh, isso resulta em cerca de 3,15 \u20ac por m\u00eas por m\u00e1quina. Com 200 hosts, isso totaliza uns consider\u00e1veis 630 \u20ac por m\u00eas.<\/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\/09\/kernel-scheduler-tickless-8475.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uma an\u00e1lise mais aprofundada: como \u00e9 que o kernel desativa realmente os ticks<\/h2>\n<p>Por tr\u00e1s do \u00abTickless\u00bb est\u00e1 a transi\u00e7\u00e3o do \u00abtick\u00bb peri\u00f3dico para um <strong>Evento de rel\u00f3gio \u00fanico<\/strong>: O kernel programa o pr\u00f3ximo \u201eevento\u201c exatamente para a primeira data de vencimento de um temporizador ou de uma decis\u00e3o do agendador. Os temporizadores de alta resolu\u00e7\u00e3o (hrtimer) permitem uma granularidade fina. Num <strong>NO_HZ_FULL<\/strong>- Na CPU, o tick peri\u00f3dico do agendador \u00e9 suprimido enquanto estiver a ser executada apenas uma tarefa e n\u00e3o houver trabalho do kernel a realizar. Assim que duas ou mais tarefas estiverem execut\u00e1veis, o kernel reinicia o tick para garantir a equidade e o particionamento de tempo. \u00c9 precisamente esta din\u00e2mica que torna o sistema mais silencioso, sem comprometer a corre\u00e7\u00e3o da agendamento.<\/p>\n\n<h2>HZ, temporizador de alta resolu\u00e7\u00e3o e conta de tempo<\/h2>\n<p>A constante do kernel <strong>HZ<\/strong> (normalmente 250 ou 1000) determina a frequ\u00eancia do \u00abtick\u00bb cl\u00e1ssico. Com o \u00abTickless\u00bb, o HZ perde import\u00e2ncia pr\u00e1tica para n\u00facleos em que o tempo de execu\u00e7\u00e3o \u00e9 cr\u00edtico, mas continua a ser relevante para a l\u00f3gica baseada em \u00abjiffies\u00bb. Tamb\u00e9m \u00e9 importante a <strong>Contabiliza\u00e7\u00e3o de tempo<\/strong> (VTIME\/Context Tracking): Para que o tempo de utilizador e o tempo do sistema sejam registados corretamente, o kernel monitoriza com precis\u00e3o quando uma tarefa se encontra no kernel ou no espa\u00e7o de utilizador \u2013 sem um tick permanente. Quem trabalha muito com an\u00e1lise de desempenho deve ter isto em conta para interpretar corretamente as medi\u00e7\u00f5es.<\/p>\n\n<h2>Mecanismos de poupan\u00e7a de energia e \u00abTickless\u00bb<\/h2>\n<p>O Tickless s\u00f3 produz o seu efeito de poupan\u00e7a de energia quando a plataforma entra em modo de hiberna\u00e7\u00e3o profunda <strong>Estados C<\/strong> de forma fi\u00e1vel. Por isso, verifico as defini\u00e7\u00f5es do firmware e do kernel relacionadas com o intel_pstate\/amd-pstate, os modos Turbo e <strong>cpufreq<\/strong>-Regulador. Um regulador de desempenho agressivo pode reduzir as lat\u00eancias, mas prejudicar os objetivos energ\u00e9ticos. Por outro lado, um regulador de poupan\u00e7a de energia demasiado lento pode comprometer o rendimento. A minha abordagem: primeiro, estabilizar a configura\u00e7\u00e3o \u00abtickless\u00bb; depois, testar sistematicamente o ajuste dos estados P e C, em cada caso com perfis de carga de trabalho id\u00eanticos.<\/p>\n\n<h2>Virtualiza\u00e7\u00e3o e contentores<\/h2>\n<p>Em hosts de hipervisor, o <strong>Marcha lenta sem tique-taque<\/strong> poupan\u00e7as muitas vezes imediatamente percet\u00edveis, uma vez que as vCPUs inativas s\u00e3o ativadas com menos frequ\u00eancia. Para <strong>NO_HZ_FULL<\/strong> Isolo n\u00facleos f\u00edsicos e atribuo vCPUs \u00e0s m\u00e1quinas virtuais cr\u00edticas exatamente a esses n\u00facleos. Importante: o Steal-Time e os IRQs do anfitri\u00e3o n\u00e3o devem interferir com estes n\u00facleos. Nos sistemas convidados, o \u00abFull Tickless\u00bb s\u00f3 faz sentido se o anfitri\u00e3o disponibilizar o tempo de CPU de forma determin\u00edstica. Em ambientes de contentores, replico a l\u00f3gica de isolamento com <strong>cgroups e conjuntos de CPU<\/strong> e evito que os Systempods ou Sidecars ocupem os n\u00facleos silenciosos.<\/p>\n\n<h2>Simplificar os percursos de rede e de armazenamento<\/h2>\n<p>Para lat\u00eancias ultrabaixas, agrupo <strong>Filas de RX\/TX<\/strong> e as suas IRQs em CPUs de gest\u00e3o interna. Nos n\u00facleos menos ativos, prefiro trabalhar com polling no espa\u00e7o do utilizador ou com threads de conclus\u00e3o dedicadas, em vez de permitir IRQs. No caso do NVMe, \u00e9 poss\u00edvel <strong>Afinidade da fila de E\/S<\/strong> ajuda de forma semelhante. O NAPI-Busy-Polling pode ser utilizado de forma espec\u00edfica quando a varia\u00e7\u00e3o do polling \u00e9 mais previs\u00edvel do que a varia\u00e7\u00e3o das interrup\u00e7\u00f5es. O objetivo \u00e9 que os n\u00facleos isolados nunca sejam ativados inesperadamente por eventos externos.<\/p>\n\n<h2>Exemplo: Par\u00e2metros de arranque e fixa\u00e7\u00e3o<\/h2>\n<p>Eis como esbo\u00e7o uma configura\u00e7\u00e3o m\u00ednima (por exemplo, 16 n\u00facleos, os n\u00facleos 0-1 para tarefas de manuten\u00e7\u00e3o; os n\u00facleos 2-7 e 10-15 como candidatos a processar carga; os n\u00facleos 8-9 para servi\u00e7os do sistema):<\/p>\n<pre><code>GRUB_CMDLINE_LINUX=\"nohz_full=2-7,10-15 rcu_nocbs=2-7,10-15 isolcpus=2-7,10-15 irqaffinity=0-1\"<\/code><\/pre>\n<p>Ap\u00f3s o arranque, aplico o Affinity e os CPUsets de forma consistente:<\/p>\n<pre><code>Agrupar IRQs #\nfor i in $(grep -E 'eth0|nvme' \/proc\/interrupts | awk -F: '{print $1}'); do\n  echo 3 &gt; \/proc\/irq\/$i\/smp_affinity_list   # CPU 0-1\ndone\n\n# Fixar servi\u00e7o com lat\u00eancia cr\u00edtica\ntaskset -c 2-3 \/usr\/bin\/meu_servi\u00e7o\n\n# cgroup-cpuset para servi\u00e7os do sistema (exemplo)\nmkdir -p \/sys\/fs\/cgroup\/cpuset\/housekeeping\necho 0-1,8-9 &gt; \/sys\/fs\/cgroup\/cpuset\/housekeeping\/cpuset.cpus\necho 0 &gt; \/sys\/fs\/cgroup\/cpuset\/housekeeping\/cpuset.mems\necho $$ &gt; \/sys\/fs\/cgroup\/cpuset\/housekeeping\/cgroup.procs<\/code><\/pre>\n<p>Nas unidades do systemd, utilizo adicionalmente <strong>CPUAffinity=<\/strong> ou <strong>AllowedCPUs=<\/strong>, para que os servi\u00e7os utilizem sempre os n\u00facleos corretos.<\/p>\n\n<h2>Diagn\u00f3stico: verificar se os n\u00facleos est\u00e3o realmente silenciosos<\/h2>\n<p>Verifico o estado de repouso dos meus n\u00facleos com alguns passos simples:\n\u2013 \/proc\/interrupts: O contador aumenta em CPUs isoladas? Se sim, corrigir a afinidade de IRQ.\n\u2013 \/proc\/timer_list: Identificar temporizadores inesperados em n\u00facleos NO_HZ_FULL.\n\u2013 ftrace\/perf: Tornar vis\u00edveis os wakeups, softirqs e eventos de agendamento.\n\u2013 turbostat: Verificar os tempos de perman\u00eancia no C-State.\nSe ainda forem registados softirqs (NET_RX, TIMER) em n\u00facleos inativos, isso indica quase sempre um problema de distribui\u00e7\u00e3o ou de controlador.<\/p>\n\n<h2>Intera\u00e7\u00e3o com o PREEMPT_RT e os RT-Threads<\/h2>\n<p><strong>PREEMPT_RT<\/strong> reduz as lat\u00eancias, ao integrar a preemp\u00e7\u00e3o profundamente no kernel. Em combina\u00e7\u00e3o com NO_HZ_FULL, isto pode proporcionar resultados muito bons quando as IRQs s\u00e3o executadas como threads e permanecem estritamente em CPUs de manuten\u00e7\u00e3o. Importante: n\u00e3o espalhe os threads RT por todo o lado, mas sim fixe-os num local restrito e controle os seus percursos de mem\u00f3ria (NUMA, falhas de p\u00e1gina). Eu mantenho os threads RT em n\u00facleos isolados sempre \u201esozinhos\u201c, para que nenhum tick regresse devido ao surgimento de uma segunda tarefa execut\u00e1vel.<\/p>\n\n<h2>Quando o Full Tickless n\u00e3o compensa<\/h2>\n<p>N\u00e3o utilizo o NO_HZ_FULL quando:\n\u2013 Surgem constantemente muitas tarefas de curta dura\u00e7\u00e3o (por exemplo, picos de Fork\/Exec).\n\u2013 A carga de trabalho estiver altamente sincronizada e for\u00e7ar constantemente a troca de n\u00facleo.\n\u2013 A plataforma n\u00e3o atingir estados C limpos ou o TSC estiver inst\u00e1vel.\nNesses casos, uma execu\u00e7\u00e3o limpa <strong>Configura\u00e7\u00e3o fixa de IRQ e CPU<\/strong> muitas vezes mais do que o custo de um isolamento completo.<\/p>\n\n<h2>Aspetos espec\u00edficos da produ\u00e7\u00e3o: monitoriza\u00e7\u00e3o e opera\u00e7\u00e3o<\/h2>\n<p>Em ambientes produtivos, alerto para as altera\u00e7\u00f5es \u201einsidiosas\u201c: uma atualiza\u00e7\u00e3o do kernel, um novo agente ou uma altera\u00e7\u00e3o no mapeamento de IRQ podem perturbar o funcionamento dos n\u00facleos. Por isso, implemento:\n\u2013 Um script \u201eGuardrail\u201c que verifica a afinidade, os conjuntos de CPU e as defini\u00e7\u00f5es RCU ap\u00f3s o rein\u00edcio.\n\u2013 M\u00e9tricas relativas a despertares por segundo, perman\u00eancia em C-State e lat\u00eancia p99,9.\n\u2013 Peri\u00f3dicas <strong>Testes de regress\u00e3o<\/strong> com cargas de trabalho id\u00eanticas.\nS\u00f3 assim \u00e9 poss\u00edvel manter de forma fi\u00e1vel a vantagem do modo \u00abtickless\u00bb.<\/p>\n\n<h2>Eliminar de forma seletiva as fontes de jitter<\/h2>\n<p>Para al\u00e9m dos IRQs, s\u00e3o frequentes <strong>Temporizador no espa\u00e7o do utilizador<\/strong> (sleep\/usleep\/timerfd) para padr\u00f5es irregulares. Trabalho com <em>timer slack<\/em> (prctl ou \/proc) e agrupar as tarefas com prazos de vencimento, para que o kernel planeie menos despertares individuais. Tamb\u00e9m planeio os GC em segundo plano em ambientes de execu\u00e7\u00e3o geridos (JVM, Go) ou isolo-os em n\u00facleos de manuten\u00e7\u00e3o. O objetivo \u00e9 sempre permitir, nos n\u00facleos NO_HZ_FULL, apenas os despertares absolutamente necess\u00e1rios.<\/p>\n\n<h2>Interpreta\u00e7\u00e3o dos KPIs: tornar vis\u00edveis as compensa\u00e7\u00f5es<\/h2>\n<p>N\u00e3o avalio apenas os valores m\u00e9dios, mas sim os <strong>Distribui\u00e7\u00e3o<\/strong>: p50, p95, p99,9 e m\u00e1ximo. Um padr\u00e3o t\u00edpico de sucesso: a lat\u00eancia de cauda diminui significativamente, a taxa de transfer\u00eancia m\u00e9dia mant\u00e9m-se igual ou aumenta ligeiramente e o tempo de perman\u00eancia no C-State diminui. Se, por outro lado, observar um jitter melhorado, mas uma taxa de transfer\u00eancia visivelmente menor, ajusto a pol\u00edtica de frequ\u00eancia da CPU ou aumentei cuidadosamente o n\u00famero de n\u00facleos inativos, para que as filas n\u00e3o fiquem congestionadas.<\/p>\n\n<h2>Lista de verifica\u00e7\u00e3o antes de ativar o NO_HZ_FULL<\/h2>\n<p>\n\u2013 Funcionalidades do kernel: CONFIG_NO_HZ_FULL, temporizador de alta resolu\u00e7\u00e3o ativado<br\/>\n\u2013 Fun\u00e7\u00f5es claras da CPU: CPUs de manuten\u00e7\u00e3o definidas por n\u00f3 NUMA<br\/>\n\u2013 Descarregamento de IRQ e RCU: as op\u00e7\u00f5es \u00abirqaffinity\u00bb e \u00abrcu_nocbs\u00bb foram definidas de forma consistente<br\/>\n\u2013 Coloca\u00e7\u00e3o de servi\u00e7os: documenta\u00e7\u00e3o e testes do \u00abpinning\u00bb do systemd\/cgroups<br\/>\n\u2013 Configura\u00e7\u00e3o da medi\u00e7\u00e3o: cargas de trabalho reproduz\u00edveis, KPIs significativos, compara\u00e7\u00e3o <em>antes\/depois<\/em><br\/>\n\u2013 Plano de revers\u00e3o: entrada de arranque dispon\u00edvel sem NO_HZ_FULL\n<\/p>\n\n<h2>Dificuldades frequentes e solu\u00e7\u00f5es<\/h2>\n\n<p>Vejo frequentemente que os servi\u00e7os do sistema s\u00e3o executados em n\u00facleos isolados e que o <strong>Isolamento<\/strong> minimizar. Para isso, o systemd-Affinity, os cgroups-CPUsets e uma documenta\u00e7\u00e3o clara dos servi\u00e7os s\u00e3o \u00fateis. Tamb\u00e9m os erros de localiza\u00e7\u00e3o NUMA levam a acessos remotos desnecess\u00e1rios e picos de lat\u00eancia. Associo a mem\u00f3ria e os threads estritamente ao respetivo n\u00f3, para que os caminhos sejam curtos e consistentes <strong>ficar<\/strong>. A distribui\u00e7\u00e3o pouco clara de IRQs \u00e9 o terceiro problema cl\u00e1ssico; por isso, agrupo as filas com elevado tr\u00e1fego nas CPUs de manuten\u00e7\u00e3o.<\/p>\n\n<h2>Resumo pr\u00e1tico<\/h2>\n\n<p>O <strong>sem tique-taque<\/strong> O kernel reduz os ticks perturbadores, poupa energia e cria intervalos de tempo fi\u00e1veis para cargas de trabalho sens\u00edveis. Com o \u00abTickless Idle\u00bb, consigo rapidamente ganhos de efici\u00eancia; o \u00abFull Tickless\u00bb proporciona mais tranquilidade nos n\u00facleos isolados. Vejo o maior efeito quando agrupo de forma organizada as IRQs, o RCU e o trabalho em segundo plano nas CPUs de manuten\u00e7\u00e3o. Sem medi\u00e7\u00f5es, n\u00e3o h\u00e1 resultado: a lat\u00eancia, o jitter, o consumo de energia e o d\u00e9bito indicam-me se o ajuste est\u00e1 a surtir efeito. \u00c9 assim que utilizo o modo \u00abtickless\u00bb de forma direcionada e tiro o m\u00e1ximo partido do <strong>agendador<\/strong> fora.<\/p>","protected":false},"excerpt":{"rendered":"<p>O kernel \u00abtickless\u00bb explicado de forma simples: vantagens, riscos e otimiza\u00e7\u00e3o do kernel para servidores, HPC e sistemas de baixa lat\u00eancia.<\/p>","protected":false},"author":1,"featured_media":21500,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21507","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"62","_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":"tickless mode","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":"21500","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21507","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=21507"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21507\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21500"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21507"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21507"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21507"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}