{"id":20548,"date":"2026-08-11T15:09:51","date_gmt":"2026-08-11T13:09:51","guid":{"rendered":"https:\/\/webhosting.de\/writeback-cache-linux-kernel-cache\/"},"modified":"2026-08-11T15:09:51","modified_gmt":"2026-08-11T13:09:51","slug":"cache-di-writeback-cache-del-kernel-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/writeback-cache-linux-kernel-cache\/","title":{"rendered":"Comprendere la cache di writeback e le pagine sporche nel kernel Linux"},"content":{"rendered":"<p>La cache di writeback nel kernel di Linux controlla quando i dati modificati vengono salvati come <strong>Pagine sporche<\/strong> rimangono nella RAM e quando il kernel li scrive in blocco sul supporto di memoria. Spiego come funziona questo processo <strong>Prestazioni<\/strong>, le latenze e la sicurezza dei dati, e quali regolatori contano davvero nella vita di tutti i giorni.<\/p>\n\n<h2>Punti centrali<\/h2>\n<ul>\n  <li><strong>Pagine sporche<\/strong> contrassegnano le pagine modificate nella RAM che non sono ancora state salvate sul supporto di memorizzazione.<\/li>\n  <li><strong>Writeback<\/strong> raggruppa le modifiche e le scrive in modo efficiente in blocchi pi\u00f9 grandi.<\/li>\n  <li><strong>Valori di soglia<\/strong> Come vm.dirty_ratio, controllano la velocit\u00e0 e la limitazione.<\/li>\n  <li><strong>Sincronizzazione<\/strong> L'uso di fsync\/Flush protegge dalla perdita di dati.<\/li>\n  <li><strong>Monitoraggio<\/strong> Tramite \/proc e gli strumenti \u00e8 possibile visualizzare il carico e i ritardi.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxserver-writeback-3901.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Come funziona la cache delle pagine<\/h2>\n\n<p>Leggo un file, il kernel inserisce i dati nella cache di pagina e gli accessi successivi vengono effettuati dalla <strong>Memoria<\/strong> anzich\u00e9 dal disco. Durante la scrittura, il sistema contrassegna le pagine modificate come <strong>Sporco<\/strong> e spesso conferma immediatamente la richiesta, in modo che l'applicazione continui a funzionare. Questo disaccoppiamento riduce i tempi di attesa, poich\u00e9 gli accessi I\/O lenti non rallentano direttamente ogni applicazione. La cache mantiene inoltre a disposizione i blocchi utilizzati di frequente e aumenta la percentuale di successi in caso di accessi successivi. Chi desidera approfondire l\u2019argomento trover\u00e0 ulteriori informazioni nella mia panoramica su <a href=\"https:\/\/webhosting.de\/it\/filesystem-caching-linux-page-cache-cacheboost\/\">Caching del filesystem<\/a>, che illustra il ruolo dei percorsi di lettura e scrittura nella vita quotidiana.<\/p>\n\n<h2>Dirty Pages: significato e conseguenze<\/h2>\n\n<p>Le \"Dirty Pages\" sono pagine di memoria modificate che non sono ancora state salvate in modo permanente e che, pertanto, sono disponibili solo nella <strong>RAM<\/strong> esistono. Finch\u00e9 sono sporchi, indosso un certo <strong>Il rischio<\/strong>: Un'interruzione di corrente potrebbe annullare queste modifiche. Ciononostante, in questo modo si ottiene una velocit\u00e0 di scrittura maggiore, poich\u00e9 il kernel raggruppa molti piccoli aggiornamenti. Se la percentuale di pagine sporche aumenta, cresce la pressione sui moduli di riscrittura. A quel punto il sistema pu\u00f2 liberare memoria scrivendo le pagine in questione sul disco con priorit\u00e0.<\/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_kernel_meeting_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Writeback: fattori scatenanti e svolgimento<\/h2>\n\n<p>Il writeback viene avviato in base a un intervallo di tempo, in base a un evento e su richiesta <strong>Applicazioni<\/strong>. Il kernel raggruppa le pagine sporche, crea sequenze di I\/O adeguate e le inoltra tramite il livello a blocchi al <strong>Dispositivo di archiviazione<\/strong>. Lungo il percorso, i file system, i reclaimer e gli scheduler I\/O intervengono per controllare l'ordine e le dimensioni. Le chiamate di sincronizzazione come fsync garantiscono che determinati dati vengano salvati in modo sicuro sul supporto prima di proseguire. Nei periodi di elevata attivit\u00e0, nelle statistiche osservo una quota crescente di writeback, che torna a diminuire dopo il flush.<\/p>\n\n<h2>Meccanismi interni: balance_dirty_pages, BDI e Writeback-Worker<\/h2>\n\n<p>Sotto il cofano, diversi componenti interagiscono tra loro. I thread di scrittura passano attraverso <strong>balance_dirty_pages()<\/strong>, che tiene conto del carico di dati sporchi attuale, della velocit\u00e0 del dispositivo e dei limiti impostati. Regola la velocit\u00e0 di scrittura dei processi (throttling) in modo che il writeback in background riesca a stare al passo. Ogni <strong>Dispositivo di supporto<\/strong>-Contesto (bdi) \u2013 in genere un dispositivo a blocchi o un backend del file system \u2013 dispone di proprie code di lavoro con <strong>Thread di flushing<\/strong>, che trasformano le \"Dirty Pages\" in richieste di I\/O ordinate. Questa ripartizione impedisce che un dispositivo lento rallenti tutti gli altri e migliora l'equit\u00e0 tra i carichi di lavoro.<\/p>\n\n<p>La limitazione \u00e8 adattiva: quando rilevo operazioni di scrittura pi\u00f9 veloci o blocchi contigui pi\u00f9 grandi, le quantit\u00e0 di dati \u201cdirty\u201d consentite aumentano temporaneamente. In caso di congestione, latenze elevate o code sature, il kernel interviene in modo pi\u00f9 aggressivo, costringendo gli scrittori a sospendere l'attivit\u00e0 fino a quando il buffer non ha nuovamente spazio a disposizione. \u00c8 proprio questa interazione a spiegare perch\u00e9 piccole variazioni dei parametri possano portare a profili di latenza sensibilmente diversi.<\/p>\n\n<h2>Valori soglia: vm.dirty_background_ratio e vm.dirty_ratio<\/h2>\n\n<p>Regolo il comportamento fissando due limiti importanti, che determinano la percentuale di pagine contaminate rispetto al <strong>RAM<\/strong> definire. Se supero il valore di fondo, il kernel inizia a <strong>Contesto<\/strong> di scrittura. Se raggiungo il limite massimo, il sistema limita i processi di scrittura finch\u00e9 non vengono restituiti dati a sufficienza. In questo modo la memoria rimane utilizzabile, anche se singoli programmi generano grandi quantit\u00e0 di modifiche. Chi lavora con limiti basati sui byte, imposta i corrispondenti parametri *_bytes al posto dei valori di rapporto.<\/p>\n\n<h2>Tabella: Parametri chiave del kernel e indicatori rilevanti<\/h2>\n\n<p>Utilizzo alcuni comandi chiave per gestire in modo mirato e rendere visibili il writeback, la latenza e la velocit\u00e0 di trasmissione; la seguente panoramica aiuta a <strong>Classificazione<\/strong> e veloci <strong>Esame<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametro\/Indicatore<\/th>\n      <th>Effetto<\/th>\n      <th>Valori iniziali\/Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio \/ vm.dirty_background_bytes<\/td>\n      <td>Avvia il writeback in background quando la percentuale di pagine corrotte supera tale valore di soglia.<\/td>\n      <td>Per i server, \u00e8 consigliabile optare per un\u2019impostazione piuttosto conservativa, in modo che il flush venga avviato prima.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio \/ vm.dirty_bytes<\/td>\n      <td>Limite massimo per le \"Dirty Pages\"; superato questo limite, gli scrittori vengono limitati.<\/td>\n      <td>Se \u00e8 troppo alta, aumenta i rischi legati alla latenza; se \u00e8 troppo bassa, si perde in termini di throughput.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisecs<\/td>\n      <td>Intervallo di tempo in cui il kernel verifica la presenza di pagine sporche per lo svuotamento in background.<\/td>\n      <td>Intervalli pi\u00f9 brevi attenuano i picchi di carico, ma generano un maggior numero di wakeup.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>Et\u00e0 a partire dalla quale le \u201eDirty Pages\u201c sono considerate \u201cmature\u201d e vengono scritte in via prioritaria.<\/td>\n      <td>Valori pi\u00f9 elevati aumentano la concentrazione, ma riducono le garanzie di coerenza in caso di errore.<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/meminfo: Dirty, Writeback<\/td>\n      <td>Numero attuale di pagine sporche o cancellate in modo attivo.<\/td>\n      <td>Utile per l'osservazione in tempo reale durante i test di carico.<\/td>\n    <\/tr>\n    <tr>\n      <td>Opzioni di montaggio\/FS (ad es. barriere, modalit\u00e0 journal)<\/td>\n      <td>Influenzano l'ordine, la persistenza e i costi dei singoli flush.<\/td>\n      <td>Selezionare in base al file system e al dispositivo.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Leggo regolarmente questi valori e li metto in relazione con i tempi di attesa I\/O in Top, iostat o strumenti simili <strong>Strumenti<\/strong>. Questo permette di capire chiaramente se \u00e8 il writeback stesso a essere limitato o se il <strong>Immagazzinamento<\/strong> \u00e8 al limite.<\/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-kernel-cache-dirty-pages-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoraggio e diagnosi: cosa misuro<\/h2>\n\n<p>Per prima cosa controllo \/proc\/meminfo e osservo i campi \"Dirty\" e \"Writeback\", mentre eseguo in modo mirato <strong>Carico<\/strong> genero. Se i prezzi salgono bruscamente e rimangono alti, spesso mancano i flush tempestivi oppure il <strong>Medio<\/strong> \u00e8 al massimo della capacit\u00e0. Se il writeback aumenta, ma il dirty diminuisce solo lentamente, il dispositivo di destinazione o il percorso I\/O rallentano il sistema. Se i picchi di latenza coincidono con i picchi di writeback, smusso l\u2019intervallo o riduco i valori del rapporto. Per avere un\u2019idea dei modelli tipici, mi \u00e8 d\u2019aiuto un breve <a href=\"https:\/\/webhosting.de\/it\/ottimizzatore-delle-prestazioni-della-cache-di-pagina-di-linux\/\">Ottimizzatore della cache delle pagine<\/a>, che riassume le viti di regolazione e i punti di misurazione.<\/p>\n\n<h2>Punti di misurazione avanzati, vmstat e tracciamento<\/h2>\n\n<p>Oltre a \/proc\/meminfo, utilizzo contatori molto dettagliati per distinguere causa ed effetto. In <strong>\/proc\/vmstat<\/strong> Campi come nr_dirty, nr_writeback, nr_dirtied e nr_written forniscono indicazioni sulla dinamica: con quale velocit\u00e0 avviene l\u2019inquinamento e con quale velocit\u00e0 avviene il flush? Inoltre, osservo la lunghezza delle code di I\/O e i tassi di interruzione delle operazioni di merge nel block layer.<\/p>\n\n<ul>\n  <li>vmstat 1: mostra al secondo la deriva di dirty\/writeback e l'attesa di I\/O (wa),<\/li>\n  <li>\/proc\/pressure\/memory: mostra la pressione sulla memoria che innesca indirettamente il writeback,<\/li>\n  <li>Tracepoint (writeback:*) ed eventi di blocco: rivelano l'ordine e la dimensione dei flush,<\/li>\n  <li>perf\/ftrace: identifica i punti critici in balance_dirty_pages e nelle code di lavoro del Flusher.<\/li>\n<\/ul>\n\n<p>Se noto che nr_dirtied \u00e8 costantemente superiore a nr_written, \u00e8 un chiaro segnale di un imminente rallentamento o di flush in background effettuati troppo tardi. Se i picchi nei tracepoint di writeback coincidono con i picchi di latenza, ottimizzo l\u2019intervallo e le dimensioni dei batch.<\/p>\n\n<h2>HDD vs. SSD: implicazioni per il design del writeback<\/h2>\n\n<p>Su i piatti rotanti, le serie pi\u00f9 lunghe e consecutive sono particolarmente redditizie, perch\u00e9 evitano costose ricerche <strong>Evitare<\/strong>. Anche gli SSD ne traggono vantaggio, ma in questo caso ci\u00f2 che conta \u00e8 la distribuzione delle operazioni di scrittura e l'interazione con il <strong>Controllore<\/strong>. Evito un numero eccessivo di piccole sincronizzazioni, in modo che il firmware possa funzionare in modo efficiente. Allo stesso tempo, con gli SSD presto maggiore attenzione alle barriere di coerenza e alla semantica del flush, per sfruttare appieno le garanzie offerte dal dispositivo. I carichi di lavoro misti con letture e scritture casuali reagiscono in modo tangibile a piccole regolazioni delle soglie di dirty e dei tempi 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\/2026\/08\/tech_office_nacht_6342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cache del dispositivo, semantica dello svuotamento e protezione contro le interruzioni di corrente (PLP)<\/h2>\n\n<p>Il fatto che un flush venga effettivamente eseguito dipende anche dal <strong>Cache del dispositivo<\/strong> . Molte unit\u00e0 di disco memorizzano i dati nella propria DRAM. Senza <strong>Protezione contro le perdite di potenza (PLP)<\/strong> Se la cache non viene svuotata in tempo, rischio di perdere i dati. Il writeback sfrutta s\u00ec la cache del dispositivo, ma mi assicuro che vengano rispettate le barriere e i comandi di flush. Sui sistemi dotati di controller RAID, valuto se \u00e8 presente una cache alimentata a batteria o supportata da memoria flash; in tal caso, le scritture sincronizzate sono spesso pi\u00f9 vantaggiose, senza compromettere la sicurezza.<\/p>\n\n<p>Faccio inoltre una distinzione: il FUA (Force Unit Access) impone la persistenza per ogni operazione di I\/O, ma comporta un costo in termini di IOPS. Le barriere di flush possono salvare pi\u00f9 operazioni di scrittura contemporaneamente. Per i percorsi particolarmente critici (come i journal), accetto l'overhead di FUA\/flush, mentre lascio i dati in blocco nel flusso di writeback. Chi modifica le opzioni di montaggio o le impostazioni del controller, verifica successivamente tramite test di carico che la semantica di flush prevista funzioni correttamente.<\/p>\n\n<h2>Coerenza dei dati: utilizzare correttamente fsync, Flush e FUA<\/h2>\n\n<p>Utilizzo fsync in modo mirato per i dati con un elevato <strong>Valore<\/strong>, che necessitano di una chiara garanzia di durabilit\u00e0. Il kernel pu\u00f2 eseguire operazioni di flush fino al supporto e, tramite FUA, richiedere che una scrittura venga effettivamente <strong>persiste<\/strong>, prima che arrivi la conferma. Questo approccio richiede tempo e IOPS, ma impedisce la perdita di dati in caso di arresti anomali. Senza tali barriere, il sistema segnala l\u2019avvenuta esecuzione anche se i byte si trovano ancora nella cache dell\u2019SSD o nella RAM. Adeguo queste decisioni in base all\u2019applicazione: i log delle transazioni vengono salvati in modo definitivo, mentre gli aggiornamenti in blocco in modo provvisorio.<\/p>\n\n<h2>Esempi di ottimizzazione per carichi di lavoro relativi a hosting e database<\/h2>\n\n<p>Per i server web e di database, imposta spesso un valore moderato per `dirty_background_ratio` e mantengo `dirty_ratio` ben al di sopra di esso, in modo da garantire che il flush in background avvenga tempestivamente <strong>inizio<\/strong>, senza che Schreiber si affretti a <strong>Freno<\/strong>. In caso di picchi di scrittura, riduco l\u2019intervallo di writeback affinch\u00e9 i processi di scrittura vengano attivati prima. Su sistemi con molta RAM preferisco i valori *_bytes, in modo che siano le dimensioni reali a fare la differenza anzich\u00e9 le percentuali. Testo ogni modifica con benchmark ripetibili e misuro la latenza, il throughput e i percentili al 95\u00b0 e al 99\u00b0. Questa panoramica pratica mi fornisce una guida sintetica sull\u2019effetto della cache di pagina: <a href=\"https:\/\/webhosting.de\/it\/ottimizzatore-delle-prestazioni-della-cache-di-pagina-di-linux\/\">Ottimizzazione delle prestazioni della cache di pagina di Linux<\/a>.<\/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\/devdesk_linux_cache_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Direct I\/O e mmap: quando si bypassa la cache di pagina<\/h2>\n\n<p>Non tutte le applicazioni utilizzano la cache di pagina allo stesso modo. Con <strong>O_DIRETTO<\/strong> pu\u00f2 bypassare intenzionalmente la cache e scrivere o leggere direttamente sul dispositivo. Questo alleggerisce il carico sulla RAM e accorcia i percorsi, ma mi priva dei vantaggi del batching e del readahead. Per trasferimenti di grandi dimensioni e una tantum ci\u00f2 pu\u00f2 essere utile; per molte piccole operazioni di scrittura, invece, perdo i vantaggi del writeback.<\/p>\n\n<p>Con <strong>mmap<\/strong> e con il Copy-on-Write contrassegno le pagine come \u201cdirty\u201d al momento della modifica; il flush avviene tramite il normale percorso di writeback oppure tramite <strong>msync<\/strong>. Ne tengo conto quando le applicazioni fanno ampio ricorso all'I\/O mappato in memoria: possono verificarsi picchi di dati non salvati in modo inaspettato, anche se l'applicazione \u201esemplicemente\u201c scrive in memoria. Anche in questo caso, i limiti di rapporto\/byte aiutano a controllare il momento della scrittura su disco.<\/p>\n\n<h2>Ambienti container e writeback dei cgroup<\/h2>\n\n<p>Nelle configurazioni multi-tenant, prevengo il fenomeno dei \u201eNoisy Neighbors\u201c tramite <strong>cgroups<\/strong>. Il kernel assegna le pagine sporche al gruppo responsabile (cgroup-Writeback), in modo che il flush in background e il throttling siano distribuiti in modo pi\u00f9 equo. Con i limiti di memoria (<strong>memoria.alta<\/strong>, memory.max) limito i picchi di memoria sporca per ogni container. Inoltre, imposto delle quote di I\/O tramite il controller I\/O, per evitare che singoli carichi di lavoro riempiano l'intera coda del dispositivo.<\/p>\n\n<p>In pratica, definisco limiti massimi realistici per ogni classe di servizio: ai job batch con un carico di scrittura elevato vengono assegnati budget \u201cdirty\u201d pi\u00f9 ampi, mentre ai frontend in cui la latenza \u00e8 critica ne vengono assegnati pi\u00f9 ristretti. In questo modo la latenza complessiva rimane pi\u00f9 stabile, poich\u00e9 il writeback non limita improvvisamente la velocit\u00e0 per tutti non appena un singolo container va fuori controllo.<\/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-kernel-cache-8974.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sistemi di file in rete (NFS, SMB, sistemi di file distribuiti)<\/h2>\n\n<p>Nei file system di rete si aggiunge un ulteriore livello di buffer. Le pagine sporche locali segnalano solo che i dati sono in transito; se <strong>da remoto<\/strong> \u00c8 il protocollo (semantica di commit) e il server a decidere se i dati sono stati salvati in modo permanente. Non mi affido ai flush impliciti: sincronizzo esplicitamente i dati critici. Allo stesso tempo, tengo conto dei costi di round-trip: sincronizzazioni troppo frequenti sulla rete peggiorano sensibilmente le latenze.<\/p>\n\n<p>Nei carichi di lavoro misti separo i percorsi: i file locali e temporanei traggono il massimo vantaggio dalla cache di pagina; ai mount di rete vengono assegnati punti di sincronizzazione pi\u00f9 rigidi. In questo modo evito che il writeback attraverso la rete diventi un collo di bottiglia, mentre i processi locali avrebbero ancora risorse disponibili.<\/p>\n\n<h2>Scheduler I\/O, blk-mq e profondit\u00e0 della coda<\/h2>\n\n<p>L'efficienza con cui i batch di writeback vengono trasferiti sul dispositivo dipende anche dal <strong>Blocklayer<\/strong> da. Con <strong>blk-mq<\/strong> Gli I\/O vengono distribuiti su pi\u00f9 code; gli scheduler come mq-deadline o kyber stabiliscono le priorit\u00e0 e li ordinano. Scelgo lo scheduler in base al supporto: su NVMe spesso \u00e8 opportuno impostare \u201enone\u201c, mentre su SATA o SAS Deadline aiuta a ordinare le operazioni di scrittura.<\/p>\n\n<p>Il sito <strong>Profondit\u00e0 della coda<\/strong> Lo imposta in modo che il dispositivo sia sfruttato al massimo, ma non sovraccarico. Una profondit\u00e0 troppo bassa riduce la velocit\u00e0 di elaborazione, mentre una troppo profonda aumenta la dispersione della latenza e rende il throttling pi\u00f9 difficile. Il writeback trae vantaggio da profondit\u00e0 moderate e da richieste grandi e contigue. Monitoro i tassi di merge e i contatori \u201einflight\u201c; un calo dei tassi di merge indica batch troppo piccoli o carichi di lavoro casuali in competizione tra loro.<\/p>\n\n<h2>Test riproducibili e rollback sicuro<\/h2>\n\n<p>Prima di regolare i comandi, registro lo stato attuale e verifico <strong>Riproducibile<\/strong> e pianifico i passi indietro. Utilizzo carichi di lavoro identici, quantit\u00e0 di dati identiche e preriscaldo la cache in modo mirato oppure la svuoto intenzionalmente, per rendere comparabili le esecuzioni di test. Applico le modifiche alle impostazioni prima in modo temporaneo, osservo le metriche e solo successivamente le salvo in modo permanente.<\/p>\n\n<pre><code># Esempio: modifiche temporanee alle impostazioni (Root)\nsysctl -w vm.dirty_background_bytes=$((512*1024*1024))\nsysctl -w vm.dirty_bytes=$((2*1024*1024*1024))\nsysctl -w vm.dirty_writeback_centisecs=100\nsysctl -w vm.dirty_expire_centisecs=3000\n\n# Breve test di carico (esempio, a seconda del carico di lavoro)\n# fio --name=wbtest --filename=\/data\/testfile --size=8G --ioengine=libaio \\\n#     --rw=randwrite --bs=128k --iodepth=32 --direct=0 --numjobs=4 --runtime=60 --time_based\n<\/code><\/pre>\n\n<p>Nel frattempo leggo in parallelo \/proc\/meminfo, vmstat e iostat e metto in correlazione i picchi. Al termine del test, ripristino i valori o li inserisco in modo controllato nella configurazione di sistema. A tal fine, documento <strong>data<\/strong>, <strong>Kernel<\/strong>- Versione, dettagli sul dispositivo e sul file system, affinch\u00e9 i confronti successivi rimangano attendibili.<\/p>\n\n<h2>Problemi ricorrenti e soluzioni<\/h2>\n\n<p>Se il sistema sembra funzionare in modo fluido, ma le operazioni di scrittura si bloccano, controllo se c\u2019\u00e8 un throttling dovuto a un valore troppo basso <strong>rapporto_sporco<\/strong>. Se Dirty rimane a un livello elevato, manca la larghezza di banda oppure il <strong>Intervallo<\/strong> \u00e8 troppo lungo per il flush. Se le latenze aumentano a dismisura in caso di brevi picchi di sincronizzazione, distribuisco il carico su batch pi\u00f9 piccoli e ottimizzo la pianificazione dell\u2019I\/O. Se la cache stenta a prendere velocit\u00e0, forse un limite *_bytes troppo basso impedisce un batching efficace. Uno sguardo pi\u00f9 approfondito a <a href=\"https:\/\/webhosting.de\/it\/server-page-cache-eviction-linux-memoria-stampa-ottimizzazione-insight\/\">Eviction della cache durante la stampa<\/a> \u00e8 utile quando a complicare le cose si aggiunge anche la carenza di memoria.<\/p>\n\n<h2>Migliori pratiche e breve lista di controllo<\/h2>\n\n<p>Faccio una netta distinzione tra i dati che devono essere salvati immediatamente e quelli che possono essere salvati in un secondo momento, al fine di <strong>Prestazioni<\/strong> da ottenere. Per i log e i giornali delle transazioni impongo le sincronizzazioni; per gli artefatti temporanei lascio che il writeback funzioni liberamente e tengo d\u2019occhio solo il limite di throttling. Prima di ogni modifica, misuro lo stato attuale e confronto i risultati A\/B attraverso scenari definiti. Tengo sotto controllo il numero di writer simultanei, poich\u00e9 picchi non coordinati riducono i vantaggi del batching. Inoltre, documento immediatamente le modifiche, in modo che le analisi future possano basarsi su dati chiari <strong>Dati<\/strong> basato.<\/p>\n\n<h2>Sintesi pratica per ottenere risultati rapidi<\/h2>\n\n<p>La cache di writeback raggruppa le modifiche nel <strong>Pagina<\/strong> La cache riduce i costi di I\/O e alleggerisce il carico sulle applicazioni. Le pagine sporche non sono un errore, ma uno strumento mirato per guadagnare velocit\u00e0, purch\u00e9 si conoscano i limiti e i requisiti di coerenza. Con i parametri vm.dirty_background_ratio e vm.dirty_ratio regolo quando il kernel opera silenziosamente in background e quando rallenta le operazioni di scrittura. Gli strumenti e \/proc mi forniscono la visione necessaria su \u00abDirty\u00bb e \u00abWriteback\u00bb, in modo da non brancolare nel buio. Se padroneggio queste leve, il web, i database e i lavori batch funzionano in modo sensibilmente pi\u00f9 veloce, senza che la <strong>Integrit\u00e0<\/strong> mettere a rischio i miei dati.<\/p>","protected":false},"excerpt":{"rendered":"<p>Cache di riscrittura nel kernel Linux: pagine sporche, cache delle pagine e riscrittura spiegate in modo chiaro.<\/p>","protected":false},"author":1,"featured_media":20541,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20548","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":"163","_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":null,"_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":"Writeback Cache","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":"20541","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20548","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=20548"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20548\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20541"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}