Announcement

Collapse
No announcement yet.

Charge élevée sur le serveur

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

  • Charge élevée sur le serveur

    Bonjour,

    Depuis quelques temps, la charge de notre serveur Nagios / Centreon à beaucoup augmenté. Cette augmentation n'est pas liée à un ajout d'hôtes ou de services.

    La charge reste stable jusqu'à la semaine 44, puis devient complètement aléatoire...

    Nagios 3.0.6 et Centreon 2.1.2 . Le serveur est une VM hébergée sur un ESX.
    Ressources dispos :
    2 cpu @ 3,2Ghz
    2Go de Ram
    250 hôtes / 1100 services


    Malgré mes recherches, je n'ai pas trouvé d'infos sur l'optimisation du serveur. Quelqu'un peut-il m'aiguiller un peu sur le sujet ?

    Merci !

    Pour info, voici le graph de charge de notre serveur sur deux mois :


    Ainsi que les stats, que je ne sais pas trop analyser:

  • #2
    Tu n'as pas ajouté d'hôte sur Nagios okai mais des VM ont-elles été ajoutées sur l'ESX depuis la semaine 44 ?
    Centreon Syslog Module Manager/Developper
    Centreon E2S Module Manager/Developper
    Centreon Enterprise Server (2.x / 3.x) : Centreon Engine 1.3.x / 1.4.x, Centreon Broker 2.6.x / 2.8.x , Centreon 2.x, Centreon-Syslog 1.5.x, Centreon E2S 2.0
    Nagios 3.x et NDOutil 1.x

    Comment


    • #3
      Quid du %ready de ta VM depuis cette semaine 44? (demande à tes admin ESX).
      Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

      Comment


      • #4
        Pas d'ajouts sur l'ESX, il est très peu chargé en VM. Les autres sont des petits services comme NTP, serveurs archivés démarrés occasionnellement.

        Je n'ai pas eu l'occasion de tester un serveur de supervision physique, je commence à me demander si ce problème de charge n'est pas lié au fait qu'il soit virtuel. Mais ce serait la première machine que je vois qui ne supporte pas la virtualisation. Si d'autres personnes peuvent me faire un retour la dessus je suis preneur.

        J'ai oublié de préciser la base, c'est une Debian 4.0 ETCH 2.6.18.

        Edit:
        naparuba, j'ai regardé sur l'ESX (pas d'admins ESX, je m'en occupe aussi) mais pas moyen d'obtenir le CPU Ready autrement qu'en realtime. Pour ce qui est de la charge de l'ESX, elle a augmenté au même moment que la courbe de charge de Nagios. La VM utiliser en moyenne 77% de ce qui lui est alloué, soit 5Hgz/5.4. Je trouve ça énorme.

        Contrairement à ce que je disais plus tôt, je me suis trompé sur la limitation de la VM en ressources. C'est bien 2Go de Ram mais 5.4Ghz de CPU en 2vCPU.

        Si je lui donne plus je n'ai pas vraiment d'utilité à la garder virtuelle car l'ESX qui héberge est un 2x 3.2Ghz.

        N'hésitez pas a me demander si je peux fournir des infos qui permettraient d'avoir une piste ! Merci pour vos débuts de réponses.

        Edit 2:

        Ok j'ai trouvé la Tech note vmware concernant les niveaux de stats du vcenter. Je passe en lvl3 pour la suite.
        Last edited by Marc; 24 November 2009, 18:04.

        Comment


        • #5
          En fait les VM sur ESX vont avoir un problème avec un nombre de VCpu > 1 (même =1 dans certains cas...) si l'hôte est chargé ; pour se voir alloué ses CPUs et donc tourner à chaque Tick système il lui faut tous ses CPUs alloués de dispos. Donc plus il y a de VCPUs et plus l'hôte est chargé, plus tu vas avoir de l'attente pour obtenir ton quotas de CPU. L'attente est le %ready justement. En realtime, il te donne quoi environs? (si > 10%, c'est pas bon )

          D'après mes tests, passer sur une VM (même nombre de VCPUs and co) ça fait perdre 40% des perfs pour Nagios. En fait c'est logique : les hyperviseurs catchs les appels systèmes. La principale consommation de Nagios sont les appels systèmes (y a qu'a regarder le %sys de ta machine pour t'en convaincre ). Appels catchés ->appels plus lents. "PAF le chien" comme dirait l'autre...

          Ensuite il y a des moyens d'améliorer ça : les tweaks de Nagios qui sont au nombres de 3:
          *pas de double FORK (c'est le meilleur)
          *pas de libération de la RAM (il laisse le soin à l'OS de le faire, peut s'activer sans trop de risque)
          *pas de MACROs d'environnements pour les checks (peut de sondes en utilisent) mais le gain est plus que limité.

          Tu peux nous donner un top et ton %ready? On va voir là où ça coince, car bon 1000 services c'est pas la mort pour une machine tout de même.
          Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

          Comment


          • #6
            Merci pour les infos, j'en apprend un peu plus !

            Voila le Realtime et un esxtop... et c'est pas top justement ! On tourne entre 5 et 30%, très variable d'ailleurs.

            Le CPU Ready est super variable, et semble dépendre de l'heure ! La je suis surpris et je ne vois pas de raison. Sur la suite du graph, je passe à 1100 average. :


            L'esxtop confirme un %Ready élevé.


            Le TOP m'apprend que c'est MySQL qui est très gourmand. Mais pourquoi...


            Penses-tu que tuner Nagios suffira, ou me conseillerais tu un passage sur serveur physique ? En fait cela fait quelques temps que je pense à passer sur du physique, mais quand j'ai vu les ressources nécessaires en VM, j'ai été calmé.

            Je peux le placer sur un serveur moins puissant (2x 2.8Ghz, 2go ram) mais physique. Si tu me dis que le ratio est d'environ 40% ca peut valoir le coup.

            Comment


            • #7
              Si tu passes en physique sur une machine équivalente, ça sera sans problèmes.

              Tu as beaucoup de VM sur l'ESX? On peut tester deux choses :
              *enlever un vCPU à la VM
              *tuner Nagios
              (*faire les deux )

              Parfois enlever un vCPU à une VM peut l'aider (si l'hôte est chargé, moins de %ready, ça peut facilement compenser la perte d'un vCPU).

              Tente avec un vCPU, si ça loose encore, on va tuner Nagios
              Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

              Comment


              • #8
                L'ESX fait tourner 4 machines :

                Nagios, un NTP, et deux vieux NT4 quasiment plus utilisés.

                Donc Nagios à quasiment l'esx pour lui seul.

                Je suis en réunion tout la journée donc je ne peux pas effectuer la manip tout de suite, mais je vais essayer de retirer un vCPU ce soir.

                Merci beaucoup pour le coup de main sur le sujet, j'étais un peu largué.

                Edit:

                J'ai vraiment un probleme avec cette VM, et il évolue en fonction de l'heure. Voila le % ready en ce moment !
                Last edited by Marc; 25 November 2009, 12:51.

                Comment


                • #9
                  Bonjour !

                  Cette nuit j'ai donc retiré un vCPU à la machine. Le résultat est sans appel ! Presque plus de %ready.





                  Par contre, je me retrouve à 100% constant et la charge est toujours élevée. De ce que j'ai vu sur le TOP, ce n'est pas nagios en lui même le problème, mais MySQL qui consomme énormément de temps CPU... Une optimisation dans ce sens vous parait-elle crédible ?




                  Sinon, j'en profite un peu (je sais que ce n'est pas bien hock mais quelqu'un à entendu parler d'une solution pour des problèmes de visibilité de services par un groupe soumis à une ACL ? J'ai des exploitants qui n'ont pas le même nombre de SVC visibles que les admins... Si oui, dites juste OUI et je chercherais

                  Comment


                  • #10
                    un admin n'est pas soumis au ACL donc OUI probable
                    Centreon Syslog Module Manager/Developper
                    Centreon E2S Module Manager/Developper
                    Centreon Enterprise Server (2.x / 3.x) : Centreon Engine 1.3.x / 1.4.x, Centreon Broker 2.6.x / 2.8.x , Centreon 2.x, Centreon-Syslog 1.5.x, Centreon E2S 2.0
                    Nagios 3.x et NDOutil 1.x

                    Comment


                    • #11
                      Et c'est toujours du %user que tu as comme CPU utilisé où il y a du %wa ?
                      Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

                      Comment


                      • #12
                        Merci pour la réponse sur les ACL, je vais me remettre à chercher

                        Pour le CPU, on peut résumer en : 15%us, 85%sy . Pas de %wa du tout. C'est le process mysqld qui est gourmand.



                        Bon, ce soir le serveur Centreon est en folie. Je pense que c'est à cause de la charge, mais il affiche énormément de "Service Check Timeout", des hôtes sont en Critical alors qu'ils vont bien. Je vais lui redonner son vCPU supplémentaire en attendant de trouver le problème.
                        Last edited by Marc; 26 November 2009, 17:34. Reason: Ajout commentaire

                        Comment


                        • #13
                          J'ai du mal à voir le %sys consommé par MySQLd. C'est %user ou %wa pour lui, le %sys je ne vois pas trop ce qu'il en ferait.

                          Tentes avec child_processes_fork_twice=0 dans nagios.cfg et regardons comment le %sys évolue.
                          Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

                          Comment


                          • #14
                            Bonjour !

                            Le changement du paramètre à été fait jeudi, et ça à changé le résultat du top. On a plutot du 50/50 entre US et SY maintenant.



                            J'ai une autre question, toujours sur le même sujet. Je m'obstine à penser que mysql me pose problème. Mais je ne suis pas connaisseur en BDD.

                            Que pensez vous de ces chiffres, ils me paraissent hallucinants !



                            Je commence à chercher sur l'optimisation SQL, ce qui est facilité par le Snapshot.

                            Comment


                            • #15
                              Teste avec http://blog.mysqltuner.com/ (il me semble que c'est le nouveau nom de tuning_primer.sh qui est un super script pour tuner MySQL)
                              Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

                              Comment

                              Working...
                              X