企业网站管理系统登录,wordpress 搜索,三点水网站建设,中国建设银行北京分行网站【问题描述】我们生产环境有一组集群的多台MySQL服务器(MySQL 5.6.21)#xff0c;不定期的会crash#xff0c;但error log中只记录了重启信息#xff0c;未记录crash时的堆栈#xff1a;mysqld_safe Number of processes running now: 0mysqld_safe mysqld restarted接下来…【问题描述】我们生产环境有一组集群的多台MySQL服务器(MySQL 5.6.21)不定期的会crash但error log中只记录了重启信息未记录crash时的堆栈mysqld_safe Number of processes running now: 0mysqld_safe mysqld restarted接下来首先排查系统日志/var/log/message文件crash时没有其他异常信息也不是OOM导致的。【排查思路】由于日志中未记录有价值的信息。为定位crash的原因首先开启mysql core dump的功能。下面是开启core dump的步骤1、 在my.cnf文件中增加2个配置项[mysqld]core_file[mysqld_safe]core-file-sizeunlimited2、修改系统参数配置suid_dumpableecho 1 /proc/sys/fs/suid_dumpable3、重启mysql服务配置生效【问题分析】开启core dump后服务器再次crash时生成了core file。用gdb分析生成的core file可以看到crash时的堆栈信息如下从函数table_esms_by_digest::delete_all_rows可以看出触发crash的是truncate table events_statements_summary_by_digest操作。我们内部有个DML的分析工具用来统计数据库每分钟增删改查的访问量。该工具的数据源是events_statements_summary_by_digest表采集程序会每一分钟采集一次这张表的数据采集完成后执行truncate操作。暂停这组集群上DML采集程序后MySQL没有再发生crash。进一步分析多个core file发现最终函数的调用都发生在_lf_pinbox_real_free函数上。结合现场环境有两处地方值得分析1、 内存的不正常值。当打印该变量时此处变量的地址偏低不太正常(gdb) p pins-pinbox$2 (LF_PINBOX *) 0x13672082、红字部分为pfs逐条释放digest记录的操作正在释放某行数据时出现错误void reset_esms_by_digest(){uint index;if (statements_digest_stat_array NULL)return;PFS_thread *thread PFS_thread::get_current_thread();if (unlikely(thread NULL))return;for (index 0; index digest_max; index){statements_digest_stat_array[index].reset_index(thread);statements_digest_stat_array[index].reset_data();}digest_index 1;}猜测有两种可能导致错误1、高并发下对内存访问出现冲突2、某个特殊SQL导致在处理hash时。在网上搜索类似的问题有了进一步的进展基本确定了这个问题是bug导致如下Mysql的bug report中讲述了类似问题https://bugs.mysql.com/bug.php?id73979更详细的环境描述如下连接中https://bugs.launchpad.net/percona-server/bug/1351148查到5.6.35上的bug fix的修复内容和我们碰到的情况非常类似。对比_lf_pinbox_real_free的修改该部分确实进行很大的调整。下面是MySQL 5.6.35函数_lf_pinbox_real_free的代码片段static void _lf_pinbox_real_free(LF_PINS pins){LF_PINBOX pinbox pins-pinbox;struct st_match_and_save_arg arg {pins, pinbox, pins-purgatory};pins-purgatory NULL;pins-purgatory_count 0;lf_dynarray_iterate(pinbox-pinarray,(lf_dynarray_func)match_and_save, arg);if (arg.old_purgatory){void *last arg.old_purgatory;while (pnext_node(pinbox, last))last pnext_node(pinbox, last);pinbox-free_func(arg.old_purgatory, last, pinbox-free_func_arg);}}下面是MySQL 5.6.21函数的_lf_pinbox_real_free的代码片段static void _lf_pinbox_real_free(LF_PINS pins){int npins;void list;void **addr NULL;void first NULL, last NULL;LF_PINBOX pinbox pins-pinbox;npins pinbox-pins_in_array1;if (pins-stack_ends_here ! NULL){int alloca_size sizeof(void )LF_PINBOX_PINSnpins;if (available_stack_size(pinbox, *pins-stack_ends_here) alloca_size){struct st_harvester hv;addr (void **) alloca(alloca_size);hv.granary addr;hv.npins npins;_lf_dynarray_iterate(pinbox-pinarray,(lf_dynarray_func)harvest_pins, hv);npins hv.granary-addr;if (npins)qsort(addr, npins, sizeof(void *), (qsort_cmp)ptr_cmp);}}同时观察到出问题的集群有指标异常QPS不到6000Threads_connected将近8000。(对比其他高并发的集群QPS在20000以上Threads_connected也只有300左右)。排查应用端的连接方式了解到其中一个应用有近百台应用服务器可能同时发起请求却没有合理的复用连接维持大量的连接线程增大了bug触发的概率。Bugs Fixed的描述如下Miscalculation of memory requirements for qsort operations could result in stack overflow errors in situations with a large number of concurrent server connections. (Bug #73979, Bug #19678930, Bug #23224078)【解决思路】我们通过分析crash时的core file文件找到crash时的触发条件暂停DML采集程序(truncate table events_statements_summary_by_digest操作)后恢复。后面了解到这是MySQL的一个bug在MySQL 5.6.35版本后已修复。这个bug在应用端与数据库建立大量的连接时更容易触发。总结以上就是这篇文章的全部内容了希望本文的内容对大家的学习或者工作具有一定的参考学习价值如果有疑问大家可以留言交流谢谢大家对服务器之家的支持。
