Comment déterminer quel code PHP ouvre les connexions MySQL qui ne sont pas fermées

Question

Nous avons une application composée de deux applications PHP standard (ExpressionEngine et XCart) ainsi que de notre propre code personnalisé.

Je n’ai pas fait l’analyse proprement dite, je ne sais donc pas exactement comment cela a été déterminé, mais je ne suis pas surpris d’apprendre que trop de connexions MySQL sont non communiquées (je ne suis pas étonné car j’ai constaté une importante fuite de mémoire sur notre serveur de développement, où, en l'espace d'un jour ou deux, à partir de 100 Mo lors du démarrage initial, la totalité du volume de RAM est consommée et très peu est mise en cache).

Alors, comment pouvons-nous déterminer précisément quel code PHP est le coupable? J'ai une expérience préalable de XDebug et je suggère que, lorsque notre environnement séparé et de stockage intermédiaire est relativement stable, nous adaptions XDebug sur dev et que nous l'utilisions pour effectuer certaines analyses. Est-ce raisonnable et / ou quelqu'un d'autre a-t-il des suggestions plus spécifiques et / ou supplémentaires?

Answer 1

Vous pouvez utiliser le

 SHOW PROCESSLIST  

Commande SQL pour voir quels processus sont en cours d'exécution. Cela vous indiquera le nom d'utilisateur, l'hôte, la base de données, etc. utilisés par chaque processus. Cela devrait vous donner une idée de ce qui se passe, surtout si vous avez accès à plusieurs bases de données.

Plus ici: http://codeinthehole.com/archives/2- Surveillance-MySQL-processus.html

Answer 2

Cela ne devrait pas être causé par un code php car les connexions mysql sont supposées être automatiquement fermées.

cf: http://www.php.net/manual/function .mysql-connect.php :

  

Le lien vers le serveur sera fermé   dès l'exécution du script   se termine, à moins que ce soit fermé plus tôt par   appelant explicitement mysql_close ().

Quelques suggestions:

• votre développeur a-t-il techniquement un accès direct à votre serveur de production mysql? Si oui, alors ils vont probablement laisser leur gestionnaire Mysql ouvert:)
• avez-vous un traitement quotidien par lots? si oui, peut-être qu'il y a un processus zombi en mémoire

Answer 3

PHP ferme automatiquement toutes les connexions mysql à la fin de la page. La seule raison pour laquelle une application Web PHP aurait trop de connexions mysql non fermées est 1) si vous utilisez le pooling de connexions, ou 2) il y a un bogue dans le serveur mysql ou le connecteur.

mais si vous voulez vraiment regarder votre code pour trouver où il se connecte, voir http: // xdebug. org / docs / profiler

Answer 4

Comme d'autres l'ont dit, PHP met fin aux connexions MySQL créées via mysql_connect ou les équivalents msqli / PDO.

Cependant, vous pouvez créer des connexions persistantes avec mysql_pconnect . Il recherchera les connexions existantes ouvertes et les utilisera; s'il ne peut pas en trouver un, il en ouvrira un autre. Si vous aviez beaucoup de demandes en même temps, cela aurait pu causer l’ouverture et le maintien de nombreuses connexions.

Vous pouvez réduire le nombre maximal de connexions ou le délai d'expiration des connexions persistantes. Voir les commentaires au bas de la page de manuel pour plus d'informations. détails.

Answer 5

J'avais l'habitude d'exécuter un script qui interrogeait SHOW STATUS sur le nombre de threads et j'ai remarqué que l'utilisation de mysql_pconnect encourageait toujours un nombre élevé de threads. J'ai trouvé cela très déconcertant, car je ne pouvais pas dire quand mon débit de connexion était en train de chuter. Je me suis donc assuré de centraliser tous les endroits où mysql_connect () était appelé et d’éliminer mysql_pconnect ().

Ensuite, j’ai examiné les délais de connexion et les ai ajustés à environ 30 secondes, car. J'ai donc ajusté mon my.cnf avec

connect-timeout = 30

afin que je puisse réellement voir le nombre de connexions chuter. La détermination du nombre de connexions à ouvrir dépend du nombre de travailleurs Apache que vous exécutez et du nombre de connexions à la base de données qu'ils ouvriront.

L’autre chose que j’ai commencée à faire a été d’ajouter une note à mes requêtes afin de les repérer dans SHOW PROCESSLIST ou dans mytop, j’ajouterais une colonne de note à mes résultats, comme suit:

$q = "SELECT '".__FILE__.'.'.__LINE__."' as _info, * FROM table ...";

Cela me montrerait le fichier à l'origine de la requête lorsque j'ai consulté mytop, et cela n'a pas altéré le cache de requêtes MySQL comme si

/* __FILE__.'.'.__LINE__ */ 

au début de ma requête serait.

Answer 6

Je suppose qu’une autre chose que je peux faire, en ce qui concerne le problème général de la mémoire, par opposition à MySQL, et en particulier dans le contexte de notre propre code personnalisé, consisterait à envelopper notre code avec des appels à un ou à l’autre. autre des fonctions intégrées suivantes de PHP:

memory_get_usage

memory_get_peak_usage

En particulier, étant donné que je travaille actuellement sur la journalisation à partir d'un code personnalisé, je peux consigner l'utilisation de la mémoire pendant que j'y suis

.