{"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\/it\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/","title":{"rendered":"I\/O Scheduler Linux: Noop, mq-deadline e BFQ spiegati nell'hosting"},"content":{"rendered":"<p>Lo scheduler I\/O Linux decide come il sistema ordina, assegna priorit\u00e0 e invia al dispositivo gli accessi di lettura e scrittura su SSD, NVMe e HDD. In questa guida spiego in modo pratico quando <strong>Noop<\/strong>, <strong>mq-scadenza<\/strong> e <strong>BFQ<\/strong> sono la scelta migliore per l'hosting, compresi tuning, test e procedure chiare.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Noop<\/strong>: Overhead minimo su SSD\/NVMe e nelle VM<\/li>\n  <li><strong>mq-scadenza<\/strong>: Latenza e throughput bilanciati per i server<\/li>\n  <li><strong>BFQ<\/strong>: Equit\u00e0 e reazione rapida in caso di multi-utenti<\/li>\n  <li><strong>blk-mq<\/strong>: Design multi-coda per hardware moderno<\/li>\n  <li><strong>Sintonizzazione<\/strong>: Test per ogni carico di lavoro anzich\u00e9 regole fisse<\/li>\n<\/ul>\n\n<h2>Come funziona lo scheduler I\/O nell'hosting Linux<\/h2>\n\n<p>Uno scheduler I\/O Linux ordina le richieste I\/O in code, esegue il merging e decide la consegna al dispositivo per <strong>Latenza<\/strong> ridurre e aumentare la velocit\u00e0 di trasmissione. I kernel moderni utilizzano blk-mq, ovvero Multi-Queue, in modo che pi\u00f9 core CPU possano avviare I\/O in parallelo. Ci\u00f2 \u00e8 adatto agli SSD NVMe, che offrono molte code e un elevato parallelismo, riducendo cos\u00ec le code di attesa. Nell'hosting spesso si verificano carichi misti di ampia portata: i server web forniscono molte piccole letture, i database generano scritture di sincronizzazione, i backup generano flussi. Lo scheduler appropriato riduce gli ingorghi, mantiene stabili i tempi di risposta e protegge il <strong>Server<\/strong>-Esperienza sotto carico.<\/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 nella pratica: none vs. noop e impostazioni predefinite del kernel<\/h2>\n\n<p>A partire dal kernel 5.x, il design multi-queue \u00e8 il percorso standard. In questo caso <strong>nessuno<\/strong> l'equivalente \u201eNoop\u201c per blk-mq, mentre <strong>noop<\/strong> proveniente storicamente dal percorso della coda singola. Sui dispositivi NVMe, solitamente \u00e8 disponibile solo <code>nessuno<\/code> disponibile; su SATA\/SAS si vede spesso <code>mq-scadenza<\/code>, opzionale <code>bfq<\/code> e, a seconda della distribuzione, anche <code>kyber<\/code>. I valori predefiniti variano: NVMe si avvia solitamente con <code>nessuno<\/code>, SCSI\/SATA spesso con <code>mq-scadenza<\/code>. Pertanto, verifico sempre le opzioni disponibili tramite <code>cat \/sys\/block\/\/queue\/scheduler<\/code> e decido per ogni dispositivo. Dove solo <code>nessuno<\/code> \u00e8 selezionabile, \u00e8 voluto: un ulteriore ordinamento non apporterebbe praticamente alcun valore aggiunto.<\/p>\n\n<h2>Noop nell'uso dei server: quando il minimalismo vince<\/h2>\n\n<p>Noop esegue principalmente il merging di blocchi adiacenti, ma non effettua alcuna operazione di ordinamento, il che riduce notevolmente il carico della CPU. <strong>basso<\/strong> . Sugli SSD e NVMe, il controller e il firmware gestiscono l'ordine in modo intelligente, quindi un ulteriore ordinamento nel kernel non apporta alcun vantaggio. Nelle VM e nei container pianifico spesso Noop, perch\u00e9 l'hypervisor pianifica comunque in modo globale. Sui dischi rotanti rinuncio a Noop, poich\u00e9 la mancanza di ordinamento aumenta i tempi di ricerca. Chi desidera delimitare con sicurezza il contesto hardware, deve prima controllare il tipo di memoria: in questo caso \u00e8 utile dare un'occhiata a <a href=\"https:\/\/webhosting.de\/it\/nvme-ssd-hdd-web-hosting-confronto-prestazioni-costi-consigli-serverprofi\/\">NVMe, SSD e HDD<\/a>, prima di avviare lo scheduler <strong>determinare<\/strong>.<\/p>\n\n<h2>mq-deadline: scadenze, sequenze e priorit\u00e0 chiare<\/h2>\n\n<p>mq-deadline assegna scadenze brevi agli accessi in lettura e fa attendere un po' pi\u00f9 a lungo gli accessi in scrittura, al fine di <strong>Tempo di risposta<\/strong> Il programma di pianificazione ordina inoltre gli indirizzi dei blocchi, riducendo cos\u00ec i tempi di ricerca, il che \u00e8 particolarmente utile per gli HDD e i sistemi RAID. Negli host web e database, mq-deadline offre un buon equilibrio tra latenza e throughput. Mi piace utilizzarlo quando i carichi di lavoro sono misti e sia le letture che le scritture sono in coda in modo permanente. Per la messa a punto, controllo la profondit\u00e0 delle richieste, il comportamento di writeback e la cache del controller, in modo che la logica della scadenza sia coerente. <strong>prese<\/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: equit\u00e0 e reattivit\u00e0 per molti utenti simultanei<\/h2>\n\n<p>BFQ distribuisce la larghezza di banda in modo proporzionale e assegna budget per ogni processo, il che \u00e8 notevolmente <strong>equo<\/strong> funziona quando molti utenti generano I\/O in parallelo. Le attivit\u00e0 interattive come shell amministrative, editor o chiamate API rimangono veloci, anche se in background sono in esecuzione dei backup. Sugli HDD, BFQ raggiunge spesso un'elevata efficienza perch\u00e9 sfrutta le fasi sequenziali e utilizza in modo intelligente brevi finestre di inattivit\u00e0. Sugli SSD molto veloci si verifica un leggero aumento del carico di lavoro, che valuto positivamente rispetto alla notevole reattivit\u00e0. Chi utilizza cgroups e ioprio pu\u00f2 ottenere garanzie chiare con BFQ ed evitare cos\u00ec fastidi causati da vicini rumorosi. <strong>Evitare<\/strong>.<\/p>\n\n<h2>QoS nella vita quotidiana: ioprio, ionice e Cgroups v2 con BFQ<\/h2>\n\n<p>Per la pulizia <strong>Definizione delle priorit\u00e0<\/strong> Combino BFQ con regole di processo e cgroup. A livello di processo, imposto con <code>ionice<\/code> Classi e priorit\u00e0: <code>ionice -c1<\/code> (in tempo reale) per letture critiche in termini di latenza, <code>ionice -c2 -n7<\/code> (Best-Effort, basso) per backup o esecuzioni di indici, <code>ionice -c3<\/code> (Idle) per tutto ci\u00f2 che deve funzionare solo nei periodi di inattivit\u00e0. In Cgroups v2 utilizzo <code>io.weight<\/code> per quote relative (ad es. 100 contro 1000) e <code>io.max<\/code> per limiti rigidi, ad esempio <code>echo \"259:0 rbps=50M wbps=20M\" &gt; \/sys\/fs\/cgroup\/\/io.max<\/code>. Con BFQ, i pesi vengono convertiti in porzioni di larghezza di banda in modo molto preciso: ideale per hosting condiviso e host container su cui <strong>Equit\u00e0<\/strong> \u00e8 pi\u00f9 importante della potenza massima.<\/p>\n\n<h2>Confronto pratico: quale scelta \u00e8 pi\u00f9 adatta all'hardware<\/h2>\n\n<p>La scelta dipende molto dal tipo di memoria e dall'architettura della coda, quindi per prima cosa controllo <strong>Dispositivo<\/strong> e controller. SSD e NVMe traggono solitamente vantaggio da Noop\/none, mentre gli HDD funzionano meglio con mq-deadline o BFQ. Nelle configurazioni RAID, SAN e host allround, spesso preferisco mq-deadline perch\u00e9 la logica deadline e l'ordinamento si armonizzano bene. Gli ambienti multiutente con molte sessioni interattive spesso traggono vantaggio da BFQ. La tabella seguente riassume in modo chiaro i punti di forza e i campi di applicazione pi\u00f9 indicati. <strong>insieme<\/strong>:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>scheduler<\/th>\n      <th>Hardware<\/th>\n      <th>Punti di forza<\/th>\n      <th>Punti di debolezza<\/th>\n      <th>Scenari di hosting<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Noop\/nessuno<\/td>\n      <td>SSD, NVMe, VM<\/td>\n      <td>Overhead minimo, fusione pulita<\/td>\n      <td>Senza ordinamento su HDD svantaggioso<\/td>\n      <td>Server Flash, container, controllato da hypervisor<\/td>\n    <\/tr>\n    <tr>\n      <td>mq-scadenza<\/td>\n      <td>HDD, RAID, server versatile<\/td>\n      <td>Priorit\u00e0 di lettura rigorosa, ordinamento, latenza solida<\/td>\n      <td>Pi\u00f9 logica che Noop<\/td>\n      <td>Database, backend web, carichi misti<\/td>\n    <\/tr>\n    <tr>\n      <td>BFQ<\/td>\n      <td>HDD, multiutente, host simili a desktop<\/td>\n      <td>Correttezza, reattivit\u00e0, buone sequenze<\/td>\n      <td>Leggermente maggiore overhead su SSD molto veloci<\/td>\n      <td>Servizi interattivi, hosting condiviso, server di sviluppo<\/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>Configurazione: controllare lo scheduler e impostarlo in modo permanente<\/h2>\n\n<p>Per prima cosa controllo quale scheduler \u00e8 attivo, ad esempio con <code>cat \/sys\/block\/sdX\/queue\/scheduler<\/code>, e annota il <strong>Opzione<\/strong> tra parentesi quadre. Per cambiare temporaneamente, scrivo ad esempio <code>echo mq-deadline | sudo tee \/sys\/block\/sdX\/queue\/scheduler<\/code>. Per le impostazioni permanenti utilizzo regole udev o parametri del kernel come <code>scsi_mod.use_blk_mq=1<\/code> e <code>mq-scadenza<\/code> nella riga di comando. Per i dispositivi NVMe, controllo i percorsi in <code>\/sys\/block\/nvme0n1\/queue\/<\/code> e imposta la selezione per dispositivo. Importante: documento le modifiche in modo che la manutenzione e il rollback possano essere eseguiti senza congetture. <strong>successo<\/strong>.<\/p>\n\n<h2>Persistenza e automazione nel funzionamento<\/h2>\n\n<p>Nella vita quotidiana, privilegio la ripetibilit\u00e0 rispetto all'automazione. Tre metodi si sono dimostrati efficaci:<\/p>\n<ul>\n  <li><strong>Regole udev<\/strong>: Esempio per tutti gli HDD (rotazionale=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>, allora <code>udevadm control --reload-rules &amp;&amp; udevadm trigger<\/code>.<\/li>\n  <li><strong>systemd-tmpfiles<\/strong>: Per dispositivi specifici definisco <code>\/etc\/tmpfiles.d\/blk.conf<\/code> con frasi come <code>w \/sys\/block\/sdX\/queue\/scheduler - - - - mq-deadline<\/code>, che scrivono durante l'avvio.<\/li>\n  <li><strong>Gestione della configurazione<\/strong>: In Ansible\/Salt creo classi di dispositivi (NVMe, HDD) e distribuisco impostazioni predefinite coerenti insieme alla documentazione e al rollback.<\/li>\n<\/ul>\n<p>Nota: <code>elevatore=<\/code> era il parametro del kernel utilizzato per il vecchio percorso a coda singola. In blk-mq determino la scelta <strong>per dispositivo<\/strong>. Per gli stack (dm-crypt, LVM, MD) imposto l'impostazione predefinita sul dispositivo superiore, maggiori informazioni in proposito sono disponibili pi\u00f9 avanti.<\/p>\n\n<h2>Carichi di lavoro nell'hosting: riconoscere i modelli e agire correttamente<\/h2>\n\n<p>Per prima cosa analizzo il carico: molte piccole letture indicano front-end web, scritture con sincronizzazione intensiva su database e pipeline di log, grandi flussi sequenziali su backup o <strong>Archivio<\/strong>. Strumenti come <code>iostat<\/code>, <code>vmstat<\/code> e <code>blktrace<\/code> mostrano code, latenze ed effetti di merge. In caso di tempo di inattivit\u00e0 della CPU evidente dovuto all'I\/O, rimando a <a href=\"https:\/\/webhosting.de\/it\/io-wait-comprendere-memoria-congestione-risolvere-ottimizzazione\/\">Comprendere l'I\/O Wait<\/a>, per risolvere le difficolt\u00e0 in modo strutturato. Successivamente, provo 1-2 candidati per lo scheduler in finestre temporali identiche. Sono i risultati delle misurazioni a decidere, non l'istinto o <strong>miti<\/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>Approfondire la pratica di misurazione: benchmark riproducibili<\/h2>\n\n<p>Per prendere decisioni affidabili utilizzo metodi controllati. <strong>fio<\/strong>-Profili e conferma con test reali dell'applicazione:<\/p>\n<ul>\n  <li><strong>Letture casuali<\/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>Mix casuale<\/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>Sequenziale<\/strong> (Backup): <code>fio --name=seqw --rw=write --bs=1m --iodepth=128 --numjobs=2 --runtime=120 --time_based --direct=1<\/code><\/li>\n<\/ul>\n<p>Contemporaneamente mi collego <code>iostat -x 1<\/code>, <code>pidstat -d 1<\/code> e registra le latenze P95\/P99 <code>fio<\/code>. Per diagnosi approfondite utilizzo <code>blktrace<\/code> o strumenti eBPF come <code>biolatenza<\/code> . Importante: effettuo le misurazioni alla stessa ora del giorno, con gli stessi carichi e le stesse dimensioni dei file. Riduco al minimo gli effetti della cache con <code>direct=1<\/code> e condizioni preliminari pulite (ad es. pre-fill sul volume).<\/p>\n\n<h2>File system e scheduler I\/O: l'interazione \u00e8 fondamentale<\/h2>\n\n<p>Il file system influisce sulle caratteristiche I\/O, quindi controllo attentamente la modalit\u00e0 journal, la profondit\u00e0 della coda e il comportamento di sincronizzazione. <strong>esattamente<\/strong>. EXT4 e XFS funzionano in modo efficiente con mq-deadline, mentre ZFS bufferizza e aggrega gran parte dei dati autonomamente. Sugli host con ZFS osservo spesso un effetto dello scheduler minore, perch\u00e9 ZFS modella gi\u00e0 l'output. Per i confronti utilizzo opzioni di montaggio e carichi di lavoro identici. Chi valuta le opzioni, trova in <a href=\"https:\/\/webhosting.de\/it\/ext4-xfs-zfs-hosting-confronto-delle-prestazioni-archiviazione\/\">EXT4, XFS o ZFS<\/a> prospettive utili su <strong>Immagazzinamento<\/strong>-Messa a punto.<\/p>\n\n<h2>Writeback, cache e barriere: la met\u00e0 spesso trascurata<\/h2>\n\n<p>Gli scheduler possono funzionare solo nella misura consentita dal sottosistema di writeback. Pertanto, controllo sempre:<\/p>\n<ul>\n  <li><strong>parametro dirty<\/strong>: <code>sysctl vm.dirty_background_bytes<\/code>, <code>vm.dirty_bytes<\/code>, <code>vm.dirty_expire_centisecs<\/code> controllare quando e con quale intensit\u00e0 il kernel scrive. Per i database, spesso riduco i picchi di burst per mantenere stabile il P99.<\/li>\n  <li><strong>Barriere\/Flush<\/strong>: Opzioni come EXT4 <code>barriera<\/code> o XFS Default-Flushes li salvo solo se l'hardware (ad es. BBWC) li riprende. \u201enobarrier\u201c senza protezione dall'alimentazione \u00e8 <strong>rischioso<\/strong>.<\/li>\n  <li><strong>Cache di scrittura del dispositivo<\/strong>: Verifico le impostazioni della cache di scrittura del controller, in modo che <code>fsync<\/code> finisca davvero sul supporto e non solo nella cache.<\/li>\n<\/ul>\n<p>Chi livella il writeback alleggerisce il carico di lavoro dello scheduler: le scadenze rimangono affidabili e BFQ deve lavorare meno contro improvvise ondate di 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>Virtualizzazione, container e cloud: chi sta davvero pianificando?<\/h2>\n\n<p>Nelle VM, l'hypervisor controlla il flusso fisico di I\/O, motivo per cui spesso seleziono Noop\/none nell'ospite per evitare duplicati. <strong>logica<\/strong> Da evitare. Sull'host stesso utilizzo mq-deadline o BFQ a seconda del dispositivo e dell'attivit\u00e0. Nel caso dei volumi cloud (ad es. network block storage), parte della pianificazione avviene nel backend; pertanto misuro le latenze reali invece di basarmi su ipotesi. Per gli host container con carichi molto eterogenei, BFQ offre spesso una migliore interattivit\u00e0. Nei cluster batch omogenei con solo flash, Noop prevale perch\u00e9 ogni tempo di CPU conta e i controller sono efficienti. <strong>lavoro<\/strong>.<\/p>\n\n<h2>RAID, LVM, MD e multipath: dove interviene lo scheduler<\/h2>\n\n<p>In pile di blocchi impilati, imposto lo scheduler su <strong>Dispositivo di punta<\/strong> , perch\u00e9 l\u00ec si trovano le code rilevanti:<\/p>\n<ul>\n  <li><strong>LVM\/dm-crypt<\/strong>: Scheduler su <code>\/dev\/dm-*<\/code> rispettivamente <code>\/dev\/mapper\/<\/code> . Di solito lascio i PV fisici su <code>nessuno<\/code>, in modo che l'unione\/ordinamento non avvenga due volte.<\/li>\n  <li><strong>MD-RAID<\/strong>: Am <code>\/dev\/mdX<\/code> decidere; sottostanti <code>sdX<\/code> I dispositivi rimangono tranquilli <code>nessuno<\/code>. Il RAID hardware viene trattato come un singolo dispositivo a blocchi.<\/li>\n  <li><strong>Multipath<\/strong>: Sul Multipath Mapper (<code>\/dev\/mapper\/mpatha<\/code>); impostare i dispositivi di percorso sottostanti su <code>nessuno<\/code>.<\/li>\n<\/ul>\n<p>Importante: separo i test in base a <strong>piscina<\/strong> e livello di ridondanza (RAID1\/10 vs. RAID5\/6). I RAID con parit\u00e0 sono pi\u00f9 sensibili alle scritture casuali; in questo caso mq-deadline spesso prevale grazie a scadenze di lettura coerenti e output ordinato.<\/p>\n\n<h2>Strategie di ottimizzazione: passo dopo passo verso prestazioni affidabili<\/h2>\n\n<p>Inizio con una misurazione di base: tempi di risposta attuali, throughput, 95\u00b0\/99\u00b0 percentile e CPU.<strong>Carico<\/strong>. Successivamente, modifico solo un fattore, in genere lo scheduler, e ripeto lo stesso carico. Strumenti come <code>fio<\/code> aiutano a controllare, ma confermo ogni ipotesi con test di applicazione reali. Per i database sono adatti benchmark propri che riproducono le transazioni e il comportamento fsync. Solo quando la misurazione \u00e8 stabile, registro la scelta e la documento. <strong>Perch\u00e9<\/strong>.<\/p>\n\n<h2>Profondit\u00e0 della coda, readahead e affinit\u00e0 CPU<\/h2>\n\n<p>Oltre allo scheduler, anche i parametri della coda influiscono notevolmente sulla pratica:<\/p>\n<ul>\n  <li><strong>Profondit\u00e0 della coda<\/strong>: <code>\/sys\/block\/\/queue\/nr_requests<\/code> Limita le richieste in sospeso per ogni coda hardware. NVMe tollera una profondit\u00e0 elevata (elevato throughput), mentre gli HDD traggono vantaggio da una profondit\u00e0 moderata (latenza pi\u00f9 stabile).<\/li>\n  <li><strong>Readahead<\/strong>: <code>\/sys\/block\/\/queue\/read_ahead_kb<\/code> rispettivamente <code>blockdev --getra\/setra<\/code>. Leggermente superiore per carichi di lavoro sequenziali, mantenere basso per quelli casuali.<\/li>\n  <li><strong>rq_affinity<\/strong>Con <code>\/sys\/block\/\/queue\/rq_affinity<\/code> Al punto 2 mi assicuro che il completamento I\/O venga eseguito preferibilmente sul core della CPU che lo ha generato, riducendo cos\u00ec i costi cross-CPU.<\/li>\n  <li><strong>rotazione<\/strong>: Verifico che gli SSD <code>rotazione=0<\/code> per impedire al kernel di applicare euristiche HDD.<\/li>\n  <li><strong>Merge<\/strong>: <code>\/sys\/block\/\/queue\/nomerges<\/code> Pu\u00f2 ridurre le fusioni (2=disattivato). Utile in parte per la micro-latenza NVMe, ma spesso svantaggioso per gli HDD.<\/li>\n  <li><strong>io_poll<\/strong> (NVMe): il polling pu\u00f2 ridurre le latenze, ma richiede CPU. Lo attivo in modo mirato in caso di <strong>Bassa latenza<\/strong>-Requisiti.<\/li>\n<\/ul>\n\n<h2>Scheduler Tunables in dettaglio<\/h2>\n\n<p>A seconda dello scheduler sono disponibili regolazioni di precisione utili:<\/p>\n<ul>\n  <li><strong>mq-scadenza<\/strong>: <code>\/sys\/block\/\/queue\/iosched\/read_expire<\/code> (ms, tipicamente piccolo), <code>write_expire<\/code> (pi\u00f9 grande), <code>fifo_batch<\/code> (dimensione batch), <code>front_merges<\/code> (0\/1). Ritengo che <code>read_expire<\/code> brevemente per proteggere le letture P95 e regolare <code>fifo_batch<\/code> a seconda del dispositivo.<\/li>\n  <li><strong>BFQ<\/strong>: <code>slice_idle<\/code> (Tempo di inattivit\u00e0 per l'utilizzo della sequenza), <code>bassa_latenza<\/code> (0\/1) per un'interattivit\u00e0 reattiva. Con <code>bfq.weight<\/code> In Cgroups controllo le quote relative in modo molto preciso.<\/li>\n  <li><strong>nessuno\/noop<\/strong>: Quasi nessuna vite di regolazione, ma la <strong>Dintorni<\/strong> (profondit\u00e0 della coda, readahead) determina i risultati.<\/li>\n<\/ul>\n<p>Modifico sempre un solo parametro alla volta e annoto accuratamente ogni modifica, in modo da poter capire chiaramente quale effetto ha avuto ciascuna di esse.<\/p>\n\n<h2>Insidie frequenti e come evitarle<\/h2>\n\n<p>I pool misti di HDD e SSD dietro un controller RAID falsano i test, quindi separo le misurazioni per <strong>Gruppo<\/strong>. Non dimentico che lo scheduler si applica per ogni dispositivo a blocchi: considero separatamente LVM Mapper e dispositivi MD. La persistenza tende a sfuggire: senza regole udev o parametri del kernel, dopo il riavvio viene ripristinato il valore predefinito. I cgroup e le priorit\u00e0 I\/O rimangono spesso inutilizzati, sebbene migliorino notevolmente l'equit\u00e0. E controllo sempre la profondit\u00e0 della coda, il writeback e le opzioni del filesystem, in modo che la logica scelta raggiunga il suo potenziale. <strong>spettacoli<\/strong>.<\/p>\n\n<h2>Risoluzione dei problemi: leggere attentamente i sintomi<\/h2>\n\n<p>Quando i valori misurati cambiano, interpreto i modelli e dedico misure concrete:<\/p>\n<ul>\n  <li><strong>Elevata latenza P99 con molte letture<\/strong>: Verificare se le scritture prevalgono sulle letture. Testare con mq-deadline., <code>read_expire<\/code> ridurre, livellare il writeback (<code>vm.dirty_*<\/code> adattare).<\/li>\n  <li><strong>100% util su HDD, throughput basso<\/strong>: Dominano le ricerche. Provare BFQ o mq-deadline, ridurre il readahead, moderare la profondit\u00e0 della coda.<\/li>\n  <li><strong>Buoni valori di throughput, ma l'interfaccia utente \u00e8 instabile<\/strong>: l'interattivit\u00e0 ne risente. Attivare BFQ, servizi critici tramite <code>ionice -c1<\/code> o dare la preferenza ai pesi Cgroup.<\/li>\n  <li><strong>Forte variazione a seconda dell'ora del giorno<\/strong>: Risorse condivise. Isolare con cgroups, selezionare lo scheduler per ogni pool, spostare i backup nelle ore non di punta.<\/li>\n  <li><strong>Timeout NVMe in dmesg<\/strong>: Backend o tema firmware. <code>io_poll<\/code> Disattivare in via sperimentale, controllare firmware\/driver, verificare la ridondanza del percorso (multipath).<\/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>In breve: decisioni chiare per l'hosting quotidiano<\/h2>\n\n<p>Per l'archiviazione flash e gli ospiti, spesso opto per <strong>Noop<\/strong>, per risparmiare overhead e far funzionare i controller. Nei server allround con HDD o RAID, mq-deadline garantisce una latenza affidabile e un'elevata usabilit\u00e0. Con molti utenti attivi e un carico interattivo, BFQ assicura una distribuzione equa e una reattivit\u00e0 notevole. Prima di ogni registrazione, effettuo misurazioni con carichi di lavoro reali e osservo gli effetti su P95\/P99. In questo modo prendo decisioni comprensibili, mantengo i sistemi veloci e stabilizzo il <strong>Server<\/strong>-Prestazioni nell'attivit\u00e0 quotidiana.<\/p>","protected":false},"excerpt":{"rendered":"<p>Spiegazione dello scheduler I\/O Linux: noop, mq-deadline e BFQ per un hosting ottimale. Suggerimenti per l'ottimizzazione dello storage per le prestazioni del server.<\/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":"1822","_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\/it\/wp-json\/wp\/v2\/posts\/16149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=16149"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/16149\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/16142"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=16149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=16149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=16149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}