Quattro strategie essenziali per risolvere le perdite di memoria e i picchi di Redis

Redis è un archivio dati in memoria, quindi i problemi di memoria si manifestano rapidamente. Un piccolo errore nella gestione del TTL, una lista troppo grande o un salvataggio in background su un host senza RAM disponibile possono trasformarsi in latenza, errori di scrittura, espulsioni, swapping o un processo Redis terminato dal sistema operativo.

La prima abitudine utile è smettere di chiamare ogni aumento di memoria una perdita. Le vere perdite di Redis sono rare. La maggior parte degli incidenti è una di tre cose: crescita reale dei dati, frammentazione dell'allocatore o sovraccarico temporaneo copy-on-write durante la persistenza. Sembrano simili su un dashboard, ma le soluzioni sono completamente diverse.

Se used_memory continua a salire, la tua applicazione sta probabilmente memorizzando più dati del previsto. Se used_memory è stabile ma used_memory_rss salta, guarda alla frammentazione, al lavoro in background forkato o al sistema operativo. Se entrambi salgono durante un picco di traffico e poi non scendono mai, controlla TTL, politica di espulsione e chiavi grandi.

Strategia 1: Monitoraggio dettagliato delle metriche di utilizzo e frammentazione

Il primo passo per diagnosticare qualsiasi problema di memoria è stabilire una linea di base e capire come Redis sta riportando l'utilizzo della memoria. Il comando standard INFO memory fornisce metriche essenziali che differenziano tra la memoria utilizzata dai dati e quella utilizzata dal sistema operativo.

Metriche chiave per la diagnosi

Quando si verifica un picco, guarda immediatamente queste metriche da INFO memory:

1. used_memory: memoria allocata da Redis per dati e strutture interne.
2. used_memory_dataset: memoria utilizzata dal dataset effettivo, escluso un certo overhead.
3. used_memory_rss: memoria residente che il sistema operativo ha assegnato al processo Redis.
4. mem_fragmentation_ratio: un confronto approssimativo tra RSS e memoria allocata. Trattalo come un indizio, non come un verdetto.

# Controlla le statistiche di memoria di base
redis-cli INFO memory

# Esempio di output
# used_memory:1073741824 			# 1 GB di dati
# used_memory_rss:1509949440 		# ~1.5 GB in RAM
# mem_fragmentation_ratio:1.40625 	# RSS è circa il 40% più alto di used_memory

Interpretare il rapporto di frammentazione

Un rapporto vicino a 1.0 è solitamente sano. Un rapporto superiore a 1.5 vale la pena di essere indagato, specialmente se RSS è abbastanza alto da minacciare l'host. Un rapporto inferiore a 1.0 non prova automaticamente lo swapping; può accadere a causa di casi limite di misurazione, contabilità della memoria condivisa o dataset molto piccoli. Controlla le metriche di swap del sistema operativo direttamente con vmstat, top, sar o il tuo sistema di monitoraggio.

Se used_memory è piatto ma RSS aumenta durante BGSAVE o BGREWRITEAOF, il copy-on-write è una causa probabile. Il processo figlio sta scrivendo un file di persistenza mentre il genitore continua a gestire le scritture. Le pagine modificate dal genitore potrebbero dover essere copiate, il che aumenta temporaneamente la pressione sulla memoria.

Strategia 2: Implementare politiche di espulsione robuste

La crescita illimitata è la causa più frequente di quelle che vengono percepite come perdite di memoria in Redis. Se l'istanza viene utilizzata come cache, deve avere un limite massimo definito per l'utilizzo della memoria, imposto dalla direttiva maxmemory.

Se maxmemory non è impostato, Redis può continuare ad allocare memoria finché l'host non è sotto pressione. Su un box Redis dedicato, ciò potrebbe finire con il kernel che uccide Redis. In un contenitore, il runtime del contenitore potrebbe ucciderlo prima.

Impostazione di maxmemory e selezione della politica

Specifica il limite massimo di memoria nel tuo redis.conf o usando CONFIG SET:

# Imposta la memoria massima a 4 GB. Lascia spazio per l'overhead di Redis, i processi figli forkati,
# la cache di pagina del sistema operativo e altri processi.
CONFIG SET maxmemory 4gb

# Configura la politica di espulsione
# allkeys-lru: Espelle le chiavi usate meno di recente dall'*intero* dataset
CONFIG SET maxmemory-policy allkeys-lru

Nome Politica	Descrizione	Caso d'Uso
noeviction	Predefinita. Restituisce errori sui comandi di scrittura quando il limite di memoria viene raggiunto.	Database dove nessuna perdita di dati è accettabile.
allkeys-lru	Espelle le chiavi usate meno di recente indipendentemente dalla scadenza.	Caching generico.
volatile-lru	Espelle le chiavi usate meno di recente solo tra quelle con una scadenza impostata.	Casi d'uso misti (dati persistenti + dati cache).
allkeys-random	Espelle chiavi casuali quando il limite viene raggiunto.	Semplici archivi di sessione o dove il pattern di accesso è imprevedibile.

Per una cache pura, allkeys-lru o allkeys-lfu è spesso un punto di partenza ragionevole. Per un'istanza Redis mista dove solo alcune chiavi sono eliminabili, volatile-lru o un'altra politica volatile-* potrebbe essere più sicura, ma solo se ogni chiave della cache ha una scadenza. La configurazione pericolosa è una cache con noeviction, nessuna disciplina TTL e nessun avviso prima che la memoria sia piena.

Strategia 3: Diagnosticare e potare i picchi di chiavi grandi

A volte il problema non è il numero di chiavi. È una chiave che è cresciuta senza limiti: una lista di feed utente che non viene mai tagliata, un insieme ordinato di ogni evento mai visto, o un hash usato come discarica per campi di sessione.

Usare redis-cli --bigkeys

L'utilità redis-cli --bigkeys scansiona il keyspace e riporta le chiavi grandi per tipo e conteggio di elementi. Non misura la dimensione esatta in byte e può aggiungere carico su un'istanza di produzione occupata, quindi eseguila con attenzione o contro una replica quando possibile.

# Esegui l'analisi delle chiavi grandi
redis-cli --bigkeys

# Output di esempio (identificazione di una Lista massiccia)
---------- Summary ----------
...
[5] Biggest list found 'user:1001:feed' with 859387 items

Usare MEMORY USAGE (Redis 4.0+)

Per determinare la dimensione precisa in byte di una chiave sospetta, usa il comando MEMORY USAGE. Questo è vitale per una diagnostica approfondita.

# Controlla l'utilizzo della memoria di una chiave specifica (in byte)
redis-cli MEMORY USAGE user:1001:feed

# Output: (es.) 84329014

Se identifichi chiavi grandi, rivedi il percorso di scrittura. Le soluzioni comuni sono tagliare le liste con LTRIM, far scadere le strutture temporanee, dividere hash o insiemi ordinati molto grandi in partizioni più piccole basate su chiavi e sostituire le letture "carica tutto" con accesso paginato come HSCAN, SSCAN o ZSCAN. La vera soluzione è solitamente nel comportamento dell'applicazione, non in una manopola di Redis.

Strategia 4: Gestire la frammentazione della memoria e il copy-on-write

L'alta frammentazione o i picchi improvvisi di RSS sono spesso scambiati per perdite di dati. Questi problemi riguardano l'allocazione della memoria, il ricambio di oggetti e la persistenza basata su fork.

Deframmentazione attiva

La deframmentazione attiva può aiutare Redis a recuperare spazio allocatore sprecato mentre il server continua a funzionare. È utile per carichi di lavoro che creano ed eliminano molti valori di dimensioni diverse. Utilizza anche CPU, quindi abilitala deliberatamente e osserva la latenza dopo la modifica.

Abilitala e configurala in redis.conf:

# Abilita la deframmentazione attiva
activedefrag yes

# Le soglie inferiore e superiore sono valori di configurazione in stile percentuale.
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100

Ridurre l'overhead del copy-on-write

Quando Redis fork un processo figlio per snapshot RDB o riscritture AOF, il sistema operativo utilizza l'ottimizzazione CoW. Se il processo genitore esegue scritture pesanti mentre il processo figlio è attivo, ogni pagina scritta deve essere duplicata, aumentando temporaneamente used_memory_rss. Questo picco può facilmente raddoppiare l'impronta di memoria di Redis.

Passaggi di mitigazione:

1. Pianifica la persistenza durante i periodi di basso traffico.
2. Lascia spazio di manovra sopra maxmemory per l'overhead dell'allocatore, i client, i buffer di replica e i processi figli forkati. Il margine giusto dipende dalla dimensione del dataset e dal tasso di scrittura; misuralo durante un BGSAVE o BGREWRITEAOF reale.
3. Evita di sovrapporre lavori pesanti in background come snapshot, riscritture AOF, backup e scansioni a livello di host.
4. Riduci il ricambio di scritture durante la persistenza se un job batch sta causando la crescita del copy-on-write.

Non ricorrere alle variabili d'ambiente dell'allocatore come prima risposta. Redis è comunemente compilato con jemalloc, e cambiare il comportamento dell'allocatore senza test può creare nuova latenza o comportamento di memoria. Se la frammentazione rimane grave dopo la deframmentazione attiva e le correzioni del carico di lavoro, testa le modifiche su un'istanza di staging o una replica prima di toccare la produzione.

Un flusso pratico per gli incidenti

Quando la memoria aumenta, raccogli i fatti prima di riavviare Redis. Un riavvio potrebbe nascondere le prove.

Esegui:

redis-cli INFO memory
redis-cli INFO persistence
redis-cli DBSIZE
redis-cli --bigkeys

Poi chiediti cosa è cambiato. Un deploy ha rimosso i TTL? Un consumatore di coda si è fermato, causando la crescita delle liste? Un nuovo job di reporting ha eseguito HGETALL su hash enormi? Una riscrittura AOF è iniziata durante il picco di traffico? Il limite di memoria del contenitore è cambiato?

Le migliori soluzioni per la memoria di Redis sono solitamente semplici: imposta un maxmemory realistico, scegli una politica di espulsione che corrisponda al carico di lavoro, dai a ogni chiave della cache un TTL, suddividi le strutture illimitate, impedisci alla persistenza di funzionare senza spazio di manovra e avvisa sulle tendenze della memoria prima che l'istanza raggiunga il limite.