thierry78
09/09/2008, 10h25
Je penses honetement que ton serveur à un probleme de tunning, peut etre même un problème hard. haproxy n'est pas loin d'atteindre le 10Gbps avec des machines achetées rue montgallet (sauf les cartes reseau bien sur). Un fichier de 3Mo doit bien sur faire monter un tout petit la conso CPU mais pendant un temps ridicule.
je viens de faire un test rapide, dans des condition qui ne correspondent pas ivraiment à la realité, mais qui sont plus ou moins similaires:
un haproxy, un client/serveur rudimentaires, sur une meme machine, j'atteint un debit de 7Gbps sur la loopback. Sur un linux, la loopback fait toutes les operation liées a la pile IP, sa seule acceleration est qu'elle n'est pas limité par le matériel.
j'ai fait le test sur mon portable, c'est un intel core2duo 2.4Ghz. bien sur le cpu est saturé (10% systeme et 80% user) la version de haproxy est: 1.3.15.1
voila le script de demarrage haproxy avec sa conf:
# cat test.sh
haproxy -p $PIDFILE -f /dev/stdin <
log 127.0.0.1:4000 local0 debug
listen proxy 127.0.0.1:4001
log global
mode http
option httpclose
option httplog
balance roundrobin
contimeout 500000
clitimeout 500000
srvtimeout 500000
server serveur 127.0.0.1:8002
EOF
le serveur:
(echo -ne "HTTP/1.0 200 OK\r\n\r\n" ; cat /dev/zero) | nc -lp 8002 >/dev/null
le client:
( echo -ne "POST / HTTP/1.0\r\nHost: www\r\n\r\n" ) | nc 127.0.0.1 4001 >/dev/null
le client fait un POST et le serveur repond un flux illimité de 0. (il faut rediriger les sortie vers /dev/null sinon c'est le terminal qui limite le debit reseau)
je ne suis pas en mesure de donner un manip pour degonfler le CPU. sans possibilité de diagnostic ce n'est pas simple. par contre je peux garantir que 5Mbps pour 100% de CPU, c'est un comportement tout a fait anormal ! lors d'un transfert de fichier de grosse taille, pendant le passage des datas, haproxy ne fait que copier du buffer reseau coté serveur vers son buffer interne et copier de son buffer interne vers le buffer reseau coté client, ces opérations ne prennent pas de temps, la conso CPU doit d'ailleur consommer plus système que de user.
Le haproxy que je connais qui consomme le plus est sur un serveur de jeu videos qui fournit des mises a jour pour WoW, le debit est aussi monstrueux que la taille des fichier fournis par le serveur, il y a un seul haproxy pour tout ça. Tu peux te faire une idée ici de ce qui est attendu en focntion du materiel: http://www.exceliance.fr/ahcaract.htm (les perfs annoncées sont largement sous estimés par rapport aux tests effectués). Pour ces machines les processeurs ne sont pas donnés, mais ce sont tous du x86 ils vont du geode LX800 pour la plus petite au P4 2,??GHz pouyr la plus grosse, les machines n'ont qu'un seul processeur. Bien evidement ces appliances sont basées sur du haproxy.
pour resoudre le souci:
- regarde si tu n'a pas des erreurs sur tes interface reseaux (netstat -ni)
- si la negociation est OK (ethtool ethx) (j'ai souvent vu des problemes de négo, notament avec des machines forcés en gigabit face a des switchs cisco),
- la version du kernel, dans les kernels 2.6 le sheduleur à été réécrit, il a mis du temps à se stabiliser. ont trouve donc des kernel 2.6 catastrophiques. toutes les appliance citées plus haut sont en 2.4. les tests rapides que j'ai fait plus haut, sont sur un 2.6.23.14
- il peut aussi y avoir l'utilisation de netfilter qui impacte les perfs. Lorsque el conntrack est activé, les perfs chutent, mais pas à ce point.
- tu peux eventuellement faire un strace sur le binaire haproxy pendant les tests, peut etre y aura t il quelque chose de flagrant.
- regarder le type des cartes reseau (j'ai deja vu un constructeur de firewalls français mettre des cartes realtek à 5 euros pieces dans leurs équipements - LA HONTE !!!)
- pour faire des tests unitaires, tu peux utiliser TUX, c'est un serveur web directement implementé dans la kernel. il arrache !
- pour des tests de debits, netcat est parfait, il faut forger la requete, mais c'est peanuts.
...
je n'ai plus d'idées, si tu souhaite une aide au debug, n'hésite pas.
je viens de faire un test rapide, dans des condition qui ne correspondent pas ivraiment à la realité, mais qui sont plus ou moins similaires:
un haproxy, un client/serveur rudimentaires, sur une meme machine, j'atteint un debit de 7Gbps sur la loopback. Sur un linux, la loopback fait toutes les operation liées a la pile IP, sa seule acceleration est qu'elle n'est pas limité par le matériel.
j'ai fait le test sur mon portable, c'est un intel core2duo 2.4Ghz. bien sur le cpu est saturé (10% systeme et 80% user) la version de haproxy est: 1.3.15.1
voila le script de demarrage haproxy avec sa conf:
# cat test.sh
haproxy -p $PIDFILE -f /dev/stdin <
log 127.0.0.1:4000 local0 debug
listen proxy 127.0.0.1:4001
log global
mode http
option httpclose
option httplog
balance roundrobin
contimeout 500000
clitimeout 500000
srvtimeout 500000
server serveur 127.0.0.1:8002
EOF
le serveur:
(echo -ne "HTTP/1.0 200 OK\r\n\r\n" ; cat /dev/zero) | nc -lp 8002 >/dev/null
le client:
( echo -ne "POST / HTTP/1.0\r\nHost: www\r\n\r\n" ) | nc 127.0.0.1 4001 >/dev/null
le client fait un POST et le serveur repond un flux illimité de 0. (il faut rediriger les sortie vers /dev/null sinon c'est le terminal qui limite le debit reseau)
je ne suis pas en mesure de donner un manip pour degonfler le CPU. sans possibilité de diagnostic ce n'est pas simple. par contre je peux garantir que 5Mbps pour 100% de CPU, c'est un comportement tout a fait anormal ! lors d'un transfert de fichier de grosse taille, pendant le passage des datas, haproxy ne fait que copier du buffer reseau coté serveur vers son buffer interne et copier de son buffer interne vers le buffer reseau coté client, ces opérations ne prennent pas de temps, la conso CPU doit d'ailleur consommer plus système que de user.
Le haproxy que je connais qui consomme le plus est sur un serveur de jeu videos qui fournit des mises a jour pour WoW, le debit est aussi monstrueux que la taille des fichier fournis par le serveur, il y a un seul haproxy pour tout ça. Tu peux te faire une idée ici de ce qui est attendu en focntion du materiel: http://www.exceliance.fr/ahcaract.htm (les perfs annoncées sont largement sous estimés par rapport aux tests effectués). Pour ces machines les processeurs ne sont pas donnés, mais ce sont tous du x86 ils vont du geode LX800 pour la plus petite au P4 2,??GHz pouyr la plus grosse, les machines n'ont qu'un seul processeur. Bien evidement ces appliances sont basées sur du haproxy.
pour resoudre le souci:
- regarde si tu n'a pas des erreurs sur tes interface reseaux (netstat -ni)
- si la negociation est OK (ethtool ethx) (j'ai souvent vu des problemes de négo, notament avec des machines forcés en gigabit face a des switchs cisco),
- la version du kernel, dans les kernels 2.6 le sheduleur à été réécrit, il a mis du temps à se stabiliser. ont trouve donc des kernel 2.6 catastrophiques. toutes les appliance citées plus haut sont en 2.4. les tests rapides que j'ai fait plus haut, sont sur un 2.6.23.14
- il peut aussi y avoir l'utilisation de netfilter qui impacte les perfs. Lorsque el conntrack est activé, les perfs chutent, mais pas à ce point.
- tu peux eventuellement faire un strace sur le binaire haproxy pendant les tests, peut etre y aura t il quelque chose de flagrant.
- regarder le type des cartes reseau (j'ai deja vu un constructeur de firewalls français mettre des cartes realtek à 5 euros pieces dans leurs équipements - LA HONTE !!!)
- pour faire des tests unitaires, tu peux utiliser TUX, c'est un serveur web directement implementé dans la kernel. il arrache !
- pour des tests de debits, netcat est parfait, il faut forger la requete, mais c'est peanuts.
...
je n'ai plus d'idées, si tu souhaite une aide au debug, n'hésite pas.
Envoyé par Meskalyn