Attention: un long sémaphore attend

Pour les 4 derniers jours, j'ai eu d'énormes problèmes avec mon tous les soirs mises à joursauf pour 1 nuit, tout s'est bien passé entre ces 4 jours.

Au cours de ces mises à jour-je mettre à jour un couple de fulltext index. Je le fais de cette façon.

1. Baisse de l'index de texte intégral
2. Mise à jour le texte complet de la table
3. Ajouter l'index de texte intégral

Ce travail a été parfait pour les plus de 2 ans. D'habitude la mise à jour était d'environ 3 à 4 heures, ce qui était normal pour la quantité de données qui est mise à jour chaque nuit. Mais depuis vendredi, vraiment la mise à jour a été entre 9-12 heures!

La nuit dernière, le serveur s'est écrasé volontairement par le moteur, c'était dans le journal des erreurs

MyISAM: Avertissement: une longue sémaphore attendre:
--Thread 8676 a attendu au dict0boot.ic la ligne 36 pour 241.00 secondes, le sémaphore: Mutex à 0000000053B0C1E8 fichier créé dict0dict.cc
ligne 887, verrouillage var 1 serveurs pavillon 1 MyISAM: ###### Commence MyISAM
Moniteur de 30 secondes pour imprimer les informations de diagnostic: MyISAM: en Attente d'intérêt
0, pwrites 0

MyISAM: ###### informations de Diagnostic de l'imprimé sur le flux d'erreur standard
MyISAM: Erreur: sémaphore attente a duré > 600 secondes MyISAM: Nous
intentionnellement crash le serveur, car il semble être bloqué.
2014-07-21 05:20:54 1384 MyISAM: échec d'Assertion dans le thread 4996 dans
fichier srv0srv.cc ligne 1748

MyISAM: Nous avons volontairement générer un mémoire piège. MyISAM: Soumettre un
détaillée rapport de bug à http://bugs.mysql.com. MyISAM: Si vous obtenez
affirmation répétée de défaillances ou d'accidents, même MyISAM: immédiatement après
le démarrage de mysqld, il peut être MyISAM: la corruption dans le MyISAM
tablespace. Veuillez vous référer à MyISAM:
http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
MyISAM: au sujet de forcer la récupération.

Ive vient de redémarrer le serveur, et il s'est bien passé donc pour maintenant je suis en attente de poste complet d'un rapport de bogue bugs.mysql.com

J'ai découvert quelque chose sur ce page , et il semble être le même genre de problème, mais pas d'autres messages tho.

Je ne sais pas où aller à partir d'ici, je ne sais pas pourquoi tout d'un coup qui se passe.

Ce genre de détails dois-je fournir à partir d'ici?

• Mysql server version: 5.6.13
• sort_buffer_size = 2M
• innodb_buffer_pool_size = 53
• innodb_log_buffer_size = 4M
• innodb_flush_log_at_trx_commit = 0
• innodb_log_file_size = 25G

MODIFIER

Après la lecture de cetteil indique que

"Les modifications de l'architecture de MySQL 5.6 et plus faire plus de charges de travail
adapté pour la désactivation de l'adaptation des index de hachage que dans les
les rejets, même s'il est toujours activé par défaut."

J'ai désactivé l'adaptation des index de hachage à l'aide de
SET GLOBAL innodb_adaptive_hash_index=0
et j'essaye maintenant de la première tentative pour voir si le problème est résolu. La Situation est tout comme la nuit.

---

Mise à jour:

La mise à jour s'est bien passé. Moins de 6 heures. Il n'y a pas de problème avec la mise à jour des index fulltext, je reste cependant constaté que la simple requête de mise à jour avec JOIN a été lente. (40000 enregistrements dans 8 secondes, ce qui était habituellement fait en moins de 1).

Allons continuer à essayer et à affiner.

source d'informationauteur Kay Nelson