Amélioration du journal lent de Redis |  Redis

Amélioration du journal lent de Redis | Redis

Journal lent de Redis est l’un des meilleurs outils de débogage et de traçage de votre base de données Redis, en particulier si vous rencontrez une latence élevée et une utilisation élevée du processeur avec les opérations Redis. Cette discussion en ligne dans un groupe Redis DB n’est qu’un des nombreux exemples qui montrent à quel point Redis Slow Log est efficace. Étant donné que Redis est basé sur une architecture à thread unique, Redis Slow Log peut être beaucoup plus utile que les mécanismes de journal lent des systèmes de base de données multithread tels que MySQL Slow Query Log.

Contrairement aux outils qui incluent la surcharge de verrouillage logiciel qui rend le processus de débogage très complexe, Redis Slow Log est très efficace pour afficher le temps de traitement réel de chaque commande lente. En tant que fournisseur de Nuage Redis, nous utilisons Redis Slow Log de manière intensive pour la surveillance interne et pour aider nos utilisateurs à résoudre les problèmes de latence liés à leurs requêtes complexes. Et nous avons souvent du mal à comprendre les différences entre deux temps d’exécution de la même commande Redis affichée dans le journal lent – généralement avec des commandes complexes telles que ZUNIONSTORE, ZINTERSTORE, ZRANGEPARSCORE. Sur la base de notre expérience, nous avons pensé que la communauté Redis pourrait bénéficier de l’ajout des paramètres de complexité temporelle pour chaque commande stockée dans le Slow Log. Avec cette amélioration, nous nous attendons à ce que les utilisateurs aient une meilleure compréhension de leurs opérations Redis DB, y compris les différences entre les temps d’exécution de la même commande et les pics d’utilisation du processeur. Alors sans plus tarder, voici (en gras) ce que nous avons contribué pour le journal lent Redis amélioré :

33) 1) (entier) 468359

2) (entier) 1358158701

3) (entier) 132912

4) Informations sur la complexité : N : 48362, M : 38687

5)1) “ZUNIONSTORE”

2) “AAA”

3) “5”

4) “BBB”

5) “CCC”

6) “DDD”

7) “EEE”

8) “FFF”

9) “POIDS”

10) “1”

11) “1”

12) “1”

13) “1”

14) “1”

15) « AGRÉGÉ »

16) “MIN”

34) 1) (entier) 61701

2) (entier) 1354754379

3) (entier) 15217

4) Informations sur la complexité : N : 886, M : 885

5) 1) “ZRANGEREV”

2) “XYZ”

3) “1”

4) “1000”

5) “AVEC SCORES”

35) 1) (entier) 61700

2) (entier) 1354754379

3) (entier) 16067

4) Informations sur la complexité : N : 897, K : 2, M : 897

5) 1) “ZINTERSTORE”

2) “XYZ”

3) “2”

4) “YZX”

5) “ZXY”

Pour mieux comprendre la complexité, vous pouvez utiliser le tableau ci-dessous :

Commande Valeur d’intérêt Complexité
LINSÉRER N – longueur de la liste SUR)
LREM N – longueur de la liste SUR)
LTRIM N – nombre d’éléments supprimés SUR)
PUBLIER N – nombre d’abonnés au canalM – nombre de modèles souscrits O(N+M)
PSABONNEZ-VOUS N – nombre de modèles auxquels le client est abonné argc – nombre d’arguments passés à la commande O(argc*N)
PUNSABONNEZ-VOUS N – nombre de modèles auxquels le client est abonnéM – nombre total de modèles souscritsargc – nombre d’arguments passés à la commande O(argc*(N+M))
SDIFF N – nombre total d’éléments dans tous les ensembles SUR)
SDIFFSTORE N – nombre total d’éléments dans tous les ensembles SUR)
FRITTAGE N – nombre d’éléments dans le plus petit setargc – nombre d’arguments passés à la commande O(argc*N)
SINTERSTORE N – nombre d’éléments dans le plus petit setargc – nombre d’arguments passés à la commande O(argc*N)
PME N – nombre d’éléments dans un ensemble SUR)
TRIER N – nombre d’éléments dans la liste/ensemble/zsetM – nombre d’éléments dans le résultat O(N+M*log(M))O(N) sans tri
SUNION N – nombre total d’éléments dans tous les ensembles SUR)
SUNIONSTORE N – nombre total d’éléments dans tous les ensembles SUR)
SE DÉSABONNER N – nombre total de clients abonnés à tous les canaux SUR)
ZADD N – nombre d’éléments dans le zset O(log(N))
ZCOUNT N – nombre d’éléments dans le zsetM – nombre d’éléments entre min et max O(log(N)+M)
ZINCRBY N – nombre d’éléments dans le zset O(log(N))
ZINTERSTORE N – nombre d’éléments dans le plus petit zsetK – nombre de zsetsM – nombre d’éléments dans l’ensemble de résultats O(N*K)+O(M*log(M))
ZRANGE N – nombre d’éléments dans le zsetM – nombre de résultats O(log(N)+M)
ZRANGEPARSCORE N – nombre d’éléments dans le zsetM – nombre de résultats O(log(N)+M)
ZRANK N – nombre d’éléments dans le zset O(log(N))
ZREM N – nombre d’éléments dans le zsetargc – nombre d’arguments passés à la commande O(argc*log(N))
ZREMRANGEPARRANK N – nombre d’éléments dans le zsetM – nombre d’éléments supprimés O(log(N)+M)
ZREMRANGEPARSCORE N – nombre d’éléments dans le zsetM – nombre d’éléments supprimés O(log(N)+M)
ZREVRANGE N – nombre d’éléments dans le zsetM – nombre de résultats O(log(N)+M)
ZREVRANK N – nombre d’éléments dans le zset O(log(N))
ZUNIONSTORE N – somme des nombres d’éléments de tous les zsetsM – nombre d’éléments du résultat O(N)+O(M*log(M))

Pour ceux que cela intéresse, cette amélioration fait partie de notre extension Redis 2.6. version et peut être trouvé ici dans notre compte GitHub.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *