Announcement

Collapse
No announcement yet.

Affichage et performance Mysql

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Affichage et performance Mysql

    Bonjour à tous,


    Je fais actuellement des tests de charge de l'interface Centreon (Centreon 2.02) avec 13000 services supervisés. J'ai remarqué que l'affichage et la navigation dans les services (pages monitoring) sont longs (une 15aine de sec pour charger une page). Après une recherche dans les requêtes lentes de Mysql, j'ai trouvé celle qui pose problème:

    "SELECT DISTINCT no.name1 as host_name, nss.process_performance_data, nss.current_state, nss.output as plugin_output, nss.current_check_attempt as current_attempt, nss.status_update_time as status_update_time, unix_timestamp(nss.last_state_change) as last_state_change, unix_timestamp(nss.last_check) as last_check, unix_timestamp(nss.next_check) as next_check, nss.notifications_enabled, nss.problem_has_been_acknowledged, nss.passive_checks_enabled, nss.active_checks_enabled, nss.event_handler_enabled, nss.is_flapping, nss.flap_detection_enabled, no.object_id, no.name2 as service_description, ns.notes, ns.notes_url, ns.action_url FROM nagios_servicestatus nss, nagios_objects no, nagios_services ns WHERE no.object_id = nss.service_object_id AND no.object_id = ns.service_object_id AND no.name1 NOT LIKE '_Module_%' AND objecttype_id = 2 AND no.name1 != '_Module_Meta' order by no.name1 ASC,no.name2 LIMIT 0,50;"


    Si j'exécute cette requête, j'obtiens ceci pour le temps d'exécution: "50 rows in set (3.61 sec)"

    Après des recherches et l'aide d'un DBA, nous nous sommes aperçu que c'est le "DISTINCT" qui posait problème car pour effectuer le tri, Mysql crée une table temporaire sur le disque et n'utilise pas la mémoire. En effet, si je lance la même requête mais sans le DISTINCT, j'obtiens le résultat suivant : 50 rows in set (0.01 sec)


    Est ce que quelqu'un à déjà rencontré ce soucis et y a t'il un moyen d'optimiser cette requête ? ou bien d'optimiser le moteur Mysql ?


    Merci de votre aide

  • #2
    Pour la requête je vais laisser les dev en parler, mais pour Mysql, quelle est la configuration "tuning"? Quelle est ta machine? As-tu encore du mou pour donner de la RAM à Mysql? Car il me semble qu'il peut créer des tables mysql temporaires en mémoire s'il en a de disponible.

    Regarde avec le script http://www.day32.com/MySQL/tuning-primer.sh si ton MySQL est bien taillé ou non.
    Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

    Comment


    • #3
      Déjà optimisé dans la 2.1 (et ça fait pas de mal)

      Si vous trouvez d'autres requêtes (de préférence dans la version 2.1 car beaucoup ont été améliorées dans la 2.1) qui sont un peu longues n'hésitez pas à nous les transmettre.

      Comment


      • #4
        Originally posted by pitpoule View Post
        Je fais actuellement des tests de charge de l'interface Centreon (Centreon 2.02) avec 13000 services supervisés. J'ai remarqué que l'affichage et la navigation dans les services (pages monitoring) sont longs (une 15aine de sec pour charger une page). Après une recherche dans les requêtes lentes de Mysql, j'ai trouvé celle qui pose problème:

        "SELECT DISTINCT no.name1 as host_name, nss.process_performance_data, nss.current_state, nss.output as plugin_output, nss.current_check_attempt as current_attempt, nss.status_update_time as status_update_time, unix_timestamp(nss.last_state_change) as last_state_change, unix_timestamp(nss.last_check) as last_check, unix_timestamp(nss.next_check) as next_check, nss.notifications_enabled, nss.problem_has_been_acknowledged, nss.passive_checks_enabled, nss.active_checks_enabled, nss.event_handler_enabled, nss.is_flapping, nss.flap_detection_enabled, no.object_id, no.name2 as service_description, ns.notes, ns.notes_url, ns.action_url FROM nagios_servicestatus nss, nagios_objects no, nagios_services ns WHERE no.object_id = nss.service_object_id AND no.object_id = ns.service_object_id AND no.name1 NOT LIKE '_Module_%' AND objecttype_id = 2 AND no.name1 != '_Module_Meta' order by no.name1 ASC,no.name2 LIMIT 0,50;"


        Si j'exécute cette requête, j'obtiens ceci pour le temps d'exécution: "50 rows in set (3.61 sec)"

        Après des recherches et l'aide d'un DBA, nous nous sommes aperçu que c'est le "DISTINCT" qui posait problème car pour effectuer le tri, Mysql crée une table temporaire sur le disque et n'utilise pas la mémoire. En effet, si je lance la même requête mais sans le DISTINCT, j'obtiens le résultat suivant : 50 rows in set (0.01 sec)


        Est ce que quelqu'un à déjà rencontré ce soucis et y a t'il un moyen d'optimiser cette requête ? ou bien d'optimiser le moteur Mysql ?
        Bonjour,

        En effet, l'équipe de Centreon s'est rendue compte de ce souci d'affichage. Ce problème a été travaillé avec l'un des meilleurs spécialistes MySQL et devrait être corrigé dans la version 2.1.

        As tu pu testé la version 2.1-RC8 avec tes données? Je sais qu'elle n'est pas considéré comme stable mais pourrais tu faire des tests sur un serveur de test?
        Chef de Projet chez MERETHIS

        Comment


        • #5
          Originally posted by naparuba View Post
          Pour la requête je vais laisser les dev en parler, mais pour Mysql, quelle est la configuration "tuning"? Quelle est ta machine? As-tu encore du mou pour donner de la RAM à Mysql? Car il me semble qu'il peut créer des tables mysql temporaires en mémoire s'il en a de disponible.

          Regarde avec le script http://www.day32.com/MySQL/tuning-primer.sh si ton MySQL est bien taillé ou non.
          Merci pour le script, je l'ai lancé et a priori les paramètres sont bons.

          C'est une config un peu particulière : c'est un serveur Sun de type T2 avec des core multithreadés. Ce type de serveur est optimisé pour les applications massivement multi threads. Le but de mon "étude" est de vérifier si cette archi n'est pas pénalisante pour Nagios et Centreon.

          En ce qui concerne la RAM, il y a 32Go sur le serveur mais comme je travaille sur des zones, je ne sais pas si je suis limité en RAM.

          Comment


          • #6
            Originally posted by cedric.temple View Post
            Bonjour,

            En effet, l'équipe de Centreon s'est rendue compte de ce souci d'affichage. Ce problème a été travaillé avec l'un des meilleurs spécialistes MySQL et devrait être corrigé dans la version 2.1.

            As tu pu testé la version 2.1-RC8 avec tes données? Je sais qu'elle n'est pas considéré comme stable mais pourrais tu faire des tests sur un serveur de test?
            Je pense que je vais tester la nouvelle version, en effet

            Sinon pour cette requête, en attendant mieux, j'ai viré le "DISTINCT" et rajouté une clause dans le where sur le champ nagios_services.config_type... je comprends pas d'ailleurs pourquoi les données dans cette table sont dupliquées... avec une fois config_type= 0 et l'autre fois config_type=1... vivement le broker Centreon

            Comment


            • #7
              Originally posted by pitpoule View Post
              [...] c'est un serveur Sun de type T2 avec des core multithreadés. [...] En ce qui concerne la RAM, il y a 32Go [...]
              Ah en effet, c'est un vrai serveur là
              Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

              Comment

              Working...
              X