{"id":18553,"date":"2026-03-30T15:05:26","date_gmt":"2026-03-30T13:05:26","guid":{"rendered":"https:\/\/webhosting.de\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/"},"modified":"2026-03-30T15:05:26","modified_gmt":"2026-03-30T13:05:26","slug":"linux-scheduler-cfs-alternative-hosting-kernelperf-boost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/","title":{"rendered":"Linux Scheduler CFS: Funcionalidade e alternativas no alojamento de servidores"},"content":{"rendered":"<p>O agendador CFS do Linux controla a forma como os n\u00facleos do servidor atribuem o seu tempo aos processos, influenciando assim diretamente a lat\u00eancia, o d\u00e9bito e a equidade no alojamento de servidores. Neste guia, explico como ele funciona, as alavancas de ajuste e alternativas \u00fateis, como ULE, BFS e EEVDF para <strong>Hospedagem<\/strong> com <strong>servidores web<\/strong>.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Equidade<\/strong> e <strong>vruntime<\/strong> determinam qual a tarefa que fica com a CPU.<\/li>\n  <li><strong>Grupos C<\/strong> regulamentar as quotas e <strong>cpu.shares<\/strong> para o isolamento do cliente.<\/li>\n  <li><strong>Afina\u00e7\u00e3o do kernel<\/strong> atrav\u00e9s de sched_latency_ns e <strong>Granularidade<\/strong>.<\/li>\n  <li><strong>Alternativas<\/strong> tais como BFS, ULE, EEVDF para <strong>Cargas de trabalho<\/strong>.<\/li>\n  <li><strong>Pr\u00e1tica<\/strong>Afinidade de n\u00facleo, planeador de E\/S e <strong>Testes<\/strong> combinar.<\/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\/03\/linux-server-cfs-9357.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como funciona a SFC no dia a dia<\/h2>\n\n<p>Com o Agendador Completamente Justo, um tempo de execu\u00e7\u00e3o virtual decide qual tarefa deve ser executada em seguida, resultando em um <strong>justo<\/strong> e previs\u00edvel <strong>Atribui\u00e7\u00e3o<\/strong> \u00e9 criado. Cada tarefa recebe tempo de CPU proporcional ao valor nice, de modo que um valor nice baixo recebe mais ac\u00e7\u00f5es. Em ambientes de hospedagem, muitas pequenas solicita\u00e7\u00f5es da Web, cronjobs e backups dividem a CPU entre eles sem que um processo ocupe tudo. As cargas de trabalho interactivas, como os pedidos NGINX, beneficiam de fatias de tempo curtas e frequentes, enquanto as tarefas em lote recebem blocos mais longos. Isto significa que os tempos de resposta permanecem fi\u00e1veis para os utilizadores, mesmo que muitos sites estejam a processar pedidos em paralelo.<\/p>\n\n<p>Utilizo Cgroups para limitar os clientes e os servi\u00e7os, porque cpu.shares e cpu.max asseguram uma <strong>Totais das ac\u00e7\u00f5es<\/strong> e duro <strong>Limites<\/strong>. Um valor padr\u00e3o de 1024 compartilhamentos para \u201cnormal\u201d e 512 para \u201cmenos importante\u201d distribui os n\u00facleos de forma compreens\u00edvel. Com cpu.max, por exemplo, defini 50ms num per\u00edodo de 100ms, o que corresponde efetivamente a 50% de quota de CPU. Essa configura\u00e7\u00e3o oferece reservas previs\u00edveis para hospedar cargas de trabalho com cargas vari\u00e1veis. Posso encontrar uma explica\u00e7\u00e3o compacta do princ\u00edpio em <a href=\"https:\/\/webhosting.de\/pt\/programacao-do-cpu-alojamento-distribuicao-justa-servidor-alojamento-recursos-optimizado\/\">distribui\u00e7\u00e3o equitativa da CPU<\/a>.<\/p>\n\n<h2>A mec\u00e2nica do SFC explicada de forma clara<\/h2>\n\n<p>No seu n\u00facleo, o CFS gere todas as tarefas prontas a executar numa \u00e1rvore vermelha\/preta, ordenada por <strong>vruntime<\/strong> e com uma eficiente <strong>Sele\u00e7\u00e3o<\/strong> do tempo de execu\u00e7\u00e3o virtual mais pequeno. Essa tarefa \u00e9 executada em seguida e aumenta seu tempo de execu\u00e7\u00e3o virtual proporcionalmente ao tempo de CPU consumido e ponderado pelo valor nice. Isso cria um equil\u00edbrio fluido sem filas dif\u00edceis, o que fornece resultados limpos, especialmente com cargas de trabalho mistas. Em sistemas com v\u00e1rios n\u00facleos, o agendador move as tarefas entre as filas de execu\u00e7\u00e3o, mas presta aten\u00e7\u00e3o \u00e0 localidade do cache por meio da afinidade de n\u00facleo. Desta forma, o CFS combina o balanceamento de carga com o menor n\u00famero poss\u00edvel de migra\u00e7\u00f5es dispendiosas.<\/p>\n\n<p>Para um ajuste fino, par\u00e2metros como sched_latency_ns e sched_min_granularity_ns definem o curso para <strong>Lat\u00eancia<\/strong> e <strong>Rendimento<\/strong>. Valores de lat\u00eancia mais pequenos favorecem os trabalhos curtos e interactivos, enquanto valores maiores refor\u00e7am os trabalhos em lote. Em testes com ferramentas como o stress-ng e o fio, verifico o efeito nos tempos de resposta e na utiliza\u00e7\u00e3o da CPU. \u00c0 medida que o n\u00famero de tarefas aumenta, tamb\u00e9m aumenta a sobrecarga administrativa da \u00e1rvore, que pode se manifestar como picos de lat\u00eancia. No entanto, quotas e limites corretamente definidos mant\u00eam estes efeitos sob controlo em ambientes de alojamento.<\/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\/03\/linux_scheduler_cfs_meeting_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pontos fortes do CFS no alojamento de servidores<\/h2>\n\n<p>A maior for\u00e7a reside na <strong>Equidade<\/strong>, de forma homog\u00e9nea e compreens\u00edvel <strong>Recursos<\/strong> distribu\u00eddos. Para ambientes partilhados, isto significa que nenhum cliente desloca permanentemente os outros porque as quotas e as partilhas definem claramente as pondera\u00e7\u00f5es. Os servi\u00e7os interactivos recebem tempos de resposta r\u00e1pidos, enquanto as c\u00f3pias de seguran\u00e7a podem ser executadas sem pressas. A defini\u00e7\u00e3o de prioridades atrav\u00e9s de valores simp\u00e1ticos completa este quadro e deixa-me espa\u00e7o para a coordena\u00e7\u00e3o em fun\u00e7\u00e3o do papel de um servi\u00e7o. O balanceamento de carga em todos os n\u00facleos permite-me fazer uma boa utiliza\u00e7\u00e3o do poder de computa\u00e7\u00e3o dispon\u00edvel sem dar demasiado espa\u00e7o a Jeff moments de threads individuais.<\/p>\n\n<p>Na pr\u00e1tica, a for\u00e7a do CFS torna-se evidente quando ocorrem picos no servidor Web e chegam muitos pedidos curtos, uma vez que o CFS atribui slots frequentes a este tipo de tarefas. Os Clean Cgroups ajudam a definir limites superiores r\u00edgidos por cliente ou contentor. As medi\u00e7\u00f5es das m\u00e9dias e percentis mostram tempos de resposta fi\u00e1veis, o que compensa no dia a dia. Esta abordagem \u00e9 particularmente \u00fatil para pilhas de aplica\u00e7\u00f5es com muitos componentes. \u00c9 precisamente aqui que a combina\u00e7\u00e3o de equidade previs\u00edvel e flexibilidade suficiente tem uma pontua\u00e7\u00e3o elevada.<\/p>\n\n<h2>Limites e obst\u00e1culos t\u00edpicos<\/h2>\n\n<p>Com um n\u00famero extremamente elevado de tarefas simult\u00e2neas, a sobrecarga das opera\u00e7\u00f5es em \u00e1rvore aumenta, o que n\u00e3o acontece com <strong>Dicas<\/strong> o <strong>Lat\u00eancia<\/strong> pode aumentar o desempenho. Em configura\u00e7\u00f5es de alojamento com muitos pedidos muito curtos, h\u00e1 por vezes mudan\u00e7as de contexto frequentes. Este comportamento de \u201cthrashing\u201d reduz a efici\u00eancia se os valores de granularidade forem escolhidos incorretamente. Menos fatias de tempo, mas mais longas, podem ajudar, desde que a interatividade seja mantida. O CFS reage de forma sens\u00edvel a quotas incorrectas, raz\u00e3o pela qual verifico constantemente os limites com testes de carga.<\/p>\n\n<p>Mesmo as cargas de trabalho favor\u00e1veis \u00e0 afinidade sofrem se as tarefas alternarem entre n\u00facleos com muita frequ\u00eancia. Um conceito de afinidade limpo mant\u00e9m as caches quentes e reduz os custos de migra\u00e7\u00e3o. Eu tamb\u00e9m gosto de vincular trabalhos em lote barulhentos aos seus pr\u00f3prios n\u00facleos, para que as solicita\u00e7\u00f5es da Web sejam executadas silenciosamente em seus n\u00facleos. Para servi\u00e7os cr\u00edticos de lat\u00eancia, vale a pena definir valores baixos de nice e uma lat\u00eancia bem ajustada. No final, o que conta \u00e9 que as medi\u00e7\u00f5es confirmam os par\u00e2metros selecionados.<\/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\/03\/linux-scheduler-cfs-server-7012.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compara\u00e7\u00e3o de alternativas: ULE, BFS e EEVDF<\/h2>\n\n<p>Para cargas de trabalho especiais, procuro alternativas para <strong>Lat\u00eancia<\/strong> ou <strong>Escalonamento<\/strong> estabelecem prioridades de forma diferente. O ULE utiliza filas de espera mais simples e obt\u00e9m resultados com menos esfor\u00e7o administrativo, o BFS d\u00e1 prioridade \u00e0 capacidade de resposta e destaca-se com poucas tarefas e o EEVDF combina uma distribui\u00e7\u00e3o equitativa com prazos. O EEVDF, em particular, promete tempos de espera mais curtos para cargas interactivas, porque o programador presta mais aten\u00e7\u00e3o ao \u201cprazo mais cedo poss\u00edvel\u201d. Para campos de servidores muito grandes, o que realmente conta no final \u00e9 qual a combina\u00e7\u00e3o de efici\u00eancia e capacidade de planeamento que realmente ganha na sua pr\u00f3pria pilha. Uma an\u00e1lise estruturada dos pontos fortes e fracos e dos campos de aplica\u00e7\u00e3o ajuda na sele\u00e7\u00e3o.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>agendador<\/th>\n      <th>Complexidade<\/th>\n      <th>Pontos fortes do alojamento<\/th>\n      <th>Pontos fracos<\/th>\n      <th>Adequado para<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>CFS<\/strong><\/td>\n      <td>Elevado<\/td>\n      <td>Distribui\u00e7\u00e3o equitativa, <strong>Grupos C<\/strong><\/td>\n      <td>Picos de lat\u00eancia<\/td>\n      <td>Alojamento partilhado, cargas mistas<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>ULE<\/strong><\/td>\n      <td>Baixa<\/td>\n      <td>Pistas simples, baixo <strong>Carga<\/strong><\/td>\n      <td>Menos isolamento<\/td>\n      <td>VMs, padr\u00f5es do tipo HPC<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>BFS<\/strong><\/td>\n      <td>M\u00e9dio<\/td>\n      <td>Interatividade, <strong>Velocidade<\/strong><\/td>\n      <td>Escalonamento fraco<\/td>\n      <td>Computadores de secret\u00e1ria, pequenos servidores<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>EEVDF<\/strong><\/td>\n      <td>M\u00e9dio<\/td>\n      <td>Baixa lat\u00eancia, <strong>prazos<\/strong><\/td>\n      <td>Ainda pouca pr\u00e1tica<\/td>\n      <td>Pilhas de alojamento modernas<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Afina\u00e7\u00e3o do kernel: passos pr\u00e1ticos para o CFS<\/h2>\n\n<p>Para o CFS, altero frequentemente sched_autogroup_enabled=0 para que nenhum grupo impl\u00edcito distor\u00e7a a imagem e o <strong>Distribui\u00e7\u00e3o da carga<\/strong> claro <strong>restos<\/strong>. Com sched_latency_ns gosto de come\u00e7ar em 20ms, o que favorece os servi\u00e7os interactivos, e ajustar sched_min_granularity_ns para domar as altera\u00e7\u00f5es de contexto. Os valores dependem do perfil: muitos pedidos web curtos precisam de um ajuste fino diferente das janelas de backup. Eu testo as altera\u00e7\u00f5es em s\u00e9rie e me\u00e7o os percentis em vez de olhar apenas para as m\u00e9dias. Isso garante que n\u00e3o apenas os valores m\u00e9dios pare\u00e7am bonitos, mas tamb\u00e9m que as longas filas diminuam.<\/p>\n\n<p>Se quiser aprofundar os par\u00e2metros sysctl, encontrar\u00e1 uma boa introdu\u00e7\u00e3o aqui: <a href=\"https:\/\/webhosting.de\/pt\/kernel-tuning-linux-sysctl-parameter-serverboost-opti\/\">ajuste do sysctl<\/a>. Tamb\u00e9m afino a distribui\u00e7\u00e3o de IRQ, o regulador da CPU e os perfis de energia para que a CPU n\u00e3o entre constantemente em estados econ\u00f3micos. Utilizo reguladores de desempenho para pilhas orientadas para a lat\u00eancia, enquanto as caixas de lote puras vivem com um controlo equilibrado. Separo claramente as fases de teste e produ\u00e7\u00e3o para que n\u00e3o haja surpresas. Ap\u00f3s cada passo, verifico os registos e as m\u00e9tricas antes de avan\u00e7ar.<\/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\/03\/linux_scheduler_cfs_tech_office_5278.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utilizar cgroups e quotas de forma sensata<\/h2>\n\n<p>Com cpu.shares eu atribuo <strong>Pesos<\/strong> enquanto cpu.max \u00e9 dif\u00edcil <strong>Limites<\/strong> conjuntos. Um cliente com 512 ac\u00e7\u00f5es obt\u00e9m metade do tempo de computa\u00e7\u00e3o que um cliente com 1024, se ambos gerarem carga ao mesmo tempo. Eu uso cpu.max para limitar os picos de forma limpa, por exemplo, 50ms em 100ms. Para trabalhos dedicados, vale a pena usar cpuset.cpus para que um servi\u00e7o utilize n\u00facleos fixos e a cache se mantenha quente. Em suma, isso resulta em uma separa\u00e7\u00e3o resiliente entre clientes e servi\u00e7os.<\/p>\n\n<p>Documento todas as altera\u00e7\u00f5es e comparo-as com os n\u00edveis de servi\u00e7o que pretendo atingir. Sem valores medidos, as quotas levam rapidamente a interpreta\u00e7\u00f5es erradas, e \u00e9 por isso que acompanho sempre os ajustes com testes de carga. Para os contentores, sugiro quotas realistas que possam lidar com os picos, mas que n\u00e3o tornem o anfitri\u00e3o mais lento. Continua a ser importante ter um or\u00e7amento de erro previs\u00edvel para que sejam detectados picos de lat\u00eancia percept\u00edveis. Se o fizer de forma consistente, evitar\u00e1 surpresas nas horas de ponta.<\/p>\n\n<h2>Pr\u00e1tica: Servidor Web e bases de dados no CFS<\/h2>\n\n<p>Os servidores Web orientados para eventos reduzem as mudan\u00e7as de contexto e harmonizam-se com o CFS, o que resulta numa constante <strong>Tempos de resposta<\/strong> e melhor <strong>Escalonamento<\/strong> gerado. Nos testes, vejo que o NGINX mant\u00e9m taxas de solicita\u00e7\u00e3o mais altas com menos jitter no mesmo hardware. Os bancos de dados reagem positivamente \u00e0 afinidade de n\u00facleos quando os trabalhos em segundo plano s\u00e3o mantidos longe dos n\u00facleos quentes. Regras simples ajudam: Web nos n\u00facleos A-B, batch nos C-D e DB nos E-F. Dessa forma, a pilha mant\u00e9m o pipeline limpo e os caches quentes.<\/p>\n\n<p>Muitos pequenos trabalhadores do PHP FPM causam demasiados switches com granularidade agressiva. Aumento ent\u00e3o a fatia de tempo m\u00ednima e verifico se os tempos de resposta permanecem est\u00e1veis. Ao mesmo tempo, eu reduzo os logs de conversa\u00e7\u00e3o para que a E\/S n\u00e3o se torne um freio. O CFS fornece a base aqui, mas o desempenho m\u00e1ximo \u00e9 alcan\u00e7ado atrav\u00e9s do ajuste fino de toda a pilha. Dessa forma, todas as engrenagens se interligam sem tirar o f\u00f4lego do host.<\/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\/03\/linux_scheduler_server_hosting_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>E\/S da mem\u00f3ria e programa\u00e7\u00e3o da CPU: a intera\u00e7\u00e3o<\/h2>\n\n<p>O agendador da CPU e o agendador de E\/S influenciam-se mutuamente, raz\u00e3o pela qual uma configura\u00e7\u00e3o harmonizada pode fazer uma diferen\u00e7a not\u00e1vel. <strong>Vantagens<\/strong> em <strong>Lat\u00eancia<\/strong> traz. Para NVMe, costumo usar Noop ou mq-deadline, enquanto em HDDs o mq-deadline atende melhor a filas longas. Se a CPU aloca tempo no tempo, mas o caminho de E\/S trava, o efeito geral \u00e9 cancelado. Por isso, verifico o agendador de E\/S em paralelo com os par\u00e2metros do CFS. Eu forne\u00e7o uma vis\u00e3o geral do Noop, mq-deadline e BFQ aqui: <a href=\"https:\/\/webhosting.de\/pt\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/\">Planeador de E\/S em compara\u00e7\u00e3o<\/a>.<\/p>\n\n<p>Para hosts de banco de dados, eu ajusto a profundidade das filas e o read-ahead para que os slots agendados pelo CFS n\u00e3o sejam perdidos devido ao bloqueio de E\/S. As caixas de servidores Web com muitos ficheiros pequenos beneficiam de baixa lat\u00eancia na pilha de E\/S. Em cen\u00e1rios de virtualiza\u00e7\u00e3o, eu confio em agendadores consistentes no host e no convidado para evitar padr\u00f5es imprevis\u00edveis. \u00c9 assim que o agendador da CPU interage com o subsistema de armazenamento. No final, o que conta \u00e9 a cadeia coerente desde o pedido at\u00e9 \u00e0 resposta.<\/p>\n\n<h2>Balanceamento de SMP, afinidade de n\u00facleos e NUMA<\/h2>\n\n<p>Direcciono as threads para n\u00facleos fixos para que <strong>Caches<\/strong> custos de aquecimento e migra\u00e7\u00e3o <strong>pequeno<\/strong> permanecer. Para hosts NUMA, eu coloco a mem\u00f3ria e a CPU juntas porque os acessos remotos \u00e0 mem\u00f3ria aumentam a lat\u00eancia. O CFS equilibra a carga entre as filas de execu\u00e7\u00e3o, mas as regras de afinidade deliberadas costumam ser mais eficazes. Servi\u00e7os com acesso frequente ao cache se beneficiam de grupos de n\u00facleo est\u00e1veis. Os trabalhos em lote podem vaguear desde que n\u00e3o interfiram com os n\u00facleos quentes.<\/p>\n\n<p>Na pr\u00e1tica, eu defino as op\u00e7\u00f5es cpuset.cpus e numactl, depois testo os tempos de solicita\u00e7\u00e3o e as taxas de falha da CPU. Quanto menos migra\u00e7\u00f5es desnecess\u00e1rias, melhor o tempo de resposta. Eu tamb\u00e9m avalio a distribui\u00e7\u00e3o de interrup\u00e7\u00f5es para que os picos de IRQs dif\u00edceis n\u00e3o obstruam um n\u00facleo. Desta forma, consigo um clocking suave das threads importantes. Esta calma compensa o desempenho geral da pilha.<\/p>\n\n<h2>Planeamento de grupos: bom, pondera\u00e7\u00e3o e hierarquias<\/h2>\n\n<p>Um obst\u00e1culo frequente no alojamento \u00e9 a <strong>Intera\u00e7\u00e3o<\/strong> entre <strong>legal<\/strong>-Prioridades e <strong>Pesos do grupo C<\/strong>. O CFS primeiro distribui de forma justa entre os grupos e depois dentro do grupo entre as tarefas. Isso significa que um processo com nice -5 ainda pode obter menos CPU do que outro com nice 0 se seu grupo (cliente\/cont\u00eainer) tiver um peso menor. Para obter resultados consistentes, primeiro defino o <em>Pesos dos grupos<\/em> e utilizar o nice apenas para afina\u00e7\u00f5es num servi\u00e7o.<\/p>\n\n<p>Na pr\u00e1tica, trabalho com alguns n\u00edveis claros (por exemplo, 512\/1024\/2048 partilhas para \u201cbaixo\/normal\/alto\u201d) e documento que servi\u00e7os est\u00e3o a ser executados em que grupo. Isso mant\u00e9m o <strong>Equidade<\/strong> rastre\u00e1veis na hierarquia. Aqueles que trabalham muito com processos de curta dura\u00e7\u00e3o (por exemplo, trabalhos CGI\/CLI) tamb\u00e9m beneficiam de <strong>baseado em grupos<\/strong> porque, de outra forma, as tarefas vol\u00e1teis contornariam involuntariamente o espartilho de grupo. Utilizo regularmente m\u00e9tricas de tempo de execu\u00e7\u00e3o para verificar se a aloca\u00e7\u00e3o interna ainda corresponde ao perfil de carga.<\/p>\n\n<h2>Contentores e orquestra\u00e7\u00e3o: pedidos, limites e estrangulamento<\/h2>\n\n<p>Em ambientes de contentor, um \u201cpedido\u201d \u00e9 normalmente mapeado para <strong>peso relativo<\/strong> (ac\u00e7\u00f5es\/peso), um \u201climite\u201d para a <strong>Quota<\/strong> (cpu.max). A intera\u00e7\u00e3o decide sobre <strong>Estrangulamento<\/strong>Se a quota for muito apertada, a CPU do contentor fica mais lenta durante o per\u00edodo - vis\u00edvel nos saltos de lat\u00eancia p95\/p99. Por isso, mantenho as quotas de forma a que as explos\u00f5es normais se enquadrem no per\u00edodo e os servi\u00e7os raramente sejam estrangulados. Quando dispon\u00edvel, eu uso um <em>Explos\u00e3o<\/em>-reserva (por exemplo, cpu.max.burst) para amortecer picos curtos sem distor\u00e7\u00f5es.<\/p>\n\n<p>\u00c9 importante n\u00e3o definir pedidos demasiado baixos: Se os pesos forem demasiado baixos, os servi\u00e7os interactivos ficar\u00e3o atr\u00e1s do ru\u00eddo do lote. Calibro os pedidos com base na carga de base medida e nos limites de seguran\u00e7a, de modo a que <strong>Or\u00e7amentos de erro<\/strong> s\u00e3o mantidos durante as horas de ponta. Para n\u00f3s multilocat\u00e1rios, tamb\u00e9m planeio n\u00facleos de buffer para que os picos de carga de contentores individuais n\u00e3o afectem os vizinhos.<\/p>\n\n<h2>M\u00e9todos de medi\u00e7\u00e3o e resolu\u00e7\u00e3o de problemas no contexto do programador<\/h2>\n\n<p>Nunca avalio a sintoniza\u00e7\u00e3o da SFC \u00e0s cegas, mas me\u00e7o-a de uma forma direcionada. Utilizo-o para ter uma vis\u00e3o geral:<\/p>\n<ul>\n  <li><strong>Comprimento da fila de espera<\/strong> por CPU (carga vs. n\u00facleos activos),<\/li>\n  <li><strong>Mudan\u00e7a de contexto<\/strong> por segundo e o n\u00famero de threads,<\/li>\n  <li><strong>Roubo de CPU<\/strong> e <strong>SoftIRQ<\/strong>-Ac\u00e7\u00f5es,<\/li>\n  <li><strong>Percentil<\/strong> dos tempos de resposta (p50\/p95\/p99),<\/li>\n  <li>Distribui\u00e7\u00e3o de <strong>vruntime<\/strong> ou lat\u00eancias de programa\u00e7\u00e3o.<\/li>\n<\/ul>\n<p>Se ocorrerem picos de lat\u00eancia, procuro primeiro <strong>Estrangulamento<\/strong> (quota esgotada), depois de <strong>Migra\u00e7\u00f5es<\/strong> (cache cold) e, finalmente, depois de <strong>Bloqueios de E\/S<\/strong> (profundidade da fila, satura\u00e7\u00e3o do armazenamento). Observo os padr\u00f5es de despertar: despertares curtos e freq\u00fcentes de muitos trabalhadores indicam granularidade muito fina ou E\/S tagarela. Uma maior propor\u00e7\u00e3o de ksoftirqd num n\u00facleo indica filas de IRQs quentes - neste caso, distribuo IRQs e ativo RPS\/XPS para que a carga da rede seja distribu\u00edda mais amplamente.<\/p>\n\n<h2>Classes em tempo real, preemp\u00e7\u00e3o e controlo de carra\u00e7as<\/h2>\n\n<p>Para al\u00e9m da SFC, existem as seguintes classes de tempo real <strong>SCHED_FIFO\/RR<\/strong>. Eles sobrep\u00f5em-se ao CFS: uma thread RT incorretamente configurada pode literalmente tirar o ar do sistema. Por isso, s\u00f3 atribuo RT-Prio de forma muito selectiva (por exemplo, para \u00e1udio\/telemetria) e defino watchdogs claros. Para o alojamento, o CFS com pesos limpos \u00e9 normalmente suficiente.<\/p>\n\n<p>Para <strong>Preemp\u00e7\u00e3o<\/strong>A escolha do modelo de preemp\u00e7\u00e3o (por exemplo, \u201cvolunt\u00e1rio\u201d vs. \u201cpreemp\u00e7\u00e3o total\/din\u00e2mica\u201d) altera a rela\u00e7\u00e3o lat\u00eancia\/rendimento. Para pilhas web eu prefiro mais preemp\u00e7\u00e3o, para hosts puramente batch menos. Optimiza\u00e7\u00f5es de ticks (<em>nohz<\/em>-modes) pode reduzir o jitter, mas deve ser usado com cautela. Em n\u00facleos isolados, eu ocasionalmente combino <em>nohz_full<\/em> e Affinity para que as threads quentes funcionem o menos perturbadas poss\u00edvel - \u00e9 importante que as cargas do sistema e IRQ n\u00e3o migrem inadvertidamente para estes n\u00facleos.<\/p>\n\n<h2>Virtualiza\u00e7\u00e3o: KVM, fixa\u00e7\u00e3o de vCPU e tempo de roubo<\/h2>\n\n<p>No ambiente do hipervisor, o agendador do anfitri\u00e3o determina quando <strong>vCPUs<\/strong> pode funcionar. Criar sobrerreservas <strong>Tempo de roubo<\/strong> nos convidados, o que funciona como uma \u201clat\u00eancia invis\u00edvel\u201d. Para locat\u00e1rios cr\u00edticos em termos de lat\u00eancia, eu fixo vCPUs em n\u00facleos f\u00edsicos e mantenho o overcommit moderado. Tamb\u00e9m separo os threads do emulador (threads de IO, vhost) dos n\u00facleos quentes dos convidados para que eles n\u00e3o interfiram uns nos outros.<\/p>\n\n<p>Evito a limita\u00e7\u00e3o dupla: se o convidado j\u00e1 estiver a utilizar o cpu.max, n\u00e3o defino quaisquer quotas r\u00edgidas adicionais no anfitri\u00e3o para a mesma carga de trabalho. O controlo de frequ\u00eancia continua a ser a tarefa do anfitri\u00e3o; os convidados beneficiam indiretamente se o regulador do anfitri\u00e3o se adaptar \u00e0 carga de trabalho real. Para lat\u00eancias uniformes, considero a estabilidade al\u00e9m das execu\u00e7\u00f5es de frequ\u00eancia m\u00e1xima pura mais importante do que o pico de GHz no papel.<\/p>\n\n<h2>AutoNUMA, localiza\u00e7\u00e3o de mem\u00f3ria e THP<\/h2>\n\n<p>O NUMA pode ser um ganho de desempenho ou uma armadilha para o desempenho. <strong>AutoNUMA<\/strong> muitas vezes ajuda, mas pode gerar sobrecarga adicional com threads de roaming intenso. Em pilhas de hospedagem com limites de servi\u00e7o claros, eu fixo CPU e <strong>Mem\u00f3ria<\/strong> (<em>cpuset.cpus<\/em> e <em>cpuset.mems<\/em>) em conjunto. Isto significa que os dados quentes permanecem locais e que o CFS tem de compensar com menos migra\u00e7\u00f5es.<\/p>\n\n<p>P\u00e1ginas grandes (<strong>THP<\/strong>) reduzem a press\u00e3o da TLB, mas n\u00e3o se adequam a todos os perfis. No caso das bases de dados, o \u201cmadvise\u201d pode fazer mais sentido do que um \u201calways\u201d generalizado. O bloqueio de falhas de p\u00e1gina atinge fortemente a lat\u00eancia interativa; portanto, planejo buffers (cache de p\u00e1gina, buffer compartilhado) para que os slots CFS sejam usados produtivamente e n\u00e3o esperem por eventos de E\/S ou MMU. Isso pode ser medido atrav\u00e9s de taxas de falha de p\u00e1gina e curvas de falha de cache.<\/p>\n\n<h2>Caminho de rede: controlo de IRQ, RPS\/XPS e sondagem de ocupado<\/h2>\n\n<p>Muitas cargas de trabalho da Web s\u00e3o dominadas por NICs. Eu distribuo <strong>IRQ<\/strong>filas de espera da placa de rede em v\u00e1rios n\u00facleos e mant\u00ea-las <em>afim<\/em> para as threads de trabalho para que os despertares permane\u00e7am locais. <strong>RPS\/XPS<\/strong> ajuda a resolver hotspots de soft se filas RX\/TX individuais estiverem carregando muita carga. Se o ksoftirqd ficar visivelmente quente, isso \u00e9 uma indica\u00e7\u00e3o de SoftIRQs transbordando - eu ent\u00e3o igualo os fluxos e aumento os par\u00e2metros de or\u00e7amento, se necess\u00e1rio, sem perder a equidade.<\/p>\n\n<p>O busy polling opcional pode fazer sentido em configura\u00e7\u00f5es muito especiais de baixa lat\u00eancia, mas custa tempo de CPU. Eu raramente o uso e somente se eu puder provar por medi\u00e7\u00e3o que o p99 cai significativamente sem estressar o host em geral. Normalmente, afinidade de IRQ limpa, grupos C e granularidade CFS fornecem a melhor rela\u00e7\u00e3o custo-benef\u00edcio.<\/p>\n\n<h2>Perspectivas: Do CFS ao EEVDF e abordagens do espa\u00e7o do utilizador<\/h2>\n\n<p>O EEVDF alarga a distribui\u00e7\u00e3o equitativa aos prazos, o que \u00e9 not\u00e1vel <strong>mais curto<\/strong> e mais previs\u00edvel <strong>Respostas<\/strong> promessas. Especialmente com alvos de lat\u00eancia interactiva, isto pode fazer toda a diferen\u00e7a. Eu mantenho-me atento \u00e0s vers\u00f5es do kernel e testo o EEVDF separadamente antes de mudar. Ao mesmo tempo, o agendamento do espa\u00e7o do utilizador atrav\u00e9s de padr\u00f5es eBPF est\u00e1 a ganhar for\u00e7a, o que pode permitir um controlo adicional, dependendo da carga de trabalho. O CFS continua a ser relevante para as infra-estruturas de alojamento, mas o EEVDF vai estabelecer-se rapidamente.<\/p>\n\n<p>Continua a ser importante um percurso de migra\u00e7\u00e3o claro: testes, implementa\u00e7\u00e3o em anfitri\u00f5es selecionados e, em seguida, expans\u00e3o. Esta \u00e9 a \u00fanica forma de manter os percentis e as taxas de erro sob controlo. Mantenho os par\u00e2metros de refer\u00eancia pr\u00f3ximos da realidade, incluindo fases de explos\u00e3o e backends lentos. S\u00f3 depois \u00e9 que intervenho em ambientes reais. Desta forma, o progresso pode ser alcan\u00e7ado sem surpresas desagrad\u00e1veis.<\/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\/03\/linux-scheduler-hosting-4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brevemente resumido<\/h2>\n\n<p>O Linux Scheduler CFS oferece uma distribui\u00e7\u00e3o justa, integra\u00e7\u00f5es s\u00f3lidas e boas <strong>Controlo<\/strong> via <strong>Grupos C<\/strong>. Com par\u00e2metros sysctl adequados, afinidade limpa e quotas realistas, mantenho as lat\u00eancias baixas e a taxa de transfer\u00eancia alta. ULE, BFS ou EEVDF oferecem uma vantagem adicional para padr\u00f5es especiais. Me\u00e7o, comparo e implemento as altera\u00e7\u00f5es por fases para limitar os riscos. Isto mant\u00e9m o alojamento previs\u00edvel - e o desempenho no seu devido lugar.<\/p>","protected":false},"excerpt":{"rendered":"<p>Linux Scheduler CFS explicado: Como funciona, servidor de agendamento de CPU e alternativas como o EEVDF. Afina\u00e7\u00e3o do kernel para um desempenho \u00f3timo do alojamento.<\/p>","protected":false},"author":1,"featured_media":18546,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-18553","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":"562","_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 CFS","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":"18546","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18553","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=18553"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18553\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/18546"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=18553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=18553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=18553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}