Maison > Article > base de données > Parlons des potentiels points de blocage d’AOF dans Redis (résumé)
Quels sont les points bloquants potentiels de l’AOF ? L'article suivant résume quelques points de blocage potentiels d'AOF dans Redis. J'espère qu'il vous sera utile !
1 Lorsque Redis utilise le sous-processus fork pour réécrire les fichiers AOF, il existe un risque potentiel de blocage
Sous-processus fork, le moment du fork bloquera définitivement le thread principal (notez que toutes les données de la mémoire ne seront pas copiées dans le processus enfant en même temps pendant le fork Fork utilise le mécanisme de copie lors de l'écriture fourni par le système d'exploitation). pour éviter une copie unique, la copie d'une grande quantité de données de mémoire entraîne des problèmes de blocage à long terme pour les processus enfants. [Recommandation associée : Tutoriel vidéo Redis]
Mais le processus enfant fork doit copier les structures de données nécessaires du processus. L'une d'elles consiste à copier la table des pages mémoire (la table d'index de mappage de la mémoire virtuelle et de la mémoire physique. ). Ce processus de copie consomme beaucoup de ressources CPU. L'ensemble du processus sera bloqué avant la fin de la copie. Le temps de blocage dépend de la taille de la mémoire de l'instance entière. Plus l'instance est grande, plus la table des pages mémoire est grande. , et plus le temps de blocage de la fourche sera long. Après avoir copié la table des pages mémoire, le processus enfant et le processus parent pointent vers le même espace d'adressage mémoire, c'est-à-dire que bien que le processus enfant soit généré à ce moment-là, il ne s'applique pas à la même taille de mémoire que le processus enfant. processus parent.
Alors, quand la mémoire des processus père et fils sera-t-elle véritablement séparée ?
Comme son nom l'indique, « copie réaliste » signifie que les données réelles dans la mémoire sont réellement copiées lors de l'écriture. Au cours de ce processus, le processus parent peut également risquer de se bloquer, ce qui est le scénario décrit ci-dessous.
2),Mais le processus parent aura toujours du trafic écrit à ce moment-là. Si le processus parent exploite une clé existante, alors à ce moment-là, le processus parent copiera en fait les données de mémoire correspondant à la clé et demandera un nouvel espace mémoire. Ainsi, progressivement, les données de mémoire des processus père et fils commencent à se séparer, et les processus père et fils ont progressivement leurs propres espaces mémoire indépendants. Étant donné que l'allocation de mémoire est allouée en unités de pages, la valeur par défaut est 4 Ko. Si le processus parent utilise une grande clé à ce moment-là, il faudra plus de temps pour réappliquer un bloc de mémoire volumineux, ce qui peut entraîner un risque de blocage.
De plus, si le système d'exploitation active le
Mécanisme Huge Page (taille de page 2M), alors la probabilité que le processus parent soit bloqué lors de la demande de mémoire sera considérablement augmentée, le mécanisme Huge Page doit donc être activé désactivé sur la machine Redis. Chaque fois que Redis lance la génération de réécriture RDB ou AOF, vous pouvez voir dans le journal Redis la quantité d'espace mémoire pour laquelle le processus parent a réappliqué.
3) Pourquoi la réécriture d'AOF ne réutilise-t-elle pas ses propres logs ? problèmes. Contrôler les conflits signifie affecter les performances du processus parent.Vidéo de programmation
! !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!