{"id":20874,"date":"2026-08-21T18:22:37","date_gmt":"2026-08-21T16:22:37","guid":{"rendered":"https:\/\/webhosting.de\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimierung\/"},"modified":"2026-08-21T18:22:37","modified_gmt":"2026-08-21T16:22:37","slug":"vm-vfs-pressione-della-cache-linux-ottimizzazione-della-cache-del-filesystem","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimierung\/","title":{"rendered":"Spiegazione di vm.vfs_cache_pressure \u2013 Utilizzo ottimale della cache del filesystem di Linux"},"content":{"rendered":"<p>Vi mostrer\u00f2 come il parametro del kernel <strong>vm.vfs_cache_pressure<\/strong> la ponderazione della cache VFS rispetto alla cache di pagina e quali valori garantiscono maggiore velocit\u00e0 con un profilo di carico reale. Con passaggi chiari regolo questo parametro, ne misuro gli effetti e in questo modo sfrutto il <strong>Cache del filesystem<\/strong> ottimale.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<p>Per iniziare subito, riassumo gli aspetti pi\u00f9 importanti relativi alla messa a punto del <strong>Cache VFS<\/strong> insieme. In questo modo, nella scelta del valore, tengo d\u2019occhio l\u2019impatto sulle ricerche nei metadati, sul carico I\/O e sulla pressione sulla RAM. Questi punti mi aiutano a ottimizzare i ruoli tipici dei server in modo sicuro e ripetibile.<\/p>\n\n<ul>\n  <li><strong>Meccanismo d'azione<\/strong>: Determina con quale decisione il kernel libera i dentries\/inode rispetto alla cache di pagina.<\/li>\n  <li><strong>Impostazione predefinita<\/strong>: 100 indica una correzione equilibrata senza preferenze.<\/li>\n  <li><strong>Valori bassi<\/strong>: I valori compresi tra 50 e 80 mantengono i metadati pi\u00f9 a lungo nella RAM e accelerano la ricerca dei file.<\/li>\n  <li><strong>Valori elevati<\/strong>: I valori compresi tra 120 e 200 liberano pi\u00f9 rapidamente le cache VFS e creano spazio per i processi.<\/li>\n  <li><strong>Pratica<\/strong>: Modificare gradualmente, misurare, documentare \u2013 solo allora procedere con ulteriori adeguamenti.<\/li>\n<\/ul>\n\n<p>Applico questi principi con coerenza per trovare il giusto equilibrio tra <strong>Tasso di risposta della cache<\/strong> e la RAM libera. Successivamente regolo il parametro vm.vfs_cache_pressure a piccoli passi, osservo i picchi di carico e, se necessario, apporto le correzioni del caso. In questo modo ottengo tempi di risposta stabili senza colli di bottiglia inaspettati nella memoria.<\/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-cache-optimierung-4756.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Che cos'\u00e8 vm.vfs_cache_pressure?<\/h2>\n\n<p>Il parametro determina con quanta rigidit\u00e0 il kernel gestisce il <strong>Cache VFS<\/strong> rispetto ad altre memorie, libera spazio non appena la RAM inizia a scarseggiare. Nella cache VFS finiscono i dentries e gli inode, ovvero le voci di directory e i metadati dei file, che accelerano sensibilmente la ricerca dei file. Un valore pari a 100 tratta la cache VFS e la cache di pagina allo stesso modo, mentre valori pi\u00f9 bassi mantengono preferibilmente i metadati nella RAM. Valori pi\u00f9 alti inducono il kernel a scartare prima le voci VFS e a liberare pi\u00f9 rapidamente la memoria. Utilizzo questa leva in modo mirato per mantenere elevati i risultati positivi dei metadati nei carichi di lavoro web, file e CMS, senza soffocare i processi. In questo modo controllo l\u2019equilibrio tra <strong>Velocit\u00e0 di ricerca<\/strong> e alla memoria libera in modo molto diretto.<\/p>\n\n<h2>Come funziona nel dettaglio la cache VFS?<\/h2>\n\n<p>Il Virtual Filesystem costituisce un livello comune per ext4, XFS, Btrfs e altri file system e memorizza <strong>Dentries<\/strong> e gli inode nella RAM, in modo che le scansioni delle directory e gli accessi ricorrenti rimangano veloci. La cache di pagina, invece, contiene i blocchi di file veri e propri; entrambe le cache si completano a vicenda, ma in condizioni di carico elevato entrano in competizione per la memoria. Maggiore \u00e8 il numero di file di piccole dimensioni e di accessi ripetuti, maggiore \u00e8 il vantaggio che l\u2019applicazione trae da un elevato tasso di corrispondenza dei metadati. \u00c8 proprio qui che entra in gioco vm.vfs_cache_pressure: posso decidere se Linux mantenga questi metadati o li sostituisca rapidamente. Per aspetti pi\u00f9 approfonditi relativi alla cache di pagina, utilizzo in aggiunta il compatto <a href=\"https:\/\/webhosting.de\/it\/ottimizzatore-delle-prestazioni-della-cache-di-pagina-di-linux\/\">Ottimizzatore delle prestazioni della cache delle pagine<\/a> come nozioni di base, in modo da poter valutare la VFS e la cache di pagina nel contesto.<\/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\/linuxcachemeeting1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Valore predefinito e intervalli tipici<\/h2>\n\n<p>Sulla maggior parte dei sistemi il valore \u00e8 impostato su <strong>100<\/strong> e costituisce cos\u00ec una base equilibrata per i primi test. Se abbasso il valore, do la priorit\u00e0 ai metadati e stabilizzo le ricerche veloci, il che \u00e8 particolarmente utile in presenza di molti file di piccole dimensioni. Se aumento il valore, Linux smantella pi\u00f9 rapidamente le voci VFS e crea pi\u00f9 buffer per le applicazioni o per la cache di pagina. Tratto i valori estremi come 0 o quelli superiori a 500 con molta cautela, poich\u00e9 possono causare comportamenti anomali e provocare effetti collaterali. Nell\u2019uso quotidiano parto da 100, procedo a passi da 20 a 40 punti e misuro l\u2019effetto su <strong>Latenza IO<\/strong> e i tempi di risposta.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Valore<\/th>\n      <th>Significato<\/th>\n      <th>Quando utilizzare<\/th>\n      <th>Rischio\/Avviso<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>&lt; 100 (ad es. 50\u201380)<\/td>\n      <td>La cache VFS rimane pi\u00f9 a lungo nella RAM<\/td>\n      <td>Molti file di piccole dimensioni, ricerche frequenti<\/td>\n      <td>Maggiore utilizzo della RAM su <strong>Metadati<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>100<\/td>\n      <td>Adeguamento equilibrato<\/td>\n      <td>Valore iniziale affidabile per le misurazioni<\/td>\n      <td>Buono <strong>Linea di base<\/strong>valore \u2011<\/td>\n    <\/tr>\n    <tr>\n      <td>&gt; 100 (ad es. 120\u2013200)<\/td>\n      <td>La cache VFS viene liberata in modo pi\u00f9 aggressivo<\/td>\n      <td>RAM insufficiente, database con cache propria<\/td>\n      <td>Possibile latenza di ricerca<\/td>\n    <\/tr>\n    <tr>\n      <td>Estremo (0, &gt; 500)<\/td>\n      <td>Cambiamenti significativi<\/td>\n      <td>Casi particolari: prova veloce<\/td>\n      <td>Rischio per la stabilit\u00e0 e <strong>Prestazioni<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Grazie a questa griglia riesco a capire rapidamente quale direzione \u00e8 quella giusta, senza perdere di vista l\u2019obiettivo. Evito di fare salti troppo grandi e registro ogni modifica in modo dettagliato. In questo modo il percorso gi\u00e0 percorso rimane sempre chiaro e mantengo un confronto preciso con i punti di misurazione precedenti.<\/p>\n\n<h2>Ruolo nella pulizia della memoria<\/h2>\n\n<p>In condizioni di pressione, il kernel deve liberare RAM, ed \u00e8 proprio qui che vm.vfs_cache_pressure definisce il bilanciamento tra <strong>Cache VFS<\/strong>, cache di pagina e memoria di processo. Valori bassi mantengono pi\u00f9 a lungo in memoria le voci delle directory e degli inode, il che velocizza le chiamate alle directory e le aperture ripetute dei file. Valori elevati liberano la memoria prima e mettono a disposizione pi\u00f9 spazio per i processi o per la cache di pagina, il che pu\u00f2 essere utile in caso di RAM limitata. In questo contesto, osservo in modo mirato le latenze di I\/O, poich\u00e9 una cache dei metadati troppo vuota rallenta la ricerca dei file. Per l\u2019interazione con le strategie di liberazione della cache di pagina, questa analisi mi fornisce informazioni su <a href=\"https:\/\/webhosting.de\/it\/server-page-cache-eviction-linux-memoria-stampa-ottimizzazione-insight\/\">Eliminazione dalla cache delle pagine<\/a> preziose indicazioni pratiche che mi consentano di prendere decisioni basate sui fatti.<\/p>\n\n<h2>Metodologia di misurazione: rendere trasparente la cache VFS<\/h2>\n\n<p>Prima di apportare modifiche, metto in evidenza, <strong>dove<\/strong> la memoria si trova e <strong>cosa<\/strong> viene soppiantato. In questo modo capisco se i metadati rappresentano davvero il collo di bottiglia, oppure se sono la cache delle pagine, i processi o le pagine sporche a prevalere.<\/p>\n\n<ul>\n  <li><strong>\/proc\/meminfo<\/strong>: Controllo InodeCache, Cached, Buffers, SReclaimable e SUnreclaim per valutare la percentuale e la recuperabilit\u00e0.<\/li>\n  <li><strong>piano di lavoro<\/strong>: Visualizzazione in tempo reale degli slab, in particolare dentry, inode_cache, ext4_inode_cache, xfs_inode. In questo modo posso vedere se i dentries e gli inode aumentano o diminuiscono.<\/li>\n  <li><strong>Percorso IO<\/strong>: Con vmstat\/iostat monitoro le latenze di lettura e verifico se gli accessi al disco aumentano durante le operazioni di ricerca.<\/li>\n<\/ul>\n\n<pre><code># Panoramica rapida\ngrep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' \/proc\/meminfo\n\n# Distribuzione degli slab (ordinata per dimensione)\nsudo slabtop -s c\n\n# Filtrare solo gli slab di tipo dentry\/inode\ngrep -Ei 'dentry|inode' \/proc\/slabinfo | sort -k3 -nr | head\n\n# Andamento delle operazioni I\/O e della memoria al secondo\nvmstat 1\niostat -x 1\n<\/code><\/pre>\n\n<p>Ritengo che l'interpretazione sia chiara: se SReclaimable cresce insieme agli slab dentry\/inode e contemporaneamente aumentano le latenze di I\/O <em>non<\/em>, ci\u00f2 conferma l'efficacia della cache dei metadati. Se questi valori scendono spesso a zero e aumentano rapidamente in caso di accessi alle directory, \u00e8 probabile che vm.vfs_cache_pressure sia impostato su un valore troppo aggressivo.<\/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-cache-optimization-tips-5467.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Esempio pratico: leggere e modificare il valore attuale<\/h2>\n\n<p>Il controllo pu\u00f2 essere effettuato dalla riga di comando in pochi secondi e senza <strong>Riavvio<\/strong>. Leggo il valore effettivo e inserisco inizialmente dei valori di prova in modo temporaneo, in modo da poter applicare immediatamente eventuali ritorni indietro nella finestra di prova. Per le modifiche definitive, inserisco le voci nel file \/etc\/sysctl.conf o in un file nella directory \/etc\/sysctl.d\/, ricarico il sistema e registro la modifica nella mia documentazione. Testo ogni livello sotto carico realistico, non solo in modalit\u00e0 inattiva, in modo che gli effetti siano visibili. In questo modo garantisco confronti \u00abprima-dopo\u00bb chiari e valuto la modifica sulla base di indicatori misurabili.<\/p>\n\n<pre><code># Verifica del valore attuale\ncat \/proc\/sys\/vm\/vfs_cache_pressure\n# oppure\nsysctl vm.vfs_cache_pressure\n\n# Prova temporanea (fino al riavvio)\nsudo sysctl -w vm.vfs_cache_pressure=60\n# in alternativa\necho 60 | sudo tee \/proc\/sys\/vm\/vfs_cache_pressure\n\n# Impostazione permanente\necho \"vm.vfs_cache_pressure = 60\" | sudo tee -a \/etc\/sysctl.conf\nsudo sysctl -p\n<\/code><\/pre>\n\n<h2>Ottimizzazione della cache in Linux: scenari utili<\/h2>\n\n<p>Nelle piattaforme di hosting con numerose risorse statiche, archivi di file o applicazioni con buffer proprio, \u00e8 opportuno effettuare una <strong>ponderazione<\/strong> della cache VFS. I server web con numerosi file di piccole dimensioni traggono grande vantaggio da valori pi\u00f9 bassi, poich\u00e9 le ricerche su SSD\/HDD avvengono meno frequentemente. I server di file con file di dimensioni miste possono utilizzare valori moderatamente ridotti, se \u00e8 disponibile RAM a sufficienza. I server di database con elevato carico sulla RAM e una cache del database di grandi dimensioni preferiscono valori pi\u00f9 elevati, in modo da garantire spazio ai processi. Valuto questi modelli in base ai dati di monitoraggio, affinch\u00e9 le impostazioni si adattino all\u2019effettivo mix di accessi.<\/p>\n\n<h3>Server web con molti file statici<\/h3>\n<p>Per i file CSS, JS e le immagini, preferisco conservare i metadati pi\u00f9 a lungo nel <strong>Cache<\/strong>. I valori compresi tra 50 e 80 si sono spesso dimostrati efficaci, poich\u00e9 la riapertura dei file risulta pi\u00f9 veloce. Controllo attentamente i picchi di I\/O durante i picchi di traffico e confronto i tempi di risposta prima e dopo la modifica. Se le latenze rimangono stabili e i costi di ricerca 404 diminuiscono, la direzione \u00e8 quella giusta. Tengo d\u2019occhio l\u2019utilizzo della RAM, in modo che i processi abbiano spazio sufficiente nonostante una cache dei metadati pi\u00f9 capiente.<\/p>\n\n<h3>Server di file o sistemi NAS<\/h3>\n<p>Un numero elevato di accessi degli utenti e i cambiamenti di directory traggono vantaggio da <strong>pi\u00f9 basso<\/strong> fino a valori equilibrati. Se la RAM \u00e8 sufficiente, tendo a impostare valori tra 50 e 80; in caso di memoria limitata, mi attengo a valori pi\u00f9 vicini a 100. Verifico che l\u2019elenco delle directory rimanga fluido e che gli snapshot\/i backup non occupino troppo spazio nella cache. Se la latenza I\/O aumenta nei momenti di picco, correggo cautamente il valore verso l\u2019alto. In questo modo mantengo l\u2019equilibrio tra fluidit\u00e0 di utilizzo e memoria libera.<\/p>\n\n<h3>Server di database e sistemi con poca memoria<\/h3>\n<p>I database gestiscono una propria cache buffer, quindi assegno al <strong>Memoria di processo<\/strong> di solito ha la priorit\u00e0. Valori compresi tra 120 e 200 indicano di svuotare le cache VFS per liberare RAM. In questo contesto, prendo in considerazione le latenze delle query e i modelli di page fault dell\u2019applicazione. Se il database subisce un rallentamento perch\u00e9 il sistema inizia a ricorrere allo swap, aumento leggermente il valore e, contestualmente, riduco vm.swappiness. Questo approccio impedisce che i metadati occupino spazio inutilmente, che il database pu\u00f2 invece utilizzare in modo pi\u00f9 efficiente.<\/p>\n\n<h2>Esempi di carico di lavoro e valori indicativi<\/h2>\n\n<p>Comincio da 100, poi riduco a intervalli di 20 per i valori vicini al valore web <strong>Carichi di lavoro<\/strong> e aumento in incrementi di 20 per i processi che richiedono molta memoria. Testo ogni livello almeno durante una fase di picco, in modo da poter individuare gli effetti su latenze, hit della cache e attivit\u00e0 di swap. Chi desidera approfondire l'argomento trover\u00e0 nel compatto <a href=\"https:\/\/webhosting.de\/it\/ottimizzatore-delle-prestazioni-della-cache-di-pagina-di-linux\/\">Ottimizzatore delle prestazioni della cache delle pagine<\/a> Ulteriori approfondimenti sulle strategie di cache dei file che prendo in considerazione parallelamente. Quando i valori misurati corrispondono agli obiettivi prefissati, blocco la configurazione e documento gli indicatori. In questo modo l'ottimizzazione rimane riproducibile e posso apportare rapidamente delle rettifiche in un secondo momento.<\/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_nutzung_4387.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rischi e insidie<\/h2>\n\n<p>Se imposto un valore troppo basso, il kernel riesce a malapena a liberare le voci VFS, il che in caso di picchi pu\u00f2 causare <strong>OOM<\/strong>\u2011rischi. Se lo aumento troppo, aumenta la latenza durante le ricerche dei file e i cambi di directory, perch\u00e9 i metadati devono essere ricaricati. Senza test sotto carico reale, si rischia di trarre conclusioni errate dai periodi di traffico ridotto. I salti bruschi rendono difficile la valutazione, pertanto procedo per gradi. Annotiamo ogni modifica indicando l\u2019ora, il profilo di carico e i valori misurati, in modo che le cause rimangano chiare.<\/p>\n\n<h2>Monitoraggio e indicatori<\/h2>\n\n<p>Se valga la pena apportare una modifica, lo dimostrano dati concreti <strong>Metriche<\/strong>. Monitoro l'utilizzo della RAM, la ripartizione tra cache e processi, le latenze I\/O e l'attivit\u00e0 di swap. Inoltre, analizzo i tassi di hit della cache e le tendenze dei page fault per individuare rapidamente eventuali effetti collaterali. Soprattutto in presenza di molti file di piccole dimensioni, si notano miglioramenti nel time-to-first-byte. Se la latenza I\/O rimane bassa e lo swapping si riduce, ci\u00f2 conferma la validit\u00e0 dell\u2019approccio.<\/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\/linuxcache_4242.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tuning\u2011Playbook: dall'ipotesi alla regolazione affidabile<\/h2>\n\n<p>Una struttura ben definita evita di procedere alla cieca. Seguo una procedura fissa affinch\u00e9 i risultati siano affidabili e i colleghi possano comprendere i vari passaggi.<\/p>\n\n<ol>\n  <li><strong>Acquisizione dei dati di riferimento<\/strong>: vm.vfs_cache_pressure=100, carico realistico per 24\u201372 ore. Salvare i parametri chiave (latenze: mediana\/95\u00b0\/99\u00b0, tempo di attesa IO, CPU steal, attivit\u00e0 di swap, dimensione inode\/dentry).<\/li>\n  <li><strong>Formulare un'ipotesi<\/strong>: \u201eMolti file di piccole dimensioni, le operazioni di ricerca sono costose \u2013 valori pi\u00f9 bassi accelerano il sistema\u201c oppure \u201eRAM insufficiente \u2013 valori pi\u00f9 alti mantengono liberi i processi\u201c.<\/li>\n  <li><strong>Modificare passo dopo passo<\/strong>: da \u00b120 a \u00b140 punti. Misurare almeno una fase di picco per ogni livello.<\/li>\n  <li><strong>Confronta<\/strong>: Verifico se gli SLO (ad es. il 95\u00b0 percentile) migliorano in modo significativo, <em>senza<\/em> pi\u00f9 eventi di swap o OOM.<\/li>\n  <li><strong>Criterio di rollback<\/strong>: Se le latenze 95\u00b0\/99\u00b0 aumentano, i tempi di attesa IO si allungano o si verificano sempre pi\u00f9 spesso errori di cache, faccio un passo indietro.<\/li>\n  <li><strong>Freeze e documentazione<\/strong>: Registrare il valore finale, la data, la finestra di carico e gli indicatori.<\/li>\n<\/ol>\n\n<pre><code># Test rapido per finestre di misurazione controllate (solo manutenzione!)\n# Prima: acquisire uno snapshot dei valori chiave\ndate; free -h; grep -E 'InodeCache|Cached' \/proc\/meminfo; vmstat 1 5\n\nsudo sysctl -w vm.vfs_cache_pressure=80\n# Attendere il picco del carico di prova, quindi acquisire nuovamente le metriche e confrontarle\n<\/code><\/pre>\n\n<h2>Sistemi di file e opzioni di montaggio: il contesto \u00e8 fondamentale<\/h2>\n\n<p>L'effetto di vm.vfs_cache_pressure dipende anche dal file system e dalle opzioni di montaggio. Valuto questi fattori come segue:<\/p>\n\n<ul>\n  <li><strong>relatime\/noatime<\/strong>: Impedisce frequenti operazioni di scrittura atime. noatime riduce il carico di I\/O in caso di numerose operazioni di lettura, rendendo pi\u00f9 evidenti i vantaggi legati ai metadati.<\/li>\n  <li><strong>pigrizia<\/strong>: Ritarda gli aggiornamenti dei metadati nella RAM; ci\u00f2 attenua i picchi, ma interagisce con i tempi di flush.<\/li>\n  <li><strong>ext4 vs. XFS vs. Btrfs<\/strong>: Diverse strutture degli inode e comportamenti dello \u201cshrinker\u201d. Misuro sempre <em>sul FS di destinazione<\/em>, anzich\u00e9 riportare delle ipotesi.<\/li>\n  <li><strong>NFS\/Netz-FS<\/strong>: La memorizzazione nella cache e l'invalidazione degli attributi possono limitare i vantaggi del VFS. Un rilascio aggressivo (valori elevati) fa quindi aumentare il numero di ricerche remote.<\/li>\n  <li><strong>OverlayFS\/FUSE<\/strong>: Molte piccole operazioni relative ai metadati traggono grande vantaggio dalla cache VFS; tendo a mantenere i valori su livelli da moderati a bassi, purch\u00e9 ci sia RAM disponibile.<\/li>\n<\/ul>\n\n<h2>Aspetti relativi ai container e ai cgroup<\/h2>\n\n<p>Negli ambienti container, tengo presente che: vm.vfs_cache_pressure \u00e8 un <strong>a livello di host<\/strong> Pulsante. Le modifiche riguardano <em>tutti<\/em> Pod\/container sul nodo. Adotto quindi un approccio prudente e coordino l'ottimizzazione a livello di nodo.<\/p>\n\n<ul>\n  <li><strong>Limiti di memoria<\/strong>: I Memory-Cgroups limitano la cache dei processi e quella delle pagine; la memoria Slab pu\u00f2 essere conteggiata proporzionalmente. Ho notato che gli eventi Pod-OOM e Node-Pressure sono correlati.<\/li>\n  <li><strong>Mix di carichi di lavoro<\/strong>: I nodi che ospitano contemporaneamente DB-Pods e front-end web non registrano valori estremi. Se necessario, distribuisco i ruoli su nodi diversi.<\/li>\n  <li><strong>Lancio<\/strong>: Prima sulle Canary (un nodo), poi con un'implementazione graduale. Documento le modifiche nella baseline del nodo (sysctl.d) e annoto le distribuzioni interessate.<\/li>\n<\/ul>\n\n<h2>Casi speciali dalla pratica<\/h2>\n\n<p>\u00c8 possibile affrontare in modo mirato alcuni modelli, se ne conosco le cause:<\/p>\n\n<ul>\n  <li><strong>CI\/Processi di compilazione<\/strong>: Le operazioni che comportano numerosi accessi brevi ai file e scansioni delle directory traggono vantaggio da valori pi\u00f9 bassi. Li aumento nuovamente al termine del processo, nel caso in cui i nodi vengano utilizzati in modo misto.<\/li>\n  <li><strong>Finestra di backup\/scansione<\/strong>: Le operazioni di scansione delle directory di lunga durata svuotano la cache. Temporaneamente, un <em>pi\u00f9 alto<\/em> Valore (ad es. 180) per impedire che i dentries\/inode riempiano la RAM durante il backup \u2013 dopodich\u00e9 lo ripristino.<\/li>\n  <li><strong>Voci negative<\/strong>: Anche i file non esistenti (404) vengono memorizzati nella cache. I carichi di lavoro web caratterizzati da frequenti errori di accesso traggono vantaggi misurabili se la cache VFS non viene svuotata in modo troppo aggressivo.<\/li>\n  <li><strong>Streaming\/I\/O sequenziale<\/strong>: Qui prevale la cache delle pagine; valori troppo bassi sono poco efficaci e occupano inutilmente RAM. Io mi mantengo intorno a 100 o leggermente al di sopra.<\/li>\n<\/ul>\n\n<pre><code># Esempio: adottare un approccio leggermente pi\u00f9 aggressivo durante un backup completo\nsudo sysctl -w vm.vfs_cache_pressure=180\n# Al termine del backup, ripristinare il valore ottimale determinato in precedenza\nsudo sysctl -w vm.vfs_cache_pressure=60\n<\/code><\/pre>\n\n<h2>Automazione e governance<\/h2>\n\n<p>Dopo aver effettuato dei test positivi, integro questa impostazione nelle mie build standard. \u00c8 importante che i team sappiano che, <em>perch\u00e9<\/em> \u00e8 stato selezionato un valore e <em>quando<\/em> che deve essere verificato (ad esempio, in seguito a cambiamenti di versione o di carico di lavoro).<\/p>\n\n<ul>\n  <li><strong>Gestione della configurazione<\/strong>: Per ogni ruolo (Web, DB, server di file) definisco delle impostazioni predefinite in \/etc\/sysctl.d\/ e le distribuisco a livello centrale.<\/li>\n  <li><strong>Controllo della derapa<\/strong>: Gli audit periodici verificano se i valori in tempo reale e il repository corrispondono.<\/li>\n  <li><strong>Libri di corsa<\/strong>: Documento le fasi di misurazione, i valori limite per il rollback e le procedure di emergenza (ad es. il ripristino a 100).<\/li>\n<\/ul>\n\n<pre><code># Ruolo: server web (esempio)\ncat &lt;&lt;&#039;EOF&#039; | sudo tee \/etc\/sysctl.d\/50-web-vfs.conf\nvm.vfs_cache_pressure = 60\nEOF\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>vm.vfs_cache_pressure e altri parametri del kernel<\/h2>\n\n<p>Un buon risultato si ottiene solo in sinergia con <strong>vm.swappiness<\/strong> e le soglie delle pagine sporche. Un valore di swappiness pi\u00f9 basso (ad es. 10\u201320) tende a mantenere i processi nella RAM ed evita lo spostamento in swap non necessario. Con vm.dirty_background_ratio e vm.dirty_ratio regolo la tempestivit\u00e0 con cui il sistema scrive le pagine modificate, in modo che i picchi di scrittura non blocchino tutto. Imposto questi valori in modo che le ricerche dei metadati rimangano veloci e le operazioni di scrittura si svolgano in modo pianificabile. A questo proposito, mi avvalgo di una panoramica concisa sull\u2019interazione delle cache dei file: <a href=\"https:\/\/webhosting.de\/it\/filesystem-caching-linux-page-cache-cacheboost\/\">Panoramica sulla memorizzazione nella cache del filesystem<\/a>.<\/p>\n\n<h2>Raccomandazioni per gli ambienti di hosting e WordPress<\/h2>\n\n<p>Molti temi, plugin e file multimediali generano innumerevoli file di piccole dimensioni, motivo per cui \u00e8 necessario un potente <strong>Cache VFS<\/strong> aiuta in modo tangibile. Comincio con 100, se la RAM \u00e8 sufficiente scendo a 80, poi a 60, e controllo i tempi di risposta, il 95\u00b0 percentile delle latenze e lo \u201cCPU steal\u201d. Se la memoria rimane a livelli adeguati, provo con 50 e convalido nuovamente durante il picco serale o nel corso delle campagne. Se le latenze diminuiscono senza che scatti lo swap o l\u2019OOM killer, salvo l\u2019impostazione in modo permanente. Parallelamente tengo d\u2019occhio la cache di pagina, affinch\u00e9 entrambe le cache si integrino in modo ottimale.<\/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-optimierung-7834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sintesi<\/h2>\n\n<p>Con vm.vfs_cache_pressure controllo la <strong>Equilibrio<\/strong> in modo molto mirato, in base alla velocit\u00e0 delle ricerche nei metadati e alla RAM libera. Per i carichi di lavoro legati al web abbasso moderatamente il valore, mentre per le applicazioni che richiedono molta memoria lo aumento. Ogni modifica viene documentata con i valori misurati relativi alle latenze I\/O, ai colpi in cache e all\u2019attivit\u00e0 di swap. In combinazione con vm.swappiness e i parametri Dirty, ottengo una gestione della memoria stabile. In questo modo utilizzo in modo efficiente la cache del filesystem di Linux e mantengo affidabilmente bassi i tempi di risposta sotto carico.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come sfruttare al meglio la cache del filesystem di Linux utilizzando \u201cvm.vfs_cache_pressure\u201d come parola chiave principale, come gestire la cache in modo mirato e come migliorare le prestazioni dei carichi di lavoro dei tuoi server.<\/p>","protected":false},"author":1,"featured_media":20867,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20874","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":"117","_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":"vm.vfs_cache_pressure","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":"20867","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20874","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=20874"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20874\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20867"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20874"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20874"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20874"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}