Connection time apache

55 réponses

Page 12 3

Auteur	Message
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 08/01/2008 à 14:01 Il faut redémarrer après ? Edit : ah bas non, si on redémarre ca va remettre l'ancienne valeur Chambres d'hote tavel Séjours en provence Forum mariage
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 08/01/2008 à 14:02 Non normalement l'effet est "immédiat" daevel : infogérance et conseil \|\| moi
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 08/01/2008 à 14:44 Bon bah... ça ne marche pas... j'ai meme des jolis 9000ms de lag maintenant daevel : infogérance et conseil \|\| moi
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 08/01/2008 à 15:28 J'ai regardé la liste des ips dans netstats. Sur 15k ips, 8k fois l'ip d'un serveur dns qui était dans /etc/resolv.conf J'ai changé la liste des serveurs dns et pour l'instant ca va "mieux" sur certaines machines... Avec la modif que tu as indiqué aussi. Il y a encore des lag, mais pas autant qu'avant. Edit : ba en fait non, ca devait etre le hasard Chambres d'hote tavel Séjours en provence Forum mariage
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 08/01/2008 à 17:02 D'après notre hébergeur il se pourrait que cela vienne des tailles de fenetre TCP (fonctionnement modifié récement sous linux, et qui pose des soucis avec certains équipements réseau buggés). Ca se passe ici : cat /proc/sys/net/ipv4/tcp_rmem 4096 16384 4194304 Il est conseillé de réduire le troisième paramêtre à 207520 (valeur de l'ancienne version du kernel à priori). Il y a aussi son petit frère /proc/sys/net/ipv4/tcp_wmem mais je ne sais pas s'il faut le modifier. J'attends demain pour appliquer cette modif, si celles en cours ne sont pas efficaces. daevel : infogérance et conseil \|\| moi
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 08/01/2008 à 17:35 okay, je teste ! edit : le premier seul ne change rien edit : modification des deux non plus (Message édité le 08-01-2008 à 17h45 par Rano) Chambres d'hote tavel Séjours en provence Forum mariage
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 08/01/2008 à 19:22 A force de tester plein de trucs, j'ai une machine sur laquelle le problème ne se produit plus du tout depuis une heure... J'ai regardé la différence des variables entre un serveur qui merde et celui-ci et j'obtiens ça : a gauche du != c'est celui qui merde plus, à droite celui qui a encore le problème Array ( [kernel.threads-max] => 32336 != 32352 [kernel.random.entropy_avail] => 3486 != 2934 [kernel.pty.nr] => 2 != 1 [vm.min_free_kbytes] => 5703 != 5704 [net.ipv4.tcp_syn_retries] => 1 != 5 [net.ipv4.tcp_synack_retries] => 1 != 5 [net.ipv4.tcp_mem] => 190560 254080 381120 != 190656 254208 381312 [net.ipv4.tcp_rmem] => 4096 87380 4194304 != 4096 87380 207520 [net.ipv4.netfilter.ip_conntrack_generic_timeout] => 60 != 600 [net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait] => 30 != 120 [net.ipv4.netfilter.ip_conntrack_count] => 19044 != 45676 [net.netfilter.nf_conntrack_generic_timeout] => 60 != 600 [net.netfilter.nf_conntrack_count] => 19044 != 45677 [net.netfilter.nf_conntrack_tcp_timeout_time_wait] => 30 != 120 [fs.inode-nr] => 11473 61 != 10645 64 [fs.inode-state] => 11473 61 0 0 0 0 0 != 10645 64 0 0 0 0 0 [fs.file-nr] => 1312 0 200906 != 1248 0 201008 [fs.file-max] => 200906 != 201008 [fs.dentry-state] => 13477 9453 45 0 0 0 != 12825 8887 45 0 0 0 ) Sur la machine "ok", ce test : ab -n 10000 -c 500 http://xxxxx/page.php Donne en "Connect time" max : 11 ms... Alors que ca allait jusqu'à 21 secondes quand elle merdait. Je vais essayer de reproduire la config sur une autre machine pour voir. (Message édité le 08-01-2008 à 19h28 par Rano) (Message édité le 08-01-2008 à 19h28 par Rano) Chambres d'hote tavel Séjours en provence Forum mariage
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 08/01/2008 à 19:35 Alors, sur une autre machine ca semble bon aussi (à confirmer avec le temps), avec ceci par rapport à config de base : /sbin/sysctl -w net.ipv4.tcp_congestion_control=cubic /sbin/sysctl -w net.ipv4.tcp_keepalive_time=120 /sbin/sysctl -w net.ipv4.tcp_keepalive_intvl=10 /sbin/sysctl -w net.ipv4.tcp_keepalive_probes=6 /sbin/sysctl -w net.ipv4.tcp_syn_retries=2 /sbin/sysctl -w net.ipv4.tcp_synack_retries=2 /sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=60 /sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait=30 edit : je mets les syn_retries à 2 plutot que 1. Pas besoin de baisser jusqu'à 1 apparemment (Message édité le 08-01-2008 à 19h47 par Rano) Chambres d'hote tavel Séjours en provence Forum mariage
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 08/01/2008 à 20:16 J'ai configuré 8 serveurs comme ça et plus aucune erreur... et ils n'ont jamais été aussi rapide. Pourvu que ça dure Chambres d'hote tavel Séjours en provence Forum mariage
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 08/01/2008 à 21:49 Rano tu viens de prendre un cours acceleré de config linux JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
Zalex14 \| Alexandre Modérateur Inscrit le : 09/05/2005	# Le 08/01/2008 à 22:26 j'ai pas compris 1/10eme de ce topic En tout cas heureux pour toi Rano Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 08/01/2008 à 22:47 mm ça pourrait être le filtre anti syn_flood alors ? je vais creuser ça, merci daevel : infogérance et conseil \|\| moi
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 09/01/2008 à 15:28 krucial a dit : Rano tu viens de prendre un cours acceleré de config linux Clair, j'ai du lire 50% d'une doc sur les paramètres de /proc En tout cas, avec la modification des paramètres, ça tient nikel, ça va super vite. Même des serveurs chargés "vont plus vite" (en tout cas, on recois les infos plus vite, moins de pertes apparemment, ou de paquets inutiles) que les mêmes serveurs sans charge. Quand j'auarais un peu de temps j'essaierai d'affiner pour voir quel paramètre exactement a joué un rôle déterminant. Chambres d'hote tavel Séjours en provence Forum mariage
Geo 113 \| Geoffrey Modérateur Inscrit le : 04/05/2005	# Le 09/01/2008 à 15:46 et les problèmes étaient donc dues à une update récente du kernel ? Cosmix Rendez imprévisible l'Economie; Mentez aux sondages
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 09/01/2008 à 16:02 Je sais pas trop, j'ai testé plusieurs kernel mis à disposition par ovh et ça n'avait rien chagné. Par contre, ça ne se pose que sur des CORE 2 QUAD pour moi. Sur les CORE 2 DUO, pas de souci. Chambres d'hote tavel Séjours en provence Forum mariage
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 09/01/2008 à 19:15 En tous cas moi ça ne change rien : j'ai toujours mes latences daevel : infogérance et conseil \|\| moi
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 14/02/2008 à 19:11 Rahhh, enfin trouvé la cause de ces soucis : ces latences ne se présentent que lorsque le module ipv6 n'est pas chargé (ou pas compilé). Avec le même kernel, et sans désactiver ipv6 tout fonctionne parfaitement bien. Maintenant reste à savoir pourquoi la désactivation provoque ces latences :S daevel : infogérance et conseil \|\| moi
midtownmad \| Ronan Membre Inscrit le : 09/05/2005	# Le 28/02/2008 à 19:03 Bonsoir, Ca va bien ? Je rencontre un problème similaire sous des serveurs Debian 4.0 Etch. Serait-il possible d'avoir les manipulations pour corriger le problème ? C'est à dire activer l'ipv6, si j'ai bien compris ? Merci. Gigi midtownmad (dit gigi par ses amis) http://www.macreators.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 28/02/2008 à 19:20 Hello, l'ipv6 est activé par défaut ; moi ce n'était pas le cas car cet hebergeur (mailclub) prend généralement la peine de désactiver ce qui ne sert pas. Pour s'en assurer, en supposant que tu ais un kernel officiel : lsmod \| grep ipv6 daevel : infogérance et conseil \|\| moi
midtownmad \| Ronan Membre Inscrit le : 09/05/2005	# Le 29/02/2008 à 10:08 nsXXXXXX:~# lsmod \| grep ipv6 Opening /proc/modules: No such file or directory Ca, c'est fait lol. Mon kernel actuel est en netboot chez OVH sur : 2.4.33 x86 & SMP & GRSEC ; par contre, je vois que le kernel 2.6.24.2 possède l'option ipv6. midtownmad (dit gigi par ses amis) http://www.macreators.com

Auteur

Message

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 08/01/2008 à 14:01

Il faut redémarrer après ?

Edit : ah bas non, si on redémarre ca va remettre l'ancienne valeur

Chambres d'hote tavel
Séjours en provence
Forum mariage

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 08/01/2008 à 14:02

Non normalement l'effet est "immédiat"

daevel : infogérance et conseil || moi

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 08/01/2008 à 14:44

Bon bah... ça ne marche pas... j'ai meme des jolis 9000ms de lag maintenant

daevel : infogérance et conseil || moi

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 08/01/2008 à 15:28

J'ai regardé la liste des ips dans netstats. Sur 15k ips, 8k fois l'ip d'un serveur dns qui était dans /etc/resolv.conf
J'ai changé la liste des serveurs dns et pour l'instant ca va "mieux" sur certaines machines...
Avec la modif que tu as indiqué aussi.

Il y a encore des lag, mais pas autant qu'avant.

Edit : ba en fait non, ca devait etre le hasard

Chambres d'hote tavel
Séjours en provence
Forum mariage

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 08/01/2008 à 17:02

D'après notre hébergeur il se pourrait que cela vienne des tailles de fenetre TCP (fonctionnement modifié récement sous linux, et qui pose des soucis avec certains équipements réseau buggés).

Ca se passe ici :

cat /proc/sys/net/ipv4/tcp_rmem

4096    16384   4194304

Il est conseillé de réduire le troisième paramêtre à 207520
(valeur de l'ancienne version du kernel à priori).

Il y a aussi son petit frère /proc/sys/net/ipv4/tcp_wmem mais je ne sais pas s'il faut le modifier.

J'attends demain pour appliquer cette modif, si celles en cours ne sont pas efficaces.

daevel : infogérance et conseil || moi

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 08/01/2008 à 17:35

okay, je teste !
edit : le premier seul ne change rien
edit : modification des deux non plus

(Message édité le 08-01-2008 à 17h45 par Rano)

Chambres d'hote tavel
Séjours en provence
Forum mariage

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 08/01/2008 à 19:22

A force de tester plein de trucs, j'ai une machine sur laquelle le problème ne se produit plus du tout depuis une heure... J'ai regardé la différence des variables entre un serveur qui merde et celui-ci et j'obtiens ça :

a gauche du != c'est celui qui merde plus, à droite celui qui a encore le problème



Array

(

    [kernel.threads-max] => 32336 != 32352

    [kernel.random.entropy_avail] => 3486 != 2934

    [kernel.pty.nr] => 2 != 1

    [vm.min_free_kbytes] => 5703 != 5704

    [net.ipv4.tcp_syn_retries] => 1 != 5

    [net.ipv4.tcp_synack_retries] => 1 != 5

    [net.ipv4.tcp_mem] => 190560 254080 381120 != 190656 254208 381312

    [net.ipv4.tcp_rmem] => 4096 87380 4194304 != 4096 87380 207520

    [net.ipv4.netfilter.ip_conntrack_generic_timeout] => 60 != 600

    [net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait] => 30 != 120

    [net.ipv4.netfilter.ip_conntrack_count] => 19044 != 45676

    [net.netfilter.nf_conntrack_generic_timeout] => 60 != 600

    [net.netfilter.nf_conntrack_count] => 19044 != 45677

    [net.netfilter.nf_conntrack_tcp_timeout_time_wait] => 30 != 120

    [fs.inode-nr] => 11473 61 != 10645 64

    [fs.inode-state] => 11473 61 0 0 0 0 0 != 10645 64 0 0 0 0 0

    [fs.file-nr] => 1312 0 200906 != 1248 0 201008

    [fs.file-max] => 200906 != 201008

    [fs.dentry-state] => 13477 9453 45 0 0 0 != 12825 8887 45 0 0 0

)

Sur la machine "ok", ce test :
ab -n 10000 -c 500 http://xxxxx/page.php

Donne en "Connect time" max : 11 ms... Alors que ca allait jusqu'à 21 secondes quand elle merdait. Je vais essayer de reproduire la config sur une autre machine pour voir.

(Message édité le 08-01-2008 à 19h28 par Rano)

(Message édité le 08-01-2008 à 19h28 par Rano)

Chambres d'hote tavel
Séjours en provence
Forum mariage

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 08/01/2008 à 19:35

Alors, sur une autre machine ca semble bon aussi (à confirmer avec le temps), avec ceci par rapport à config de base :

/sbin/sysctl -w net.ipv4.tcp_congestion_control=cubic
/sbin/sysctl -w net.ipv4.tcp_keepalive_time=120
/sbin/sysctl -w net.ipv4.tcp_keepalive_intvl=10
/sbin/sysctl -w net.ipv4.tcp_keepalive_probes=6
/sbin/sysctl -w net.ipv4.tcp_syn_retries=2
/sbin/sysctl -w net.ipv4.tcp_synack_retries=2
/sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=60
/sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait=30

edit : je mets les syn_retries à 2 plutot que 1. Pas besoin de baisser jusqu'à 1 apparemment

(Message édité le 08-01-2008 à 19h47 par Rano)

Chambres d'hote tavel
Séjours en provence
Forum mariage

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 08/01/2008 à 20:16

J'ai configuré 8 serveurs comme ça et plus aucune erreur... et ils n'ont jamais été aussi rapide. Pourvu que ça dure

Chambres d'hote tavel
Séjours en provence
Forum mariage

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 08/01/2008 à 21:49

Rano tu viens de prendre un cours acceleré de config linux

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

Zalex14 | Alexandre
Modérateur

Inscrit le : 09/05/2005

# Le 08/01/2008 à 22:26

j'ai pas compris 1/10eme de ce topic
En tout cas heureux pour toi Rano

Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 08/01/2008 à 22:47

mm ça pourrait être le filtre anti syn_flood alors ? je vais creuser ça, merci

daevel : infogérance et conseil || moi

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 09/01/2008 à 15:28

krucial a dit :
Rano tu viens de prendre un cours acceleré de config linux

Clair, j'ai du lire 50% d'une doc sur les paramètres de /proc

En tout cas, avec la modification des paramètres, ça tient nikel, ça va super vite. Même des serveurs chargés "vont plus vite" (en tout cas, on recois les infos plus vite, moins de pertes apparemment, ou de paquets inutiles) que les mêmes serveurs sans charge.

Quand j'auarais un peu de temps j'essaierai d'affiner pour voir quel paramètre exactement a joué un rôle déterminant.

Chambres d'hote tavel
Séjours en provence
Forum mariage

Geo 113 | Geoffrey
Modérateur

Inscrit le : 04/05/2005

# Le 09/01/2008 à 15:46

et les problèmes étaient donc dues à une update récente du kernel ?

Cosmix
Rendez imprévisible l'Economie; Mentez aux sondages

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 09/01/2008 à 16:02

Je sais pas trop, j'ai testé plusieurs kernel mis à disposition par ovh et ça n'avait rien chagné. Par contre, ça ne se pose que sur des CORE 2 QUAD pour moi. Sur les CORE 2 DUO, pas de souci.

Chambres d'hote tavel
Séjours en provence
Forum mariage

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 09/01/2008 à 19:15

En tous cas moi ça ne change rien : j'ai toujours mes latences

daevel : infogérance et conseil || moi

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 14/02/2008 à 19:11

Rahhh, enfin trouvé la cause de ces soucis : ces latences ne se présentent que lorsque le module ipv6 n'est pas chargé (ou pas compilé).

Avec le même kernel, et sans désactiver ipv6 tout fonctionne parfaitement bien.

Maintenant reste à savoir pourquoi la désactivation provoque ces latences :S

daevel : infogérance et conseil || moi

midtownmad | Ronan
Membre

Inscrit le : 09/05/2005

# Le 28/02/2008 à 19:03

Bonsoir,

Ca va bien ?

Je rencontre un problème similaire sous des serveurs Debian 4.0 Etch.
Serait-il possible d'avoir les manipulations pour corriger le problème ? C'est à dire activer l'ipv6, si j'ai bien compris ?

Merci. Gigi

midtownmad (dit gigi par ses amis)
http://www.macreators.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 28/02/2008 à 19:20

Hello,

l'ipv6 est activé par défaut ; moi ce n'était pas le cas car cet hebergeur (mailclub) prend généralement la peine de désactiver ce qui ne sert pas.

Pour s'en assurer, en supposant que tu ais un kernel officiel :

lsmod | grep ipv6

daevel : infogérance et conseil || moi

midtownmad | Ronan
Membre

Inscrit le : 09/05/2005

# Le 29/02/2008 à 10:08

nsXXXXXX:~# lsmod | grep ipv6

Opening /proc/modules: No such file or directory

Ca, c'est fait lol. Mon kernel actuel est en netboot chez OVH sur : 2.4.33 x86 & SMP & GRSEC ; par contre, je vois que le kernel 2.6.24.2 possède l'option ipv6.

midtownmad (dit gigi par ses amis)
http://www.macreators.com

Page 12 3

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.