Padroneggiare la Gestione della Memoria di Redis per Prestazioni Ottimali

Redis è veloce perché mantiene i dati in memoria, ma questo stesso design fa sì che gli errori di memoria si manifestino rapidamente. Una cache senza scadenze cresce fino a quando le scritture falliscono. Alcune chiavi enormi creano picchi di latenza quando vengono eliminate. Un salvataggio in background può richiedere più memoria del previsto a causa del copy-on-write. Un client lento può accumulare un buffer di output abbastanza grande da diventare parte del problema.

Una buona gestione della memoria di Redis non significa solo "comprare più RAM". Significa sapere cosa è memorizzato, per quanto tempo dovrebbe vivere, cosa succede al limite di memoria e quali operazioni possono bloccare il server quando le chiavi sono grandi.

Comprendere l'Utilizzo della Memoria di Redis

Redis utilizza la memoria di sistema per memorizzare tutti i suoi dati. Quando si utilizza SET per una coppia chiave-valore, Redis alloca memoria sia per la stringa della chiave che per il valore, insieme a un sovraccarico per le strutture dati interne. Comprendere le diverse componenti dell'utilizzo della memoria è il primo passo verso una gestione efficace:

Memoria dei Dati: Questa è la memoria consumata dai dati effettivi (chiavi, valori e strutture dati interne come i dizionari per mappare le chiavi ai valori). La dimensione dipende dal numero e dalla dimensione delle chiavi e dei valori, e dalle strutture dati scelte (stringhe, hash, liste, insiemi, insiemi ordinati).
Memoria di Sovraccarico: Redis aggiunge un sovraccarico per ogni chiave, inclusi puntatori, metadati, informazioni di scadenza e dati relativi all'espulsione. Le piccole strutture aggregate possono utilizzare codifiche compatte come listpack o intset a seconda della versione di Redis e del tipo di dato, mentre le strutture più grandi utilizzano rappresentazioni più generali.
Memoria del Buffer: Redis utilizza buffer di output del client, buffer del backlog di replica e buffer AOF. Client grandi o lenti, o una configurazione di replica intensa, possono consumare una quantità significativa di memoria del buffer.
Memoria di Fork: Quando Redis esegue operazioni in background come il salvataggio di snapshot RDB o la riscrittura di file AOF, esegue il fork di un processo figlio. Questo processo figlio inizialmente condivide la memoria con il processo padre tramite copy-on-write (CoW). Tuttavia, qualsiasi scrittura nel set di dati da parte del processo padre dopo il fork causerà la duplicazione delle pagine, aumentando l'impronta di memoria totale.

Monitoraggio della Memoria di Redis

Monitorare regolarmente la memoria di Redis è fondamentale per identificare potenziali problemi prima che si aggravino. Lo strumento principale per questo è il comando INFO memory, insieme a MEMORY USAGE.

Il Comando `INFO memory`

redis-cli INFO memory

Metriche chiave da INFO memory:

used_memory: Il numero totale di byte allocati da Redis utilizzando il suo allocatore (jemalloc, glibc, ecc.). Questa è la somma della memoria utilizzata dai dati, dalle strutture dati interne e dai buffer temporanei.
used_memory_human: used_memory in formato leggibile dall'uomo.
used_memory_rss: Resident Set Size (RSS), la quantità di memoria consumata dal processo Redis come riportato dal sistema operativo. Include le allocazioni proprie di Redis, più la memoria utilizzata dalla gestione della memoria del sistema operativo, dalle librerie condivise e potenzialmente dalla memoria frammentata non ancora rilasciata al sistema operativo.
mem_fragmentation_ratio: Questo è approssimativamente used_memory_rss / used_memory. Un valore superiore a 1.0 è normale. Un valore molto più alto può significare frammentazione, comportamento dell'allocatore o RSS che non è stato restituito al sistema operativo. Un valore inferiore a 1.0 è un segnale di avvertimento che vale la pena indagare perché potrebbe indicare memoria spostata su disco o effetti di temporizzazione della misurazione.
allocator_frag_bytes: Byte di frammentazione riportati dall'allocatore di memoria.
lazyfree_pending_objects: Numero di oggetti in attesa di essere liberati in modo asincrono.

Il Comando `MEMORY USAGE`

Per ispezionare l'utilizzo della memoria di singole chiavi:

redis-cli MEMORY USAGE mykey
redis-cli MEMORY USAGE myhashkey SAMPLES 0 # Stima per gli aggregati

Questo comando fornisce una stima dell'utilizzo della memoria per una data chiave, aiutando a individuare punti dati grandi o memorizzati in modo inefficiente.

Strategie Chiave per l'Ottimizzazione della Memoria

Ottimizzare la memoria in Redis comporta diversi passaggi proattivi, dalla scelta dei tipi di dati giusti alla gestione della frammentazione.

1. Ottimizzazione della Struttura Dati

Redis offre diverse strutture dati, ognuna con il proprio comportamento di memoria. La struttura giusta dipende da come l'applicazione legge e scrive i dati.

Stringhe: Le più semplici, ma fai attenzione alle stringhe grandi. Usare SET o GET su stringhe molto grandi (MB) può influire sulle prestazioni a causa del sovraccarico di trasferimento di rete e memoria.
Hash, Liste, Insiemi, Insiemi Ordinati (Aggregati): Redis può codificare in modo compatto piccoli tipi di dati aggregati. I nomi delle codifiche esatte e le soglie variano a seconda della versione di Redis, quindi controlla il tuo redis.conf e l'output OBJECT ENCODING invece di assumere che la vecchia terminologia ziplist si applichi ovunque.
- Suggerimento: Mantieni piccoli i singoli membri aggregati. Per gli hash, preferisci molti campi piccoli rispetto a pochi grandi.
- Configurazione: Le versioni di Redis differiscono qui. Le versioni più vecchie utilizzavano impostazioni *-ziplist-*; le versioni più recenti utilizzano comunemente impostazioni *-listpack-* per alcune strutture. Ottimizza queste con attenzione e testa con dati reali, perché le codifiche compatte risparmiano memoria ma possono costare CPU per alcuni modelli di accesso.

2. Migliori Pratiche per la Progettazione delle Chiavi

Mentre i valori consumano tipicamente più memoria, ottimizzare i nomi delle chiavi è anche importante:

Chiavi Brevi e Descrittive: Chiavi più corte risparmiano memoria, specialmente quando ne hai milioni. Tuttavia, non sacrificare la chiarezza per una brevità estrema. Punta a nomi di chiave descrittivi ma concisi.
- Male: user:1000:profile:details:email
- Bene: user:1000:email (se memorizzi solo l'email)
Prefissi: Usa prefissi coerenti (es., user:, product:) per scopi organizzativi. Questo ha un impatto minimo sulla memoria ma aiuta la gestione.

3. Minimizzare il Sovraccarico

Ogni chiave e valore ha un certo sovraccarico interno. Ridurre il numero di chiavi, specialmente quelle piccole, può essere efficace.

Hash Invece di Stringhe Multiple: Se hai molti campi correlati per un'entità, memorizzali in un singolo HASH invece di più chiavi STRING. Questo riduce il numero di chiavi di primo livello e il loro sovraccarico associato.
- Esempio: Invece di user:1:name, user:1:email, user:1:age, usa una chiave HASH user:1 con campi name, email, age.

4. Gestione della Frammentazione della Memoria

La frammentazione della memoria si verifica quando l'allocatore di memoria non riesce a trovare blocchi contigui di memoria della dimensione esatta necessaria, portando a spazi vuoti inutilizzati. Questo può causare used_memory_rss significativamente più alto di used_memory.

Cause: Inserimenti ed eliminazioni frequenti di chiavi di dimensioni variabili, specialmente dopo che l'allocatore di memoria è stato in esecuzione per molto tempo.
Rilevamento: Un mem_fragmentation_ratio significativamente superiore a 1.0 (es., 1.5-2.0) indica un'alta frammentazione.
Soluzioni:
- Deframmentazione Attiva Redis 4.0+: Redis può deframmentare attivamente la memoria senza riavviare. Abilitala con activedefrag yes in redis.conf e configura active-defrag-max-scan-time e active-defrag-cycle-min/max. Questo permette a Redis di spostare i dati, compattando la memoria.
- Riavvio di Redis: Il modo più semplice, sebbene dirompente, per deframmentare la memoria è riavviare il server Redis. Questo rilascia tutta la memoria al sistema operativo e l'allocatore ricomincia da capo. Per le istanze persistenti, assicurati che uno snapshot RDB o un file AOF sia salvato prima del riavvio.

# impostazioni redis.conf per la deframmentazione attiva
activedefrag yes
active-defrag-ignore-bytes 100mb  # Non deframmentare se la frammentazione è inferiore a 100MB
active-defrag-threshold-lower 10  # Inizia la deframmentazione se il rapporto di frammentazione è > 10%
active-defrag-threshold-upper 100 # Ferma la deframmentazione se il rapporto di frammentazione è > 100%
active-defrag-cycle-min 1         # Sforzo CPU minimo per la deframmentazione (1-100%)
active-defrag-cycle-max 20        # Sforzo CPU massimo per la deframmentazione (1-100%)

Politiche di Espulsione: Gestire `maxmemory`

Quando Redis viene utilizzato come cache, è fondamentale definire cosa succede quando la memoria raggiunge un limite predefinito. La direttiva maxmemory in redis.conf imposta questo limite, e maxmemory-policy detta la strategia di espulsione.

maxmemory 2gb # Imposta la memoria massima a 2 gigabyte
maxmemory-policy allkeys-lru # Espelle le chiavi usate meno di recente tra tutte le chiavi

Opzioni comuni di maxmemory-policy:

noeviction: (Predefinito) Le nuove scritture vengono bloccate quando viene raggiunto maxmemory. Le letture funzionano ancora. Questo è utile per il debug ma tipicamente non per le cache di produzione.
allkeys-lru: Espelle le chiavi usate meno di recente (LRU) da tutti i keyspace (chiavi con o senza scadenza).
volatile-lru: Espelle le chiavi LRU da solo quelle chiavi che hanno una scadenza impostata.
allkeys-lfu: Espelle le chiavi usate meno frequentemente (LFU) da tutti i keyspace.
volatile-lfu: Espelle le chiavi LFU da solo quelle chiavi che hanno una scadenza impostata.
allkeys-random: Espelle casualmente le chiavi da tutti i keyspace.
volatile-random: Espelle casualmente le chiavi da solo quelle chiavi che hanno una scadenza impostata.
volatile-ttl: Espelle le chiavi con il Time To Live (TTL) più breve da solo quelle chiavi che hanno una scadenza impostata.

Scegliere la Politica Giusta:

Per la memorizzazione nella cache generale, allkeys-lru o allkeys-lfu sono spesso buone scelte, a seconda che la recenza o la frequenza sia un indicatore migliore di utilità per i tuoi dati.
Se utilizzi principalmente Redis per la gestione delle sessioni o oggetti con scadenze esplicite, volatile-lru o volatile-ttl potrebbero essere più appropriati.

Avvertenza: Se maxmemory-policy è impostato su noeviction e maxmemory viene raggiunto, le operazioni di scrittura falliranno, portando a errori dell'applicazione.

Scegliere un Valore per `maxmemory`

Non impostare maxmemory uguale alla RAM totale del server. Lascia spazio per il sistema operativo, il sovraccarico del processo Redis, i buffer del client, il backlog di replica, il copy-on-write della persistenza, gli agenti di monitoraggio e l'accesso SSH di emergenza.

Per un'istanza Redis solo cache, un punto di partenza semplice è impostare maxmemory al di sotto della RAM fisica con un margine confortevole, quindi osservare le metriche reali durante il carico di punta e la persistenza in background. Per un'istanza con molta persistenza, lascia più margine perché gli snapshot RDB e le riscritture AOF possono aumentare temporaneamente la pressione sulla memoria.

La configurazione pericolosa è nessun limite su un host condiviso. Redis può quindi competere con il sistema operativo e altri servizi fino a quando l'OOM killer del kernel decide cosa muore. Un maxmemory chiaro più una politica di espulsione deliberata è più facile da gestire.

Anche le Chiavi Grandi Sono un Problema di Latenza

La gestione della memoria non riguarda solo i byte totali. Una chiave enorme può danneggiare operazioni che sembrano innocue.

Esempi:

redis-cli MEMORY USAGE huge:hash
redis-cli HLEN huge:hash
redis-cli LLEN queue:events

Eliminare una chiave molto grande con DEL può bloccare il ciclo degli eventi mentre Redis libera memoria. Preferisci UNLINK per le chiavi grandi quando la tua versione di Redis lo supporta:

redis-cli UNLINK huge:hash

UNLINK scollega la chiave e libera la memoria in modo asincrono. La chiave scompare rapidamente dal keyspace, mentre il costoso lavoro di liberazione avviene in background.

Per le grandi collezioni, progetta attorno a dimensioni limitate. Taglia stream e liste. Dividi gli hash grandi per tenant, bucket temporali o tipo di oggetto quando corrisponde al modello di accesso. Un hash con un milione di campi può risparmiare un po' di sovraccarico delle chiavi di primo livello, ma può diventare scomodo da migrare, far scadere, ispezionare o eliminare.

Persistenza e Sovraccarico di Memoria

Anche i meccanismi di persistenza di Redis (RDB e AOF) interagiscono con la memoria:

Snapshot RDB: Quando Redis salva un file RDB, esegue il fork di un processo figlio. Durante il processo di snapshot, qualsiasi scrittura nel set di dati Redis da parte del genitore causerà la duplicazione delle pagine di memoria a causa del copy-on-write (CoW). Questo può temporaneamente raddoppiare l'impronta di memoria, specialmente su istanze occupate con salvataggi RDB frequenti.
Riscrittura AOF: Allo stesso modo, quando il file AOF viene riscritto (es., BGREWRITEAOF), si verifica un fork, portando a una duplicazione temporanea della memoria. Anche il buffer AOF stesso consuma memoria.

Suggerimento: Se possibile, programma i salvataggi RDB e le riscritture AOF durante le ore non di punta, o assicurati che il tuo server abbia sufficiente RAM libera per gestire il sovraccarico CoW.

Liberazione Lazy

Redis 4.0 ha introdotto la liberazione lazy (eliminazione non bloccante) per impedire il blocco del server durante l'eliminazione di chiavi grandi o lo svuotamento dei database. Invece di recuperare la memoria in modo sincrono, Redis può mettere il compito di liberare la memoria in un thread in background.

lazyfree-lazy-eviction yes: Libera la memoria in modo asincrono durante l'espulsione.
lazyfree-lazy-expire yes: Libera la memoria in modo asincrono quando le chiavi scadono.
lazyfree-lazy-server-del yes: Libera la memoria in modo asincrono per le eliminazioni lato server nei percorsi supportati.
lazyfree-lazy-user-del yes: Fa sì che il DEL emesso dall'utente si comporti più come UNLINK sulle versioni di Redis che lo supportano.

Abilita la liberazione lazy con attenzione sulle istanze occupate per ridurre i picchi di latenza dal recupero sincrono della memoria. Quindi osserva lazyfree_pending_objects; se rimane alto, il lavoro di liberazione in background non sta tenendo il passo.

Buffer del Client e Pipelining

Il pipelining, sebbene sia principalmente una tecnica di ottimizzazione della rete, può influenzare indirettamente le prestazioni della memoria rendendo l'elaborazione dei comandi più efficiente. Inviando più comandi a Redis in un unico round trip, riduce la latenza di rete e il sovraccarico della CPU per comando sia sul lato client che su quello server. Questo permette a Redis di elaborare più operazioni al secondo senza accumulare grandi code di comandi, che altrimenti potrebbero portare a un maggiore utilizzo della memoria nei buffer del client o a un'elaborazione più lenta che stressa l'allocatore di memoria nel tempo.

Il pipelining può migliorare il throughput, ma pipeline illimitate possono aumentare i buffer di output del client. Un client che invia una pipeline enorme e legge le risposte lentamente può far sì che Redis mantenga una grande quantità di output in sospeso.

Osserva le metriche del buffer del client in INFO clients e configura limiti sensati per i client normali, replica e pub/sub:

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

Queste sono impostazioni predefinite di esempio, non raccomandazioni universali. Il punto chiave è evitare una crescita illimitata per i client che possono rimanere indietro.

Una Routine Utile di Revisione della Memoria

Quando un'istanza Redis inizia a utilizzare più memoria del previsto, procedi dal generale al particolare:

Controlla INFO memory per used_memory, RSS, frammentazione, statistiche dell'allocatore e liberazioni lazy in sospeso.
Controlla INFO keyspace per vedere se un database o una famiglia di chiavi sta crescendo.
Campiona le chiavi grandi con MEMORY USAGE, SCAN e comandi di lunghezza specifici del tipo.
Conferma che le chiavi simili a cache abbiano TTL.
Rivedi i deploy recenti per nuovi nomi di chiave, valori più lunghi o scadenze mancanti.
Controlla la tempistica della persistenza e la pressione della memoria correlata al fork.
Rivedi i buffer del client se la memoria aumenta durante i picchi di traffico.

Ad esempio, se la crescita della memoria segue il rilascio di una nuova funzionalità, cerca nuove chiavi senza scadenza:

redis-cli --scan --pattern 'feature-x:*' | head
redis-cli TTL feature-x:example

Un TTL di -1 significa che la chiave non ha scadenza. Questo può essere corretto per i dati durevoli. Di solito è sbagliato per i dati della cache.

I problemi di memoria di Redis sono più facili da risolvere prima che l'istanza sia piena. Imposta un maxmemory deliberato, scegli una politica di espulsione che corrisponda al ruolo dell'istanza, mantieni le chiavi della cache con TTL, evita chiavi sovradimensionate e lascia margine per fork e buffer. Quindi rivedi le metriche di memoria reali dopo ogni grande cambiamento nella forma dei dati. Redis rimarrà veloce quando il suo comportamento di memoria sarà noioso.