Redis è un database in memoria che fornisce prestazioni incredibilmente veloci. Ciò lo rende un'alternativa convincente ai database basati su disco quando le prestazioni sono un problema. Potresti già utilizzare l'hosting ScaleGrid per Redis™* per potenziare le tue applicazioni sensibili alle prestazioni. Come vi assicurate che la vostra distribuzione Redis sia sana e soddisfi i vostri requisiti? Dovrai sapere quali metriche di monitoraggio per Redis™ guardare e uno strumento per monitorare queste metriche critiche del server per garantirne l'integrità. Redis restituisce un ampio elenco di metriche del database quando esegui il comando info sulla shell Redis. Puoi scegliere una selezione intelligente di metriche pertinenti da queste. E questi possono aiutarti a garantire la salute del tuo sistema e a eseguire rapidamente l'analisi della causa principale di qualsiasi problema relativo alle prestazioni che potresti riscontrare.
Questo post del blog elenca le importanti metriche del database da monitorare. Esamineremo ciascuna metrica dal punto di vista delle prestazioni del database e discuteremo i problemi comuni e le soluzioni ad esse associate.
1. Metrica delle prestazioni:throughput
Il throughput ti dice quante operazioni di database sta eseguendo il tuo server in un particolare periodo di tempo. Dipende dal carico di lavoro dell'applicazione e dalla sua logica aziendale. Osservando la cronologia del throughput, puoi dedurre il modello di carico su un server, ad es. carico di picco, la frequenza del carico di picco, i periodi di carico di picco, carico medio ecc.
Puoi raccogliere i valori delle metriche di throughput per tutti i comandi eseguiti sul server Redis eseguendo “info commandstats ”.
127.0.0.1:6379> info commandstats # Commandstats cmdstat_get:calls=797,usec=4041,usec_per_call=5.07 cmdstat_append:calls=797,usec=4480,usec_per_call=5.62 cmdstat_expire:calls=797,usec=5471,usec_per_call=6.86 cmdstat_auth:calls=147,usec=288,usec_per_call=1.96 cmdstat_info:calls=46,usec=902,usec_per_call=19.61 cmdstat_config:calls=2,usec=130,usec_per_call=65.00 cmdstat_eval:calls=796,usec=36950,usec_per_call=46.42 cmdstat_command:calls=796,usec=8578,usec_per_call=10.78
Redis raggruppa i suoi vari comandi in connessione, server, cluster, generico ecc. Il monitoraggio ScaleGrid per Redis™ aggrega il throughput di vari comandi in uno dei gruppi sopra menzionati. Il throughput è rappresentato come un grafico ad area in pila, in cui l'altezza di ciascuna area colorata fornisce il throughput di un gruppo di comandi.
Un throughput ridotto potrebbe generalmente indicare che il server riceve meno query. Potrebbe anche indicare un potenziale problema, ad esempio una query costosa. Allo stesso modo, una maggiore velocità effettiva significa un carico di lavoro intenso su un server e una maggiore latenza.
2. Utilizzo della memoria
La memoria è una risorsa fondamentale per le prestazioni di Redis. Memoria utilizzata definisce il numero totale di byte allocati da Redis utilizzando il suo allocatore (o standard libc, jemaloc o un allocatore alternativo come tcmalloc).
Puoi raccogliere tutti i dati delle metriche di utilizzo della memoria per un'istanza Redis eseguendo "info memory ”.
127.0.0.1:6379> info memory # Memory used_memory:1007280 used_memory_human:983.67K used_memory_rss:2002944 used_memory_rss_human:1.91M used_memory_peak:1008128 used_memory_peak_human:984.50K
A volte, quando Redis è configurato senza limite massimo di memoria, l'utilizzo della memoria raggiungerà la memoria di sistema e il server inizierà a generare errori di "memoria insufficiente". Altre volte, Redis è configurato con un limite di memoria massimo ma nessuna sfratto politica. Ciò farebbe sì che il server non elimini alcuna chiave, impedendo così qualsiasi scrittura fino a quando la memoria non viene liberata. La soluzione a tali problemi sarebbe la configurazione di Redis con memoria massima e alcuni criteri di sfratto. In questo caso, il server inizia a rimuovere le chiavi utilizzando la politica di rimozione poiché l'utilizzo della memoria raggiunge il massimo.
Memory RSS (Resident Set Size) è il numero di byte che il sistema operativo ha allocato a Redis. Se il rapporto tra "memory_rss" e "memory_used" è maggiore di ~1,5, significa frammentazione della memoria. La memoria frammentata può essere recuperata riavviando il server.
3. Rapporto cache hit
Il rapporto di accesso alla cache rappresenta l'efficienza dell'utilizzo della cache. Matematicamente, è definito come (Totale tasti premuti)/ (Totale tasti premuti + Totale tasti mancati).
"statistiche informative Il comando ” fornisce keyspace_hit &keyspace_misses dati della metrica per calcolare ulteriormente il tasso di hit della cache per un'istanza Redis in esecuzione.
127.0.0.1:6379> info stats # Stats ............. sync_partial_err:0 expired_keys:10 evicted_keys:12 keyspace_hits:4 keyspace_misses:15 pubsub_channels:0 pubsub_patterns:0 .............
Se la percentuale di riscontro nella cache è inferiore a ~0,8, una quantità significativa delle chiavi richieste viene rimossa, scaduta o non esiste affatto. È fondamentale osservare questa metrica mentre si utilizza Redis come cache. Un rapporto di hit della cache inferiore comporta una latenza maggiore poiché la maggior parte delle richieste recupera i dati dal disco. Indica che devi aumentare le dimensioni della cache Redis per migliorare le prestazioni della tua applicazione.
4. Connessioni attive
Il numero di connessioni è una risorsa limitata che viene imposta dal sistema operativo o dalla configurazione Redis. Il monitoraggio delle connessioni attive ti aiuta ad assicurarti di avere connessioni sufficienti per soddisfare tutte le tue richieste nelle ore di punta.
5. Chiavi sfrattate/scadute
Redis supporta varie politiche di sfratto utilizzati dal server quando l'utilizzo della memoria raggiunge il limite massimo. Un valore positivo persistente di questa metrica indica che è necessario aumentare la memoria.
127.0.0.1:6379> info stats # Stats .............. sync_partial_err:0 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 ..............
Redis supporta TTL (time to live) proprietà per ogni chiave. Il server cancella la chiave se il TTL associato è scaduto. Se l'applicazione non definisce questa proprietà, i dati scaduti si accumulano in memoria. Un valore di metrica positivo indica che i dati scaduti vengono ripuliti correttamente.
6. Metriche di replica
'connected_slaves' metrica informa la raggiungibilità del server slave a un master. L'impossibilità di raggiungere lo slave potrebbe portare a una maggiore latenza di lettura a seconda del carico di lettura su un server.
127.0.0.1:6379> info replication # Replication role:master/slave connected_slaves:0/master_slave_io_seconds_ago:0 master_repl_offset:0 ..............
'master_slave_io_seconds_ago La metrica indica quanto tempo trascorre durante la comunicazione tra uno slave e il master. Un valore più alto per questa metrica può essere indicativo di problemi sul master/slave o di alcuni problemi di rete. Inoltre fa sì che lo slave serva dati non aggiornati.
Conclusione
Abbiamo menzionato alcune delle metriche importanti che forniranno una buona visibilità sullo stato e sulle prestazioni del tuo server di database. Potrebbero essercene altri rilevanti per i tuoi particolari server di database e casi d'uso. Ti consigliamo di esaminare e comprendere tutte le metriche riportate dal comando "info".
Se hai bisogno di aiuto per gestire il tuo hosting AWS per le implementazioni Redis™ , non esitare a contattarci via e-mail all'indirizzo [email protected] o su Twitter @scalegridio.
