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?
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?
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?
Johan Dindaine à écrit le Thu, 10 Sep 2009
14:57:39 +0100Re-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 <jojolapin972@gmail.com> à écrit le Thu, 10 Sep 2009
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Johan Dindaine à écrit le Thu, 10 Sep 2009
14:57:39 +0100Re-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
> Tes Bases sont-elles répliquées (maitre-esclave ?)
Elle sont répliqué et la connexion loquée est celle sur le master.
> Tes Bases sont-elles répliquées (maitre-esclave ?)
Elle sont répliqué et la connexion loquée est celle sur le master.
> Tes Bases sont-elles répliquées (maitre-esclave ?)
Elle sont répliqué et la connexion loquée est celle sur le master.
Johan Dindaine à écrit le Thu, 10 Sep 2009
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 <jojolapin972@gmail.com> à écrit le Thu, 10 Sep 2009
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Johan Dindaine à écrit le Thu, 10 Sep 2009
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
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
a écrit :Johan Dindaine à écrit le Thu, 10 Sep 2009
16:27:20 +0100Tes 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
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
<debian.list@batman.dyndns.org> a écrit :
Johan Dindaine <jojolapin972@gmail.com> à écrit le Thu, 10 Sep 2009
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
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
a écrit :Johan Dindaine à écrit le Thu, 10 Sep 2009
16:27:20 +0100Tes 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
>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 ?
>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 ?
>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 ?
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 noyauEs-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
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
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 noyauEs-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
> 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.
> 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.
> 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.
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 stateCe 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
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?id=121
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
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 stateCe 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
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.
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.
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.