Monitoring MySQL performance metrics and managing your database doesn’t need to be difficult. Yes, you heard that right. With the proper monitoring strategies and tools at your disposal, you can finally take a backseat. The RED method, paired with Releem’s powerful monitoring capabilities and easy-to-apply configuration recommendations, does the heavy lifting for you.
The RED method is traditionally used for monitoring the performance of web applications and services but can also be applied to MySQL performance monitoring. Releem has found the framework to be equally valuable in monitoring MySQL performance metrics because the challenges faced by databases, in terms of performance and reliability, mirror those encountered by web applications.
When applied to MySQL databases, the RED method breaks down into three critical areas of concern, each providing insights into your database's operational health:
Query Rate (Rate)– This assesses the volume of queries or commands executed per second, offering a direct measure of the server's workload. It's instrumental in evaluating the database's ability to handle concurrent operations and its responsiveness to user demands.
Error Rate (Errors)– Tracking the frequency of errors in queries sheds light on potential reliability issues within the database. A high error rate may indicate underlying problems with query syntax, database schema, or system constraints that are affecting the overall database integrity. The primary MySQL metric for monitoring rate is Aborted_clients.
Query Execution Duration (Duration)– The duration metric is a measure of the time it takes for queries to complete, from initiation to execution. This performance indicator assesses the efficiency of data retrieval and processing operations which have direct impacts on the user experience and system throughput.
The health of these metrics gives you a solid understanding of how your database is performing and in turn, the experience your users are having. The RED method makes it easy to gauge what is wrong with your database and what needs to be fixed. For instance, should you find that queries are sluggishly executing, it might signal the need for tweaking indexes or optimizing the affected queries to boost efficiency.
To apply the RED method effectively to MySQL performance monitoring, Releem zeros in on eight critical aspects of your database. Each of these is tied back to Rate, Errors, or Duration in one way or another:
Latency measures the time it takes to execute a query – from the moment a query is sent to the database until the database responds. Latency directly influences how users perceive your application.
For most web applications, achieving a latency in the range of a few milliseconds up to about 10 milliseconds for database operations is considered excellent. This range ensures a seamless user experience, as the delay is virtually imperceptible to the end user.
Once latency hits the 100 milliseconds mark and beyond for simple to moderately complex queries, users start to notice a delay. This can become problematic where immediate feedback is critical, such as in form submissions, search queries, or dynamic content loading.
For More On MySQL Latency
Throughput, quantified as Queries per Second (QPS), gauges your database's efficiency and its capacity to manage workloads. High throughput signifies a well-optimized database system that can handle significant query volumes efficiently. Low throughput may indicate performance bottlenecks or resource limitations.
Achieving high throughput typically involves a combination of optimized SQL queries, appropriate hardware resources (CPU, memory, and fast IO subsystems), and fine-tuned database configurations.
For More on Throughput
Les requêtes lentes sont essentiellement des requêtes de base de données qui dépassent un seuil de temps d'exécution prédéfini. Vous pouvez ajuster ce seuil en fonction de vos objectifs de performances spécifiques ou de vos références opérationnelles. Le suivi du nombre de requêtes lentes vous permet d'identifier les requêtes qui nécessitent une optimisation.
L'identification et la journalisation de ces requêtes lentes ont lieu dans le slow_query_log, un fichier dédié créé pour stocker les détails des requêtes qui ne répondent pas aux normes de performances définies.
Pour en savoir plus sur le nombre de requêtes lentes
Cette métrique compte le nombre de connexions qui ont été interrompues parce que le client n'a pas fermé correctement la connexion. Un nombre élevé de clientes avortées peut indiquer diverses causes :
Pour en savoir plus sur les clients avortés
Le CPU est le cerveau de votre serveur. Il exécute des commandes et effectue des calculs qui permettent à votre base de données de stocker, récupérer, modifier et supprimer des données. Garder un œil attentif sur l'utilisation du processeur permet de garantir que le serveur dispose de suffisamment de puissance de traitement pour gérer sa charge de travail. Une utilisation élevée du processeur peut être le signe révélateur d'un serveur surchargé qui a du mal à répondre aux demandes qui lui sont imposées.
Voici quelques directives générales à prendre en compte pour l'utilisation du processeur :
50-70% Sustained– À ce niveau, votre processeur gère efficacement une charge de travail modérée à lourde, mais il reste encore une certaine marge pour les charges de pointe. C'est une gamme saine pour les serveurs en fonctionnement normal.
70-90% Soutenu– Lorsque l'utilisation du processeur se situe systématiquement dans cette plage, cela indique une charge de travail élevée qui laisse une marge limitée pour gérer les demandes de pointe. Vous devez surveiller le serveur de près.
Supérieur à 90 % soutenu– Il s'agit d'un indicateur fort que le serveur approche ou atteint sa capacité. Des problèmes de performances notables, notamment des temps de réponse lents aux requêtes et des délais d’attente potentiels, sont probables. Il est essentiel d’en rechercher la cause et de mettre en œuvre des optimisations ou de faire évoluer les ressources en conséquence.
Remarque :Des pics occasionnels au-dessus de ces seuils n'indiquent pas nécessairement un problème, car les bases de données sont conçues pour gérer des charges variables. Le mot clé est soutenu. Une utilisation soutenue et élevée est le signe que votre serveur est soumis à une pression importante.
La RAM est une ressource clé pour les bases de données, car elle stocke les données actives et les index, permettant un accès rapide et un traitement efficace des requêtes. Une bonne gestion de l'utilisation de la RAM garantit que la base de données peut gérer efficacement les charges de travail, optimisant à la fois les opérations de récupération et de manipulation des données.
Voici quelques directives générales à prendre en compte pour l'utilisation de la RAM :
<60-70 % d'utilisation– Cette plage est généralement considérée comme sûre et indique qu'il y a suffisamment de mémoire disponible pour les opérations de base de données en cours et les pics de charge de travail supplémentaires.
Utilisation de 70 à 85 %– Lorsque l'utilisation de la RAM se situe systématiquement dans cette plage, cela suggère que la base de données fait bon usage de la mémoire disponible mais commence à atteindre le seuil d'une surveillance attentive. Rester dans cette fourchette pendant les heures de pointe peut limiter la marge nécessaire pour gérer les augmentations soudaines de la demande.
Utilisation de 85 à 90 %– Dans cette plage, le serveur approche de sa capacité de mémoire. Une utilisation élevée de la mémoire peut entraîner une augmentation des E/S du disque lorsque le système commence à échanger des données vers et depuis le disque. Considérez cela comme un signe d'avertissement indiquant que la charge de travail doit être optimisée ou que la mémoire physique du serveur doit être étendue.
>95 % d'utilisation– Un fonctionnement à une utilisation égale ou supérieure à 95 % de la RAM est critique et susceptible d'entraîner des problèmes de performances. À ce niveau, le serveur peut fréquemment recourir à des permutations, entraînant de graves ralentissements et potentiellement des délais d'attente pour les applications clientes. Une action immédiate est requise de votre part.
L'espace SWAP est utilisé lorsque la RAM physique de votre base de données est pleinement utilisée, permettant au système de décharger certaines des données les moins fréquemment consultées vers le stockage sur disque. Bien que ce mécanisme constitue un tampon utile contre les erreurs de mémoire insuffisante, le recours à SWAP peut avoir un impact important sur les performances en raison des temps d'accès nettement plus lents par rapport à la RAM.
Idéalement, un serveur MySQL devrait présenter une utilisation SWAP faible à minimale. Cela indique que la base de données fonctionne dans sa RAM disponible.
Une utilisation élevée de SWAP est un signal d'alarme indiquant que la mémoire physique du serveur est insuffisante pour sa charge de travail, l'obligeant à dépendre de l'espace disque pour les opérations de données de routine. Vous devez prendre des mesures immédiates pour résoudre ce problème, en optimisant les demandes de mémoire de l'application ou en augmentant la RAM du serveur.
La métrique Opérations d'entrée/sortie par seconde (IOPS) indique l'intensité avec laquelle votre base de données interagit avec son système de stockage sous-jacent, c'est-à-dire le disque. Des niveaux élevés d'IOPS signifient une lourde charge de données transférées vers et depuis le support de stockage, ce qui, bien qu'indiquant une base de données chargée, peut également mettre en évidence des goulots d'étranglement potentiels dans les performances du disque.
Certains facteurs clés influençant les IOPS incluent :
L'approche de Releem en matière de surveillance des performances MySQL consiste à garder un œil attentif sur les détails importants. Cette stratégie comprend un suivi assidu des 8 métriques mentionnées – latence MySQL, débit, requêtes lentes, clients abandonnés, CPU, RAM, utilisation SWAP et IOPS – le tout dans le cadre de la méthode RED. En intégrant cette surveillance dans le cadre des bilans de santé biquotidiens (19 métriques !), Releem aide votre base de données à atteindre et à maintenir des niveaux élevés de performances, de fiabilité et d'évolutivité.
Au-delà du simple suivi des performances de MySQL, Releem va encore plus loin en proposant des suggestions de configuration sur mesure visant à résoudre les problèmes découverts lors de la surveillance. Nous appelons cette fonctionnalité Autopilot pour MySQL. Par exemple, si vous rencontrez des problèmes de latence élevée, Releem vous fournira des informations exploitables pour remettre vos chiffres de latence en ligne. Notre objectif ultime est de supprimer le besoin de surveillance manuelle grâce à un logiciel puissant et intuitif qui gère toutes les complexités de la gestion de bases de données dont vous préférez ne pas vous soucier.
Releem a une compatibilité étendue, donc que vous utilisiez Percona, MySQL ou MariaDB pour votre système de gestion de base de données, Releem peut vous aider. Consultez la liste officielle des systèmes pris en charge ici.
Pour une exploration approfondie de chaque métrique et des meilleures pratiques en matière de surveillance et d'optimisation des bases de données MySQL, pensez à visiter Releem.com.
The above is the detailed content of Mastering MySQL: Key Performance Metrics Every Developer Should Monitor. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
