Passer au contenu 
CloudLinux MySQL Governor limite la charge de la base de données par compte et la répartit équitablement, afin que certaines requêtes ne ralentissent pas l'ensemble de l'hébergement. J'utilise le MySQL Governor, afin de surveiller en temps réel l'utilisation du processeur, les opérations de lecture et d'écriture par utilisateur, et de limiter automatiquement ces ressources en cas de dépassement.
Points centraux
- Par compte au lieu de limites globales
- CPU/LECTURE/ÉCRITURE gérer séparément
- Modes « Monitor-only » et « Abusen » li>LVE en tant que deuxième niveau de protection
- Outils en ligne de commande à des fins de contrôle
Pourquoi certaines requêtes ralentissent-elles l'ensemble du système ?
Dans les environnements d'hébergement mutualisé, ce sont généralement quelques-uns qui génèrent Requêtes la charge la plus importante, et non le volume des bases de données. Je constate souvent qu'une requête défectueuse ou un plugin générant un trafic d'E/S élevé monopolise soudainement le temps CPU et que la latence augmente de manière perceptible pour les autres utilisateurs. C'est précisément là qu'intervient le gouverneur car il met en évidence la charge par utilisateur et ne se contente pas de considérer la moyenne globale. J'évite ainsi qu'un „ voisin bruyant “ ne ralentisse tous les autres projets, alors que leurs charges de travail sont tout à fait normales. Grâce à des limites claires et à une répartition équitable, je garantis la prévisibilité des temps de réponse et je s’attaque à la racine du problème des accès excessifs.
Voici comment fonctionne MySQL Governor au quotidien
Je commence souvent par Écranle mode « -only » pour mesurer l'utilisation réelle sans intervenir. Ensuite, j'active le mode « Abusen », qui transfère automatiquement les comptes présentant une activité excessive vers un environnement restreint, ce qui permet d'en limiter immédiatement l'impact. La mesure repose sur fil de discussion- Des statistiques par connexion MySQL/MariaDB, permettant de suivre la répartition de l'utilisation du processeur, des opérations de lecture et d'écriture par utilisateur. En cas de surcharge persistante, le LVE associé entre également en action, ce qui ralentit davantage les processus de ces comptes. Ce processus en deux étapes empêche les escalades, atténue les pics de charge et protège efficacement les projets non concernés.
Choisir judicieusement les valeurs limites et les plages horaires
Je fixe des limites sur plusieurs Intervalles, afin de tolérer les pics ponctuels tout en limitant de manière fiable les surcharges persistantes. Les plages de temps courtes peuvent présenter des valeurs plus élevées, les moyennes doivent rester modérées, les longues doivent clairement être plus strictes, et elles doivent toutes rester en dessous des limites globales de LVE. Je mesure l'utilisation du processeur en pourcentage par Noyau; avec huit cœurs, 100% correspond à un cœur complet, ce qui garantit la transparence de la répartition et de l'équité. J'évalue les opérations READ et WRITE sur la base d'E/S disque réelles, c'est-à-dire sans accès au cache, afin de visualiser la charge réelle sur le stockage. Pour une configuration globale propre, je m’appuie sur les règles LVE éprouvées et les détails tels que décrits dans Configurer correctement les limites LVE décrites.
Planifier des intervalles en fonction de l'heure de la journée et des profils
Je dépose volontiers profils en fonction de l'heure de la journée: Pendant les heures de pointe, j'autorise des intervalles courts de manière un peu plus souple afin de faire face aux pics de trafic légitimes (par exemple, les ventes flash des boutiques en ligne). Le soir et la nuit, je privilégie surtout les longs intervalles plus strict, afin que les tâches de longue durée n'épuisent pas le disque sans que l'on s'en aperçoive. Pour les fenêtres de traitement par lots, je définis mes propres profils avec un peu plus de WRITE, mais une utilisation CPU limitée, afin que les importations s'exécutent rapidement sans pour autant monopoliser les ressources. Un point essentiel : je ne modifie jamais tous les paramètres en même temps. Je commence par ajuster l’utilisation du processeur, j’observe, puis je passe aux paramètres READ/WRITE. Chaque modification fait l’objet d’une période d’observation bien définie, afin de pouvoir distinguer clairement la cause et l’effet.
Outils en ligne de commande et diagnostic rapide
J'analyse les comptes suspects à l'aide de dbtop en temps réel, je mets à jour les limites avec dbctl et je consulte l'historique via lveinfo –dbgov. Ces outils me fournissent en quelques secondes les informations pertinentes sur les pics d'activité, les requêtes de longue durée et le nombre de connexions par utilisateur. Cela me permet de déterminer si, notamment, CPU ou limité par les E/S, que ce soit en raison d'un nombre excessif de connexions ou d'un engorgement des requêtes sur certaines tables. À partir de ces modèles, je détermine des seuils adaptés pour chaque intervalle et je teste d'abord les modifications en mode « monitor-only ». Ce n'est que lorsque les courbes présentent une baisse plausible que j'active la limitation de manière permanente.
| Outil | Objectif | Exemple |
|---|---|---|
| dbtop | Affichage en direct par utilisateur/fil de discussion | dbtop – par utilisateur |
| dbctl | Définir des limites et contrôler les modes | dbctl set userX cpu=120 read=8 write=6 |
| lveinfo –dbgov | Vérifier l'historique et les infractions | lveinfo –dbgov –id userX –period 1h |
Dépannage : cas de figure typiques et mesures correctives rapides
Si CPU d'un compte, je constate souvent des schémas tels que SELECT *, des clauses WHERE manquantes, des ORDER BY complexes avec des ensembles de résultats volumineux ou des requêtes N+1 issues d'ORM. Côté E/S, je constate des balayages complets sans index adaptés, des répétitions de LIKE ‚ %…% ‘ ou des JOIN sur des colonnes non indexées. Ma démarche : identifier les tables concernées, vérifier le plan d’exécution, ajouter les index manquants et optimiser la requête rationaliser (uniquement les colonnes nécessaires, pagination avec LIMIT/OFFSET ou des approches par curseur). En parallèle, je définis temporairement des règles plus strictes pour cet utilisateur intervalles courts, afin que le pic soit immédiatement atténué, puis relâchez-les dès que la solution est opérationnelle et que la courbe redescend de manière stable.
Interaction avec LVE : contrôle en deux étapes
Je considère MySQL Governor comme premier Une couche de protection de la base de données et LVE servent de deuxième frein si la charge persiste. Le Governor limite de manière ciblée l'activité de la base de données, tandis que LVE gère de manière stricte l'ensemble des ressources CPU, RAM et E/S du compte. Cette combinaison empêche un compte de devenir incontrôlable en répétant simplement des requêtes courtes. Si l'activité reste élevée, LVE et réduit la priorité des processus du compte, ce qui allège sensiblement la charge de la base de données. Ainsi, la qualité de service reste fiable pour tous les clients, même pendant les pics de charge et de trafic.
Valeurs limites dans la pratique : exemples de valeurs
Pour les serveurs mutualisés classiques, je commence par CPU- Je fixe des limites comprises entre 80 et 1 501 TP3T par compte sur le court terme et je les réduis considérablement sur le long terme. Pour la lecture/écriture, je commence souvent entre 4 et 12 Mo/s à court terme, puis je resserre les limites à long terme afin que le disque ne bascule pas dans des temps d’attente permanents. Je limite volontiers le nombre de connexions simultanées à 30, car un nombre excessif de connexions épuise rapidement les pools de threads. Ces valeurs de départ constituent une bonne base, mais je les ajuste en fonction des données réelles issues de dbtop et de lveinfo. L’essentiel est le suivant : je peux tolérer des pics de courte durée, mais j’empêche systématiquement toute saturation prolongée.
Exceptions, listes blanches et fenêtres de maintenance
Certains comptes ont parfois besoin d'un peu plus de marge de manœuvre : les grands Importations, migrations de boutiques en ligne, réindexation. Je planifie ces opérations pendant des plages horaires en dehors des heures de pointe et je définis au préalable des limites temporairement plus élevées par utilisateur. Une fois l'opération terminée, je rétablis les valeurs par défaut à l'aide d'un script. Il est également judicieux de mettre en place une petite Liste blanche pour les comptes critiques pour le système qui ne doivent jamais être limités (par exemple, les utilisateurs de services internes). Je consigne chaque exception en précisant l'heure de début et de fin ainsi que les valeurs cibles, afin que des analyses ultérieures puissent expliquer cet écart. Cela permet de garantir la traçabilité de la gouvernance sans entraver les opérations de maintenance légitimes.
WordPress et les plugins : comment remédier aux problèmes courants
Dans les installations CMS, je vois souvent des JOINs, des widgets dynamiques sans cache et des tâches cron qui analysent des tables entières toutes les heures. Le Governor assure ici une protection fiable, mais je m'attaque également à la cause au niveau de l'application. J'active le cache d'objets, je réduis le nombre de requêtes de recherche et j'utilise, lorsque cela s'avère pertinent, Pooling de connexions, afin d'éviter les pics de connexions et de déconnexions. En associant cela à des limites claires pour le CPU et les E/S, je réduis sensiblement les temps de réponse et maintiens la Dernier maîtrisable. Cette combinaison permet de réduire le nombre de tickets d'assistance et d'amortir les pics de trafic avant qu'ils ne surchargent le serveur.
L'entretien des schémas et des index dans la pratique
Je vérifie régulièrement si les tables et les index sont toujours adaptés à Modèles d'accès s'adaptent. Les nouvelles fonctionnalités et les plugins modifient souvent subtilement les requêtes : un filtre supplémentaire, un autre critère de tri… et déjà, l'ancien index ne fonctionne plus. Je donne donc la priorité aux index pour les colonnes WHERE fréquemment utilisées, je réduis indices qui se chevauchent et je remplace les recherches avec le préfixe LIKE par des champs plus ciblés. Pour les tables d'archives, j'utilise des concepts de partitionnement ou des filtres par horodatage afin d'éviter les analyses complètes. Le Governor atténue les conséquences d'une mauvaise conception des schémas, mais la solution la plus efficace consiste à facile d'accès à structurer.
Gestion des connexions : éviter les erreurs 500
Un nombre trop élevé de connexions simultanées entraîne souvent des interruptions de service Time-outs, qui se traduisent par des erreurs 500. Je commence par vérifier le taux de connexion par utilisateur et l’utilisation du pool de threads. S’il y a des signes de pic de connexions, je resserre les limites et je mets en place une mise en cache au niveau des requêtes ou des objets. Pour plus d’informations, consultez l’article sur Erreurs 500 liées aux connexions Causes courantes et mesures à prendre pour remédier à ce goulot d'étranglement. En résumé, je sécurise la pile MySQL et je maintiens la Latence prévisible.
Trouver le juste équilibre entre le pooling et le keep-alive
Je dimensionne des piscines faible, mais constant: suffisamment pour couvrir le parallélisme habituel sans bloquer le serveur avec des sessions inactives. Des durées de keep-alive longues permettent de lisser les pics de charge, mais ne doivent pas pour autant entraîner une accumulation de connexions inactives qui monopolisent les ressources. Je mesure donc la durée de connexion et les temps d’inactivité par compte, et j’ajuste en conséquence la taille des pools ainsi que les délais d’expiration des sessions. En combinaison avec le « Governor », j’empêche ainsi que la création et la fermeture effrénées de connexions ne mobilisent excessivement le processeur, tout en évitant que des pools surdimensionnés n’occupent inutilement le pool de threads.
Bien interpréter les indicateurs de suivi
Je fais clairement la distinction entre CPU et les E/S, car ces deux ressources imposent des contraintes totalement différentes. Si l'utilisation du processeur augmente fortement sans que les valeurs d'E/S soient adaptées, c'est souvent la logique, l'analyse syntaxique ou un plan inefficace qui bloque le système ; en cas d'E/S élevées avec une faible utilisation du processeur, ce sont les analyses complètes ou l'absence d'index qui indiquent le goulot d'étranglement. J’évalue toujours les opérations READ/WRITE sans cache, afin de détecter la charge réelle du disque et non pas uniquement les accès en mémoire. Je examine également la durée des connexions, les threads actifs et la longueur des requêtes afin de repérer rapidement les exécutions lentes. Ces schémas me permettent de déterminer quelle limite fixer et quel intervalle resserrer.
Prendre en compte les facteurs liés au matériel et au moteur de jeu
Le Classe de stockage détermine quelles valeurs limites sont réalisables. Sur NVMe, je peux autoriser à court terme des valeurs de lecture/écriture plus élevées ; sur HDD, j'adopte une approche plus prudente et je respecte plus strictement les intervalles longs. Je tiens également compte de la manière dont le moteur gère la mise en mémoire tampon : les écritures en arrière-plan agressives peuvent lisser les pics, mais aussi produire des phases apparemment „ calmes “ pendant lesquelles les écritures s’accumulent. C’est pourquoi je mets en corrélation les métriques du régulateur avec les E/S physiques et les temps d’attente au niveau du périphérique bloc. L’objectif est toujours un stable La médiane plutôt que les débits maximaux, au détriment de la latence.
Comparaison entre « Monitor-only » et « Abusen »
J'utilise le ÉcranMode « -only » pour collecter des profils d'utilisation réels et établir des valeurs de référence. Dès que j'ai défini des seuils plausibles, je passe en mode « Abusen » afin que le régulateur limite automatiquement les comptes en surcharge. Le premier mode réduit les fausses alertes, tandis que le second évite les dommages collatéraux lors de véritables pics de trafic. En fonction de mon niveau d’expérience, je peux travailler avec des intervalles longs et plus stricts, tout en assouplissant légèrement les règles pour les intervalles courts. Cette approche garantit que les limites ne sont pas fixées au hasard, mais qu’elles reposent sur une Mesure suivre.
Plan de déploiement et communication
Je ne lance jamais le Governor en mode „ Big Bang “. La procédure a fait ses preuves : 1) Inventaire des comptes actifs, regroupement approximatif par profils de charge. 2) Uniquement sur écran pendant au moins une à deux semaines, afin de mettre en évidence les tendances hebdomadaires. 3) Définition de limites de base par groupe et déploiement contrôlé par vagues, en surveillant de près à chaque fois les indicateurs clés de performance (taux d'erreur, latence P95, taux d'abandon). 4) Ajustement fin et documentation des exceptions. En parallèle, j’informe de manière proactive les clients de l’objectif de „ Fair Share “, des causes typiques des limitations de débit et des optimisations pertinentes. La transparence réduit les demandes de précisions et renforce l’acceptation des limites.
Sauvegarder la réplication, les sauvegardes et les utilisateurs spéciaux
Les utilisateurs proches du système, tels que Réplication- ou Utilisateur de sauvegarde ne doivent pas être freinés de manière inattendue. J'attribue clairement ces comptes, je les documente et je les exclue des limitations automatiques. Pour les sauvegardes, je prévois des limites de lecture inférieures à la zone de confort de stockage, afin que la charge des utilisateurs n'en pâtisse pas en parallèle. En matière de réplication, je veille à ce que les processus de rattrapage ne compromettent pas la charge de production : des intervalles courts sont gérés de manière un peu plus souple, tandis que les intervalles longs sont gérés de manière prudente, afin qu’un rattrapage prolongé ne devienne pas un frein permanent. Il reste important de bien séparer entre Service- et les comptes clients, afin que les indicateurs restent univoques.
Procédure d'urgence en cas de surcharge aiguë
Si, malgré les limites fixées, une dégradation sensible se produit, j'interviens Guide tactique À partir de : 1) Identifier le compte le plus actif dans dbtop et renforcer temporairement ses limites. 2) Réduire le nombre maximal de connexions pour cet utilisateur afin de soulager le pool de threads. 3) Mettre en évidence les requêtes de longue durée, optimiser en priorité ou suspendre celles qui semblent problématiques. 4) En cas de charge système importante, abaisser temporairement les limites LVE de l’utilisateur incriminé afin de stabiliser la plateforme. 5) Une fois la situation stabilisée, revenir progressivement aux valeurs initiales et résoudre définitivement la cause du problème (index, cache, code). Je consigne chaque mesure avec l'heure et l'effet mesuré, afin d'accélérer les interventions futures.
En bref : des lignes directrices applicables
Je mise sur une distinction claire entre Limites pour CPU, READ et WRITE, car chaque ressource a un impact différent. Je commence par une approche prudente, je mesure les effets en mode « Monitor-only » et je fixe des limites en mode « Abusen » dès que les courbes indiquent clairement la direction à suivre. Je gère les intervalles à long terme de manière plus stricte et je reste en dessous des limites globales de LVE afin que le deuxième niveau de protection se déclenche en toute sécurité si nécessaire. Je surveille le nombre de connexions, je commence avec 30 sessions par compte et j’ajuste en fonction de la charge de travail et de l’heure de la journée. Je combine le contrôle technique avec un travail sur les causes au niveau de l’application, car c’est ainsi que je maintiens la Base de données fiable, équitable et rapide pour tous les projets hébergés sur le même serveur.
