Charge mémoire de l interface

[krbian]

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?

[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.

[julio]

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...

[DonKiShoot]

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 ?

[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.

[DonKiShoot]

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:

[julio]

bah ui mais bon... encore un peu de patience...

[krbian]

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

[templuche]

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.

[krbian]

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

[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 ?

[DonKiShoot]

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