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 liberaLinux è 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 smemNon è quasi mai preinstallato, ma è nei repository delle principali distribuzioni:# RHEL / CentOS / AlmaLinux / Fedora dnf install smem # Debian / Ubuntu apt install smemUSS, PSS e RSS: la differenza che conta davveroLa 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 swapIl comando principale per la diagnosi dello swap ordina i processi per swap decrescente:smem -rs swapOutput 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 29100In 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 colpevoleUna 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.confUn 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.Conclusionesmem è 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

Il process manager sbagliato è spesso il vero collo di bottiglia di PHPQuando un’applicazione PHP inizia a rallentare sotto traffico reale, la prima cosa che si tende a ottimizzare è il codice: query più efficienti, cache applicativa, opcache. Tutte cose giuste, ma c’è un parametro a monte che viene sistematicamente sottovalutato e che, su un server con traffico costante, può pesare quanto tutto il resto messo insieme: il process manager (PM) di PHP-FPM.La quasi totalità delle installazioni lascia pm impostato su dynamic, il valore di default, oppure viene consigliato di passare a ondemand quando la memoria disponibile è scarsa. Per un server che riceve traffico costante e prevedibile, però, esiste una terza opzione quasi sempre trascurata: pm = static. In questo articolo vediamo perché, come calcolare i parametri corretti e in quali scenari conviene davvero.Le tre modalità del process managerPHP-FPM gestisce un pool di processi worker che eseguono lo script PHP per ogni richiesta. Il parametro pm nel file di configurazione del pool decide come questi worker vengono creati e distrutti nel tempo:dynamic: il numero di processi figli varia dinamicamente in base a pm.max_children, pm.start_servers, pm.min_spare_servers e pm.max_spare_servers. All’avvio del servizio vengono lanciati pm.start_servers worker, poi il pool si espande e si contrae seguendo il carico.ondemand: i processi vengono avviati solo quando arriva una richiesta, invece di essere già pronti all’avvio del servizio come accade con dynamic. Ottimo per il risparmio di memoria, meno per la latenza sul primo hit.static: il numero di processi figli è fisso, determinato unicamente da pm.max_children. Nessuna logica di scaling: i worker vengono creati all’avvio e restano attivi.La documentazione ufficiale di PHP elenca tutte le direttive globali di php-fpm.conf, ma la scelta tra queste tre modalità è più una questione di architettura del server che di singola direttiva.Un parallelo utile: il governor della CPUChiunque abbia mai armeggiato con le impostazioni di risparmio energetico della CPU (CPUFreq governor, presenti sia su *nix che su Windows) riconoscerà lo stesso identico compromesso:ondemand: scala la frequenza dinamicamente in base al carico corrente, saltando rapidamente alla frequenza massima per poi scendere durante i periodi di inattività.conservative: scala la frequenza in modo più graduale rispetto a ondemand.performance: mantiene sempre la CPU alla frequenza massima.Il compromesso è lo stesso che si ritrova in PHP-FPM: un’impostazione privilegia la reattività immediata, le altre il risparmio di risorse durante i periodi di inattività. Con il governor performance, i core mantengono la frequenza massima invece di scalare verso il basso in idle: è un boost di prestazioni relativamente sicuro, il cui costo dipende quasi solo dai limiti termici della CPU. Lo stesso principio, applicato ai processi PHP-FPM invece che ai cicli di clock, è ciò che rende pm = static efficace su un server sotto carico costante.Usare pm static per il massimo delle prestazioniL’impostazione pm = static dipende fortemente dalla memoria libera disponibile sul server. Se la memoria è scarsa, ondemand o dynamic restano scelte più sicure. Se invece la memoria è disponibile, static elimina gran parte dell’overhead di gestione del pool impostando il numero di worker al massimo che il server può sostenere.In pratica, pm.max_children con static va calcolato come il numero massimo di processi PHP-FPM che possono girare senza generare pressione sulla memoria disponibile o sulla cache del sistema, e senza saturare le CPU con una coda di operazioni PHP-FPM in attesa.Un caso reale: un server con 32 GB di RAM installata, pm = static e pm.max_children = 100, usa un massimo di circa 10 GB. Anche con circa 200 utenti attivi negli ultimi 60 secondi (dato preso da Google Analytics), circa il 70% dei worker PHP-FPM resta idle. Questo è precisamente il punto: PHP-FPM lavora sempre alla capacità massima configurata, indipendentemente dal traffico istantaneo, e i worker idle restano pronti a rispondere immediatamente ai picchi di traffico invece di dover attendere che il process manager ne generi di nuovi (e poi li termini dopo che pm.process_idle_timeout scade).Calcolare pm.max_children, non indovinarloIl passaggio più importante, spesso saltato, è misurare invece di stimare a occhio. Prima si misura la dimensione media residente (RSS) di un worker PHP-FPM sotto carico reale:ps --no-headers -o rss -C php-fpm | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB" }'A questo punto si divide la memoria che si è disposti a dedicare a PHP-FPM per questo valore medio. Se un worker occupa in media 60 MB e si vogliono allocare 6 GB a PHP-FPM, il calcolo è circa pm.max_children = 100 (6144 / 60). È fondamentale lasciare margine per il sistema operativo, il web server e il database: non va mai assegnata a PHP-FPM tutta la RAM fisica disponibile.Da qui si procede per iterazioni: si testa sotto carico reale e si affina il valore osservando uso di memoria, utilizzo CPU e tempi di risposta. Con pm = static, poiché i worker restano già residenti in memoria, i picchi di traffico si traducono in picchi di carico e CPU molto più contenuti, e le medie restano più stabili nel tempo.Per monitorare i processi attivi in tempo reale si può usare top filtrato per utente:top -bn1 | grep php-fpmImpostando anche pm.max_requests a un valore alto (o a 0 per disabilitare il riavvio periodico dei worker) si evita ulteriore overhead di gestione, ma questa scelta ha senso solo su un server di produzione senza memory leak noti negli script PHP. In generale conviene comunque impostare un valore alto ma finito, ad esempio pm.max_requests = 1000, per garantire un riavvio periodico dei worker senza reintrodurre overhead significativo.Quando usare ondemand e dynamic invece di staticCon pm = dynamic capita spesso di incontrare un warning simile a questo nei log:WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total childrenIl consiglio più comune, in questi casi, è passare a ondemand. Su un server costantemente sotto carico, però, questa scelta si ritorce contro: ondemand azzera i worker idle appena il traffico cala, per poi doverli rigenerare non appena il traffico torna a salire, scambiando risparmio di memoria con latenza di spawn esattamente nel momento peggiore. Un timeout di idle molto alto attenua il problema, ma a quel punto conviene semplicemente passare a pm.static con un pm.max_requests elevato.dynamic e soprattutto ondemand restano invece la scelta giusta in scenari con molti pool PHP-FPM distinti sullo stesso server, ad esempio hosting condiviso con centinaia di account cPanel o siti diversi ciascuno con il proprio pool. In un ambiente con 100+ pool e 200+ domini, dove la maggior parte dei siti riceve pochissimo traffico, static o dynamic sprecherebbero enormi quantità di memoria su worker perennemente idle: ondemand chiude i worker inattivi liberando memoria, motivo per cui è diventato il default in ambienti come cPanel.Un cenno ai containerLo stesso ragionamento va adattato quando PHP-FPM gira dentro un container con risorse limitate (ad esempio 0.5 vCPU e 1 GB di RAM) e la scalabilità è orizzontale, tramite orchestrazione (Docker Swarm, Kubernetes). In questi contesti pm.static resta spesso l’unica scelta sensata a livello di singolo container, ma la decisione su quando far partire un nuovo container non può basarsi solo su CPU e memoria: va monitorato anche il numero di processi PHP-FPM attivi rispetto a pm.max_children. Se il pool ha 50 worker configurati e 40 sono già occupati, è il momento di avviare un nuovo container, indipendentemente da quanto CPU e RAM stiano effettivamente segnalando in quel momento. Questo richiede di esporre lo stato di php-fpm status al sistema di autoscaling, valutato a intervalli brevi.ConclusioneSuperata una certa soglia di traffico costante, ondemand e dynamic introducono un overhead di gestione dei processi che una configurazione static ben calcolata elimina alla radice. La regola pratica è semplice da enunciare ma richiede disciplina nell’applicarla: non indovinare pm.max_children, misurarlo a partire dal consumo medio di RSS dei worker sotto carico reale, lasciare margine per OS, web server e database, e poi affinare osservando le metriche reali. Su un server dedicato o una VM con traffico prevedibile, il guadagno in stabilità di CPU e tempi di risposta è concreto. Su hosting condiviso con centinaia di pool a bassissimo traffico, ondemand resta la scelta più razionale. Conoscere il proprio sistema, prima ancora del proprio codice PHP, è ciò che fa la differenza.Fonte: PHP-FPM tuning: Using ‘pm static’ for max performance, LinuxBlog.io (Hayden James)

Nel 2026 quasi tutto il traffico web viaggia in HTTPS, ma quanto di quella cifratura sta ancora costando millisecondi inutili al vostro Time To First Byte? Molte configurazioni Nginx che giravano perfettamente nel 2020 oggi trascinano direttive deprecate, parametri OCSP che non fanno più nulla e cipher suite che TLS 1.3 ignora comunque. Vale la pena rimettere mano al blocco ssl_* del vostro server, non per inseguire un punteggio più alto su SSL Labs, ma perché ogni handshake più corto si moltiplica per il numero di visitatori.Va detto subito, con onestà: il tuning TLS non salva un backend lento. Se il TTFB del vostro sito è dominato da query al database, cache fredda o un’applicazione PHP/.NET che impiega 800ms a costruire la pagina, ottimizzare l’handshake sposta l’ago di qualche decina di millisecondi. Ma è ottimizzazione a costo quasi zero, che si somma a tutto il resto: cache, CDN, query tuning. Va fatta bene una volta e poi dimenticata.HTTP/2 e HTTP/3: la sintassi è cambiataSe la vostra configurazione risale a qualche anno fa, probabilmente avete ancora questa riga:listen 443 ssl http2;Funziona ancora, ma da Nginx 1.25.1 il parametro http2 sulla direttiva listen è deprecato: lanciando nginx -t su una build recente comparirà un warning esplicito. La forma corretta separa i due concetti:listen 443 ssl; http2 on;La direttiva http2 attiva il protocollo per l’intero server block, il che è più pulito che ripeterlo su ogni riga listen. Se gestite una flotta di server dietro un load balancer, verificate che tutte le istanze montino Nginx 1.25.1 o superiore prima di effettuare lo switch: una versione più vecchia non riconosce http2 on; e si rifiuta di avviarsi.Attivare HTTP/3 con QUIC senza compilare nullaFino a poco tempo fa, abilitare HTTP/3 su Nginx significava patchare e ricompilare da sorgente contro una libreria TLS con supporto QUIC: un esercizio che pochi sistemisti volevano affrontare in produzione. Quell’epoca è finita. Il supporto nativo a QUIC e HTTP/3 è arrivato nel mainline Nginx a partire dalla 1.25.0 ed è ormai maturo nel branch stable, quindi sulle distribuzioni recenti o sul repository ufficiale Nginx non serve più compilare nulla a mano.Va detto che, nonostante l’entusiasmo degli anni scorsi, l’adozione reale di HTTP/3 procede più lentamente del previsto: a metà 2026 HTTP/2 serve poco più della metà delle richieste globali mentre HTTP/3 si attesta intorno al 21%, con un plateau che dura da diversi mesi. Parte del motivo è strutturale: un browser passa a HTTP/3 solo dopo aver scoperto il supporto tramite un header Alt-Svc o un record DNS, quindi molte prime visite non negoziano mai QUIC. Vale comunque la pena abilitarlo: sposta il trasporto su UDP ed elimina l’head-of-line blocking di TCP, un vantaggio concreto su connessioni mobili lente o con perdita di pacchetti.Su Nginx 1.25.0 o superiore con supporto QUIC integrato, un server block tipico è:server { listen 443 ssl; listen [::]:443 ssl; listen 443 quic reuseport; listen [::]:443 quic reuseport; http2 on; ssl_certificate /path/to/your/certificate.pem; ssl_certificate_key /path/to/your/key.pem; # Annuncia HTTP/3 ai client che arrivano via HTTP/1.1 o HTTP/2 add_header Alt-Svc 'h3=":443"; ma=86400'; # ... resto della configurazione del server }Attenzione a reuseport: va specificato una sola volta per combinazione IP/porta. Se gestite più server block sullo stesso indirizzo, mettete reuseport solo sul blocco predefinito e usate listen 443 quic; sugli altri, altrimenti Nginx si rifiuta di partire.L’header Alt-Svc è il dettaglio che quasi tutti dimenticano: senza di esso i browser non hanno modo di sapere che il server parla HTTP/3 e restano su HTTP/2. Dopo la modifica, testate e ricaricate:nginx -t nginx -s reloadPer verificare rapidamente da riga di comando quale protocollo state effettivamente servendo:curl --http2 -I https://vostrodominio.it/ curl --http3 -I https://vostrodominio.it/Session cache e session ticket: il vero risparmio sull’handshakeCon HTTPS, invece di una singola andata e ritorno, la connessione richiede un handshake aggiuntivo. Attivare la cache delle sessioni TLS riduce questo costo per le connessioni ripetute:ssl_session_cache shared:SSL:10m; # circa 40.000 sessioni ssl_session_timeout 1d; # tempo di riutilizzo della sessioneSui session ticket la raccomandazione è cambiata rispetto a qualche anno fa. Un tempo si consigliava di disabilitarli perché la rotazione della chiave di cifratura non era gestita correttamente da Nginx. Da Nginx 1.23.2 in poi la gestione delle chiavi per la ripresa stateless delle sessioni è molto migliorata, quindi salvo casi particolari conviene tenerli attivi:ssl_session_tickets on;Unica eccezione: se gestite più server Nginx dietro un bilanciatore senza sincronizzare le chiavi dei ticket tra le istanze, la ripresa della sessione si rompe silenziosamente e perdete il beneficio. In quel caso, sincronizzate le chiavi o disabilitate i ticket su tutta la flotta in modo coerente.Quali versioni TLS tenere attiveTLS 1.0 e 1.1 sono obsoleti, bloccati da ogni browser moderno e vietati dallo standard PCI DSS: vanno disattivati ovunque, senza eccezioni. La vera decisione riguarda invece TLS 1.2 e 1.3.Per la maggior parte dei siti pubblici, la scelta corretta è tenere entrambi attivi:ssl_protocols TLSv1.2 TLSv1.3;È TLS 1.3 a fare la differenza sul TTFB: riduce l’handshake a un singolo round trip e supporta la ripresa di sessione, quindi i visitatori che tornano si connettono più rapidamente. TLS 1.2 resta come fallback per client più datati e, su un sito pubblico normale, non costa nulla lasciarlo attivo.Passate a TLS 1.3 soltanto se controllate i client che si connettono: un’API interna, un backend applicativo, un servizio dove sapete con certezza che nessun client datato deve collegarsi:ssl_protocols TLSv1.3;Disabilitare TLS 1.2 su un sito pubblico è il tipo di modifica che sembra pulita in un file di configurazione e poi silenziosamente taglia fuori una fetta di traffico reale. Senza un motivo specifico, lasciatelo acceso.OCSP stapling: cosa è cambiato con Let’s EncryptL’OCSP stapling permette a Nginx di allegare all’handshake una prova firmata dalla CA della validità del certificato, evitando che il client debba interrogare direttamente il servizio OCSP. La configurazione classica resta questa:ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /path/to/full_chain.pem; resolver 8.8.8.8 8.8.4.4 valid=300s; resolver_timeout 5s;Ma qui c’è un cambiamento importante da conoscere se usate Let’s Encrypt: il 6 agosto 2025 Let’s Encrypt ha terminato il supporto OCSP e spento i propri responder. I certificati che emette oggi non hanno più un URL OCSP, ma un URL CRL al suo posto. Senza un responder da interrogare, ssl_stapling on; non fa più nulla sui certificati Let’s Encrypt e Nginx registra nei log un warning "ssl_stapling" ignored, no OCSP responder URL.Il bilancio onesto nel 2026 è questo: se la vostra CA pubblica ancora un URL OCSP, lo stapling resta un piccolo vantaggio innocuo e potete tenerlo attivo. Se siete su Let’s Encrypt, le direttive sopra sono ormai inerti e potete rimuoverle per tenere puliti configurazione e log. È parte di uno spostamento più ampio del settore verso CRL e certificati a vita breve.Buffer SSL più piccolo per ridurre il TTFBIl parametro ssl_buffer_size imposta la dimensione del buffer usato per inviare dati via HTTPS. Il valore predefinito è 16k, pensato per risposte di grandi dimensioni, ma per minimizzare il TTFB conviene spesso un valore più piccolo:ssl_buffer_size 4k;Il risparmio tipico è di 30-50 millisecondi sul TTFB, variabile a seconda del carico e delle dimensioni medie delle risposte servite.Configurazione completa consigliata per il 2026http2 on; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305'; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; ssl_session_tickets on; ssl_buffer_size 4k; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; add_header X-Frame-Options sameorigin; add_header X-Content-Type-Options nosniff;Da notare: con TLS 1.3 le cipher suite sono fissate dal protocollo stesso, quindi una lunga stringa ssl_ciphers personalizzata e una direttiva ssl_ecdh_curve manuale non portano quasi nessun beneficio. I cipher elencati sopra si applicano soltanto alle connessioni TLS 1.2, e ssl_prefer_server_ciphers va disattivato perché i client moderni scelgono in modo sensato per conto proprio. Piuttosto che ottimizzare a mano all’infinito, generate una configurazione aggiornata con il Mozilla SSL Configuration Generator e incollate solo le parti che vi servono.Se avete ancora in configurazione una riga X-Xss-Protection "1; mode=block", rimuovetela: l’XSS auditor del browser che controllava è stato eliminato da tutti i browser principali, e in alcuni casi quell’header può addirittura introdurre vulnerabilità invece di prevenirle. Una Content-Security-Policy è il sostituto moderno.ConclusioneNessuna di queste modifiche, presa singolarmente, trasformerà le prestazioni del vostro sito. Ma insieme costituiscono un livello di ottimizzazione a costo pressoché nullo che qualsiasi sistemista dovrebbe verificare almeno una volta l’anno, specialmente dopo un major upgrade di Nginx o un rinnovo dell’infrastruttura dei certificati. Testate sempre con nginx -t prima di ricaricare, verificate il risultato con SSL Labs e con l’ispezione della colonna Protocol negli strumenti di sviluppo del browser, e ricordate che il vero collo di bottiglia, nella maggior parte dei casi, resta ciò che succede dopo l’handshake: cache, query e tempo di generazione della risposta.Fonte: Nginx tuning tips: HTTPS/TLS – Turbocharge TTFB/Latency, LinuxBlog.io (Hayden James).

Perché il tuo server usa swap con RAM libera (e come scoprire chi è il colpevole con smem)Capita spesso: un server ha 32 o 64 GB di RAM, il carico è tutto sommato modesto, eppure free -h mostra qualche centinaio di MB o addirittura qualche GB in swap. Il riflesso istintivo di molti sistemisti è colpevolizzare la RAM insufficiente e chiedere un upgrade. Nella maggior parte dei casi, però, il problema non è la quantità di memoria disponibile, ma quali processi stanno finendo in swap e perché. Per rispondere serve uno strumento che guardi dentro ai singoli processi, non solo ai numeri aggregati: smem.Perché Linux usa lo swap anche con RAM liberaIl kernel Linux non tratta la RAM come una risorsa da tenere il più vuota possibile: la usa aggressivamente per la page cache, per velocizzare I/O su file e librerie. Quando il kernel individua pagine di memoria che non vengono acquisite/toccate da tempo, può decidere di spostarle in swap per liberare RAM fisica da destinare alla cache, anche se tecnicamente c’è ancora memoria “libera” disponibile. Questo comportamento è regolato dal parametro vm.swappiness (0-100, con default storicamente a 60 su molte distribuzioni), che indica al kernel quanto è propenso a scambiare memoria anonima verso lo swap piuttosto che liberare pagine di cache.Il punto chiave: prima di toccare vm.swappiness alla cieca, bisogna sapere chi sta effettivamente occupando swap. Un valore aggregato come quello di free non lo dice. Serve la vista per processo.smem: memoria proporzionale, non solo RSSTool classici come top o ps mostrano RSS (Resident Set Size), che però ha un difetto noto: se due processi condividono le stesse pagine di memoria (librerie condivise, memoria mappata), quella memoria viene contata per intero in ognuno dei due, gonfiando artificialmente i numeri quando si sommano i processi.smem risolve il problema calcolando anche:USS (Unique Set Size): memoria usata esclusivamente da quel processo, non condivisa con nessun altro — utile per capire quanto libereresti davvero uccidendo il processoPSS (Proportional Set Size): memoria condivisa divisa proporzionalmente tra i processi che la usano — la metrica più corretta per sommare l’uso reale di memoria di un sistema senza doppi conteggiSwap: quanta memoria di quello specifico processo è stata spostata su discoInstallazionesmem non è quasi mai preinstallato, ma è nei repository di tutte le principali distribuzioni:# RHEL / CentOS / AlmaLinux / Fedora dnf install smem # Debian / Ubuntu apt install smemUso pratico: trovare chi consuma swapIl comando base per ordinare i processi per swap consumato:smem -rs swapOutput tipico (troncato):PID User Command Swap USS PSS RSS 28986 mysql /usr/sbin/mysqld --daemon 476372 10963864 10963932 10965112 29152 root /usr/sbin/rsyslogd -n 371424 3956 17475 43352 31423 root /opt/fluent-bit/bin/fluent 22508 26612 26739 29100Da un output così è immediato capire che mysqld e rsyslogd sono i principali responsabili dell’uso di swap su questo host, e non un generico “poca RAM”. Da qui l’indagine si sposta su quel servizio specifico: per MySQL, ad esempio, tipicamente significa rivedere innodb_buffer_pool_size rispetto alla RAM totale disponibile, o verificare connessioni/thread che allocano memoria inutilmente.Alcune varianti utili del comando:# Ordina per USS (memoria realmente esclusiva del processo) smem -rs uss # Filtra per utente smem -u # Vista grafica a torta per RSS (richiede matplotlib) smem --pie name -s rssDalla diagnosi al tuningUna volta identificati i servizi che finiscono in swap, ci sono due strade complementari:Agire sul servizio: ridimensionare i buffer/pool applicativi (buffer pool di MySQL, heap JVM, cache applicative) in base alla RAM effettivamente disponibile, invece di lasciare valori di default pensati per macchine generiche.Agire sul kernel, solo dopo aver capito il quadro reale: ridurre vm.swappiness per rendere il kernel meno aggressivo nello spostare memoria anonima in swap:sysctl vm.swappiness=1 echo 'vm.swappiness=1' >> /etc/sysctl.confDa notare che vm.swappiness=0 non disabilita completamente lo swap su kernel recenti (dal 3.5 in poi il comportamento è cambiato rispetto alle versioni più vecchie), mentre valori molto bassi come 1 riducono drasticamente la propensione allo swap mantenendo comunque una valvola di sicurezza in caso di pressione di memoria reale. Su un database server dedicato, dove si preferisce quasi sempre tenere i dati “caldi” in RAM piuttosto che liberare cache, è una delle prime ottimizzazioni da considerare.ConclusioneVedere swap attivo su un server con RAM apparentemente libera non è di per sé un allarme: è il comportamento normale di un kernel che ottimizza l’uso della cache. Il problema comincia quando lo swap coinvolge processi critici per la latenza, come un database o un servizio applicativo, degradando le performance in modo silenzioso. smem -rs swap è il primo comando da lanciare in questi casi: in pochi secondi isola il processo responsabile, distingue la memoria condivisa da quella esclusiva, e trasforma un sintomo generico (“il server è lento”) in un’azione concreta di tuning, sul servizio o sul kernel.Fonte: LinuxBlog.io, “Diagnosing Swap Usage with smem on Linux”.