Les vacances étant terminées, nous allons boucler notre tour de vue des index inutiles en voyant quels outils vont nous aider à découvrir les index qui peuvent être supprimés. Le dernier article présentait en effet des indications qui fonctionnent généralement bien mais qui ont l’inconvénient de demander beaucoup de travail manuel et de laisser de côté tout un pan d’index qui peuvent être inutiles : ceux qui ne sont pas en doublon ni redondants, qui n’ont pas une cardinalité faible mais qui ne sont tout simplement pas utilisés par l’application.

Idée générale

Si vous avez bien lu l’article précédent, vous avez probablement remarqué que la principale difficulté est qu’il n’existe quasiment jamais de règle absolue permettant de savoir à coup sûr qu’un index est inutile (exception notable : les index en doublon repérés par mk-duplicate-key-checker et qui peuvent être supprimés dans 99% …

Une manière d’identifier d’où provient des peaks de performance momentanés est de regarder les logs produit par MySQL, soit le slow query log et les binlog. Malheureusement (ou heureusement?), il est possible qu’un grand nombre de requêtes optimisées soit envoyées au serveur, et par conséquent, ne se trouve pas dans le slow query log. Le binlog s’avère donc une source plus fiable.

Comment faire? En utilisant mk-query-digest de la suite d’outil Maatkit. Cet outil permet d’analyse les logs générés par mysqlbinlog et crée un rapport complet de la situation. Il possède une multitude d’options que je vous invite à lire dans la doc officielle, mais voici comment l’utiliser dans sa forme la plus simple:

mysqlbinlog mysql-binlog.003161 | mk-query-digest --type binlog --report-format …

The second OSSEC week just ended. Here is a reflection about a feature that does not exist (yet?) in OSSEC. The goal of a SIEM (“Security Incidents and Events Management“) is to collect logs from multiple non-heterogeneous sources and process them to add some extra value to the events. To achieve this, powerful correlation engines can be used to create rules to match different types of events  coming from different sources and to create a unique security incident:

  if (condition1 && condition2 && condition3)
  {
    created_security_alert();
  }

Once created, The security incident must be processed. The basic action is to notify the right people with messages displayed on a console, new events, emails, etc. But, depending on their criticality, not all security incidents must result in messages. Some correlation rules results may just create new …

Et voici notre troisième et dernière partie consacrée aux outils d’analyse de requêtes lentes. Aujourd’hui, après le très simple mysqldumpslow et le configurable mysqlsla, nous allons examiner mk-query-digest, un des scripts Perl faisant partie de la suite Maatkit.

mk-query-digest permet d’analyser de nombreux types de journaux et présente un rapport qu’on peut configurer de multiples manières. Contrairement à mysqlsla qui ne sait lire que des fichiers journaux, mk-query-digest offre la possibilité d’analyser d’autres sources de requêtes, par exemple des paquets issus de tcpdump. Un autre point fort de cet outil est le nombre d’options disponibles, qui permettent de filtrer ou classer les entrées analysées de manière à obtenir exactement le rapport que chacun souhaite.

Comme toujours, notre propos va commencer par …

Hello,

Un post pour vous démontrer que c’est toujours intéressant de lire les documentations et que parfois, les petites lignes en bas de page peuvent révéler des informations importantes.

J’étais récemment chez un client pour un audit de performance dans un environnement Windev / …

Nous avons vu dans un précédent article comment tracer les requêtes lentes avec MySQL et quelles sont les possibilités selon la version du serveur. Si vous avez activé le journal des requêtes lentes, vous avez sans doute recueilli un certain nombre de requêtes qu’il faut maintenant analyser afin de pouvoir les optimiser ou afin de revoir le paramétrage du serveur. Cet article est le premier d’une série de trois, qui va vous montrer quelques outils qui vont vous aider dans cette analyse.

Avant toute chose, montons une petite configuration qui va nous être utile pour illustrer le fonctionnement et les limitations de chaque outil.

Prenons un serveur MySQL en version 5.1 avec la table exemple sakila et choisissons une valeur de long_query_time de 0.05s. Pourquoi une valeur aussi faible ? Tout simplement parce qu’avec une telle valeur, il n’est vraiment pas difficile des requêtes qui seront considérées …

Les informations recueillies dans le journal d’erreurs sont très intéressantes à examiner, non seulement en cas de crash, mais aussi de façon périodique pour détecter d’éventuels problèmes. Ce billet va vous rappeler le rôle de ce journal, vous indiquer quelles sont les options de configuration et vous donner quelques bonnes pratiques pour éviter les pièges les plus fréquents.

Commençons par le plus simple : que contient ce journal ? Facile : toutes les erreurs rencontrées par le serveur. Mais vous y trouverez également d’autres informations, comme par exemple les arrêts et démarrages du serveur. Par défaut, l’option log_warnings est activée (valeur à 1), ce qui signifie que les messages d’avertissement sont également présents. Si vous ne souhaitez pas avoir les message d’avertissement, il vous suffit de positionner cette variable à 0. A l’inverse, si vous voulez avoir des informations …