Bonjour,
Quelqu'un parmi vous aurait il une idée pour réduire la consommation des
ressources lors de l'exécution d'un script ?
La problématique est la suivante, je parse 4 fichiers de log de 50 Mo sur
des DNS pour récupérer les IP toutes les heures sur des station Sun T1 105,
et je me rend compte que la consommation CPU atteint les 99% durant 3
minutes !!!
Je redoute un ralentissement de l'application qui tourne sur le serveur,
Bind 9.3.1, cad un timeout sur des requêtes lorsque le script tourne.
J'ai essaye 2 méthodes, mais la charge CPU ne se reduit pas, j'en cherche
donc une autre.
1 - Passer les fichiers dans une liste, ensuite utiliser la liste pour
compter.
@liste=("queries.log", "queries.log.0", "queries.log.1", "queries.log.2");
foreach $fichier (@liste) {
open(FIC, "< $fichier") || die "Erreur ouverture du fichier $fichier: $!";
while (<FIC>) {
push (@liste_ip, <FIC>);
};
};
close (FIC);
2 - Lire chaque fichier et traiter ligne à ligne.
my $today = time();
my $minus=$today - 3600;
my $need = strftime "%d-%b-%Y %H", localtime($minus);
@liste=("queries.log", "queries.log.0", "queries.log.1","queries.log.2");
foreach $fichier (@liste) {
open(FIC, "< $fichier") || die "Erreur ouverture du fichier $fichier: $!";
while ($line = <FIC>) {
chomp ($line);
if ($line =~ /^($need)(.*) client (.*)\#(.*) view (.*)$/)
{
$total{$3} += 1;
}
};
};
close (FIC);
Geo
Supprimer nospam dans le domaine pour obtenir mon mail.
277 requêtes DNS par seconde !!! Ça c'est du troyen !!! C'était un serveur client très mal configuré qui utilisait nos DNS.
La fonction (de filtrage des denis de service ou DOS) que vous décrivez me semblerait beaucoup plus facile à mettre en oeuvre a priori par un firewall plutôt que par une analyse a posteriori des logs de bind. De plus, plutôt que de s'apercevoir de l'abus au bout d'une heure et de bloquer tout pendant 24h00, votre firewall ne ferait que ralentir les clients qui abusent... en temps réel. Oui, cela permettrait de proteger les serveurs mais pas le client.
L'obljectif, utopique je dois l'admettre, est d'informer les clients sur les faiblesse de leur machines ( spyware, troyen etc ) de tel sorte qu'ils puissent les corriger. Mais, en parlant de foold dns, il existe un soft "dns_flood" qui lui fonctionne en temps reel log les activités abusives. http://www.adotout.com/dnsflood.html
Merci pour l'info, je vais soumettre l'idée du firewall.
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/> Georges
277 requêtes DNS par seconde !!! Ça c'est du troyen !!!
C'était un serveur client très mal configuré qui utilisait nos DNS.
La fonction (de filtrage des denis de service ou DOS) que vous
décrivez me semblerait beaucoup plus facile à mettre en oeuvre a
priori par un firewall plutôt que par une analyse a posteriori des
logs de bind. De plus, plutôt que de s'apercevoir de l'abus au bout
d'une heure et de bloquer tout pendant 24h00, votre firewall ne ferait
que ralentir les clients qui abusent... en temps réel.
Oui, cela permettrait de proteger les serveurs mais pas le client.
L'obljectif, utopique je dois l'admettre, est d'informer les clients sur les
faiblesse de leur machines ( spyware, troyen etc ) de tel sorte qu'ils
puissent les corriger.
Mais, en parlant de foold dns, il existe un soft "dns_flood" qui lui
fonctionne en temps reel log les activités abusives.
http://www.adotout.com/dnsflood.html
Merci pour l'info, je vais soumettre l'idée du firewall.
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Georges
277 requêtes DNS par seconde !!! Ça c'est du troyen !!! C'était un serveur client très mal configuré qui utilisait nos DNS.
La fonction (de filtrage des denis de service ou DOS) que vous décrivez me semblerait beaucoup plus facile à mettre en oeuvre a priori par un firewall plutôt que par une analyse a posteriori des logs de bind. De plus, plutôt que de s'apercevoir de l'abus au bout d'une heure et de bloquer tout pendant 24h00, votre firewall ne ferait que ralentir les clients qui abusent... en temps réel. Oui, cela permettrait de proteger les serveurs mais pas le client.
L'obljectif, utopique je dois l'admettre, est d'informer les clients sur les faiblesse de leur machines ( spyware, troyen etc ) de tel sorte qu'ils puissent les corriger. Mais, en parlant de foold dns, il existe un soft "dns_flood" qui lui fonctionne en temps reel log les activités abusives. http://www.adotout.com/dnsflood.html
Merci pour l'info, je vais soumettre l'idée du firewall.
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/> Georges
Patrick Mevzek
Cependant, lors de la rotation des logs le fichier change de nom ( .log en log.0, log.0 en log.1 etc ), et si les requetes sont excessives ( + 1 000 000 de requetes pour un ip en une heure !!! ), le debut de ligne se trouve dans le 2 eme fichier de log. La manipe devient un peu tordu.
Regardez du côté de File::Tail
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Cependant, lors de la rotation des logs le fichier change de nom ( .log en
log.0, log.0 en log.1 etc ), et si les requetes sont excessives ( + 1 000
000 de requetes pour un ip en une heure !!! ), le debut de ligne se trouve
dans le 2 eme fichier de log. La manipe devient un peu tordu.
Regardez du côté de File::Tail
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Cependant, lors de la rotation des logs le fichier change de nom ( .log en log.0, log.0 en log.1 etc ), et si les requetes sont excessives ( + 1 000 000 de requetes pour un ip en une heure !!! ), le debut de ligne se trouve dans le 2 eme fichier de log. La manipe devient un peu tordu.
Regardez du côté de File::Tail
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
La problématique est la suivante, je parse 4 fichiers de log de 50 Mo sur des DNS pour récupérer les IP toutes les heures sur des station Sun T1 105, et je me rend compte que la consommation CPU atteint les 99% durant 3 minutes !!!
Et alors, où est le problème ? Votre machine travaille : c'est son rôle ;-) Le problème ? ; ))) Les seuils qui déclanchent une alarme à la supervision
si la charge CPU > 80%.
Je redoute un ralentissement de l'application qui tourne sur le serveur, Bind 9.3.1, cad un timeout sur des requêtes lorsque le script tourne. J'ai essaye 2 méthodes, mais la charge CPU ne se reduit pas, j'en cherche donc une autre.
Il ne sert strictement à rien de réduire la charge de la CPU. Elle est faite pour travailler. Et si c'est à 100% c'est là où elle travaille le mieux. Si elle n'est pas à 100%, c'est qu'elle attend à ne rien faire !
Votre problème n'est pas qu'elle travaille beaucoup mais plutôt à quoi elle travaille : c'est donc un problème de priorité ! Baissez la priorité de votre script pour qu'il soit beaucoup moins prioritaire que bind. Par exemple, en le lançant via :
nice +10 lescript.pl
Comme ça, votre CPU travaillera à 100% mais utilisera sa puissance de calcul prioritairement pour bind (et autres processus avec priorité normal) puis pour votre script (mais uniquement si elle n'a rien à faire d'autre). Oui cette solution semble la meilleurs. Je changerai les timing si le parse
dépasse les 3 minutes.
1 - Passer les fichiers dans une liste, ensuite utiliser la liste pour compter.
C'est idiot parce que cela oblige votre script à stocker en mémoire le fichier entier. S'il est très gros, c'est même impossible. Il faut bien commencer avec quelque chose ; ))) D'autant plus que j'ai 2 Go
de memoire disponible. J'ai une question sur ce point précis : le rapport chargement en memoire des données puis traitement est il plus lourd que le l'ouverture du fichier et le parsing ligne à ligne pour perl ?
2 - Lire chaque fichier et traiter ligne à ligne.
C'est la bonne méthode. Ouf !!! ; )))))))))))))))))))
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/> Merci pour toutes ces précisions.
Georges
"Paul Gaborit" <Paul.Gaborit@invalid.invalid> a écrit dans le message de
news: r764t263fk.fsf@vaugirard.enstimac.fr...
La problématique est la suivante, je parse 4 fichiers de log de 50 Mo sur
des DNS pour récupérer les IP toutes les heures sur des station Sun T1
105,
et je me rend compte que la consommation CPU atteint les 99% durant 3
minutes !!!
Et alors, où est le problème ? Votre machine travaille : c'est son
rôle ;-)
Le problème ? ; ))) Les seuils qui déclanchent une alarme à la supervision
si la charge CPU > 80%.
Je redoute un ralentissement de l'application qui tourne sur le serveur,
Bind 9.3.1, cad un timeout sur des requêtes lorsque le script tourne.
J'ai essaye 2 méthodes, mais la charge CPU ne se reduit pas, j'en cherche
donc une autre.
Il ne sert strictement à rien de réduire la charge de la CPU. Elle est
faite pour travailler. Et si c'est à 100% c'est là où elle travaille
le mieux. Si elle n'est pas à 100%, c'est qu'elle attend à ne rien
faire !
Votre problème n'est pas qu'elle travaille beaucoup mais plutôt à quoi
elle travaille : c'est donc un problème de priorité ! Baissez la
priorité de votre script pour qu'il soit beaucoup moins prioritaire
que bind. Par exemple, en le lançant via :
nice +10 lescript.pl
Comme ça, votre CPU travaillera à 100% mais utilisera sa puissance de
calcul prioritairement pour bind (et autres processus avec priorité
normal) puis pour votre script (mais uniquement si elle n'a rien à
faire d'autre).
Oui cette solution semble la meilleurs. Je changerai les timing si le parse
dépasse les 3 minutes.
1 - Passer les fichiers dans une liste, ensuite utiliser la liste pour
compter.
C'est idiot parce que cela oblige votre script à stocker en mémoire le
fichier entier. S'il est très gros, c'est même impossible.
Il faut bien commencer avec quelque chose ; ))) D'autant plus que j'ai 2 Go
de memoire disponible.
J'ai une question sur ce point précis : le rapport chargement en memoire des
données puis traitement est il plus lourd que le l'ouverture du fichier et
le parsing ligne à ligne pour perl ?
2 - Lire chaque fichier et traiter ligne à ligne.
C'est la bonne méthode.
Ouf !!! ; )))))))))))))))))))
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Merci pour toutes ces précisions.
La problématique est la suivante, je parse 4 fichiers de log de 50 Mo sur des DNS pour récupérer les IP toutes les heures sur des station Sun T1 105, et je me rend compte que la consommation CPU atteint les 99% durant 3 minutes !!!
Et alors, où est le problème ? Votre machine travaille : c'est son rôle ;-) Le problème ? ; ))) Les seuils qui déclanchent une alarme à la supervision
si la charge CPU > 80%.
Je redoute un ralentissement de l'application qui tourne sur le serveur, Bind 9.3.1, cad un timeout sur des requêtes lorsque le script tourne. J'ai essaye 2 méthodes, mais la charge CPU ne se reduit pas, j'en cherche donc une autre.
Il ne sert strictement à rien de réduire la charge de la CPU. Elle est faite pour travailler. Et si c'est à 100% c'est là où elle travaille le mieux. Si elle n'est pas à 100%, c'est qu'elle attend à ne rien faire !
Votre problème n'est pas qu'elle travaille beaucoup mais plutôt à quoi elle travaille : c'est donc un problème de priorité ! Baissez la priorité de votre script pour qu'il soit beaucoup moins prioritaire que bind. Par exemple, en le lançant via :
nice +10 lescript.pl
Comme ça, votre CPU travaillera à 100% mais utilisera sa puissance de calcul prioritairement pour bind (et autres processus avec priorité normal) puis pour votre script (mais uniquement si elle n'a rien à faire d'autre). Oui cette solution semble la meilleurs. Je changerai les timing si le parse
dépasse les 3 minutes.
1 - Passer les fichiers dans une liste, ensuite utiliser la liste pour compter.
C'est idiot parce que cela oblige votre script à stocker en mémoire le fichier entier. S'il est très gros, c'est même impossible. Il faut bien commencer avec quelque chose ; ))) D'autant plus que j'ai 2 Go
de memoire disponible. J'ai une question sur ce point précis : le rapport chargement en memoire des données puis traitement est il plus lourd que le l'ouverture du fichier et le parsing ligne à ligne pour perl ?
2 - Lire chaque fichier et traiter ligne à ligne.
C'est la bonne méthode. Ouf !!! ; )))))))))))))))))))
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/> Merci pour toutes ces précisions.
Georges
yves Agostini
Le Thu, 15 Sep 2005 09:32:21 +0200, Geo Kosto a écrit :
Bonjour, Quelqu'un parmi vous aurait il une idée pour réduire la consommation des ressources lors de l'exécution d'un script ? La problématique est la suivante, je parse 4 fichiers de log de 50 Mo sur des DNS pour récupérer les IP toutes les heures sur des station Sun T1 105, et je me rend compte que la consommation CPU atteint les 99% durant 3 minutes !!! Je redoute un ralentissement de l'application qui tourne sur le serveur, Bind 9.3.1, cad un timeout sur des requêtes lorsque le script tourne. J'ai essaye 2 méthodes, mais la charge CPU ne se reduit pas, j'en cherche donc une autre.
1 - Passer les fichiers dans une liste, ensuite utiliser la liste pour compter.
.........
2 - Lire chaque fichier et traiter ligne à ligne.
..........
pour traiter des fichiers de log important, j'utilise une variante de la ligne à ligne mais en temps réel ce n'est pas dit que cela serve dans ton cas ...
dans syslog.conf local4.info; /var/log/router.log local4.info; |/tmp/routersock
puis un daemon ( fork et POSIX::setsid() ) qui en gros
.... test existe sinon etc ...
sysopen(PIPE,"/tmp/routersock",O_RDWR);
while (1) { my $eventbuf = '';
sysread(PIPE,$eventbuf,1024); while ($eventbuf =~ /^(.*)n((.|n)*)$/) { ($_,$eventbuf)=($1,$2); s/s*$//; s/^s*//; Parse($_) if ($_); }
}
Le Thu, 15 Sep 2005 09:32:21 +0200, Geo Kosto a écrit :
Bonjour,
Quelqu'un parmi vous aurait il une idée pour réduire la consommation des
ressources lors de l'exécution d'un script ?
La problématique est la suivante, je parse 4 fichiers de log de 50 Mo sur
des DNS pour récupérer les IP toutes les heures sur des station Sun T1 105,
et je me rend compte que la consommation CPU atteint les 99% durant 3
minutes !!!
Je redoute un ralentissement de l'application qui tourne sur le serveur,
Bind 9.3.1, cad un timeout sur des requêtes lorsque le script tourne.
J'ai essaye 2 méthodes, mais la charge CPU ne se reduit pas, j'en cherche
donc une autre.
1 - Passer les fichiers dans une liste, ensuite utiliser la liste pour
compter.
.........
2 - Lire chaque fichier et traiter ligne à ligne.
..........
pour traiter des fichiers de log important, j'utilise une variante de la
ligne à ligne mais en temps réel
ce n'est pas dit que cela serve dans ton cas ...
dans syslog.conf
local4.info; /var/log/router.log
local4.info; |/tmp/routersock
puis un daemon ( fork et POSIX::setsid() )
qui en gros
.... test existe sinon etc ...
sysopen(PIPE,"/tmp/routersock",O_RDWR);
while (1) {
my $eventbuf = '';
sysread(PIPE,$eventbuf,1024);
while ($eventbuf =~ /^(.*)n((.|n)*)$/) {
($_,$eventbuf)=($1,$2);
s/s*$//; s/^s*//;
Parse($_) if ($_);
}
Le Thu, 15 Sep 2005 09:32:21 +0200, Geo Kosto a écrit :
Bonjour, Quelqu'un parmi vous aurait il une idée pour réduire la consommation des ressources lors de l'exécution d'un script ? La problématique est la suivante, je parse 4 fichiers de log de 50 Mo sur des DNS pour récupérer les IP toutes les heures sur des station Sun T1 105, et je me rend compte que la consommation CPU atteint les 99% durant 3 minutes !!! Je redoute un ralentissement de l'application qui tourne sur le serveur, Bind 9.3.1, cad un timeout sur des requêtes lorsque le script tourne. J'ai essaye 2 méthodes, mais la charge CPU ne se reduit pas, j'en cherche donc une autre.
1 - Passer les fichiers dans une liste, ensuite utiliser la liste pour compter.
.........
2 - Lire chaque fichier et traiter ligne à ligne.
..........
pour traiter des fichiers de log important, j'utilise une variante de la ligne à ligne mais en temps réel ce n'est pas dit que cela serve dans ton cas ...
dans syslog.conf local4.info; /var/log/router.log local4.info; |/tmp/routersock
puis un daemon ( fork et POSIX::setsid() ) qui en gros
.... test existe sinon etc ...
sysopen(PIPE,"/tmp/routersock",O_RDWR);
while (1) { my $eventbuf = '';
sysread(PIPE,$eventbuf,1024); while ($eventbuf =~ /^(.*)n((.|n)*)$/) { ($_,$eventbuf)=($1,$2); s/s*$//; s/^s*//; Parse($_) if ($_); }
}
DoMinix
Geo Kosto wrote: ...
J'ai 14 DNS CACHE, sur lesquels mes clients viennent se connecter. Malheureusement, la mode des tryens, spyware et autres consomme un nombre grandissant de requetes DNS ( ex : 1 000 000 pour un client sur une heure il y a une semaine !!! ).
ne serais pas plutot du ppp over DNS ? toujours vers le meme domaine ou vers n'importe qui ?
-- dominix
Geo Kosto wrote:
...
J'ai 14 DNS CACHE, sur lesquels mes clients viennent se connecter.
Malheureusement, la mode des tryens, spyware et autres consomme un nombre
grandissant de requetes DNS ( ex : 1 000 000 pour un client sur une heure il
y a une semaine !!! ).
ne serais pas plutot du ppp over DNS ?
toujours vers le meme domaine ou vers n'importe qui ?
J'ai 14 DNS CACHE, sur lesquels mes clients viennent se connecter. Malheureusement, la mode des tryens, spyware et autres consomme un nombre grandissant de requetes DNS ( ex : 1 000 000 pour un client sur une heure il y a une semaine !!! ).
ne serais pas plutot du ppp over DNS ? toujours vers le meme domaine ou vers n'importe qui ?
Le problème ? ; ))) Les seuils qui déclanchent une alarme à la supervision si la charge CPU > 80%.
Vous déclenchez une alarme à chaque fois qu'une machine travaille plus de 80% de son temps !!! Si vous faites pareil avec le personnel, je connais beaucoup de monde qui serait prêt à venir travailler chez vous ;-)
[...]
J'ai une question sur ce point précis : le rapport chargement en memoire des données puis traitement est il plus lourd que le l'ouverture du fichier et le parsing ligne à ligne pour perl ?
Oui.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Le problème ? ; ))) Les seuils qui déclanchent une alarme à la supervision
si la charge CPU > 80%.
Vous déclenchez une alarme à chaque fois qu'une machine travaille plus
de 80% de son temps !!! Si vous faites pareil avec le personnel, je
connais beaucoup de monde qui serait prêt à venir travailler chez vous
;-)
[...]
J'ai une question sur ce point précis : le rapport chargement en memoire des
données puis traitement est il plus lourd que le l'ouverture du fichier et
le parsing ligne à ligne pour perl ?
Oui.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Le problème ? ; ))) Les seuils qui déclanchent une alarme à la supervision si la charge CPU > 80%.
Vous déclenchez une alarme à chaque fois qu'une machine travaille plus de 80% de son temps !!! Si vous faites pareil avec le personnel, je connais beaucoup de monde qui serait prêt à venir travailler chez vous ;-)
[...]
J'ai une question sur ce point précis : le rapport chargement en memoire des données puis traitement est il plus lourd que le l'ouverture du fichier et le parsing ligne à ligne pour perl ?
Oui.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
