Announcement

Collapse
No announcement yet.

Charge mémoire de l interface

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

  • Charge mémoire de l interface

    Bonjour,

    Je teste actuellement Oreon.
    J'utilise un serveur : bi-pro 2,4GHZ Xeon et 1G de RAM avec nagios 1.2 et oreon 1.2.2RC2. Je supervise environ 100 hosts et 400 services (à terme plus de 1000 services).

    J'ai remarqué qu au fur et à mesure que j'ajoutais ces services , l'interface ralentissait, n'affichait que la moitié des pages ou ne s'affichait plus rien . (Détails des services et Historisques des évenments principalement)

    Dans les log d'apache2 j ai remarqué ce message :
    Allowed memory size of 8057280 bytes exhausted (tried to allocate 64 bytes)

    J'ai donc augmenté la quantité de mémoire dédiée à un script php (8M par défaut)
    Cela a fonctionné un moment, mais lorsque j ai voulu regarder mes logs la limite mémoire nécessaire était d'environ 40M. (rotation des log journaliere environ 70000 lignes, je vais certainement etre obligé d'augmenter la fréquence de rotation)

    En modifiant, ces paramètres j ai pus règler le problème de disponibilité des pages mais pas de leur lenteur.

    Suis je le seul à me confronter à la lourdeur de l'interface? probleme avec ma config?
    D'autre personne utilise-t-elle Oreon avec un réseau important?
    ...

  • #2
    Oui effectivement, la somme d'objet cree fait monter la memoire. Selon ton parc il faut effectivement faire evoluer la memory_limit.

    Peut etre que la compatibilite avec PHP5 resoudera en partie ce probleme.
    Romain Le Merlus
    Centreon Forge
    MERETHIS

    Comment


    • #3
      nan nan c normal, nous somes en train d'essayer de l'alleger... mais c etonnant car nous sommes deja monté bcp plus haut en charge...
      Julien Mathis
      Centreon Project Leader
      www.merethis.com |

      Comment


      • #4
        Originally posted by rom
        Oui effectivement, la somme d'objet cree fait monter la memoire. Selon ton parc il faut effectivement faire evoluer la memory_limit.

        Peut etre que la compatibilite avec PHP5 resoudera en partie ce probleme.
        Tu as une deadline pour le support de php5 ? Une RC ?
        Intel(R) Xeon(TM) CPU 3.4GHz - MemTotal : 1034476 kB
        Centreon 2.4.1 - Nagios 3.2.1 - Nagios Plugins 1.4.15 - Manubulon Plugins tuné
        Fedora Core 5 - 2.6.20-1.2320

        Comment


        • #5
          C vrai qu'on devrait mettre une roadmap.
          En gros, on veut etre avec la prochaine version super compatible avec la configuration de Nagios 1.x. Ca touche toutes les valeurs == 0, le choix des bonnes valeurs de template ou de definitions, les tricks de nagios....

          Ensuite viendra le support PHP5. Puis Nagios 2.x

          Et ensuite on integrera de nouveaux modules.
          Romain Le Merlus
          Centreon Forge
          MERETHIS

          Comment


          • #6
            Originally posted by rom
            C vrai qu'on devrait mettre une roadmap.
            En gros, on veut etre avec la prochaine version super compatible avec la configuration de Nagios 1.x. Ca touche toutes les valeurs == 0, le choix des bonnes valeurs de template ou de definitions, les tricks de nagios....

            Ensuite viendra le support PHP5. Puis Nagios 2.x

            Et ensuite on integrera de nouveaux modules.
            :cry: c pas pour toute suite ! :cry:
            Intel(R) Xeon(TM) CPU 3.4GHz - MemTotal : 1034476 kB
            Centreon 2.4.1 - Nagios 3.2.1 - Nagios Plugins 1.4.15 - Manubulon Plugins tuné
            Fedora Core 5 - 2.6.20-1.2320

            Comment


            • #7
              bah ui mais bon... encore un peu de patience...
              Julien Mathis
              Centreon Project Leader
              www.merethis.com |

              Comment


              • #8
                je viens d'utiliser xdebug pour voir la taille mémoire utiliser par les différentes pages d'oreon

                Pour les intéressés j'utilise xdebug fournit par PEAR
                J'ai éditer oreon.php :
                des le debut du fichier j ai mis :
                xdebug_start_trace();
                et à la fin :
                $memory = xdebug_memory_usage() / 1000000;
                $memory = sprintf ("%.2f",$memory);
                $memory = "<h6 style=\"color: blue\">Memory Used = " . $memory . "M</h>";
                echo $memory;
                xdebug_stop_trace();


                J'ai noté deux choses :
                - quelque soit la page la charge mémoire est d'au moins 8M et cela meme lorsqu'il n'y a aucun traitement à part l'affichage html , est ce dû aux nombreuses informations contenues dans la session?
                - plus le fichier de log est important et plus la charge monte (16M pour un fichier de 12000 lignes la page est affiché en 22sec !), peut etre que l'utilisation de template HTML pourrait améliorer cela? car le traitement qui fait 16M, peut quasiment se resumer à une ouverture d'un fichier de log et a l affichage de celui-ci.

                je trouve que cela fait beaucoup de mémoire...

                Je pense que reprendre la meme méthode d'affichage que pour la configuration, cad la répartition des entrées sur plusieurs pages, serait bien. Ca eviterais de charger le navigateur du client
                ...

                Comment


                • #9
                  Bonjour,

                  - plus le fichier de log est important et plus la charge monte
                  Intéressant. Je suppose que tu parles du fichier de log Nagios (nagios.log) et pas du fichier d'historique d'Oreon? C'est bien cela?

                  Merci.

                  Comment


                  • #10
                    Oui c'est bien le fichier nagios.log.

                    plus le fichier de log est important et plus la charge monte
                    Lorsque je parle de monter en charge, je ne parle pas seulement du serveur mais aussi du client. Car la la page html devient trop importante par rapport à ce qu accepete un navigateur. C'est pourquoi je parlais de découpage de la page.

                    voilou
                    ...

                    Comment


                    • #11
                      oui tout a fait nous sommes concient du pb. En fait oreon trimbale toute la conf de Nagios sur chacune des pages. Il ne load qu'une fois la base tant qu'il n'y a pas de changement. Nous somme justement en train d'etudier qq chose pour allerger les pages. Si PHP pouvait avoir la patate de CGI sa serait genial... Personne ne veut inventer un nouveau langage ?
                      Julien Mathis
                      Centreon Project Leader
                      www.merethis.com |

                      Comment


                      • #12
                        Originally posted by julio
                        oui tout a fait nous sommes concient du pb. En fait oreon trimbale toute la conf de Nagios sur chacune des pages. Il ne load qu'une fois la base tant qu'il n'y a pas de changement. Nous somme justement en train d'etudier qq chose pour allerger les pages. Si PHP pouvait avoir la patate de CGI sa serait genial... Personne ne veut inventer un nouveau langage ?
                        Tu réécris en c et t'auras un beau CGI
                        Intel(R) Xeon(TM) CPU 3.4GHz - MemTotal : 1034476 kB
                        Centreon 2.4.1 - Nagios 3.2.1 - Nagios Plugins 1.4.15 - Manubulon Plugins tuné
                        Fedora Core 5 - 2.6.20-1.2320

                        Comment

                        Working...
                        X