Une brève discussion sur les raisons pour lesquelles Redis est lent et comment le résoudre-Redis-php.cn

Cet article vous apporte des connaissances pertinentes sur Redis. Il présente principalement les raisons pour lesquelles Redis est lent et les méthodes de dépannage. L'article le présente en détail à travers un exemple de code, qui est d'une certaine importance pour l'étude ou le travail de chacun. Jetons un coup d'œil à la valeur d'apprentissage. J'espère que cela sera utile à tout le monde.

Une brève discussion sur les raisons pour lesquelles Redis est lent et comment le résoudre

Apprentissage recommandé : Tutoriel vidéo Redis

Cause 1 : La mémoire de l'instance a atteint la limite supérieure

Idées de dépannage

Si votre instance Redis a une limite supérieure de mémoire de maxmemory, cela peut également causer Redis pour ralentir.

Lorsque nous utilisons Redis comme cache pur, nous définissons généralement une limite de mémoire maxmemory pour cette instance, puis définissons une stratégie d'élimination des données. Lorsque la mémoire de l'instance atteint maxmemory, vous constaterez peut-être que le délai d'opération augmente à chaque fois que vous écrivez de nouvelles données par la suite.

Cause du ralentissement

Lorsque la mémoire Redis atteint la mémoire maximale, avant chaque écriture de nouvelles données, Redis doit d'abord expulser une partie des données de l'instance pour conserver la mémoire de l'instance entière en dessous de la mémoire maximale, puis seulement ensuite de nouvelles données peuvent-elles être écrites.

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 que vous configurez :

allkeys-lru : que la clé soit configurée pour expirer ou non, les clés les moins récemment consultées le seront être éliminé key
volatile-lru : seules les clés avec le délai d'accès et d'expiration le moins récent sont définies pour être éliminées key
allkeys-ttl : que la clé soit configurée pour expirer ou non, la clé qui est sur le point d'expirer. sera éliminée. Noeviction : aucune clé ne sera éliminée. Une fois que la mémoire de l'instance atteint la mémoire maximale, une erreur sera renvoyée directement après l'écriture de nouvelles données.
allkeys-lfu : quelle que soit la clé, qu'il s'agisse de définir l'expiration ou d'éliminer la clé. fréquence d'accès la plus basse (prise en charge dans la version 4.0+)
volatile-lfu : éliminez uniquement la clé avec la fréquence d'accès la plus basse et définissez le délai d'expiration (prise en charge dans la version 4.0+)
Quelle stratégie utiliser spécifiquement ? selon des scénarios commerciaux spécifiques. Généralement, les plus couramment utilisées sont les stratégies d'élimination allkeys-lru / volatile-lru. Leur logique de traitement consiste à retirer aléatoirement un lot de clés de l'instance à chaque fois (ce nombre est configurable), puis à éliminer la clé la moins consultée, puis à éliminer la clé la moins utilisée. utilisez les clés restantes. Stockez temporairement les clés dans un pool, continuez à sélectionner au hasard un lot de clés, comparez-les avec les clés du pool précédent, puis éliminez la clé la moins consultée. Répétez cette opération jusqu'à ce que la mémoire de l'instance tombe en dessous de maxmemory.
Il convient de noter que la logique d'élimination des données dans Redis est la même que celle de suppression des clés expirées. Elle est également exécutée avant que la commande ne soit réellement exécutée. En d'autres termes, cela augmentera également le délai de fonctionnement de Redis. De plus, plus l'OPS d'écriture est élevé, plus le délai deviendra également plus évident.

De plus, si bigkey est également stocké dans votre instance Redis à ce moment-là, il faudra également beaucoup de temps pour éliminer et supprimer bigkey pour libérer de la mémoire.

L'avez-vous vu ? Les dangers du bigkey sont partout, c'est pourquoi je vous ai rappelé plus tôt de ne pas stocker le bigkey autant que possible.

Solution

Évitez de stocker les grandes clés et réduisez le temps de libération de la mémoire

La stratégie d'élimination est modifiée en élimination aléatoire, qui est beaucoup plus rapide que LRU (selon la situation commerciale)

Divisez l'instance et éliminez le key La pression est répartie sur plusieurs instances

Si vous utilisez Redis 4.0 ou supérieur, activez le mécanisme layz-free et exécutez l'opération d'élimination des clés et de libération de mémoire dans le thread d'arrière-plan (configurez lazyfree-lazy-eviction = yes )
Idées de dépannage

Nous savons tous que lorsqu'une application demande de la mémoire au système d'exploitation, elle s'applique par page de mémoire, et la taille conventionnelle de la page de mémoire est de 4 Ko. .

À partir de la version 2.6.38, le noyau Linux prend en charge le mécanisme de mémoire énorme, qui permet aux applications de demander de la mémoire au système d'exploitation par unités de 2 Mo.

L'unité de mémoire que l'application applique au système d'exploitation à chaque fois devient plus grande, mais cela signifie également que le temps nécessaire pour demander de la mémoire devient plus long.

Causes du ralentissement
- Lorsque Redis exécute une réécriture RDB et AOF en arrière-plan, il utilise des processus enfants fork pour le gérer. Cependant, une fois que le processus principal a dérivé le processus enfant, le processus principal à ce moment-là peut toujours recevoir des demandes d'écriture, et les demandes d'écriture entrantes utiliseront la méthode Copy On Write (copie lors de l'écriture) pour exploiter les données en mémoire.
- En d'autres termes, une fois que le processus principal a des données qui doivent être modifiées, Redis ne modifiera pas directement les données dans la mémoire existante, mais copiera d'abord les données de la mémoire, puis modifiera les données dans la nouvelle mémoire. c'est ce qu'on appelle la "copie sur écriture".
- Vous pouvez également comprendre la copie sur écriture car quiconque a besoin d'écrire doit d'abord copier puis modifier.
- L'avantage de ceci est que toute opération d'écriture effectuée par le processus parent n'affectera pas la persistance des données du processus enfant (le processus enfant ne conserve que toutes les données de l'instance entière au moment du fork et ne se soucie pas des nouvelles données). changements de données), car le processus enfant n'a besoin que d'un instantané de mémoire, qui est ensuite conservé sur le disque).
- Mais veuillez noter que lorsque le processus principal copie les données de la mémoire, cette étape implique l'application d'une nouvelle mémoire. Si le système d'exploitation active de grandes pages de mémoire à ce moment-là, alors pendant cette période, même si le client n'en modifie que 10 Mo. données, lorsque Redis demande de la mémoire, cela s'appliquera également au système d'exploitation par unités de 2 Mo. Le temps nécessaire pour demander de la mémoire devient plus long, ce qui à son tour entraîne une augmentation du délai de chaque demande d'écriture et affecte les performances de Redis.
- De même, si cette demande d'écriture opère sur une bigkey, alors lorsque le processus principal copie le bloc mémoire bigkey, la mémoire demandée à un moment donné sera plus grande et le temps sera plus long. On peut voir que bigkey affecte ici encore les performances.
Solution

Désactivez le mécanisme des énormes pages.

Tout d'abord, vous devez vérifier si la machine Redis a activé les grandes pages :
```
$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
```
Copier après la connexion
Si l'option de sortie est toujours, cela signifie que le mécanisme des grandes pages est actuellement activé, et nous devons le désactiver :
```
$ echo never > /sys/kernel/mm/transparent_hugepage/enabled
```
Copier après la connexion
En fait, le système d'exploitation fournit L'avantage du mécanisme de page de mémoire énorme est qu'il peut réduire le nombre d'applications qui doivent demander de la mémoire dans certains programmes.
Mais pour une base de données comme Redis qui est extrêmement sensible aux performances et à la latence, nous espérons que Redis prendra le moins de temps possible à chaque fois qu'elle demande de la mémoire, je ne vous recommande donc pas d'activer ce mécanisme sur la machine Redis .
Cause 3 : Utiliser Swap
Idées de dépannage
Si vous constatez que Redis devient soudainement très lent et que chaque opération prend des centaines de millisecondes, voire des secondes, vous devez alors vérifier si Redis Swap est utilisé, et dans ce cas Dans ce cas, Redis est fondamentalement incapable de fournir des services hautes performances.
Causes du ralentissement
Qu'est-ce que Swap ? Pourquoi l'utilisation de Swap entraîne-t-elle une dégradation des performances de Redis ?
Si vous connaissez quelque chose sur le système d'exploitation, vous saurez que afin d'atténuer l'impact d'une mémoire insuffisante sur les applications, le système d'exploitation permet de déplacer une partie des données en mémoire vers le disque pour tamponner l'utilisation de la mémoire. de l'application. Ces données de mémoire La zone qui est échangée sur le disque est Swap.
Le problème est que lorsque les données de la mémoire sont déplacées vers le disque, lorsque Redis accède à nouveau aux données, il doit les lire à partir du disque. La vitesse d'accès au disque est des centaines de fois plus lente que celle d'accès à la mémoire ! Surtout pour une base de données comme Redis, qui a des exigences de performances extrêmement élevées et est extrêmement sensible aux performances, ce retard de fonctionnement est inacceptable.
À ce stade, vous devez vérifier l'utilisation de la mémoire de la machine Redis pour confirmer si Swap est utilisé. Vous pouvez vérifier si le processus Redis utilise Swap de la manière suivante :
```
# 先找到 Redis 的进程 ID
$ ps -aux | grep redis-server
 
# 查看 Redis Swap 使用情况
$ cat /proc/$pid/smaps | egrep &#39;^(Swap|Size)&#39;
```
Copier après la connexion
Les résultats de sortie sont les suivants

Taille : 1256 Ko
Swap : 0 Ko
Taille : 4 Ko
Swap : 0 Ko B
Taille : 132 Ko
Swap : 0 Ko
Taille : 63488 Ko
Swap : 0 Ko
Taille : 132 Ko
Swap : 0 kB
Taille : 65404 kB
Échange :
...

Ce résultat répertoriera l'utilisation de la mémoire par le processus Redis.

Chaque ligne de Size représente la taille d'un morceau de mémoire utilisé par Redis. Le Swap ci-dessous Size représente la taille de cette mémoire et la quantité de données qui ont été échangées sur le disque. Si ces deux valeurs sont égales, cela signifie que les données de cette mémoire ont toutes été complètement transférées sur le disque.

Si seulement une petite quantité de données est échangée sur le disque, par exemple, chaque Swap occupe une petite proportion de la taille correspondante, l'impact n'est pas très important. Si des centaines de mégaoctets, voire de Go de mémoire, sont transférés sur le disque, vous devez alors être vigilant. Dans ce cas, les performances de Redis chuteront certainement fortement.

Solution
Augmentez la mémoire de la machine afin que Redis ait suffisamment de mémoire à utiliser
- Organisez l'espace mémoire, libérez suffisamment de mémoire pour que Redis puisse l'utiliser, puis relâchez l'échange de Redis pour permettre à Redis de réutiliser la mémoire
On peut voir que lorsque Redis utilise Swap, les performances de Redis à l'heure actuelle ne peuvent fondamentalement pas répondre aux exigences de haute performance (vous pouvez comprendre que les arts martiaux sont abolis), vous devez donc également éviter cette situation à l'avance.

Le moyen de l'éviter est que vous devez surveiller la mémoire et l'utilisation du Swap de la machine Redis, déclencher une alarme lorsque la mémoire est insuffisante ou que le Swap est utilisé et le gérer à temps.

Cause 4 : Surcharge de bande passante du réseau

Idées de dépannage
Si vous avez évité les scénarios ci-dessus qui provoquent des problèmes de performances et que Redis fonctionne de manière stable depuis longtemps, mais après un certain temps, l'opération Redis a soudainement commencé à ralentir et continue de ralentir. Quelle en est la raison ?

À ce stade, vous devez vérifier si la bande passante réseau de la machine Redis est surchargée et s'il existe une instance qui remplit la bande passante réseau de l'ensemble de la machine.

Raisons du ralentissement
Lorsque la bande passante du réseau est surchargée, le serveur connaîtra des retards d'envoi de paquets, des pertes de paquets, etc. au niveau de la couche TCP et de la couche réseau.

Les hautes performances de Redis, en plus de la mémoire de fonctionnement, résident dans les E/S du réseau. S'il y a un goulot d'étranglement dans les E/S du réseau, cela affectera également sérieusement les performances de Redis.

Solution
Confirmez en temps opportun que l'instance Redis a occupé toute la bande passante du réseau. S'il s'agit d'un accès professionnel normal, vous devez étendre ou migrer l'instance à temps pour éviter d'affecter d'autres instances de cette machine en raison d'un excès. trafic de cette instance.
- Au niveau de l'exploitation et de la maintenance, vous devez augmenter la surveillance de divers indicateurs de la machine Redis, y compris le trafic réseau lorsque le trafic réseau atteint un certain seuil, une alarme préalable, une confirmation et une expansion en temps opportun.
- Raison 5 : Autres raisons
1) Connexions courtes et fréquentes
Votre application métier doit utiliser des connexions longues pour faire fonctionner Redis afin d'éviter les connexions courtes fréquentes.

Les connexions courtes et fréquentes obligeront Redis à passer beaucoup de temps à établir et à libérer les connexions. La poignée de main à trois voies et la vague à quatre voies de TCP augmenteront également les délais d'accès.

2) Surveillance du fonctionnement et de la maintenance
J'ai également mentionné auparavant que si vous souhaitez prévoir le ralentissement de Redis à l'avance, il est essentiel de faire un bon travail de surveillance.

La surveillance est en fait la collecte de divers indicateurs d'exécution de Redis. L'approche habituelle consiste pour le programme de surveillance à collecter régulièrement les informations INFO de Redis, puis à effectuer un affichage des données et une alarme en fonction des données d'état contenues dans les informations INFO.

Ce que je dois vous rappeler ici, c'est que vous ne pouvez pas le prendre à la légère lorsque vous écrivez des scripts de surveillance ou utilisez des composants de surveillance open source.

Lorsque vous écrivez des scripts de surveillance pour accéder à Redis, essayez d'utiliser des connexions longues pour collecter des informations d'état afin d'éviter des connexions courtes et fréquentes. Dans le même temps, vous devez également veiller à contrôler la fréquence d'accès à Redis pour éviter d'affecter les demandes commerciales.

Lors de l'utilisation de certains composants de surveillance open source, il est préférable de comprendre les principes de mise en œuvre de ces composants et de configurer ces composants correctement pour éviter les bogues dans les composants de surveillance, entraînant un grand nombre d'opérations Redis dans un court laps de temps et affectant les performances de Redis.

Il nous est arrivé à cette époque que lorsque le DBA utilisait certains composants open source, en raison de problèmes de configuration et d'utilisation, le programme de surveillance s'établissait et se déconnectait fréquemment de Redis, ce qui entraînait une réponse lente de Redis.

3) D'autres programmes se disputent les ressources

Enfin, je dois vous rappeler que votre machine Redis est mieux dédiée et utilisée uniquement pour déployer des instances Redis. Essayez de fournir un environnement relativement silencieux pour Redis. . » pour empêcher d’autres programmes d’occuper les ressources du processeur, de la mémoire et du disque, ce qui entraîne des ressources insuffisantes allouées à Redis.

Apprentissage recommandé : Tutoriel vidéo Redis