1 25/05/2026 10 min

Memcached su Ubuntu LTS: installazione pulita, servizio attivo e verifica reale

Su Ubuntu 24.04 e 22.04 LTS l’installazione di Memcached è lineare, ma il punto non è solo portare su il demone: va verificato dove ascolta, con quali limiti di memoria, chi può raggiungerlo e come si collega all’applicazione. In pratica, il lavoro utile finisce quando hai un servizio stabile, non esposto oltre il necessario e già testato con un client reale. Memcached è un cache server in RAM, senza persistenza e senza complicazioni inutili. Questa è la sua forza e anche il suo limite: se il nodo si riavvia, la cache sparisce; se lo esponi sulla rete sbagliata, diventa un bersaglio facile; se gli dai troppa poca memoria, inizia a evictare oggetti e il beneficio si riduce. Per questo conviene impostarlo subito con criterio, invece di correggere dopo.

Quando ha senso usarlo

Memcached torna utile quando devi alleggerire letture ripetitive: sessioni applicative, frammenti di pagina, query costose già normalizzate dall’applicazione, token temporanei o oggetti serializzati. Non è un database, non è un archivio e non va trattato come fallback permanente. Se ti serve persistenza o struttura dati più ricca, il discorso cambia e spesso Redis è più adatto. Una regola pratica: se il dato si può rigenerare rapidamente e il costo di rigenerazione è più alto del costo di una miss in cache, Memcached ha senso. Se invece il dato deve sopravvivere ai reboot o richiede logiche atomiche complesse, stai guardando lo strumento sbagliato.

Installazione su Ubuntu 24.04 e 22.04 LTS

I pacchetti disponibili nei repository ufficiali coprono entrambe le release LTS. La procedura base è identica; cambia poco o nulla dal punto di vista operativo. Prima di toccare il sistema, conviene aggiornare l’indice dei pacchetti e verificare la versione disponibile. Step 1: aggiorna i repository e installa il pacchetto. 
sudo apt update
sudo apt install memcached libmemcached-tools
Il pacchetto `memcached` installa il demone. `libmemcached-tools` aggiunge strumenti utili per test e diagnostica, in particolare `memcached-tool` e client di supporto che tornano comodi quando devi controllare lo stato del server. Step 2: verifica che il servizio sia installato e attivo. 
systemctl status memcached --no-pager
L’output atteso è un servizio `active (running)`. Se vedi `failed`, il problema è quasi sempre nella configurazione o nel binding di rete. In quel caso il primo log da leggere è il journal del servizio. 
journalctl -u memcached -b --no-pager

Configurazione di base: porta, interfaccia, memoria

Su Ubuntu il file principale è `

/etc/memcached.conf

`. La configurazione standard tende a essere prudente: ascolto su localhost, memoria contenuta, utente dedicato, opzioni conservative. È una base buona per un nodo locale o per un server app che parla con Memcached sulla stessa macchina. Se il tuo caso è diverso, ad esempio un nodo cache separato, devi esplicitare indirizzo di ascolto e regole di accesso. Non farlo “a sentimento”: un servizio su rete aperta senza filtro è una pessima idea. Step 3: apri la configurazione e controlla i parametri chiave. 

sudo nano /etc/memcached.conf
I campi che contano davvero, nella pratica, sono questi: 
-m 64
-l 127.0.0.1
-p 11211
-u memcache
`-m` definisce la RAM assegnata alla cache in MB. `-l` definisce l’interfaccia di ascolto. `-p` è la porta. `-u` indica l’utente con cui gira il processo. Su una macchina applicativa singola, `127.0.0.1` è spesso la scelta corretta. Su una macchina dedicata, puoi ascoltare su un IP privato specifico invece che su tutte le interfacce. Dopo ogni modifica, ricarica il servizio e verifica che resti in ascolto. 
sudo systemctl restart memcached
sudo systemctl status memcached --no-pager
ss -ltnp | grep 11211
Il comando `ss` deve mostrare il socket in ascolto sulla porta 11211. Se hai impostato `127.0.0.1`, non devi vedere un bind su `0.0.0.0`. Se invece il servizio deve essere raggiungibile da altri host, assicurati che il bind sia sull’IP corretto e che il firewall consenta il traffico solo dai sistemi autorizzati.

Verifica funzionale con un client reale

A servizio avviato, il test più semplice è scrivere e leggere una chiave. Non basta vedere il processo attivo: serve una prova di funzionamento del protocollo. Step 4: usa un client per impostare una chiave e rileggerla. 
printf 'set prova 0 60 5\r\nhello\r\nget prova\r\nquit\r\n' | nc 127.0.0.1 11211
L’output atteso include `STORED` e poi `VALUE prova 0 5` seguito da `hello`. Se ottieni `connection refused`, il demone non ascolta sulla porta prevista. Se ottieni timeout, controlla firewall, bind e stato del processo. In alternativa puoi usare `memcached-tool` per una verifica più orientata allo stato del server. 
memcached-tool 127.0.0.1:11211 stats
Tra le statistiche utili ci sono `curr_items`, `get_hits`, `get_misses`, `evictions` e `bytes`. Se `evictions` cresce rapidamente, la cache è troppo piccola o il pattern di accesso è sbilanciato. Se `get_misses` domina, la cache non sta intercettando davvero il carico atteso.

Integrare Memcached con PHP su Ubuntu

Su un server LAMP o LEMP, l’uso più comune è lato PHP. Qui il punto non è solo installare il modulo, ma allineare estensione, socket o host e strategia di sessione o caching applicativo. Step 5: installa il supporto PHP per Memcached. Su Ubuntu il nome del pacchetto dipende dalla versione di PHP installata, ma in molti casi basta: 
sudo apt install php-memcached
Dopo l’installazione, verifica che l’estensione sia caricata. 
php -m | grep -i memcached
Se usi PHP-FPM, riavvia il pool o il servizio relativo. Su sistemi con più versioni di PHP, controlla di operare sulla versione effettivamente servita dal web server. È un errore classico installare l’estensione sulla CLI e poi scoprire che FPM usa un’altra versione. 
sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager
Per una verifica applicativa minima, crea uno script PHP di test che esegue un set/get. Non lasciarlo in produzione oltre il tempo necessario. 
<?php
$mem = new Memcached();
$mem->addServer('127.0.0.1', 11211);
$mem->set('chiave_test', 'ok', 30);
var_dump($mem->get('chiave_test'));
L’output atteso è `string(2) "ok"`. Se ricevi `bool(false)`, controlla estensione, connettività e log PHP-FPM o del web server.

Impostare Memcached come cache di sessione PHP

Una configurazione frequente è l’uso di Memcached per le sessioni. Funziona bene quando hai più nodi web e vuoi evitare sessioni locali su disco. Però va fatto con attenzione: se il backend cache non è affidabile, le sessioni diventano fragili. Il file da toccare dipende dalla distribuzione e dalla versione PHP, ma il concetto è sempre lo stesso: `session.save_handler` e `session.save_path`. In PHP-FPM puoi intervenire in un file `php.ini` o in uno snippet del pool. Esempio di configurazione, da adattare alla tua versione: 
session.save_handler = memcached
session.save_path = "127.0.0.1:11211"
Se Memcached è remoto, inserisci più server separati da spazio oppure la sintassi supportata dalla tua estensione. Dopo la modifica, riavvia PHP-FPM e verifica i log della sessione se qualcosa non torna. Un dettaglio utile: in ambienti con molti utenti, la strategia di sessione va testata sotto carico. Non basta il login riuscito su un browser. Devi osservare errori sporadici, rigenerazioni di sessione e eventuali collisioni di chiavi.

Tuning essenziale: memoria, eviction e concorrenza

Il tuning di Memcached non richiede acrobazie. Di solito i parametri che fanno davvero differenza sono pochi: memoria allocata, numero di worker, connessioni massime e posizione del servizio rispetto al carico applicativo. Il resto è secondario finché non hai dati che dimostrano il contrario. Se il server è dedicato alla cache, puoi aumentare `-m` con una logica coerente rispetto alla RAM totale e al resto dei servizi. Se ospita anche altro, lascia margine al sistema operativo e agli altri demoni. Una cache che provoca swap non è una cache ben dimensionata. Per osservare se la dimensione è corretta, controlla:
  • evictions: se aumenta troppo in fretta, la cache è insufficiente o gli oggetti hanno vita troppo lunga.
  • curr_items rispetto a bytes: ti dice quanto spazio reale stai usando.
  • get_hits e get_misses: misurano se la cache sta davvero assorbendo il traffico.
Per un controllo immediato della memoria allocata puoi usare: 
grep -E '^-m|^-l|^-p|^-u' /etc/memcached.conf
Se il file non riflette il comportamento osservato, verifica anche l’unità systemd o eventuali override. Su Ubuntu vale la pena controllare se esistono drop-in locali: 
systemctl cat memcached
Questo evita di inseguire un parametro nel posto sbagliato quando il servizio parte con opzioni diverse da quelle che pensavi di aver impostato.

Esposizione in rete e firewall

Se Memcached deve accettare connessioni da altri host, non limitarti a cambiare `-l`. Devi anche filtrare in ingresso. La porta 11211 non va mai lasciata aperta indiscriminatamente su Internet. Con UFW, una regola minimale per consentire solo da una subnet privata può essere simile a questa: 
sudo ufw allow from 10.0.0.0/24 to any port 11211 proto tcp
Poi verifica la policy effettiva: 
sudo ufw status numbered
Se usi `nftables` o `iptables`, la logica resta identica: consenti solo i client necessari e lascia negato il resto. Su un nodo cache interno, il firewall è parte della configurazione, non un’aggiunta opzionale.

Diagnostica rapida quando qualcosa non torna

Quando Memcached non risponde, il primo ordine di controllo è sempre: processo, bind, log, rete. Questa sequenza evita di perdere tempo su ipotesi fantasiose.
  1. Controlla che il servizio sia vivo: systemctl is-active memcached.
  2. Controlla il bind: ss -ltnp | grep 11211.
  3. Controlla i log di avvio: journalctl -u memcached -b --no-pager.
  4. Testa la porta localmente: nc 127.0.0.1 11211 o memcached-tool 127.0.0.1:11211 stats.
  5. Se è remoto, verifica firewall e routing tra client e server.
Se il demone parte e poi si ferma, i motivi tipici sono: configurazione errata, porta già occupata, permessi non coerenti o opzioni non valide. Se invece resta up ma non accetta connessioni, il problema è quasi sempre nel bind o nel firewall.

Disinstallazione o rollback pulito

Se stai facendo una prova e vuoi tornare indietro, il rollback è semplice: fermi il servizio, rimuovi il pacchetto e ripristini il file di configurazione salvato. Non cancellare nulla alla cieca se il nodo serve altri servizi. Prima del rollback, salva la configurazione corrente. 
sudo cp /etc/memcached.conf /etc/memcached.conf.bak
Poi arresta il servizio e, solo se davvero serve, rimuovi il pacchetto: 
sudo systemctl stop memcached
sudo apt remove memcached libmemcached-tools
Se Memcached era usato per sessioni o cache applicativa, considera l’impatto sugli utenti: le sessioni potrebbero decadere e la cache si svuoterà. In quel caso il rollback applicativo deve essere coordinato con il resto dello stack, non eseguito isolatamente.

Scelta pratica tra installazione locale e nodo dedicato

Su una singola macchina web, installare Memcached in locale è spesso la strada più semplice e con meno variabili. Riduci latenza, riduci dipendenze di rete e semplifichi il troubleshooting. Su un cluster, invece, un nodo dedicato ha senso quando vuoi centralizzare la cache o separare i ruoli. La decisione non va presa per moda. Se il carico è modesto, il nodo locale è più che sufficiente. Se hai più web server, più pool PHP o più applicazioni che condividono oggetti, un nodo cache separato può essere più ordinato, purché sia protetto e monitorato. In entrambi i casi, il criterio resta lo stesso: installa, limita l’esposizione, testa un set/get reale, osserva gli hit ratio e solo dopo collega l’applicazione. È il modo corretto per evitare una cache presente ma inutile. Se ti manca un dettaglio specifico della tua versione di PHP, del web server o del layout della rete, il punto da chiudere è sempre lo stesso: controlla la configurazione effettiva in uso, non quella che pensi di aver modificato. Su Linux i file giusti da leggere sono quasi sempre `

/etc/memcached.conf

`, l’unità systemd e la configurazione PHP-FPM del pool attivo.