Aperçu — à quoi sert cet écran
Service ▸ Base de données se connecte directement aux collecteurs BD enregistrés (access=database) et expose des métriques de charge et de structure en direct. Plutôt que de se contenter d’aligner des chiffres, l’écran attache à chaque métrique clé (attente de verrou, taux de succès du cache, utilisation des index, checkpoint, pages modifiées) un popover pédagogique conçu pour cela, afin que vous appreniez « pourquoi cette valeur est mauvaise / comment la corriger » à l’endroit même où vous la voyez.
Cet article résume les concepts enseignés par ces popovers. Le lexique complet réside en source unique dans les popovers en direct (resources/lang/{ko,en}/dbmon.php, clé edu) : en situation réelle, survolez donc la métrique pour lire le détail propre à son contexte.
L’écran est le moniteur (qu’est-ce qui va mal maintenant), le popover est la formation sur la cause (pourquoi / comment), et l’instantané réel de la configuration se trouve dans les paramètres d’instance ([param] · nginx / my.cnf / sysctl). Lisez les trois ensemble pour aller du diagnostic → à la preuve → à l’action.
Quand l’utiliser
- Une carte BD affiche Degraded ou Down et vous voulez en comprendre la raison (saturation des connexions, forte concurrence, file d’attente de requêtes, taux de requêtes lentes en hausse).
- Le score de taux de succès du cache ou d’utilisation des index est faible et vous cherchez la cause racine ainsi que les leviers d’amélioration (taille du buffer pool, ajout d’index, index couvrants).
- L’attente de verrou de ligne s’envole et vous devez cerner quelle requête ou quel motif crée la contention.
- Le détail de gestion de la mémoire montre des formes d’onde de pages modifiées / checkpoint qui se rapprochent de la zone de risque et vous voulez une direction de réglage (buffer pool ou journal redo plus grands).
- Intégration d’un DBA / DevOps — apprendre les rouages d’InnoDB (verrous, buffer pool, redo) sur des données réelles.
Disposition
Où s’attachent les popovers pédagogiques :
| Emplacement | Métrique | Ce qu’enseigne le popover |
|---|---|---|
Pied de carte, à droite · pastille Cache |
Taux de succès du cache (buffer pool) | La formule de calcul + 4 façons de l’augmenter |
Pied de carte, à droite · pastille Index |
Utilisation des index | La formule de calcul + 5 façons d’augmenter les succès d’index |
Charge de concurrence · lock |
Attente moyenne de verrou de ligne (ms) | Les 7 causes de hausse de l’attente de verrou (par fréquence) |
En-tête / détail mémoire · Checkpoint … % of redo |
Âge du checkpoint | Ce que signifie la pression du journal redo et comment lire ses hausses et ses baisses |
| Détail (repliable) · Gestion de la mémoire | Pages modifiées · série temporelle du checkpoint | Superposition des seuils LWM/MAX + annotations des épisodes de vidage |
Le corps de la carte lui-même résume deux axes de charge :
- Charge de concurrence — saturation des connexions (jauge annulaire) ·
Running(threads_running) ·Backlog(waiting) ·lock. - Débit — courbe
Total QPS·Slow rate(slow_qps) ·Slow (total).
L’analyse de schéma en bas (repliable) affiche la taille totale, les principaux schémas, les tables les plus volumineuses et la répartition des moteurs (indépendante des concepts de réglage, issue d’information_schema).
Utilisation
- Sur une carte BD, repérez la métrique problématique (pastille rouge/jaune ou valeur élevée).
- Survolez l’étiquette ou la pastille de cette métrique pour ouvrir le popover contextuel : la cause, la formule et la marche à suivre apparaissent.
- Dépliez Détails pour inspecter la série temporelle de gestion de la mémoire, avec les formes d’onde pages modifiées / checkpoint et les lignes de seuil.
- Appliquez sur la BD cible le levier de configuration indiqué par le popover (par exemple
innodb_buffer_pool_size, ajouter un index), ou recoupez-le avec la valeur actuelle dans les paramètres d’instance.
Ci-dessous une référence résumée de chaque concept (le popover en direct fait foi).
Attente de verrou de ligne — 7 causes
Temps moyen pendant lequel InnoDB a attendu l’acquisition d’un verrou de ligne (ms). Plus c’est élevé, plus il y a de contention. Par fréquence :
| # | Cause | Idée |
|---|---|---|
| 1 | Transactions qui gardent les verrous trop longtemps | Après BEGIN … UPDATE …, un commit tardif (API externe, temps de réflexion de l’utilisateur, requête lente) met en file toutes les transactions en attente de cette ligne. La plus courante. |
| 2 | Contention sur une ligne chaude | De nombreuses transactions mettent à jour LA MÊME ligne (compteur, stock, ligne de synthèse/agrégat, séquence) → sérialisation et empilement des attentes. |
| 3 | UPDATE/DELETE sans index | Si le WHERE ne peut pas utiliser d’index, InnoDB verrouille bien plus de lignes ou de plages que nécessaire → il bloque des transactions sans rapport. En pratique, la cause n° 1 cachée. |
| 4 | Verrous d’intervalle / next-key | En REPEATABLE READ, les verrous de plage verrouillent aussi les intervalles entre les lignes et bloquent les INSERT. Motif UPDATE par plage + INSERT concurrent. |
| 5 | DML par lots volumineux | Un seul UPDATE/DELETE touchant des dizaines de milliers de lignes retient de nombreux verrous longtemps. |
| 6 | Détenteur de verrou lent | Si la requête qui détient le verrou est lente sur les E/S ou le CPU, elle conserve les verrous plus longtemps : la hausse du taux de requêtes lentes et celle des attentes de verrou évoluent ensemble. |
| 7 | Vérifications de clé étrangère | Mettre à jour une table référençant une FK prend des verrous partagés sur les lignes parentes, ce qui allonge l’attente. |
Sur cet écran, la cause n° 3 (UPDATE sans index) est le moteur caché n° 1 des pics d’attente de verrou. Lisez la section TRANSACTIONS de
SHOW ENGINE INNODB STATUSconjointement avec le score d’utilisation des index.
Taux de succès du cache (buffer pool InnoDB)
Élevé lorsque la plupart des lectures sont servies depuis la mémoire (le buffer pool) plutôt que depuis le disque.
hit ratio = 1 − Δinnodb_buffer_pool_reads / Δinnodb_buffer_pool_read_requests
| Note | Seuil |
|---|---|
| Excellent | ≥ 99,5 % |
| Bon | ≥ 98 % |
| Correct | ≥ 90 % |
Comment l’augmenter (résumé) : agrandir innodb_buffer_pool_size (règle empirique : 50–75 % de la RAM) · réduire les parcours complets pour ne pas polluer le buffer pool · réduire l’ensemble de travail (éviter les colonnes inutilisées, séparer les gros BLOB, archiver) · utiliser innodb_buffer_pool_instances pour diminuer la contention et vider/recharger le buffer pool au redémarrage.
Utilisation des index
Rapport entre les lectures ayant trouvé les lignes via un index et les lectures ayant parcouru jusqu’à la ligne suivante.
index usage = Δhandler_read_key / (Δhandler_read_key + Δhandler_read_rnd_next)
| Note | Seuil |
|---|---|
| Excellent | ≥ 90 % |
| Bon | ≥ 70 % |
| Correct | ≥ 40 % |
Comment l’augmenter (résumé) : utiliser EXPLAIN pour repérer les parcours complets (type=ALL) et les tris sur fichier, puis indexer les colonnes de WHERE/JOIN/ORDER BY · construire les index composites en plaçant d’abord la colonne la plus sélective (règle du préfixe le plus à gauche) · ne pas neutraliser les index par des fonctions ou des conversions sur la colonne (WHERE DATE(col)=… → utiliser une plage) · utiliser des index couvrants · supprimer les index en double ou inutilisés.
Âge du checkpoint (pression du journal redo)
De combien le journal redo a progressé au-delà du dernier checkpoint (octets) = les modifications pas encore écrites dans les fichiers de données, et le travail qu’InnoDB rejouerait après un crash. Le % of redo de l’en-tête est la distance jusqu’au précipice de la tempête de vidage.
| État | % of redo | Signification |
|---|---|---|
| Sûr | < 50 % | Les modifications sont vidées à temps |
| Surveiller | 50 – 75 % | Les écritures dépassent le vidage ; le vidage forcé se rapproche |
| Risque | ≥ 75 % | Proche du seuil de vidage asynchrone/synchrone — le vidage forcé risque de provoquer de la latence et des tempêtes d’E/S |
Comment le lire : en hausse = écritures > vidage (le redo se remplit) · en baisse = le vidage a rattrapé son retard (sain) · en dents de scie = accumulation ↔ vidage, un rythme normal. Près de 75 %, envisagez un buffer pool plus grand ou un innodb_log_file_size plus important.
Vidage des pages modifiées (gestion de la mémoire)
Pages du buffer pool modifiées mais pas encore écrites sur le disque. La valeur appropriée, ce sont les seuils de vidage propres au serveur (innodb_max_dirty_pages_pct = MAX, innodb_max_dirty_pages_pct_lwm = LWM). Les experts : les pages modifiées devraient osciller sous le LWM.
| État | Condition | Signification |
|---|---|---|
| Sain (good) | Oscille sous le seuil (dents de scie saines) | La BD ne souffre pas pendant les vidages |
| Prudence (warn) | Au-dessus du seuil bas (zone de pré-vidage) | Surveillez la pression d’écriture et le retard du checkpoint |
| À risque (crit) | Seuil MAX atteint | Vidage agressif → pics de latence / tempêtes d’E/S (agrandir le buffer pool ou le journal redo) |
La série temporelle de gestion de la mémoire superpose les lignes de seuil LWM/MAX aux pages modifiées et épingle les épisodes d’éviction et de vidage. Les métriques de droite affichent aussi Pending writes et Row-lock avg.
Sources de données
Les compteurs et le stockage réels auxquels renvoient les concepts pédagogiques :
| Concept | Compteur / état source | Remarque |
|---|---|---|
| Attente de verrou | SHOW GLOBAL STATUS · information_schema.processlist |
Calcule la file d’attente ; nécessite le privilège PROCESS |
| Taux de succès du cache | Innodb_buffer_pool_reads / _read_requests |
Delta entre deux échantillons |
| Utilisation des index | Handler_read_key / Handler_read_rnd_next |
Delta entre deux échantillons |
| Checkpoint · pages modifiées | État InnoDB (âge du checkpoint · pages modifiées · en attente) | Série temporelle de gestion de la mémoire |
| QPS · lentes | Questions · Slow_queries (cumulés) |
Delta → QPS / taux de requêtes lentes dérivés |
- La série temporelle est stockée dans
infr_db_metric(migration 000681).App\Services\Database\DbCollectorServicese connecte directement à la BD enregistrée, litSHOW GLOBAL STATUS+@@max_connections+ processlist, et calcule les métriques dérivées comme delta par rapport à l’échantillon précédent. - La collecte s’exécute via la commande
infr:collect-db(planifiée chaque minute par défaut, sortie en un seul passage). À l’entrée sur la page, si le dernier échantillon est périmé,ensureFresh()prend immédiatement un échantillon ponctuel. - Intervalle d’interrogation de l’écran : 30 s. Pour éviter les fuites de connexions, le collecteur utilise
DB::purgedans un blocfinally, doublé d’un délai d’expiration PDO.
Seuils d’état de carte (degraded) (valeurs par défaut d’OpsPolicy::dbThresholds() — à ajuster dans la Politique d’exploitation) :
| Condition | Seuil par défaut | Libellé de motif |
|---|---|---|
Saturation des connexions conn_pct ≥ |
80 % | saturation des connexions |
threads_running ≥ |
40 | forte concurrence |
waiting (file d’attente) ≥ |
5 | file d’attente de requêtes |
slow_qps ≥ |
1/s | taux de requêtes lentes |
Accès
- Lecture (voir l’écran et les popovers) : demo (niveau 1) et au-delà. Les popovers sont un contenu purement pédagogique — pas de restriction supplémentaire ni d’audit.
- Ajuster les seuils d’état BD : gérés dans la Politique d’exploitation — administrateur (niveau 5/10 ·
infr.level:N). - Enregistrer ou modifier des collecteurs BD : Collecteurs, administrateur (niveau 5/10). Les mots de passe sont stockés chiffrés (Crypt) dans le collecteur, ou vous réutilisez un jeu d’identifiants de
.envviacred_ref = env:PREFIX(jamais codés en dur).
Dépannage et FAQ
Q. Backlog affiche « own connections only ».
Compter les requêtes en file d’attente à l’échelle du serveur exige le privilège PROCESS sur le compte BD. Sans lui, seules vos propres connexions sont comptées. Voir sql/infr_db_monitor_grant.sql (un compte de supervision dédié est recommandé).
Q. Les scores de cache ou d’index sont vides (N/A). Les métriques dérivées sont calculées comme le delta entre deux échantillons. Si le collecteur vient de démarrer ou si les compteurs ont été remis à zéro (redémarrage), le premier échantillon ne produit aucun score — attendez le cycle suivant.
Q. Une carte affiche stale (aucun échantillon récent).
En mode economy, la collecte est ignorée lorsqu’aucun utilisateur n’est présent sur la console. À l’entrée, ensureFresh(45s) prend un échantillon immédiat, mais si le planificateur est en retard la carte peut brièvement se dégrader en pending. Pour une collecte permanente, réglez le mode de collecte BD sur always dans la Politique d’exploitation.
Q. Comment traduire ou modifier le texte des popovers ?
Le lexique pédagogique réside en un seul endroit : la clé edu de resources/lang/{ko,en}/dbmon.php (source unique). Les autres langues se rabattent sur en.
Q. Comment cerner concrètement la cause d’une attente de verrou ?
Sur la BD cible, examinez SHOW ENGINE INNODB STATUS (TRANSACTIONS · LATEST DETECTED DEADLOCK) ainsi qu’information_schema.INNODB_TRX / data_locks, et recoupez avec le tableau des 7 causes ci-dessus.
Voir aussi
- Service ▸ Base de données — l’écran en direct de charge et de structure où apparaissent ces concepts
- Concepts de réglage Redis — les popovers pédagogiques équivalents pour Sessions (Redis) : capacité mémoire, taux de succès, fragmentation
- Collecteurs BD — la chaîne de collecte par connexion directe aux BD enregistrées
- Politique d’exploitation — ajustez les seuils d’état BD et le mode de collecte
- Paramètres d’instance — l’instantané réel des valeurs de réglage (my.cnf, etc.), la preuve pour le réglage assisté par IA
