1 14/04/2026 9 min

Memcached su AlmaLinux 8: quando serve davvero

Memcached è un cache in-memory semplice da mettere in piedi e utile quando vuoi alleggerire database o applicazione da letture ripetute, sessioni o oggetti temporanei. Su AlmaLinux 8 l’installazione è lineare, ma il punto non è solo far partire il demone: bisogna decidere quale layer deve usarlo, con quali limiti di memoria e con quale esposizione di rete. Se lo apri senza criterio, stai solo aggiungendo un servizio in più da mantenere.

In pratica, Memcached ha senso quando la tua metrica obiettivo è ridurre latenza media e carico sul database, non quando vuoi persistenza o replica. Se ti serve durabilità, non è lo strumento giusto. Se ti serve un cache server leggero, prevedibile e veloce, invece sì.

Scelta architetturale prima dell’installazione

Su un server AlmaLinux 8 tipico, Memcached viene usato in uno di questi modi:

  • cache applicativa per dati ripetuti;
  • storage sessioni PHP;
  • buffer temporaneo per query costose o risultati aggregati.

La decisione che va presa subito è se il servizio deve ascoltare solo in locale oppure anche sulla rete interna. Nel 90% dei casi server singolo o applicazione locale: solo localhost. Se invece hai più nodi applicativi, allora puoi valutare l’ascolto su IP privato, ma con firewall stretto e senza esporlo a Internet.

Regola pratica: se non sai già chi deve parlare con Memcached, lascialo su 127.0.0.1. È la scelta più sicura e quasi sempre sufficiente.

Installazione dei pacchetti su AlmaLinux 8

AlmaLinux 8 usa il gestore pacchetti DNF. Il pacchetto principale è memcached; per PHP spesso servono anche i moduli client. Prima di installare, conviene verificare i repository attivi e la disponibilità del pacchetto.

dnf repolist
sudo dnf info memcached

Se il pacchetto è disponibile, installa il demone e gli strumenti base:

sudo dnf install -y memcached

Se il server ospita PHP e vuoi usare Memcached come backend per sessioni o cache applicativa, potresti avere bisogno del client PHP. Il nome del pacchetto dipende dal repo e dalla versione PHP installata, quindi verifica prima la disponibilità:

sudo dnf search memcached | grep -i php
sudo dnf search pecl-memcached

Non dare per scontato che il modulo sia già presente. In ambiente LAMP/LEMP capita spesso che il demone sia installato correttamente ma l’applicazione non riesca a usarlo perché il client lato PHP manca o non è compatibile con la versione di PHP in uso.

Configurazione minima del servizio

Il file principale su AlmaLinux 8 è in genere /etc/sysconfig/memcached. Qui definisci porta, indirizzo di ascolto, dimensione cache e numero di connessioni. Prima di cambiare qualcosa, fai un backup del file così hai un rollback immediato.

sudo cp -a /etc/sysconfig/memcached /etc/sysconfig/memcached.bak.$(date +%F-%H%M)

Un profilo minimale e prudente per uso locale può essere questo:

PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS="-l 127.0.0.1 -U 0"

Qui la scelta importante è -l 127.0.0.1, che limita l’ascolto al loopback, e -U 0, che disabilita la porta UDP. UDP per Memcached non serve nella maggior parte degli scenari moderni e lascia aperta una superficie d’attacco inutile.

Se devi ascoltare su rete privata, sostituisci 127.0.0.1 con l’IP del server o con l’interfaccia corretta, ma lascia il firewall chiuso verso l’esterno e apri solo i peer autorizzati. Non esporre mai Memcached direttamente su Internet.

Avvio, abilitazione e controllo con systemd

Dopo la configurazione, abilita e avvia il servizio. Systemd ti dà subito il primo controllo di stato e gli errori di bootstrap.

sudo systemctl enable --now memcached
sudo systemctl status memcached --no-pager

Il risultato atteso è active (running). Se il servizio fallisce, il punto da verificare subito è il journal:

sudo journalctl -u memcached -b --no-pager

Errori tipici: porta già occupata, indirizzo di bind inesistente, permessi sul file di configurazione, oppure parametri non validi nel file sotto /etc/sysconfig/memcached. Non andare a tentativi: il journal ti dice quasi sempre dove si è rotto l’avvio.

Verifica della porta e test funzionale

Una volta avviato, controlla che il processo ascolti davvero dove ti aspetti. Il test più rapido è con ss:

sudo ss -lntp | grep 11211

Se hai scelto localhost, dovresti vedere il bind su 127.0.0.1:11211. Se non compare nulla, il demone non è partito o sta ascoltando su un altro indirizzo.

Per un test reale usa il protocollo testuale via netcat. È il controllo più semplice per capire se il servizio risponde e mantiene valori in memoria.

printf 'set prova 0 60 5\r\nhello\r\nget prova\r\n' | nc 127.0.0.1 11211

L’output atteso include STORED e poi il valore hello. Se ricevi ERROR o nessuna risposta, il problema può essere di bind, firewall locale, servizio fermo o una configurazione errata della porta.

Firewall: aprire solo ciò che serve

Se Memcached è usato solo localmente, il firewall non va aperto. Se invece deve essere raggiungibile da altri host della rete interna, apri la porta 11211 solo per le sorgenti autorizzate. Con firewalld, il controllo va fatto con criterio, non con aperture generiche.

sudo firewall-cmd --state
sudo firewall-cmd --list-all

Per un’esposizione interna limitata, preferisci una richesta esplicita su zona dedicata o regola ricca, non una apertura ampia sulla zona pubblica. Il principio è semplice: Memcached non deve diventare un servizio di rete “libero”.

Se devi cambiare la policy firewall, conserva sempre la possibilità di rollback. Prima annota la regola esistente, poi applica la modifica minima e verifica con un client remoto autorizzato.

Integrazione con PHP: uso come cache o session handler

In ambiente PHP, Memcached viene spesso usato in due modi distinti: come cache applicativa tramite librerie/framework, oppure come backend delle sessioni. Le due cose non sono equivalenti. Se configuri le sessioni in Memcached, devi essere sicuro di avere persistenza sufficiente lato applicativo e di non perdere sessioni durante restart o saturazione memoria.

Per verificare che il modulo sia disponibile, controlla i moduli PHP caricati:

php -m | grep -i memcached
php -i | grep -i memcached

Se il modulo non compare, il problema non è il demone ma il layer client. In quel caso devi installare il pacchetto corretto per la tua versione PHP, poi riavviare PHP-FPM o Apache in base allo stack.

Per le sessioni PHP, la configurazione può stare in php.ini, in un pool PHP-FPM o nella configurazione dell’applicazione. Un esempio minimale, da adattare al tuo ambiente, è questo:

session.save_handler = memcached
session.save_path = "127.0.0.1:11211"

Se usi più server, puoi indicare più endpoint separati da virgola, ma resta valida la regola di rete privata e firewall stretto. Non usare host name non verificati se non hai un DNS interno affidabile e coerente.

Tuning pratico: memoria, connessioni e comportamento atteso

La dimensione della cache va scelta in base a carico reale, non a sensazione. Un valore come 64 MB può bastare per test o siti piccoli; per ambienti con molto oggetto cache o sessioni, serve più spazio. La regola corretta è osservare hit rate, eviction e consumo RAM prima di aumentare a caso.

Le metriche da guardare sono poche ma decisive:

  • hit rate: se è basso, la cache non sta aiutando davvero;
  • evictions: se crescono, la memoria è insufficiente;
  • curr_connections: se è vicino al limite, il client o il pool applicativo va rivisto;
  • bytes e limit_maxbytes: per capire se la memoria è satura.

Puoi leggerle con il comando standard:

echo stats | nc 127.0.0.1 11211

Se vuoi un controllo mirato, cerca voci come get_hits, get_misses, evictions e bytes. Un numero alto di miss non è sempre un problema di Memcached: spesso è l’applicazione che usa chiavi troppo granulari o un TTL incoerente.

Hardening minimo: meno superficie, meno sorprese

Memcached non richiede autenticazione nativa nel flusso classico, quindi la sicurezza dipende quasi tutta dall’isolamento di rete. Per questo motivo il default più sensato è bind su localhost e niente accesso esterno.

Le misure minime da considerare sono queste:

  • disabilitare UDP con -U 0;
  • limitare il bind all’IP necessario;
  • aprire la porta solo ai nodi applicativi;
  • eseguire il servizio con l’utente dedicato memcached;
  • tenere aggiornato il pacchetto con il normale ciclo di patching.

Se il server è esposto in ambienti condivisi o multi-tenant, valuta anche la segmentazione di rete. Un cache server non protetto può diventare un bersaglio per abuso di banda o per tentativi di accesso non autorizzato.

Problemi tipici e lettura rapida dei sintomi

Se il servizio non parte, i casi più frequenti sono banali ma ricorrenti. Il primo è un bind fallito perché l’IP specificato non esiste ancora al boot. Il secondo è una porta occupata da un altro processo. Il terzo è una configurazione sintatticamente sbagliata nel file sotto /etc/sysconfig/memcached.

Se parte ma l’applicazione non lo usa, il problema è quasi sempre lato client: modulo PHP assente, configurazione errata della sessione, endpoint sbagliato o firewall che blocca la comunicazione. In quel caso non toccare subito Memcached: verifica prima il client con un test locale o con il log dell’app.

Se invece il servizio risponde ma le performance non migliorano, la cache probabilmente è mal dimensionata o il pattern di accesso è inefficiente. Non basta aggiungere memoria: bisogna capire se le chiavi sono riutilizzate davvero, se il TTL è sensato e se il dataset cacheabile è abbastanza stabile.

Procedura completa consigliata, in ordine operativo

Se vuoi una sequenza sicura e ripetibile, questa è quella che uso di solito su AlmaLinux 8.

  1. Verifica che il pacchetto sia disponibile con dnf info memcached.
  2. Installa il demone con sudo dnf install -y memcached.
  3. Salva un backup di /etc/sysconfig/memcached.
  4. Imposta bind, memoria e connessioni nel file di configurazione.
  5. Abilita e avvia il servizio con systemctl enable --now memcached.
  6. Controlla stato e log con systemctl status e journalctl -u memcached -b.
  7. Verifica l’ascolto sulla porta con ss -lntp.
  8. Esegui un test set/get con nc.
  9. Se serve accesso remoto, apri il firewall solo per gli host autorizzati.
  10. Integra il client applicativo e valida il funzionamento dal layer PHP o dall’applicazione.

Questa sequenza riduce gli errori perché separa chiaramente installazione, servizio, rete e integrazione applicativa. Saltare uno di questi passaggi è il modo più rapido per finire con un demone attivo ma inutilizzato.

Quando non usare Memcached

Non usare Memcached se ti serve persistenza, coda, replica nativa o struttura dati più ricca. Non usarlo nemmeno come sostituto generico di un database o come archivio temporaneo per dati che non puoi perdere senza effetti collaterali.

Se il tuo problema è la gestione di configurazioni, chiavi o dati con necessità di persistenza e failover, devi valutare un altro strumento. Memcached vince per semplicità e velocità, non per completezza funzionale.

Verifica finale e rollback rapido

Dopo l’installazione, la condizione minima di successo è questa: systemctl status memcached mostra active (running), ss -lntp conferma il bind corretto e un test set/get via nc restituisce i valori attesi. Se hai modificato il firewall, il client autorizzato deve raggiungere la porta 11211 senza aprire esposizioni indesiderate.

Rollback semplice: ripristina /etc/sysconfig/memcached dal backup, poi riavvia il servizio.

sudo cp -a /etc/sysconfig/memcached.bak.YYYY-MM-DD-HHMM /etc/sysconfig/memcached
sudo systemctl restart memcached

Assunzione: Memcached viene installato su AlmaLinux 8 in un contesto server standard con systemd, e l’obiettivo è un uso locale o su rete privata con esposizione minima.