BA应当对InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung. 一点都不生疏，MySQL背景线程srv_error_monitor_thread发明存在壅塞凌驾600s的latch锁时，假如一连10次检测该锁仍没有开释，就会触发panic防止效劳延续hang下去。
发生了什么
版本号：MySQL 5.5.40
日记中延续输出线程守候数据字典锁，位置是dict0dict.c line 305，守候时间凌驾了900s。
持有锁的线程是 139998697924352 ，其十六进制是7f53fca8a700。
--Thread 139998393616128 has waited at dict0dict.c line 305 for 934.00 seconds the semaphore:X-lock on RW-latch at 0x105a1b8 created in file dict0dict.c line 748a writer (thread id 139998697924352) has reserved it in mode exclusivenumber of readers 0, waiters flag 1, lock_word: 0Last time read locked in file dict0dict.c line 302Last time write locked in file /pb2/build/sb_0-13157587-1410170252.03/rpm/BUILD/mysql-5.5.40/mysql-5.5.40/storage/innobase/dict/dict0dict.c line 305
上锁线程 139998697924352 的事件信息，查询数据字典表的操纵。
---TRANSACTION 0, not started updating table statistics：MySQL thread id 14075, OS thread handle 0x7f53fca8a700, query id 110414021 21.14.5.139 jzjkusrSELECT ROUND(SUM(DATA_LENGTH+INDEX_LENGTH+DATA_FREE)/1024/1024/1024) AS MY_DB_TOTAL_SIZE FROM information_schema.TABLES
搜检下持锁线程 139998697924352 是不是存在其他锁守候。
发明线程 139998697924352 ，self-lock 在 btr0sea.c line 1134，该锁构造和 AHI 相干。
--Thread 139998697924352 has waited at btr0sea.c line 1134 for 934.00 seconds the semaphore:X-lock (wait_ex) on RW-latch at 0x1eb06448 created in file btr0sea.c line 178a writer (thread id 139998697924352) has reserved it in mode wait exclusivenumber of readers 1, waiters flag 1, lock_word: ffffffffffffffffLast time read locked in file btr0sea.c line 1057Last time write locked in file /pb2/build/sb_0-13157587-1410170252.03/rpm/BUILD/mysql-5.5.40/mysql-5.5.40/storage/innobase/btr/btr0sea.c line 1134
接下来看下两处锁构造离别在哪一个函数内：
dict0dict.c line 305在dict_table_stats_lock函数内
btr0sea.c line 1134在btr_search_drop_page_hash_index函数内
什么状况会挪用这些函数？
启用 innodb_table_monitor，输出日记时挪用 dict_table_stats_lock 上 X 锁，本案例未开启。
启用 innodb_stats_on_metadata 时，查询数据字典表会触发统计信息的更新操纵，会挪用 dict_table_stats_lock 上 X 锁。这与持锁线程的事件信息婚配。
Adaptive hash index(AHI) 是 InnoDB 用来加快索引页查找的 hash 表构造。当页面接见次数满足肯定前提后，这个页面的地点将存入一个 hash 表中，削减 B 树查询的开支。
MySQL 5.5 版本 AHI 是由全局锁 btr_search_latch 保护 hash 表修正的一致性。
InnoDB buffer pool 状况显现 free buffer 基础坚持0余暇。InnoDB buffer pool 驱赶数据页时，会挪用 btr_search_drop_page_hash_index 函数，从 AHI 中清理该数据页。
-----------------------------BUFFER POOL AND MEMORY-----------------------------Total memory allocated 17582522368; in additional pool allocated 0
Dictionary memory allocated 4289681
Buffer pool size 1048576
Free buffers 0
Database pages 1040831
Old database pages 384193
Modified db pages 0
小结
AHI 的全局锁 btr_search_latch 常常会是合作热门影响机能，5.7版本后有所改善与 InnoDB buffer 一样做了多实例拆分。本案例在开启 Innodb_stats_on_metadata 参数，查询元数据信息时触发统计信息更新，上锁数据字典，壅塞了了大批营业操纵，又因为 buffer pool 空间不足，致使表驱赶旧页触发 AHI 的 btr_search_latch 锁合作，终究致使信号量超时 crash。
>> 彩蛋 <<
在动辄几兆的日记中剖析 Semaphore crash，寻觅锁、线程、事件之间的关联，相称使人抓狂的。借助 sed、awk、grep 三大法宝，虽有效力提拔，但仍不够高效。
为了偷懒写了一个小顺序，协助DBA疾速梳理出这些关联。
它的用法是如许的：
hongbin@MBP ~> mysqldba doctor -f /Users/hongbin/workbench/mysqld_safe.log
目的版本，查代码时找对应版本：
MySQL Server Version: '5.7.16-log’
日记中涌现的 semaphore crash 次数和 mysql 启动次数，假如启动次数大于 crash 次数申明多是一般启动或其他 crash 形成：
********** MySQL service start count **********
MySQL Semaphore crash -> 3 times ["2018-08-13 23:12:18" "2018-08-14 12:13:43" "2018-08-16 13:42:36"]
MySQL Service start -> 3 times ["2018-08-13 23:12:59" "2018-08-14 12:15:20" "2018-08-16 13:46:37"]
线程主要在守候哪些 RW-latch，内容包含：锁位置、涌现次数、线程 id (涌现次数)，重点关注涌现次数较多的：
********** Which thread waited lock **********row0purge.cc:861 -> 58 140477266503424:(57) 140617703745280:(1)gi.cc:14791 -> 1 140477035656960:(1)trx0undo.ic:171 -> 1 140617682765568:(1)ha_innodb.cc:14791 -> 620 140617389913856:(58) 140202719565568:(58) 140202716903168:(57) 140477029533440:(56) 140617407219456:(55) 140477035656960:(52) 140477035124480:(29) 140477108467456:(29) 140477025539840:(26) 140477031130880:(25) 140477027669760:(22) 140617634944768:(21) 140617634146048:(21) 140477019948800:(21) 140477026604800:(20) 140477022078720:(18) 140477018883840:(16) 140477038585600:(15) 140477028734720:(10) 140477022877440:(9) 140477034325760:(1) 140477031663360:(1)srv0srv.cc:1968 -> 208 140477276993280:(185) 140617714235136:(23)ha_innodb.cc:5510 -> 601 140617398167296:(57) 140617409615616:(55) 140617392043776:(53) 140477110597376:(52) 140617395771136:(50) 140617636275968:(45) 140617632548608:(40) 140617634146048:(33) 140617639675648:(32) 140617397102336:(28) 140617639409408:(23) 140617635743488:(21) 140617637811968:(18) 140617638610688:(16) 140617399232256:(12) 140617638344448:(10) 140617638078208:(10) 140477033793280:(10) 140477029267200:(10) 140617397368576:(9) 140617635211008:(6) 140617393641216:(5) 140617637545728:(3) 140617402693376:(2) 140477037254400:(1)dict0dict.cc:1239 -> 136 140477122623232:(50) 140617392842496:(35) 140202726487808:(26) 140477123688192:(12) 140477038851840:(5) 140477030065920:(4) 140617634412288:(4)row0trunc.cc:1835 -> 1 140477109798656:(1)
上述锁被哪些写线程持有 X 锁，重点关注涌现次数较多的：
********** Which writer threads block at **********
140616681907968 -> 1 trx0undo.ic:171:(1)140477173069568 -> 243 srv0srv.cc:1968:(185) row0purge.cc:861:(57) row0trunc.cc:1835:(1)140617682765568 -> 29 srv0srv.cc:1968:(23) ha_innodb.cc:5510:(5) row0purge.cc:861:(1)
写线程对应的事件信息，也能够存在日记纪录没有输出事件信息：
********** These writer threads trx state **********MySQL thread id 83874, OS thread handle 140477173069568, query id 13139674 10.0.1.146 aml deleting from reference tables
统计写线程持有 S 锁状况：
****These writer threads at last time reads locked ****
140477173069568 -> 243 row0purge.cc:861:(243)140617682765568 -> 24 row0purge.cc:861:(24)140616681907968 -> 1 trx0undo.ic:190:(1)
统计写线程持有 X 锁状况：
****These writer threads at last time write locked ****
140477173069568 -> 243 dict0stats.cc:2366:(243)140617682765568 -> 24 dict0stats.cc:2366:(24)140616681907968 -> 1 buf0flu.cc:1198:(1)
经由过程预先日记剖析，有能够涌现线程的事件信息没有输出到日记中的状况，没法获知事件细致执行了什么操纵。应对这类状况，小顺序到场了事中收集事件信息。
用法是如许的：
hongbin@MBP ~> mysqldba -uxxx -pxxx doctor -w
它会看管目的 mysql 的毛病日记，一旦涌现“a writer (thread id 140616681907968) has reserved it in mode” 关键字就查询 ps 中的事件信息，并保留下来。
以上只是小顺序一个用法，作为一个为DBA效劳的小顺序，另有其他功用等你去发明。迎接与我交换你的主意。
更多SQL的相干技术文章，请接见SQL教程栏目举行进修！
以上就是记一次MySQL semaphore crash的剖析的细致内容，更多请关注ki4网别的相干文章！
