rechercher les connexions Msql ouvertes

[raljx]

Bonjour bonjour,

j'ai récupérer un site (version "spaguettis") au niveau du code (des connexions partout partout avec des mysql_connect() mais pas de mysql_close() à chaque coup) du coup, j'ai toute une floppée de SLEEP dans mon processlist ...

Vu que je n'ai pas l'envie et le temps de prendre chaque fichier (et il y en a beaucoup beaucoup), ni de tout recoder!, connaissez vous un moyen de déterminer (logs mysql, logs apache ....) dans quelles pages se situent les connexions qui ne sont pas fermées par un mysql_close()

Sinon je pense que je vais laisser tomber

EDIT : mysql_ping() peut eventuelle faire tampon un certain temps

[Julia41]

J'avais fait un ptit script, tente un (attention à faire un backup xD)

Code: Tout sélectionner

mysql -e 'SHOW FULL PROCESSLIST;' | grep "Sleep" | awk {'print $1'} | mysql -u root -p<tonpass> -e 'kill -'

Bon, j'ai tenté de le faire en une ligne pour te montrer l'idée, faut le faire dans un for pour que ça marche

Ca devrait donner un truc comme ça :

Code: Tout sélectionner

for test in `mysql -e 'SHOW FULL PROCESSLIST;' | grep "Sleep" | awk {'print $1'}`; do echo $test; done

remplace le echo $test par un mysql -e 'kill $test'

[Julia41]

tu devrais même pouvoir regarder la durée du sleep avec un :

Code: Tout sélectionner

awk {'if ($ton_sleep_ici > 20) print $2'}

[stopher]

Salut ,

De toute manière , les connexions sont automatiquement fermées à la fin du script .
Sinon , tu peux toujours remplacer le mysql_connect() par un "singleton" que tu auras développé , ce qui t'assurera de toujours utiliser la même ressource partout dans ton code .

Good luck ,
Ch.

[raljx]

je vais tenter deja de palier dans l'urgence les SLEEP avec le script de Julia41 ...
Si je peux faire tourner le truc comme ca un moment je m'attarderai a mettre les pieds dans le code

Un grand merci a vous deux

[nza2k]

Salut ,
De toute manière , les connexions sont automatiquement fermées à la fin du script .

C'est aussi ce qui me semblait, du coup, jusqu'à présent, je n'ai pas fait l'effort d' insérer mysql_close() à la fin de mes pages php. => C'est bien ou pas bien ?

[stopher]

Ce n'est effectivement pas nécessaire le zendEngine possède un bon collector qui libérera de façon automatique , sauf s'il faut libérer la ressource le plus tôt possible ...

[nza2k]

sauf s'il faut libérer la ressource le plus tôt possible ...

Pour être bien sûr de comprendre : sauf s'il faut libérer la ressource afin la fin de l'exécution du fichier php ?
Donc, si le fichier est exécuté en 0.5 seconde, dont 0.2 seconde de traitement "post requête SQL", c'est pour libérer la ressource 0.2 seconde plus tôt ?

[stopher]

Celà ne changera pas grand chose , les habitués de la chasse aux fuites mémoire feront eux même cette cloture , les autres feront confiance au "garbage collector" qui le fera pour nous comme en java.

Laisse donc le ramasse miettes fermer la connexion pour toi , celà t'évitera d'avoir une ligne supplémentaire dans ton code .

Par contre , une ressource ( fichier, Xml, classe ect .. ) il peut être utile de la supprimer par toi même après son utilisation , en effet le fait de libérer la mémoire au fur et à mesure du script et plutôt bien apprécié .

Imaginons un script X qui au finale aura consommé ( au cumul ) 5Mo de mémoire avant enfin de se terminer , et donc de libérer la mémoire , si cette fois nous libérons la mémoire au fil du script , nous arriverons en fin de script à une consommation bien inférieur 500Ko par exemple ..

Il n'y a pas de pic de consommation de mémoire à chaque exécution du script , ce qui permet au finale au serveur de pourvoir gérer bien plus de connexions simultané .

Maintenant , ce cas n'est réellement valable uniquement sur les scripts qui utilisent des ressources gourmandes en mémoire ... , ça ne sert vraiment à rien de faire un unset() sur toutes les variables utilisées ... il n'y aura aucun gain à ce niveau .

Ch.

[nza2k]

Merci bcp pour ces explications
Je me permets de recommander !

[Rod la Kox]

Pas d'accord du tout.

Le ramasse miette comme tu dis, c'est des ressources utilisées.

Une page correcte, c'est :

écriture requêtes
connexion bdd
exécution requêtes
fermeture connexion
récup des données
libération mémoire
traitement des données
affichage

Ta voiture, tu coupe le contact dés que t'en sort. T'attend pas qu'un pseudo système détecte que t'es plus là.

[jcaron]

C'est amusant cette manie des développeurs php/mysql de vouloir fermer les connexions... Je ne sais vraiment pas si c'est une vraie bonne idée, ou si c'est juste lié au limites de nombre de connexions imposées sur les mutualisés par exemple...

Moi en ce qui me concerne (mod_perl/postgresql), le but du jeu est au contraire de conserver les connexions établies autant que possible, pour éviter l'overhead lié à la nouvelle connexion (il faut dire que postgresql utilise un process par connexion alors que mysql utilise juste un thread, mais bon, il y a quand même forcément un minimum d'overhead). Mais ça suppose évidemment que la même connexion soit réutilisée par tous les appels, et que chaque requête SQL n'ouvre pas une nouvelle connexion, sinon effectivement c'est la cata...

Bref, chez moi un serveur SQL avec plus de 1000 connexions "idle" c'est normal et volontaire, mais visiblement tout le monde n'a pas la même façon de voir les choses...

Jacques.

[Rod la Kox]

Of course.

Faut aussi ajouter la mise en cache.

[stopher]

Pas d'accord du tout.

Le ramasse miette comme tu dis, c'est des ressources utilisées.

Une page correcte, c'est :

écriture requêtes
connexion bdd
exécution requêtes
fermeture connexion
récup des données
libération mémoire
traitement des données
affichage

Ta voiture, tu coupe le contact dés que t'en sort. T'attend pas qu'un pseudo système détecte que t'es plus là.

Quand tu libères la mémoire , c'est bien la mémoire du résultat de la requête , avec mysql_free_result par exemple , alors là ok .

Mais ta ressource à ta base , tu peux encore l'utiliser dans la suite de ton script , s'il continu d'une manière ou d'une autre .
utiliser mysql_close() ou laisse le zend_engine le faire à ta place , ne changera pas grand chose ..

Enfin , c'est toujours comme ça que je l'ai vu ..

Perso je preferts utiliser 1 connexion par session ( exécution de script ), le script se lance , je connecte , je fais mes X requetes au fil du script exécuté , c'est fini , la connexion est coupé .

Apres il existe des connexions persistantes si l'on veut aller plus loin , mais c'est encore un autre débats .. il y a des pour et des contres .. mais dans 99% des cas , les connexions non persistantes sont recommandés .