optimiser munin-graph par rapport à votre nombre de core/cpu

J'utilise depuis plusieurs années munin dans les deux laboratoires du CNRS que j'administre. Je ne vais pas ici vous faire une présentation de munin qui est déjà plus que complète sur d'autres sites tel que sur wikipedia. De nombreux how-to sont également présents sur google.

L'un de ces nombreux avantages est la facilité d'écrire des plugins que vous pouvez également piocher sur le site du projet MuninExchange. Vous pouvez très facilement écrire ces plugins pour monitorer tout et n'importe quoi comme les entrées sorties en provenance de la chatière, à partir du moment ou vous avez le matériel envoyant le signal adéquat à l'ordi .

Ce Hack est en fait inspiré de celui de nico sur son site rottenbytes.info il c'est lui même inspiré du site CodeWord: Apokalyptik.

Il s'agit ici d'optimiser le script munin-graph afin d'en augmenter la vitesse d'exécution. Ce script écrit en Perl fait plutôt bien son boulot, mais lentement. On peut facilement lors du rechargement d'une page se retrouver avec des images à moitié chargées car non terminées de générer.

Les deux premiers hack ont augmentés drastiquement la vitesse d'exécution afin d'avoir des graphes générés aussi vite que possible. Ces hacks fonctionnent très bien mais ont la fâcheuse tendance à surcharger la machine si le nombre de graphe à générer est trop grand.

J'ai donc légèrement tunné le hack présent sur rottenbytes pour que le nombre de fork soit limité par la charge de la machine en fonction du nombre de cpu/core et de la charge globale de la machine.

Ce tunning ne fonctionne pour l'instant que sous FreeBSD mais est facilement adaptable à tout autres systèmes. J'aurai de toute façon besoin bientôt de l'adapter pour Debian.

J'ai utilisé le port p5-BSD-Sysctl.

Path:   /usr/ports/sysutils/p5-BSD-Sysctl
Info:   Fetch sysctl values from BSD-like systems

Une petit requête google bien placé devrait vous faire tomber sur le site de l'auteur. Les quelques exemples de présentation suffisent à en comprendre le principe.

Près requis :

• être sur la machine "serveur" munin et localiser munin-graph (ici sous FreeBSD) :

root@myhost:~# locate munin-graph
[...]
/usr/local/share/munin/munin-graph
[...]

Hack :

• 1 : ajouter la fonction suivante à munin-graph :

sub myforked_processnode {
        my ($domain, $code) = @_;
        my $loadavg = sysctl('vm.loadavg');
        my $ncpu = sysctl('hw.ncpu');
        my $max = $ncpu * 4;
        if ($loadavg->[1] > $max) { $max = $max / 2 }
        my $counter = 0;
        for my $key ( keys %{$config->{domain}->{$domain}->{node}}) 
              {
                wait unless ++ $counter <= $max;                                                                                          
                die "Fork failed: $!\n" unless defined (my $pid = fork);
                exit $code -> ($domain,$key,$config->{domain}->{$domain}->{node}->{$key}) unless $pid;
              }
        1 until -1 == wait;
      }

• 2 : modifier la fonction process_domain toujours dans munin-graph :

sub process_domain {
    my ($domain) = @_;
#    for my $key ( keys %{$config->{domain}->{$domain}->{node}}) {                                                                           
#       my $node_time= Time::HiRes::time;                                                                                                    
#                                                                                                                                            
#       process_node($domain,$key ,$config->{domain}->{$domain}->{node}->{$key} );                                                           
#       $node_time = sprintf ("%.2f",(Time::HiRes::time - $node_time));                                                                      
#       logger ("Processed node: $key ($node_time sec)");                                                                                    
#       print STATS "GN|$domain|$key|$node_time\n" unless $skip_stats;                                                                       
#                                                                                                                                            
#    }                                                                                                                                       
    myforked_processnode($domain, \&process_node);
}

Résultats :

Ces résultats ont été obtenu sur un Intel(R) Xeon(TM) CPU 3.20GHz Dual Core avec 1Go de Ram. Il surveille une dizaine de serveurs et une centaine de postes utilisateurs. Les résultats sont à prendre avec parcimonie car les temps de génération des graphes sont variables. Je présente ici les résultats moyens.

On peut voir ici que le hack current présenté ici ne charge pas plus que de raison la machine.

Les résultats semblent être plus rapide car il vaut mieux moins de process plus occupé que beaucoup trop de process se répartissant la charge globale. Le code ci-présent en plus de ceux qui ont servi d'inspiration détermine le nombre de process en fonction de la charge et du nombre de cpu/core.

• munin-graph du package d'installation :

munin@myhost:/root$ time /usr/local/share/munin/munin-graph
version d'origine : real    1m37.166s
munin@myhost:/root$ ps aux | grep munin-graph | grep -v emacs | grep -v grep | wc -l
       1 

note : un seul process qui fait de sont mieux.

• version rottenbytes.info :

munin@myhost:/root$ time /usr/local/share/munin/munin-graph
version d'origine : real    0m49.216s
munin@myhost:/root$ ps aux | grep munin-graph | grep -v emacs | grep -v grep | wc -l
       25 

note : le process fork 25 fois et la charge ce repartie entre ces différents process.

•  current hack :

munin@myhost:/root$ time /usr/local/share/munin/munin-graph
version d'origine : real    0m25.385s
munin@myhost:/root$ ps aux | grep munin-graph | grep -v emacs | grep -v grep | wc -l
       8 

note : le process fork "4 * (nombre de cpu)" et si la charge devient supérieure à "4 * (nombre de cpu)" le nombre de threads max est divisé par 2.