J'ai remarqué le même phénomène sur mes systèmes. Les requêtes qui prennent normalement une milliseconde prendront soudainement 1 à 2 secondes. Tous mes cas sont des instructions INSERT/UPDATE/REPLACE simples et à table unique --- pas sur des SELECT. Aucune charge, blocage ou accumulation de filetage n'est évident.
J'avais soupçonné que cela était dû au nettoyage des pages sales, au vidage des modifications sur le disque ou à un mutex caché, mais je n'ai pas encore réussi à le réduire.
Également exclu
- Charge du serveur :pas de corrélation avec une charge élevée
- Engine -- se produit avec InnoDB/MyISAM/Memory
- Cache de requêtes MySQL :se produit, qu'il soit activé ou non
- Rotations des journaux :pas de corrélation dans les événements
La seule autre observation que j'ai à ce stade découle du fait que j'exécute la même base de données sur plusieurs machines. J'ai une application de lecture intensive, j'utilise donc un environnement avec réplication - la majeure partie de la charge est sur les esclaves. J'ai remarqué que même s'il y a une charge minimale sur le maître, le phénomène se produit davantage là-bas. Même si je ne vois aucun problème de verrouillage, c'est peut-être Innodb/Mysql qui a des problèmes avec la concurrence (thread) ? Rappelez-vous que les mises à jour sur l'esclave seront monothread.
MySQL version 5.1.48
Mettre à jour
Je pense avoir une piste pour le problème sur mon cas. Sur certains de mes serveurs, j'ai remarqué ce phénomène sur plus que les autres. En voyant ce qui était différent entre les différents serveurs et en peaufinant les choses, j'ai été amené au Variable système MySQL innodb
innodb_flush_log_at_trx_commit .
J'ai trouvé la doc un peu difficile à lire, mais innodb_flush_log_at_trx_commit peut prendre les valeurs de 1,2,0 :
- Pour 1, le tampon du journal est vidé dans le fichier journal pour chaque validation, et le fichier journal est vidé sur le disque pour chaque validation.
- Pour 2, le tampon du journal est vidé dans le fichier journal pour chaque validation, et le fichier journal est vidé sur le disque environ toutes les 1 à 2 secondes.
- Pour 0, le tampon du journal est vidé dans le fichier journal toutes les secondes, et le fichier journal est vidé sur le disque toutes les secondes.
En effet, dans l'ordre (1,2,0), tel que rapporté et documenté, vous êtes censé obtenir des performances croissantes dans le commerce pour un risque accru.
Cela dit, j'ai trouvé que les serveurs avec innodb_flush_log_at_trx_commit=0 fonctionnaient moins bien (c'est-à-dire qu'ils avaient 10 à 100 fois plus de "mises à jour longues") que les serveurs avec innodb_flush_log_at_trx_commit=2 . De plus, les choses se sont immédiatement améliorées sur les mauvaises instances lorsque je l'ai changé en 2 (notez que vous pouvez le changer à la volée).
Donc, ma question est, à quoi est réglé le vôtre ? Notez que je ne blâme pas ce paramètre, mais souligne plutôt que son contexte est lié à ce problème.
