{"id":16149,"date":"2025-12-23T11:53:06","date_gmt":"2025-12-23T10:53:06","guid":{"rendered":"https:\/\/webhosting.de\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/"},"modified":"2025-12-23T11:53:06","modified_gmt":"2025-12-23T10:53:06","slug":"io-scheduler-linux-noop-mq-deadline-bfq-serverboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/","title":{"rendered":"Agendador de E\/S Linux: Noop, mq-deadline e BFQ explicados na hospedagem"},"content":{"rendered":"<p>O I\/O Scheduler Linux decide como o sistema classifica, prioriza e envia acessos de leitura e grava\u00e7\u00e3o para SSD, NVMe e HDD. Neste guia, explico de forma pr\u00e1tica quando <strong>Noop<\/strong>, <strong>prazo mq<\/strong> e <strong>BFQ<\/strong> s\u00e3o a melhor escolha em termos de alojamento \u2013 incluindo afina\u00e7\u00e3o, testes e etapas de a\u00e7\u00e3o claras.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Noop<\/strong>: Overhead m\u00ednimo em SSD\/NVMe e em VMs<\/li>\n  <li><strong>prazo mq<\/strong>: Lat\u00eancia e taxa de transfer\u00eancia equilibradas para servidores<\/li>\n  <li><strong>BFQ<\/strong>: Equidade e resposta r\u00e1pida em ambientes multiusu\u00e1rio<\/li>\n  <li><strong>blk-mq<\/strong>: Design multi-fila para hardware moderno<\/li>\n  <li><strong>Afina\u00e7\u00e3o<\/strong>: Testes por carga de trabalho em vez de regras fixas<\/li>\n<\/ul>\n\n<h2>Como funciona o I\/O Scheduler na hospedagem Linux<\/h2>\n\n<p>Um programador de E\/S do Linux organiza as solicita\u00e7\u00f5es de E\/S em filas, realiza a fus\u00e3o e decide a entrega ao dispositivo para <strong>Lat\u00eancia<\/strong> e aumentar o rendimento. Os kernels modernos utilizam blk-mq, ou seja, multi-queue, para que v\u00e1rios n\u00facleos de CPU possam iniciar I\/O em paralelo. Isso \u00e9 adequado para SSDs NVMe, que oferecem muitas filas e alta paralelidade, reduzindo assim as filas de espera. Na hospedagem, muitas vezes ocorrem cargas mistas amplas: servidores web fornecem muitas pequenas leituras, bancos de dados geram grava\u00e7\u00f5es sincronizadas e backups geram fluxos. O agendador adequado reduz congestionamentos, mant\u00e9m os tempos de resposta est\u00e1veis e protege o <strong>Servidor<\/strong>-Experi\u00eancia sob carga.<\/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\/2025\/12\/linux-io-scheduler-hosting-8391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>blk-mq na pr\u00e1tica: none vs. noop e predefini\u00e7\u00f5es do kernel<\/h2>\n\n<p>Desde o kernel 5.x, o design multi-fila \u00e9 o caminho padr\u00e3o. Nesse caso, <strong>nenhum<\/strong> o equivalente \u201eNoop\u201c para blk-mq, enquanto <strong>noop<\/strong> historicamente proveniente do caminho de fila \u00fanica. Em dispositivos NVMe, geralmente apenas <code>nenhum<\/code> dispon\u00edvel; em SATA\/SAS, \u00e9 comum ver <code>prazo mq<\/code>, opcional <code>bfq<\/code> e, dependendo da distribui\u00e7\u00e3o, tamb\u00e9m <code>kyber<\/code>. Os padr\u00f5es variam: o NVMe geralmente inicia com <code>nenhum<\/code>, SCSI\/SATA frequentemente com <code>prazo mq<\/code>. Por isso, verifico sempre as op\u00e7\u00f5es dispon\u00edveis atrav\u00e9s de <code>cat \/sys\/block\/\/queue\/scheduler<\/code> e decida por dispositivo. Onde apenas <code>nenhum<\/code> \u00e9 selecion\u00e1vel, isso \u00e9 intencional \u2013 uma classifica\u00e7\u00e3o adicional n\u00e3o traz praticamente nenhum valor acrescentado.<\/p>\n\n<h2>Noop em utiliza\u00e7\u00e3o no servidor: quando o minimalismo ganha<\/h2>\n\n<p>O Noop realiza principalmente a fus\u00e3o de blocos adjacentes, mas n\u00e3o os ordena, o que torna a sobrecarga da CPU extremamente <strong>baixo<\/strong> mant\u00e9m. Em SSDs e NVMe, os controladores e o firmware assumem a sequ\u00eancia inteligente, de modo que a classifica\u00e7\u00e3o adicional no kernel dificilmente traz benef\u00edcios. Em VMs e contentores, costumo planear o Noop, porque o hipervisor faz o planeamento de forma abrangente. Em discos rotativos, dispenso o Noop, pois a falta de ordena\u00e7\u00e3o aumenta os tempos de busca. Quem quiser delimitar com seguran\u00e7a o contexto do hardware deve primeiro verificar o tipo de mem\u00f3ria \u2013 aqui, \u00e9 \u00fatil dar uma olhada em <a href=\"https:\/\/webhosting.de\/pt\/nvme-ssd-hdd-alojamento-web-comparacao-desempenho-custos-dicas-servidor-profissional\/\">NVMe, SSD e HDD<\/a>, antes de eu usar o Scheduler <strong>determinar<\/strong>.<\/p>\n\n<h2>mq-deadline: prazos, sequ\u00eancias e prioridades claras<\/h2>\n\n<p>O mq-deadline atribui prazos curtos aos acessos de leitura e faz com que os acessos de escrita esperem um pouco mais, a fim de <strong>Tempo de resposta<\/strong> O Scheduler tamb\u00e9m classifica por endere\u00e7os de bloco, reduzindo assim os tempos de pesquisa, o que ajuda principalmente os HDDs e os conjuntos RAID. Em hosts web e de bases de dados, o mq-deadline oferece um bom equil\u00edbrio entre lat\u00eancia e rendimento. Gosto de us\u00e1-lo quando as cargas de trabalho s\u00e3o mistas e h\u00e1 leituras e grava\u00e7\u00f5es em espera de forma cont\u00ednua. Para o ajuste fino, verifico a profundidade da solicita\u00e7\u00e3o, o comportamento de writeback e o cache do controlador para garantir que a l\u00f3gica do prazo seja consistente. <strong>agarra<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux_io_scheduler_meeting_4273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>BFQ: Equidade e capacidade de resposta para muitos utilizadores simult\u00e2neos<\/h2>\n\n<p>O BFQ distribui a largura de banda proporcionalmente e atribui or\u00e7amentos por processo, o que \u00e9 not\u00e1vel. <strong>justo<\/strong> funciona quando muitos utilizadores geram E\/S em paralelo. Tarefas interativas, como shells de administra\u00e7\u00e3o, editores ou chamadas de API, permanecem r\u00e1pidas, mesmo com backups a decorrer em segundo plano. Em HDDs, o BFQ frequentemente atinge alta efici\u00eancia, pois aproveita fases sequenciais e usa janelas de inatividade curtas de maneira inteligente. Em SSDs muito r\u00e1pidos, h\u00e1 um pequeno esfor\u00e7o adicional, que eu comparo com a resposta percept\u00edvel. Quem usa Cgroups e ioprio pode criar garantias claras com o BFQ e, assim, evitar aborrecimentos com vizinhos barulhentos. <strong>Evitar<\/strong>.<\/p>\n\n<h2>QoS no dia a dia: ioprio, ionice e Cgroups v2 com BFQ<\/h2>\n\n<p>Para limpar <strong>Defini\u00e7\u00e3o de prioridades<\/strong> Eu combino BFQ com regras de processo e cgroup. No n\u00edvel do processo, eu defino com <code>ionice<\/code> Classes e prioridades: <code>ionice -c1<\/code> (em tempo real) para leituras cr\u00edticas em termos de lat\u00eancia, <code>ionice -c2 -n7<\/code> (Melhor esfor\u00e7o, baixo) para backups ou execu\u00e7\u00f5es de \u00edndice, <code>ionice -c3<\/code> (Idle) para tudo o que deve funcionar apenas em per\u00edodos de inatividade. No Cgroups v2, utilizo <code>io.weight<\/code> para propor\u00e7\u00f5es relativas (por exemplo, 100 vs. 1000) e <code>io.max<\/code> para limites r\u00edgidos, por exemplo <code>echo \"259:0 rbps=50M wbps=20M\" &gt; \/sys\/fs\/cgroup\/\/io.max<\/code>. Com o BFQ, os pesos s\u00e3o convertidos com grande precis\u00e3o em propor\u00e7\u00f5es de largura de banda \u2013 ideal para alojamento partilhado e hosts de contentores, nos quais <strong>Equidade<\/strong> \u00e9 mais importante do que a pot\u00eancia bruta m\u00e1xima.<\/p>\n\n<h2>Compara\u00e7\u00e3o pr\u00e1tica: qual escolha de hardware \u00e9 adequada<\/h2>\n\n<p>A escolha depende muito do tipo de mem\u00f3ria e da arquitetura da fila, por isso, primeiro verifico <strong>Dispositivo<\/strong> e controladores. SSD e NVMe beneficiam-se principalmente do Noop\/none, enquanto HDDs funcionam melhor com mq-deadline ou BFQ. Em configura\u00e7\u00f5es RAID, SANs e hosts vers\u00e1teis, prefiro frequentemente o mq-deadline, porque a l\u00f3gica do Deadline e a classifica\u00e7\u00e3o harmonizam-se bem. Ambientes multiusu\u00e1rio com muitas sess\u00f5es interativas geralmente se beneficiam do BFQ. A tabela a seguir resume os pontos fortes e os campos de aplica\u00e7\u00e3o \u00fateis de forma clara <strong>juntos<\/strong>:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>agendador<\/th>\n      <th>Hardware<\/th>\n      <th>Pontos fortes<\/th>\n      <th>Pontos fracos<\/th>\n      <th>Cen\u00e1rios de alojamento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Noop\/nenhum<\/td>\n      <td>SSD, NVMe, VMs<\/td>\n      <td>Overhead m\u00ednimo, fus\u00e3o limpa<\/td>\n      <td>Sem classifica\u00e7\u00e3o em discos r\u00edgidos, desvantajoso<\/td>\n      <td>Servidor Flash, contentor, controlado por hipervisor<\/td>\n    <\/tr>\n    <tr>\n      <td>prazo mq<\/td>\n      <td>HDD, RAID, servidor multifuncional<\/td>\n      <td>Prioridade de leitura rigorosa, ordena\u00e7\u00e3o, lat\u00eancia s\u00f3lida<\/td>\n      <td>Mais l\u00f3gica do que Noop<\/td>\n      <td>Bases de dados, back-ends web, cargas mistas<\/td>\n    <\/tr>\n    <tr>\n      <td>BFQ<\/td>\n      <td>HDD, multiutilizadores, anfitri\u00f5es semelhantes a computadores de secret\u00e1ria<\/td>\n      <td>Justi\u00e7a, capacidade de rea\u00e7\u00e3o, boas sequ\u00eancias<\/td>\n      <td>Um pouco mais de sobrecarga em SSDs muito r\u00e1pidos<\/td>\n      <td>Servi\u00e7os interativos, alojamento partilhado, servidor de desenvolvimento<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux-io-scheduler-hosting-4397.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configura\u00e7\u00e3o: verificar o agendador e definir como permanente<\/h2>\n\n<p>Primeiro, vejo qual agendador est\u00e1 ativo, por exemplo, com <code>cat \/sys\/block\/sdX\/queue\/scheduler<\/code>, e anote o <strong>Op\u00e7\u00e3o<\/strong> entre par\u00eanteses retos. Para mudar temporariamente, escrevo, por exemplo <code>echo mq-deadline | sudo tee \/sys\/block\/sdX\/queue\/scheduler<\/code>. Para configura\u00e7\u00f5es persistentes, utilizo regras udev ou par\u00e2metros do kernel, como <code>scsi_mod.use_blk_mq=1<\/code> e <code>prazo mq<\/code> na linha de comando. Para dispositivos NVMe, verifico os caminhos em <code>\/sys\/block\/nvme0n1\/queue\/<\/code> e defina a sele\u00e7\u00e3o por dispositivo. Importante: eu documento as altera\u00e7\u00f5es para que a manuten\u00e7\u00e3o e a revers\u00e3o possam ser feitas sem suposi\u00e7\u00f5es. <strong>ter sucesso<\/strong>.<\/p>\n\n<h2>Persist\u00eancia e automatiza\u00e7\u00e3o na opera\u00e7\u00e3o<\/h2>\n\n<p>No dia a dia, eu priorizo a repetibilidade em detrimento da automatiza\u00e7\u00e3o. Tr\u00eas m\u00e9todos t\u00eam se mostrado eficazes:<\/p>\n<ul>\n  <li><strong>Regras udev<\/strong>: Exemplo para todos os discos r\u00edgidos (rotacional=1) <code>echo 'ACTION==\"add|change\", KERNEL==\"sd*\", ATTR{queue\/rotational}==\"1\", ATTR{queue\/scheduler}=\"mq-deadline\"' &gt; \/etc\/udev\/rules.d\/60-io-scheduler.rules<\/code>, ent\u00e3o <code>udevadm control --reload-rules &amp;&amp; udevadm trigger<\/code>.<\/li>\n  <li><strong>systemd-tmpfiles<\/strong>: Para dispositivos espec\u00edficos, defino <code>\/etc\/tmpfiles.d\/blk.conf<\/code> com frases como <code>w \/sys\/block\/sdX\/queue\/scheduler - - - - mq-deadline<\/code>, que escrevem durante o arranque.<\/li>\n  <li><strong>Gest\u00e3o de configura\u00e7\u00e3o<\/strong>: No Ansible\/Salt, crio classes de dispositivos (NVMe, HDD) e distribuo predefini\u00e7\u00f5es consistentes, incluindo documenta\u00e7\u00e3o e revers\u00e3o.<\/li>\n<\/ul>\n<p>Nota: <code>elevador=<\/code> como par\u00e2metro do kernel era v\u00e1lido para o antigo caminho de fila \u00fanica. No blk-mq, eu determino a escolha <strong>por aparelho<\/strong>. Para stacks (dm-crypt, LVM, MD), defino a configura\u00e7\u00e3o padr\u00e3o no dispositivo superior. Mais informa\u00e7\u00f5es sobre isso abaixo.<\/p>\n\n<h2>Cargas de trabalho na hospedagem: reconhecer padr\u00f5es e agir corretamente<\/h2>\n\n<p>Primeiro, analiso a carga: muitas pequenas leituras indicam interfaces web, grava\u00e7\u00f5es pesadas de sincroniza\u00e7\u00e3o em bases de dados e pipelines de registo, grandes fluxos sequenciais em backups ou <strong>Arquivo<\/strong>. Ferramentas como <code>iostat<\/code>, <code>vmstat<\/code> e <code>blktrace<\/code> mostram filas de espera, lat\u00eancias e efeitos de fus\u00e3o. Em caso de tempo de inatividade da CPU percept\u00edvel devido a E\/S, remeto para <a href=\"https:\/\/webhosting.de\/pt\/io-wait-compreender-gargalo-de-memoria-resolver-otimizacao\/\">Entender a espera de E\/S<\/a>, para resolver os pontos cr\u00edticos de forma estruturada. Depois, testo 1\u20132 candidatos a programadores em intervalos de tempo id\u00eanticos. S\u00e3o os resultados das medi\u00e7\u00f5es que decidem, n\u00e3o a intui\u00e7\u00e3o ou <strong>mitos<\/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\/2025\/12\/linux_scheduler_hosting_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aprofundar a pr\u00e1tica de medi\u00e7\u00e3o: benchmarks reprodut\u00edveis<\/h2>\n\n<p>Para tomar decis\u00f5es s\u00f3lidas, utilizo m\u00e9todos controlados <strong>fio<\/strong>Perfis e confirma\u00e7\u00e3o com testes reais da aplica\u00e7\u00e3o:<\/p>\n<ul>\n  <li><strong>Leituras aleat\u00f3rias<\/strong> (Web\/Cache): <code>fio --name=rr --rw=randread --bs=4k --iodepth=32 --numjobs=4 --runtime=120 --time_based --filename=\/mnt\/testfile --direct=1<\/code><\/li>\n  <li><strong>Mistura aleat\u00f3ria<\/strong> (DB): <code>fio --name=randmix --rw=randrw --rwmixread=70 --bs=8k --iodepth=64 --numjobs=8 --runtime=180 --time_based --direct=1<\/code><\/li>\n  <li><strong>Sequencialmente<\/strong> (C\u00f3pia de seguran\u00e7a): <code>fio --name=seqw --rw=write --bs=1m --iodepth=128 --numjobs=2 --runtime=120 --time_based --direct=1<\/code><\/li>\n<\/ul>\n<p>Paralelamente, eu fa\u00e7o login <code>iostat -x 1<\/code>, <code>pidstat -d 1<\/code> e anote as lat\u00eancias P95\/P99 <code>fio<\/code>. Para diagn\u00f3sticos aprofundados, utilizo <code>blktrace<\/code> ou ferramentas eBPF, como <code>biolatic\u00eancia<\/code> Importante: eu fa\u00e7o as medi\u00e7\u00f5es nos mesmos hor\u00e1rios do dia, com as mesmas janelas de carga e os mesmos tamanhos de ficheiro. Eu minimizo os efeitos do cache com <code>direct=1<\/code> e pr\u00e9-condi\u00e7\u00f5es limpas (por exemplo, pr\u00e9-preenchimento no volume).<\/p>\n\n<h2>Sistemas de ficheiros e programador de E\/S: a intera\u00e7\u00e3o \u00e9 importante<\/h2>\n\n<p>O sistema de ficheiros influencia as caracter\u00edsticas de E\/S, por isso verifico cuidadosamente o seu modo de registo, profundidade da fila e comportamento de sincroniza\u00e7\u00e3o. <strong>exatamente<\/strong>. EXT4 e XFS funcionam eficientemente com mq-deadline, enquanto ZFS armazena e agrega muitas coisas por conta pr\u00f3pria. Em hosts com ZFS, observo que o efeito do agendador \u00e9 frequentemente menor, porque o ZFS j\u00e1 molda a sa\u00edda. Para compara\u00e7\u00f5es, utilizo op\u00e7\u00f5es de montagem e cargas de trabalho id\u00eanticas. Quem estiver a ponderar op\u00e7\u00f5es, encontrar\u00e1 em <a href=\"https:\/\/webhosting.de\/pt\/ext4-xfs-zfs-comparacao-de-desempenho-de-alojamento-armazenamento\/\">EXT4, XFS ou ZFS<\/a> perspetivas \u00fateis sobre <strong>Armazenamento<\/strong>-Afina\u00e7\u00e3o.<\/p>\n\n<h2>Writeback, cache e barreiras: a metade frequentemente ignorada<\/h2>\n\n<p>Os agendadores s\u00f3 podem funcionar t\u00e3o bem quanto o subsistema de registo permite. Por isso, verifico sempre:<\/p>\n<ul>\n  <li><strong>par\u00e2metro sujo<\/strong>: <code>sysctl vm.dirty_background_bytes<\/code>, <code>vm.dirty_bytes<\/code>, <code>vm.dirty_expire_centisecs<\/code> controlar quando e com que agressividade o kernel grava. Para bases de dados, muitas vezes reduzo os picos de burst para manter o P99 est\u00e1vel.<\/li>\n  <li><strong>Barreiras\/Flush<\/strong>: Op\u00e7\u00f5es como EXT4 <code>barreira<\/code> ou XFS Default-Flushes, eu s\u00f3 os protejo se o hardware (por exemplo, BBWC) os assumir. \u201enobarrier\u201c sem prote\u00e7\u00e3o contra energia \u00e9 <strong>arriscado<\/strong>.<\/li>\n  <li><strong>Cache de escrita do dispositivo<\/strong>: Verifico as configura\u00e7\u00f5es da cache de escrita do controlador para que <code>fsync<\/code> realmente chega ao meio de armazenamento e n\u00e3o apenas \u00e0 cache.<\/li>\n<\/ul>\n<p>Quem suaviza o Writeback alivia o Scheduler \u2013 os prazos permanecem fi\u00e1veis e o BFQ tem menos trabalho para lidar com ondas repentinas de flush.<\/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\/2025\/12\/linux_io_scheduler_4813.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Virtualiza\u00e7\u00e3o, contentores e nuvem: quem est\u00e1 realmente a planear?<\/h2>\n\n<p>Nas VMs, o hipervisor controla o fluxo f\u00edsico de E\/S, por isso, muitas vezes, seleciono Noop\/none no convidado para evitar duplica\u00e7\u00e3o. <strong>L\u00f3gica<\/strong> evitar. No pr\u00f3prio host, utilizo mq-deadline ou BFQ, dependendo do dispositivo e da tarefa. No caso de volumes na nuvem (por exemplo, armazenamento em bloco de rede), parte do planeamento fica no backend; por isso, me\u00e7o lat\u00eancias reais em vez de confiar em suposi\u00e7\u00f5es. Para hosts de contentores com carga muito mista, o BFQ frequentemente oferece melhor interatividade. Em clusters de lotes homog\u00e9neos com apenas flash, o Noop prevalece porque cada tempo de CPU conta e os controladores s\u00e3o eficientes. <strong>trabalho<\/strong>.<\/p>\n\n<h2>RAID, LVM, MD e Multipath: onde o Scheduler interv\u00e9m<\/h2>\n\n<p>Em pilhas de blocos empilhados, coloco o programador no <strong>Dispositivo de topo<\/strong> , pois \u00e9 a\u00ed que se encontram as filas relevantes:<\/p>\n<ul>\n  <li><strong>LVM\/dm-crypt<\/strong>: Agendador em <code>\/dev\/dm-*<\/code> respectivamente <code>\/dev\/mapper\/<\/code> colocar. Normalmente, deixo os PVs f\u00edsicos em <code>nenhum<\/code>, para que a fus\u00e3o\/classifica\u00e7\u00e3o n\u00e3o ocorra duas vezes.<\/li>\n  <li><strong>MD-RAID<\/strong>: No <code>\/dev\/mdX<\/code> decidir; abaixo <code>sdX<\/code> Os dispositivos permanecem tranquilos <code>nenhum<\/code>. O RAID de hardware \u00e9 tratado como um \u00fanico dispositivo de bloco.<\/li>\n  <li><strong>Multicaminho<\/strong>: No Multipath-Mapper (<code>\/dev\/mapper\/mpatha<\/code>); defina os dispositivos de caminho abaixo em <code>nenhum<\/code>.<\/li>\n<\/ul>\n<p>Importante: Eu separo os testes por <strong>piscina<\/strong> e n\u00edvel de redund\u00e2ncia (RAID1\/10 vs. RAID5\/6). Os RAIDs de paridade s\u00e3o mais sens\u00edveis a grava\u00e7\u00f5es aleat\u00f3rias; aqui, o mq-deadline costuma ganhar devido aos prazos de leitura consistentes e \u00e0 sa\u00edda ordenada.<\/p>\n\n<h2>Estrat\u00e9gias de afina\u00e7\u00e3o: passo a passo para um desempenho fi\u00e1vel<\/h2>\n\n<p>Come\u00e7o com uma medi\u00e7\u00e3o b\u00e1sica: tempos de resposta atuais, taxa de transfer\u00eancia, percentis 95\/99 e CPU.<strong>Carga<\/strong>. Depois disso, altero apenas um fator, normalmente o agendador, e repito a mesma carga. Ferramentas como <code>fio<\/code> ajudam a controlar, mas eu confirmo cada hip\u00f3tese com testes de aplica\u00e7\u00e3o reais. Para bases de dados, s\u00e3o adequados benchmarks pr\u00f3prios que reproduzem transa\u00e7\u00f5es e comportamento fsync. S\u00f3 quando a medi\u00e7\u00e3o est\u00e1 est\u00e1vel \u00e9 que eu defino a escolha e documento o <strong>Porqu\u00ea<\/strong>.<\/p>\n\n<h2>Profundidade da fila, leitura antecipada e afinidade da CPU<\/h2>\n\n<p>Al\u00e9m do agendador, os par\u00e2metros da fila t\u00eam grande influ\u00eancia na pr\u00e1tica:<\/p>\n<ul>\n  <li><strong>Profundidade da fila<\/strong>: <code>\/sys\/block\/\/queue\/nr_requests<\/code> Limita as solicita\u00e7\u00f5es pendentes por fila de hardware. O NVMe suporta alta profundidade (alto rendimento), enquanto os HDDs beneficiam de profundidade moderada (lat\u00eancia mais est\u00e1vel).<\/li>\n  <li><strong>Readahead<\/strong>: <code>\/sys\/block\/\/queue\/read_ahead_kb<\/code> respectivamente <code>blockdev --getra\/setra<\/code>. Para cargas de trabalho sequenciais, mantenha um valor ligeiramente mais alto; para cargas de trabalho aleat\u00f3rias, mantenha um valor baixo.<\/li>\n  <li><strong>rq_affinity<\/strong>Com <code>\/sys\/block\/\/queue\/rq_affinity<\/code> No ponto 2, garanto que a conclus\u00e3o da E\/S seja direcionada preferencialmente para o n\u00facleo da CPU que a gerou, o que reduz os custos entre CPUs.<\/li>\n  <li><strong>rotacional<\/strong>: Confirmo que os SSDs <code>rotacional=0<\/code> para que o kernel n\u00e3o aplique heur\u00edsticas HDD.<\/li>\n  <li><strong>Mesclagens<\/strong>: <code>\/sys\/block\/\/queue\/nomerges<\/code> Pode reduzir as fus\u00f5es (2=desativado). \u00datil para NVMe com microlat\u00eancia, mas geralmente prejudicial para HDDs.<\/li>\n  <li><strong>io_poll<\/strong> (NVMe): O polling pode reduzir as lat\u00eancias, mas requer CPU. Eu ativo-o especificamente em <strong>Baixa lat\u00eancia<\/strong>-Requisitos.<\/li>\n<\/ul>\n\n<h2>Scheduler-Tunables em detalhe<\/h2>\n\n<p>Dependendo do programador, existem ajustes precisos \u00fateis dispon\u00edveis:<\/p>\n<ul>\n  <li><strong>prazo mq<\/strong>: <code>\/sys\/block\/\/queue\/iosched\/read_expire<\/code> (ms, tipicamente pequeno), <code>write_expire<\/code> (maior), <code>fifo_batch<\/code> (tamanho do lote), <code>front_merges<\/code> (0\/1). Eu considero <code>read_expire<\/code> brevemente, para proteger as leituras P95, e ajuste <code>fifo_batch<\/code> dependendo do dispositivo.<\/li>\n  <li><strong>BFQ<\/strong>: <code>slice_idle<\/code> (Tempo ocioso para utiliza\u00e7\u00e3o da sequ\u00eancia), <code>baixa lat\u00eancia<\/code> (0\/1) para interatividade responsiva. Com <code>bfq.weight<\/code> Nos Cgroups, controlo as quotas relativas com muita precis\u00e3o.<\/li>\n  <li><strong>nenhum\/noop<\/strong>: Quase sem parafusos de ajuste, mas a <strong>Arredores<\/strong> (profundidade da fila, leitura antecipada) determina os resultados.<\/li>\n<\/ul>\n<p>Eu altero sempre apenas um par\u00e2metro e registo rigorosamente a altera\u00e7\u00e3o \u2013 assim fica claro qual foi o efeito de cada altera\u00e7\u00e3o.<\/p>\n\n<h2>Armadilhas comuns e como as evito<\/h2>\n\n<p>Pools mistos de HDD e SSD atr\u00e1s de um controlador RAID distorcem os testes, por isso separo as medi\u00e7\u00f5es por <strong>Grupo<\/strong>. N\u00e3o me esque\u00e7o que o agendador se aplica por dispositivo de bloco \u2013 considero o LVM-Mapper e os dispositivos MD separadamente. A persist\u00eancia tende a escapar: sem a regra udev ou o par\u00e2metro do kernel, ap\u00f3s a reinicializa\u00e7\u00e3o, volta-se ao padr\u00e3o. Cgroups e prioridades de E\/S muitas vezes permanecem inutilizadas, embora aumentem significativamente a equidade. E eu sempre verifico a profundidade da fila, o writeback e as op\u00e7\u00f5es do sistema de ficheiros para que a l\u00f3gica escolhida alcance o seu potencial. <strong>espect\u00e1culos<\/strong>.<\/p>\n\n<h2>Resolu\u00e7\u00e3o de problemas: ler os sintomas de forma espec\u00edfica<\/h2>\n\n<p>Quando os valores medidos mudam, eu interpreto os padr\u00f5es e deduzo medidas concretas:<\/p>\n<ul>\n  <li><strong>Alta lat\u00eancia P99 em muitas leituras<\/strong>: Verificar se as grava\u00e7\u00f5es substituem as leituras. Testar com mq-deadline., <code>read_expire<\/code> reduzir, suavizar a revers\u00e3o (<code>vm.dirty_*<\/code> ajustar).<\/li>\n  <li><strong>100% util no HDD, baixo rendimento<\/strong>: Dominar as pesquisas. Experimentar BFQ ou mq-deadline, reduzir o readahead, moderar a profundidade da fila.<\/li>\n  <li><strong>Bons valores de rendimento, mas a interface do utilizador \u00e9 inst\u00e1vel<\/strong>: A interatividade \u00e9 prejudicada. Ativar BFQ, servi\u00e7os cr\u00edticos por <code>ionice -c1<\/code> ou pesos Cgroup.<\/li>\n  <li><strong>Grande varia\u00e7\u00e3o dependendo da hora do dia<\/strong>: Recursos partilhados. Isolar com Cgroups, selecionar o programador por pool, transferir as c\u00f3pias de seguran\u00e7a para fora do hor\u00e1rio de pico.<\/li>\n  <li><strong>Timeouts NVMe no dmesg<\/strong>: Quest\u00e3o relacionada com o backend ou firmware. <code>io_poll<\/code> Desativar para teste, verificar firmware\/driver, verificar redund\u00e2ncia de caminho (multicaminho).<\/li>\n<\/ul>\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\/2025\/12\/linux-io-hosting-9481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumo: decis\u00f5es claras para o dia a dia da hospedagem<\/h2>\n\n<p>Para armazenamento flash e convidados, muitas vezes opto por <strong>Noop<\/strong>, para economizar despesas gerais e deixar os controladores a trabalhar. Em servidores vers\u00e1teis com HDD ou RAID, o mq-deadline oferece lat\u00eancia confi\u00e1vel e alta usabilidade. Com muitos utilizadores ativos e carga interativa, o BFQ garante distribui\u00e7\u00f5es justas e respostas r\u00e1pidas. Antes de cada grava\u00e7\u00e3o, fa\u00e7o medi\u00e7\u00f5es com cargas de trabalho reais e observo os efeitos em P95\/P99. Assim, tomo decis\u00f5es compreens\u00edveis, mantenho os sistemas r\u00e1pidos e estabilizo o <strong>Servidor<\/strong>-Desempenho nas atividades di\u00e1rias.<\/p>","protected":false},"excerpt":{"rendered":"<p>I\/O Scheduler Linux explicado: noop, mq-deadline e BFQ para uma hospedagem ideal. Dicas de ajuste de armazenamento para o desempenho do servidor.<\/p>","protected":false},"author":1,"featured_media":16142,"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-16149","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":"1823","_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":null,"_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":"I\/O Scheduler Linux","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":"16142","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/16149","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=16149"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/16149\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/16142"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=16149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=16149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=16149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}