Redis er en database i hukommelsen, der giver lynende hurtig ydeevne. Dette gør det til et overbevisende alternativ til diskbaserede databaser, når ydeevne er et problem. Du bruger muligvis allerede ScaleGrid hosting for Redis™* til at drive dine præstationsfølsomme applikationer. Hvordan sikrer du, at din Redis-implementering er sund og opfylder dine krav? Du skal vide, hvilke overvågnings-metrics for Redis™, du skal se, og et værktøj til at overvåge disse kritiske server-metrics for at sikre dens sundhed. Redis returnerer en stor liste over databasemetrikker, når du kører info-kommandoen på Redis-shell. Du kan vælge et smart udvalg af relevante metrics fra disse. Og disse kan hjælpe dig med at sikre dit systems sundhed og til hurtigt at udføre rodårsagsanalyse af ethvert præstationsrelateret problem, du måtte støde på.
Dette blogindlæg viser de vigtige database-metrics, der skal overvåges. Vi vil se på hver metrik fra et databaseydeevneperspektiv og diskutere de almindelige problemer og løsninger, der er forbundet med dem.
1. Ydeevnemåling:Gennemløb
Throughput fortæller dig, hvor mange databaseoperationer din server udfører i en bestemt tidsperiode. Det afhænger af din applikationsarbejdsmængde og dens forretningslogik. Ved at se på gennemløbshistorikken kan du udlede mønsteret for belastning på en server, f.eks. spidsbelastning, hyppigheden af spidsbelastning, tidsrammerne for spidsbelastning, gennemsnitlig belastning osv.
Du kan indsamle gennemstrømningsmetriske værdier for alle de kommandoer, der køres på Redis-serveren ved at udføre "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 grupperer sine forskellige kommandoer i forbindelse, server, klynge, generisk osv. ScaleGrid-overvågning for Redis™ samler gennemløbet af forskellige kommandoer i en af de ovennævnte grupper. Gennemløbet er repræsenteret som en stablet områdegraf, hvor højden af hvert farvet område giver gennemløbet af en gruppe kommandoer.
En reduceret gennemstrømning kunne generelt indikere, at serveren får færre forespørgsler. Det kunne også indikere et potentielt problem, f.eks. en dyr forespørgsel. På samme måde betyder en øget gennemstrømning intensiv arbejdsbyrde på en server og en større latenstid.
2. Hukommelsesudnyttelse
Hukommelse er en kritisk ressource for Redis ydeevne. Brugt hukommelse definerer det samlede antal bytes allokeret af Redis ved hjælp af dens allokator (enten standard libc, jemalloc eller en alternativ allokator såsom tcmalloc).
Du kan indsamle alle data for hukommelsesudnyttelse for en Redis-instans ved at køre "infohukommelse ”.
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
Nogle gange, når Redis er konfigureret uden maks. hukommelsesbegrænsning, vil hukommelsesforbruget til sidst nå systemhukommelsen, og serveren vil begynde at smide "Tom for hukommelse"-fejl. På andre tidspunkter er Redis konfigureret med en maksimal hukommelsesgrænse, men noeviction politik. Dette ville medføre, at serveren ikke smide nogen nøgler ud, og dermed forhindre enhver skrivning, indtil hukommelsen er frigivet. Løsningen på sådanne problemer ville være at konfigurere Redis med maksimal hukommelse og en vis udsættelsespolitik. I dette tilfælde begynder serveren at smide nøgler ud ved hjælp af eviction policy, da hukommelsesforbruget når maks.
Hukommelse RSS (Resident Set Size) er antallet af bytes, som operativsystemet har allokeret til Redis. Hvis forholdet mellem 'memory_rss' og 'memory_used' er større end ~1,5, betyder det hukommelsesfragmentering. Den fragmenterede hukommelse kan gendannes ved at genstarte serveren.
3. Cache-hitforhold
Cachehitforholdet repræsenterer effektiviteten af cachebrug. Matematisk defineres det som (Samlet antal nøglehits)/ (Total antal nøglehits + Samlet nøglemisser).
“infostatistik ” kommandoen giver keyspace_hits &keyspace_misses metriske data for yderligere at beregne cache-hitforhold for en kørende Redis-instans.
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 .............
Hvis cache-hitforholdet er lavere end ~0,8, bliver en betydelig mængde af de anmodede nøgler smidt ud, udløbet eller eksisterer slet ikke. Det er afgørende at se denne metrik, mens du bruger Redis som en cache. Lavere cache-hitforhold resulterer i større latenstid, da de fleste anmodninger henter data fra disken. Det indikerer, at du skal øge størrelsen på Redis-cachen for at forbedre din applikations ydeevne.
4. Aktive forbindelser
Antallet af forbindelser er en begrænset ressource, som enten håndhæves af operativsystemet eller af Redis-konfigurationen. Overvågning af de aktive forbindelser hjælper dig med at sikre, at du har tilstrækkelige forbindelser til at betjene alle dine anmodninger i spidsbelastningsperioder.
5. Udsatte/udløbne nøgler
Redis understøtter forskellige udsættelsespolitikker som bruges af serveren, når hukommelsesforbruget når maks. grænsen. En vedvarende positiv værdi af denne metrik er en indikation af, at du skal skalere hukommelsen op.
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 understøtter TTL (tid til at leve) ejendom for hver nøgle. Serveren sletter nøglen, hvis den tilknyttede TTL er udløbet. Hvis applikationen ikke definerer denne egenskab, får det udløbne data til at hobe sig op i hukommelsen. En positiv metrisk værdi viser, at dine udløbne data bliver ryddet ordentligt op.
6. Replikeringsmålinger
'connected_slaves' metric informerer slaveserverens tilgængelighed til en master. Utilgængeligheden af slaver kan føre til højere læseforsinkelse afhængigt af læsebelastningen 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 ' Metrisk fortæller, hvor meget tid der går under kommunikationen mellem en slave og masteren. En højere værdi for denne metrik kan være tegn på problemer på master/slave eller nogle netværksproblemer. Det får yderligere slaven til at servere forældede data.
Konklusion
Vi har nævnt nogle af de vigtige metrics, der vil give et godt overblik over din databaseservers sundhed og ydeevne. Der kan være andre, der er relevante for netop dine databaseservere og use cases. Vi vil anbefale at gå igennem og forstå alle de metrics, der rapporteres af "info"-kommandoen.
Hvis du har brug for hjælp til at administrere din AWS-hosting til Redis™ -implementeringer, er du velkommen til at kontakte os via e-mail på [email protected] eller på Twitter @scalegridio.