客服电话
APP下载
迪恩网络APP
随时随地掌握行业动态
官方微信
扫描二维码
关注迪恩网络微信公众号
|
【问题描述】 我们生产环境有一组集群的多台MySQL服务器(MySQL 5.6.21)，不定期的会crash，但error log中只记录了重启信息，未记录crash时的堆栈： mysqld_safe Number of processes running now: 0 mysqld_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-size=unlimited 2、修改系统参数，配置suid_dumpable echo 1 >/proc/sys/fs/suid_dumpable 3、重启mysql服务，配置生效 【问题分析】 开启core dump后，服务器再次crash时生成了core file。 用gdb分析生成的core file，可以看到crash时的堆栈信息如下：
从函数 我们内部有个DML的分析工具，用来统计数据库每分钟增删改查的访问量。该工具的数据源是events_statements_summary_by_digest表，采集程序会每一分钟采集一次这张表的数据，采集完成后执行truncate操作。 暂停这组集群上DML采集程序后MySQL没有再发生crash。 进一步分析多个core file，发现最终函数的调用都发生在_lf_pinbox_real_free函数上。 结合现场环境，有两处地方值得分析： 1、 内存的不正常值。当打印该变量时，此处变量的地址偏低，不太正常： (gdb) p pins->pinbox $2 = (LF_PINBOX *) 0x1367208 2、红字部分为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?id=73979 更详细的环境描述如下连接中 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_array+1;
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不到6000，Threads_connected将近8000。（对比其他高并发的集群，QPS在20000以上，Threads_connected也只有300左右）。 排查应用端的连接方式，了解到其中一个应用有近百台应用服务器，可能同时发起请求，却没有合理的复用连接，维持大量的连接线程增大了bug触发的概率。 Bugs Fixed的描述如下：
【解决思路】 我们通过分析crash时的core file文件，找到crash时的触发条件，暂停DML采集程序（truncate table events_statements_summary_by_digest操作）后恢复。 后面了解到这是MySQL的一个bug，在MySQL 5.6.35版本后已修复。这个bug在应用端与数据库建立大量的连接时，更容易触发。 总结 以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对极客世界的支持。 |
请发表评论