testcase入门教程(如何快速分析CallStack)

testcase入门教程(如何快速分析CallStack)(1)

你是否会经常遇到MySQL hang了而不知所措?面对繁杂的callstack信息如何才能快速分析出原因?

本文将通过一个案例,介绍如何快速分析这类问题的方法。

当我们遇到MySQL hang的场景时,大概率是程序内部发生了mutex冲突造成的。这时我们需要在重启服务前,先搜集callstack信息。

pstack`pidof mysqld` > mysql_callstack 注意:mysqld需要包含符号表

注意:mysqld需要包含符号表

有了callstack信息,我们便可以开始进行分析了。

分析步骤


1. 首先,在callstack日志筛选出每个线程调用inline_mysql_mutex_lock前的函数,以及对应的mutex代码位置,此处便是线程在等待的mutex。

testcase入门教程(如何快速分析CallStack)(2)

2. 然后,从该函数向前遍历每个函数调用,寻找这些函数,看已经成功获得哪些mutex。

testcase入门教程(如何快速分析CallStack)(3)

这里我用脚本对日志进行格式化处理,将每个函数都映射到了github的代码位置,点击链接可以直接跳转,使用Chrome浏览器配合sourcegraph查看代码也很香。

3. 最后,从日志中回溯每个上锁函数所对应的前端操作行为,并绘制一张关于线程持有和等待mutex的表格,便能直观的分析出函数的冲突关系。

testcase入门教程(如何快速分析CallStack)(4)

总结


由于show binlog logs操作、purge binlog以及从读取 performance_schema读取会话变量几个操作并行发生产生mutex冲突,导致无法新建连接请求。

  • show binary logs,持有LOCK_log,等待LOCK_index
  • binlog purge,持有LOCK_index, 等待LOCK_thd_data
  • 读取performance_schema.session_variables,持有LOCK_thd_data, LOCK_global_system_variables, 等待LOCK_log
  • 新建连接,等待LOCK_global_system_variables

最终确认是binlog_transaction_dependency_*变量的读取需要获取LOCK_log锁,此处容易造成死锁,MySQL 5.7.25 修复了此问题。

关键字:爱可生、MySQL数据库、数据库运维管理、开源数据库解决方案

,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页