{"id":20540,"date":"2026-08-11T11:56:13","date_gmt":"2026-08-11T09:56:13","guid":{"rendered":"https:\/\/webhosting.de\/linux-page-cache-performance-booster\/"},"modified":"2026-08-11T11:56:13","modified_gmt":"2026-08-11T09:56:13","slug":"ottimizzatore-delle-prestazioni-della-cache-di-pagina-di-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-page-cache-performance-booster\/","title":{"rendered":"Capire la cache di pagina di Linux: maggiori prestazioni grazie alla cache"},"content":{"rendered":"<p><strong>Pagina Linux<\/strong> Considero la cache uno strumento diretto per accelerare l'accesso ai file, poich\u00e9 consente di eseguire letture ripetute dalla RAM anzich\u00e9 da un supporto di archiviazione pi\u00f9 lento. Mostrer\u00f2 concretamente come il kernel riduca cos\u00ec le latenze, acceleri carichi di lavoro quali server web, database e WordPress, e come io sfrutti questo effetto con mezzi semplici.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<p>I seguenti punti chiave mi aiutano a... <strong>Cache di pagina<\/strong> valutarli e sfruttarli in modo mirato.<\/p>\n<ul>\n  <li><strong>Cache RAM<\/strong>: I dati dei file vengono memorizzati nella memoria, riducendo i tempi di accesso.<\/li>\n  <li><strong>Ripristino<\/strong>: Le operazioni di scrittura vengono raggruppate in modo pi\u00f9 efficiente sotto forma di \u201epagine sporche\u201c.<\/li>\n  <li><strong>Trasparenza<\/strong>: Le applicazioni ne traggono vantaggio senza modifiche al codice.<\/li>\n  <li><strong>Dinamica<\/strong>: La cache libera la memoria quando necessario.<\/li>\n  <li><strong>Carichi di lavoro<\/strong>: Web, database, CI\/CD e log registrano un netto miglioramento.<\/li>\n<\/ul>\n\n<h2>Che cos'\u00e8 la cache delle pagine Linux?<\/h2>\n\n<p>Capisco il <strong>Cache di pagina<\/strong> come area di memoria nella RAM in cui il kernel conserva i blocchi di file non appena i processi, tramite <code>read()<\/code>, <code>write()<\/code> oppure <code>mmap()<\/code> accedere ai file. Ad ogni accesso, il kernel controlla innanzitutto la cache e fornisce immediatamente i dati dalla memoria, se gi\u00e0 presenti, riducendo in modo misurabile i tempi di risposta. Se i dati non sono presenti nella cache, il kernel li carica dal supporto di memorizzazione, li memorizza nella cache e li rende disponibili al processo, garantendo cos\u00ec un accesso pi\u00f9 rapido al successivo accesso. Questo meccanismo \u00e8 strettamente legato al Virtual File System e funziona in modo trasparente per le applicazioni, il che ne rende l\u2019utilizzo universale. Da questo funzionamento deriva un principio semplice: utilizzo la RAM libera come <strong>Area della cache<\/strong> anzich\u00e9 lasciarlo inutilizzato.<\/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-page-cache-performance-5830.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Perch\u00e9 la cache delle pagine accelera sensibilmente la navigazione<\/h2>\n\n<p>L'effetto maggiore si ottiene perch\u00e9 io <strong>I\/O disco<\/strong> riduco drasticamente non appena i dati ricorrenti vengono memorizzati nella cache e non devono pi\u00f9 essere letti dal supporto di memorizzazione. Gli accessi in lettura attingono quindi dalla RAM, il che riduce notevolmente le latenze e le code sui controller. Anche i percorsi di scrittura ne traggono vantaggio, poich\u00e9 il kernel contrassegna le modifiche come \u201edirty pages\u201c, le raggruppa nel tempo e successivamente le scrive in modo efficiente sul supporto. In questo modo, molti piccoli accessi singoli, che appesantirebbero lo storage, vengono sostituiti da un numero minore di operazioni pi\u00f9 grandi. Nel complesso, dopo una breve fase di riscaldamento, il sistema sembra pi\u00f9 veloce perch\u00e9 una maggiore quantit\u00e0 di dati di lavoro \u00e8 presente nella <strong>Memoria<\/strong> rimangono.<\/p>\n\n<h2>Leggere, scrivere, \u201cDirty Pages\u201d: ecco come funziona<\/h2>\n\n<p>Un'operazione di lettura inizia sempre con un controllo della cache, grazie al quale ottengo i risultati positivi senza tempi di attesa e quelli negativi comportano un costo solo una volta. In fase di scrittura, il contenuto modificato viene inizialmente memorizzato nella RAM e rimane in stato di attesa come \u201edirty\u201c fino a quando il kernel non lo trasferisce in blocco sul supporto di dati. Se lo desidero, posso forzare la memorizzazione permanente con <code>fsync()<\/code>, cosa che rimane importante quando si tratta di dati <strong>Coerenza<\/strong> di cui ho bisogno immediatamente. Questo percorso di write-back aumenta l\u2019efficienza delle applicazioni che gestiscono molti file di piccole dimensioni, come il codice PHP, i file di configurazione o le risorse. Allo stesso tempo, tengo presente che il write-back garantisce prestazioni elevate, ma che esiste un breve lasso di tempo in cui non tutto \u00e8 ancora stato salvato fisicamente.<\/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_Page_Cache_3892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>La RAM libera \u00e8 cache \u2013 non \u00e8 una perdita<\/h2>\n\n<p>Molti guardano con scetticismo alla memoria \u201eoccupata\u201c, ma io leggo correttamente il valore considerando la percentuale \u201ebuff\/cache\u201c come un indicatore significativo <strong>memoria temporanea<\/strong> valori. Il kernel utilizza attivamente la RAM inutilizzata, la restituisce ai processi in un batter d\u2019occhio quando necessario e ne gestisce l\u2019equilibrio tramite meccanismi di recupero. Questa dinamica garantisce che il mio sistema reagisca rapidamente, purch\u00e9 nella cache sia presente un set di lavoro sufficiente. Se il fabbisogno di un\u2019applicazione aumenta, il kernel sostituisce le vecchie pagine della cache e crea spazio senza che io debba intervenire manualmente. Quando entro in fasi di carico elevato, osservo la situazione concentrandomi su <a href=\"https:\/\/webhosting.de\/it\/pressione-di-memoria-kernel-linux-sistemi-di-hosting-ottimizzazione-ram\/\">Pressione di accumulo<\/a>, per valutare correttamente la situazione e classificare i colli di bottiglia.<\/p>\n\n<h2>Carichi di lavoro che ne traggono grande vantaggio<\/h2>\n\n<p>Ritengo che i vantaggi maggiori si riscontrino proprio laddove i dati ricorrono spesso e si verificano numerose piccole richieste di accesso, che il <strong>Cache<\/strong> semplificato. Esempi classici sono i server web con file PHP e HTML di uso frequente, nonch\u00e9 le installazioni di WordPress con temi, plugin, file multimediali e configurazioni ricorrenti. I database traggono vantaggio dalle query ripetute a livello di filesystem, a condizione che non aggirino in modo mirato la cache delle pagine. Anche i sistemi CI\/CD con artefatti di build e gli strumenti che gestiscono molti file di piccole dimensioni registrano un'accelerazione tangibile. Persino le analisi dei log, che effettuano letture sequenziali, traggono vantaggio dai buffer RAM, poich\u00e9 il kernel memorizza i modelli di accesso e li rende disponibili pi\u00f9 rapidamente.<\/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-page-cache-performance-3829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoraggio e misurazione: ecco come valuto gli effetti della cache<\/h2>\n\n<p>Per prima cosa controllo con <code>libero -h<\/code>, qual \u00e8 la dimensione di \u201ebuff\/cache\u201c e come <strong>occupato<\/strong> Memoria sviluppata nel corso del tempo. Uno sguardo a <code>\/proc\/meminfo<\/code> mi mostra indicatori quali <code>Memorizzato nella cache<\/code>, <code>Sporco<\/code> e <code>Writeback<\/code>, che forniscono indicazioni sui libri pi\u00f9 letti e sulle operazioni di scrittura in sospeso. Con <code>iostat -x 1<\/code> oppure <code>pidstat -d 1<\/code> mi accorgo se il carico fisico di I\/O diminuisce non appena la mia cache si \u00e8 riscaldata. Strumenti come <code>perf<\/code> oppure <code>bcc<\/code>Gli script basati su - aiutano ad approfondire l'analisi, ma nella pratica quotidiana sono raramente necessari quando sono visibili modelli chiari. Inoltre, verifico, effettuando ripetuti accessi ai file, se la seconda esecuzione risulta significativamente pi\u00f9 veloce, il che dimostra l'efficacia del <strong>Cache<\/strong> confermato.<\/p>\n\n<h2>Ottimizzazione: parametri e impostazioni predefinite consigliate<\/h2>\n\n<p>Mi limito ad adattare ci\u00f2 che capisco e, per quanto riguarda l'ottimizzazione della cache, parto da pochi elementi ben comprensibili <strong>Viti di regolazione<\/strong>. I parametri vm.dirty determinano a partire da quando le operazioni di scrittura dalla RAM vengono trasferite sul supporto e con quale intensit\u00e0 avviene tale processo. <code>vm.vfs_cache_pressure<\/code> Determina l'entit\u00e0 con cui il kernel sostituisce le cache Dentry e Inode, il che influisce direttamente sulle operazioni del file system. I valori di readahead a livello di dispositivo a blocchi possono migliorare le prestazioni di lettura sequenziale, qualora i carichi di lavoro ne traggano vantaggio. Documenter\u00f2 ogni fase, effettuer\u00f2 dei test sotto carico e, se necessario, torner\u00f2 ai valori iniziali qualora non si riscontrino miglioramenti.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Parametri<\/strong><\/th>\n      <th><strong>Standard<\/strong><\/th>\n      <th><strong>Effetto<\/strong><\/th>\n      <th><strong>Quando modificare<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>10%<\/td>\n      <td>Avvio della fase di write-back asincrono<\/td>\n      <td>In caso di molte piccole operazioni di scrittura, innescare il flush prima<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>20%<\/td>\n      <td>Percentuale massima di \u201edirty\u201c nella RAM<\/td>\n      <td>In caso di picchi di carico, aumentare la capacit\u00e0 di buffer<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>3000<\/td>\n      <td>Tempo di \u201edirty\u201c fino al flush (in 1\/100 s)<\/td>\n      <td>Per gli obiettivi di latenza, impostare un valore pi\u00f9 basso<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisecs<\/td>\n      <td>500<\/td>\n      <td>Intervallo per il write-back in background<\/td>\n      <td>Se lo storage \u00e8 lento, aumentare leggermente la velocit\u00e0<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.vfs_cache_pressure<\/td>\n      <td>100<\/td>\n      <td>Necessit\u00e0 di liberare spazio nei dentries\/inode<\/td>\n      <td>In molte operazioni sui file, ridurre<\/td>\n    <\/tr>\n    <tr>\n      <td>Lettura anticipata a blocchi<\/td>\n      <td>a seconda del dispositivo<\/td>\n      <td>Anteprima di lettura sequenziale<\/td>\n      <td>Aumentare la velocit\u00e0 di lettura in streaming<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Per approfondire le dinamiche relative al recupero e allo stoccaggio, vale la pena dare un'occhiata a <a href=\"https:\/\/webhosting.de\/it\/server-page-cache-eviction-linux-memoria-stampa-ottimizzazione-insight\/\">Eliminazione dalla cache delle pagine<\/a>, per valutare in modo approfondito la propria configurazione. Applico sempre le modifiche gradualmente, le monitoro tramite punti di misurazione e ne documento chiaramente gli effetti, in modo che ogni <strong>Personalizzazione<\/strong> rimanga comprensibile.<\/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\/LinuxCachePerformance5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cache delle pagine e database: quando \u00e8 opportuno aggirarli<\/h2>\n\n<p>Alcuni database utilizzano deliberatamente <strong>I\/O diretto<\/strong> per evitare il doppio buffering e utilizzare le proprie cache. In tali scenari lavoro con i parametri interni al database e faccio meno affidamento sulla page cache di Linux. Se un motore accede frequentemente a nuovi dati o a carichi di lavoro molto grandi, vale la pena utilizzare il modello di bypass per rendere pi\u00f9 prevedibile il consumo di memoria. Se invece l\u2019attenzione \u00e8 rivolta a letture ripetute di file dalle stesse tabelle o dagli stessi indici, la cache del filesystem rimane utile. Prendo le mie decisioni in base al modello di accesso effettivo, non a una regola generica, in modo che la <strong>Prestazioni<\/strong> aumenta davvero.<\/p>\n\n<h2>Eviction, Reclaim e pressione di memoria<\/h2>\n\n<p>In presenza di un carico elevato, il kernel classifica le pagine in attive e inattive <strong>Elenchi LRU<\/strong> e rimuove gradualmente i candidati dalla cache. Questo processo di recupero reagisce alla pressione derivante dall\u2019aumento della domanda dei processi, dai limiti dei cgroup o dai tempi di attesa I\/O. Se il mio sistema di monitoraggio rileva un aumento delle espulsioni e, contemporaneamente, un aumento del carico di I\/O, capisco che il set di dati di lavoro \u00e8 pi\u00f9 grande della RAM disponibile. In tali fasi, valuto se isolare i carichi di lavoro, modificare le strategie di caching o espandere la memoria. Per comprendere le regole di eviczione, trovo utile una guida strutturata su <a href=\"https:\/\/webhosting.de\/it\/pressione-di-memoria-kernel-linux-sistemi-di-hosting-ottimizzazione-ram\/\">Pressione di accumulo<\/a>, per interpretare correttamente i sintomi e pianificare le contromisure.<\/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_cache_performance_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pratica: controlli rapidi e comandi<\/h2>\n\n<p>Per farmi una prima idea, comincio con <code>libero -h<\/code> e leggi la quota <strong>buff\/cache<\/strong>, prima di approfondire l'argomento. Successivamente metter\u00f2 a confronto due esecuzioni di una scansione di file, ad esempio con <code>trovare<\/code> o un benchmark, e osserva la differenza di tempo tra l'avvio a freddo e quello a caldo. <code>grep -E \"Cached|Dirty|Writeback\" \/proc\/meminfo<\/code> mi mostra quanto c'\u00e8 nella cache e cosa deve ancora essere scritto. <code>iostat -xz 1<\/code> rivela il livello di utilizzo delle risorse da parte dei dispositivi e se la coda si riduce non appena entra in gioco la cache. Chi desidera approfondire i fondamenti del caching, trover\u00e0 nella panoramica su <a href=\"https:\/\/webhosting.de\/it\/filesystem-caching-linux-page-cache-cacheboost\/\">Caching del filesystem<\/a> una guida introduttiva di facile comprensione che spiega l'interazione tra VFS e buffer RAM.<\/p>\n\n<h2>Chiarire i malintesi pi\u00f9 comuni<\/h2>\n\n<p>\u201eLa RAM \u00e8 piena, il server ha un problema\u201c, mi capita spesso di sentirlo dire, ma il <strong>Cache<\/strong> Questa \u00e8 la risposta, non la causa. Linux libera la memoria in modo flessibile quando le applicazioni la occupano e la rioccupano non appena vengono memorizzati nuovi dati. Lo svuotamento manuale tramite <code>echo 3 &gt; \/proc\/sys\/vm\/drop_caches<\/code> raramente apporta benefici duraturi e falsifica le misurazioni. \u00c8 pi\u00f9 sensato identificare i veri punti critici e alleggerire il carico sui percorsi I\/O in quei punti. Distinguo inoltre tra la cache delle pagine e le cache slab per i dentries\/inode, in modo da non avere due diverse <strong>Meccanismi<\/strong> lo metto in una pentola.<\/p>\n\n<h2>Opzioni di montaggio e sottigliezze del file system<\/h2>\n\n<p>Tengo conto del fatto che le opzioni del file system e di montaggio influenzano notevolmente l'efficienza della cache di pagina. <strong>atime<\/strong>- Gli aggiornamenti generano ulteriori operazioni di scrittura; con <em>relatime<\/em> (oggi \u00e8 la norma) le riduco, <em>noatime<\/em> risparmio ancora di pi\u00f9 se non devo mai fare i conti con gli orari di accesso. <strong>sincronizzazione<\/strong> e <strong>dirsync<\/strong> impongono la persistenza immediata e annullano i vantaggi del write-back \u2013 giustificabili per i metadati in cui la latenza \u00e8 un fattore critico, altrimenti li evito. Modalit\u00e0 di journaling (ad es. in ext4 <em>dati=ordinati<\/em> vs. <em>writeback<\/em>) influenzano il fatto che i dati utili vengano scritti sul supporto prima o dopo i metadati; io preferisco la sicurezza a una prestazione apparente. XFS e btrfs si comportano in modo diverso per quanto riguarda i metadati e il CoW: il CoW, la compressione o la deduplicazione riducono gli I\/O, ma possono comportare un maggiore carico sulla CPU. Pertanto, misuro i carichi di lavoro in modo realistico e valuto se le opzioni di montaggio siano adeguate al modello di accesso.<\/p>\n\n<h2>Container, macchine virtuali e cache duplicate<\/h2>\n\n<p>Nei container, tutti i processi condividono lo stesso kernel \u2013 e quindi anche la stessa cache di pagina. Ci\u00f2 facilita la condivisione dei file pi\u00f9 utilizzati (ad esempio le librerie), ma i limiti rigorosi imposti dai cgroup (<em>memoria.max<\/em>) possono sostituire le pagine in cache in anticipo. Prevedo un margine per ogni servizio e utilizzo <em>memoria.bassa<\/em>, per garantire una certa protezione ai cache importanti. Nelle macchine virtuali esistono <strong>due<\/strong> Cache: nella macchina ospite e, se del caso, nell\u2019host (in caso di file di backup). Ci\u00f2 comporta un doppio buffering. Se utilizzo dispositivi raw o Direct Storage, evito l\u2019uso della cache dell\u2019host, ma ne perdo i vantaggi. Il ballooning e l\u2019overcommit influenzano il reclaim nel guest: osservo se un ballooning costante porta al cache thrashing e adeguo le risorse o il dimensionamento. Con lo storage dei container (OverlayFS), riscaldo in modo mirato i layer utilizzati di frequente, in modo che le distribuzioni non partano a freddo.<\/p>\n\n<h2>NUMA, cgroups e isolamento<\/h2>\n\n<p>Sui sistemi NUMA, il kernel gestisce liste LRU per ogni nodo. Se i thread effettuano accessi prevalentemente a livello locale, i successi nella cache delle pagine <strong>numa-nah<\/strong> e ridurre la latenza. Grazie all\u2019affinit\u00e0 della CPU e della memoria, mi assicuro che un\u2019applicazione e i suoi dati siano vicini tra loro. Tramite <strong>memcg<\/strong> (cgroups v2) la cache di pagina viene assegnata a un gruppo; con <em>memoria.alta<\/em> avvio un'operazione di reclaim controllata, con <em>memoria.max<\/em> fisso dei limiti ben precisi e con <em>memoria.bassa<\/em> Do priorit\u00e0 ai servizi importanti. Questi strumenti aiutano a evitare che un\u2019operazione batch particolarmente onerosa svuoti la cache di un servizio web sensibile alla latenza. L\u2019isolamento garantisce una maggiore prevedibilit\u00e0, ma cerco di trovare un equilibrio in modo da non creare troppe cache di piccole dimensioni, ciascuna delle quali otterrebbe un numero insufficiente di hit.<\/p>\n\n<h2>SSD, HDD e l'applicazione pratica del readahead<\/h2>\n\n<p>Il readahead \u00e8 vantaggioso per gli accessi sequenziali, mentre per quelli casuali spesso rappresenta solo un peso. Sugli HDD, di solito aumento il readahead per velocizzare le scansioni lineari. Sugli SSD NVMe veloci, il vantaggio \u00e8 minore; un readahead eccessivo spreca RAM e peggiora gli hit della cache, poich\u00e9 le pagine inutilizzate ne sostituiscono altre. Regolo il readahead per ogni dispositivo e verifico, con test ripetuti, se la velocit\u00e0 effettiva o le latenze ne traggono vantaggio. Inoltre, prendo in considerazione lo scheduler I\/O: per gli NVMe \u00e8 comune impostare \u201enone\u201c\/\u201emq-deadline\u201c, mentre gli HDD possono trarre vantaggio dalla pianificazione deadline. La cache di pagina livella i profili di I\/O, ma il livello dei blocchi deve essere adeguato a questo scopo. L\u2019obiettivo rimane quello di garantire che la cache contenga prevalentemente dati utili e riutilizzati, non solo byte prelevati in anticipo.<\/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-page-cache-performance-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Avvii a freddo, preriscaldamento e implementazioni<\/h2>\n\n<p>Ogni cache necessita di una fase di riscaldamento. Dopo i riavvii o i rollout, leggo in modo mirato gli hotset, ad esempio scorrendo una volta in sequenza le directory importanti. Ci\u00f2 riduce sensibilmente il \u201eminuto freddo\u201c dopo le distribuzioni. Nelle strategie rolling mantengo online almeno un\u2019istanza \u201ccalda\u201d, in modo che il servizio complessivo risponda rapidamente mentre le nuove istanze riempiono la propria cache. Evito modifiche di massa all\u2019albero dei file (ad es. cambi di percorso), poich\u00e9 ci\u00f2 rende freddi i dentries\/inode. Lavoro invece con sostituzioni atomiche dei collegamenti simbolici o strategie \u00abcopy-on-write\u00bb, in cui i contenuti dei file e i percorsi rimangono sostanzialmente stabili. In questo modo non solo la cache di pagina rimane efficace, ma anche le cache dei metadati mantengono la loro efficacia.<\/p>\n\n<h2>Parametri di misura in profondit\u00e0<\/h2>\n\n<p>Inoltre <code>\/proc\/meminfo<\/code> per una diagnosi accurata do un'occhiata a <code>\/proc\/vmstat<\/code>: contatori come <em>pgfault<\/em> e <em>pgmajfault<\/em> distinguono i page fault lievi da quelli gravi, <em>nr_active_file<\/em>\/<em>nr_file_inattivo<\/em> indicano la dimensione del set di lavoro basato sui file e <em>workingset_refault<\/em> aiuta a individuare il thrashing. Se i refault aumentano mentre la velocit\u00e0 di I\/O del dispositivo rimane elevata, il set di lavoro non rientra nella RAM. Eseguo il test con due cicli dello stesso carico di lavoro: il secondo ciclo dovrebbe risultare nettamente pi\u00f9 veloce se la cache funziona correttamente. Per garantire la riproducibilit\u00e0 dei test di avvio a freddo, svuoto le cache esclusivamente in ambiente di laboratorio e documento accuratamente l\u2019operazione, per non falsare le misurazioni in produzione. Per me \u00e8 importante non dare un\u2019interpretazione eccessiva a un singolo indicatore, ma piuttosto individuare modelli ricorrenti nelle serie temporali.<\/p>\n\n<h2>Come evitare lo swap, lo \"swappiness\" e il thrashing<\/h2>\n\n<p>Quando \u00e8 sotto pressione, Linux svuota prima la cache di pagina prima di passare alle pagine anonime \u2013 purch\u00e9 ci\u00f2 sia opportuno. Se la memoria di lavoro per i processi inizia a scarseggiare e le pagine anonime non sono sufficienti, il sistema inizia a ricorrere allo swap. Una <strong>troppo bassa<\/strong> Lo \"swappiness\" pu\u00f2 comportare che la memoria anonima importante (heap\/stack) venga mantenuta in modo aggressivo, mentre le pagine di cache utili vengono invece sostituite, il che aumenta l'I\/O. Una <strong>troppo alta<\/strong> Lo swappiness, al contrario, porta a uno spostamento precoce in swap e a picchi di latenza. Scelgo valori moderati, misuro e osservo: l'obiettivo \u00e8 che il mio hotset rimanga nella RAM e che solo i dati freddi, usati raramente, vengano spostati nello swap \u2013 mai quelli caldi.<\/p>\n\n<h2>Sicurezza e durata: i dati sul supporto<\/h2>\n\n<p>Il write-back migliora le prestazioni, ma crea una breve finestra temporale in cui le modifiche risiedono solo nella RAM. Per i dati che devono essere immediatamente persistenti, utilizzo <code>fsync()<\/code> oppure <code>fdatasync()<\/code>. Mi affido inoltre a impostazioni predefinite sicure come le barriere di scrittura e il journaling; evito invece le opzioni rischiose che disattivano tali barriere. A livello di storage, prendo in considerazione le cache dei controller: le politiche di scrittura differita (write-back) con batteria o condensatore sono veloci e sicure, mentre le cache non protette sono invece rischiose. A livello di sistema, impongo <code>sincronizzazione<\/code> La cancellazione di tutti i dati: uno strumento piuttosto rudimentale che utilizzo in modo consapevole e solo raramente. In questo modo combino la velocit\u00e0 offerta dalla cache delle pagine con una persistenza pulita laddove \u00e8 fondamentale per l\u2019attivit\u00e0.<\/p>\n\n<h2>WordPress e stack web: consigli pratici<\/h2>\n\n<p>Nello stack web si sommano diverse cache: la cache di pagina di Linux accelera le risorse statiche, i file PHP e le configurazioni, mentre una cache OpCode di PHP mantiene in memoria il percorso di esecuzione e il bytecode. Mi assicuro che i deployment non modifichino continuamente il percorso del codice e riduco gli accessi ai file raggruppando le risorse. Uno strato di cache a oggetti persistente riduce l\u2019I\/O del database, consentendo alla cache del filesystem di gestire in modo ancora pi\u00f9 efficace i file pi\u00f9 accessi rimanenti. Ove possibile, non memorizzo le sessioni e i dati transitori sul disco locale, ma in cache di memoria o di rete, in modo che la cache di pagina possa sfruttare appieno i propri punti di forza sui restanti file letti frequentemente. Risultato: meno I\/O fisico, risposte pi\u00f9 veloci e latenze pi\u00f9 stabili.<\/p>\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>La cache di pagina di Linux mi fornisce risposte rapide alle richieste sui file <strong>RAM<\/strong> e riduce notevolmente i costosi accessi al supporto dati. Le operazioni di lettura accelerano le applicazioni, mentre il write-back raggruppa molte singole operazioni di scrittura, aumentando l\u2019efficienza. La memoria libera non rimane inattiva, ma funge da cache per garantire una piattaforma reattiva. Con punti di misurazione quali <code>libero -h<\/code>, <code>\/proc\/meminfo<\/code> e <code>iostat<\/code> mi rendo conto dell'effetto prima di considerare parametri come <code>vm.dirty_ratio<\/code> oppure <code>vm.vfs_cache_pressure<\/code> Vai. Chi conosce i carichi di lavoro, testa le modifiche in modo controllato e utilizza la cache in modo mirato, ottiene un miglioramento tangibile <strong>Prestazioni<\/strong> senza modifiche al codice.<\/p>","protected":false},"excerpt":{"rendered":"<p>La cache di pagina di Linux utilizza la RAM come cache, migliorando cos\u00ec le prestazioni del server per l'hosting web, WordPress e l'accesso ai file.<\/p>","protected":false},"author":1,"featured_media":20533,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20540","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":"170","_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":"Linux Page","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":"20533","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20540","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=20540"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20540\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20533"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}