警告:长信号量等待

Kay*_*son 15 mysql sql innodb alter-table full-text-indexing

在过去的4天里,我的夜间更新出现了大量问题,除了1晚之外,这4天之间一切都很顺利.

在这些更新期间,我更新了几个全文索引.我是这样做的.

  1. 删除全文索引
  2. 更新全文表
  3. 添加全文索引

这已经超过2年完美.通常的更新时间约为3-4小时,这对于每晚更新的数据量是正常的.但自周五以来,更新时间确实在9-12小时之间!

昨晚服务器故意被引擎崩溃,这是在错误日志中

InnoDB:警告:一个长信号量等待: - 线程8676已经在dict0boot.ic第36行等待241.00秒信号量:Mutex在0000000053B0C1E8创建文件dict0dict.cc第887行,lock var 1 waiters flag 1 InnoDB:#### ##启动InnoDB Monitor 30秒打印诊断信息:InnoDB:待处理的preads 0,pwrites 0

InnoDB:######诊断信息打印到标准错误流InnoDB:错误:信号量等待持续> 600秒InnoDB:我们故意使服务器崩溃,因为它似乎挂起了.2014-07-21 05:20:54 1384 InnoDB:文件srv0srv.cc第1748行中的线程4996中的断言失败

InnoDB:我们故意生成一个内存陷阱.InnoDB:向http://bugs.mysql.com提交详细的错误报告.InnoDB:如果你重复断言失败或崩溃,即使是InnoDB:在mysqld启动之后,可能会有InnoDB:InnoDB表空间中的损坏.请参考InnoDB:http: //dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB:关于强制恢复.

我刚刚重新启动服务器,它很好,所以我现在等待在bugs.mysql.com发布完整的错误报告

我在这个页面上发现了一些东西,它似乎是同一类问题,但没有进一步的消息.

我不知道从哪里开始,我不知道为什么会突然发生这种情况.

我必须从这里提供什么样的细节?

  • Mysql服务器版本:5.6.13
  • sort_buffer_size = 2M
  • innodb_buffer_pool_size = 53G
  • innodb_log_buffer_size = 4M
  • innodb_flush_log_at_trx_commit = 0
  • innodb_log_file_size = 25G

编辑

看完这个,它指出

"MySQL 5.6及更高版本中的体系结构更改使得更多工作负载适合于禁用自适应哈希索引,而不是早期版本,尽管默认情况下仍然启用它."

我已经禁用了自适应哈希索引 SET GLOBAL innodb_adaptive_hash_index=0 ,我现在正在尝试第一次尝试查看问题是否已修复.情况就像晚上一样.


夜间更新:

更新很顺利.不到6个小时.全文索引更新没有问题,但我仍然发现简单的更新查询JOIN速度很慢.(以8秒为单位的40000条记录,通常在不到的时间内完成1).

将继续今天尝试和微调它.

Kay*_*son 16

问题在于 innodb_adaptive_hash_index

innodb_adaptive_hash_index=0 并重新启动解决了问题.

正如我在问题中所述

"MySQL 5.6及更高版本中的体系结构更改使得更多工作负载适合于禁用自适应哈希索引,而不是早期版本,尽管默认情况下仍然启用它."

这对我有用,因为我没有再次遇到同样的问题.

  • 你能评论为什么会出现问题吗? (3认同)