Comment réduire le processus de connexion vide du sommeil en php et mysql

Un grand nombre de connexions vides en état de veille de la base de données sont apparues dans le système développé. Dans le même temps, grâce au journal, il a été constaté qu'il y avait un grand nombre d'exceptions dans les commentaires du tiers. Interface API demandée via curl de PHP dans le système, je n'ai pas pu m'empêcher de connecter les deux pour analyser les raisons. Le journal indique que l'interface tierce répond lentement et que le résultat est vide. La raison est inconnue, mais il est concevable que PHP attende le retour de la connexion après avoir émis une requête curl. Pendant le processus d'attente, la connexion à la base de données commence à se connecter. dormir jusqu'à ce que curl expire et que le lien de base de données soit libéré après l'exécution du processus.

1. Test technique pratique php+mysql+memcache

Il y a deux questions anormales Les questions sont très anormales, mais ce sont des cas réels rencontrés en combat réel,

.

1 : J'écris un programme qui utilise à la fois mysql et memcache

La première ligne est

mysql_connect et la deuxième ligne est memcache_connect

Writing. une fois terminé, la première ligne est memcache_connect et la deuxième ligne est mysql_connect

caoz a découvert qu'il y avait une grande différence entre ces deux façons d'écrire dans la pratique.

2 : J'ai écrit un programme, utilisé MySQL, généré une page et finalement utilisé echo $html ; pour afficher

Une façon de l'écrire est

mysql_close ();

echo $html;

L'autre est

echo $html;

mysql_close();

caoz a constaté qu'il y a une grande différence entre les deux dans la pratique. Quelle est la différence ?

Les deux sont des cas découverts et ajustés dans la pratique.

caoz n'est pas quelqu'un qui recherche BT lors de l'écriture de programmes. Caoz souligne souvent auprès des ingénieurs qu'il ne recherche pas d'expression technique extrême ou de démonstration technique. Par conséquent, si les lecteurs pensent que les questions ici sont pour de soi-disant raisons. car une certaine méthode d'écriture est meilleure qu'une certaine. Si la surcharge des ressources d'écriture est plus petite ou autre chose, ce n'est vraiment pas l'intention initiale de caoz.

Ces deux questions sont des cas typiques rencontrés dans des environnements opérationnels réels. Où sont les cas typiques ? Autrement dit, lorsque vous rencontrez une défaillance du système, comment analysez-vous, comment pensez-vous et comment jugez-vous l'impact de plusieurs facteurs liés. Par conséquent, peu importe que vous puissiez répondre à cette question ou non. est de savoir comment penser la relation entre les systèmes.

Une panne système typique est un trop grand nombre de connexions MySQL, ou un trop grand nombre de connexions. Ce problème nous préoccupe depuis longtemps. Si cela est causé par l'indexation ou des demandes de données simultanées, localisez la cause. mais une fois le problème ci-dessus résolu, un phénomène étrange s'est produit. Il n'y avait presque aucune pression sur la base de données, aucun processus bloqué et aucune requête lente, mais il y avait de nombreuses connexions MySQL, et c'étaient toutes des connexions en veille. À l'heure actuelle, il existe également de nombreux liens vers le serveur Web. En d'autres termes, l'exécution de PHP étant bloquée, le lien MySQL ne peut pas être libéré rapidement. Alors, pourquoi PHP se bloque-t-il ? L'analyse point d'arrêt par point d'arrêt a révélé que l'écho retardait le plus de temps.

Cet incident a donné une certaine expérience à Caoz. Je n'ai jamais pensé que l'écho soit un point de blocage temporel auparavant (si vous le testez sur cette machine, vous penserez que son délai est presque 0), mais le suivi des instances. J'ai découvert qu'Echo représente en fait le processus de transmission réseau dans notre environnement de travail. En d'autres termes, il attendra en raison de facteurs de routage et de bande passante. À l'heure actuelle, le lien mysql est toujours là et n'a pas été publié. Oui, tout le monde le voit. la question. Tout le monde pensera que mysql_close devrait être placé après echo, mais pourquoi echo retardera le temps, peu de gens y penseront. Bien sûr, cela est également lié à l'environnement de travail. Caoz sait seulement que le serveur Web que nous avons configuré aura cette situation. Existe-t-il un autre mode de configuration ? Caoz ne l'a pas testé, donc je n'ose pas dire de bêtises, mais l'expérience ici est la suivante. que mysql_close soit placé devant echo , un grand nombre de liens de veille diminuera rapidement.

echo ne consomme pas trop de ressources système, mais il attendra la transmission réseau. Dans un environnement réseau à haute concurrence, il est bon que la base de données y prête attention.

Après la résolution de ce problème, MySQL est devenu beaucoup plus sain, mais le problème du trop grand nombre de liens s'est parfois produit, ce qui m'a longtemps troublé jusqu'au jour, selon certains

messages d'erreur. signalé par les utilisateurs, il a été constaté que le serveur memcached présentait des facteurs d'instabilité. Il s'est avéré que le trafic memcached était trop élevé et bloqué, et le processus php attendait des liens, provoquant l'attente d'un grand nombre de liens mysql. origine de la première question. En fait, il n'y a pas de réponse standard à cette question elle-même, mais vous devez en être conscient, lorsque vous démarrez deux liens A et B en même temps dans un script, alors si vous ne pouvez pas garantir que ceux-ci. deux liens sont nécessairement fiables (ne peuvent généralement pas être garantis), puis une fois le dernier bloqué, le premier attendra un grand nombre de liens, tandis que le premier bloque, cela n'affecte généralement pas le second. Ainsi, la réponse dépend du lien qui est le plus important pour votre application et du lien qui prend en charge la plus grande concurrence.

Les deux questions signifient la même chose en dernière analyse. Lorsque vous rencontrez des problèmes et des pannes du système, réfléchissez davantage à l'impact de certains facteurs liés et à la logique de la séquence de réponse de l'ensemble de l'architecture. connexions. Cela doit être dû à la base de données. Il y a trop de liens Web. Il n'est pas nécessaire d'optimiser le serveur Web. Les facteurs associés peuvent être la cause première. Ce n'est qu'en résolvant la cause première que les symptômes seront complètement résolus.

2. Méthode efficace pour réduire le processus de veille de MySQL

1. De manière générale, la raison pour laquelle MySQL a un grand nombre de processus de veille est qu'il adopte la méthode de base de données de liens longs MySQL de PHP, c'est-à-dire qu'elle utilise mysql_pconnect pour ouvrir la base de données liée. pour utiliser des liens "courts", c'est-à-dire la fonction mysql_connect.
2. Lorsque vous utilisez la méthode de lien court mysql_connect pour ouvrir la base de données, chaque page exécutera SQL après l'ouverture de la base de données. Lorsque le script de la page se terminera, la connexion MySQL se fermera automatiquement et libérera de la mémoire. Cependant, il existe encore un grand nombre de processus de veille. Vous pouvez vérifier si le site Web présente les problèmes suivants.
A. Il y a un grand nombre de fichiers statiques sur le disque dur, ou le serveur WEB est trop chargé et la réponse aux requêtes HTTP devient trop lente. Cela peut également entraîner un grand nombre de processus de mise en veille. La solution consiste à ajuster de manière appropriée les paramètres et les fichiers du service WEB. Le contenu Web statique ou mis en cache n'est pas une panacée.
B. Dans les scripts web, certains calculs et applications peuvent prendre beaucoup de temps. Par exemple, après avoir ouvert la base de données à 0 seconde et exécuté un code SQL, le script web met alors 20 secondes à effectuer une opération complexe, ou encore. nécessite un énorme fichier PHP (comme une fonction de filtre contenant des milliers de mots-clés illégaux). À ce moment-là, dans le processus observé en arrière-plan MySQL, MySQL n'a rien fait pendant ce processus de 20 secondes et était toujours en état de veille jusqu'à ce que. la page termine son exécution ou atteint la valeur wait_timeout (est fermée de force), optimisez le script de la page Web et essayez de faire exécuter le programme le plus rapidement possible, ou exécutez mysql_close pour fermer de force le lien MySQL actuel pendant ce processus d'exécution fastidieux.
C. Dans la station de collecte, le phénomène d'un grand nombre de processus Sleep dans MySQL est particulièrement évident (par exemple, de nombreux internautes se sont interrogés sur le grand nombre de processus Sleep dans MySQL de DeDeCMS), car la plupart des pages collectrices sont ouvert à l'avance pendant le processus en cours. Créez un lien MySQL (peut-être pour vérifier les autorisations de l'utilisateur, etc.), puis commencez à utiliser des opérations telles que file_get_contents pour obtenir le contenu d'une page Web distante. la vitesse est trop lente, par exemple, il faut 10 secondes pour récupérer la page Web, donc le programme de script d'acquisition actuel est toujours bloqué ici, et MySQL ne fait rien et est toujours en état de veille. La solution est la même que ci-dessus. Lorsque vous exécutez file_get_contents pour collecter des pages Web distantes, utilisez mysql_close pour fermer de force la connexion MySQL, puis re-mysql_connect si nécessaire.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!