Identifiez-vous Devenir membre

Rechercher

Connection time apache

61 réponses

Page |<<<12 3 4 >>>|

Auteur	Message
Bool Modérateur Inscrit le : 09/05/2005	# Le 08/01/2008 à 13:51 Sur un kernel Debian essaye ça pour voir : echo htcp > /proc/sys/net/ipv4/tcp_congestion_control Je n'en suis pas encore certain à 100%, mais aujourd'hui j'ai l'impression que ça règle les soucis. (je ne l'avais peut être pas activé sur les deux machines...) Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?
Rano 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 Modérateur Inscrit le : 09/05/2005	# Le 08/01/2008 à 14:02 Non normalement l'effet est "immédiat" Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?
Bool 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 Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?
Rano 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 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. Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?
Rano 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 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 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 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 Administrateur Inscrit le : 09/03/2005	# Le 08/01/2008 à 21:49 Rano tu viens de prendre un cours acceleré de config linux JC - Webworkerclub \| Forum construire \| Profil facebook
Zalex14 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 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 Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?
Rano 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 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 ? Eldael Interactive Ouvert ! Rendez imprévisible l'Economie; Mentez aux sondages
Rano 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 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 Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?
Bool 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 Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?
dob Modérateur Inscrit le : 10/05/2005	# Le 15/02/2008 à 10:24 On peut le charger/décharger à la volée ? Je testerais bien sur quelques machines mais pas trop envie de rebooter en boucle pour ça :/ SDNS.fr - conseil & hébergement web privés
midtownmad 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

Auteur

Message

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 08/01/2008 à 13:51

Sur un kernel Debian essaye ça pour voir :

echo htcp > /proc/sys/net/ipv4/tcp_congestion_control

Je n'en suis pas encore certain à 100%, mais aujourd'hui j'ai l'impression que ça règle les soucis.
(je ne l'avais peut être pas activé sur les deux machines...)

Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?

Rano
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
Modérateur

Inscrit le : 09/05/2005

# Le 08/01/2008 à 14:02

Non normalement l'effet est "immédiat"

Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?

Bool
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

Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?

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

Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?

Rano
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
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
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
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
Administrateur

Inscrit le : 09/03/2005

# Le 08/01/2008 à 21:49

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

JC - Webworkerclub | Forum construire | Profil facebook

Zalex14
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
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

Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?

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

Eldael Interactive Ouvert !
Rendez imprévisible l'Economie; Mentez aux sondages

Rano
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
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

Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?

Bool
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

Vous utilisez probablement des logiciels libres tous les jours, pourquoi ne pas aider à les promouvoir et les défendre ?

dob
Modérateur

Inscrit le : 10/05/2005

# Le 15/02/2008 à 10:24

On peut le charger/décharger à la volée ? Je testerais bien sur quelques machines mais pas trop envie de rebooter en boucle pour ça :/

SDNS.fr - conseil & hébergement web privés

midtownmad
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

Page |<<<12 3 4 >>>|

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.