Opnieuw is een in-memory database die razendsnelle prestaties levert. Dit maakt het een aantrekkelijk alternatief voor op schijf gebaseerde databases wanneer prestaties een probleem zijn. Mogelijk gebruikt u al ScaleGrid-hosting voor Redis™* om uw prestatiegevoelige apps van stroom te voorzien. Hoe zorgt u ervoor dat uw Redis-implementatie in orde is en aan uw vereisten voldoet? U moet weten welke monitoringstatistieken Redis™ moet bekijken en een tool om deze kritieke serverstatistieken te bewaken om de gezondheid ervan te garanderen. Redis retourneert een grote lijst met databasestatistieken wanneer u de info-opdracht op Redis-shell uitvoert. U kunt hieruit een slimme selectie van relevante statistieken kiezen. En deze kunnen u helpen de gezondheid van uw systeem te waarborgen en snel een analyse van de hoofdoorzaak uit te voeren van elk prestatiegerelateerd probleem dat u mogelijk tegenkomt.
Dit blogbericht geeft een overzicht van de belangrijke databasestatistieken die moeten worden gecontroleerd. We bekijken elke statistiek vanuit het perspectief van databaseprestaties en bespreken de veelvoorkomende problemen en oplossingen die ermee samenhangen.
1. Prestatiestatistiek:doorvoer
De doorvoer vertelt u hoeveel databasebewerkingen uw server uitvoert in een bepaalde tijdsduur. Het is afhankelijk van de werkbelasting van uw toepassing en de bedrijfslogica. Door naar de geschiedenis van de doorvoer te kijken, kunt u het belastingpatroon op een server afleiden, b.v. piekbelasting, frequentie van piekbelasting, tijdsbestek van piekbelasting, gemiddelde belasting etc.
U kunt metrische doorvoerwaarden verzamelen voor alle opdrachten die op de Redis-server worden uitgevoerd door "info commandstats uit te voeren". ”.
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 groepeert zijn verschillende commando's in verbinding, server, cluster, generiek enz. ScaleGrid-monitoring voor Redis™ verzamelt de doorvoer van verschillende commando's in een van de bovengenoemde groepen. De doorvoer wordt weergegeven als een gestapeld gebiedsdiagram, waarbij de hoogte van elk gekleurd gebied de doorvoer van een groep opdrachten geeft.
Een verminderde doorvoer kan er over het algemeen op duiden dat de server minder vragen krijgt. Het kan ook wijzen op een mogelijk probleem, bijvoorbeeld een dure zoekopdracht. Evenzo betekent een verhoogde doorvoer een intensieve werkbelasting op een server en een grotere latentie.
2. Geheugengebruik
Geheugen is een kritieke bron voor Redis-prestaties. Gebruikt geheugen definieert het totale aantal bytes dat is toegewezen door Redis met behulp van zijn allocator (standaard libc, jemalloc of een alternatieve allocator zoals tcmalloc).
U kunt alle metrische gegevens over geheugengebruik voor een Redis-instantie verzamelen door "info memory uit te voeren". ”.
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
Soms, wanneer Redis is geconfigureerd zonder maximale geheugenlimiet, zal het geheugengebruik uiteindelijk het systeemgeheugen bereiken en begint de server "Onvoldoende geheugen"-fouten te genereren. Op andere momenten is Redis geconfigureerd met een maximale geheugenlimiet maar noeviction het beleid. Dit zou ervoor zorgen dat de server geen sleutels verwijdert, waardoor schrijfacties worden voorkomen totdat geheugen is vrijgemaakt. De oplossing voor dergelijke problemen zou zijn om Redis te configureren met maximaal geheugen en wat uitzettingsbeleid. In dit geval begint de server met het verwijderen van sleutels met behulp van het uitzettingsbeleid als het geheugengebruik het maximum bereikt.
Geheugen-RSS (Resident Set Size) is het aantal bytes dat het besturingssysteem aan Redis heeft toegewezen. Als de verhouding van 'memory_rss' tot 'memory_used' groter is dan ~1,5, betekent dit geheugenfragmentatie. Het gefragmenteerde geheugen kan worden hersteld door de server opnieuw op te starten.
3. Cache-hitratio
De cache hit ratio geeft de efficiëntie van het cachegebruik weer. Wiskundig wordt het gedefinieerd als (Totaal aantal toetsaanslagen)/ (Totaal toetsaanslagen + Totaal aantal toetsaanslagen).
“info stats ” commando levert keyspace_hits &keyspace_misses metrische gegevens om de cachehit-ratio verder te berekenen voor een actieve Redis-instantie.
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 .............
Als de cache-hitratio lager is dan ~0,8, dan is een aanzienlijk deel van de gevraagde sleutels verwijderd, verlopen of helemaal niet meer aanwezig. Het is van cruciaal belang om deze statistiek te bekijken terwijl u Redis als cache gebruikt. Een lagere cache-hitverhouding resulteert in een grotere latentie omdat de meeste verzoeken gegevens van de schijf ophalen. Het geeft aan dat u de Redis-cache moet vergroten om de prestaties van uw toepassing te verbeteren.
4. Actieve verbindingen
Het aantal verbindingen is een beperkte hulpbron die wordt afgedwongen door het besturingssysteem of door de Redis-configuratie. Door de actieve verbindingen te bewaken, kunt u ervoor zorgen dat u voldoende verbindingen hebt om al uw verzoeken tijdens piekuren te behandelen.
5. Uitgezet/verlopen sleutels
Redis ondersteunt verschillende uitzettingsbeleid die door de server worden gebruikt wanneer het geheugengebruik de maximale limiet bereikt. Een aanhoudende positieve waarde van deze statistiek is een indicatie dat u het geheugen moet opschalen.
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 ondersteunt TTL (tijd om te leven) eigendom voor elke sleutel. De server verwijdert de sleutel als de bijbehorende TTL is verstreken. Als de toepassing deze eigenschap niet definieert, zorgt dit ervoor dat verlopen gegevens zich opstapelen in het geheugen. Een positieve metrische waarde geeft aan dat uw verlopen gegevens correct worden opgeschoond.
6. Replicatiestatistieken
‘connected_slaves’ metric informeert de bereikbaarheid van de slave-server naar een master. Onbereikbaarheid van slaven kan leiden tot een hogere leeslatentie, afhankelijk van de leesbelasting op een 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 ’ metric vertelt hoeveel tijd er verstrijkt tijdens de communicatie tussen een slave en de master. Een hogere waarde voor deze statistiek kan wijzen op problemen met de master/slave of op bepaalde netwerkproblemen. Het zorgt er verder voor dat de slaaf oude gegevens weergeeft.
Conclusie
We hebben enkele van de belangrijke statistieken genoemd die een goed inzicht geven in de gezondheid en prestaties van uw databaseserver. Er kunnen andere zijn die relevant zijn voor uw specifieke databaseservers en use-cases. We raden aan om alle statistieken die worden gerapporteerd door de "info"-opdracht door te nemen en te begrijpen.
Als je hulp nodig hebt bij het beheren van je AWS-hosting voor Redis™-implementaties, neem dan gerust contact met ons op via e-mail op [email protected] of op Twitter @scalegridio.