Pourquoi les threads MySQL affichent-ils souvent le statut "éléments de libération" lorsque le cache de requête est désactivé?
Quand je lance SHOW PROCESSLIST, il existe 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, mon query_cache_size est 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.
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 le remède miracle "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 en fonction de la version 5.0 point 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 des performances.
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.
Il y avait un rapport de bogue sur ce problème concernant la "libération des éléments" et le cache de requête . 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 de innodb_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.
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é.
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.