Analyse ralentissement transaction MySQL

Le
Grégoire COUTANT
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ù (%)
Soit un developpeur qui travaille de chez lui sur ubuntu

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

La voici :
SELECT * FROM content WHERE state = '1' AND id != '5865' AND id !=
'9110' ORDER BY hits DESC;

Très simple

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 u=
n
peu longue, mais ca ne change rien.

Comment analyser ce souci ? Avec quel outil ?

Les logs mysql ne disent rien à part le slow_query, mais ca je m'en douta=
is ;-)

Des idées ?

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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le Cerdocyon
Le #21365571
--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Le 12/03/10 à 14:54, Grégoire COUTANT a ecrit:
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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkuaSpwACgkQdztIO6wJkyawxQCgniGbkBZa9RhZvrISk8ewC7Jw
km0AoOjcX9ibC7ZemIVwrZD5SjuO8cqn
=goTQ
-----END PGP SIGNATURE-----

--G4iJoqBmSsgzjUCe--

--
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
Le #21365811
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/
Publicité
Poster une réponse
Anonyme