J'ai un script qui analyse un fichier journalier par période de 30 jours
mais qui est tres long à l'execution
chaque fichier fait entre 600Ko et 900Ko (entre 20 et 30.000 lignes), au bas
mot, une 30 de mo à analyser.
mon probleme donc est que ce script met environ 15 à 20s pour s'executer.
la bete ...
##########################
#!/usr/bin/perl
use CGI qw/:standard/;
use CGI::Carp qw(fatalsToBrowser);
use Date::Manip;
### par rapport a un jour donné, on calcule les 30 jours précédent, module
tres peu gourmand
$date = DateCalc("$annee$mois$jour","$i day",\$err);
$dir_fichier = "$date.data";
open F, "$dir_fichier";
flock F, 2 or die "lock: $!\n";
seek F, 0, 0 or die "rewind: $!\n";
while (<F>)
{
($var1, $var2, $var3) = split(/\|/,$_);
### je traite les données(nombre d'occurence) je mets le resultat dans
$resultat
}
close F or die "unlock: $!\n";
push @infos, "$date|$resultat"; ## dans un tableau pour reutilisation
ultérieure..
## il y aurait ptetre kkchose a faire la avant le $i suivant...
}
########
Via un "top" sous linux, pdt l'execution du script, ce dernier prend jusqu'a
98% du cpu... (serveur bi-xeon 2.4Ghz/2GO mem )
Si kkun a une idée je suis preneur.
Faudrait voir où le script passe du temps précisément, personnellement je suis un peu étonné du 98%.
J'ai supprimé tous les traitements, c'est l'ouverture et la lecture du fichier qui prennent le temps et les ressources.
BTW, vous êtes sûr que vous pouvez pas faire le traitement hors du Web et des CGI, par exemple dans un cron chaque jour ?
malheureusement non ;)
Patrick.
Fabrice
Samuel Mouniée
Bonjour,
Modperl ?
Faudrait voir où le script passe du temps précisément, personnellement je suis un peu étonné du 98%.
a mon sens, il n'y a rien d'inquietant. un processus peut prendre ce qu'il veut en temps processeur, c'est le scheduler qui le gere. par contre si le load de la machine augemente de trop il faut s'inquieter.
BTW, vous êtes sûr que vous pouvez pas faire le traitement hors du Web et des CGI, par exemple dans un cron chaque jour ?
un fork peut etre utile si le temps de traitement depasse le timeout apache. sinon, faire un echo toutes les minutes peut etre un bon plan ( SIGALRM ).
Patrick.
.s'nuoM
Bonjour,
Modperl ?
Faudrait voir où le script passe du temps précisément, personnellement je
suis un peu étonné du 98%.
a mon sens, il n'y a rien d'inquietant. un processus peut prendre ce
qu'il veut en temps processeur, c'est le scheduler qui le gere. par
contre si le load de la machine augemente de trop il faut s'inquieter.
BTW, vous êtes sûr que vous pouvez pas faire le traitement hors du Web et
des CGI, par exemple dans un cron chaque jour ?
un fork peut etre utile si le temps de traitement depasse le timeout
apache. sinon, faire un echo toutes les minutes peut etre un bon plan (
SIGALRM ).
Faudrait voir où le script passe du temps précisément, personnellement je suis un peu étonné du 98%.
a mon sens, il n'y a rien d'inquietant. un processus peut prendre ce qu'il veut en temps processeur, c'est le scheduler qui le gere. par contre si le load de la machine augemente de trop il faut s'inquieter.
BTW, vous êtes sûr que vous pouvez pas faire le traitement hors du Web et des CGI, par exemple dans un cron chaque jour ?
un fork peut etre utile si le temps de traitement depasse le timeout apache. sinon, faire un echo toutes les minutes peut etre un bon plan ( SIGALRM ).
Patrick.
.s'nuoM
Samuel Mouniée
Bonjour,
Bonjour à tous et toutes !
J'ai un script qui analyse un fichier journalier par période de 30 jours mais qui est tres long à l'execution chaque fichier fait entre 600Ko et 900Ko (entre 20 et 30.000 lignes), au bas mot, une 30 de mo à analyser.
mon probleme donc est que ce script met environ 15 à 20s pour s'executer.
15-20s cela reste raisonnable ...
la bete ...
########################## #!/usr/bin/perl
use CGI qw/:standard/; use CGI::Carp qw(fatalsToBrowser); use Date::Manip;
### par rapport a un jour donné, on calcule les 30 jours précédent, module tres peu gourmand $date = DateCalc("$annee$mois$jour","$i day",$err);
$dir_fichier = "$date.data";
open F, "$dir_fichier"; flock F, 2 or die "lock: $!n"; seek F, 0, 0 or die "rewind: $!n"; while (<F>) { ($var1, $var2, $var3) = split(/|/,$_); ### je traite les données(nombre d'occurence) je mets le resultat dans $resultat } close F or die "unlock: $!n";
push @infos, "$date|$resultat"; ## dans un tableau pour reutilisation ultérieure..
## il y aurait ptetre kkchose a faire la avant le $i suivant...
} ########
Via un "top" sous linux, pdt l'execution du script, ce dernier prend jusqu'a 98% du cpu... (serveur bi-xeon 2.4Ghz/2GO mem )
ce qu'il faut voir, ce n'est pas le temps CPU mais le loadavg de la machine. en gros, la charge peut monter jusqu'à 1 par CPU . donc dans votre cas : 2 .
si le loadavg est superieur à 1xnbCPU il faut regarder quel processus consomme le plus de temps CPU, et le reduire de priorité, voir le patcher pour qu'il soit moins mechant.
mais un processus qui prend 99% d'un CPU est assez commun sur des archi multi processeur ... tant que cela ne dure pas ...
Si kkun a une idée je suis preneur.
pour la partie perl : dprofpp .
dprofpp est un profileur pour les programmes perl.
sinon je vois a vue de nez : DatCalc, split et readline()/<> qui sont consommateur de temps CPU .
apres faut voir vos traitements.
merci d'avance Fabrice
.s'nuoM
Bonjour,
Bonjour à tous et toutes !
J'ai un script qui analyse un fichier journalier par période de 30 jours
mais qui est tres long à l'execution
chaque fichier fait entre 600Ko et 900Ko (entre 20 et 30.000 lignes), au bas
mot, une 30 de mo à analyser.
mon probleme donc est que ce script met environ 15 à 20s pour s'executer.
15-20s cela reste raisonnable ...
la bete ...
##########################
#!/usr/bin/perl
use CGI qw/:standard/;
use CGI::Carp qw(fatalsToBrowser);
use Date::Manip;
### par rapport a un jour donné, on calcule les 30 jours précédent, module
tres peu gourmand
$date = DateCalc("$annee$mois$jour","$i day",$err);
$dir_fichier = "$date.data";
open F, "$dir_fichier";
flock F, 2 or die "lock: $!n";
seek F, 0, 0 or die "rewind: $!n";
while (<F>)
{
($var1, $var2, $var3) = split(/|/,$_);
### je traite les données(nombre d'occurence) je mets le resultat dans
$resultat
}
close F or die "unlock: $!n";
push @infos, "$date|$resultat"; ## dans un tableau pour reutilisation
ultérieure..
## il y aurait ptetre kkchose a faire la avant le $i suivant...
}
########
Via un "top" sous linux, pdt l'execution du script, ce dernier prend jusqu'a
98% du cpu... (serveur bi-xeon 2.4Ghz/2GO mem )
ce qu'il faut voir, ce n'est pas le temps CPU mais le loadavg de la
machine. en gros, la charge peut monter jusqu'à 1 par CPU . donc dans
votre cas : 2 .
si le loadavg est superieur à 1xnbCPU il faut regarder quel processus
consomme le plus de temps CPU, et le reduire de priorité, voir le
patcher pour qu'il soit moins mechant.
mais un processus qui prend 99% d'un CPU est assez commun sur des archi
multi processeur ... tant que cela ne dure pas ...
Si kkun a une idée je suis preneur.
pour la partie perl : dprofpp .
dprofpp est un profileur pour les programmes perl.
sinon je vois a vue de nez :
DatCalc, split et readline()/<> qui sont consommateur de temps CPU .
J'ai un script qui analyse un fichier journalier par période de 30 jours mais qui est tres long à l'execution chaque fichier fait entre 600Ko et 900Ko (entre 20 et 30.000 lignes), au bas mot, une 30 de mo à analyser.
mon probleme donc est que ce script met environ 15 à 20s pour s'executer.
15-20s cela reste raisonnable ...
la bete ...
########################## #!/usr/bin/perl
use CGI qw/:standard/; use CGI::Carp qw(fatalsToBrowser); use Date::Manip;
### par rapport a un jour donné, on calcule les 30 jours précédent, module tres peu gourmand $date = DateCalc("$annee$mois$jour","$i day",$err);
$dir_fichier = "$date.data";
open F, "$dir_fichier"; flock F, 2 or die "lock: $!n"; seek F, 0, 0 or die "rewind: $!n"; while (<F>) { ($var1, $var2, $var3) = split(/|/,$_); ### je traite les données(nombre d'occurence) je mets le resultat dans $resultat } close F or die "unlock: $!n";
push @infos, "$date|$resultat"; ## dans un tableau pour reutilisation ultérieure..
## il y aurait ptetre kkchose a faire la avant le $i suivant...
} ########
Via un "top" sous linux, pdt l'execution du script, ce dernier prend jusqu'a 98% du cpu... (serveur bi-xeon 2.4Ghz/2GO mem )
ce qu'il faut voir, ce n'est pas le temps CPU mais le loadavg de la machine. en gros, la charge peut monter jusqu'à 1 par CPU . donc dans votre cas : 2 .
si le loadavg est superieur à 1xnbCPU il faut regarder quel processus consomme le plus de temps CPU, et le reduire de priorité, voir le patcher pour qu'il soit moins mechant.
mais un processus qui prend 99% d'un CPU est assez commun sur des archi multi processeur ... tant que cela ne dure pas ...
Si kkun a une idée je suis preneur.
pour la partie perl : dprofpp .
dprofpp est un profileur pour les programmes perl.
sinon je vois a vue de nez : DatCalc, split et readline()/<> qui sont consommateur de temps CPU .
apres faut voir vos traitements.
merci d'avance Fabrice
.s'nuoM
Patrick
Faudrait voir où le script passe du temps précisément, personnellement je suis un peu étonné du 98%.
a mon sens, il n'y a rien d'inquietant. un processus peut prendre ce qu'il veut en temps processeur, c'est le scheduler qui le gere.
Oui, bien entendu. Mais le script présenté ne fait que de l'I/O en gros, donc c'est étonnant que le processeur mouline autant. Peut-être un problème de disques, de swap, etc...
Patrick.
Faudrait voir où le script passe du temps précisément, personnellement
je suis un peu étonné du 98%.
a mon sens, il n'y a rien d'inquietant. un processus peut prendre ce
qu'il veut en temps processeur, c'est le scheduler qui le gere.
Oui, bien entendu. Mais le script présenté ne fait que de l'I/O en gros,
donc c'est étonnant que le processeur mouline autant.
Peut-être un problème de disques, de swap, etc...
Faudrait voir où le script passe du temps précisément, personnellement je suis un peu étonné du 98%.
a mon sens, il n'y a rien d'inquietant. un processus peut prendre ce qu'il veut en temps processeur, c'est le scheduler qui le gere.
Oui, bien entendu. Mais le script présenté ne fait que de l'I/O en gros, donc c'est étonnant que le processeur mouline autant. Peut-être un problème de disques, de swap, etc...
