Redis ist eine In-Memory-Datenbank, die eine blitzschnelle Leistung bietet. Dies macht es zu einer überzeugenden Alternative zu festplattenbasierten Datenbanken, wenn es um Leistung geht. Möglicherweise verwenden Sie bereits ScaleGrid-Hosting für Redis™*, um Ihre leistungsempfindlichen Anwendungen zu unterstützen. Wie stellen Sie sicher, dass Ihre Redis-Bereitstellung fehlerfrei ist und Ihre Anforderungen erfüllt? Sie müssen wissen, welche Überwachungsmetriken für Redis™ überwacht werden müssen, und ein Tool zur Überwachung dieser kritischen Servermetriken, um deren Zustand sicherzustellen. Redis gibt eine große Liste von Datenbankmetriken zurück, wenn Sie den info-Befehl auf der Redis-Shell ausführen. Sie können daraus eine intelligente Auswahl relevanter Metriken auswählen. Und diese können Ihnen dabei helfen, den Zustand Ihres Systems sicherzustellen und schnell eine Ursachenanalyse für eventuell auftretende leistungsbezogene Probleme durchzuführen.
Dieser Blogbeitrag listet die wichtigen zu überwachenden Datenbankmetriken auf. Wir betrachten jede Metrik aus der Perspektive der Datenbankleistung und erörtern die damit verbundenen allgemeinen Probleme und Lösungen.
1. Leistungsmetrik:Durchsatz
Durchsatz sagt Ihnen, wie viele Datenbankoperationen Ihr Server in einer bestimmten Zeitdauer durchführt. Dies hängt von Ihrer Anwendungsworkload und ihrer Geschäftslogik ab. Durch Betrachten des Durchsatzverlaufs können Sie das Lastmuster auf einem Server ableiten, z. Spitzenlast, die Häufigkeit der Spitzenlast, die Zeiträume der Spitzenlast, die durchschnittliche Last usw.
Sie können Durchsatzmetrikwerte für alle Befehle sammeln, die auf dem Redis-Server ausgeführt werden, indem Sie „info commandstats“ ausführen “.
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 gruppiert seine verschiedenen Befehle in Verbindung, Server, Cluster, generisch usw. ScaleGrid-Überwachung für Redis™ aggregiert den Durchsatz verschiedener Befehle in einer der oben genannten Gruppen. Der Durchsatz wird als gestapeltes Flächendiagramm dargestellt, wobei die Höhe jedes farbigen Bereichs den Durchsatz einer Gruppe von Befehlen angibt.
Ein verringerter Durchsatz kann im Allgemeinen darauf hindeuten, dass der Server weniger Anfragen erhält. Es könnte auch auf ein potenzielles Problem hinweisen, z. B. eine teure Abfrage. Ebenso bedeutet ein erhöhter Durchsatz eine intensive Arbeitsbelastung auf einem Server und eine größere Latenzzeit.
2. Speicherauslastung
Arbeitsspeicher ist eine entscheidende Ressource für die Leistung von Redis. Verwendeter Speicher Definiert die Gesamtzahl der von Redis zugewiesenen Bytes mithilfe seines Zuordners (entweder Standard-libc, jemalloc oder ein alternativer Zuordner wie tcmalloc).
Sie können alle Messwerte zur Speichernutzung für eine Redis-Instanz sammeln, indem Sie „info memory“ ausführen “.
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
Manchmal, wenn Redis ohne maximales Speicherlimit konfiguriert ist, erreicht die Speichernutzung schließlich den Systemspeicher und der Server beginnt, „Out of Memory“-Fehler auszugeben. Zu anderen Zeiten ist Redis mit einem maximalen Speicherlimit, aber noeviction konfiguriert Politik. Dies würde dazu führen, dass der Server keine Schlüssel entfernt, wodurch Schreibvorgänge verhindert werden, bis der Speicher freigegeben wird. Die Lösung für solche Probleme wäre die Konfiguration von Redis mit maximalem Speicher und einigen Eviction-Richtlinien. In diesem Fall beginnt der Server mit dem Entfernen von Schlüsseln mithilfe der Entfernungsrichtlinie, wenn die Speicherauslastung das Maximum erreicht.
Speicher-RSS (Resident Set Size) ist die Anzahl der Bytes, die das Betriebssystem Redis zugewiesen hat. Wenn das Verhältnis von „memory_rss“ zu „memory_used“ größer als ~1,5 ist, bedeutet dies eine Speicherfragmentierung. Der fragmentierte Speicher kann durch einen Neustart des Servers wiederhergestellt werden.
3. Cache-Trefferquote
Die Cache-Trefferquote repräsentiert die Effizienz der Cache-Nutzung. Mathematisch ist es definiert als (Total key hits)/ (Total key hits + Total key mises).
“Info-Statistiken “-Befehl liefert keyspace_hits &keyspace_misses Metrikdaten zur weiteren Berechnung der Cache-Trefferquote für eine laufende Redis-Instanz.
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 .............
Wenn die Cache-Trefferquote unter ~0,8 liegt, wird eine erhebliche Menge der angeforderten Schlüssel entfernt, ist abgelaufen oder existiert überhaupt nicht. Es ist wichtig, diese Metrik zu beobachten, während Redis als Cache verwendet wird. Eine niedrigere Cache-Trefferquote führt zu einer größeren Latenz, da die meisten Anforderungen Daten von der Festplatte abrufen. Es weist darauf hin, dass Sie den Redis-Cache vergrößern müssen, um die Leistung Ihrer Anwendung zu verbessern.
4. Aktive Verbindungen
Die Anzahl der Verbindungen ist eine begrenzte Ressource, die entweder vom Betriebssystem oder von der Redis-Konfiguration erzwungen wird. Die Überwachung der aktiven Verbindungen hilft Ihnen sicherzustellen, dass Sie genügend Verbindungen haben, um alle Ihre Anfragen zu Spitzenzeiten zu bedienen.
5. Verdrängte/abgelaufene Schlüssel
Redis unterstützt verschiedene Eviction-Richtlinien die vom Server verwendet werden, wenn die Speicherauslastung die maximale Grenze erreicht. Ein dauerhaft positiver Wert dieser Metrik ist ein Hinweis darauf, dass Sie den Arbeitsspeicher vergrößern müssen.
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 unterstützt TTL (Lebensdauer) Eigenschaft für jeden Schlüssel. Der Server löscht den Schlüssel, wenn die zugehörige TTL abgelaufen ist. Wenn die Anwendung diese Eigenschaft nicht definiert, führt dies dazu, dass sich abgelaufene Daten im Speicher anhäufen. Ein positiver Metrikwert zeigt, dass Ihre abgelaufenen Daten ordnungsgemäß bereinigt werden.
6. Replikationsmetriken
‘connected_slaves’ Die Metrik informiert einen Master über die Erreichbarkeit des Slave-Servers. Die Unerreichbarkeit des Slaves kann abhängig von der Leselast auf einem Server zu einer höheren Leselatenz führen.
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 ’-Metrik gibt an, wie viel Zeit während der Kommunikation zwischen einem Slave und dem Master vergeht. Ein höherer Wert für diese Metrik kann auf Probleme mit dem Master/Slave oder einige Netzwerkprobleme hinweisen. Außerdem veranlasst es den Slave, veraltete Daten bereitzustellen.
Schlussfolgerung
Wir haben einige der wichtigen Metriken erwähnt, die einen guten Einblick in den Zustand und die Leistung Ihres Datenbankservers geben. Es könnte andere geben, die für Ihre speziellen Datenbankserver und Anwendungsfälle relevant sind. Wir empfehlen, alle vom „info“-Befehl gemeldeten Metriken durchzugehen und zu verstehen.
Wenn Sie Hilfe bei der Verwaltung Ihrer AWS-Hosting für Redis™-Bereitstellungen benötigen, können Sie sich gerne per E-Mail unter [email protected] oder auf Twitter unter @scalegrid mit uns in Verbindung setzen.
P>
