{"id":20858,"date":"2026-08-21T11:49:48","date_gmt":"2026-08-21T09:49:48","guid":{"rendered":"https:\/\/webhosting.de\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/"},"modified":"2026-08-21T11:49:48","modified_gmt":"2026-08-21T09:49:48","slug":"linux-rapporto-di-dati-sporchi-rapporto-di-dati-sporchi-in-background-ottimizzazione-writeback","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/","title":{"rendered":"Dirty Ratio e Dirty Background Ratio in Linux: messa a punto per prestazioni di scrittura ottimali"},"content":{"rendered":"<p>Mostro come <strong>linux dirty<\/strong> e il rapporto \"dirty background\" per controllare la cache della pagina e, di conseguenza, ottimizzare la velocit\u00e0 di scrittura, la latenza e la sicurezza dei dati. In questo modo puoi impostare valori limite precisi che attivano tempestivamente i flusher, evitano i blocchi e migliorano le prestazioni di scrittura dei tuoi carichi di lavoro.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>Per cominciare, riassumer\u00f2 brevemente i punti salienti prima di approfondire l'argomento.<\/p>\n<ul>\n  <li><strong>Pagine sconvenienti<\/strong> Memorizza i dati in RAM e raggruppa numerosi piccoli accessi in operazioni di I\/O pi\u00f9 efficienti.<\/li>\n  <li><strong>rapporto_di_sfondo_sporco<\/strong> avvia thread di pulizia in background, limitando cos\u00ec in modo impercettibile la quantit\u00e0 di dati inutili.<\/li>\n  <li><strong>rapporto_sporco<\/strong> rallenta i processi di scrittura quando viene superato il limite massimo.<\/li>\n  <li><strong>Relazione<\/strong> Entrambi questi valori determinano i picchi di latenza, la velocit\u00e0 di trasmissione e la dimensione del buffer.<\/li>\n  <li><strong>Varianti di Bytes<\/strong> (dirty_bytes) offrono un controllo pi\u00f9 preciso e assoluto sui server di grandi dimensioni.<\/li>\n<\/ul>\n\n<h2>Capire le \"Dirty Pages\"<\/h2>\n\n<p>Quando un processo scrive dei dati, questi finiscono prima nel <strong>Cache della pagina<\/strong> e vengono contrassegnati come \u201edirty\u201c finch\u00e9 il kernel non riesce a scaricarli sul supporto di memoria. Questo buffering accelera le applicazioni, poich\u00e9 la RAM reagisce pi\u00f9 rapidamente di qualsiasi SSD o HDD e le piccole operazioni di scrittura si aggregano in grandi trasferimenti sequenziali. In questo contesto tengo sempre presente quanta \u201esporcizia\u201c mi concedo, poich\u00e9 un buffer eccessivo pu\u00f2 allungare le code o comportare un rischio maggiore di dati non salvati in caso di arresti anomali. Chi ne comprende il funzionamento prende decisioni migliori in merito a writeback, latenza e pressione sulla memoria. Un breve articolo di approfondimento sul <a href=\"https:\/\/webhosting.de\/it\/cache-di-writeback-cache-del-kernel-linux\/\">Cache di writeback<\/a> aiuta a inquadrare chiaramente questo meccanismo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-schreibfeintuning-7492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sicurezza dei dati, fsync e finestra di crash<\/h2>\n<p>I valori limite non influenzano solo le prestazioni, ma anche la tua finestra di rischio. La calcolo con una semplice regola empirica: la quantit\u00e0 massima di dati non salvati divisa per la velocit\u00e0 di trasferimento sostenibile del dispositivo d\u00e0 approssimativamente il tempo necessario affinch\u00e9 il buffer si svuoti. Esempio: se ammetto 4 GB di dati non validi e il supporto di destinazione raggiunge i 500 MB\/s, la scrittura completa richiede circa 8 secondi. In questo lasso di tempo, in caso di interruzione di corrente o di kernel panic, le scritture pi\u00f9 recenti potrebbero andare perse.<\/p>\n<p>Le applicazioni possono chiudere la finestra tramite <code>fsync()<\/code> oppure <code>fdatasync()<\/code> ridurre, poich\u00e9 questi accessi costringono il file system a scrivere i dati (e, a seconda della modalit\u00e0 di journaling, anche i metadati) sul supporto. Si tratta di un\u2019operazione pi\u00f9 onerosa, ma essenziale per i database o i journal. Mi assicuro che i miei limiti di dati sporchi siano in linea con il comportamento di sincronizzazione: frequenti <code>fsync()<\/code>-Le visualizzazioni beneficiano di un <em>rapporto_sporco<\/em>, in modo che il kernel non riduca ulteriormente la velocit\u00e0 quando la persistenza avviene comunque regolarmente. Al contrario, nel caso di log che utilizzano prevalentemente l'append e che vengono svuotati raramente, posso consentire buffer pi\u00f9 grandi \u2013 sempre tenendo conto del rischio di perdita accettabile.<\/p>\n<p>Sono importanti anche le barriere e le sequenze di scrittura: i moderni sistemi di file utilizzano comandi FUA\/Flush per svuotare correttamente le cache dei controller. Su supporti privi di protezione contro la perdita di alimentazione (PLP), buffer di grandi dimensioni aumentano il rischio; con la PLP o la protezione della cache di scrittura, buffer pi\u00f9 grandi sono spesso accettabili.<\/p>\n\n<h2>Dirty Background Ratio: il valore di soglia morbido<\/h2>\n\n<p>Con <strong>rapporto_di_sfondo_sporco<\/strong> Indico a partire da quale percentuale di memoria disponibile i thread di flushing iniziano a scrivere in background. Questo valore non blocca le applicazioni, ma avvia silenziosamente le operazioni di pulizia per evitare che il buffer si riempia eccessivamente. Valori bassi generano una scrittura in background pi\u00f9 frequente ma pi\u00f9 uniforme e smussano i picchi di latenza. Valori pi\u00f9 alti consentono un buffer pi\u00f9 ampio, il che aumenta la velocit\u00e0 effettiva in caso di scritture sequenziali di grandi dimensioni, ma pu\u00f2 causare notevoli picchi di I\/O in caso di flush improvvisi. In genere i valori predefiniti si aggirano intorno al dieci per cento, ma io modifico questo limite a seconda del supporto, del carico di lavoro e dei requisiti di sicurezza.<\/p>\n\n<h2>Dirty Ratio: la frenata brusca<\/h2>\n\n<p>Il parametro <strong>rapporto_sporco<\/strong> indica il limite oltre il quale il kernel limita i processi in fase di scrittura, finch\u00e9 non vengono riscritte un numero sufficiente di pagine. Questo limite rigido protegge la memoria da un\u2019ondata di dati non persistenti e incide quindi direttamente sulle applicazioni non appena queste intendono continuare a generare dati. Per i database, imposto un valore piuttosto basso, in modo che le query mantengano tempi di risposta costanti e non si verifichino lunghe fasi di flush. Per i processi di backup, invece, utilizzo buffer pi\u00f9 generosi per trasferire in modo efficiente blocchi di grandi dimensioni. I valori predefiniti standard variano tra il venti e il quaranta per cento, ma io adeguo sempre questo intervallo al carico effettivo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_perf_neu_opt_3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interazioni e relazioni tipiche<\/h2>\n\n<p>Entrambi i valori limite funzionano come <strong>Tandem<\/strong> e producono effetto solo insieme. Mantengo sempre il valore di `dirty_background_ratio` inferiore a quello di `dirty_ratio`, in modo che il kernel si avvii per tempo in background e il freno duro scatti raramente. Come regola empirica, scelgo spesso un valore compreso tra un quarto e la met\u00e0 del limite massimo, ad esempio 5\u201310 rispetto a 20. In questo modo il writeback viene avviato con sufficiente anticipo, senza ridurre inutilmente la velocit\u00e0 di trasmissione. Chi non rispetta questo rapporto, si trover\u00e0 di fronte a una limitazione troppo precoce o a un'elaborazione in background troppo tardiva, con picchi di latenza percepibili.<\/p>\n\n<h2>Controllo per dispositivo e granularit\u00e0 del livello di blocco<\/h2>\n<p>Oltre ai limiti globali, vale la pena dare un\u2019occhiata al livello dei dispositivi. Linux distribuisce il carico \u201cdirty\u201d tramite i cosiddetti <em>Dispositivi supportati<\/em> (bdi). In <code>\/sys\/class\/block\/\/bdi\/<\/code> Trovo che parametri come <code>max_ratio<\/code>, che stabiliscono quale quota del \u201cDirty Budget\u201d consentito a livello globale possa essere utilizzata da una singola unit\u00e0. Nei sistemi in cui coesistono unit\u00e0 lente e veloci, limito le unit\u00e0 lente in modo che non diventino un collo di bottiglia.<\/p>\n<p>Altrettanto rilevante \u00e8 la limitazione a livello di blocco tramite <code>\/sys\/block\/\/queue\/wbt_lat_usec<\/code> (Writeback Throttling). In questo modo punto a una latenza target; il kernel limita il carico di scrittura quando questo supera il tempo target. Con gli HDD SATA preferisco impostare valori prudenti per garantire l'interattivit\u00e0. Su unit\u00e0 NVMe molto veloci, disattivo o aumento la latenza target, in modo che il controller possa sfruttare appieno il suo parallelismo. Scelgo lo scheduler I\/O (mq-deadline, BFQ, none) in base alle esigenze: BFQ \u00e8 utile nei sistemi interattivi con carico misto, mentre <em>nessuno<\/em> oppure mq-deadline spesso funziona meglio nei lavori di puro throughput su NVMe.<\/p>\n<p>L'interazione \u00e8 fondamentale: se <em>rapporto_di_sfondo_sporco<\/em> basso, ma poich\u00e9 il dispositivo \u00e8 soggetto a limitazioni aggressive da parte di WBT, si verificano comunque congestioni visibili. Pertanto, calibro entrambi i livelli insieme: limiti globali di \u201cdirty\u201d per la dimensione del buffer e il livello di blocco per la protezione dalla latenza.<\/p>\n\n<h2>Ratio vs. Bytes: valori predefiniti e varianti<\/h2>\n\n<p>Su sistemi con molta <strong>RAM<\/strong> I valori percentuali crescono rapidamente fino a raggiungere grandi ordini di grandezza assoluti. In tal caso, preferisco introdurre limiti massimi assoluti con `dirty_bytes` e `dirty_background_bytes`, per limitare chiaramente la quantit\u00e0 di buffer a circa 2\u20138 GB. Ci\u00f2 disaccoppia la regolazione dai livelli di espansione della memoria fortemente variabili e mantiene calcolabile la quantit\u00e0 di dati non persistenti. La scelta rimane dinamica: per i server di piccole dimensioni con poca RAM, le percentuali sono spesso del tutto sufficienti. Chi dispone di una capacit\u00e0 elevata, spesso trova pi\u00f9 prevedibile utilizzare valori in byte.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametri<\/th>\n      <th>Significato<\/th>\n      <th>Valori predefiniti tipici<\/th>\n      <th>Quando cambiare?<\/th>\n      <th>Suggerimento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>Inizio del <strong>Flush di sfondo<\/strong> in percentuale<\/td>\n      <td>\u2248 10%<\/td>\n      <td>In caso di fluttuazioni della latenza o di SSD\/NVMe molto veloci<\/td>\n      <td>Pi\u00f9 basso = latenza pi\u00f9 regolare, pi\u00f9 alto = pi\u00f9 buffer<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>Duro <strong>Limite di strozzamento<\/strong> in percentuale<\/td>\n      <td>\u2248 20\u201340%<\/td>\n      <td>Pi\u00f9 basso per i database, pi\u00f9 alto per i backup<\/td>\n      <td>Troppo alto \u2192 Possibili blocchi durante il flush<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_background_bytes<\/td>\n      <td>Avvio del flush in background in <strong>Byte<\/strong><\/td>\n      <td>Disattivato se si utilizza Ratio<\/td>\n      <td>Molta RAM, obiettivi di buffer fissi<\/td>\n      <td>Disattiva i parametri di Ratio<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_bytes<\/td>\n      <td>Limite rigido per il tordo in <strong>Byte<\/strong><\/td>\n      <td>Disattivato se si utilizza Ratio<\/td>\n      <td>Molta RAM, limite massimo pianificabile<\/td>\n      <td>Disattiva i parametri di Ratio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Scenari di carico di lavoro e raccomandazioni<\/h2>\n\n<p>Carichi di scrittura sequenziali come <strong>Backup<\/strong> traggono vantaggio da buffer di grandi dimensioni e da una scrittura in background moderata, poich\u00e9 il kernel pu\u00f2 scrivere sul supporto a grandi blocchi. In questo caso, imposta spesso il `dirty_ratio` tra il 30 e il 40 per cento e il `dirty_background_ratio` tra il 10 e il 20 per cento. I database e le piccole applicazioni con I\/O casuale traggono vantaggio da una latenza prevedibile, pertanto scelgo il 10\u201315% per la latenza rigida e il 3\u20135% per quella flessibile. Per i server misti web e applicativi, il 15\u201320% per la scrittura in background rigida e il 5\u201310% per quella morbida si rivelano un buon compromesso. Questi intervalli valgono come punto di partenza; in seguito, ci\u00f2 che conta \u00e8 la realt\u00e0 misurata del proprio sistema.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-schreibperformance-feintuning-5648.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspetti relativi al file system e opzioni di montaggio<\/h2>\n<p>Il percorso di writeback termina nel file system, la cui strategia determina le latenze e la sicurezza. Ext4 con <em>dati=ordinati<\/em> (Impostazione predefinita) scrive i dati utente prima dei commit del journal; <em>dati=riscrittura<\/em> riduce la latenza, ma comporta il rischio di perdere i dati precedenti in caso di crash. Il parametro <code>impegnarsi=<\/code> (secondi) determina la frequenza con cui il journal viene salvato. Intervalli pi\u00f9 brevi riducono la perdita di dati, ma comportano un maggiore carico di I\/O. XFS utilizza un design del log ben collaudato; grandi <em>logbsize<\/em> e un allineamento adeguato favoriscono le operazioni ad alta produttivit\u00e0. Btrfs raggruppa le operazioni di scrittura tramite il meccanismo \u201ccopy-on-write\u201d: ci\u00f2 stabilizza le latenze, ma pu\u00f2 causare frammentazione in caso di piccole operazioni di scrittura casuale e SSD con capacit\u00e0 limitata. Opzioni come <em>nodatacow<\/em> possono essere utili per determinati percorsi o per una deframmentazione mirata in caso di picchi di latenza.<\/p>\n<p>Prendo inoltre atto che <em>relatime<\/em>\/<em>noatime<\/em> (riduce le operazioni di scrittura dei metadati), <em>pigrizia<\/em> (mtime\/atime pi\u00f9 persistenti) e barriere di journaling. Proprio sui controller RAID o nelle macchine virtuali, la corretta semantica della cache \u00e8 fondamentale: le cache di scrittura impostate in modo errato vanificano ogni lavoro di \u201cdirty tuning\u201d.<\/p>\n\n<h2>I\/O diretto, O_SYNC e comportamento dell'applicazione<\/h2>\n<p>Non tutte le richieste passano attraverso la cache delle pagine. Con <code>O_DIRETTO<\/code> oppure <code>O_SYNC<\/code>\/<code>O_DSYNC<\/code> I processi aggirano parti della cache o richiedono una persistenza immediata. I database in genere scrivono un WAL\/redo log in modo sincrono e le aree di dati in modo asincrono. Calibro i limiti di dirty in particolare per i percorsi asincroni, mentre garantisco la latenza ai percorsi sincroni tramite journal veloci (NVMe, LUN dedicati). Se le applicazioni eseguono molto frequentemente <code>fsync()<\/code> Quando si esegue una chiamata, i buffer di grandi dimensioni sono poco utili: la latenza dipende allora pi\u00f9 dal controller, dalla profondit\u00e0 della coda e dallo scheduler I\/O che da <em>rapporto_sporco<\/em>.<\/p>\n\n<h2>Messa a punto pratica passo dopo passo<\/h2>\n\n<p>Prima di ogni modifica, controllo il <strong>valori effettivi<\/strong> con <code>sysctl vm.dirty_ratio<\/code> e <code>sysctl vm.dirty_background_ratio<\/code>, per documentare la situazione iniziale. Per i test a breve termine, annoto i valori direttamente dopo <code>\/proc\/sys\/vm\/<\/code>per esempio <code>echo 15 &gt; \/proc\/sys\/vm\/dirty_ratio<\/code> e <code>echo 5 &gt; \/proc\/sys\/vm\/dirty_background_ratio<\/code>. Se l'adattamento \u00e8 permanente, lo salvo in <code>\/etc\/sysctl.conf<\/code> oppure <code>\/etc\/sysctl.d\/*.conf<\/code>. Apporto le modifiche con <code>sysctl -p<\/code> immediatamente, in modo da poter misurare l'effetto in tempi brevi. Chi approfondisce l'argomento delle regole di sistema trarr\u00e0 vantaggio da consigli pratici su <a href=\"https:\/\/webhosting.de\/it\/ottimizzazione-delle-prestazioni-dei-server-di-web-hosting-tramite-sysctl\/\">Ottimizzazione tramite sysctl<\/a> su server di produzione.<\/p>\n\n<h2>Determinazione dei valori: esempi di calcolo<\/h2>\n<p>Mi piace partire da parametri concreti. Esempio 1: server web\/app con 64 GB di RAM, NVMe. L\u2019obiettivo \u00e8 una latenza ottimale. Impostazione: <code>dirty_background_bytes=1073741824<\/code> (1 GB) e <code>dirty_bytes=3221225472<\/code> (3 GB). Con una velocit\u00e0 di trasferimento NVMe costante di 2 GB\/s, ci\u00f2 significa circa 0,5\u20131,5 secondi per lo svuotamento \u2013 ottimo per carichi interattivi. Esempio 2: nodo di backup con 128 GB di RAM, RAID SATA veloce a 800 MB\/s. Scelgo <code>dirty_background_ratio=10<\/code>, <code>dirty_ratio=35<\/code>. In termini assoluti si tratta di circa 12,8 GB e 44,8 GB; il RAID impiega 16\u201356 secondi per svuotarsi. Va bene cos\u00ec, perch\u00e9 il processo non \u00e8 interattivo.<\/p>\n<p>Esempio 3: server di database con 256 GB di RAM, journal separato su NVMe, dati su array SSD. Imposto un limite assoluto per evitare valori anomali: <code>dirty_background_bytes=2147483648<\/code> (2 GB), <code>dirty_bytes=8589934592<\/code> (8 GB). Ci\u00f2 consente di mantenere le dimensioni della finestra di crash entro limiti prevedibili e riduce le brusche frenate durante i checkpoint.<\/p>\n\n<h2>Temporizzazione del writeback e parametri correlati<\/h2>\n\n<p>Oltre ai valori limite, influiscono <strong>Timer<\/strong> il comportamento di writeback e, di conseguenza, la fluidit\u00e0 delle applicazioni. Con <code>vm.dirty_writeback_centisecs<\/code> regolo l'intervallo con cui il kernel flusher viene riattivato, mentre <code>vm.dirty_expire_centisecs<\/code> definisce il tempo massimo che le pagine sporche possono rimanere in memoria. Intervalli pi\u00f9 brevi garantiscono flush pi\u00f9 frequenti ma di dimensioni inferiori, mentre intervalli pi\u00f9 lunghi riducono le chiamate I\/O, ma comportano il rischio di blocchi pi\u00f9 grandi. Modifico questi valori solo se le misurazioni evidenziano effettivi svantaggi, come ad esempio flush troppo rari su unit\u00e0 NVMe veloci. Adottando un approccio metodico, si evita l\u2019oscillazione tra un\u2019attivit\u00e0 di writeback troppo frenetica e una troppo lenta.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_performance_finetune_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoraggio e messa a punto<\/h2>\n\n<p>Dopo aver apportato alcune modifiche, noto che <strong>continuo<\/strong> gli indicatori chiave per mettere in evidenza i risultati positivi e gli effetti collaterali. In <code>\/proc\/meminfo<\/code> Controllo \u201eDirty\u201c e \u201eWriteback\u201c per verificare i livelli dei buffer e i flush attivi. Strumenti come iostat, sar o atop mi mostrano il throughput, le code e l\u2019andamento della latenza. Questo articolo offre un\u2019ottima introduzione alle metriche relative a <a href=\"https:\/\/webhosting.de\/it\/server-io-aspettare-analizzare-iostat-vmstat-metriche-disco\/\">Analisi dell'attesa I\/O<\/a>. Solo sulla base di questi dati riduco o aumento i limiti a piccoli passi, in modo da evitare effetti collaterali imprevisti.<\/p>\n\n<h2>Container, cgroups e distribuzione equa<\/h2>\n<p>Negli ambienti containerizzati, i carichi di lavoro condividono gli stessi meccanismi del kernel. Il writeback dei cgroup garantisce che le pagine sporche vengano attribuite a chi le ha generate. Utilizzo i controller I\/O dei cgroup (blkcg) per limitare la larghezza di banda o gli IOPS per ciascun container, qualora singoli tenant utilizzino la cache in modo troppo aggressivo. Limiti assoluti in byte a livello di host (<em>byte_sporchi<\/em>) per evitare che un singolo ospite prosciughi l\u2019intero budget per le spese extra. Inoltre, limito lo spazio di archiviazione tramite <code>memoria.max<\/code>, in modo che il writeback non reagisca solo in caso di pressione globale. L'obiettivo rimane: nessun carico ospite deve causare limitazioni a livello di host del <em>rapporto_sporco<\/em> imporre.<\/p>\n\n<h2>Ambienti di hosting e macchine virtuali<\/h2>\n\n<p>Nelle configurazioni multi-cliente e nelle macchine virtuali, faccio attenzione a <strong>Overbooking<\/strong> di RAM e I\/O, poich\u00e9 in questi casi i limiti percentuali hanno un impatto diverso. I limiti assoluti in byte possono impedire che singoli guest accumulino troppo buffer e rallentino i vicini. Prendo in considerazione la deduplicazione della memoria, il ballooning e le cache dei controller, poich\u00e9 questi fattori si sovrappongono agli effetti di buffering. Per i server gestiti, \u00e8 vantaggioso che il fornitore imposti valori predefiniti adeguati, in modo che i clienti possano beneficiare di tempi di risposta costanti. Chi gestisce i propri nodi trae vantaggio da impostazioni di profilo ben definite per ciascuna classe di carico di lavoro.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/DirtyRatioTuning1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Malintesi comuni e ostacoli<\/h2>\n<ul>\n  <li><strong>\u201eMaggiore margine = sempre maggiore produttivit\u00e0.\u201c<\/strong> Non \u00e8 corretto in caso di carichi di lavoro prevalentemente casuali o di dispositivi con una profondit\u00e0 di coda ridotta. Buffer troppo grandi generano picchi di flush e code.<\/li>\n  <li><strong>\u201edirty_ratio non influisce sui read.\u201c<\/strong> In modo indiretto, s\u00ec: le fasi di writeback aggressive sostituiscono le pagine della cache e aumentano le latenze di lettura.<\/li>\n  <li><strong>\u201eI byte e la ragione si sommano.\u201c<\/strong> No. Se imposti le varianti \"Bytes\", queste annullano le corrispondenti \"Ratio\". Rimani chiaro.<\/li>\n  <li><strong>\u201efsync() rende irrilevanti i limiti di dati non salvati.\u201c<\/strong> No. Sebbene le sincronizzazioni frequenti riducano la finestra di rischio, il resto del carico rimane comunque soggetto ai valori limite.<\/li>\n  <li><strong>\u201eUn supporto dati veloce risolve tutto.\u201c<\/strong> Non se il Block-Layer limita la velocit\u00e0 (WBT) o se il file system \u00e8 montato in modo non ottimale.<\/li>\n  <li><strong>\u201eDrop_caches \u00e8 uno strumento di ottimizzazione.\u201c<\/strong> Lo svuotamento della cache distorce le misurazioni e aggrava i picchi di latenza. In produzione cerco di evitarlo.<\/li>\n<\/ul>\n\n<h2>Risoluzione dei problemi: sintomi tipici e soluzioni<\/h2>\n\n<p>Accumulare <strong>Picchi di latenza<\/strong>, per prima cosa abbasso la soglia di background, in modo che i flusher inizino prima e si verifichino meno spesso grandi picchi di scrittura. Se le applicazioni si bloccano a tratti, il limite massimo \u00e8 solitamente troppo alto oppure il supporto non riesce a gestire i picchi di flush che si generano. In questi casi abbasso il dirty_ratio, controllo le impostazioni di readahead e verifico le opzioni di journaling del file system. Con hardware NVMe molto veloce, aumento gradualmente la soglia di background per non limitare artificialmente la velocit\u00e0 di trasferimento. Dopo ogni modifica mi affido ai dati di monitoraggio, non all\u2019istinto.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-schreibperformance-5712.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Breve bilancio per la pratica<\/h2>\n\n<p>Con pochi <strong>Viti di regolazione<\/strong> Posso influenzare il modo in cui Linux memorizza i dati in scrittura nel buffer, quando vengono avviati i flusher e quando il kernel rallenta. Il \u00abDirty Background Ratio\u00bb garantisce una pulizia silenziosa, mentre il \u00abDirty Ratio\u00bb limita in modo pi\u00f9 rigido il consumo di RAM. Il rapporto tra questi due valori determina se il sistema punta a latenze costanti o alla massima velocit\u00e0 di trasmissione. Documenter\u00f2 le impostazioni predefinite, apporter\u00f2 modifiche graduali e valuter\u00f2 le misurazioni in modo coerente. In questo modo si ottiene una configurazione che bilancia in modo ragionevole carico di lavoro, supporto e rischio e che, nella pratica, risulta sensibilmente pi\u00f9 veloce.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come ottimizzare in modo mirato le prestazioni di scrittura e quelle del kernel del tuo server utilizzando i parametri \u201cdirty ratio\u201d e \u201cdirty background ratio\u201d di Linux, e come gestire in modo efficiente le pagine sporche.<\/p>","protected":false},"author":1,"featured_media":20851,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20858","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":"144","_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 dirty","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":"20851","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20858","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=20858"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20851"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}