背景:
MySQL-5.7.12, debian 8核16G虚拟机, 业务方反馈在某一个时间点, 出现了大量的数据库报错, 之后恢复正常;

场景:
开发查看日志后, 发现在某个时间点, 应用断开了所有与数据库的连接, 几秒钟以后就恢复了;同时监控系统的内存使用率出现了异常的骤降;

3min之后收到了报警系统的信息, 内存使用率82%;

分析:
第一时间的判断是网络的问题造成了应用层的连接断开了, 但是这种内存使用率骤降的现象不会是网络造成的;查看MySQL的日志, 发现MySQL实例发生了crash, 相关的报错信息如下:

07:42:44 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=8388608
read_buffer_size=16777216
max_used_connections=29
max_threads=5000
thread_count=32
connection_count=22
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 245834871 K bytes of memory
Hope that is ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f607c0072c0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f6141b36e80 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0xe77fec]
/usr/sbin/mysqld(handle_fatal_signal+0x459)[0x7a7019]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7f643257a8d0]
/usr/sbin/mysqld(_ZN16Partition_helper25handle_ordered_index_scanEPh+0x5c)[0xbbabec]
/usr/sbin/mysqld(_ZN7handler13ha_index_lastEPh+0x1b0)[0x7f4410]
/usr/sbin/mysqld(_Z14join_read_lastP7QEP_TAB+0x65)[0xc1f605]
/usr/sbin/mysqld(_Z10sub_selectP4JOINP7QEP_TABb+0x11b)[0xc25e4b]
/usr/sbin/mysqld(_ZN4JOIN4execEv+0x3b8)[0xc1ea78]
/usr/sbin/mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x238)[0xc8e408]
/usr/sbin/mysqld[0x770ccf]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x3403)[0xc51103]
/usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3ad)[0xc531bd]
/usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x817)[0xc53a47]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x18f)[0xc54faf]
/usr/sbin/mysqld(handle_connection+0x278)[0xd108d8]
/usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0xe90784]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7f64325730a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6430e1b87d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query
(7f607c015ad0): select * from test where time>='2016-07-29 00:00:00'
and time<='2016-07-29 23:59:59' and tag in (2,3,6) order by id desc
limit 2000
Connection ID (thread ID): 138760
Status: NOT_KILLED

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
2016-07-29T07:42:45.661724Z mysqld_safe Number of processes running now: 0
2016-07-29T07:42:45.664516Z mysqld_safe mysqld restarted
2016-07-29T15:42:45.991109+08:00 0 [Note] /usr/sbin/mysqld (mysqld 5.7.12-log) starting as process 8367 ...

首先是第一部分的信息:

mysqld got signal 11 ;
通过perror命令(感谢@杨奇龙的场外援助..._(:з」∠)_...)看到ErrorCode的信息:

Resource temporarily unavailable
代表MySQL发现某一项资源临时不可用, 应该是资源耗尽 or 申请失败等情况;

然后是第二部分信息:

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 245834871 K bytes of memory
这一段计算了当前配置下, 需要的最大内存数, 大概换算了一下, 是234G;

这么高, 明显是有问题的, 联想到82%内存使用率的报警信息, 推测是内存耗尽造成的;

用max_used_connections来算一下使用的内存的话,有约1.5G;

加上BP的9.6G, 有11G了, 算上MySQL本身占用的一部分内存, 确实达到了比较高的程度;

但是看了一下kernel和message, 都没有发现系统出现OOM的日志, 应该不是系统kill的;

再看看堆栈相关的信息, 在里面记录了MySQL crash时的状态;

stack_bottom = 7f6141b36e80 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0xe77fec]
/usr/sbin/mysqld(handle_fatal_signal+0x459)[0x7a7019]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7f643257a8d0]
/usr/sbin/mysqld(_ZN16Partition_helper25handle_ordered_index_scanEPh+0x5c)[0xbbabec]
/usr/sbin/mysqld(_ZN7handler13ha_index_lastEPh+0x1b0)[0x7f4410]
/usr/sbin/mysqld(_Z14join_read_lastP7QEP_TAB+0x65)[0xc1f605]
/usr/sbin/mysqld(_Z10sub_selectP4JOINP7QEP_TABb+0x11b)[0xc25e4b]
/usr/sbin/mysqld(_ZN4JOIN4execEv+0x3b8)[0xc1ea78]
/usr/sbin/mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x238)[0xc8e408]
/usr/sbin/mysqld[0x770ccf]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x3403)[0xc51103]
/usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3ad)[0xc531bd]
/usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x817)[0xc53a47]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x18f)[0xc54faf]
/usr/sbin/mysqld(handle_connection+0x278)[0xd108d8]
/usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0xe90784]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7f64325730a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6430e1b87d]
从红字等地方的信息, 可以推断出当时MySQL是正在执行查询, 这些查询中有join, 也有subquery, 且查询的表包含了分区表;

可以预料到在crash的时候, MySQL执行这些语句时肯定需要申请一部分join用的buffer, 同时子查询也会建立临时表, 都需要占用内存空间;

同时还有分区表的使用, 看了一下当时候分区表的大小:

发现当天的数据超过了BP的大小, 且用到分区表的查询走的全表扫描, 并且还有order by, 会用到sort的buffer, 且由于全表扫描的数据很多, 这个buffer有可能是需要申请满的;

综合这些信息, 基本确认是内存耗尽造成了MySQL crash;

那么根据堆栈的信息尝试还原crash时的场景:

在内存占用率很高的情况下, MySQL thread在执行较大表的查询时, 无法再申请到足够的内存(sort的buffer, join的buffer等), 因此发生了crash;

处理方式:
最终把BP从9.6G调整为9G, 并把sort, read等buffer的数值调整到了4M, 其他的buffer也调低了;

PS: 算是疏忽吧, 因为说在生产环境已经用这么一套配置很久了, 没出过问题, 所以也没有仔细的排查配置文件中的设置;
PSS: sort的buffer原来是多少? 32M...sort的buffer还是per thread的...失职了..._(:з」∠)_

-------------------------------------------------------------------------------------------------后续---------------------------------------------------------------------------------------------------------------

峰回路转.....在调整了buffer的数量以后, 不可能再出现内存不够的现象了, 然后crash的现象重现了;

而且是主库和备库在非常短的时间内都发生了crash;

报错信息除了pointer不同以外, 堆栈的信息也是完全一致;

包括那个语句;
在之前出问题的时候, 记录了一条语句:

select * from test where time>='2016-07-29 00:00:00' and
time<='2016-07-29 23:59:59' and tag in (2,3,6) order by id desc limit
2000
在后来重现的时候, 两次crash的语句中, 记录的是同样的语句, (而且堆栈的输出信息也是完全一样) , 仅仅只是时间不一样:

select * from test where time>='2016-08-09 00:00:00' and
time<='2016-08-09 23:59:59' and tag in (2,3,6) order by id desc limit
2000
如果是因为内存or系统资源的不可用导致了crash的话, 不可能有这么巧合的事情, 都是这个语句;

so, 在被拉起来的备库上跑了一下这个语句, 结果MySQL马上就crash了...

那么明显就是这个语句的问题了, order by desc + limit, 看上去并没什么问题, 看看explain的结果

虽然好久没做开发了, 但是filtered在100%的情况下, rows只有1还是挺奇怪的, 一整张表只有一行数据, 但是还有这种查询一整天的语句;

看看表的结构;
隐去生产库上的一部分信息, 留下关键的部分;

分区表的分区有问题....

问过业务以后, 原来是这个功能还没做完, 所以表相关的操作并没有一直执行;
但是这个功能的页面没有屏蔽, 所以对应的那条语句是有可能被触发的;

考虑到用那条语句可以必现这个crash, 且输出的堆栈信息和之前完全一致,
所以确定是这个分区表的分区缺失的前提下, 触发那个查询语句的时导致了MySQL的Crash;

处理方式:
虽然最后还是找到了问题所在, 但是最开始的时候还是被buffer和内存使用率的现象误导了, too young......
PS:本来还是觉得分区表在5.7改进了一点以后, 应该还挺好用的.....恩, 现在持保留意见....._(:з」∠)_
PPS:应该不会再有后续了, 嗯嗯....

原文 https://www.linuxidc.com/Linux/2016-12/137853.htm

MySQL案例-mysqld got signal 11的更多相关文章

  1. mysqld got signal 11

    问题发生背景 问题实例之前使用的是percona server,是安装pmm镜像自带的数据库,之后通过mysqldump迁移到了MySQL server,目前是只有有pmm server 访问pmm库 ...

  2. mysql 案例 ~ 常见案例汇总

    一 简介:这里汇总了一些mysql常见的问题二 案例场景   问题1 mysql设置了默认慢日志记录1S,为何会记录不超过1S的sql语句   答案 mysql~log_queries_not_usi ...

  3. ANDROID开发 Fatal signal 11(SIGSEGV) at 0x问题解决方案

    最近做ANDROID开发,也遇到了很多程序员遇到的一个问题:FATAL SIGNAL 11(SIGSEGV) at 0xxxxx,自然是各种搜索是否有人已然解决,虽然搜索出来的已有案例不少,基本都是内 ...

  4. mysqld_safe启动报错 mysqld_safe The file /usr/local/mysql/bin/mysqld does not exist or is not executable

    报错(如下),但是使用mysqld直接启动没有问题. 150718 00:03:38 mysqld_safe Logging to '/var/log/mysqld.log'. 150718 00:0 ...

  5. MySQL指定mysqld启动时所加载的配置文件

    mysqld.exe --init-file=file_name 以下为配置文件参数优化和中文详解: [client]port = 3306socket = /tmp/mysql.sock [mysq ...

  6. Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1) 错误 解决方案(android-ndk)

    在android里做ndk编程的时候,碰到个随机性错误 错误信息如下: 05-06 15:59:44.411: A/libc(3347): Fatal signal 11 (SIGSEGV) at 0 ...

  7. 关于cocos2dx 3.0升级崩溃报错(unable to load native library) 和(Fatal signal 11 (SIGSEGV) at 0x00000000)

    近期一直在Windows平台开发cocos-2dx游戏,期间做了一次引擎升级,升级到了3.0正式版本号.Windows平台上表现非常正常,没有出现什么问题. 上周五准备公布一个安卓包,编译非常轻松的就 ...

  8. [cocos2d-x][apk打包][Fatal signal 11][andriod]Eclipse编译Fatal signal 11报错-都是字符赋值惹的祸

    流程重现: 使用coco2d-x制作了一个2048,在xcode模拟器执行以及在pad上真机调试都是没有问题的. 可是在使用eclipse调试打包android可以执行,可是进入游戏之后会在随机的地方 ...

  9. exited abnormally with signal 11: Segmentation fault 的相关处理

    前一阵子遇到一个问题,程序打包后,在某个界面总是崩溃,device log只打印了exited abnormally with signal 11: Segmentation fault 网上找了下相 ...

随机推荐

  1. CentOS 6.9上inotify-tools 安装及使用方法

    文章目录 [隐藏] 一.检查系统内核版本 三.下载安装(下载有点慢) 四.查看inotify默认参数 五.修改inotify参数 六.创建实时监控脚本 (file 里面放的需要监听的目录) 七:实例操 ...

  2. 微信小程序开发语言的选择

    微信使用的开发语言和文件很「特殊」. 小程序所使用的程序文件类型大致分为以下几种: ①WXML(WeiXin Mark Language,微信标记语言) ②WXSS(WeiXin Style Shee ...

  3. HttpServletRequest.getInputStream() 只能读取一次

    问题:在使用HTTP协议实现应用间接口通信时,服务端读取客户端请求过来的数据,会用到request.getInputStream(),第一次读取的时候可以读取到数据,但是接下来的读取操作都读取不到数据 ...

  4. Ansible工作流程详解

    1:Ansible的使用者 ------>Ansible的使用者来源于多种维度,(1):CMDB(Configuration Management Database,配置管理数据库),CMDB存 ...

  5. JS和Java正则表达式验证

    js代码 <script type="text/javascript"> function SubmitCk() { var reg = /^([a-zA-Z0-9]+ ...

  6. 百度前端技术学院task34源码——会指令的小块2

    任务描述 增加新的指令如下: TRA LEF:向屏幕的左侧移动一格,方向不变 TRA TOP:向屏幕的上面移动一格,方向不变 TRA RIG:向屏幕的右侧移动一格,方向不变 TRA BOT:向屏幕的下 ...

  7. [总结]多项式类数学相关(定理&证明&板子)

    目录 写在前面 前置技能 多项式相关 多项式的系数表示 多项式的点值表示 复数相关 复数的意义 复数的基本运算 单位根 代码相关 多项式乘法 快速傅里叶变换 DFT IDFT 算法实现 递归实现 迭代 ...

  8. Netty 核心组件 EventLoop 源码解析

    前言 在前文 Netty 启动过程源码分析 (本文超长慎读)(基于4.1.23) 中,我们分析了整个服务器端的启动过程.在那篇文章中,我们重点关注了启动过程,而在启动过程中对核心组件并没有进行详细介绍 ...

  9. Hibernate Tools for Eclipse的使用

    Hibernate Tools的官方网站:http://hibernate.org/tools/Step1.安装好Hibernate Tools,建立一个Dynamic web project,工程名 ...

  10. LDA算法学习(Matlab实现)

    LDA算法 对于两类问题的LDA(Matlab实现) function [ W] = FisherLDA(w1,w2) %W最大特征值对应的特征向量 %w1 第一类样本 %w2 第二类样本 %第一步: ...