Hébergeur depuis 1997

Monitoring Bases de Données

Voici un exemple de monitoring de Bases de Données MySQL sur l'un de nos serveurs en temps réel. L'analyse de ses données nous permet d'optimiser fortement les temps d'accès et les temps de réponses, quel que soit le type de requêtes. En fonction des paramètres d'alertes que l'on peut paramétrer pour chaque serveur de base de donnée, notre service de monitoring est prévenu en temps réel. En fonction de votre contrat d'infogérance vous pouvez être alerté par mail ou sms dès qu'un indicateur devient anormal.

Le serveur MySQL de bases de données qui nous sert d'exemple contient entre autres une base de plus de 1.120.000 produits. Elle appartient au site www.kataclop.com qui est certainement l'un des comparateur de prix les plus rapides du réseau .

Panneau de Contrôle Général

Ce panneau vous indique de façon très intuitive que votre base de donnée fonctionne parfaitement ( tout est vert ).

Mais de façon plus détaillée, nous savons que la taille des bases de données de ce serveur MySql est de 3,6 Go , que le serveur exécute actuellement 45 requêtes par seconde, qu'un utilisateur et connecté et actif, que le processeur du serveur est utilisé à 4 % , que 23 sessions sont disponibles et que 4 coeurs du serveur peuvent être utilisé par le serveur MySQL.

Cache InnoDB

Un partie importante de ces bases MySQL est en mémoire vive ( 2,45 Go ). Il s'agit des bases de données InnoDB . La mise en cache des bases de données Myisam est plus complexe et est limitée. Nous vous déconseillons d'utiliser ces bases si vous avez un usage intensif de vos bases de données. Dans le cas de bases de données existantes MyIsam, et dans la mesure du possible, il est conseillé de les convertir en bases de données InnoDB.
Dans notre exemple, la taille du cache est utilisée à 100 % , il serait bon, s'il reste de la mémoire, de l'augmenter.

Buffer de Tri

Dans notre exemple, vous bénéficiez d'un cache mémoire de tri de vos données de 256 Mo . MySQL, par défaut, quand il ne bénéficie pas d'un buffer de mémoire allouée pour le tri des donnée, ouvre une table provisoire sur le disque dur pour écrire ses données. Cette opération n'est généralement pas très rapide, une bonne taille de buffer de tri est donc conseillée pour répondre rapidement à ces requêtes.

Cache de requêtes

Il indique également que vous bénéficiez d'un cache mémoire des requêtes de 512 Mo , que ce cache est efficace dans 83 % des cas , qu'il a déjà mémorisé 103.594 requêtes différentes depuis le re démarrage de votre base de donnée, que 321 Mo de mémoire vive sont encore disponibles pour accepter de nouvelle requêtes.

Buffer de Log

Le buffer de log permet de stocker provisoirement en mémoire vive les logs générés par le serveur MySQL. Sa taille n'a pas besoin d'être très importante, dans notre cas 32 Mo

Activité du Serveur de base de donnée

Le contrôle de l'activité du serveur de bases de données se fait sous forme de différents graphiques lisibles facilement et qu'il convient de comparer l'un avec l'autre pour en tirer des bonne informations sur le fonctionnement de votre serveur.

Requêtes SQL par secondes

Ce graphique vous donne le nombre de requêtes adressées au serveur durant la dernière heure en différenciant les demandes selon leur type.

Accès Base sur le Disque

Ce graphique vous indique le nombre de lignes ayant été lues, insérées, effacées ou mises à jour sur le disque dur. Dans notre cas nous constatons qu'il n'y a aucune lecture mal grès le nombre de requêtes figurant dans la tableau précédent, seules des insertions ou mises à jour sont inscrites sur le disque. Cela nous montre l'efficacité des caches, les opérations de lectures étant toutes traitées en mémoire et sont donc de ce fait extrêmement rapides.

Taux d' échec

Le taux d'échec est le pourcentage de de réponses n'ayant pas pu être délivrées directement du cache de requête. Dans notre exemple, le taux est assez élevé car de nombreuses mises à jour de la base de donnée sont en cours.

Tri par seconde

Ce graphique nous indique le nombre de requêtes de tri reçues par seconde. Il est réparti entre le total des requêtes de tri, le tri sur des enregistrements filtrés et le tri sur l'ensemble de la table.

Enregistrements triées par seconde

Ce graphique nous représente le nombre d'enregistrements triées par le serveur mysql par seconde. Vous noterez que trier plus de 12.000 enregistrements par secondes n'est pas un problème pour notre serveur mysql hébergé sur notre offre serveur virtuel illimité !

 

Utilisation CPU

Ce graphe nous donne l'utilisation des processeurs. Comme on peut le remarquer, le serveur a encore de nombreuses ressources disponibles. Dans notre cas, nous noterons que le tri de plus de 12.000 requêtes par secondes n'a pas augmenté de façon remarquable l'utilisation du processeur.

Notre logiciel de gestion et d'optimisation de bases de donnée dispose encore de nombreux autres graphiques et données à analyser mais qui n'ont pas grand intérêt dans le cadre de cet exemple.

Conclusion

L'optimisation d'une bases de donnée, en soi, est déjà complexe, choix du type de base, création des champs et index , relations entre les tables etc..

L'optimisation d'un serveur mySQL nécessite également un travail important avec une adaptation, en fonction du type de base utilisée, de la taille des tables, de la mémoire disponible.

Une ré-actualisation régulière doit être prévue, en fonction de l'évolution des bases de données enregistrées ainsi que du volume des requêtes.

Espace 2001 est à votre disposition pour analyser le fonctionnement de vos serveurs MySQL et vous proposer une optimisation efficace et garantie. N'hésitez pas à nous contacter.

 

Share this page:

LinkedIn Google+


Copyright © 1997-2024 G. H. & Espace 2001 77 route de la Banvoie - 88340 Le Val d'Ajol - France - Tel: +33 (0) 970 408 150