Redis est une base de données en mémoire qui offre des performances incroyablement rapides. Cela en fait une alternative intéressante aux bases de données sur disque lorsque les performances sont un problème. Vous utilisez peut-être déjà l'hébergement ScaleGrid pour Redis™* pour alimenter vos applications sensibles aux performances. Comment vous assurez-vous que votre déploiement Redis est sain et répond à vos exigences ? Vous aurez besoin de savoir quelles métriques de surveillance pour Redis™ surveiller et un outil pour surveiller ces métriques critiques du serveur afin d'assurer sa santé. Redis renvoie une longue liste de métriques de base de données lorsque vous exécutez la commande info sur le shell Redis. Vous pouvez choisir une sélection intelligente de métriques pertinentes parmi celles-ci. Et ceux-ci peuvent vous aider à garantir la santé de votre système et à effectuer rapidement une analyse des causes profondes de tout problème lié aux performances que vous pourriez rencontrer.
Cet article de blog répertorie les métriques de base de données importantes à surveiller. Nous examinerons chaque métrique du point de vue des performances de la base de données et discuterons des problèmes courants et des solutions qui leur sont associées.
1. Mesure des performances :débit
Le débit vous indique le nombre d'opérations de base de données effectuées par votre serveur dans un laps de temps donné. Cela dépend de la charge de travail de votre application et de sa logique métier. En examinant l'historique du débit, vous pouvez déduire le modèle de charge sur un serveur, par ex. la charge de pointe, la fréquence de la charge de pointe, les périodes de charge de pointe, la charge moyenne, etc.
Vous pouvez collecter des valeurs de métrique de débit pour toutes les commandes exécutées sur le serveur Redis en exécutant "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 regroupe ses différentes commandes en connexion, serveur, cluster, générique, etc. La surveillance ScaleGrid pour Redis™ agrège le débit de diverses commandes dans l'un des groupes mentionnés ci-dessus. Le débit est représenté sous la forme d'un graphique à aires empilées, où la hauteur de chaque zone colorée fournit le débit d'un groupe de commandes.
Un débit réduit peut généralement indiquer que le serveur reçoit moins de requêtes. Cela pourrait également indiquer un problème potentiel, par exemple une requête coûteuse. De même, un débit accru signifie une charge de travail intensive sur un serveur et une latence plus importante.
2. Utilisation de la mémoire
La mémoire est une ressource essentielle pour les performances de Redis. Mémoire utilisée définit le nombre total d'octets alloués par Redis à l'aide de son allocation (libc standard, jemalloc ou un allocateur alternatif tel que tcmalloc).
Vous pouvez collecter toutes les données de métriques d'utilisation de la mémoire pour une instance Redis en exécutant "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
Parfois, lorsque Redis est configuré sans limite de mémoire maximale, l'utilisation de la mémoire finira par atteindre la mémoire système et le serveur commencera à générer des erreurs "Mémoire insuffisante". À d'autres moments, Redis est configuré avec une limite de mémoire maximale mais aucune éviction politique. Cela empêcherait le serveur d'expulser les clés, empêchant ainsi toute écriture jusqu'à ce que la mémoire soit libérée. La solution à de tels problèmes serait de configurer Redis avec une mémoire maximale et une politique d'expulsion. Dans ce cas, le serveur commence à expulser les clés en utilisant la politique d'expulsion lorsque l'utilisation de la mémoire atteint le maximum.
Mémoire RSS (Resident Set Size) est le nombre d'octets que le système d'exploitation a alloués à Redis. Si le rapport entre "memory_rss" et "memory_used" est supérieur à ~1,5, cela signifie une fragmentation de la mémoire. La mémoire fragmentée peut être récupérée en redémarrant le serveur.
3. Taux d'accès au cache
Le taux d'accès au cache représente l'efficacité de l'utilisation du cache. Mathématiquement, il est défini comme (Total des touches)/(Total des touches + Total des touches manquées).
"statistiques d'informations ” la commande fournit keyspace_hits &keyspace_misses données métriques pour calculer davantage le taux d'accès au cache pour une instance Redis en cours d'exécution.
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 .............
Si le taux d'accès au cache est inférieur à ~0,8, une quantité importante de clés demandées est supprimée, a expiré ou n'existe pas du tout. Il est crucial de surveiller cette métrique tout en utilisant Redis comme cache. Un taux d'accès au cache plus faible entraîne une latence plus importante, car la plupart des requêtes récupèrent des données sur le disque. Cela indique que vous devez augmenter la taille du cache Redis pour améliorer les performances de votre application.
4. Connexions actives
Le nombre de connexions est une ressource limitée qui est imposée soit par le système d'exploitation, soit par la configuration Redis. La surveillance des connexions actives vous aide à vous assurer que vous disposez de suffisamment de connexions pour répondre à toutes vos demandes aux heures de pointe.
5. Clés évincées/expirées
Redis prend en charge diverses politiques d'expulsion qui sont utilisés par le serveur lorsque l'utilisation de la mémoire atteint la limite maximale. Une valeur positive persistante de cette métrique indique que vous devez augmenter la mémoire.
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 prend en charge TTL (durée de vie) propriété pour chaque clé. Le serveur supprime la clé si le TTL associé est écoulé. Si l'application ne définit pas cette propriété, les données expirées s'accumulent en mémoire. Une valeur de métrique positive indique que vos données expirées sont correctement nettoyées.
6. Métriques de réplication
'connected_slaves' La métrique informe de l'accessibilité du serveur esclave à un maître. L'inaccessibilité de l'esclave peut entraîner une latence de lecture plus élevée en fonction de la charge de lecture sur un serveur.
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 La métrique indique combien de temps s'écoule pendant la communication entre un esclave et le maître. Une valeur plus élevée pour cette métrique peut indiquer des problèmes sur le maître/esclave ou certains problèmes de réseau. Cela amène en outre l'esclave à servir des données obsolètes.
Conclusion
Nous avons mentionné certaines des métriques importantes qui fourniront une bonne visibilité sur la santé et les performances de votre serveur de base de données. Il pourrait y en avoir d'autres qui sont pertinents pour vos serveurs de base de données et vos cas d'utilisation particuliers. Nous vous recommandons de parcourir et de comprendre toutes les métriques rapportées par la commande "info".
Si vous avez besoin d'aide pour gérer votre hébergement AWS pour les déploiements Redis™, n'hésitez pas à nous contacter par e-mail à [email protected] ou sur Twitter @scalegridio.
