Série incontournable sur les bases de données : outils de surveillance et de réglage des performances des bases de données

Auteur : Zen et l'art de la programmation informatique

1. Introduction générale

En tant que technicien supérieur, nous devons comprendre de quels indicateurs de performance, outils et techniques nous avons besoin dans notre travail pour mieux contrôler l'entreprise et améliorer la qualité du service. Alors, comment pouvons-nous surveiller, analyser et optimiser efficacement les performances des bases de données ? Cet article présentera les outils de surveillance et de réglage des performances des bases de données sous les aspects suivants :

  1. Analyse et ajustement des paramètres de configuration

  2. Analyse et optimisation des journaux lents SQL

  3. Analyse statistique des requêtes lentes

  4. Analyse du comportement de l'optimiseur de requêtes

  5. Recommandation et construction des index InnoDB et MyISAM

  6. Analyse du taux de réussite du cache

  7. Analyse de la distribution des tableaux de données

  8. Analyse TPS/QPS et consommation de ressources

  9. Stratégie de sauvegarde et sélection des outils

  10. Introduction aux principaux outils d'optimisation des performances des bases de données open source

2. Concepts de base et connexions

Tout d’abord, nous introduisons quelques concepts et noms de base liés aux bases de données pour aider les lecteurs à comprendre les concepts et les méthodes des outils de surveillance des performances des bases de données.

  1. CPU : désigne le processeur d'un ordinateur, qui est responsable de l'exécution des instructions du programme.

  2. QPS (Queries Per Second) : c'est le nombre de requêtes auxquelles le serveur peut répondre par seconde. Il est généralement utilisé dans les applications Web. Le résultat est le nombre de requêtes divisé par le temps de réponse du serveur, qui reflète la capacité de charge du site Web. .

  3. QPM (Queries Per Minute) : nombre de requêtes auxquelles le serveur répond par minute.

  4. RPS (Requests Per Second) : Le nombre de requêtes que le serveur peut recevoir par seconde.

  5. RPM (Requests Per Minute) : Le nombre de requêtes reçues par le serveur par minute.

  6. TPS (Transactions par seconde) : Le nombre de fois qu'une transaction est effectuée par seconde.

  7. TPMS (Transaction Per Minute) : Le nombre de transactions effectuées par minute.

  8. Utilisation du processeur : l'utilisation du processeur fait référence à la proportion de temps pendant lequel le processeur traite les tâches par unité de temps.

  9. Attente IO : temps d'attente des E/S, qui fait référence au temps pendant lequel le processeur attend les demandes d'E/S pour suspendre le fonctionnement.

  10. Changement de contexte : le changement de contexte signifie que le processeur s'exécute dans le processus de premier plan et passe au processus d'arrière-plan, ou vice versa.

  11. Connexions : nombre de connexions, qui fait référence au nombre de connexions actuellement utilisées par le serveur.

  12. Threads : nombre de threads, fait référence au nombre de threads actuellement utilisés par le serveur.

  13. Pool de tampons : le pool de tampons est un tampon utilisé pour stocker les données dans la mémoire de l'ordinateur et est utilisé pour mettre en cache l'accès aux données.

  14. Échange : l'échange de pages signifie que lorsque la mémoire physique du système est limitée, certaines pages de mémoire virtuelle temporairement stockées sur le disque sont stockées dans la mémoire, ce qu'on appelle l'échange de pages.

  15. Taille de l'index : la taille de l'index fait référence à la taille du fichier d'index créé dans la table de base de données.

  16. Taux d'accès à l'index : le taux d'accès à l'index fait référence au rapport entre le nombre de fois où le fichier d'index est lu et le nombre total d'analyses d'index.

  17. Analyse du comportement de l'optimiseur de requêtes : analyse du comportement de l'optimiseur de requêtes, obtenant le comportement généré par l'optimiseur de requêtes de base de données lors de l'exécution d'une instruction SQL spécifique via des journaux ou d'autres méthodes, par exemple s'il faut choisir une analyse d'index ou une analyse de table complète, s'il faut activer les index et d'autres informations, afin de déterminer si la requête existe Problèmes d'efficacité.

  18. Attendre un événement : l'attente d'un événement est un processus consistant à attendre qu'une condition spécifique se produise.

  19. Verrous : verrouillage, un mécanisme de synchronisation utilisé pour empêcher l'accès aux ressources de la base de données par plusieurs transactions simultanées en même temps.

  20. Journal des requêtes lentes MySQL : journal des requêtes lentes MySQL, qui enregistre les instructions de requête dans MySQL dont la durée d'exécution dépasse le seuil et est utilisé pour localiser le goulot d'étranglement des performances de la base de données.

  21. Outil de surveillance : outil de surveillance, utilisé pour collecter, analyser et afficher divers indicateurs de performances du serveur, tels que l'utilisation du processeur, le temps de réponse aux demandes d'E/S, le nombre de connexions, le TPS, etc., afin que les administrateurs puissent surveiller l'état d'exécution de base de données. Surveillance et gestion en temps réel.

  22. Profileur : profileur de performances, qui peut compter le temps, la mémoire et les informations d'appel de fonction occupées par le code lors de son exécution.

  23. Requêtes lentes : les requêtes lentes font référence aux requêtes dont le temps d'exécution dépasse un certain seuil (par exemple 1 seconde).

  24. Outils de profilage de base de données : outils de profilage des performances de la base de données, tels que Show Profile, pt-query-digest, sysbench, etc. fournis par MySQL. Ils peuvent collecter des informations sur les performances de la base de données, telles que les demandes d'E/S, les délais de requête et les conflits de verrouillage, via des journaux. compteurs de performances, etc. Utilisez wait.

  25. Schéma de performances : le schéma de performances fournit une interface unifiée pour collecter les données de performances de divers modules de MySQL, y compris les variables d'état du serveur, les métadonnées, les informations de verrouillage, les statistiques d'index, etc.

3. Explication détaillée des principes de base de l'algorithme, des étapes de fonctionnement spécifiques et des formules de modèles mathématiques

(1) Analyse et ajustement des paramètres de configuration

Les paramètres clés qui affectent les performances de la base de données se trouvent généralement dans le fichier de configuration mysqld.cnf, notamment innodb_buffer_pool_size, innodb_log_file_size, innodb_thread_concurrency, etc. Parmi eux, innodb_buffer_pool_size est le paramètre le plus important. Une valeur trop petite peut entraîner une faible efficacité des requêtes de données. Une valeur trop grande peut entraîner une consommation excessive de mémoire et même provoquer un temps d'arrêt du système ; innodb_log_file_size est utilisé pour contrôler la taille du journal des transactions. la valeur par défaut est 5M, une valeur trop petite peut entraîner un échec de soumission de transaction ou un crash du serveur, une valeur trop grande peut affecter la capacité du disque du serveur ; innodb_thread_concurrency est utilisé pour contrôler le nombre de threads simultanés lorsqu'InnoDB effectue des opérations d'écriture, la valeur par défaut est 8. Par conséquent, il est recommandé d'ajuster les paramètres en fonction de l'environnement réel et de surveiller et d'alarmer les paramètres importants.

(2) Analyse et optimisation des journaux lents SQL

Le journal des requêtes lentes enregistre les instructions SQL dans la base de données dont la durée d'exécution dépasse le seuil. Il s'agit généralement d'un problème que les développeurs ignorent souvent. L'analyse et l'optimisation du journal des requêtes lentes peuvent révéler certains goulots d'étranglement potentiels en termes de performances. Tout d'abord, vérifiez le journal SQL lent via la commande SHOW warns. S'il y a des invites de requête lentes, vous pouvez vérifier davantage l'analyseur de performances de MySQL (tel que pt-query-digest, sysbench) pour obtenir des informations plus détaillées ; deuxièmement, pour la requête lente L'analyse des journaux révèle que pour les instructions SQL, vous pouvez d'abord vérifier s'il y a des erreurs de syntaxe dans l'instruction et s'il y a des problèmes avec le plan de requête, puis essayer d'utiliser EXPLAIN pour analyser l'instruction SQL ou optimiser le plan de requête. S'il y a effectivement une surcharge de performances importante, vous pouvez également envisager d'optimiser ou de diviser la requête du côté métier.

(3) Analyse statistique des requêtes lentes

L'analyse des statistiques des requêtes lentes est basée sur l'analyse statistique des journaux historiques des requêtes lentes. Elle collecte des informations telles que la fréquence d'exécution et le temps d'exécution moyen de différentes instructions SQL selon une certaine plage de temps, découvrant ainsi les points chauds et les anomalies dans les requêtes lentes. L'analyse statistique des requêtes lentes comprend généralement les étapes suivantes :

  1. Obtenir des journaux de requêtes lentes : MySQL propose deux manières d'obtenir des journaux de requêtes lentes, l'une via des fichiers journaux et l'autre via des outils de surveillance des requêtes lentes.

  2. Analyser les journaux de requêtes lentes : analysez les journaux de requêtes lentes, extrayez les instructions SQL, le temps d'exécution, l'adresse IP du client et d'autres informations, et analysez ces informations pour trouver les instructions SQL les plus chronophages, telles que le temps d'exécution moyen, la fréquence d'exécution, etc.

  3. Classer et compter les requêtes lentes : classez et comptez les requêtes lentes par type, fréquence, degré d'impact, etc., et recherchez les requêtes lentes courantes et spécifiques, telles que le SQL de longue durée, le SQL haute fréquence et les requêtes lentes. Proportion, etc.

  4. Générer des rapports : générez des rapports, tels que des rapports HTML, des tableaux Excel, etc., pour afficher les résultats statistiques des requêtes lentes et évaluer les goulots d'étranglement des performances du système et les orientations d'optimisation SQL.

(4) Analyse du comportement de l'optimiseur de requêtes

L'analyse du comportement de l'optimiseur de requêtes fait référence à l'obtention du comportement généré par l'optimiseur de requêtes de base de données lors de l'exécution d'instructions SQL spécifiques via des journaux ou d'autres méthodes, et à l'analyse de ses index sélectionnés, méthodes d'analyse, retours de table, etc., pour déterminer s'il existe des problèmes d'efficacité dans le requête. MySQL fournit des outils d'analyse du comportement de l'optimiseur de requêtes pt-query-digest et sysbench, qui peuvent fournir des informations détaillées sur l'exécution des instructions SQL, telles que l'analyse d'index, l'analyse complète de la table, le retour de la table, etc.

(5) Recommandation et construction des index InnoDB et MyISAM

Dans un environnement de production réel, le choix de MyISAM et InnoDB doit être déterminé en fonction de scénarios spécifiques et après avoir analysé des facteurs tels que le mode de lecture et d'écriture de la base de données, la taille de la table, la longueur du champ, la sélection des colonnes d'index et la complexité des requêtes.

  1. MyISAM convient aux tables avec un petit volume de données et une insertion intensive.

  2. InnoDB convient aux gros volumes de données et aux tables nécessitant beaucoup de mises à jour.

  3. Lors du choix d'un moteur de table, il est recommandé de donner la priorité à InnoDB, qui prend en charge les transactions.

  4. Lorsque InnoDB sélectionne un index, il doit sélectionner le type d'index correspondant en fonction de la nature de l'index et de la fréquence des requêtes.

  5. Lors de la création d'un index, vous devez sélectionner des colonnes d'index de couverture et des combinaisons de colonnes d'index en fonction des besoins de l'entreprise.

  6. Pour les tables de données fréquemment mises à jour, vous pouvez utiliser MyISAM au lieu d'InnoDB.

  7. Pour un grand nombre de tables de données, vous devez transférer progressivement de MyISAM vers InnoDB pour éviter la pression d'écriture sur la base de données principale via le mécanisme de verrouillage.

  8. N'utilisez pas la table SELECT * FROM pour éviter de générer un grand nombre de paquets réseau invalides et une consommation de mémoire.

  9. N'incluez pas de conditions de plage dans les index d'union, car cela entraînerait des conversions implicites.

(6) Analyse du taux de réussite du cache

Le taux d'accès au cache mesure le rapport entre les requêtes de requêtes et le nombre d'accès au cache, c'est-à-dire le taux d'accès au cache = nombre d'accès/nombre de requêtes. Plus le taux d'accès au cache est élevé, moins il y a d'accès au cache et plus l'efficacité du cache est élevée. D'une manière générale, un taux de réussite du cache supérieur à 90 % est le meilleur état. Lorsqu'il est inférieur à 50 %, une planification du cache ou une maintenance d'invalidation du cache est requise.

(7) Analyse de la distribution des tableaux de données

L'analyse de la distribution des tables de données fait référence à la plage de distribution des données, aux règles de distribution, etc. de la table de base de données. La distribution des données peut être divisée dans les catégories suivantes :

  1. Partitionnement horizontal : le fractionnement horizontal consiste à diviser les mêmes données structurées en plusieurs sous-tables en fonction d'une certaine dimension (telle que la date, la région, l'ID utilisateur, etc.), et chaque sous-table contient uniquement les données d'une certaine partition.

  2. Partitionnement vertical : le fractionnement vertical consiste à diviser le tableau en plusieurs sous-tableaux selon les fonctions, les sujets, les sources de données, etc.

  3. Partitionnement hybride : le fractionnement hybride est une table qui comporte à la fois un fractionnement horizontal et un fractionnement vertical, c'est-à-dire une combinaison des deux.

  4. Table distribuée : une table distribuée fait référence à une table stockée sur plusieurs serveurs de base de données. Étant donné que les tables distribuées sont réparties sur différents serveurs, elles ne peuvent pas utiliser l'index global de la base de données, mais elles peuvent réduire la surcharge du réseau lors des opérations entre tables.

(8) TPS/QPS et analyse de la consommation des ressources

TPS (Transaction par seconde) est le nombre de transactions traitées par seconde, c'est-à-dire le débit de la base de données. QPS (Query per second) est le nombre de requêtes envoyées par seconde, qui est déterminé par les performances matérielles du serveur de base de données. TPS et QPS sont tous deux des indicateurs importants pour mesurer les capacités de traitement de la base de données. La consommation de ressources comprend principalement le processeur, la mémoire, la bande passante du réseau, l'espace disque, etc. L'analyse de la consommation des ressources consiste à analyser la consommation des ressources, à déterminer l'état d'exécution de la base de données et à allouer les ressources du serveur en fonction des besoins de l'entreprise.

(9) Stratégie de sauvegarde et sélection des outils

La stratégie de sauvegarde détermine la sécurité et la disponibilité des données. Sans sauvegarde, il existe un risque de perte de données. Lorsque vous choisissez un outil de sauvegarde, vous devez choisir des outils de sauvegarde régulière, de sauvegarde différentielle ou de sauvegarde incrémentielle en fonction du volume d'activité et de la fréquence de sauvegarde. La méthode de sauvegarde régulière peut conserver un instantané de l'intégralité de la base de données et effectuer des sauvegardes régulières, ce qui peut garantir l'intégrité et la disponibilité des données, mais elle nécessite beaucoup d'espace disque ; la sauvegarde différentielle utilise une méthode incrémentielle pour comparer la sauvegarde la plus récente. , et enregistre uniquement les parties modifiées des données. Il peut économiser de l'espace disque, mais il ne peut pas garantir l'intégrité et la disponibilité des données ; la sauvegarde incrémentielle est effectuée sur la base d'une sauvegarde régulière et sauvegarde uniquement les données mises à jour, économisant ainsi du temps et de l'espace de sauvegarde. , mais il ne peut toujours pas garantir pleinement l’intégrité et la disponibilité des données. Lors du choix d'un outil de sauvegarde, vous devez également faire attention aux exigences d'autorisation du logiciel. Certains logiciels gratuits ont une période d'autorisation plus courte, mais les fonctions fournies sont également limitées ; la période d'autorisation des logiciels payants est généralement plus longue, mais le support des fonctions acheté est plus riche et la garantie de performance fournie est plus fiable.

(10) Introduction aux principaux outils de réglage des performances des bases de données open source

Actuellement, les principaux outils d'optimisation des performances des bases de données open source incluent :

  1. mytop : Un outil en temps réel pour surveiller les performances du serveur MySQL.

  2. pt-query-digest : un outil qui fournit une analyse du comportement de l'optimiseur de requêtes MySQL.

  3. sysbench : fournit une variété d'outils de test de charge de base de données, y compris les tests TPS.

  4. innotop : Un outil pour surveiller l'état d'exécution d'InnoDB.

  5. mysqltuner : un outil qui fournit des suggestions d'optimisation de base de données et une analyse des performances.

Guess you like

Origin blog.csdn.net/universsky2015/article/details/133594441