Maison > base de données > Redis > Parlons des potentiels points de blocage d'AOF dans Redis (résumé)

Parlons des potentiels points de blocage d'AOF dans Redis (résumé)

青灯夜游
Libérer: 2021-12-24 10:05:47
avant
1909 Les gens l'ont consulté

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 !

Parlons des potentiels points de blocage d'AOF dans Redis (résumé)

Quels sont les points de blocage potentiels d'AOF

1 Lorsque Redis utilise le sous-processus fork pour réécrire les fichiers AOF, il existe un risque potentiel de blocage

1), sous-processus fork

.

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),

Scénario dans lequel le processus parent écrit pendant la réécriture AOFLe processus enfant fork pointe vers le même espace d'adressage mémoire que le processus parent. À ce stade, le processus enfant peut effectuer une réécriture AOF et modifier le. mémoire Toutes les données sont écrites dans le fichier AOF.

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.

Deuxièmement, si le processus de réécriture AOF échoue, alors le fichier AOF original équivaut à être contaminé et ne peut pas être restauré et utilisé. Par conséquent, Redis AOF réécrit un nouveau fichier si la réécriture échoue, supprimez simplement le fichier directement. Cela n'affectera pas le fichier AOF d'origine. Une fois la réécriture terminée, remplacez simplement l'ancien fichier.

  • Pour plus de connaissances sur la programmation, veuillez visiter :

    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!

Étiquettes associées:
source:juejin.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal