Utilisation du processeur et Iptables/Ipchains

( Mon, 22 Nov 2004 17:25:22 +0100 ) J1 :

Bonjour le monde,

Bonjour

consomment
pas (+/-) inutilement des ressources CPU / mémoire...

Alors:


Est ce que tes serveur sont overbookés ? est ce que la consommation CPU
stabilise à plus de 80 % à longueur de journée ?

Si "non", alors tu as vraiment tort de t'inquiéter.

Si moi j'achète une barette de RAM et on bon CPU, c'est justement pour
qu'il soit utilisé. Si tu tien absolument à avoir ta ram libre,
démonte-la et pose la sur ton bureau :-)

Si tu en es à une moyenne de 10-15% sur toute une
journée, à mon avis tu à le temps de dormir. Pour avoir une idée, je
crois qu'il existe des outils comme mrtg qui font ça tres bien.

Ta distribution doit bien avoir des packages mrtg.

Merci de me fu2er vers un autre groupe si fcolc n'est pas approprié...

Pour iptables/ipchain je crois bien que c'est OK.
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)

consomment
pas (+/-) inutilement des ressources CPU / mémoire...

Alors:

Est ce que tes serveur sont overbookés ? est ce que la consommation CPU
stabilise à plus de 80 % à longueur de journée ?

Et bien certains serveurs sont parfois dans le rouge, ce qui m'oblige à
à surdimensionner un peu ...

Si "non", alors tu as vraiment tort de t'inquiéter.

Si moi j'achète une barette de RAM et on bon CPU, c'est justement pour
qu'il soit utilisé. Si tu tien absolument à avoir ta ram libre,
démonte-la et pose la sur ton bureau :-)

Les barettes de RAM font de piètres presse papiers, soit :-)

Si je cherche un moyen de mesurer la quantité de ressources utilisées
par iptables/ipchains, c'est aussi pour optimiser les règles de filtrage
afin qu'elles consomment le moins possible sans pour autant que la
sécurité en patisse.

Si tu en es à une moyenne de 10-15% sur toute une
journée, à mon avis tu à le temps de dormir. Pour avoir une idée, je
crois qu'il existe des outils comme mrtg qui font ça tres bien.

Ta distribution doit bien avoir des packages mrtg.

A vrai dire j'ai déjà des outils de monitoring (peu sophistiqués) qui
m'indiquent que certains serveurs sont parfois très chargés.

Merci de me fu2er vers un autre groupe si fcolc n'est pas approprié...

Pour iptables/ipchain je crois bien que c'est OK.

Merci bien pour ton conseil,
je vais regarder ce que sait faire mrtg!

--
J1

On 2004-11-22, J1 <ji1.NOJUNK@free.fr> wrote:

consomment
pas (+/-) inutilement des ressources CPU / mémoire...

Alors:

Est ce que tes serveur sont overbookés ? est ce que la consommation CPU
stabilise à plus de 80 % à longueur de journée ?

Et bien certains serveurs sont parfois dans le rouge, ce qui m'oblige à
à surdimensionner un peu ... [....]

Si je cherche un moyen de mesurer la quantité de ressources utilisées
par iptables/ipchains, c'est aussi pour optimiser les règles de filtrage
afin qu'elles consomment le moins possible sans pour autant que la
sécurité en patisse.

A mon avis la charge des iptables est difficile à mesurer. En effet,
Linux mesure bien la charge de chaque processus; mais le traitement
des paquets (donc celui par iptables) est effectué dans le noyau. Et
les iptables agissent par définition avant le processus recevant le
paquet.

Pour ma part, je n'imagine pas que les iptables chargent
significativement la machine. L'essentiel de la charge est AMHA dû aux
serveurs comme Apache, inetd, sshd, mysqld ... qui recoivent les
paquets.

Mais c'est vrai que je n'ai pas regardé précisement le source du noyau
à ce propos....

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

On Mon, 22 Nov 2004 18:03:40 +0000, Basile Starynkevitch [news] wrote:

On 2004-11-22, J1 <ji1.NOJUNK@free.fr> wrote:

consomment
pas (+/-) inutilement des ressources CPU / mémoire...

Alors:

Est ce que tes serveur sont overbookés ? est ce que la consommation CPU
stabilise à plus de 80 % à longueur de journée ?

Et bien certains serveurs sont parfois dans le rouge, ce qui m'oblige à
à surdimensionner un peu ... [....]

Si je cherche un moyen de mesurer la quantité de ressources utilisées
par iptables/ipchains, c'est aussi pour optimiser les règles de filtrage
afin qu'elles consomment le moins possible sans pour autant que la
sécurité en patisse.

A mon avis la charge des iptables est difficile à mesurer. En effet,
Linux mesure bien la charge de chaque processus; mais le traitement
des paquets (donc celui par iptables) est effectué dans le noyau. Et
les iptables agissent par définition avant le processus recevant le
paquet.

Pour ma part, je n'imagine pas que les iptables chargent
significativement la machine. L'essentiel de la charge est AMHA dû aux
serveurs comme Apache, inetd, sshd, mysqld ... qui recoivent les
paquets.

Je pense comme toi. Et je pense que quoi qu'il en soit, il faut de toute
façon essayer d'optimiser les chaines en faisant en sorte qu'un paquet
traverse le moins de règles possibles. Donc, à mon avis, il ne faut pas
hésiter à créer des chaines, ça ne coute rien en temps d'execution
(juste un peu de RAM) et à diriger chaque paquet à filtrer sur la chaine
contenant toutes les règles qui s'y appliquent et uniquement elles...
Ainsi, le cout de traitement d'un paquet est minimisé.

Dans le message <news:41a21ba0$0$4373$626a14ce@news.free.fr>,
*J1* tapota sur f.c.o.l.configuration :

Si je cherche un moyen de mesurer la quantité de ressources utilisées
par iptables/ipchains, c'est aussi pour optimiser les règles de filtrage
afin qu'elles consomment le moins possible sans pour autant que la
sécurité en patisse.

Le mieux serait à mon avis de publier vos règles et nous demander
commentaires et conseils.

--
TiChou

On 2004-11-22, J1 <ji1.NOJUNK@free.fr> wrote:

Est ce que tes serveur sont overbookés ? est ce que la consommation CPU
stabilise à plus de 80 % à longueur de journée ?

Et bien certains serveurs sont parfois dans le rouge, ce qui m'oblige à
à surdimensionner un peu ... [....]

Si je cherche un moyen de mesurer la quantité de ressources utilisées
par iptables/ipchains, c'est aussi pour optimiser les règles de filtrage
afin qu'elles consomment le moins possible sans pour autant que la
sécurité en patisse.

A mon avis la charge des iptables est difficile à mesurer. En effet,
Linux mesure bien la charge de chaque processus; mais le traitement
des paquets (donc celui par iptables) est effectué dans le noyau. Et
les iptables agissent par définition avant le processus recevant le
paquet.

Pour ma part, je n'imagine pas que les iptables chargent
significativement la machine. L'essentiel de la charge est AMHA dû aux
serveurs comme Apache, inetd, sshd, mysqld ... qui recoivent les
paquets.

Mais c'est vrai que je n'ai pas regardé précisement le source du noyau
à ce propos....

Si j'ai tout suivi, iptables (netfilter ?) agit avant que les paquets
arrivent aux processi, et c'est même là son interêt.
Mais ces taches doivent tout de même bien être traitées par le noyau,
donc par un (ou des) processeur, ce qui implique bien une charge...

Tout comme le travail concernant la gestion des FS, de la mise en cache,
de la swap, de l'ordonnancement, et la liste doit être bien plus longue
encore.

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 ?
Si oui, comment faut il faire pour savoir quels éléments composent ce
total de charge "system" ?

--
J1

On Mon, 22 Nov 2004 18:03:40 +0000, Basile Starynkevitch [news] wrote:

A mon avis la charge des iptables est difficile à mesurer. En effet,
Linux mesure bien la charge de chaque processus; mais le traitement
des paquets (donc celui par iptables) est effectué dans le noyau. Et
les iptables agissent par définition avant le processus recevant le
paquet.

Pour ma part, je n'imagine pas que les iptables chargent
significativement la machine. L'essentiel de la charge est AMHA dû aux
serveurs comme Apache, inetd, sshd, mysqld ... qui recoivent les
paquets.

Je pense comme toi. Et je pense que quoi qu'il en soit, il faut de toute
façon essayer d'optimiser les chaines en faisant en sorte qu'un paquet
traverse le moins de règles possibles. Donc, à mon avis, il ne faut pas
hésiter à créer des chaines, ça ne coute rien en temps d'execution
(juste un peu de RAM) et à diriger chaque paquet à filtrer sur la chaine
contenant toutes les règles qui s'y appliquent et uniquement elles...
Ainsi, le cout de traitement d'un paquet est minimisé.

Merci pour le conseil, je vais essayer d'utiliser des chaines, je fais
quelque chose de bien propre et je reviens le poster ici, comme me l'a
suggéré TiChou.

--
J1

Salut,

TiChou wrote:

Si je cherche un moyen de mesurer la quantité de ressources utilisées
par iptables/ipchains, c'est aussi pour optimiser les règles de filtrage
afin qu'elles consomment le moins possible sans pour autant que la
sécurité en patisse.

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
En attendant j'ai aussi quelques questions plus générales.

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) ?

Par exemple, est-ce que le temps d'exécution de

INPUT -j chaine
chaine -p tcp --dport 80 -j ACCEPT
chaine -p udp --dport 53 -j ACCEPT

est sensiblement plus long que

INPUT -p tcp --dport 80 -j ACCEPT
INPUT -p udp --dport 53 -j ACCEPT

Connaissez-vous des docs qui en parlent ?

On Tue, 23 Nov 2004 16:08:13 +0100, J1 wrote:

On 2004-11-22, J1 <ji1.NOJUNK@free.fr> wrote:

Est ce que tes serveur sont overbookés ? est ce que la consommation CPU
stabilise à plus de 80 % à longueur de journée ?

Et bien certains serveurs sont parfois dans le rouge, ce qui m'oblige à
à surdimensionner un peu ... [....]

Si je cherche un moyen de mesurer la quantité de ressources utilisées
par iptables/ipchains, c'est aussi pour optimiser les règles de filtrage
afin qu'elles consomment le moins possible sans pour autant que la
sécurité en patisse.

A mon avis la charge des iptables est difficile à mesurer. En effet,
Linux mesure bien la charge de chaque processus; mais le traitement
des paquets (donc celui par iptables) est effectué dans le noyau. Et
les iptables agissent par définition avant le processus recevant le
paquet.

Pour ma part, je n'imagine pas que les iptables chargent
significativement la machine. L'essentiel de la charge est AMHA dû aux
serveurs comme Apache, inetd, sshd, mysqld ... qui recoivent les
paquets.

Mais c'est vrai que je n'ai pas regardé précisement le source du noyau
à ce propos....

Si j'ai tout suivi, iptables (netfilter ?) agit avant que les paquets
arrivent aux processi, et c'est même là son interêt.
Mais ces taches doivent tout de même bien être traitées par le noyau,
donc par un (ou des) processeur, ce qui implique bien une charge...

Tout comme le travail concernant la gestion des FS, de la mise en cache,
de la swap, de l'ordonnancement, et la liste doit être bien plus longue
encore.

Oui, mais dans la plupart des cas, le travail est très simple puisqu'il
s'agit de comparer quelques octets du paquets avec les valeurs
correspondant à la règle de filtrage, et ce, une fois pour chaque règle
et éventuellement à modifier quelques octets de celui-ci.
Le cas du connection tracking (masquerading, ...) est un peu plus complexe
puisqu'il faut retrouver la connection d'origine du paquet.

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%...

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.

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.

En attendant j'ai aussi quelques questions plus générales.

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) ?

Questions qui sont assez récurrentes et qui sont toujours restées sans
réponses concrètes.

Par exemple, est-ce que le temps d'exécution de

INPUT -j chaine
chaine -p tcp --dport 80 -j ACCEPT
chaine -p udp --dport 53 -j ACCEPT

est sensiblement plus long que

INPUT -p tcp --dport 80 -j ACCEPT
INPUT -p udp --dport 53 -j ACCEPT

Il faudrait faire des benchmarks en injectant en masse des paquets dans ses
chaînes, en utilisant par exemple libnet, et analyser les différences
observées.

J'ai effectué un test, il vaut ce qu'il vaut, c'est-à-dire pas grand
chose :

pegase root # iptables -F INPUT
pegase root # time ping -f -c 10000000 -s 10000 -q -n 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 10000(10028) bytes of data.

--- 127.0.0.1 ping statistics ---
10000000 packets transmitted, 10000000 received, 0% packet loss, time
1188614ms
rtt min/avg/max/mdev = 0.037/0.044/20.528/0.011 ms, pipe 3, ipg/ewma
0.118/0.043 ms

real 19m48.622s
user 5m38.745s
sys 10m22.955s


pegase root # iptables -A INPUT -p icmp -i lo --icmp-type echo-request

-j ACCEPT
pegase root # time ping -f -c 10000000 -s 10000 -q -n 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 10000(10028) bytes of data.

--- 127.0.0.1 ping statistics ---
10000000 packets transmitted, 10000000 received, 0% packet loss, time
1216447ms
rtt min/avg/max/mdev = 0.038/0.045/20.600/0.014 ms, pipe 2, ipg/ewma
0.121/0.042 ms

real 20m16.453s
user 5m49.640s
sys 10m37.905s


pegase root # iptables -F INPUT
pegase root # iptables -N chaine
pegase root # iptables -A INPUT -j chaine
pegase root # iptables -A chaine -p icmp -i lo --icmp-type echo-request

-j ACCEPT
pegase root # time ping -f -c 10000000 -s 10000 -q -n 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 10000(10028) bytes of data.

--- 127.0.0.1 ping statistics ---
10000000 packets transmitted, 10000000 received, 0% packet loss, time
1171270ms
rtt min/avg/max/mdev = 0.038/0.043/30.269/0.012 ms, pipe 2, ipg/ewma
0.117/0.043 ms

real 19m31.276s
user 5m24.880s
sys 10m13.305s

Je soupçonne que les différences de temps sont dues à quelques petites
tâches cron durant les tests.
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.

Connaissez-vous des docs qui en parlent ?

Depuis le temps que je m'intéresse à Netfilter, je n'ai personnellement
jamais vu de telles documentations.

--
TiChou