{"id":20778,"date":"2026-08-18T18:23:16","date_gmt":"2026-08-18T16:23:16","guid":{"rendered":"https:\/\/webhosting.de\/linux-scheduler-latenz-messen-und-optimieren-performance\/"},"modified":"2026-08-18T18:23:16","modified_gmt":"2026-08-18T16:23:16","slug":"medir-a-latencia-do-agendador-do-linux-e-otimizar-o-desempenho","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-scheduler-latenz-messen-und-optimieren-performance\/","title":{"rendered":"Medir e otimizar a lat\u00eancia do agendador do Linux para um melhor desempenho do kernel"},"content":{"rendered":"<p>Medei a lat\u00eancia do <strong>Agendador do Linux<\/strong> de forma direcionada, analiso os valores at\u00edpicos e otimizo os par\u00e2metros at\u00e9 que as cargas de trabalho interativas e em tempo real respondam de forma fi\u00e1vel. Desta forma, reduzo sistematicamente a lat\u00eancia do agendador e aumente o <strong>Desempenho do kernel<\/strong> sem voar \u00e0s cegas.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>M\u00e9todos de medi\u00e7\u00e3o<\/strong>: perf sched, eBPF runqlat, schedstat e cyclictest proporcionam uma vis\u00e3o completa.<\/li>\n  <li><strong>Na pior das hip\u00f3teses<\/strong>: Os valores at\u00edpicos dominam a experi\u00eancia do utilizador e os prazos em tempo real.<\/li>\n  <li><strong>Par\u00e2metros CFS<\/strong>: O `sched_latency_ns` e as faixas de tempo determinam os tempos de resposta.<\/li>\n  <li><strong>Pol\u00edticas<\/strong>: As pol\u00edticas SCHED_FIFO\/RR\/DEADLINE d\u00e3o prioridade \u00e0s threads cr\u00edticas.<\/li>\n  <li><strong>Isolamento<\/strong>: A fixa\u00e7\u00e3o da CPU e o ajuste das IRQ estabilizam as lat\u00eancias.<\/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\/linux-performance-2349.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que significa \u00ablat\u00eancia do agendador\u00bb no kernel<\/h2>\n\n<p>Defino a lat\u00eancia do agendador como o tempo que decorre entre o <strong>Despertar<\/strong> de uma tarefa e o momento em que o seu c\u00f3digo \u00e9 executado ap\u00f3s a mudan\u00e7a de contexto. Uma interrup\u00e7\u00e3o encerra uma fase de espera de E\/S, o manipulador marca o thread como execut\u00e1vel, o agendador faz a sele\u00e7\u00e3o e inicia a mudan\u00e7a. Para sistemas interativos, cada microsegundo conta, mas no dia a dia \u00e9 sobretudo a <strong>Na pior das hip\u00f3teses<\/strong>-A lat\u00eancia afeta a perce\u00e7\u00e3o. Algumas centenas de milissegundos prejudicam o funcionamento, mesmo que o valor m\u00e9dio pare\u00e7a bom. \u00c9 precisamente por isso que analiso toda a cadeia no kernel, mas concentro-me na sec\u00e7\u00e3o entre o \u00abwakeup\u00bb e a entrada na CPU.<\/p>\n\n<h2>Por que \u00e9 que a lat\u00eancia no pior cen\u00e1rio \u00e9 importante<\/h2>\n\n<p>N\u00e3o avalio apenas os valores m\u00e9dios, porque uma m\u00e9dia baixa pode <strong>Dicas<\/strong> pode mascarar. O \u00e1udio fica distorcido quando picos espor\u00e1dicos esgotam as mem\u00f3rias tamp\u00e3o, e as transa\u00e7\u00f5es perdem o timing quando os prazos s\u00e3o ultrapassados. Para computadores de secret\u00e1ria, servidores e aplica\u00e7\u00f5es em tempo real, aplica-se o seguinte: alguns valores at\u00edpicos determinam o <strong>Capacidade de resposta<\/strong> mais do que milhares de boas amostras. Por isso, procuro distribui\u00e7\u00f5es estreitas e valores de jitter controlados. S\u00f3 quando os valores m\u00e1ximos diminuem \u00e9 que se obt\u00e9m um fluxo suave e previs\u00edvel.<\/p>\n\n<h2>Medir a lat\u00eancia do agendador: ferramentas e procedimento<\/h2>\n\n<p>Come\u00e7o por <strong>perfeito<\/strong> e registo eventos do agendador espec\u00edficos da carga de trabalho: \u201eperf sched record\u201c recolhe dados, \u201eperf sched latency\u201c organiza-os por tarefa e \u201eperf sched timehist\u201c apresenta eventos com marcas temporais. Assim, consigo ver o tempo de espera desde o \u201esched-out\u201c at\u00e9 ao \u201esched-in\u201c, o atraso entre o despertar e a execu\u00e7\u00e3o efetiva, bem como o tempo de execu\u00e7\u00e3o puro. Para uma an\u00e1lise detalhada da CPU, combino isto com este guia: <a href=\"https:\/\/webhosting.de\/pt\/ferramenta-perf-do-linux-analise-de-gargalos-da-cpu-otimizacao-carga-do-servidor-analise-de-desempenho\/\">perf para gargalos da CPU<\/a>. Esta perspetiva permite identificar pontos de estrangulamento e determinar se a causa reside em conten\u00e7\u00f5es, prioridades ou sobrecargas.<\/p>\n\n<p>Com o eBPF, medo os tempos de espera de execu\u00e7\u00e3o diretamente na <strong>Runqueue<\/strong>. O habitual \u201erunqlat\u201c gera histogramas em intervalos de nanossegundos, o que me permite identificar zonas t\u00edpicas e picos raros. Estas distribui\u00e7\u00f5es reagem de forma percet\u00edvel ao isolamento da CPU ou a altera\u00e7\u00f5es de pol\u00edtica, fornecendo assim provas concretas para as etapas de afina\u00e7\u00e3o. Repito as medi\u00e7\u00f5es antes e depois das altera\u00e7\u00f5es, at\u00e9 que os picos desapare\u00e7am. S\u00f3 ent\u00e3o considero o resultado satisfat\u00f3rio.<\/p>\n\n<p>Para tarefas individuais, recorro a \u201e\/proc\/\/schedstat\u201c e comparo as percentagens de tempo de execu\u00e7\u00e3o da CPU, <strong>Runqueue<\/strong>-Tempo de espera e fases de suspens\u00e3o. Ao serem lidos em intervalos, obt\u00eam-se valores como a percentagem de CPU, a percentagem de lat\u00eancia e a percentagem de suspens\u00e3o. Assim, consigo perceber rapidamente se o processo est\u00e1 a lutar por tempo de CPU ou se est\u00e1 bloqueado devido a restri\u00e7\u00f5es de E\/S. Esta clareza evita otimiza\u00e7\u00f5es erradas que atuem no fator errado. Como teste adicional, utilizo o `cyclictest` com prioridade elevada para documentar o jitter e os valores m\u00e1ximos.<\/p>\n\n<h2>Ler e interpretar os valores medidos<\/h2>\n\n<p>Primeiro, avalio os valores medidos de forma qualitativa: onde se verificam tempos de espera mais frequentes e quais s\u00e3o os threads que aparecem repetidamente com <strong>Picos<\/strong> . Em seguida, verifico se est\u00e3o relacionados com limites da CPU, conflitos de pol\u00edticas ou picos de interrup\u00e7\u00f5es. Mantenho o tempo de amostragem suficientemente longo para captar eventos raros, mas suficientemente curto para analisar as altera\u00e7\u00f5es de forma isolada. Valores na ordem das microssegundos s\u00e3o adequados no dia-a-dia, mas as cargas de trabalho em tempo real exigem, por vezes, intervalos ainda mais restritos. O que importa \u00e9: a lat\u00eancia m\u00e1xima diminui de forma fi\u00e1vel e o jitter torna-se mais reduzido.<\/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\/linuxscheduler_9374.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Par\u00e2metros do agendador do Linux que influenciam a lat\u00eancia<\/h2>\n\n<p>Come\u00e7o por ajustar a lat\u00eancia-alvo \u201esched_latency_ns\u201c, que determina em que intervalo de tempo todas as tarefas prontas para execu\u00e7\u00e3o <strong>CPU<\/strong>-Tempo. Em muitos processos, o intervalo de tempo por tarefa diminui; em alguns, aumenta, o que garante a equidade, mas pode alterar os tempos de resposta. Para aplica\u00e7\u00f5es interativas, reduzo moderadamente esse valor, a fim de promover respostas r\u00e1pidas, mas fico atento \u00e0 sobrecarga. O CFS distribui os tempos de forma justa, mas as cargas de trabalho com threads cr\u00edticos beneficiam de prioridades claras. Resumo aqui os princ\u00edpios b\u00e1sicos da programa\u00e7\u00e3o justa no contexto da hospedagem: <a href=\"https:\/\/webhosting.de\/pt\/cfs-scheduler-agendamento-equitativo-alojamento\/\">Compreender o CFS-Scheduler<\/a>.<\/p>\n\n<p>Para al\u00e9m da lat\u00eancia e dos quanta, a granularidade do despertar e a l\u00f3gica de migra\u00e7\u00e3o influenciam <strong>Dicas<\/strong>. As migra\u00e7\u00f5es demasiado agressivas prejudicam a localidade da cache e, indiretamente, prolongam os tempos de espera. Reduzo as migra\u00e7\u00f5es desnecess\u00e1rias, fixo os \u00abhot threads\u00bb e mantenho os dados pr\u00f3ximos dos seus n\u00facleos. Em ambientes NUMA, isto aplica-se duplamente, porque as dist\u00e2ncias de mem\u00f3ria aumentam as lat\u00eancias. O objetivo continua a ser um ambiente de agendamento est\u00e1vel e previs\u00edvel.<\/p>\n\n<h2>Utilizar de forma inteligente as pol\u00edticas, as prioridades e os prazos<\/h2>\n\n<p>Atribuo aos t\u00f3picos cr\u00edticos <strong>SCHED_FIFO<\/strong> ou prioridade SCHED_RR, quando a lat\u00eancia \u00e9 mais importante do que o d\u00e9bito. Com SCHED_DEADLINE, posso atribuir recursos com precis\u00e3o em termos de per\u00edodos, tempo de execu\u00e7\u00e3o e prazo, o que garante o cumprimento de prazos r\u00edgidos. Utilizo essas pol\u00edticas com modera\u00e7\u00e3o, para que o sistema n\u00e3o fique sem recursos. Calibro as prioridades at\u00e9 que apenas os percursos verdadeiramente essenciais sejam aprovados. Pode encontrar aqui uma introdu\u00e7\u00e3o pr\u00e1tica \u00e0s prioridades: <a href=\"https:\/\/webhosting.de\/pt\/escalonamento-de-processos-no-servidor-prioridades-otimizacao-serverboost\/\">Prioridades do processo<\/a>.<\/p>\n\n<p>Verifico regularmente se existem conflitos de pol\u00edticas, por exemplo, quando as tarefas em segundo plano consomem mais <strong>Prio<\/strong> recebidos como threads de intera\u00e7\u00e3o. Os par\u00e2metros de prazo tamb\u00e9m precisam de um dimensionamento adequado; caso contr\u00e1rio, surgem novos congestionamentos. Os testes com cargas de trabalho reais garantem a escolha correta. Documento cada altera\u00e7\u00e3o e fa\u00e7o medi\u00e7\u00f5es de acompanhamento, para que os efeitos permane\u00e7am rastre\u00e1veis. Desta forma, evito efeitos indesejados durante o funcionamento.<\/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\/LinuxSchedulerOptimierung4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Isolamento da CPU, pinning e NUMA: estabilizar as lat\u00eancias<\/h2>\n\n<p>Separo os threads cr\u00edticos da carga geral, isolando CPUs dedicadas e mantendo os servi\u00e7os do sistema afastados, onde a baixa <strong>Lat\u00eancia<\/strong> \u00e9 necess\u00e1rio. O \u00abCPU-Pinning\u00bb mant\u00e9m os \u00abhot paths\u00bb em n\u00facleos fixos e protege a localidade da cache. Em configura\u00e7\u00f5es NUMA, associo os threads a bancos de mem\u00f3ria locais para evitar acessos desnecess\u00e1rios entre n\u00f3s. Estas medidas reduzem sensivelmente os efeitos de instabilidade. O benef\u00edcio \u00e9 imediatamente vis\u00edvel em histogramas eBPF mais estreitos.<\/p>\n\n<p>A distribui\u00e7\u00e3o de IRQ faz parte disso: desvio as interrup\u00e7\u00f5es perturbadoras dos n\u00facleos de lat\u00eancia, aliviando assim a carga <strong>Quente<\/strong>-Threads. O MSI-X e as afinidades ajudam a controlar com precis\u00e3o a distribui\u00e7\u00e3o. Sempre que poss\u00edvel, utilizo IRQs multithread para que o trabalho do ISR seja conclu\u00eddo mais rapidamente. Tudo isto cria margem para a execu\u00e7\u00e3o em situa\u00e7\u00f5es em que o tempo \u00e9 cr\u00edtico. As medi\u00e7\u00f5es com o perf e o cyclictest comprovam este efeito.<\/p>\n\n<h2>Otimizar interrup\u00e7\u00f5es, controladores e preemp\u00e7\u00e3o<\/h2>\n\n<p>Transfiro as partes que exigem muitos c\u00e1lculos do ISR para filas de trabalho a jusante, para que o agendador funcione mais rapidamente <strong>alternar<\/strong> posso. Divido as sec\u00e7\u00f5es cr\u00edticas mais longas no kernel, para que surjam pontos de preemp\u00e7\u00e3o com maior frequ\u00eancia. Desativo funcionalidades desnecess\u00e1rias do kernel e controladores pesados, caso estes aumentem as lat\u00eancias. Para aplica\u00e7\u00f5es em tempo real rigoroso, utilizo o PREEMPT_RT; para cargas de servidor mais amplas, o PREEMPT, com uma boa configura\u00e7\u00e3o, \u00e9 frequentemente suficiente. \u00c9 importante medir cuidadosamente cada ajuste, em vez de confiar em suposi\u00e7\u00f5es.<\/p>\n\n<p>Estou a verificar se as resolu\u00e7\u00f5es do temporizador e as op\u00e7\u00f5es de tick se adequam \u00e0 carga de trabalho, porque os ticks grosseiros <strong>Jitter<\/strong> podem aumentar. A isto acrescenta-se a gest\u00e3o de energia: os estados C profundos prolongam os tempos de despertar e podem provocar picos de lat\u00eancia. Com defini\u00e7\u00f5es de governador bem ajustadas, consigo encontrar um compromisso vi\u00e1vel. No final, o que conta \u00e9 a consist\u00eancia dos valores medidos, n\u00e3o o nome de uma op\u00e7\u00e3o. Uma abordagem est\u00e1vel \u00e9 prefer\u00edvel a um ajuste pontual agressivo.<\/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_scheduler_performance1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Passos pr\u00e1ticos de afina\u00e7\u00e3o com valores de exemplo<\/h2>\n\n<p>Come\u00e7o por fazer uma medi\u00e7\u00e3o de refer\u00eancia e alterei apenas um <strong>Par\u00e2metros<\/strong> por ronda, para registar a causalidade. Depois, var\u00edo o `sched_latency_ns` em pequenos incrementos, observo os valores m\u00e1ximos e o jitter e registo os efeitos. Se necess\u00e1rio, fixo threads cr\u00edticos e desloquei IRQs, volto a medir e registo os picos. Quando as pol\u00edticas se adequam, mudo de forma espec\u00edfica para FIFO\/RR ou DEADLINE. A tabela seguinte compara op\u00e7\u00f5es frequentes com os seus efeitos e efeitos secund\u00e1rios:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Op\u00e7\u00e3o\/Mec\u00e2nica<\/th>\n      <th>Impacto previsto na lat\u00eancia<\/th>\n      <th>Poss\u00edveis efeitos secund\u00e1rios<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>lat\u00eancia_ns<\/strong> baixar<\/td>\n      <td>Tempo de espera mais curto at\u00e9 \u00e0 CPU<\/td>\n      <td>Maior sobrecarga de agendamento<\/td>\n      <td>Pequenos passos, avaliar o impacto<\/td>\n    <\/tr>\n    <tr>\n      <td>Ajustar a granularidade do despertar<\/td>\n      <td>Recupera\u00e7\u00e3o mais r\u00e1pida ap\u00f3s o despertar<\/td>\n      <td>Preemp\u00e7\u00f5es mais frequentes<\/td>\n      <td>Ajustar apenas ligeiramente<\/td>\n    <\/tr>\n    <tr>\n      <td>Fixa\u00e7\u00e3o\/Isolamento da CPU<\/td>\n      <td>Mais est\u00e1veis <strong>Picos<\/strong> e menos instabilidade<\/td>\n      <td>Menor flexibilidade<\/td>\n      <td>Ter em conta as afinidades de IRQ<\/td>\n    <\/tr>\n    <tr>\n      <td>SCHED_FIFO\/RR<\/td>\n      <td>Conce\u00e7\u00e3o preferida<\/td>\n      <td>Deslocamento de outras tarefas<\/td>\n      <td>Apenas para percursos cr\u00edticos<\/td>\n    <\/tr>\n    <tr>\n      <td>PREEMPT_RT<\/td>\n      <td>Baixa lat\u00eancia no pior cen\u00e1rio<\/td>\n      <td>Mais mudan\u00e7as de contexto<\/td>\n      <td>S\u00e3o necess\u00e1rios controladores compat\u00edveis com RT<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Valido as altera\u00e7\u00f5es com o perf timehist e os histogramas eBPF at\u00e9 que a <strong>Distribui\u00e7\u00e3o<\/strong> de forma restrita e mantendo o valor m\u00e1ximo conservador. Se os efeitos forem contradit\u00f3rios, recuo um passo e experimento uma combina\u00e7\u00e3o alternativa. Cada ambiente reage de forma ligeiramente diferente, pelo que \u00e9 importante experimentar com cuidado. Com testes de desempenho consistentes, demonstro objetivamente os benef\u00edcios. \u00c9 assim que se cria um processo de afina\u00e7\u00e3o repet\u00edvel.<\/p>\n\n<h2>Contexto de alojamento e servidores: reduzir eficazmente a lat\u00eancia<\/h2>\n\n<p>No contexto do alojamento web, um ajuste preciso do agendador reduz os tempos de resposta para aplica\u00e7\u00f5es web e <strong>BD<\/strong>-Solicita\u00e7\u00f5es. Muitos processos simult\u00e2neos beneficiam-se quando os tempos de espera na fila de execu\u00e7\u00e3o diminuem e os picos desaparecem. As pilhas de contentores e microsservi\u00e7os ganham em uniformidade assim que os servi\u00e7os cr\u00edticos recebem prioridade e proximidade \u00e0 CPU. Ao selecionar um fornecedor, deve-se ter em conta kernels atualizados, preemp\u00e7\u00e3o adequada e controlo flex\u00edvel de IRQ\/CPU. Uma menor lat\u00eancia traduz-se diretamente em receitas e numa melhor experi\u00eancia do utilizador.<\/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-performance-optimierung-4523.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Funcionalidades modernas do kernel que influenciam a lat\u00eancia<\/h2>\n\n<p>Os kernels atuais incluem mecanismos que influenciam diretamente os tempos de resposta. Nas vers\u00f5es mais recentes, o CFS passou a dispor de heur\u00edsticas aperfei\u00e7oadas para despertamentos e deslocamentos, que d\u00e3o prioridade \u00e0s cargas interativas. Atributos como um <strong>Prefer\u00eancia de vig\u00edlia-lat\u00eancia<\/strong> por t\u00f3pico, ajuda a dar prioridade mais rapidamente a caminhos importantes, sem abusar das pol\u00edticas de RT. Al\u00e9m disso, controla <strong>uclamp<\/strong> (limita\u00e7\u00e3o de utiliza\u00e7\u00e3o) a utiliza\u00e7\u00e3o m\u00ednima e m\u00e1xima da CPU, definida do ponto de vista do programador, por tarefa ou cgroup. Desta forma, imponho um limite m\u00ednimo de pot\u00eancia de processamento para threads sens\u00edveis \u00e0 lat\u00eancia, o que orienta o regulador de frequ\u00eancia e a atribui\u00e7\u00e3o a n\u00facleos ativos.<\/p>\n\n<p>Para sistemas com poucos ticks, utilizo <strong>NOHZ_FULL<\/strong> em combina\u00e7\u00e3o com CPUs dedicadas \u00e0 gest\u00e3o interna. Isto transfere as tarefas peri\u00f3dicas do kernel para fora dos n\u00facleos de lat\u00eancia. Al\u00e9m disso, alivio a carga destes n\u00facleos atrav\u00e9s de <code>rcu_nocbs<\/code>, para que os callbacks n\u00e3o os desestabilizem. Ambas as medidas reduzem as preemp\u00e7\u00f5es no momento errado e estabilizam os valores no pior dos casos.<\/p>\n\n<p>Com <strong>PSI<\/strong> (Informa\u00e7\u00f5es sobre o \u00abPressure Stall\u00bb) medo a press\u00e3o do sistema na CPU, na mem\u00f3ria e nas E\/S. Os indicadores em <code>\/proc\/pressure\/*<\/code> mostram se os threads est\u00e3o parados devido \u00e0 falta de recursos. Se o CPU-PSI aumentar paralelamente aos tempos de espera da fila de execu\u00e7\u00e3o, isso \u00e9 um ind\u00edcio claro de sobrecarga real ou de um controlo de quotas demasiado restritivo.<\/p>\n\n<h2>Cgroups, contentores e equidade: isolamento sem sobrecarga<\/h2>\n\n<p>Em ambientes de contentores, os cgroups s\u00e3o o fator determinante para uma lat\u00eancia previs\u00edvel. Eu utilizo <strong>cpu.weight<\/strong>, para regular a equidade relativa, e utilizo <strong>cpu.max<\/strong>, para limitar rigorosamente os servi\u00e7os em segundo plano que causam perturba\u00e7\u00f5es. Os servi\u00e7os cr\u00edticos n\u00e3o recebem uma quota de CPU restrita, para que n\u00e3o <em>limitar<\/em> e serem fragmentados em termos de tempo. Para garantir a proximidade com a CPU, separo os cpusets: um conjunto de n\u00facleos para intera\u00e7\u00e3o e outro para processamento em lote. Este isolamento tem um efeito mais forte do que a simples defini\u00e7\u00e3o do n\u00edvel de prioridade (nice).<\/p>\n\n<p>Em plataformas com orquestra\u00e7\u00e3o, evito que v\u00e1rios pods sens\u00edveis \u00e0 lat\u00eancia partilhem o mesmo n\u00facleo f\u00edsico. Reservo n\u00facleos <em>exclusivo<\/em> e atribuo as IRQs correspondentes de forma consistente. Mede as altera\u00e7\u00f5es na hierarquia do cgroup com o eBPF atrav\u00e9s de filtros de cgroup, para poder ver os tempos de espera na fila de execu\u00e7\u00e3o por servi\u00e7o. Assim, consigo identificar se a distribui\u00e7\u00e3o de carga ou as quotas s\u00e3o a verdadeira causa dos picos.<\/p>\n\n<h2>Virtualiza\u00e7\u00e3o e SMT: Detetar e atenuar o ru\u00eddo do anfitri\u00e3o<\/h2>\n\n<p>Nas m\u00e1quinas virtuais, presto aten\u00e7\u00e3o ao seguinte: <strong>Roubar tempo<\/strong>: Mostra quando o hipervisor retira tempo de CPU ao sistema convidado. Se o perf indicar percursos bons, mas a aplica\u00e7\u00e3o estiver a apresentar lentid\u00e3o, muitas vezes o \u00abSteal Time\u00bb \u00e9 o culpado. A solu\u00e7\u00e3o \u00e9 <em>Atribui\u00e7\u00e3o de vCPU<\/em> em pCPUs dedicadas, taxas de overcommitment reduzidas e a separa\u00e7\u00e3o dos threads de E\/S em n\u00facleos pr\u00f3prios. Para uma lat\u00eancia constante, pretendo que pCPU = vCPU; caso contr\u00e1rio, o pior cen\u00e1rio \u00e9 praticamente imposs\u00edvel de calcular.<\/p>\n\n<p>Com <strong>SMT<\/strong> (Hyper-Threading) partilho os recursos do n\u00facleo com um n\u00facleo irm\u00e3o. Por isso, direciono as rotas de lat\u00eancia para n\u00facleos cujos irm\u00e3os estejam livres, ou utilizo op\u00e7\u00f5es de agendamento de n\u00facleos que limitam as interfer\u00eancias entre n\u00facleos. Quando os objetivos s\u00e3o exigentes, desativo o SMT seletivamente para n\u00facleos cr\u00edticos. O ganho adv\u00e9m de uma menor concorr\u00eancia nas portas, caches e unidades de execu\u00e7\u00e3o.<\/p>\n\n<h2>Caminhos de armazenamento, E\/S e rede: fontes ocultas de lat\u00eancia<\/h2>\n\n<p>A lat\u00eancia do agendador parece muitas vezes ser um problema da CPU, mas, na verdade, \u00e9 <strong>Reclaim<\/strong> ou <strong>Compacta\u00e7\u00e3o<\/strong>. O \u00abReclaim\u00bb direto interrompe os threads e gera picos prolongados. Mantenho os pools de p\u00e1ginas livres suficientemente elevados e opto por um valor moderado <code>vm.swappiness<\/code>, para que os acessos \u00e0 mem\u00f3ria n\u00e3o sejam prejudicados por trocas intensas. Calibro as Transparent Huge Pages de forma defensiva: se o kernel compactar p\u00e1ginas grandes num momento inoportuno, surgem pausas; com <em>enlouquecer<\/em> Coloco os THP onde proporcionam um maior rendimento, sem interferir na intera\u00e7\u00e3o.<\/p>\n\n<p>Os intervalos de reescrita e de confirma\u00e7\u00e3o do di\u00e1rio tamb\u00e9m influenciam as intera\u00e7\u00f5es. Limites de \u00abdirty\u00bb demasiado elevados deslocam o trabalho para fases desfavor\u00e1veis; limites demasiado baixos for\u00e7am picos frequentes de \u00abflushing\u00bb. Eu dimensiono em bytes em vez de percentagens e distribuo as grava\u00e7\u00f5es, de modo a que as fases de vig\u00edlia da CPU n\u00e3o colidam com picos de E\/S.<\/p>\n\n<p>No caminho de rede, vejo <strong>SoftIRQs<\/strong>, or\u00e7amentos NAPI e agrupamento de pacotes. Um GRO demasiado agressivo reduz a sobrecarga por pacote, mas pode aumentar a lat\u00eancia interativa. Os RPS\/RFS distribuem bem a carga, mas t\u00eam de se adequar \u00e0s afinidades de IRQ e CPU. O objetivo \u00e9 que os pacotes sejam processados no local onde o thread da aplica\u00e7\u00e3o est\u00e1 a ser executado \u2013 e n\u00e3o tenham de percorrer v\u00e1rios n\u00facleos primeiro.<\/p>\n\n<h2>Equilibrar a limita\u00e7\u00e3o do RT, os prazos e os mecanismos de prote\u00e7\u00e3o<\/h2>\n\n<p>O <strong>Limita\u00e7\u00e3o de RT<\/strong> protege o sistema contra a falta de recursos, mas limita eficazmente a carga de RT a uma parte do tempo da CPU. Para obter tempos de resposta determin\u00edsticos, aumento <code>kernel.sched_rt_runtime_us<\/code> ou desativar o limite em ambientes cuidadosamente isolados. Em seguida, verifico sistematicamente se os threads que n\u00e3o s\u00e3o RT continuam a receber janelas suficientes. Igualmente importantes s\u00e3o as vari\u00e1veis globais <strong>Prazo<\/strong>-Contingentes: se forem definidos de forma demasiado restritiva, as tarefas DEADLINE n\u00e3o cumprem os seus prazos, apesar de os par\u00e2metros estarem corretos. Estou a verificar a rela\u00e7\u00e3o entre <em>tempo de execu\u00e7\u00e3o<\/em> para <em>per\u00edodo<\/em> e a soma de todas as reservas DEADLINE por CPU.<\/p>\n\n<h2>Conce\u00e7\u00e3o da medi\u00e7\u00e3o, prote\u00e7\u00e3o contra regress\u00e3o e funcionamento<\/h2>\n\n<p>Separo rigorosamente as fases de medi\u00e7\u00e3o: aquecimento, refer\u00eancia, varia\u00e7\u00e3o, verifica\u00e7\u00e3o. As caches frias distorcem os resultados; medo as fases estabilizadas e correlaciono-as com os dados de desempenho e eBPF. As compara\u00e7\u00f5es A\/B s\u00e3o realizadas com cargas de trabalho id\u00eanticas, dura\u00e7\u00e3o id\u00eantica e afinidades fixas. Escolho janelas de amostragem suficientemente amplas para que picos raros surjam estatisticamente, mas suficientemente pequenas para avaliar isoladamente cada etapa de ajuste.<\/p>\n\n<p>Para o funcionamento cont\u00ednuo, defino uma <strong>SLO<\/strong> para lat\u00eancia e jitter: cerca de 99,91% do quantil TP3T abaixo de X microsegundos com carga Y. A telemetria do PSI, as estat\u00edsticas de desempenho e os histogramas eBPF servem como indicadores; se as m\u00e9tricas ultrapassarem os limiares, volto automaticamente a utilizar perfis conservadores. Cada altera\u00e7\u00e3o recebe um registo de altera\u00e7\u00f5es com a vers\u00e3o do kernel, par\u00e2metros, m\u00e9todos de medi\u00e7\u00e3o, dados brutos e interpreta\u00e7\u00e3o. Desta forma, o ajuste permanece reprodut\u00edvel \u2013 e \u00e9 poss\u00edvel reverter a altera\u00e7\u00e3o a qualquer momento.<\/p>\n\n<ul>\n  <li>Criar linha de refer\u00eancia: perf, eBPF, schedstat, cyclictest<\/li>\n  <li>Identificar o ponto de estrangulamento: CPU, IRQ, E\/S, mem\u00f3ria, pol\u00edtica<\/li>\n  <li>Uma altera\u00e7\u00e3o por ronda: par\u00e2metros, fixa\u00e7\u00e3o, pol\u00edtica, isolamento<\/li>\n  <li>Medi\u00e7\u00e3o antes\/depois: valor m\u00e9dio, quantis 99% e 99,9%, m\u00e1ximo<\/li>\n  <li>Testar a estabilidade: execu\u00e7\u00f5es prolongadas, cargas de trabalho reais, picos de carga<\/li>\n  <li>Documentar e arquivar: perfis, valores-limite, plano de resposta a recidivas<\/li>\n<\/ul>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Mido a lat\u00eancia do agendador com <strong>perfeito<\/strong>, eBPF, schedstat e cyclictest, antes de alterar qualquer par\u00e2metro. Depois, reduzo cuidadosamente a lat\u00eancia alvo, calibro as pol\u00edticas e isolo os threads cr\u00edticos atrav\u00e9s de pinning e afinidades de IRQ. Defino os controladores, a distribui\u00e7\u00e3o de ISRs e a preemp\u00e7\u00e3o de forma a reduzir os picos no pior dos casos e a minimizar o jitter. Comprovo cada altera\u00e7\u00e3o com medi\u00e7\u00f5es repetidas, at\u00e9 que as curvas sejam convincentes. \u00c9 assim que aumento a <strong>Kernel<\/strong>- Capacidade de resposta sustent\u00e1vel e resultados fi\u00e1veis para computadores de secret\u00e1ria, servidores e cargas de trabalho em tempo real.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guia pr\u00e1tico sobre como medir e otimizar a lat\u00eancia do agendador do Linux para aumentar o desempenho do kernel. Foco: lat\u00eancia do agendador no Linux para um agendamento preciso da CPU e tempos de resposta est\u00e1veis do servidor.<\/p>","protected":false},"author":1,"featured_media":20771,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20778","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":"175","_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":"Linux Scheduler","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":"20771","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20778","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=20778"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20778\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20771"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20778"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20778"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20778"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}