Optimisation des connexions TCP du noyau

Le
Johan Dindaine
Re-bonjour la liste,

J'ai en ce moment un nombre super important de connexions vers mon
serveur de base de données qui ne sont pas fermés proprement.

netstat | grep mysql | wc -l
405

netstat | grep mysql
tcp 0 0 webserv:60957 mysqlserv:mysql TIME_WAIT
tcp 0 0 webserv:60956 mysqlserv:mysql TIME_WAIT
tcp 0 0 webserv:60959 mysqlserv:mysql TIME_WAIT
tcp 0 0 webserv:60958 mysqlserv:mysql TIME_WAIT

Cependant il y a une chose que je ne comprends pas dans mon noyau au
démarrage j'ai un script qui me mets les timout a 5 sec et je ne
comprends vraiment pas pourquoi j'ai ces conexion qui stagnent comme
cela.

Quelqu'un aurait une idée s'il vous plait?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Grégory Bulot
Le #20111741
Johan Dindaine 14:57:39 +0100
Re-bonjour la liste,

J'ai en ce moment un nombre super important de connexions vers mon
serveur de base de données qui ne sont pas fermés proprement.

netstat | grep mysql | wc -l
405

netstat | grep mysql
tcp 0 0 webserv:60957 mysqlserv:mysql TIME_WAIT
tcp 0 0 webserv:60956 mysqlserv:mysql TIME_WAIT
tcp 0 0 webserv:60959 mysqlserv:mysql TIME_WAIT
tcp 0 0 webserv:60958 mysqlserv:mysql TIME_WAIT

Cependant il y a une chose que je ne comprends pas dans mon noyau au
démarrage j'ai un script qui me mets les timout a 5 sec et je ne
comprends vraiment pas pourquoi j'ai ces conexion qui stagnent comme
cela.

Quelqu'un aurait une idée s'il vous plait?



Regarde tous ce qui utilise mysql (php ?), si ce sont des projets
php perso ou ayant potentiellement un fort dialogue sql voir :
- si tu peux remplacer les mysql_pconnect par mysql_pconnect
- voir si après ouverture d'une ressource sur une base, cela est ferm é
à la fin du script.


Tes Bases sont-elles répliquées (maitre-esclave ?)


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Johan Dindaine
Le #20112091
Le 10 septembre 2009 15:40, Grégory Bulot
Johan Dindaine 14:57:39 +0100
Re-bonjour la liste,

J'ai en ce moment un nombre super important de connexions vers mon
serveur de base de données qui ne sont pas fermés proprement.

netstat | grep mysql | wc -l
405

netstat | grep mysql
tcp        0      0 webserv:60957 mysqlserv:mysql     TIME_WAIT
tcp        0      0 webserv:60956 mysqlserv:mysql     TIME_WAIT
tcp        0      0 webserv:60959 mysqlserv:mysql     TIME_WAIT
tcp        0      0 webserv:60958 mysqlserv:mysql     TIME_WAIT

Cependant il y a une chose que je ne comprends pas dans mon noyau au
démarrage j'ai un script qui me mets les timout a 5 sec et je ne
comprends vraiment pas pourquoi j'ai ces conexion qui stagnent comme
cela.

Quelqu'un aurait une idée s'il vous plait?



Regarde tous ce qui utilise mysql (php ?), si ce sont des projets
php perso ou ayant potentiellement un fort dialogue sql voir :
- si tu peux remplacer les mysql_pconnect par mysql_pconnect
- voir si après ouverture d'une ressource sur une base, cela est ferm é
à la fin du script.


Tes Bases sont-elles répliquées (maitre-esclave ?)



Elle sont répliqué et la connexion loquée est celle sur le master.



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Grégory Bulot
Le #20112521
Johan Dindaine 16:27:20 +0100


> Tes Bases sont-elles répliquées (maitre-esclave ?)

Elle sont répliqué et la connexion loquée est celle sur le master.



dans mysql
show master|slave status te dirais pas qu'il y a un pb de sync entre
maitre esclave ?

tu prends le fichier (ex : mysql-bin.003) indiqué par cette commande
et tu vi /var/log/mysql/[le fichier de log]

tu regarde s'il n'y a pas de message d'erreur sql ...(lecture en
diagonale ....)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Johan Dindaine
Le #20117561
le probleme n'est pas entre le master et slave mais entre le slave et
le serveur WEB.
J'ai des connexions stagnantes entre sur mon serveur web. Et je ne
comprends la raison puisse que ceux ci doivent etre coupé apres 5
secondes comme configuré dans le noyau

# cat /proc/sys/net/ipv4/tcp_fin_timeout
5

Le 10 septembre 2009 16:43, Grégory Bulot
Johan Dindaine 16:27:20 +0100


> Tes Bases sont-elles répliquées (maitre-esclave ?)

Elle sont répliqué et la connexion loquée est celle sur le master.



dans mysql
show master|slave status te dirais pas qu'il y a un pb de sync entre
maitre esclave ?

tu prends le fichier (ex : mysql-bin.003) indiqué par cette commande
et tu vi /var/log/mysql/[le fichier de log]

tu regarde s'il n'y a pas de message d'erreur sql ...(lecture en
diagonale ....)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Vera Mickael
Le #20118291
Est-ce que les connexions ne doivent pas être coupées par le
noyau uniquement dans certaines conditions qui ne sont pas
réunies ici ? Es-tu sûr de bien comprendre à quoi correspond
ce paramètre ? Est-ce que les connexions ne sont pas tout
simplement conservées ouvertes côté serveur WEB suite à une
mauvaise programmation ? Ce qui expliquerait que le noyau ne
libère pas les ressources.

Je ne suis pas spécialiste mais il me semble que normalement
il existe des pool de connexions utilisés pas les serveurs
WEBs qui devraient de toute façon limiter le nombre de
connexions réseau non ?

Mickaël

Johan Dindaine a écrit :
le probleme n'est pas entre le master et slave mais entre le slave et
le serveur WEB.
J'ai des connexions stagnantes entre sur mon serveur web. Et je ne
comprends la raison puisse que ceux ci doivent etre coupé apres 5
secondes comme configuré dans le noyau

# cat /proc/sys/net/ipv4/tcp_fin_timeout
5

Le 10 septembre 2009 16:43, Grégory Bulot
Johan Dindaine 16:27:20 +0100


Tes Bases sont-elles répliquées (maitre-esclave ?)


Elle sont répliqué et la connexion loquée est celle sur le master.


dans mysql
show master|slave status te dirais pas qu'il y a un pb de sync entre
maitre esclave ?

tu prends le fichier (ex : mysql-bin.003) indiqué par cette commande
et tu vi /var/log/mysql/[le fichier de log]

tu regarde s'il n'y a pas de message d'erreur sql ...(lecture en
diagonale ....)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS








--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Jean-Michel OLTRA
Le #20118441
Bonjour,


Le vendredi 11 septembre 2009, Vera Mickael a écrit...

>J'ai des connexions stagnantes entre sur mon serveur web. Et je ne
>comprends la raison puisse que ceux ci doivent etre coupé apres 5
>secondes comme configuré dans le noyau



Es-tu sûr de bien comprendre à quoi correspond ce paramètre ? Est-ce
que les connexions ne sont pas tout simplement conservées ouvertes
côté serveur WEB suite à une mauvaise programmation ? Ce qui
expliquerait que le noyau ne libère pas les ressources.



Je ne suis pas spécialiste mais il me semble que normalement il
existe des pool de connexions utilisés pas les serveurs WEBs qui
devraient de toute façon limiter le nombre de connexions réseau non ?



Certainement. Et un close() sur une connexion appartenant à un pool ne
doit (devrait ?) pas fermer la connexion, mais la rendre au pool,
l'établissement de la connexion étant une perte de temps.

--
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.spidboutic.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Johan Dindaine
Le #20119871
Le 11 septembre 2009 13:44, Jean-Michel OLTRA

   Bonjour,


Le vendredi 11 septembre 2009, Vera Mickael a écrit...

>J'ai des connexions stagnantes entre sur mon serveur web. Et je ne
>comprends la raison puisse que ceux ci doivent etre coupé apres 5
>secondes comme configuré dans le noyau



Es-tu sûr de bien comprendre à quoi correspond ce paramètre ? Est- ce
que les connexions ne sont pas tout simplement conservées ouvertes
côté serveur WEB suite à une mauvaise programmation ? Ce qui
expliquerait que le noyau ne libère pas les ressources.



Je ne suis pas spécialiste mais il me semble que normalement il
existe des pool de connexions utilisés pas les serveurs WEBs qui
devraient de toute façon limiter le nombre de connexions réseau non ?



Certainement. Et un close() sur une connexion appartenant à un pool ne
doit (devrait ?) pas fermer la connexion, mais la rendre au pool,
l'établissement de la connexion étant une perte de temps.



Sur la page http://www.speedguide.net/read_articles.php?id1
il est marqué:
TCP_FIN_TIMEOUT
This setting determines the time that must elapse before TCP/IP can
release a closed connection and reuse its resources. During this
TIME_WAIT state, reopening the connection to the client costs less
than establishing a new connection. By reducing the value of this
entry, TCP/IP can release closed connections faster, making more
resources available for new connections. Addjust this in the presense
of many connections sitting in the TIME_WAIT state

Ce qui veut dire que si au bout de 5 secondes une connexion n'est pas
réutilisée elle est est fermée. Ce qui est totallement le contraire d e
ce que je peux constater en ce moment.


--
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.spidboutic.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Jean-Michel OLTRA
Le #20120221
Bonjour,


Le vendredi 11 septembre 2009, Johan Dindaine a écrit...


> Certainement. Et un close() sur une connexion appartenant à un pool ne
> doit (devrait ?) pas fermer la connexion, mais la rendre au pool,
> l'établissement de la connexion étant une perte de temps.



Sur la page http://www.speedguide.net/read_articles.php?id1
il est marqué:
TCP_FIN_TIMEOUT
This setting determines the time that must elapse before TCP/IP can
release a closed connection and reuse its resources. During this
TIME_WAIT state, reopening the connection to the client costs less
than establishing a new connection. By reducing the value of this
entry, TCP/IP can release closed connections faster, making more
resources available for new connections. Addjust this in the presense
of many connections sitting in the TIME_WAIT state



Ce qui veut dire que si au bout de 5 secondes une connexion n'est pas
réutilisée elle est est fermée. Ce qui est totallement le contraire de
ce que je peux constater en ce moment.



Je suis mauvais en anglais mais je ne dirais pas ça. La variable que tu
cites agirait sur des connexions fermées en libérant les ressources
allouées à la connexion. Si la connexion n'est pas véritablement fermée,
je ne sais pas si ce paramètre joue.

Les pools de connexions ont toujours des connexions ouvertes en réserve
(sauf si elles sont toutes occupées) jusqu'à concurrence du nombre
maximal paramétré.

--
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.spidboutic.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Johan Dindaine
Le #20120611
Je vais profiler l'application entiere afin de voir si quelqu'un n'a
pas laissé une connexion ouverte dans une des action alors.

Je parirais pas qu'il y ait sur une petite page que l'on ne teste
malheureusement pas un petit mysql_connect sans fermeture.

Le 11 septembre 2009 17:20, Jean-Michel OLTRA

   Bonjour,


Le vendredi 11 septembre 2009, Johan Dindaine a écrit...


> Certainement. Et un close() sur une connexion appartenant à un pool ne
> doit (devrait ?) pas fermer la connexion, mais la rendre au pool,
> l'établissement de la connexion étant une perte de temps.



Sur la page http://www.speedguide.net/read_articles.php?id1
il est marqué:
TCP_FIN_TIMEOUT
This setting determines the time that must elapse before TCP/IP can
release a closed connection and reuse its resources. During this
TIME_WAIT state, reopening the connection to the client costs less
than establishing a new connection. By reducing the value of this
entry, TCP/IP can release closed connections faster, making more
resources available for new connections. Addjust this in the presense
of many connections sitting in the TIME_WAIT state



Ce qui veut dire que si au bout de 5 secondes une connexion n'est pas
réutilisée elle est est fermée. Ce qui est totallement le contrair e de
ce que je peux constater en ce moment.



Je suis mauvais en anglais mais je ne dirais pas ça. La variable que tu
cites agirait sur des connexions fermées en libérant les ressources
allouées à la connexion. Si la connexion n'est pas véritablement fe rmée,
je ne sais pas si ce paramètre joue.

Les pools de connexions ont toujours des connexions ouvertes en réserve
(sauf si elles sont toutes occupées) jusqu'à concurrence du nombre
maximal paramétré.

--
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.spidboutic.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Vera Mickael
Le #20137411
Johan Dindaine a écrit :
Je vais profiler l'application entiere afin de voir si quelqu'un n'a
pas laissé une connexion ouverte dans une des action alors.

Je parirais pas qu'il y ait sur une petite page que l'on ne teste
malheureusement pas un petit mysql_connect sans fermeture.



Salut,

Comme a dit Jean-Michel, ce n'est pas toi qui gère
directement l'ouverture de la connexion TCP, le pool de
connexions, une couche intermédiaire, le fait pour toi.

Au lancement de ton application, un certain nombre de
connexions sont ouvertes par le pool et le resteront
toujours. Lorsque tu as besoin d'une connexion le pool t'en
attribue une. Lorsque tu libères la connexion le pool ne la
ferme pas mais la garde en réserve pour une prochaine demande.

Etant donné que le pool ne ferme pas de connexions, je pense
que le paramètre du noyau sur lequel tu joues n'a absolument
aucun effet.

Si tu utilises une système avec les bons outils, tu devrais
pouvoir monitorer:

- le nombre de connexions à MySql
- le nombre de connexions utilisées de ton pool

Normalement ce chiffre devrait toujours rester très bas, en
dessous de 10.

Je ne sais pas ce que l'on peut monitorer au niveau noyau ?

Mickaël

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Publicité
Poster une réponse
Anonyme