Discussion :

[Fango]

Bonjour a tous,

j'ai un script qui tourne sur une trentaine de Go de fichiers de logs dans le but d'etablir des stats. Il prend chaque fichier, le lit ligne par ligne, cherche quelques patterns, construit 2 gigantesques hash maps (et une localisee par fichier), et log dans un fichier de resultat. Il marche tres bien mais a priori il va tourner pendant une bonne dizaine de jours...

Auriez vous des recommandations pour essayer d'optimiser le temps d' execution ?

Merci.

[djibril]

Bah avoir des fichiers plus petit . Sérieusement, si ton script est long, bah c'est qu'il y a beaucoup de données à gérer, donc je ne vois pas comment tu pourrais faire autrement. Est ce un script qui tournera en boucle ? Pourquoi utiliser les hashmap ? Sans script, difficile de se faire une idée ?

[Fango]

Hello,

merci de ta reponse. Je pense que la limitation viens des hash map... C'est un script qui prend tous les fichiers d' un repertoire, verifie que le nom correspond a un pattern et les lit ligne par ligne. Il recherche une ligne (une seul expression reguliere) dans chaque fichier et update une hash map qui tient a jour le nombre de lignes differentes globalement en gros et une autre qui le fait par tranche horaire. Ca donne a peu pres ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
my %hash = ();
my %hash_time = ();
my @update_list = ();
 
Foreach file
  if (file =~ /pattern/) {
    &Extract();
  }
 
  // iterate on the hash maps and compute stats
 
#-----------------------------
sub Extract
{
  open (IN, <file);
  while ($line=<IN>)
  {
    if (line =~ /pattern/){
      my @res_list=grep ( { $_ eq $update } @update_list);
      if (@res_list > 0){
        $hash{$update}++;
      }else{   # Not in the list
         $update_list[@update_list] = $update;
	  # Init
          $hash{$update}=1;
  	  $hash_time{$time_key}++;
      }
    }
  }
  close IN;
}

J' ai l'impression que je ne peux pas optimiser grand chose et que la limitation vient de Perl J' ai deja enlever le process d' ecrire des logs dans un fichier, mais ca n'a pas vraiment eu d' impact sur les perfs

[djibril]

euh, ton code perl est un peu bizarre car il y a des syntaxes pas très bien écrites. De plus, je ne vois pas l'intérêt des hashmap, pourquoi ne pas mettre tes résultats dans un fichier (avec >>) à la suite.

[jabbounet]

Combien de CPU/coeurs possède ta machine?

si elle en a plusieurs il pourrait être intéressant de multi-threader ton script.



si le fichiers sont neombreux et petit j'aurais plutôt fait ceci pour directement avoir les lignes qui m'intéressent dans le fichier.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
open FILE, "<", "file" or die $!
my @selectedLines = grep (/pattern/,<FILE>);
close FILE
 
## traitement sur @seledtedLines pour avoir la hashmap

là ou je suis je n'ai pas perl sour la main mais l'esprit et là je pense.

[Fango]

euh, ton code perl est un peu bizarre car il y a des syntaxes pas très bien écrites. De plus, je ne vois pas l'intérêt des hashmap, pourquoi ne pas mettre tes résultats dans un fichier (avec >>) à la suite.

Oui, je l'ai ecrit en "pseudo Perl" pour aller plus vite et faire en sorte que le code ne soit pas long.
Les hash maps, c'est pour associer un update (chaine de caractere dans la ligne que je recherche dans les fichiers) a son nombre d'occurences dans tous les fichiers du repertoire.

Combien de CPU/coeurs possède ta machine?

si elle en a plusieurs il pourrait être intéressant de multi-threader ton script.



si le fichiers sont neombreux et petit j'aurais plutôt fait ceci pour directement avoir les lignes qui m'intéressent dans le fichier.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
open FILE, "<", "file" or die $!
my @selectedLines = grep (/pattern/,<FILE>);
close FILE
 
## traitement sur @seledtedLines pour avoir la hashmap

là ou je suis je n'ai pas perl sour la main mais l'esprit et là je pense.

Je lance ce script sur un serveur Linux. J'ai fait cat /proc/cpuinfo et apparemment il y a 4 processeurs Le probleme avec le multi-thread, c'est que je ne veux pas traiter chaque fichier dans leur coin, mais en connaissant les updates qui ont deja ete faits dans les autres fichiers deja traites. Je ne connais pas les threads en perl mais je ne pense pas que ca s' appliquerait dans le cas present.
Je vais essayer avec le bout de code que tu m' as file, meme si les fichiers sont gros, ca ameliorera peut etre les perfs ! Quelle est la difference par rapport a une expression reguliere ? C' est vraiment plus efficace ?

[50Nio]

Ca sera plus efficace car tu ouvriras moins de ligne sur le fichier dans ton script Perl.
Après tu vas quand même boucler sur tout le fichier pour trouver tes occurences, mais grep doit être plus optimisé qu'un parcours systématique de tout le fichier par un while.

Avant toute chose, je testarais comme suit:
- juste boucler sur tes fichiers, en ne fesant que le parcours et aucun traitement (une fois avec ta méthode initiale, une fois avec la methode qui greppe directement)
- ensuite refaire le même en faisant tes traitements

Tu verras déjà où le temps est passé, et s'il faut travailler sur l'ouverture et le parcours des fichiers ou si tes traitements sont aussi à optimiser.

Dans tous les cas selon ta machine, parser des gigas de log prendra forcément du temps. :-( Pour éventuellement gagner encore plus, ptêt un programme C compilé sera plus rapide, mais je ne pense pas que tu gagnes beaucoup car le progrmma Perl ne doit être compilé en langage machine qu'une fois, pas à chaque ligne -à vérifier ou infirmer-

[jabbounet]

Ca sera plus efficace car tu ouvriras moins de ligne
Dans tous les cas selon ta machine, parser des gigas de log prendra forcément du temps. :-( Pour éventuellement gagner encore plus, ptêt un programme C compilé sera plus rapide, mais je ne pense pas que tu gagnes beaucoup car le progrmma Perl ne doit être compilé en langage machine qu'une fois, pas à chaque ligne -à vérifier ou infirmer-

Perl est un langage de script moderne, le script est "compilé" au moment ou tu le lance le script et ensuite c'est que du binaire ou du pseudo code.

Je lance ce script sur un serveur Linux. J'ai fait cat /proc/cpuinfo et apparemment il y a 4 processeurs Le probleme avec le multi-thread, c'est que je ne veux pas traiter chaque fichier dans leur coin, mais en connaissant les updates qui ont deja ete faits dans les autres fichiers deja traites. Je ne connais pas les threads en perl mais je ne pense pas que ca s' appliquerait dans le cas present.

tu as donc une section critique ici.


Après ne connaissant pas la finalité exacte de ton script, quelques exemple de fichier d'entrées et de sortie serait bienvenue, ton problème peu peu être se résoudre de façon plus simple ou plus complexe.
http://www.perlmonks.org/?node_id=597051
http://www.perl.com/pub/a/2004/08/09...ne.html?page=2
http://stackoverflow.com/questions/8...ns-on-the-same

[Fango]

Merci ! J'ai utilisé toutes vos recommendations, mais c'etait encore le remplissage des hash maps qui posaient pb. Du coup, j'ai migré ce code dans un petit programme c++ (sans chercher a l'optimiser particulierement) en adaptant le script perl. Et la, je suis passe de 40 minutes a 4 secondes de process en testant sur 10 fichiers de log a parser...

Encore merci en tout cas, maintenant j'ai un super script multi threadé interfacé avec un binaire c++... aucun rapport avec mon script initial Et c'etait vraiment interessant de tester les threads en perl.

[djibril]

mouais, je reste persuadé que c'est ton algo en perl qui pose souci, car passer de 40 min à 4 sec juste en changeant de langage de programmation, je trouve ça bizarre. Mais, bon, tant mieux si tu arrives à faire ce que tu veux.

[jabbounet]

pour les threads


http://perldoc.perl.org/perlthrtut.h...-Perl-threads?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
use threads;
 
my $thr = threads->create(\&sub1);
 
sub sub1 {
print("In the thread\n");
 
}

[jabbounet]

oui ça fait pas mal de différence en temps ça ne devrais pas être aussi grand.