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.
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.
la source
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.
la source
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é.
la source
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.
la source