Ca concerne plus ou moins de loin une question sur un serveur debian,
alors sorry si je suis HS.
Soit MySQL sur un serveur debian 5
Soit une base test accessible au user test de n'importe o=F9 (%)
Soit un developpeur qui travaille de chez lui sur ubuntu
Chaque requete =E0 la base est extr=EAmement longue =E0 partir de ce PC
alors qu'en local elle prend moins de 0.3 secondes et via les autres
serveurs =E9galement.
La requ=EAte passe par diff=E9rents =E9tat, reste assez longtemps sur l'=E9=
tat
"Writing on net" (60 =E0 120 secondes) et ensuite passe en "Sleep" (60 =E0
120 secs =E9galement), mais le r=E9sultat n'arrive toujours pas sur le PC
du d=E9veloppeur.
La voici :
SELECT * FROM content WHERE state =3D '1' AND id !=3D '5865' AND id !=3D
'9110' ORDER BY hits DESC;
Tr=E8s simple...
J'ai propos=E9 =E0 l'utilisateur de mettre l'ip du serveur sql dans son
/etc/hosts en pensant que c'=E9tait peut =EAtre un pb de r=E9solution dns u=
n
peu longue, mais ca ne change rien.
Comment analyser ce souci ? Avec quel outil ?
Les logs mysql ne disent rien =E0 part le slow_query, mais ca je m'en douta=
is ;-)
Des id=E9es ?
Greg
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
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
Archive: http://lists.debian.org/464735d91003120554p1494b098wf608b34ce97b541@mail.gmail.com
Ca concerne plus ou moins de loin une question sur un serveur debian, alors sorry si je suis HS.
Ouais ici si on regarde bien tout est HS si tu vas par là ;-)
Soit MySQL sur un serveur debian 5 Soit une base test accessible au user test de n'importe où (%) Soit un developpeur qui travaille de chez lui sur ubuntu
Il faut que tu déclares ton user (ayant droit sur la base) de pouvoir y a ccéder à distance, c'est préférable qu'un simple accès depuis % - partout / all
Sépare tes acces local = locahost et distant, point de vue sécurité c'est mieux.
Ca fait un moment que je n'ai pas bosser sur un mysql, mais il me semble bi en que c'est dans la base mysql ou user.
Chaque requete à la base est extrêmement longue à partir de ce PC alors qu'en local elle prend moins de 0.3 secondes et via les autres serveurs également.
Il y'à peut etre un filtrage de flux entre les deux ? un firewall, vlan o u autre qui gene la liaison (quoi si il y accede, le vlan est bien configurer)
La requête passe par différents état, reste assez longtemps sur l' état "Writing on net" (60 à 120 secondes) et ensuite passe en "Sleep" (60 à 120 secs également), mais le résultat n'arrive toujours pas sur le PC du développeur.
là je ne vois pas
La voici : SELECT * FROM content WHERE state = '1' AND id != '5865' AND id != '9110' ORDER BY hits DESC;
Très simple...
C'est clair.
J'ai proposé à l'utilisateur de mettre l'ip du serveur sql dans son /etc/hosts en pensant que c'était peut être un pb de résolution dns un peu longue, mais ca ne change rien.
non mais l'accès distant déclaré pour ton ayant droit sur la base peu t arranger les choses.
Comment analyser ce souci ? Avec quel outil ?
Les log systemes.
Les logs mysql ne disent rien à part le slow_query, mais ca je m'en dout ais ;-)
;-)
Des idées ?
Celles que j'évoquais
Greg
Cerdo
fin du message de Grégoire COUTANT
-- Cerdocyon key ID 0x773B483BAC099326
--G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline
Ca concerne plus ou moins de loin une question sur un serveur debian,
alors sorry si je suis HS.
Ouais ici si on regarde bien tout est HS si tu vas par là ;-)
Soit MySQL sur un serveur debian 5
Soit une base test accessible au user test de n'importe où (%)
Soit un developpeur qui travaille de chez lui sur ubuntu
Il faut que tu déclares ton user (ayant droit sur la base) de pouvoir y a ccéder
à distance, c'est préférable qu'un simple accès depuis % - partout / all
Sépare tes acces local = locahost et distant, point de vue sécurité c'est mieux.
Ca fait un moment que je n'ai pas bosser sur un mysql, mais il me semble bi en que
c'est dans la base mysql ou user.
Chaque requete à la base est extrêmement longue à partir de ce PC
alors qu'en local elle prend moins de 0.3 secondes et via les autres
serveurs également.
Il y'à peut etre un filtrage de flux entre les deux ? un firewall, vlan o u autre qui
gene la liaison (quoi si il y accede, le vlan est bien configurer)
La requête passe par différents état, reste assez longtemps sur l' état
"Writing on net" (60 à 120 secondes) et ensuite passe en "Sleep" (60 à
120 secs également), mais le résultat n'arrive toujours pas sur le PC
du développeur.
là je ne vois pas
La voici :
SELECT * FROM content WHERE state = '1' AND id != '5865' AND id !=
'9110' ORDER BY hits DESC;
Très simple...
C'est clair.
J'ai proposé à l'utilisateur de mettre l'ip du serveur sql dans son
/etc/hosts en pensant que c'était peut être un pb de résolution dns un
peu longue, mais ca ne change rien.
non mais l'accès distant déclaré pour ton ayant droit sur la base peu t arranger les choses.
Comment analyser ce souci ? Avec quel outil ?
Les log systemes.
Les logs mysql ne disent rien à part le slow_query, mais ca je m'en dout ais ;-)
;-)
Des idées ?
Celles que j'évoquais
Greg
Cerdo
fin du message de Grégoire COUTANT
--
Cerdocyon
key ID 0x773B483BAC099326
--G4iJoqBmSsgzjUCe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
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
Archive: http://lists.debian.org/20100312140724.GA18249@the-rabbit-hole.co.uk
Ca concerne plus ou moins de loin une question sur un serveur debian, alors sorry si je suis HS.
Ouais ici si on regarde bien tout est HS si tu vas par là ;-)
Soit MySQL sur un serveur debian 5 Soit une base test accessible au user test de n'importe où (%) Soit un developpeur qui travaille de chez lui sur ubuntu
Il faut que tu déclares ton user (ayant droit sur la base) de pouvoir y a ccéder à distance, c'est préférable qu'un simple accès depuis % - partout / all
Sépare tes acces local = locahost et distant, point de vue sécurité c'est mieux.
Ca fait un moment que je n'ai pas bosser sur un mysql, mais il me semble bi en que c'est dans la base mysql ou user.
Chaque requete à la base est extrêmement longue à partir de ce PC alors qu'en local elle prend moins de 0.3 secondes et via les autres serveurs également.
Il y'à peut etre un filtrage de flux entre les deux ? un firewall, vlan o u autre qui gene la liaison (quoi si il y accede, le vlan est bien configurer)
La requête passe par différents état, reste assez longtemps sur l' état "Writing on net" (60 à 120 secondes) et ensuite passe en "Sleep" (60 à 120 secs également), mais le résultat n'arrive toujours pas sur le PC du développeur.
là je ne vois pas
La voici : SELECT * FROM content WHERE state = '1' AND id != '5865' AND id != '9110' ORDER BY hits DESC;
Très simple...
C'est clair.
J'ai proposé à l'utilisateur de mettre l'ip du serveur sql dans son /etc/hosts en pensant que c'était peut être un pb de résolution dns un peu longue, mais ca ne change rien.
non mais l'accès distant déclaré pour ton ayant droit sur la base peu t arranger les choses.
Comment analyser ce souci ? Avec quel outil ?
Les log systemes.
Les logs mysql ne disent rien à part le slow_query, mais ca je m'en dout ais ;-)
;-)
Des idées ?
Celles que j'évoquais
Greg
Cerdo
fin du message de Grégoire COUTANT
-- Cerdocyon key ID 0x773B483BAC099326
--G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
François Cerbelle
Grégoire COUTANT a écrit : [...]
La requête passe par différents état, reste assez longtemps sur l'état "Writing on net" (60 à 120 secondes) et ensuite passe en "Sleep" (60 à 120 secs également), mais le résultat n'arrive toujours pas sur le PC du développeur.
Le writing on net peut être long si le résultat est volumineux et qu'il transite par un lien lent sur le trajet. L'état Sleep dure tant que la connexion reste ouverte et qu'aucune requête n'est en cours sur cette connexion.
La voici : SELECT * FROM content WHERE state = '1' AND id != '5865' AND id ! > '9110' ORDER BY hits DESC; Très simple...
Heu, si c'est une requête générée (ou non, d'ailleurs), tu devrais envisager : SELECT * FROM content WHERE state = '1' AND id NOT IN ('5865','9110') ORDER BY hits DESC; Ça a au moins le mérite d'être plus lisible.
J'ai proposé à l'utilisateur de mettre l'ip du serveur sql dans son /etc/hosts en pensant que c'était peut être un pb de résolution dns un peu longue, mais ca ne change rien.
Oui, ça aurait pu, mais apparemment pas dans le sens aller, plutôt dans le sens retour, puisque ton serveur semble recevoir la requête instantanément, mais semble avoir des problèmes pour renvoyer le résultat.
Tu as peut etre un équipement réseau entre le serveur et le poste utilisateur qui cherche à faire une résolution DNS alors que le nom ou l'IP n'est pas défini. Ca peut aussi etre un filtrage de contenu.
Tu peux essayer avec d'autres protocoles comme un téléchargement par HTTP (pas FTP qui jongle avec les ports), par exemple.
Fanfan
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Grégoire COUTANT a écrit :
[...]
La requête passe par différents état, reste assez longtemps sur l'état
"Writing on net" (60 à 120 secondes) et ensuite passe en "Sleep" (60 à
120 secs également), mais le résultat n'arrive toujours pas sur le PC
du développeur.
Le writing on net peut être long si le résultat est volumineux et qu'il transite par un lien lent
sur le trajet. L'état Sleep dure tant que la connexion reste ouverte et qu'aucune requête n'est en
cours sur cette connexion.
La voici :
SELECT * FROM content WHERE state = '1' AND id != '5865' AND id ! > '9110' ORDER BY hits DESC;
Très simple...
Heu, si c'est une requête générée (ou non, d'ailleurs), tu devrais envisager :
SELECT * FROM content WHERE state = '1' AND id NOT IN ('5865','9110') ORDER BY hits DESC;
Ça a au moins le mérite d'être plus lisible.
J'ai proposé à l'utilisateur de mettre l'ip du serveur sql dans son
/etc/hosts en pensant que c'était peut être un pb de résolution dns un
peu longue, mais ca ne change rien.
Oui, ça aurait pu, mais apparemment pas dans le sens aller, plutôt dans le sens retour, puisque ton
serveur semble recevoir la requête instantanément, mais semble avoir des problèmes pour renvoyer le
résultat.
Tu as peut etre un équipement réseau entre le serveur et le poste utilisateur qui cherche à faire
une résolution DNS alors que le nom ou l'IP n'est pas défini. Ca peut aussi etre un filtrage de contenu.
Tu peux essayer avec d'autres protocoles comme un téléchargement par HTTP (pas FTP qui jongle avec
les ports), par exemple.
Fanfan
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
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
Archive: http://lists.debian.org/4B9A5959.9080903@cerbelle.net
La requête passe par différents état, reste assez longtemps sur l'état "Writing on net" (60 à 120 secondes) et ensuite passe en "Sleep" (60 à 120 secs également), mais le résultat n'arrive toujours pas sur le PC du développeur.
Le writing on net peut être long si le résultat est volumineux et qu'il transite par un lien lent sur le trajet. L'état Sleep dure tant que la connexion reste ouverte et qu'aucune requête n'est en cours sur cette connexion.
La voici : SELECT * FROM content WHERE state = '1' AND id != '5865' AND id ! > '9110' ORDER BY hits DESC; Très simple...
Heu, si c'est une requête générée (ou non, d'ailleurs), tu devrais envisager : SELECT * FROM content WHERE state = '1' AND id NOT IN ('5865','9110') ORDER BY hits DESC; Ça a au moins le mérite d'être plus lisible.
J'ai proposé à l'utilisateur de mettre l'ip du serveur sql dans son /etc/hosts en pensant que c'était peut être un pb de résolution dns un peu longue, mais ca ne change rien.
Oui, ça aurait pu, mais apparemment pas dans le sens aller, plutôt dans le sens retour, puisque ton serveur semble recevoir la requête instantanément, mais semble avoir des problèmes pour renvoyer le résultat.
Tu as peut etre un équipement réseau entre le serveur et le poste utilisateur qui cherche à faire une résolution DNS alors que le nom ou l'IP n'est pas défini. Ca peut aussi etre un filtrage de contenu.
Tu peux essayer avec d'autres protocoles comme un téléchargement par HTTP (pas FTP qui jongle avec les ports), par exemple.
Fanfan
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
