Un server con RAM libera che continua a usare swap è uno degli scenari più fraintesi nella diagnostica Linux. La reazione istintiva è quasi sempre la stessa: aumentare la RAM o disattivare lo swap. Nessuna delle due è la risposta giusta se prima non sai quale processo sta finendo su disco e perché. Lo strumento più adatto a rispondere a questa domanda è smem, un tool di reporting che calcola l’uso di memoria proporzionale per processo, swap incluso — una cosa che top e ps da soli non fanno.

Perché il kernel usa lo swap anche con RAM libera

Linux è progettato per usare tutta la RAM disponibile, spesso per la cache dei file. Quando il kernel decide che alcune pagine di memoria non vengono accedute da un po’, può spostarle su swap anche se c’è ancora RAM libera: è un comportamento intenzionale, non un guasto. Il parametro che governa questa aggressività è vm.swappiness, un valore da 0 a 200 che esprime quanto il kernel preferisce recuperare pagine di cache file rispetto a spostare pagine anonime su swap.

Un dettaglio poco noto e rilevante da kernel 5.8 in poi: con i cgroup v2, vm.swappiness=0 non significa più “non spostare mai nulla su swap”. Continua a indicare una forte preferenza per liberare cache file, ma il kernel spingerà comunque pagine anonime su swap se è vicino all’OOM. Prima di intervenire su questo parametro, però, il primo passo resta capire chi sta effettivamente consumando swap.

Installare smem

Non è quasi mai preinstallato, ma è nei repository delle principali distribuzioni:

# RHEL / CentOS / AlmaLinux / Fedora
dnf install smem

# Debian / Ubuntu
apt install smem

USS, PSS e RSS: la differenza che conta davvero

La ragione per cui smem è più utile di un ps aux --sort=-rss al volo sta nelle metriche che espone. ps e top mostrano principalmente RSS, che sovrastima sistematicamente l’uso di memoria perché conta anche le pagine condivise tra processi (librerie, memoria mappata) come se appartenessero interamente a ciascun processo.

• RSS (Resident Set Size): memoria fisica occupata dal processo, incluse le pagine condivise con altri processi — per questo tende a sovrastimare.
• USS (Unique Set Size): memoria usata esclusivamente da quel processo, senza nulla di condiviso. È quanta memoria verrebbe effettivamente liberata se il processo terminasse.
• PSS (Proportional Set Size): somma la USS più una quota proporzionale della memoria condivisa, distribuita tra tutti i processi che la usano. È la metrica più realistica per capire “quanta memoria sta davvero consumando il sistema per questo processo”, perché sommando i PSS di tutti i processi non conti la stessa pagina condivisa più volte.

Su un web server con decine di processi PHP-FPM o worker Nginx che condividono le stesse librerie, la differenza tra RSS e PSS può essere enorme: sommare tutti gli RSS ti dà un numero fantasioso, sommare i PSS ti avvicina al reale consumo di RAM del sistema.

Uso di base: chi sta consumando swap

Il comando principale per la diagnosi dello swap ordina i processi per swap decrescente:

smem -rs swap

Output tipico (troncato):

  PID User     Command                         Swap      USS      PSS      RSS
28986 mysql    /usr/sbin/mysqld --daemoniz   476372  10963864 10963932 10965112
29152 root     /usr/sbin/rsyslogd -n         371424     3956    17475    43352
31423 root     /opt/fluent-bit/bin/fluent-     22508    26612    26739    29100

In questo esempio è immediato vedere che mysqld e rsyslogd sono i responsabili principali dello swap, non un generico “sistema pieno”. Questo è già un’informazione azionabile: invece di aggiungere RAM alla cieca, sai su quale servizio intervenire.

Per una vista più visuale, smem genera anche grafici a torta per utente o processo, utile per presentare rapidamente la distribuzione dei consumi:

smem --pie name -s rss

(richiede matplotlib installato per generare l’immagine).

Cosa fare dopo aver identificato il colpevole

Una volta isolato il processo, la strada tipica è duplice: da un lato tuning applicativo del servizio (per MySQL, rivedere innodb_buffer_pool_size e le connessioni aperte; per rsyslog, verificare codeon accumulo di code su disco lento), dall’altro una revisione più conservativa di vm.swappiness:

sysctl vm.swappiness=1
echo 'vm.swappiness=1' >> /etc/sysctl.conf

Un valore basso (1-10) dice al kernel di preferire fortemente la RAM e ricorrere allo swap solo come ultima risorsa, comportamento adatto alla maggior parte dei carichi di hosting: il default di 60 è pensato per un uso desktop generico ed è piuttosto aggressivo per un server.

Se il servizio gira in un cgroup (container, systemd slice)

Su sistemi che orchestrano i workload con cgroup v2 — container Docker/Podman, unit systemd con MemoryMax=, pod Kubernetes — la vecchia intuizione su swap e RAM va integrata con un secondo livello di controllo: memory.swap.max. Questo parametro è un limite massimo di swap utilizzabile dal cgroup: se il cgroup raggiunge quel tetto, la memoria anonima al suo interno smette di essere spostata su swap, indipendentemente da cosa dice vm.swappiness a livello di kernel. Non è pensato per gestire quanto swap viene usato durante il funzionamento normale, ma come argine per evitare che un singolo cgroup saturi lo swap dell’intero host.

Una pratica ragionevole quando si dimensionano i limiti di un cgroup è impostare memory.high attorno al 10-20% sotto memory.max, per dare al kernel margine di reclaim prima di colpire il limite duro, e aggiungere un 20-30% al di sopra del picco di utilizzo reale dell’applicazione quando si calcola memory.max, per tenere conto della page cache che nei cgroup v2 conta comunque contro il totale di memoria assegnato.

Conclusione

smem è uno strumento leggero ma preciso per rispondere a una domanda che free, top o vmstat lasciano aperta: non solo “quanto swap sto usando”, ma “chi lo sta usando e quanto pesa davvero, al netto della memoria condivisa”. Su un server che sembra inspiegabilmente lento nonostante RAM apparentemente disponibile, è spesso il primo strumento da tirare fuori prima di toccare vm.swappiness, aggiungere RAM o — peggio — disattivare lo swap del tutto, cosa che su Linux tende a peggiorare le cose sotto pressione di memoria invece di risolverle.

Fonte originale: Diagnosing Swap Usage with smem on Linux, LinuxBlog.io