Dimensionare correttamente maxmemory in Redis: riserve di memoria per i dati e il funzionamento

Cosa limita effettivamente maxmemory

maxmemory crea in Redis Open Source un Soglia di sfratto Non esiste un limite massimo rigido per il processo Redis o il suo container. Se il consumo rilevante ai fini della gestione della memoria raggiunge la soglia, Redis tenta di rimuovere alcune chiavi in base alla policy selezionata. Nel caso di una policy senza eviction, i comandi di scrittura che aumentano l'occupazione di memoria potrebbero invece fallire.

L'indicatore used_memory comprende la memoria occupata da Redis tramite il suo allocatore. Ciò include non solo i valori effettivi della tua applicazione, ma anche le strutture di gestione e altre aree di memoria di Redis. Chi deduce il limite basandosi esclusivamente sulla dimensione stimata dei dati utili, non tiene conto di questo overhead.

Una parte di used_memory è escluso dalla prova di espulsione: mem_not_counted_for_evict presenta in particolare buffer temporanei di replica e AOF. Questi buffer richiedono comunque memoria fisica. Il valore è già presente in used_memory è già incluso e pertanto non può essere sommato una seconda volta a questo indicatore senza essere verificato.

Ciò non significa che tutte le memorie dei client o di replica siano escluse dal calcolo dell'eviction. Inoltre, un singolo comando di grandi dimensioni può superare temporaneamente la soglia in modo significativo. Se imposti maxmemory Raggiunto il limite massimo del container, non rimane alcun margine affidabile per tali sbalzi e per il consumo aggiuntivo di risorse di processo.

Per la pianificazione occorre quindi rispondere separatamente a due domande: quanto spazio occupano il set di dati e l’overhead di Redis all’interno della gestione della memoria? E di quanta riserva ha bisogno, inoltre, l’intero ambiente di esecuzione? Solo considerando entrambe le prospettive insieme è possibile stabilire se un valore scelto sia plausibile al di sotto del limite effettivo di memoria.

RSS, Allocator e picchi di persistenza

Dopo un picco di carico, è possibile used_memory diminuire, mentre used_memory_rss rimane elevato: Redis ha sì liberato memoria tramite l’allocatore, ma questa non è stata necessariamente restituita immediatamente al sistema operativo. L’RSS descrive la memoria residente del processo dal punto di vista del sistema operativo e rappresenta quindi un diverso livello di osservazione.

Supponiamo che una cache cresca notevolmente durante un’operazione e che molte chiavi scadano in seguito. Il valore di memoria Redis più basso non implica automaticamente che il contenitore recuperi immediatamente una quantità corrispondente di spazio libero. Per il picco successivo, quindi, l’andamento del consumo effettivo è più importante dell’ipotesi che la memoria liberata scompaia immediatamente.

Anche mem_fragmentation_ratio non è una semplice percentuale di frammentazione. Il rapporto comprende anche altre componenti del processo; per l’analisi delle cause dovresti considerarlo insieme ai dati disponibili allocator_*-analizzare le metriche e lo storico del carico. Da un singolo rapporto non è possibile dedurre una riserva valida in generale.

Nel caso degli snapshot RDB e delle riscritture AOF, Redis genera un processo figlio. Tramite Copy-on-Write Potrebbero essere necessarie ulteriori pagine di memoria fisica se, durante il ciclo di persistenza, le pagine vengono modificate. Quanto più intenso e esteso è il carico di scrittura durante tale fase, tanto più è importante tenerne conto nella pianificazione della capacità.

L'amministrazione di Redis indica che, in casi estremi, le applicazioni con un'elevata attività di scrittura possono richiedere fino al doppio della memoria normalmente utilizzata. Si tratta di un avvertimento relativo a condizioni di carico sfavorevoli, non di un moltiplicatore generico. Inoltre, non limitarti a sommare i valori RSS del processo padre e di quello figlio: le pagine condivise verrebbero conteggiate più volte; è fondamentale monitorare l’host o il container appropriato.

I replici richiedono un proprio budget

Una replica conserva fondamentalmente una copia del set di dati e richiede, a tal fine, una propria RAM. Il primario e la replica sono quindi consumatori di memoria distinti: una riserva sul primario non libera spazio nel contenitore della replica. Pianifica ogni nodo in base al proprio limite e al consumo osservato.

Per impostazione predefinita, una replica ignora il proprio maxmemory per le proprie eliminazioni. Il Primary decide in merito alla rimozione delle chiavi e replica le cancellazioni. Ciononostante, i valori memorizzati possono differire, ad esempio a causa di buffer o strutture di dati diversi; lo stesso valore limite non garantisce quindi un carico di lavoro identico.

Nel caso di una Promozione l'ex replica assume il ruolo di primario. Verifica quindi non solo se, in qualità di copia di lettura, dispone di spazio sufficiente, ma anche se il suo limite di memoria e la sua configurazione consentono il funzionamento come primario. Ciò include in particolare il carico di scrittura, le connessioni di replica e il controllo di eviction allora in vigore.

A partire da Redis 7.0, il buffer di replica e il backlog di replica condividono la memoria. mem_clients_slaves può quindi indicare zero, sebbene la replica occupi spazio di memoria. Non interpretare il campo isolatamente e non sommare il backlog e il buffer di replica senza verificarli come aree completamente separate.

Oltre al consumo di memoria, anche l’andamento della trasmissione dei dati è rilevante per il funzionamento: un ritardo presenta caratteristiche diverse rispetto alla dimensione di un buffer. L’articolo dedicato a questo argomento spiega come classificare lo stato della replica e il ritardo. Offset di replica di Redis. Per quanto riguarda la riserva di memoria, tuttavia, sono comunque determinanti gli andamenti effettivi dei consumi di ciascuna istanza.

Registrare la memoria su tre livelli

Per il dimensionamento ti servono i valori provenienti da Redis e dall'ambiente in cui è in esecuzione l'istanza. I Livello di osservazione determina il significato di un dato: l'allocazione dell'Allocator, l'RSS del processo e l'utilizzo dei container sono grandezze diverse e non possono essere semplicemente sommate.

Con INFO memory tra le altre cose, leggi i valori memorizzati in Redis e la policy configurata. MEMORY STATS aggiunge dettagli sulla distribuzione della memoria. Entrambi i comandi sono di sola lettura; i campi disponibili dipendono dalla versione di Redis, dai permessi e dal piano di hosting.

Per verificare la correlazione temporale, controlla inoltre INFO persistence sull'attività di persistenza e sui valori Copy-on-Write disponibili. INFO replication Mostra il ruolo e lo stato di replica. Registra questi dati separatamente per il primario e la replica, in modo che un cambio di ruolo o una sincronizzazione rimangano riconoscibili durante l'analisi.

Un singolo valore non indica né il carico tipico né la riserva di picco necessaria. Raccogli quindi serie temporali relative al funzionamento normale, ai picchi di scrittura e alle operazioni di persistenza, e associale al consumo dell'host o del container osservato contemporaneamente. In questo modo potrai anche capire se un valore RSS elevato è correlato a un carico attuale o se persiste dopo un picco precedente.

Calcolare un budget di memoria sostenibile

Il punto di partenza è quella effettivamente in vigore Limite di memoria: Nel caso di un container, tale limite può essere inferiore alla RAM dell'host. Individua quali altri processi e componenti del sistema occupano lo stesso limite. Lo spazio a loro riservato non è disponibile per Redis per i dati o i picchi di carico.

Sottrai quindi le riserve per effetti RSS e Allocator aggiuntivi, i buffer non conteggiati per l’eviction, i picchi di persistenza e un margine di sicurezza. Il risultato è un valore provvisorio maxmemory-Bilancio, nessuna equazione interna a Redis. Le riserve devono corrispondere allo stesso limite e a condizioni di carico realistiche che si verificano contemporaneamente.

Esempio di calcolo illustrativo, non basato su misurazioni: da un limite di container di 8 GiB, vengono sottratti 0,5 GiB per altri consumatori, 0,5 GiB per effetti RSS aggiuntivi, 0,5 GiB per buffer esclusi dal calcolo dell’eviction, 1 GiB per un picco di persistenza e 0,5 GiB di margine di sicurezza. Come valore provvisorio rimangono 5 GiB per maxmemory.

Questi numeri non costituiscono una raccomandazione per un'istanza specifica. L'esempio presuppone che le riserve stimate descrivano contributi aggiuntivi e non sovrapposti al limite del contenitore. Soprattutto in un'esecuzione persistente, le pagine di memoria condivise e il copy-on-write possono complicare l'assegnazione; una semplice somma dei valori RSS del processo padre e del processo figlio non sarebbe adeguata a tale scopo.

Evita Conteggi duplicati: mem_not_counted_for_evict è già presente in used_memory. Se parti dal consumo totale osservato di RSS o del contenitore, non devi sommare nuovamente questa quota di buffer senza verificarla. Nel budget di eviction rimanente devono rientrare sia il set di dati che l'overhead di Redis già conteggiato; verifica poi l'approccio con un carico simile.

Confronto pratico delle politiche di sfratto

Il sito Politica di sfratto Determina il modo in cui Redis reagisce ai comandi di scrittura in caso di carenza di memoria. Non sostituisce la pianificazione della capacità: anche una policy adeguata richiede riserve al di fuori del calcolo dell’eviction. La decisione dipende soprattutto dalle chiavi che possono andare perse e dal modo in cui l’applicazione reagisce agli errori.

Nel caso di una cache pura è possibile allkeys-lru sono adatte quando è possibile ricostruire le voci rimosse attingendo da un'altra fonte. In Redis, l'LRU è un'approssimazione e non un ordinamento globale esatto. Le espulsioni frequenti possono comportare un aumento degli accessi al backend; pertanto, non contano solo i byte liberi, ma anche la percentuale di hit della cache e la capacità del backend.

Per i dati che non possono essere cancellati a piacimento, vale quanto segue: noeviction Un’altra decisione: l’applicazione deve essere in grado di gestire le operazioni di scrittura non andate a buon fine, anziché dare per scontato che il salvataggio sia avvenuto con successo. La policy non garantisce né la persistenza né la protezione da un errore OOM a livello di sistema operativo o di container.

Nel caso di stock misti, la Disciplina TTL fondamentale: Una volatile-*- La policy può selezionare solo chiavi con un tempo di scadenza. Se i candidati idonei sono troppo pochi, il TTL da solo non protegge dagli errori di scrittura. Verifica quindi se la cache e i dati importanti debbano davvero condividere la stessa istanza e la stessa strategia di gestione degli errori.

I dati relativi alla sessione evidenziano il conflitto di obiettivi: la rimozione di una voce può comportare per gli utenti la perdita dello stato della sessione, anche se l’applicazione continua tecnicamente a funzionare. Valuta le conseguenze e la possibilità di ripristino prima di scegliere la politica; ulteriori informazioni di base sono disponibili nell’articolo su Gestione delle sessioni con Redis e altri sistemi di archiviazione.

Controllare la riserva sotto carico

Un valore calcolato per maxmemory È innanzitutto un punto di partenza. Testalo in un ambiente isolato con una versione di Redis, una struttura dei dati e un limite di memoria simili. Il carico non dovrebbe riprodurre solo il funzionamento normale, ma anche i picchi di scrittura e le fasi in cui la persistenza e la replica sono attive contemporaneamente.

Presta attenzione al Consumo di container ovvero la metrica dell'host corrispondente e i valori di memoria di Redis. Tieni traccia di quando viene eseguito uno snapshot o una riscrittura AOF e se una replica viene sincronizzata. È fondamentale valutare quanto tempo rimane prima del limite effettivo durante gli eventi sovrapposti, non solo nel periodo di inattività successivo.

Con il comando di lettura INFO stats Tra le altre cose, registra i contatori delle evictions. Analizza la loro variazione per intervallo di tempo: un valore storico elevato, di per sé, non indica se in quel momento le chiavi vengano effettivamente sostituite. Metti in relazione l’aumento delle evictions con gli hit della cache e il carico del backend, a condizione che la tua applicazione fornisca questi dati.

Inoltre, registra le risposte OOM di Redis nell'applicazione e gli eventi relativi ai container legati alla memoria sulla piattaforma. Entrambi gli errori possono verificarsi con un carico simile, ma riguardano limiti diversi. Un sistema di allerta dovrebbe quindi tenere conto sia della riserva disponibile sia degli errori rilevati e della loro evoluzione nel tempo.

Ripetere la valutazione dopo aver apportato modifiche al set di dati, al carico di scrittura o alla persistenza e alla replica. Anche una promozione modifica il ruolo di una replica e, di conseguenza, il profilo di carico da verificare. I risultati ottenuti dall'ambiente isolato non sostituiscono il monitoraggio continuo delle istanze di produzione.

Individuare in modo mirato i problemi di memoria

Se il valore RSS del processo aumenta mentre used_memory Se si verifica un'interruzione, considerare innanzitutto l'andamento e il carico precedente. La memoria liberata non deve necessariamente essere restituita immediatamente al sistema operativo. La Metriche dell'allocatore da INFO memory aiutano a contestualizzare; il rapporto di frammentazione, di per sé, non dimostra né la presenza di una perdita di memoria né la sua causa.

Verifica quindi se l'aumento coincide temporalmente con una corsa di persistenza o con una sincronizzazione. A tal fine servono INFO persistence e INFO replication. Un singolo valore relativo a un buffer non considerato ai fini dell'eviction descrive solo lo stato attuale. Per calcolare una riserva, sono necessarie osservazioni relative a tutte le fasi rilevanti di carico e di guasto.

Nel caso di una Risposta OOM di Redis Verifica la policy configurata e assicurati che siano disponibili chiavi adeguate per l'eviction. In particolare, un comando di scrittura potrebbe fallire se Redis non è in grado di liberare spazio sufficiente in base alla policy in vigore. L'applicazione deve gestire questo errore, anziché dare per scontato che l'operazione di scrittura vada a buon fine.

In caso di interruzione del container dovuta alla memoria, invece, esamina gli eventi della piattaforma e il consumo rispetto al limite del container. Prendi in considerazione i picchi di persistenza e altri consumatori registrati nel container. Un OOM di Redis e un OOM del container non sono equivalenti: il limite massimo di memoria esterno può essere raggiunto anche senza una precedente risposta OOM da parte di Redis.

maxmemory-clients può inoltre limitare la memoria occupata dai client. Se la memoria utilizzata dal client in questione supera la soglia configurata, Redis può disconnettere i client con un consumo elevato; le applicazioni devono gestire le interruzioni di connessione. Questa impostazione non limita tutte le connessioni di replica e non sostituisce né il budget complessivo né il monitoraggio dei picchi di buffer.

Valutare l'hosting e l'architettura di Redis

Se la riserva osservata non è sufficiente con un carico rappresentativo, può essere opportuno aumentare la RAM qualora si intenda mantenere il set di dati e il carico su un’unica istanza. La capacità aggiuntiva deve tuttavia rientrare nel limite effettivo dell’host o del container. Un limite Redis più elevato, di per sé, non crea memoria fisica aggiuntiva.

In alternativa, è possibile utilizzare una Distribuzione del carico distribuire il fabbisogno di memoria e le operazioni di scrittura su più istanze. Ciò richiede un’adeguata ripartizione dei dati e una propria allocazione di risorse per ciascuna istanza coinvolta. Le repliche non sono da equiparare a una ripartizione del database: esse conservano infatti una copia e richiedono, a tal fine, una propria RAM.

Anche una modifica dell'architettura può essere d'aiuto, ad esempio la separazione di una cache tollerante alle perdite dai dati con requisiti più rigorosi. In questo modo è possibile scegliere in modo indipendente le politiche e le capacità. Tuttavia, né questa separazione, né una maggiore quantità di RAM, né la distribuzione del carico garantiscono che in futuro non si verifichino picchi di persistenza, replica e scrittura.

Confrontando Limiti dei fornitori Chiarisci se il valore indicato si riferisce a un limite di container, a un limite di istanza o a un limite del database definito in altro modo. Chiedi inoltre quali metriche e comandi di diagnostica sono accessibili, se le repliche sono incluse nello spazio di archiviazione prenotato e in che modo una promozione influisce sulle risorse disponibili.

Redis Open Source, Redis Software e Redis Cloud devono essere considerati separatamente. Nel caso di Redis Software, il limite del database documentato si applica sia agli shard primari che a quelli replica; ne consegue che non esiste una regola corrispondente per una singola istanza di Redis OSS. Per Redis Cloud e altre offerte di hosting, ti invitiamo a verificare le condizioni specifiche di ciascun prodotto, anziché applicare questa definizione senza averla verificata.