Redis är en databas i minnet som ger blixtsnabb prestanda. Detta gör det till ett övertygande alternativ till diskbaserade databaser när prestanda är ett problem. Du kanske redan använder ScaleGrid hosting för Redis™* för att driva dina prestandakänsliga applikationer. Hur säkerställer du att din Redis-distribution är sund och uppfyller dina krav? Du måste veta vilken övervakningsstatistik för Redis™ du ska titta på och ett verktyg för att övervaka dessa kritiska servermätningar för att säkerställa dess hälsa. Redis returnerar en stor lista med databasstatistik när du kör kommandot info på Redis-skalet. Du kan välja ett smart urval av relevanta mätvärden från dessa. Och dessa kan hjälpa dig att säkerställa ditt systems hälsa och att snabbt utföra rotorsaksanalyser av alla prestandarelaterade problem du kan stöta på.
Det här blogginlägget listar viktiga databasmått att övervaka. Vi kommer att titta på varje mätvärde ur ett databasprestandaperspektiv och diskutera de vanliga problemen och lösningarna förknippade med dem.
1. Prestandamått:Genomströmning
Genomströmning talar om hur många databasoperationer din server utför under en viss tidsperiod. Det beror på din applikations arbetsbelastning och dess affärslogik. Genom att titta på genomströmningshistoriken kan du härleda belastningsmönstret på en server, t.ex. toppbelastning, frekvensen av toppbelastning, tidsramarna för toppbelastning, medelbelastning etc.
Du kan samla in genomströmningsmetriska värden för alla kommandon som körs på Redis-servern genom att köra "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 grupperar sina olika kommandon i anslutning, server, kluster, generisk etc. ScaleGrid-övervakning för Redis™ samlar genomströmningen av olika kommandon i en av de ovan nämnda grupperna. Genomströmningen representeras som ett staplade områdesdiagram, där höjden på varje färgat område ger genomströmningen av en grupp kommandon.
En minskad genomströmning kan i allmänhet indikera att servern får färre frågor. Det kan också indikera ett potentiellt problem, till exempel en dyr fråga. På samma sätt betyder en ökad genomströmning intensiv arbetsbelastning på en server och en större latens.
2. Minnesanvändning
Minne är en kritisk resurs för Redis prestanda. Använt minne definierar det totala antalet byte som tilldelats av Redis med dess allokator (antingen standard libc, jemalloc eller en alternativ allokator som tcmalloc).
Du kan samla in alla mätdata för minnesutnyttjande för en Redis-instans genom att köra infominne ”.
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
Ibland, när Redis är konfigurerad utan max minnesgräns, kommer minnesanvändningen så småningom att nå systemminnet och servern kommer att börja skicka felmeddelanden "Minne är slut". Vid andra tillfällen är Redis konfigurerad med en maximal minnesgräns men noeviction politik. Detta skulle få servern att inte vräka ut några nycklar, vilket förhindrar skrivningar tills minnet frigörs. Lösningen på sådana problem skulle vara att konfigurera Redis med max minne och viss vräkningspolicy. I det här fallet börjar servern vräka ut nycklar med hjälp av eviction policy när minnesanvändningen når max.
RSS-minne (Resident Set Size) är antalet byte som operativsystemet har allokerat till Redis. Om förhållandet mellan "memory_rss" och "memory_used" är större än ~1,5, betyder det minnesfragmentering. Det fragmenterade minnet kan återställas genom att starta om servern.
3. Cache-träffförhållande
Cacheträffförhållandet representerar effektiviteten av cacheanvändningen. Matematiskt definieras det som (Totalt antal nyckelträffar)/ (Totalt antal nyckelträffar + Totalt antal nyckelmissar).
“infostatistik ” kommandot ger keyspace_hits &keyspace_misses metriska data för att ytterligare beräkna cacheträffförhållandet för en Redis-instans som körs.
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 .............
Om cacheminnets träffförhållande är lägre än ~0,8 kommer en betydande mängd av de begärda nycklarna att vräkas, förfalla eller existerar inte alls. Det är avgörande att titta på detta mått när du använder Redis som cache. Lägre cacheträffförhållande resulterar i större latens eftersom de flesta av förfrågningarna hämtar data från disken. Det indikerar att du måste öka storleken på Redis-cachen för att förbättra din applikations prestanda.
4. Aktiva anslutningar
Antalet anslutningar är en begränsad resurs som antingen upprätthålls av operativsystemet eller av Redis-konfigurationen. Att övervaka de aktiva anslutningarna hjälper dig att säkerställa att du har tillräckligt med anslutningar för att betjäna alla dina förfrågningar under högtrafik.
5. Vräktade/förfallna nycklar
Redis stöder olika vräkningspolicyer som används av servern när minnesanvändningen når maxgränsen. Ett beständigt positivt värde för detta mått är en indikation på att du behöver skala upp minnet.
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 stöder TTL (tid att leva) egendom för varje nyckel. Servern tar bort nyckeln om den associerade TTL har förflutit. Om applikationen inte definierar den här egenskapen, orsakar det att förfallna data samlas i minnet. Ett positivt mätvärde visar att din utgångna data rensas upp ordentligt.
6. Replikeringsmått
‘anslutna_slavar’ metric informerar om slavserverns tillgänglighet till en master. Otillgänglighet av slav kan leda till högre läslatens beroende på läsbelastningen på en 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 ’ mått visar hur mycket tid som går under kommunikationen mellan en slav och mastern. Ett högre värde för detta mått kan vara indikativt på problem med mastern/slaven eller vissa nätverksproblem. Det får dessutom slaven att servera inaktuella data.
Slutsats
Vi har nämnt några av de viktiga mätvärdena som ger god insyn i din databasservers hälsa och prestanda. Det kan finnas andra som är relevanta för just dina databasservrar och användningsfall. Vi rekommenderar att du går igenom och förstår alla mätvärden som rapporteras av "info"-kommandot.
Om du behöver hjälp med att hantera din AWS-hosting för Redis™ distributioner får du gärna kontakta oss via e-post på [email protected] eller på Twitter @scalegridio.