Différences

Ci-dessous, les différences entre deux révisions de la page.

--- applications:cemu:mysql:debug [23/06/2020 14:00]
127.0.0.1 modification externe
+++ applications:cemu:mysql:debug [22/01/2024 09:23] (Version actuelle)
dumontj01 ↷ Page déplacée de moodle4_nouveautes:applications:cemu:mysql:debug à applications:cemu:mysql:debug
@@ Ligne 1: / Ligne 1: @@
-====== Surveillance du serveur MySQL ======
-===== Innodb status =====
-Executer
-<file sql>
-SHOW ENGINE INNODB STATUS\G
-</file>
-Surveillez notamment le //**Buffer pool hit rate**// qui, s'il est élevé (par exemple 999/1000), indique que mysql va majoritairement chercher ses données en mémoire plutôt que sur le disque.
-Pour plus de détails, voir
-  * https://www.rathishkumar.in/2017/01/how-to-allocate-innodb-buffer-pool-size-in-mysql.html
-  * http://mysqlopt.blogspot.com/2012/01/mysql-server-tuning.html
-===== Regarder les requêtes en cours d'exécution =====
-Pour demander à MySQL une liste des requêtes actuellement en cours d'exécution, on peut utiliser la requête :
-<file sql>
-show full processlist;
-</file>
-Inconvénient : On récupère un tableau de la situation à l'instant de la demande. On ne sait rien de ce qui s'est passé avant, ni de ce qui se passe après.
-<note tip>
-**EN CAS DE CRISE**, pour garder un historique complet des requêtes SQL en cours sur le serveur (sur bddmoodle pour l'instant), lancer :
-<file bash>
-. /root/check_serveur_bdd.sh
-</file>
-Ce script execute notamment les requêtes ci-dessous et stocke ces sorties dans un fichier texte daté (dans /root/) pour analyse ultérieure :
-<file SQL>
-SHOW full processlist
-SHOW ENGINE INNODB STATUS\G
-</file>
-</note>
-===== Regarder l'historique des requêtes les plus longues =====
-//(documenter la manière d'activer cette fonctionnalité...)//
-Le traçage exhaustif de ces requêtes suspectes se trouve dans le fichier de log :
-<file>
-/var/log/mysql/mysql-slow.log
-</file>
-Il concerne le jour courant. //logrotate// archive les logs des jours précédents dans les fichier //mysql-slow.log.n.gz// ('n' = itération)
-===== Traçage d'indicateurs =====
-Pour suivre l'évolution dans le temps de certains indicateurs clés, on peut ajouter une tache cron au serveur, avec //crontab -e// :
-<file>
-*/1 * * * * /root/check_serveur_bdd.sh
-</file>
-Dans le script //check_serveur_bdd.sh//, placer :
-<file bash>
-echo `date +"%d/%m/%Y %H:%M:%S"` = `mysql -u root -p<pw...> -h bddmoodle.unicaen.fr information_schema -BNe 'select count(*) from processlist'` >> nb_bdd_queries.log
-echo `date +"%d/%m/%Y %H:%M:%S"` = `mysql -u root -p<pw...> -h bddmoodle.unicaen.fr information_schema -BNe "show status like 'opened_files'"` >> nb_bdd_opened_files.log
-</file>
-//(avec **<pw...>** pour le mot de passe root du serveur mysql)//
-Ensuite les 2 fichiers générés (//nb_bdd_....log//) peuvent être
-  * soit regardé sur place, par exemple avec
-<file bash>
-tail nb_bdd_*
-</file>
-<note>
-On attend un nombre de requêtes aux environ de 50. Le nombre de fichiers ouverts, lui, est cumulatif, donc il augmente sans cesse. Ce qui nous intéresse est la vitesse à laquelle il augmente (actuellement est sur un rythme d'environ 14000 en 5 minutes)
-</note>
-  * soit récupérés (par exemple sur un poste de travail via un //scp//) et ouverts dans Libre Office Calc (ajouter '//**=**//' comme séparateur de champs au moment de l'ouverture) pour faire l'objet de graphiques.
-===== Regarder en temps réel les requêtes s'exécuter =====
-Pour surveiller en temps réel l'activité du serveur MySQL, et voir chaque nouvelle requête qui lui est  demandée, il faut configurer le serveur MySQL pour avoir ces informations dans une sortie de log verbeuse.
-  * Avantage : temps réel
-  * Inconvénients :
-    * nécessite un redémarrage de MySQL pour la prise en compte du changement de config.
-    * c'est très verbeux et peu vite devenir illisible
-    * génère potentiellement de très gros fichier de log
-    * impact sur les performances ?
-(voir [[https://dev.mysql.com/doc/refman/8.0/en/query-log.html|la doc MySQL officielle]])
-<note>
-Ce qui est expliqué ici concerne MySQL version > 5.1.29 (avant c'était d'autres options de config.)
-</note>
-On peut agir sur le fichier de configuration de mysql (///etc/mysql/my.cnf// ou un autre fichier dans ///etc/mysql/conf.d///).
-Dans la section **[mysqld]**, ajouter (pour logger par exemple dans ///tmp/mysql_queries.log//) :
-<file>
-log_output = 'file'
-general_log_file = /tmp/mysql_queries.log
-general_log = on
-</file>
-Puis redémarrer le service mysql.
-<note tip>
-  - On peut aussi exécuter une requête qui active les logs, mais je n'ai pas essayé.
-  - On peut également limiter la sortie de log aux grosses requêtes (plus de 10 sec.) (voir les options de configuration //slow_query_log//, //slow_query_log_file//, //long_query_time//, et [[https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html|la doc]]). Je n'ai pas essayé non plus.
-</note>
-<note warning>
-L'utilisateur //mysql// doit avoir un accès en écriture au dossier censé contenir les fichiers de log. Essayer, par exemple, ///tmp//
-</note>
-Pour voir en direct les requêtes exécutées, sur le serveur mysql, taper (pour notre exemple) :
-<file bash>
-tail -f /tmp/mysql_queries.log
-</file>
-===== Performances MySQL =====
-<note important>chapitre à l'état embryonnaire...</note>
-(synthèse d'informations déduites du ticket [[https://assistance.unicaen.fr/front/ticket.form.php?id=116024|116024]])
-Parmi les paramètres importants concernant les performances d'ecampus, il y a :
-  * **//innodb_buffer_pool_size//** qui définit l'espace mémoire alloué à MySQL (à son moteur innodb en particulier)
-  * **//join_buffer_size//** taille du buffer disponible pour effectuer des jointures
-  * **//table_definition_cache//** (lié à //**innodb_open_files**//, voir https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_table_definition_cache)
-Pour **consulter** la valeur d'une variable de configuration, par exemple sur ecampus :
-<file bash>
-mysql -u root -p ecampus -e "show variables like 'innodb_buffer_pool_size';"
-</file>
-(qui retourne ici //2147483648//, ce qui signifie que MySQL dispose de 2Go de RAM pour travailler).
-Pour modifier une variable de façon durable, il faut le faire dans le fichier de configuration MySQL.
-<note>
-Après migration vers mariadb, c'est maintenant //**/etc/mysql/my.cnf.migrated**// qui est utilisé.
-</note>
 <note important>
-Pour que les modifications soient prises en compte, il faut lancer un
+La présente page était redondante avec une autre.
-<file bash>
-service mysql restart
-</file>
-(un //reload// ne suffit malheureusement pas)
-RAPPEL ! Des risques de déconnexions utilisateurs existe lors de l'opération de redémarrage.
+Voir [[cemu:plateformes:moodle:documentation:debug_mysql|Surveillance/Débogage du serveur MySQL]]
 </note>