Best Practices per la Regolazione del Swappiness e del Comportamento della Cache in Linux

Linux utilizzerà la RAM libera. Questo sorprende le persone la prima volta che vedono un server con pochissima memoria "libera" in free -h. Gran parte di quella memoria potrebbe essere cache di pagina, dentry e cache di inode, non una perdita. La parte difficile è sapere quando il kernel sta facendo buon uso della RAM e quando il recupero della memoria sta iniziando a danneggiare le tue applicazioni.

Due impostazioni sysctl vengono spesso menzionate durante la regolazione della memoria di Linux: vm.swappiness e vm.vfs_cache_pressure. Sono utili, ma non sono interruttori di prestazioni magici. Un valore sbagliato può nascondere il vero problema o spostare il dolore da un carico di lavoro all'altro.

Comprensione dei Parametri di Gestione della Memoria di Linux

Linux utilizza euristiche per decidere quali pagine di memoria recuperare quando il sistema necessita di più RAM libera. Le due aree principali controllate dai parametri del kernel sono lo swapping (spostamento delle pagine di memoria inattive su disco) e la caching (mantenimento dei metadati del filesystem e dei dati in RAM).

1. `vm.swappiness`

vm.swappiness determina la tendenza del kernel a spostare i processi dalla memoria fisica allo spazio di swap su disco. È un valore compreso tra 0 e 100.

Valore più alto (ad esempio, 60, un valore predefinito comune): Il kernel è più disposto a recuperare memoria anonima e utilizzare lo swap come parte della normale gestione della memoria. Questo può preservare la cache di pagina, ma può anche danneggiare i servizi sensibili alla latenza se le pagine attive vengono espulse.
Valore basso (ad esempio, 10 o meno): Il kernel preferisce recuperare memoria dalla cache di pagina prima di iniziare a spostare i processi in swap. Questo mantiene le applicazioni in esecuzione in RAM più a lungo, migliorando la reattività ma potenzialmente riducendo le prestazioni di I/O del disco se il sistema deve costantemente eliminare le pagine della cache.
Valore 0: Il kernel evita lo swapping il più possibile, ma questo non disabilita lo swap. Se devi disabilitare lo swap, usa swapoff e comprendi prima il rischio di esaurimento della memoria.

Applicazione Pratica di `vm.swappiness`

L'impostazione ottimale dipende fortemente dal carico di lavoro:

Tipo di Carico di Lavoro	Intervallo di `swappiness` Consigliato	Motivazione
Server di Database, Calcolo ad Alte Prestazioni (HPC)	1 - 10	Spesso un buon punto di partenza quando la latenza dello swap è peggiore rispetto all'eliminazione della cache. Convalida con metriche del carico di lavoro reale.
Server per Scopi Generali, Desktop	30 - 60	Di solito ragionevole a meno che non ci siano prove che il comportamento dello swap ti stia danneggiando.
Sistemi di file-serving o con cache pesante	60 o superiore in alcuni casi	Può preservare la cache di pagina, ma ha senso solo se lo swapping occasionale è accettabile per il carico di lavoro.

Come Verificare il Valore Corrente:

cat /proc/sys/vm/swappiness

Come Cambiare il Valore Temporaneamente (fino al riavvio):

Per impostare swappiness a 10:

sudo sysctl vm.swappiness=10

Come Cambiare il Valore Permanentemente:

Modifica il file /etc/sysctl.conf e aggiungi o modifica la riga:

# /etc/sysctl.conf
vm.swappiness = 10

Dopo aver salvato, applica le modifiche senza riavviare usando:

sudo sysctl -p

Per database con uso intensivo di memoria, da 1 a 10 è un punto di partenza comune. Non trattarlo come una regola. Un database che ha già la propria cache di buffer, come PostgreSQL o MySQL/InnoDB, di solito beneficia dell'evitare lo swap. Un file server potrebbe preferire una cache di pagina più grande. Una piccola VM con troppa poca RAM soffrirà indipendentemente dal numero scelto.

2. `vfs_cache_pressure`

vfs_cache_pressure controlla quanto aggressivamente il kernel recupera la memoria utilizzata per i metadati di directory e inode (la cache VFS).

Questo valore varia da 0 a 1000.
Il valore predefinito è tipicamente 100.

Con un valore di 100, il kernel bilancia il recupero della memoria della cache VFS rispetto al recupero della memoria utilizzata dalla cache di pagina (dati del disco). Un valore di 100 significa che quando c'è pressione sulla memoria, il kernel cerca di recuperare 1 parte di memoria cache inode/dentry per ogni 1 parte di memoria cache di pagina.

Regolazione di `vfs_cache_pressure`

Aumentare il Valore (ad esempio, > 100): Rende il kernel più aggressivo nel recuperare la memoria della cache VFS. Questo libera RAM più velocemente ma può portare a ricerche del filesystem successive più lente, poiché i metadati devono essere letti di nuovo dal disco.
Diminuire il Valore (ad esempio, < 100): Rende il kernel più conservativo nel recuperare la cache VFS. Questo mantiene le informazioni di directory e inode in memoria più a lungo, accelerando le operazioni ripetute del filesystem.

Quando Diminuire vfs_cache_pressure:

Se il tuo sistema accede frequentemente alle stesse grandi strutture di directory (comune in applicazioni complesse, orchestrazione di container o configurazioni di rete specifiche), impostare questo valore più basso (ad esempio, 50) può migliorare le prestazioni mantenendo i metadati prontamente disponibili in RAM.

Quando Aumentare vfs_cache_pressure:

Se il tuo sistema soffre di pressione generale sulla memoria e desideri che il kernel recuperi rapidamente qualsiasi memoria inutilizzata, potresti aumentare questo valore, anche se questo è meno comune che abbassarlo.

Come Verificare il Valore Corrente:

cat /proc/sys/vm/vfs_cache_pressure

Come Cambiare il Valore Permanentemente:

Modifica /etc/sysctl.conf:

# /etc/sysctl.conf
vfs_cache_pressure = 50

Applica le modifiche con sudo sysctl -p.

Avvertenza: Valori molto bassi di vfs_cache_pressure possono far sì che il kernel mantenga la cache di directory e inode più a lungo del previsto. Questo può aiutare i carichi di lavoro pesanti sui metadati, ma può anche peggiorare la pressione della memoria per le applicazioni. Evita valori estremi a meno che tu non abbia misurato l'effetto.

Scenari Completi di Regolazione

Scegliere la giusta combinazione di questi parametri ottimizza il compromesso tra stabilità dell'applicazione e caching del filesystem.

Scenario 1: Server di Database (Priorità alla Memoria)

Obiettivo: Massimizzare la residenza della memoria dell'applicazione; ridurre al minimo lo swapping a tutti i costi.

vm.swappiness = 5
vfs_cache_pressure = 50 (Mantieni i dati della directory in cache in una certa misura, ma dai priorità alla memoria dell'applicazione rispetto ai metadati VFS se la RAM diventa scarsa).

Prima di cambiare qualsiasi cosa, verifica se il database sta effettivamente facendo swapping:

free -h
vmstat 1
grep -E 'pswpin|pswpout' /proc/vmstat

Se i contatori di swap-in e swap-out stanno aumentando durante i picchi di latenza delle query, abbassare swappiness può aiutare. Se lo swap non viene utilizzato e il database è lento, swappiness non è il tuo problema. Esamina invece i piani di query, il rapporto di hit del buffer, i checkpoint, la latenza del disco e la pressione delle connessioni.

Scenario 2: Server con Elevato I/O su Disco (Priorità alla Cache)

Obiettivo: Massimizzare le prestazioni del disco mantenendo i dati dei file a cui si accede frequentemente nella cache di pagina.

vm.swappiness = 80 (Consente lo swapping prima per liberare RAM per l'espansione della cache del disco).
vfs_cache_pressure = 100 (Bilanciamento standard tra cache di inode e pagina).

Questo è lo scenario in cui le persone più spesso esagerano con la regolazione. Se il server legge per lo più gli stessi file ripetutamente, la cache di pagina è importante. Ma se il sistema inizia a fare swapping dei processi di lavoro attivi per preservare la cache, gli utenti potrebbero vedere una latenza peggiore anche se la cache del filesystem sembra sana. Osserva il tempo di risposta dell'applicazione, non solo la dimensione della cache.

Scenario 3: Host di Virtualizzazione o Sistema per Scopi Generali

Obiettivo: Prestazioni stabili su più carichi di lavoro.

vm.swappiness = 30 (Un'impostazione moderata che favorisce il mantenimento di VM/processi attivi in RAM leggermente più a lungo rispetto al valore predefinito di 60, ma consente comunque uno swapping controllato).
vfs_cache_pressure = 100 (Il valore predefinito è spesso sufficiente).

Gli host di virtualizzazione necessitano di particolare cautela perché il comportamento della memoria degli ospiti può fuorviare la regolazione a livello di host. Il ballooning, l'overcommit e lo swap degli ospiti possono tutti interagire. Un host che fa swapping pesante della memoria degli ospiti può creare una latenza dolorosa all'interno delle VM anche quando ogni ospite pensa che il proprio carico di lavoro sia normale.

Un Flusso di Lavoro di Regolazione Più Sicuro

Non iniziare modificando /etc/sysctl.conf. Inizia dimostrando che l'impostazione è rilevante.

Cattura una baseline durante il carico normale:

free -h
vmstat 1 10
cat /proc/sys/vm/swappiness
cat /proc/sys/vm/vfs_cache_pressure

Cattura gli stessi dati durante il periodo di rallentamento. Aggiungi la memoria a livello di processo:
```
ps -eo pid,comm,rss,vsz,%mem --sort=-rss | head -20
```
Cambia un valore temporaneamente:
```
sudo sysctl vm.swappiness=10
```
Esegui il carico di lavoro abbastanza a lungo per osservare il comportamento. Cerca una minore attività di swap, una migliore latenza dell'applicazione e nessun nuovo rallentamento del filesystem.
Rendi il valore persistente solo dopo che ha superato una finestra di test realistica.

Sui sistemi che utilizzano /etc/sysctl.d/, un piccolo file dedicato è spesso più pulito che aggiungere a /etc/sysctl.conf:

sudo tee /etc/sysctl.d/90-memory-tuning.conf >/dev/null <<'EOF'
vm.swappiness = 10
vm.vfs_cache_pressure = 100
EOF

sudo sysctl --system

Se il tuo sistema di gestione della configurazione possiede le impostazioni sysctl, inserisci la modifica lì invece. Le modifiche manuali di sysctl su un server sono facili da dimenticare e difficili da riprodurre.

Leggere `free -h` Senza Farsi Prendere dal Panico

Un tipico output di free -h potrebbe mostrare un numero piccolo sotto free e un numero grande sotto buff/cache. Questo è normale. Linux mantiene in memoria i dati dei file usati di recente perché la RAM inutilizzata non aiuta nessuno.

Concentrati su available, l'uso dello swap e se l'attività di swap sta avvenendo ora. Un server può avere swap allocato da un picco di memoria passato ma nessun attuale churn di swap. Questo è meno urgente di un server che fa continuamente swap in e out.

Usa:

vmstat 1

Se si e so rimangono vicini allo zero sotto carico normale, lo swap non sta guidando attivamente la latenza in quel momento. Se rimangono diversi da zero mentre le applicazioni si bloccano, la pressione della memoria è un sospetto serio.

Quando Non Regolare Queste Impostazioni

Ci sono diversi casi in cui cambiare swappiness o la pressione della cache è la prima soluzione sbagliata.

Se il server non ha swap configurato, vm.swappiness ha poco effetto pratico. Potresti comunque regolarlo per coerenza delle policy, ma non risolverà la pressione della memoria da solo.

Se lo swap esiste solo come una piccola partizione di emergenza, anche l'impostazione ha spazio limitato per aiutare. Il kernel può scegliere quando usare lo swap, ma non può trasformare poche centinaia di megabyte di spazio di emergenza in un vero livello di memoria. In quella configurazione, concentrati sul rischio OOM e sui limiti del servizio.

Se un processo ha una reale perdita di memoria, abbassare swappiness ritarda il dolore. La perdita continuerà a crescere. Riavviare il servizio può ripristinare temporaneamente la capacità, ma la soluzione duratura è a livello di applicazione: correggi la perdita, limita la memoria, riduci la concorrenza o cambia il carico di lavoro.

Se il disco è lento a causa di un'unità guasta, limitazione dello storage o un volume cloud saturo, la regolazione della memoria può ridurre alcune letture ma non risolverà il guasto dello storage. Controlla iostat, i log del kernel, le metriche del volume cloud e lo stato di salute SMART/NVMe.

Se il working set è più grande della RAM, non esiste un valore sysctl perfetto. Hai bisogno di più memoria, meno concorrenza, cache più piccole, un diverso layout dei dati o una suddivisione del carico di lavoro.

Note su Container e Kubernetes

La regolazione della memoria diventa più complicata nei container. Un container può raggiungere il suo limite di memoria cgroup anche mentre l'host ha RAM libera. L'impostazione di swappiness dell'host conta ancora, ma il sintomo immediato potrebbe essere un kill OOM all'interno di un pod o container.

Controlla i segnali cgroup e dell'orchestratore:

dmesg -T | grep -i 'killed process'
docker stats
kubectl describe pod <nome-pod>

Per Kubernetes, la modifica dei sysctl a livello di nodo dovrebbe far parte della configurazione del pool di nodi, non di una sessione shell una tantum. Ricorda anche che alcuni sysctl sono con namespace e altri sono a livello di nodo. vm.swappiness e vm.vfs_cache_pressure sono impostazioni a livello di host sui tipici sistemi Linux, quindi modificarle influisce su ogni carico di lavoro su quel nodo.

Monitoraggio e Validazione

Dopo aver applicato le modifiche, il monitoraggio continuo è cruciale per convalidare l'impatto. Usa strumenti come free, vmstat e dashboard di monitoraggio delle prestazioni del sistema.

Usando vmstat:

Monitora le colonne si (swap in) e so (swap out). Un sistema sano con basso swappiness dovrebbe mostrare valori bassi o zero per si e so sotto carico normale.

vmstat 5 10

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 123456 102400 5123456    0    0     0     5   40   70  1  1 98  0  0

Se i valori so rimangono alti dopo aver ridotto swappiness, il carico di lavoro probabilmente necessita di più memoria utilizzabile o di una minore richiesta di memoria. Più RAM è una risposta, ma non l'unica. Puoi anche ridurre i conteggi dei worker, ridurre le cache dell'applicazione, regolare la memoria del database, correggere le perdite o suddividere i servizi tra gli host.

Tratta vm.swappiness e vm.vfs_cache_pressure come preferenze del carico di lavoro, non come aggiornamenti universali. Il percorso pratico è noioso ma affidabile: misura l'attuale comportamento di swap e recupero, cambia un'impostazione, testa sotto carico reale e mantieni la modifica solo se il comportamento dell'applicazione migliora.