[Base de données MySQL] Interprétation du chapitre 3 : Analyse des performances du serveur (Partie 2)

Laissez-moi soupirer d'émotion : DBA n'est vraiment pas couvert

3.3.3 Analyse des performances d'utilisation : limitée

3.4 Diagnostic des problèmes intermittents

Si le système s'arrête occasionnellement, ralentit les requêtes ou provoque des problèmes d'observation, essayez de ne pas recourir aux essais et aux erreurs pour résoudre le problème : le risque est élevé

3.4.1 Problème de requête unique ou problème de service

Utilisez SHOW GLOBAL STATUS

Fréquence plus élevée : 1 s/heure Exécutez cette commande pour obtenir des données. Le problème se produit via le compteur

Utilisez SHOW PROCESSLIST [Référence] Afficher quels threads sont en cours d'exécution

Utilisez le journal des requêtes

pour activer les requêtes lentes, définissez le long_query_time global = 0 et confirmez que toutes les connexions adoptent les nouveaux paramètres (vous devrez peut-être réinitialiser toutes les connexions prennent effet)

Faites attention aux journaux pendant la période où le débit chute soudainement. La requête est écrite dans le journal des requêtes lentes pendant la phase d'achèvement

Les bons outils obtiennent deux fois plus. résultat avec moitié moins d'effort : tcpdump, pt-query-digest, Percona Server

Comprendre les problèmes rencontrés

Visualiser les données : gnuplot /R (outil de dessin)

gnuplot :

Installation Quelques commandes : Conseils courants Tutoriel de démarrage 2 Visualisation des données Gnuplot

Recommandation : Utilisez d'abord les deux premières méthodes, qui sont peu coûteuses et collectent des données de manière interactive via de simples scripts shell ou exécutées à plusieurs reprises requêtes

3.4.2 Obtenir des données de diagnostic

Problème intermittent, essayez de collecter autant de données que possible (pas seulement lorsque le problème survient)

Clair : 1. Il y a façons de distinguer quand des problèmes surviennent : déclencheurs ; 2. Outils de collecte de données de diagnostic

Déclencheur de diagnostic

Erreur : De nombreuses données de diagnostic sont collectées pendant la période où aucun problème ne se produit, ce qui est un perte de temps (cela n'est pas incompatible avec le précédent, lisez-le attentivement)

Détection manquée : Lorsque le problème survient Aucune donnée n'a été capturée, une opportunité a été manquée, assurez-vous que le déclencheur peut véritablement identifier le problème avant démarrage de la collecte

Bons déclencheurs :

Trouvez-en qui fonctionnent bien avec les horaires normaux Comparez les indicateurs avec les seuils

Choisissez un seuil approprié : assez élevé (pas déclenché lorsque c'est normal), pas trop élevé (à ne pas manquer lorsque des problèmes surviennent)

Outil recommandé pt-stalk【 Référence] [2] Déclencheur, réglé sur une certaine condition pour enregistrer la fréquence de vérification du seuil des variables à surveillé et configuré

Quel type de données sont collectées

Délai d'exécution : Temps de travail et temps d'attente

Collecter toutes les données qui peuvent être collecté dans le délai requis

La raison du problème inconnu  : 1 , le serveur doit faire beaucoup de travail, ce qui entraîne une grande consommation de CPU 2 ; . En attente de libération des ressources

Collectez les données de diagnostic en utilisant différentes méthodes pour confirmer la raison :

1 Rapport d'analyse : confirmez s'il y a trop de travail, outil : tcpdump surveille l'ouverture du mode de trafic TCP et. fermeture, journal des requêtes lent

2. Analyse d'attente : confirmer s'il y a un grand nombre d'attentes, informations de trace de la pile GDB, afficher la liste des processus, afficher l'état d'innodb pour observer les threads et l'état de la transaction

Interpréter les données de résultat

Objectif : 1. Si le problème s'est réellement produit ; 2. S'il y a un changement de saut évident

Outils :

oprofile utilise le compteur de performances (compteur de performances) fourni au niveau matériel du processeur pour nous aider à trouver le "coupable" qui occupe le processeur aux niveaux du processus, de la fonction et du code grâce à l'échantillonnage de comptage. Exemple [Référence]

La commande opreport est une méthode permettant d'afficher l'utilisation du processeur à partir des niveaux de processus et de fonction respectivement

 samples |                            %|
-----------------------------------------------------
     镜像内发生的采样次数     采样次数所占总采样次数的百分比      镜像名称

La commande opannotate peut afficher les informations statistiques sur l'utilisation du processeur au niveau niveau de code

GDB :Dans le développement d'applications Linux, le débogueur le plus couramment utilisé est gdb (l'objet débogué est un fichier exécutable). Il peut définir des points d'arrêt dans le programme, afficher les valeurs des variables, et suivez le programme étape par étape Processus d'exécution (données, code source), affichez la mémoire, empilez les informations. L'utilisation de ces fonctions du débogueur permet de trouver facilement des erreurs non grammaticales dans le programme. [Référence] [Référence] Syntaxe et exemples

3.4.3 Un cas de diagnostic

Problème de performances intermittent, avec une connaissance pertinente de MySQL, innodb, GNU/Linux

Clair : 1. Quel est le problème, décrivez-le clairement ; 2. Quelles mesures ont été prises pour résoudre le problème ?

Démarrer : 1. Comprendre le comportement du serveur ; 2. Trier les paramètres d'état du serveur et configurer l'environnement logiciel et matériel (pt-summary pt-mysql -résumé)

Ne vous laissez pas distraire par diverses situations trop hors sujet Écrivez les questions sur des bouts de papier et vérifiez bien les rayer

Est-ce une cause ou un résultat. ? ? ?

Raisons possibles pour lesquelles les ressources sont devenues inefficaces :

1. Les ressources sont surutilisées et le solde est insuffisant ; 2. Les ressources ne sont pas correctement adaptées ; Ressources Dommages ou pannes

3.5 Autres outils d'analyse

USER_STATISTICS : certaines tables mesurent et auditent les activités de la base de données

strace : enquêter sur les appels système, utiliser le temps réel , imprévisibilité, surcharge,

oprofile coûts d'utilisation des cycles CPU

Résumé :

• Le moyen le plus efficace de définir les performances est le temps de réponse

• Vous ne pouvez pas optimiser efficacement si vous ne pouvez pas le mesurer. Le travail d'optimisation des performances doit être basé sur une mesure du temps de réponse de haute qualité, complète et complète

• Le Le meilleur point de départ pour la mesure est une application. Même si le problème réside dans la base de données sous-jacente, il est plus facile de trouver le problème avec de bonnes mesures

• La plupart des systèmes ne peuvent pas mesurer complètement, et parfois les mesures avoir des résultats erronés. Trouvez des moyens de contourner certaines limitations et soyez conscient des défauts et des incertitudes de la méthode

• Une mesure complète générera une grande quantité de données qui doivent être analysées, donc vous devez utiliser un profileur (meilleur outil)

• Rapport de profilage : résume les informations, passe sous silence et jette beaucoup de détails, ne vous dira pas ce qui manque, ne peut pas être s'appuie totalement

• Deux opérations chronophages : travailler ou attendre Presque le profileur ne peut mesurer que le temps passé au travail, donc attendre le partage est parfois un complément utile, surtout quand le. L'utilisation du processeur est faible mais le travail n'a jamais été terminé.

• L'optimisation et l'amélioration sont deux choses différentes. Lorsque le coût de l'amélioration continue dépasse les avantages, l'optimisation doit être arrêtée

  <.>
• Faites attention à votre franchise, vos idées et vos décisions autant que possible. Basé sur les données

en un mot :Clarifiez d'abord le problème, choisir la technologie appropriée, faire bon usage des outils, être assez prudent, avoir une logique claire et s'y tenir, ne pas mettre les raisons et les résultats Confusion, ne pas apporter de modifications au système avec désinvolture avant de déterminer le problème

Articles connexes :

[Base de données MySQL] Interprétation du chapitre 2 : Test de référence MySQL

[Base de données MySQL] Interprétation du chapitre 3 : Analyse des performances du serveur (Partie 1)

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!