Pourquoi les threads MySQL affichent-ils souvent le statut «éléments de libération» lorsque le cache de requête est désactivé?


16

Lorsque je lance SHOW PROCESSLIST, il y a souvent un grand nombre de threads INSERT / UPDATE à l'état "éléments de libération".

Le manuel MySQL suggère qu'au moins une partie de la raison pour laquelle un thread se trouve dans cet état implique le cache de requêtes - il est probable qu'il invaliderait les requêtes mises en cache en raison des données modifiées.

Cependant, my query_cache_sizeest défini sur 0, ce qui devrait désactiver complètement le cache de requêtes.

Quelles autres raisons y aurait-il d'avoir autant de fils dans cet état?

Les tableaux appropriés utilisent le moteur de stockage InnoDB.

Réponses:


7

Vérifiez la valeur de innodb_thread_concurrency.

Pour mon système, l'augmentation de la valeur de 8 à 32, conformément aux instructions de la documentation MySql , a provoqué une diminution perceptible du nombre de threads signalant simultanément l'état des «éléments de libération». De plus, le temps de requête moyen observé a chuté d'un ordre de grandeur.

Bien que cela ait fait une grande différence dans les performances globales du serveur, ce n'était pas la solution miracle pour "libérer des éléments". Mon écosystème matériel me conduit à émettre l'hypothèse que cet état est principalement observé sur les systèmes avec des disques "lents" (2x10k disques raid 1), et est moins répandu sur les systèmes avec un stockage plus rapide (12x15k disques raid 10). Ainsi, une vérification des performances du disque peut également être garantie.

Bonne chance!

Aussi:

Il convient de noter que la valeur par défaut de innodb_thread_concurrency est radicalement différente selon la version de 5,0 points utilisée.

La valeur par défaut a changé plusieurs fois: 8 avant MySQL 5.0.8, 20 (infini) de 5.0.8 à 5.0.18, 0 (infini) de 5.0.19 à 5.0.20 et 8 (fini) de 5.0.21 sur. - source

Cela signifie qu'une mise à niveau apparemment inoffensive de 5.0.20 à 5.0.21 a changé la valeur par défaut de l'infini à 8, et a amené avec elle les ramifications de performances.


Avait un problème similaire comme celui-ci, et il était directement lié à la vitesse lente du disque dur. L'analyse de la vitesse du disque a montré que l'écriture et la lecture sur le disque dur étaient extrêmement lentes. Cela a eu un impact sur MySQL, et c'est pourquoi les états "Libération des éléments" (avec les mêmes requêtes) s'affichent depuis longtemps dans la liste des processus. Tuer les autres processus qui ralentissaient la vitesse du disque dur a résolu le problème.
Navigatron

5

La libération d'éléments est une étape d'exécution de requête où les structures temporaires, les tampons, etc. sont désalloués. Certains travaux de cache de requêtes sont effectués à cette étape, mais ce n'est pas la seule chose qui s'y produit. Je suggère d'utiliser SHOW PROFILES pour voir combien de temps cette étape prend par rapport aux autres étapes, et si le temps consommé finit par être un problème, dépanner avec des outils tels que le profileur du pauvre et oprofile.


Merci d'avoir mis à zéro ce qu'est la «libération d'articles». Existe-t-il des documents spécifiques le détaillant, ou s'agit-il simplement d'un exercice Google pour moi?
RolandoMySQLDBA

Ou parcourez l'exercice de code source! :)
Derek Downey

3

Il y avait un rapport de bogue sur ce problème concernant la «libération des éléments» et le cache de requêtes . Bien que le bogue soit fermé, il n'y avait aucune mention de innodb_thread_concurrency .

Par coïncidence, j'ai parlé avec Ronald Bradford au Percona Live NYC en mai. Je lui ai parlé d'une situation où j'ai tweek innodb_thread_concurrency parce que le multiple pool de tampons InnoDB de MySQL 5.5 a produit une tonne de verrouillage de threads et je soupçonnais que les données mises en cache dont j'avais besoin s'étaient probablement répandues parmi les multiples pools de tampons.

Il m'a clairement dit que je ne devrais jamais définir de valeurs par rapport à innodb_thread_concurrency. Soit toujours la valeur par défaut, qui est maintenant zéro (0). Ce faisant, vous laissez le stockage InnoDB décider du nombre inodb_concurrency_tickets à générer par lui-même. C'est ce que fait la concurrence infinie.

La «libération des éléments» se produit le plus souvent lorsque nous imposons des limites à innodb_thread_concurrency. Cela devrait toujours être zéro (0). Je prendrais un risque et augmenterais innodb_concurrency_tickets et verrais si cela aide ou non.


2

Nous avons eu un problème avec exactement les mêmes symptômes. Il s'est avéré que le disque contenant les fichiers journaux InnoDB était plein. Vaut la peine d'être vérifié.


Vous avez besoin de fichiers journaux beaucoup plus volumineux. En fait, le plus gros fichier journal autorisé avec la valeur par défaut innodb_log_files_in_group (qui est 2) est 2047M. Vous devez arrêter mysql, rm -f / var / lib / ib_logfile [01], faire innodb_log_file_size = 2047M dans /etc/my.cnf et démarrer mysql. Bien sûr, obtenez un disque plus gros !!!
RolandoMySQLDBA

1

Un autre indice: pourrait être innodb fsync (). Essayez de définir

innodb_flush_log_at_trx_commit = 2

Dans my.cnf

Le fichier journal innodb est ensuite vidé sur le disque toutes les 1-2 secondes, à la place ob à chaque validation. Légère pénalité pour l'intégrité des données, grand gain de vitesse.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.