2009-07-11 9 views
0

J'ai un bogue étrange dans une application (ou est-ce la construction de MySQL?) Qui fait que les requêtes restent dans l'état "verrouillé" pour toujours, remplissant le nombre maximum de threads.Les requêtes de journalisation supprimées dans MySQL

J'ai lu à propos de la définition de la variable wait_timeout pour tuer les threads «faux» après un certain temps. Cela fonctionne bien, mais je voudrais enregistrer les requêtes tuées pour une inspection plus approfondie/s'assurer que les scripts de sauvegarde ne sont pas tués.

Est-il possible de faire cela?

Merci.

+0

Il semble que wait_timeout ne tue pas les requêtes après l'heure spécifiée ... J'ai créé un travail cron qui exécute "SHOW FULL PROCESSLIST" et recherche les requêtes qui s'exécutent pendant plus de n secondes. Ensuite, je tue ces requêtes avec KILL #id et je les envoie par e-mail. –

Répondre

0

Vous pourriez être en mesure d'utiliser le slow log, mais je ne suis pas sûr si le problème est qu'ils ne finissent jamais. Ça vaut le coup.

De même, vous pourrez peut-être voir ce qui se passe en exécutant SHOW FULL PROCESSLIST alors que vous avez des threads morts. Il devrait vous montrer quel est le problème et quelle était la requête.

Si vous pouvez simuler cela dans un environnement de développement, vous pouvez également activer la consignation générale des requêtes (qui enregistre chaque instruction), puis arrêter le journal après le blocage.

0

Dans le passé, j'ai requêtes marquées avec un commentaire uniques (par type de requête):

/* Query_12345 */ SELECT ... FROM ... WHERE ... LIMIT ... 

Un processus d'arrière-plan serait sondage SHOW FULL PROCESSLIST et rechercher toutes les requêtes qui ont été plus X secondes, et étiqueté avec Query_NNNNN. Enfin, il les tuerait s'ils allaient trop longtemps. Cela a permis au serveur de respirer pendant que nous avons trouvé comment optimiser la table de 80 000 000 d'enregistrements qui ralentissait les choses.

Questions connexes