J'utilise sur plusieurs serveurs web iptables, et sur d'autres ipchains.
Y a t'il un moyen de mesurer le pourcentage processeur consommé par l'un
et l'autres de ces outils?
En particulier j'aimerai savoir si les (relativement) nombreuses regles
que j'ai ajouté pour restreindre les accès aux serveurs ne consomment
pas (+/-) inutilement des ressources CPU / mémoire...
Merci de me fu2er vers un autre groupe si fcolc n'est pas approprié...
L'intégralité de cette charge est elle reportée par le pourcentage que l'on peut voir sous le label "system" en faisant un top ?
Oui, je pense, puisqu'il ne peuvent être comptés nul par ailleurs et que le total doit toujours être de 100%...
Je pense aussi.
Si oui, comment faut il faire pour savoir quels éléments composent ce total de charge "system" ?
On ne peut pas avoir de détail précis, sauf dans le cas des démons kernels. Si je cumule la somme des temps des démons kernels sur mon routeur, j'arrive à moins de 15 minutes pour un uptime de 45 jours, dont la moitié est due aux IO disques. Je pense que la consomation des iptables est très faible: j'ai 770 règles iptables sur cette machine.
Et cette machine est notre passerelle principale (uniquement pour la bureautique, le dev et la pré-prod). C'est un PIII 1 GHz, je n'ai pas charché à optimiser les règles, c'est du presque linéaire, c'est infâme.
Ca va changer prochainement pour du netfilter, optimisé, avec 4 interfaces réseau en plus (comme d'hab, quand j'aurais le temps).
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- (A)bort, (R)etry, (I)nfluence with large hammer.
Bonjour,
On Wed, 24 Nov 2004, no_spam wrote:
On Tue, 23 Nov 2004 16:08:13 +0100, J1 wrote:
L'intégralité de cette charge est elle reportée par le pourcentage que
l'on peut voir sous le label "system" en faisant un top ?
Oui, je pense, puisqu'il ne peuvent être comptés nul par ailleurs et que
le total doit toujours être de 100%...
Je pense aussi.
Si oui, comment faut il faire pour savoir quels éléments composent ce
total de charge "system" ?
On ne peut pas avoir de détail précis, sauf dans le cas des démons
kernels.
Si je cumule la somme des temps des démons kernels sur mon routeur,
j'arrive à moins de 15 minutes pour un uptime de 45 jours, dont la
moitié est due aux IO disques. Je pense que la consomation des iptables
est très faible: j'ai 770 règles iptables sur cette machine.
Et cette machine est notre passerelle principale (uniquement pour la
bureautique, le dev et la pré-prod). C'est un PIII 1 GHz, je n'ai pas
charché à optimiser les règles, c'est du presque linéaire, c'est infâme.
Ca va changer prochainement pour du netfilter, optimisé, avec 4 interfaces
réseau en plus (comme d'hab, quand j'aurais le temps).
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
(A)bort, (R)etry, (I)nfluence with large hammer.
L'intégralité de cette charge est elle reportée par le pourcentage que l'on peut voir sous le label "system" en faisant un top ?
Oui, je pense, puisqu'il ne peuvent être comptés nul par ailleurs et que le total doit toujours être de 100%...
Je pense aussi.
Si oui, comment faut il faire pour savoir quels éléments composent ce total de charge "system" ?
On ne peut pas avoir de détail précis, sauf dans le cas des démons kernels. Si je cumule la somme des temps des démons kernels sur mon routeur, j'arrive à moins de 15 minutes pour un uptime de 45 jours, dont la moitié est due aux IO disques. Je pense que la consomation des iptables est très faible: j'ai 770 règles iptables sur cette machine.
Et cette machine est notre passerelle principale (uniquement pour la bureautique, le dev et la pré-prod). C'est un PIII 1 GHz, je n'ai pas charché à optimiser les règles, c'est du presque linéaire, c'est infâme.
Ca va changer prochainement pour du netfilter, optimisé, avec 4 interfaces réseau en plus (comme d'hab, quand j'aurais le temps).
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- (A)bort, (R)etry, (I)nfluence with large hammer.
Pascal
TiChou wrote:
Dans le message <news:co0hcq$16uv$, ** tapota sur f.c.o.l.configuration :
Le mieux serait à mon avis de publier vos règles et nous demander commentaires et conseils.
Cette proposition tient-elle aussi pour un jeu de 300 règles ? :-D
Pourquoi pas ? :-) C'est d'autant plus intéressant quand les règles sont nombreuses.
Entendu, dès que j'ai une première mouture sous la main, je publie tout ça et le soumets à votre jugement. L'affaire est un peu compliquée (pour moi) : c'est pour faire une passerelle ayant 5 interfaces au moins dont certaines sont dynamiques (nom et adresse), un LAN privé, plusieurs adresses publiques et du NAT dans tous les sens. Et bien sûr je veux que le tout soit aussi modulaire et souple que possible.
Quelle est l'influence relative des éléments suivants sur le temps d'exécution ? - la présence d'une règle indépendamment de son contenu - le saut d'une chaîne dans une autre - le nombre et le type des correspondances dans une règle - y a-t-il des correspondances plus gourmandes que d'autres (à factoriser en priorité donc) ? [...]
Au final, et c'est toujours ce qui a été conclu dans différents messages sur le sujet et aussi en se basant sur l'expérience de chacun, le nombre de règles et leurs complexités semblent influencer de façon non mesurable le temps de traversée des paquets dans la couche Netfilter.
Ça veut dire qu'on peut balancer son tas de règles comme un gros goret sans se soucier d'optimisation alors ? Merci, voici une excellente nouvelle :-D
TiChou wrote:
Dans le message <news:co0hcq$16uv$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :
Le mieux serait à mon avis de publier vos règles et nous demander
commentaires et conseils.
Cette proposition tient-elle aussi pour un jeu de 300 règles ? :-D
Pourquoi pas ? :-) C'est d'autant plus intéressant quand les règles sont
nombreuses.
Entendu, dès que j'ai une première mouture sous la main, je publie tout
ça et le soumets à votre jugement.
L'affaire est un peu compliquée (pour moi) : c'est pour faire une
passerelle ayant 5 interfaces au moins dont certaines sont dynamiques
(nom et adresse), un LAN privé, plusieurs adresses publiques et du NAT
dans tous les sens. Et bien sûr je veux que le tout soit aussi modulaire
et souple que possible.
Quelle est l'influence relative des éléments suivants sur le temps
d'exécution ?
- la présence d'une règle indépendamment de son contenu
- le saut d'une chaîne dans une autre
- le nombre et le type des correspondances dans une règle
- y a-t-il des correspondances plus gourmandes que d'autres (à
factoriser en priorité donc) ?
[...]
Au final, et c'est toujours ce qui a été conclu dans différents messages
sur le sujet et aussi en se basant sur l'expérience de chacun, le nombre
de règles et leurs complexités semblent influencer de façon non
mesurable le temps de traversée des paquets dans la couche Netfilter.
Ça veut dire qu'on peut balancer son tas de règles comme un gros goret
sans se soucier d'optimisation alors ? Merci, voici une excellente
nouvelle :-D
Dans le message <news:co0hcq$16uv$, ** tapota sur f.c.o.l.configuration :
Le mieux serait à mon avis de publier vos règles et nous demander commentaires et conseils.
Cette proposition tient-elle aussi pour un jeu de 300 règles ? :-D
Pourquoi pas ? :-) C'est d'autant plus intéressant quand les règles sont nombreuses.
Entendu, dès que j'ai une première mouture sous la main, je publie tout ça et le soumets à votre jugement. L'affaire est un peu compliquée (pour moi) : c'est pour faire une passerelle ayant 5 interfaces au moins dont certaines sont dynamiques (nom et adresse), un LAN privé, plusieurs adresses publiques et du NAT dans tous les sens. Et bien sûr je veux que le tout soit aussi modulaire et souple que possible.
Quelle est l'influence relative des éléments suivants sur le temps d'exécution ? - la présence d'une règle indépendamment de son contenu - le saut d'une chaîne dans une autre - le nombre et le type des correspondances dans une règle - y a-t-il des correspondances plus gourmandes que d'autres (à factoriser en priorité donc) ? [...]
Au final, et c'est toujours ce qui a été conclu dans différents messages sur le sujet et aussi en se basant sur l'expérience de chacun, le nombre de règles et leurs complexités semblent influencer de façon non mesurable le temps de traversée des paquets dans la couche Netfilter.
Ça veut dire qu'on peut balancer son tas de règles comme un gros goret sans se soucier d'optimisation alors ? Merci, voici une excellente nouvelle :-D
TiChou
Dans le message <news:co32qj$2ap2$, ** tapota sur f.c.o.l.configuration :
Cette proposition tient-elle aussi pour un jeu de 300 règles ? :-D
Pourquoi pas ? :-) C'est d'autant plus intéressant quand les règles sont nombreuses.
Entendu, dès que j'ai une première mouture sous la main, je publie tout ça et le soumets à votre jugement. L'affaire est un peu compliquée (pour moi) : c'est pour faire une passerelle ayant 5 interfaces au moins dont certaines sont dynamiques (nom et adresse), un LAN privé, plusieurs adresses publiques et du NAT dans tous les sens. Et bien sûr je veux que le tout soit aussi modulaire et souple que possible.
Ça semble très intéressant. :)
Au final, et c'est toujours ce qui a été conclu dans différents messages sur le sujet et aussi en se basant sur l'expérience de chacun, le nombre de règles et leurs complexités semblent influencer de façon non mesurable le temps de traversée des paquets dans la couche Netfilter.
Ça veut dire qu'on peut balancer son tas de règles comme un gros goret sans se soucier d'optimisation alors ? Merci, voici une excellente nouvelle :-D
Jusqu'à preuve du contraire, je dirais oui...
-- TiChou
Dans le message <news:co32qj$2ap2$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :
Cette proposition tient-elle aussi pour un jeu de 300 règles ? :-D
Pourquoi pas ? :-) C'est d'autant plus intéressant quand les règles sont
nombreuses.
Entendu, dès que j'ai une première mouture sous la main, je publie tout ça
et le soumets à votre jugement.
L'affaire est un peu compliquée (pour moi) : c'est pour faire une
passerelle ayant 5 interfaces au moins dont certaines sont dynamiques (nom
et adresse), un LAN privé, plusieurs adresses publiques et du NAT dans
tous les sens. Et bien sûr je veux que le tout soit aussi modulaire et
souple que possible.
Ça semble très intéressant. :)
Au final, et c'est toujours ce qui a été conclu dans différents messages
sur le sujet et aussi en se basant sur l'expérience de chacun, le nombre
de règles et leurs complexités semblent influencer de façon non mesurable
le temps de traversée des paquets dans la couche Netfilter.
Ça veut dire qu'on peut balancer son tas de règles comme un gros goret
sans se soucier d'optimisation alors ? Merci, voici une excellente
nouvelle :-D
Dans le message <news:co32qj$2ap2$, ** tapota sur f.c.o.l.configuration :
Cette proposition tient-elle aussi pour un jeu de 300 règles ? :-D
Pourquoi pas ? :-) C'est d'autant plus intéressant quand les règles sont nombreuses.
Entendu, dès que j'ai une première mouture sous la main, je publie tout ça et le soumets à votre jugement. L'affaire est un peu compliquée (pour moi) : c'est pour faire une passerelle ayant 5 interfaces au moins dont certaines sont dynamiques (nom et adresse), un LAN privé, plusieurs adresses publiques et du NAT dans tous les sens. Et bien sûr je veux que le tout soit aussi modulaire et souple que possible.
Ça semble très intéressant. :)
Au final, et c'est toujours ce qui a été conclu dans différents messages sur le sujet et aussi en se basant sur l'expérience de chacun, le nombre de règles et leurs complexités semblent influencer de façon non mesurable le temps de traversée des paquets dans la couche Netfilter.
Ça veut dire qu'on peut balancer son tas de règles comme un gros goret sans se soucier d'optimisation alors ? Merci, voici une excellente nouvelle :-D
