MySQL Governor : limiter les ressources de la base de données de chaque client d'hébergement

Ce que limite MySQL Governor

MySQL Governor Il s'agit d'un composant de CloudLinux destiné aux serveurs d'hébergement mutualisé, et non d'une fonctionnalité générale de MySQL. Il mesure la charge de la base de données en fonction des utilisateurs associés et peut limiter les requêtes lorsque les seuils sont dépassés, via les environnements virtuels légers (Lightweight Virtual Environments, ou LVE). Cela permet d'analyser la charge de chaque compte d'hébergement de manière plus nuancée que la simple charge globale du serveur de base de données.

Au cœur de l'attention se trouvent Processeur et E/S du disque dur: Le Governor prend en compte la charge de calcul ainsi que l'activité de lecture et d'écriture. Une utilisation élevée peut par exemple résulter d'une importation ou d'une requête fréquente sur la boutique en ligne. L'affectation à un compte rend cette utilisation visible ; il convient ensuite d'évaluer, en fonction du contexte, si elle est appropriée pour l'opération concernée.

Une limite de base de données pour ces ressources n'est pas un quota d'espace de stockage. Une grande base de données rarement utilisée peut générer une faible charge CPU et E/S ; à l'inverse, une petite base de données peut être fortement sollicitée par de nombreux accès gourmands en ressources. Les limites de connexions répondent également à une autre question : elles limitent les accès, mais ne remplacent pas automatiquement le contrôle du CPU et des E/S.

Si une requête est limitée, cela ne signifie pas nécessairement qu'elle est erronée. Cette limitation peut protéger d'autres comptes contre une charge élevée, mais peut également ralentir une application légitime. Cela ne garantit toutefois pas des temps de réponse fixes, car le service de base de données, le matériel et les autres composants de l'application restent des éléments partagés du système.

Pour mieux comprendre l'interaction entre les comptes, la charge et les éléments de facturation, l'aperçu complémentaire sur la Limitation de la charge de la base de données avec CloudLinux MySQL Governor une autre approche. L'environnement réellement installé et les paramètres qui y sont définis restent déterminants pour la configuration concrète.

Vérifier la version et la compatibilité

Avant de définir les limites de la base de données, tu dois d'abord vérifier Édition et licence. Selon le fabricant, CloudLinux OS Admin ne comprend pas MySQL Governor. Un système CloudLinux ne suffit donc pas à lui seul à prouver que ce composant est disponible pour l'édition choisie, qu'il fait l'objet d'une licence et qu'il est installé sur le serveur.

Ensuite, tu dois examiner la combinaison entre la version de CloudLinux, le pack Governor et le serveur de base de données. MySQL et MariaDB constituent des branches de développement distinctes : le fait qu’une version de MySQL soit prise en charge ne signifie pas qu’une version de MariaDB de la même date fonctionnera dans les mêmes conditions. Le panneau de contrôle utilisé et son intégration doivent également être pris en compte dans cette vérification.

Les versions minimales indiquées montrent pourquoi une autorisation générale ne suffit pas : pour MySQL 8.4, CloudLinux exige au minimum la version 1.2-129 de MySQL Governor. MariaDB 11.4 nécessite au minimum la version 1.2-122 du Governor et n'est pas prise en charge pour CloudLinux OS 7 dans la documentation du fabricant. Ces informations concernent les branches mentionnées et ne remplacent pas la vérification des autres combinaisons.

Le fabricant cite notamment parmi les environnements d'installation : cPanel, Plesk, DirectAdmin, ISPmanager et InterWorx, ainsi que les serveurs sans panneau de contrôle. Si vous utilisez un panneau différent ou que vous en avez intégré un vous-même, vous devez vous renseigner séparément sur la prise en charge concrète et, en particulier, sur l'attribution des utilisateurs. Le fait qu'une version de base de données figure dans la liste ne garantit pas sa compatibilité avec toutes les combinaisons de panneaux de contrôle et de systèmes d'exploitation.

Avant d'effectuer une modification, notez les versions et les paquets existants, puis comparez-les à la documentation relative à la configuration cible prévue. Vous pourrez ainsi déterminer s'il est nécessaire de remplacer certains composants, plutôt que de considérer une installation existante comme compatible sur la seule base du nom de la base de données.

Attribuer des comptes d'hébergement aux utilisateurs de la base de données

Pour que la charge puisse être attribuée à un client d'hébergement, la correspondance entre les utilisateurs de la base de données et les comptes d'hébergement doit être correcte. Dans le cadre d'une intégration au panneau de contrôle, on utilise généralement pour cela le fichier /etc/container/dbuser-map mise à jour. Le gouverneur applique les modifications apportées à cette affectation, conformément à la documentation d'intégration, dans un délai de cinq minutes.

Exemple : un compte d'hébergement héberge une boutique en ligne et un blog distinct, qui fonctionnent chacun avec leur propre utilisateur de base de données. Si ces deux utilisateurs sont associés au même compte, la charge de la base de données peut être enregistrée pour ce compte. Si l'une des entrées est manquante ou si elle renvoie au mauvais compte, l'affectation affichée n'est pas fiable pour une évaluation spécifique au client.

Vérifie la Attribution des utilisateurs Ce n'est donc pas seulement le cas lors de la première installation. Même après la création ou le déplacement de bases de données et d'utilisateurs, le panneau de contrôle doit mettre à jour correctement l'affectation. Lors d'une vérification effectuée immédiatement après une modification, il faut tenir compte du délai de prise en compte indiqué avant de conclure à une erreur permanente sur la base d'un état encore obsolète.

L'absence de mappage en mode « Abusers » revêt une importance particulière : selon le fabricant, ce mode émule alors le mode « Single ». Les clients soumis à des restrictions partagent, en mode « Single », un LVE commun et restreint, au lieu d'être chacun limités dans leur propre LVE client. Le simple fait que le mode « Abusers » soit activé ne prouve donc pas à lui seul que la restriction prévue pour chaque compte s’applique effectivement.

En cas d'anomalies, comparez entre eux les utilisateurs de la base de données concernés, l'affectation définie et le mode de fonctionnement sélectionné. Même un mappage correct ne garantit pas un isolement total : le service de base de données et le matériel sous-jacent continuent d’être partagés. L’affectation est une condition préalable à un contrôle adapté à chaque client, mais ne remplace pas la planification des capacités.

Comparaison des modes de fonctionnement

Le mode de fonctionnement détermine si MySQL Governor se contente de surveiller la charge de la base de données ou s'il exécute des requêtes dans un environnement restreint. Les seuils ne sont pas les seuls éléments importants pour ce choix : l'affectation des utilisateurs de la base de données et la question de savoir quels clients partagent une LVE influencent également le résultat.

Pour faire le point, on peut Off Remarque : l'utilisation observée indique quels comptes et quelles périodes méritent un examen plus approfondi, sans que le Governor ne limite pour autant les requêtes. Une valeur ponctuelle élevée ne permet toutefois pas à elle seule de déterminer si un compte génère une charge importante de manière durable ou s'il effectue simplement une opération de maintenance légitime.

À l'adresse suivante : Auteurs d'abus Les requêtes de base de données soumises à des restrictions partagent le budget de ressources LVE avec d'autres processus du même compte, tels que PHP. Une restriction peut donc non seulement allonger la durée des requêtes, mais aussi ralentir la réactivité de l'application lorsque ses processus se disputent ces mêmes ressources limitées. À l'inverse, le budget PHP déjà utilisé peut influencer le fonctionnement de la base de données.

Le mode « Single » est obsolète et concerne principalement les configurations existantes ainsi que le comportement de remplacement documenté : plusieurs clients soumis à des restrictions se partagent un environnement et peuvent y entrer en concurrence les uns avec les autres. En l'absence de fichier « dbuser-map », « Abusers » émule ce comportement ; le paramètre sélectionné ne permet alors pas à lui seul de conclure à une restriction propre au client. Le paramètre « All » est également obsolète et n’est pas recommandé pour une nouvelle installation.

Planifier les limites de la base de données et les créneaux horaires

MySQL Governor distingue l'utilisation du processeur ainsi que les E/S de lecture et d'écriture. L'interface CLI documentée affiche l'utilisation du processeur en pourcentage et les E/S en Mo/s ; des valeurs distinctes peuvent être configurées pour la lecture et l'écriture. Ces indicateurs décrivent des charges différentes : une opération nécessitant une grande puissance de calcul n'implique pas nécessairement un volume d'écriture particulièrement important sur le support de données.

Les traverses à court terme, à moyen terme et à long terme tiennent compte d'une utilisation à court terme et à plus long terme. Leur dépassement déclenche une limitation en fonction du mode de fonctionnement et de la configuration. Il ne s'agit ni d'un débit garanti, ni de quatre engagements de performance indépendants les uns des autres et appliqués de manière stricte et permanente. La limitation qui s'applique effectivement dépend également du mode de fonctionnement choisi et des limites LVE.

Une importation illustre bien la différence : si la charge d'écriture augmente brièvement puis redescend, cela peut faire partie d'une opération planifiée. Si elle reste élevée pendant une longue période, l'importation mobilise les ressources plus longtemps. Pour prendre une décision, tu dois non seulement tenir compte de la valeur maximale, mais aussi vérifier quelle ressource est concernée, combien de temps dure l'opération et si elle se répète.

Faible Seuils de déclenchement peuvent protéger plus tôt les autres clients contre une charge prolongée, mais risquent de freiner des importations ou des tâches de maintenance légitimes. Des seuils élevés laissent davantage de marge de manœuvre pour ce type de travaux, tout en autorisant une charge plus élevée pendant plus longtemps. Une fenêtre de maintenance ou une capacité planifiée de manière ciblée peut s’avérer plus judicieuse qu’une exception permanente.

Évaluez les valeurs du régulateur par rapport aux limites LVE et aux tarifs effectivement proposés. Les recommandations du fabricant tiennent expressément compte de cette corrélation ; il n’est toutefois pas possible d’en déduire des valeurs de production universellement valables. La charge de requêtes observée, l’efficacité des requêtes et la nature des travaux des clients constituent la base permettant d’ajuster les seuils de manière contrôlée après la mise en service.

Préparer la mise en place et les limites tarifaires

Avant toute installation ou mise à niveau, il faut sauvegarde complète de la base de données y compris les tables système. Prévoyez également comment la restauration devra s'effectuer en cas de besoin. Le fabricant précise que les paquets de base de données peuvent être mis à jour à partir des dépôts CloudLinux ; le changement de paquet n'est donc pas un effet secondaire anodin que vous ne devriez vérifier qu'après l'installation.

Vérifiez ensuite la combinaison de l'édition et de la version de CloudLinux, de la licence, de la branche de la base de données, du pack Governor et du panneau de configuration. Le fait qu'une version de la base de données soit prise en charge ne garantit pas à lui seul que toutes les combinaisons de ces composants le soient également. Si les versions des paquets ou l'intégration du panneau de configuration ne correspondent pas, il convient de vérifier la prise en charge concrète avant toute intervention.

Une fois la préparation technique terminée, commencez par observer la situation plutôt que de procéder immédiatement à une réduction de la charge. Comparez les horaires d'activité habituels aux fenêtres d'importation et de maintenance connues, et vérifiez si les utilisateurs de la base de données sont bien affectés aux comptes d'hébergement appropriés. Sans affectation fiable, une charge apparemment faible sur les comptes ne permet pas de tirer des conclusions fiables sur les besoins réels en ressources.

À partir de cet état des lieux, définissez une mise en place progressive : déterminez quels comptes ou quels tarifs doivent être concernés, comment les réclamations seront enregistrées et sur la base de quelles observations vous vérifierez le bon fonctionnement du dispositif. Une fois le dispositif activé, comparez les restrictions aux opérations réelles, plutôt que de considérer immédiatement tout dépassement comme un manquement.

CloudLinux Manager permet de gérer les limites du gouverneur au niveau des paquets ; des valeurs différentes peuvent s'appliquer à certains clients. Veillez donc à documenter, à chaque modification, les Origine de la limite: Provient-il du forfait ou a-t-il été défini individuellement ? Cela permettra de déterminer ultérieurement quels clients sont concernés par un changement de tarif et quelles exceptions doivent faire l'objet d'un examen séparé.

Vérifier la charge actuelle et l'historique

Pour établir le diagnostic, tu as besoin à la fois d'une Instantané ainsi que l'évolution dans le temps. Les commandes suivantes sont exécutées dans le terminal du serveur CloudLinux, et non dans la console MySQL. Elles sont fournies à titre informatif et ne modifient aucune limite ; pour une analyse pertinente, les outils correspondants doivent être installés et les données pertinentes doivent être disponibles.

Identifier les comptes suspects présentant les mêmes caractéristiques que le Attribution des utilisateurs et du mode de fonctionnement sélectionné. Si un utilisateur de la base de données est absent du mappage, la charge visible pour le compte d'hébergement peut être incomplète. La documentation relative à l'intégration indique qu'une modification apportée au fichier de mappage est prise en compte dans un délai de cinq minutes ; un résultat vérifié immédiatement après ne peut donc pas encore refléter la nouvelle situation.

Comparez ensuite le moment où une restriction a été appliquée avec le processus d'utilisation observé. Une valeur ponctuelle élevée peut être liée à une importation et ne constitue pas en soi une preuve d'une utilisation excessive durable. La Guide d'interprétation des rapports du gouverneur MySQL complète l'interprétation des indicateurs affichés.

Distinguer la limitation et ses causes

Si un site web ralentit, vérifiez d'abord si une restriction était effectivement active à ce moment-là et quelle raison est indiquée. Reliez ce constat à l'opération concrète : un processus de paiement lent et une importation en cours au même moment peuvent être liés, mais ce n'est pas forcément le cas. En l’absence de coïncidence temporelle, il serait prématuré de désigner le régulateur comme seule cause.

En mode « Abusers », des requêtes de base de données limitées sont exécutées dans le LVE du compte associé. Elles y partagent le Budget des ressources avec d'autres processus de gestion de comptes, tels que PHP. En cas de plainte, il convient donc d'examiner les deux aspects : une tâche sollicitant fortement la base de données peut entrer en concurrence avec PHP pour l'utilisation des ressources ; à l'inverse, une capacité LVE déjà mobilisée peut affecter les requêtes limitées.

Si la charge se répète au niveau d'une fonctionnalité de la boutique, examine la requête concernée et son Plan d'interrogation ainsi que des statistiques de base de données appropriées. L'absence d'index ou un index inadapté peut en être la cause, mais ce n'est pas la seule. La limitation peut réduire l'impact sur les ressources partagées ; elle ne corrige ni le plan ni la logique de l'application.

Pour les utilisateurs « Single » et « Abusers », CloudLinux indique que les restrictions sont levées dès que l'utilisation est restée inférieure au seuil pendant une minute. Vérifiez néanmoins le mécanisme de restriction effectivement configuré et l'évolution dans le temps sur votre propre système, plutôt que de conclure immédiatement à une solution permanente sur la base d'un bref allègement. Une tâche qui redémarre peut à nouveau dépasser un seuil ultérieurement.

Réajuster les limites ou modifier l'architecture

Commencez par vous demander si le pic observé correspond à une tâche prévue ou s’il perturbe régulièrement le fonctionnement du système. Une importation planifiée peut éventuellement être reportée à une fenêtre de maintenance. Dans ce cas, notez la durée, la ressource concernée et les répercussions sur l'application avant de déduire une modification tarifaire permanente à partir d'un pic isolé.

Si ce créneau horaire n'est pas suffisant, une Dérogation tarifaire être plus appropriée qu'une augmentation forfaitaire pour tous les clients. Consignez le motif, le nom du responsable et la date de la nouvelle vérification. Précisez également si la valeur actuelle provient du pack ou si elle a été définie individuellement : CloudLinux Manager prend en charge les limites liées aux packs ainsi que les dérogations individuelles.

Après avoir apporté une modification, vérifiez, sur une période représentative, si le traitement des tâches prévues s'effectue mieux et si des restrictions ou des problèmes apparaissent ailleurs. Pour ce faire, mettez en relation les seuils du régulateur avec les limites LVE. Un seuil plus élevé permet potentiellement de supporter une charge plus importante pendant plus longtemps ; il ne s'agit ni d'un débit garanti, ni d'un engagement concernant des temps de réponse spécifiques.

Un autre levier d'action est la résolution du problème: L'optimisation des requêtes, l'utilisation d'index adaptés ou la mise en cache peuvent réduire les tâches récurrentes, plutôt que de se contenter d'en limiter l'impact. Les limites de connexion au niveau de la base de données restreignent en revanche les accès simultanés et ne remplacent pas automatiquement le contrôle du CPU et des E/S assuré par le Governor.

Si les besoins d'un client s'écartent durablement et de manière significative de l'hébergement mutualisé, il peut être judicieux de disposer d'une instance de base de données dédiée ou d'un serveur dédié. Cela fait toutefois passer la décision du simple franchissement de seuils à la planification des capacités, de la maintenance et de l'exploitation. Une telle séparation ne doit pas non plus être présentée de manière générale comme une garantie d’isolation totale ou de temps de réponse fixes.