Redis Getting started tutoriel complet: positionnement et optimisation des problèmes

RedisLa persistance a toujours été un impactRedisLieu de haute performance,Cette section combine les
Problèmes de persistance pour l'analyse, le positionnement et l'optimisation.

5.3.1　forkFonctionnement
QuandRedisFais - le.RDBOuAOFLors de la réécriture,Une opération essentielle est d'effectuerforkOpération
Sous - processus de construction,Pour la plupart des systèmes d'exploitationforkC'est une erreur lourde.Bien queforkCréé
Le processus enfant n'a pas besoin d'espace mémoire physique pour copier le processus parent,Mais la page Mémoire spatiale du processus parent est copiée
Tableau.Par exemple, pour10GBDeRedisProcessus,Besoin de copier environ20MBTable des pages de mémoire pour,Donc,fork
Le temps de fonctionnement dépend de la quantité totale de mémoire du processus,Si vous utilisez la technologie de virtualisation,En particulierXenVirtuel
Machine,forkL'opération prendra plus de temps.
forkLocalisation des problèmes de temps：Pour un débit élevéRedisExempleOPSAccessibilité5Plus de 10 000,Sifork
Le temps de fonctionnement ralentira au niveau des secondesRedisDes dizaines de milliers de commandes sont exécutées,L'effet de retard sur l'application en ligne est très
C'est évident..Dans des conditions normalesforkÇa devrait prendre du temps pour chaqueGBConsommation20Milliseconde environ.Ça pourrait être dansinfo statsStatistiques
Vérification en cours de calcullatest_fork_usecDernière acquisition de l'indicateurforkTemps de fonctionnement,Unités microsecondes.
Comment améliorerforkLe temps de fonctionnement：
1）Priorité à l'utilisation de machines physiques ou à un soutien efficaceforkVirtualisation des opérations,Ne pas utiliser
Xen.
2）ContrôleRedisMémoire maximale disponible par instance,forkLe temps est proportionnel à la quantité de mémoire, Conseils en ligne
ChaqueRedisLa mémoire d'instance est contrôlée dans10GBÀ l'intérieur.
3）Configuration rationnelleLinuxPolitique d'allocation de mémoire,Évitez de manquer de mémoire physiqueforkÉchec,Avec
Pour plus de détails, voir 12.1Section“LinuxOptimisation de la configuration”.
4）RéductionforkFréquence des opérations,Si elle est légèrement assouplieAOFTemps de déclenchement automatique,Évitez les inutiles
Copie complète, etc .

5.3.2　 Surveillance et optimisation des frais généraux des sous - processus
Le Sous - processus est responsable de AOFOuRDBRéécriture du fichier, Son fonctionnement implique principalement CPU、Intérieur
Dépôt、 Consommation de trois parties du disque dur .
1.CPU
·CPUAnalyse des frais généraux.Le Sous - processus est responsable de l'écriture des données dans le processus par lots dans le fichier,Ce processus
DeCPUOpérations intensives,En général, les sous - processus sont jumelés à un seul noyauCPUUtilisation proche de90%.
·CPUOptimisation de la consommation.Redis- Oui.CPUServices intensifs,Ne pas faire de noyau de liaisonCPUFonctionnement.
Parce que les sous - processus sont très consommablesCPU,Concurrence avec les ressources du noyau unique du processus parent.
Pas avec les autres.CPUServices intensifs déployés ensemble,CauseCPUConcurrence excessive.
Si plusieurs sont déployésRedisExemple, Essayez de vous assurer qu'un seul sous - processus effectue la réécriture en même temps
Le travail, Pour plus de détails, voir 5.4 Section déploiement Multi - instances ”.
2.Mémoire
·Analyse de la consommation de mémoire.Le Sous - processus passeforkProduction opérationnelle, La taille de la mémoire utilisée est égale à l'entrée du parent
Cheng, En théorie, il faut deux fois plus de mémoire pour effectuer une opération de persistance ,Mais...Linux Il y a un mécanisme de copie en écriture
（copy-on-write）.Les processus parent - enfant partagent la même page de mémoire physique, Lorsque le processus parent traite l'écriture
Une copie de la page à modifier est créée sur demande , Et le processus enfant est fork Partager l'ensemble du processus parent pendant l'opération
Snapshots de mémoire.
· Surveillance de la consommation de mémoire .RDBLors de la réécriture,Redis La sortie du journal est la suivante ：
* Background saving started by pid 7692
* DB saved on disk
* RDB: 5 MB of memory used by copy-on-write
* Background saving terminated with success
Si une opération de modification de mémoire existe pendant la réécriture , Le processus parent est responsable de la création d'une copie de la page mémoire modifiée
Ben, Comme vous pouvez le voir dans le Journal, cette partie de la mémoire est consommée 5MB, Peut être considéré comme équivalent à RDB Override Consumption
C'est5MBMémoire.
AOFLors de la réécriture,Redis La sortie du journal est la suivante ：
* Background append only file rewriting started by pid 8937
* AOF rewrite child asks to stop sending diffs.
* Parent agreed to stop sending diffs. Finalizing AOF...
* Concatenating 0.00 MB of AOF diff received from parent.
* SYNC append only file rewrite performed
* AOF rewrite: 53 MB of memory used by copy-on-write
* Background AOF rewrite terminated with success
* Residual parent diff successfully flushed to the rewritten AOF (1.49 MB)
* Background AOF rewrite finished successfully
La consommation de copie de la page de maintenance du processus parent est la même que RDB Le processus de réécriture est similaire à ,La différence est queAOF La réécriture nécessite
Oui.AOFOutrepasser le tampon, Par conséquent, la consommation de mémoire peut être estimée à ：
53MB+1.49MB,C'est - à - direAOF Quantité de mémoire consommée par le Sous - processus lors de la réécriture .
Conseils d'exploitation et d'entretien
CompilationshellScript basé surRedis Les journaux localisent rapidement la consommation excessive de mémoire lors de la réécriture du sous - processus
La situation.
Optimisation de la consommation de mémoire：
1）Même chose.CPUMême optimisation,Si plusieurs sont déployésRedisExemple, Essayez de vous assurer qu'il n'y a que
Un sous - processus fonctionne .
2）Évitez les réécritures de sous - processus lors d'un grand nombre d'écritures, Cela entraînera une maintenance importante du processus parent
Copie de la page ,Provoque une consommation de mémoire.
Linux kernelIn2.6.38Le noyau a été ajoutéTransparent Huge Pages（THP）,Soutien
huge page（2MB） Répartition des pages pour ,Par défaut. Il peut être abaissé lorsqu'il est allumé forkCréer un sous - processus
Vitesse,Mais la mise en œuvreforkAprès,Si onTHP, Copier l'unit é de page à partir de 4KBDevient
2MB,Augmente considérablement la consommation de mémoire du processus parent pendant la réécriture.Paramètres recommandés“sudo echo
never>/sys/kernel/mm/transparent_hugepage/enabled”FermerTHP.PlusTHPDétails
Et les configurations sont décrites dans 12.1SectionLinuxOptimisation de la configuration”.
3.Disque dur
· Analyse des frais généraux du disque dur . La responsabilité principale du sous - processus est de AOFOuRDB Fichier écrit sur le disque dur persistant
De. Il doit y avoir une pression d'écriture sur le disque dur .SelonRedisRéécritureAOF/RDBQuantité de données, Système combiné
Des outils commesar、iostat、iotopAttendez., Analyse de la charge du disque dur pendant la réécriture .
· Optimisation des frais généraux du disque dur .Les méthodes d'optimisation sont les suivantes:：
a）Ne pas déployer avec d'autres services à forte charge de disque dur.Par exemple:：Services de stockage、Équipe d'information
Services de colonnes, etc .
b）AOFLa réécriture consomme beaucoup de disques dursIO,La configuration peut être activéeno-appendfsync-on-
rewrite,Fermeture par défaut.Indique qu'il y aAOFNe pas faire pendant la réécriturefsyncFonctionnement.
c）Quand onAOFFonctionnelRedis Pour les scènes d'écriture à haut débit , Si des machines ordinaires sont utilisées
Disque, Le débit d'écriture est généralement 100MB/sGauche et droite,À ce moment - là,Redis Le goulot d'étranglement de l'Instance est principalement AOFSynchroniser
Sur le disque dur.
343
d） Plus d'une configuration autonome RedisCas d'instance, Vous pouvez configurer le stockage fractionné de différentes instances
AOFDocumentation, Répartition de la pression d'écriture du disque dur .
Conseils d'exploitation et d'entretien
Configurationno-appendfsync-on-rewrite=yesHeure, Dans des cas extrêmes, la totalité peut être perdue AOF
Données pendant la réécriture, La configuration doit être déterminée en fonction de la sécurité des données .

5.3.3　AOFAjouter un blocage
Quand onAOFLors de la persistance, La stratégie commune pour synchroniser les disques durs est everysec, Pour l'équilibre
Et la sécurité des données .De cette façon,Redis Exécuter toutes les secondes en utilisant un autre thread fsyncSynchroniser
Disque dur. Lorsque les ressources du disque dur du système sont occupées ,Peut causerRedisBlocage du fil principal,Comme le montre la figure5-5Comme indiqué.

 

  Analyse du processus de blocage ：
1） Le fil principal est responsable de l'écriture AOFTampon.
2）AOF Le thread est responsable de la synchronisation du disque une fois par seconde , Et enregistrer la dernière synchronisation
Chambre.
3） Le fil principal est responsable de la comparaison de la dernière AOFSynchronisation：
· Si la dernière synchronisation réussie a eu lieu à 2En quelques secondes,Retour direct du fil principal.
· Si le temps écoulé depuis la dernière synchronisation réussie dépasse 2Secondes, Le fil principal va bloquer , Jusqu'à ce que la synchronisation soit terminée
Oui..
Par la droiteAOF Deux problèmes peuvent être identifiés en bloquant le processus ：
1）everysec La configuration peut être perdue jusqu'à 2Secondes de données,Non, pas du tout.1Secondes.
2）Si le systèmefsyncDoucement.,Qui mènera àRedis Le blocage du fil principal affecte l'efficacité .
AOF Emplacement du problème de blocage ：
1）C'est arrivé.AOFEn cas de blocage,RedisSortie du Journal suivant,Pour l'enregistrementAOF fsyncLe blocage provoque
Ralentis.Redis Comportement du service ：
Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF buffer
without waiting for fsync to complete, this may slow down Redis
2）Chaque fois que cela se produitAOF Lorsque l'événement de blocage supplémentaire se produit ,Ininfo PersistenceStatistiques,
aof_delayed_fsync Les indicateurs s'additionnent , Voir cet indicateur pour un positionnement facile AOFProblème de blocage.
3）AOF Synchronisation autorisée jusqu'à 2Délai de quelques secondes, Lorsque le retard se produit, il y a un problème de charge élevée sur le disque dur
Questions, Des outils de surveillance tels que iotop, Localiser le disque dur consommable IOProcessus de ressources.
OptimisationAOF Le problème de blocage supplémentaire est principalement d'optimiser la charge du disque dur du système. , La méthode d'optimisation est décrite dans la section précédente .

5.4　Déploiement Multi - instances
Redis Architecture monothreadée entraînant une sous - utilisation CPUPropriétés multicentriques, La pratique habituelle est de
Déploiement de plusieurs machinesRedisExemple. Lorsque plusieurs instances sont activées AOFAprès réécriture, Entre nous, il y aura
Oui. CPUEtIODe la concurrence. Cette section se concentre sur l'analyse et l'optimisation de ce scénario .
La section précédente décrit les frais généraux des sous - processus liés à la persistance. . Pour une seule machine RedisDéploiement,Si
Exécuter plusieurs sous - processus en même temps , L'impact sur le système actuel sera très évident , Il est donc nécessaire d'adopter un
Mesures, Isoler les travaux des sous - processus .RedisIninfo Persistence Nous avons une surveillance
Mesures de la santé des sous - processus ,Comme indiqué dans le tableau5-2Comme indiqué.

Nous sommes basés sur les indicateurs ci - dessus , Peut être contrôlé par un programme externe AOF Exécution de l'opération de réécriture ,
L'ensemble du processus est illustré à la figure5-6Comme indiqué.

 

 Description du processus：
1） Machine de surveillance des sondages programmée par un programme externe （machine）Tous lesRedisExemple.
2）Pour ouvrirAOFExemples,Voir（aof_current_size-
aof_base_size）/aof_base_size Confirmer le taux de croissance .
3） Lorsque le taux de croissance dépasse un certain seuil （Par exemple:100%）,Mise en œuvrebgrewriteaofCommande déclenchée manuellement
De l'Instance actuelleAOFRéécriture.
4） Contrôle du cycle pendant le fonctionnement aof_rewrite_in_progressEt
aof_current_rewrite_time_secIndicateurs,Jusqu'àAOF Fin de la réécriture .
5）Exemple de confirmationAOFUne fois la réécriture terminée, Vérifiez les autres instances et répétez 2）~4）Marche à suivre.
Pour s'assurer que chaque RedisExempleAOF Outrepasser l'exécution de sérialisation .