Comment résoudre les problèmes de latence courants dans Redis

Utilisez des commandes complexes

Si vous constatez que le délai d'accès augmente soudainement lors de l'utilisation de Redis, comment dépanner ?

Tout d'abord, la première étape consiste à vérifier le journal lent de Redis. Grâce à la fonction de statistiques de commandes de journalisation lente de Redis, nous pouvons définir les options suivantes pour voir quelles commandes entraînent un retard d'exécution important.

Définissez d'abord le seuil de journal lent de Redis. Seules les commandes qui dépassent le seuil seront enregistrées. L'unité ici est la microseconde. Par exemple, définissez le seuil de journal lent sur 5 millisecondes et définissez uniquement les 1 000 derniers enregistrements de journal lent à conserver. :

# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000

Une fois le réglage terminé, toutes les commandes exécutées seront enregistrées par Redis si le délai est supérieur à 5 millisecondes. Nous exécutons SLOWLOG get 5 pour interroger les 5 derniers journaux lents :

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 执行时间
   3) (integer) 5299        # 执行耗时(微妙)
   4) 1) "LRANGE"           # 具体执行的命令和参数
      2) "user_list_2000"
      3) "0"
      4) "-1"
2) 1) (integer) 32692
   2) (integer) 1593763337
   3) (integer) 5044
   4) 1) "GET"
      2) "book_price_1000"
...

En visualisant les enregistrements des journaux lents, nous pouvons savoir quelles commandes ont été exécutées à quelle heure. Les commandes prennent du temps. Si votre entreprise utilise souvent des commandes d'une complexité supérieure à O(N), telles que sort, sunion, zunionstore, key, scan ou la quantité de données exploitées lors de l'exécution. Les commandes O(N) sont relativement volumineuses, ces situations prendront beaucoup de temps lors du traitement des données sous Redis.

Si l'utilisation du processeur de l'instance Redis est élevée, mais que le volume de vos demandes de service n'est pas important, cela est probablement dû à l'utilisation de commandes d'une grande complexité.

La solution est de ne pas utiliser ces commandes complexes, et de ne pas obtenir trop de données à la fois. Essayez d'exploiter une petite quantité de données à chaque fois afin que Redis puisse les traiter et les renvoyer à temps.

Stockage de bigkey

Si vous interrogez le journal lent et constatez qu'il n'est pas causé par des commandes très complexes, par exemple, les opérations SET et DELETE apparaissent dans l'enregistrement du journal lent, alors vous devez vous demander si Redis a écrit bigkey. Condition.

Lorsque Redis écrit de nouvelles données, de l'espace mémoire leur est alloué, et lorsque les données sont supprimées de Redis, l'espace mémoire correspondant est également libéré.

Lorsque les données écrites par une clé sont très volumineuses, l'allocation de mémoire par Redis prendra également plus de temps. De même, lors de la suppression des données de cette clé, la libération de la mémoire prendra beaucoup de temps.

Vous devez vérifier votre code métier pour voir si une grande clé est en cours d'écriture. Vous devez évaluer la quantité de données écrites. La couche métier doit éviter de stocker trop de données dans une seule clé.

En réponse au problème de bigkey, Redis a officiellement lancé le mécanisme lazy-free dans la version 4.0, qui est utilisé pour libérer de manière asynchrone la mémoire de bigkey et réduire l'impact sur les performances de Redis. Même ainsi, nous ne recommandons pas d'utiliser bigkey. Bigkey affectera également les performances de la migration pendant le processus de migration du cluster. Cela sera présenté en détail plus loin dans les articles relatifs au cluster.

Expiration concentrée

Parfois, vous constaterez qu'il n'y a pas de retard important lors de l'utilisation de Redis, mais une vague de retards se produit soudainement à un certain moment, et les points temporels lents sont très réguliers, comme un certain cela arrivera à l'heure ou à intervalles réguliers.

Si cela se produit, vous devez vous demander s'il existe un grand nombre de clés collectivement expirées.

Si un grand nombre de clés expirent à un moment donné, lors de l'accès à Redis à ce moment-là, le délai peut augmenter.

La stratégie d'expiration de Redis adopte deux stratégies : suppression régulière + suppression paresseuse ;

Notez que les tâches planifiées de suppression régulière de Redis sont également exécutées dans le thread principal de Redis, ce qui signifie que si lors de l'exécution de l'expiration active, une erreur se produit Si vous en avez besoin pour supprimer un grand nombre de clés expirées, alors lors de l'accès métier, vous devez attendre la fin de la tâche expirée avant de traiter la demande métier. À ce stade, le problème de l'augmentation du délai d'accès professionnel se posera et le délai maximum est de 25 millisecondes.

Et ce délai d'accès ne sera pas enregistré dans le journal des lenteurs. Le journal lent enregistre uniquement le temps d'exécution réel d'une certaine commande. La politique d'expiration active Redis est exécutée avant la commande d'opération. Si la commande d'opération n'atteint pas le seuil de journal lent, elle ne sera pas calculée dans les statistiques du journal lent. les entreprises ont connu des retards accrus.

La solution est d'ajouter une heure aléatoire à l'expiration centralisée et d'étaler les heures de ces clés qui doivent expirer.

La mémoire de l'instance atteint la limite supérieure

Parfois, lorsque nous utilisons Redis comme cache pur, nous définissons une limite supérieure de mémoire maxmemory pour l'instance, puis activons la stratégie d'élimination LRU.

Lorsque la mémoire de l'instance atteint la mémoire maximale, vous constaterez que l'écriture de nouvelles données peut devenir plus lente à chaque fois.

La raison du ralentissement est que lorsque la mémoire Redis atteint la mémoire maximale, avant que chaque nouvelle donnée ne soit écrite, une partie des données doit être expulsée pour maintenir la mémoire en dessous de la mémoire maximale.

Cette logique d'élimination des anciennes données prend également du temps, et la durée spécifique dépend de la stratégie d'élimination configurée

fork prend beaucoup de temps

Si votre Redis a la fonction de génération automatique de RDB et de réécriture AOF activée, alors cela peut entraîner une augmentation du délai d'accès de Redis lorsque la réécriture RDB et AOF est générée en arrière-plan, et le délai disparaît une fois ces tâches terminées.

Lorsque vous rencontrez cette situation, cela est généralement dû à l'exécution des tâches de génération de réécriture RDB et AOF.

La génération de RDB et d'AOF nécessite que le processus parent débourse un processus enfant pour la persistance des données. Pendant le processus d'exécution du fork, le processus parent doit copier la table des pages mémoire dans le processus enfant si l'instance entière occupe une grande quantité de données. mémoire, alors la mémoire doit être copiée. La table des pages prendra du temps. Ce processus consommera beaucoup de ressources CPU avant que le fork ne soit terminé, l'instance entière sera bloquée et incapable de traiter aucune requête. Les ressources CPU sont limitées en ce moment, le fork prendra plus de temps, voire atteindra quelques secondes. Cela affectera sérieusement les performances de Redis.

Liaison du processeur

Souvent, lorsque nous déployons des services, afin d'améliorer les performances et de réduire la perte de performances du changement de contexte lorsque le programme utilise plusieurs processeurs, nous utilisons généralement le processus pour lier le processeur.

Mais lorsque vous utilisez Redis, nous vous déconseillons de le faire pour les raisons suivantes.

Redis lié au CPU, lors de l'exécution de la persistance des données, le processus enfant dupliqué héritera de la préférence d'utilisation du processeur du processus parent. À ce stade, le processus enfant consommera une grande quantité de ressources CPU pour la persistance des données. Il y aura un conflit de CPU avec le processus principal, ce qui entraînera également des ressources CPU insuffisantes du processus principal et une augmentation du délai d'accès.

Ainsi, lors du déploiement du processus Redis, si vous devez activer le mécanisme de réécriture RDB et AOF, vous ne devez pas effectuer d'opérations de liaison CPU

Utilisez Swap

Si vous constatez que Redis devient soudainement très lent, chaque accès prend jusqu'à des centaines de millisecondes ou même de secondes, puis vérifiez si Redis utilise Swap. Dans ce cas, Redis est fondamentalement incapable de fournir des services hautes performances.

Nous savons que le système d'exploitation fournit un mécanisme de Swap. Le but est d'échanger une partie des données en mémoire sur le disque lorsque la mémoire est insuffisante, afin de tamponner l'utilisation de la mémoire.

Mais une fois les données de la mémoire transférées sur le disque, l'accès aux données nécessite une lecture à partir du disque, ce qui est beaucoup plus lent que la mémoire !

Surtout pour une base de données en mémoire hautes performances comme Redis, si la mémoire de Redis est échangée sur le disque, ce temps de fonctionnement est inacceptable pour une base de données extrêmement sensible aux performances comme Redis. Vous pouvez arrêter temporairement le système d'exploitation Swap

La charge de la carte réseau est trop élevée

La caractéristique est qu'elle commence à ralentir à partir d'un certain moment et continue. À ce stade, vous devez vérifier si le trafic de la carte réseau de la machine est épuisé.

Une charge réseau élevée peut entraîner des problèmes tels que des retards d'envoi de données et des pertes de données au niveau de la couche réseau et du TCP. En plus de la mémoire, Redis est performant en raison de ses excellentes performances d'E/S réseau. Cependant, à mesure que le nombre de requêtes continue d'augmenter, la charge sur la carte réseau augmentera en conséquence.

Si cela se produit, vous devez vérifier quelle instance Redis sur cette machine a un trafic excessif et remplit la bande passante du réseau, puis confirmer si l'augmentation soudaine du trafic est une situation commerciale normale. Si c'est le cas, vous devez alors vous développer. ou migrez l'instance à temps. Empêchez que d'autres instances de cette machine soient affectées.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!