Ponownie to baza danych w pamięci, która zapewnia niesamowicie wysoką wydajność. To sprawia, że jest to atrakcyjna alternatywa dla baz danych opartych na dyskach, gdy liczy się wydajność. Być może korzystasz już z hostingu ScaleGrid dla Redis™* do obsługi aplikacji wrażliwych na wydajność. W jaki sposób upewnisz się, że wdrożenie Redis jest sprawne i spełnia Twoje wymagania? Musisz wiedzieć, które metryki monitorowania Redis™ należy obserwować, oraz narzędzie do monitorowania tych krytycznych metryk serwera, aby zapewnić jego kondycję. Redis zwraca dużą listę metryk bazy danych po uruchomieniu polecenia info w powłoce Redis. Możesz wybrać z nich sprytny wybór odpowiednich danych. A to może pomóc w zapewnieniu dobrego stanu systemu i szybkim przeprowadzeniu analizy przyczyn źródłowych wszelkich problemów związanych z wydajnością, które możesz napotkać.
Ten post na blogu zawiera listę ważnych wskaźników bazy danych do monitorowania. Przyjrzymy się każdemu wskaźnikowi z perspektywy wydajności bazy danych i omówimy typowe problemy i rozwiązania z nimi związane.
1. Wskaźnik wydajności:przepustowość
Przepustowość informuje, ile operacji na bazie danych wykonuje Twój serwer w określonym czasie. Zależy to od obciążenia aplikacji i jej logiki biznesowej. Patrząc na historię przepustowości, można wywnioskować schemat obciążenia serwera, np. obciążenie szczytowe, częstotliwość obciążenia szczytowego, ramy czasowe obciążenia szczytowego, średnie obciążenie itp.
Możesz zbierać wartości metryki przepustowości dla wszystkich poleceń uruchamianych na serwerze Redis, wykonując „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 grupuje różne polecenia w połączenia, serwer, klaster, ogólne itp. Monitorowanie ScaleGrid dla Redis™ agreguje przepustowość różnych poleceń w jedną z wyżej wymienionych grup. Przepustowość jest reprezentowana jako skumulowany wykres warstwowy, w którym wysokość każdego kolorowego obszaru zapewnia przepustowość grupy poleceń.
Zmniejszona przepustowość może ogólnie wskazywać, że serwer otrzymuje mniej zapytań. Może również wskazywać na potencjalny problem, powiedzmy, kosztowne zapytanie. Podobnie zwiększona przepustowość oznacza intensywne obciążenie serwera i większe opóźnienia.
2. Wykorzystanie pamięci
Pamięć jest krytycznym zasobem wydajności Redis. Wykorzystana pamięć definiuje całkowitą liczbę bajtów przydzielonych przez Redis przy użyciu jego alokatora (standardowego libc, jemalloc lub alternatywnego alokatora, takiego jak tcmalloc).
Możesz zebrać wszystkie dane dotyczące metryk wykorzystania pamięci dla instancji Redis, uruchamiając „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
Czasami, gdy Redis jest skonfigurowany bez maksymalnego limitu pamięci, użycie pamięci w końcu osiągnie pamięć systemową, a serwer zacznie wyrzucać błędy „Brak pamięci”. Innym razem Redis jest skonfigurowany z maksymalnym limitem pamięci, ale noeviction polityka. Spowodowałoby to, że serwer nie eksmitowałby żadnych kluczy, uniemożliwiając w ten sposób wszelkie zapisy do czasu zwolnienia pamięci. Rozwiązaniem takich problemów byłoby skonfigurowanie Redisa z maksymalną pamięcią i pewną polityką eksmisji. W takim przypadku serwer zaczyna eksmitować klucze za pomocą zasad eksmisji, gdy wykorzystanie pamięci osiągnie maksimum.
Pamięć RSS (Rozmiar zestawu rezydentnego) to liczba bajtów, które system operacyjny przydzielił do Redis. Jeśli stosunek „memory_rss” do „memory_used” jest większy niż ~1,5, oznacza to fragmentację pamięci. Pofragmentowaną pamięć można odzyskać przez ponowne uruchomienie serwera.
3. Współczynnik trafień w pamięci podręcznej
Współczynnik trafień w pamięci podręcznej reprezentuje efektywność wykorzystania pamięci podręcznej. Matematycznie jest to zdefiniowane jako (Łączna liczba trafień klawiszy)/ (Łączna liczba trafień klawiszy + Całkowita liczba nietrafionych klawiszy).
„informacje statystyczne Polecenie zapewnia kluczowe_trafienia &keyspace_misses dane metryczne w celu dalszego obliczenia współczynnika trafień w pamięci podręcznej dla działającej instancji Redis.
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 .............
Jeśli współczynnik trafień w pamięci podręcznej jest niższy niż ~0,8, znaczna liczba żądanych kluczy jest usuwana, wygasła lub w ogóle nie istnieje. Bardzo ważne jest obserwowanie tego wskaźnika podczas korzystania z Redis jako pamięci podręcznej. Niższy współczynnik trafień w pamięci podręcznej skutkuje większym opóźnieniem, ponieważ większość żądań pobiera dane z dysku. Wskazuje, że musisz zwiększyć rozmiar pamięci podręcznej Redis, aby poprawić wydajność aplikacji.
4. Aktywne połączenia
Liczba połączeń jest ograniczonym zasobem, który jest wymuszany przez system operacyjny lub konfigurację Redis. Monitorowanie aktywnych połączeń pomaga upewnić się, że masz wystarczającą liczbę połączeń, aby obsłużyć wszystkie żądania w godzinach szczytu.
5. Wykluczone/wygasłe klucze
Redis obsługuje różne zasady eksmisji które są używane przez serwer, gdy użycie pamięci osiągnie maksymalny limit. Trwała dodatnia wartość tego wskaźnika wskazuje, że musisz skalować pamięć w górę.
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 obsługuje TTL (czas życia) właściwość dla każdego klucza. Serwer usuwa klucz, jeśli skojarzony czas TTL upłynął. Jeśli aplikacja nie definiuje tej właściwości, powoduje to gromadzenie się w pamięci wygasłych danych. Dodatnia wartość metryki wskazuje, że wygasłe dane są prawidłowo czyszczone.
6. Metryki replikacji
‘connected_slaves’ metryka informuje serwer nadrzędny o osiągalności serwera podrzędnego. Nieosiągalność urządzenia podrzędnego może prowadzić do większego opóźnienia odczytu w zależności od obciążenia odczytu na serwerze.
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 ’ metryka mówi, ile czasu upływa podczas komunikacji między urządzeniem podrzędnym a urządzeniem nadrzędnym. Wyższa wartość tej metryki może wskazywać na problemy z urządzeniem nadrzędnym/podrzędnym lub pewne problemy z siecią. Ponadto powoduje to, że urządzenie podrzędne obsługuje przestarzałe dane.
Wniosek
Wspomnieliśmy o niektórych ważnych metrykach, które zapewnią dobry wgląd w stan i wydajność serwera bazy danych. Mogą istnieć inne, które są odpowiednie dla konkretnych serwerów baz danych i przypadków użycia. Zalecamy przejrzenie i zrozumienie wszystkich metryk zgłaszanych przez polecenie „info”.
Jeśli potrzebujesz pomocy w zarządzaniu hostingiem AWS dla wdrożeń Redis™, skontaktuj się z nami przez e-mail na [email protected] lub na Twitterze @scalegridio.
