MySQL案例-mysqld got signal 11

-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------

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

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


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

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

点击(此处)折叠或打开

  1. 07:42:44 UTC - mysqld got signal 11 ;
  2. This could be because you hit a bug. It is also possible that this binary
  3. or one of the libraries it was linked against is corrupt, improperly built,
  4. or misconfigured. This error can also be caused by malfunctioning hardware.
  5. Attempting to collect some information that could help diagnose the problem.
  6. As this is a crash and something is definitely wrong, the information
  7. collection process might fail.
  8. key_buffer_size=8388608
  9. read_buffer_size=16777216
  10. max_used_connections=29
  11. max_threads=5000
  12. thread_count=32
  13. connection_count=22
  14. It is possible that mysqld could use up to
  15. key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 245834871 K bytes of memory
  16. Hope that is ok; if not, decrease some variables in the equation.
  17. Thread pointer: 0x7f607c0072c0
  18. Attempting backtrace. You can use the following information to find out
  19. where mysqld died. If you see no messages after this, something went
  20. terribly wrong...
  21. stack_bottom = 7f6141b36e80 thread_stack 0x40000
  22. /usr/sbin/mysqld(my_print_stacktrace+0x2c)[0xe77fec]
  23. /usr/sbin/mysqld(handle_fatal_signal+0x459)[0x7a7019]
  24. /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7f643257a8d0]
  25. /usr/sbin/mysqld(_ZN16Partition_helper25handle_ordered_index_scanEPh+0x5c)[0xbbabec]
  26. /usr/sbin/mysqld(_ZN7handler13ha_index_lastEPh+0x1b0)[0x7f4410]
  27. /usr/sbin/mysqld(_Z14join_read_lastP7QEP_TAB+0x65)[0xc1f605]
  28. /usr/sbin/mysqld(_Z10sub_selectP4JOINP7QEP_TABb+0x11b)[0xc25e4b]
  29. /usr/sbin/mysqld(_ZN4JOIN4execEv+0x3b8)[0xc1ea78]
  30. /usr/sbin/mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x238)[0xc8e408]
  31. /usr/sbin/mysqld[0x770ccf]
  32. /usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x3403)[0xc51103]
  33. /usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3ad)[0xc531bd]
  34. /usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x817)[0xc53a47]
  35. /usr/sbin/mysqld(_Z10do_commandP3THD+0x18f)[0xc54faf]
  36. /usr/sbin/mysqld(handle_connection+0x278)[0xd108d8]
  37. /usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0xe90784]
  38. /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7f64325730a4]
  39. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6430e1b87d]
  40. Trying to get some variables.
  41. Some pointers may be invalid and cause the dump to abort.
  42. 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
  43. Connection ID (thread ID): 138760
  44. Status: NOT_KILLED
  45. The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
  46. information that should help you find out what is causing the crash.
  47. 2016-07-29T07:42:45.661724Z mysqld_safe Number of processes running now: 0
  48. 2016-07-29T07:42:45.664516Z mysqld_safe mysqld restarted
  49. 2016-07-29T15:42:45.991109+08:00 0 [Note] /usr/sbin/mysqld (mysqld 5.7.12-log) starting as process 8367 ...

首先是第一部分的信息:

点击(此处)折叠或打开

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

点击(此处)折叠或打开

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

然后是第二部分信息:

点击(此处)折叠或打开

  1. It is possible that mysqld could use up to
  2. 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时的状态;

点击(此处)折叠或打开

  1. stack_bottom = 7f6141b36e80 thread_stack 0x40000
  2. /usr/sbin/mysqld(my_print_stacktrace+0x2c)[0xe77fec]
  3. /usr/sbin/mysqld(handle_fatal_signal+0x459)[0x7a7019]
  4. /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7f643257a8d0]
  5. /usr/sbin/mysqld(_ZN16Partition_helper25handle_ordered_index_scanEPh+0x5c)[0xbbabec]
  6. /usr/sbin/mysqld(_ZN7handler13ha_index_lastEPh+0x1b0)[0x7f4410]
  7. /usr/sbin/mysqld(_Z14join_read_lastP7QEP_TAB+0x65)[0xc1f605]
  8. /usr/sbin/mysqld(_Z10sub_selectP4JOINP7QEP_TABb+0x11b)[0xc25e4b]
  9. /usr/sbin/mysqld(_ZN4JOIN4execEv+0x3b8)[0xc1ea78]
  10. /usr/sbin/mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x238)[0xc8e408]
  11. /usr/sbin/mysqld[0x770ccf]
  12. /usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x3403)[0xc51103]
  13. /usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3ad)[0xc531bd]
  14. /usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x817)[0xc53a47]
  15. /usr/sbin/mysqld(_Z10do_commandP3THD+0x18f)[0xc54faf]
  16. /usr/sbin/mysqld(handle_connection+0x278)[0xd108d8]
  17. /usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0xe90784]
  18. /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7f64325730a4]
  19. /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的...失职了..._(:з」∠)_

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
今天的技术问答是刘晨兄的一个问题,提问来自于我新书中的一个实验,刘晨兄非常认真,对我书中的很多细节都进行了测试。 看到这个错误,如果出现end-of-file这类的错误信息,基本可以断定数据库实例是宕了。 找到刘晨兄提到的页码标示,原来和我书中的测试结果有一些差别。 我书中的结果类似这样的形式: 错误代码也完全不同,这个问题该怎么解释呢,这个应该是一个很细节的问题。 首先网络上关于这个错误有很多种说法,很多我不认同。 我们先来复现一下问题,找了一套11.2.0.3的环境测试了一下。 先初始化数据 然后复现问
【故障处理】分布式事务 ORA-01591 错误解决 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ①  分布式事务的简单概念         ②  ORA-01591 错误解决   Tips: ① 本文在 ITpub ( http://blog.itpub.net/26736162 )、博客园 ( http://www.cnblogs.com/lh
我们有几个项目使用了Windows Server 2008+ ROSE HA+Oracle 的组合方案,但是最近遇到了一个不大不小的麻烦。 甲方在进行故障测试时,断掉了一个网络交换机 的电源 (共有两个网络交换机,对应两个冗余的业务网络),Oracle服务竟然停止了,导致所有的客户端数据库连接中断。 首先,这个测试结果甲方是无法接受的; 其次,这个结果也出乎我们的意料,在另外一个交换机正常工作的情况下,ROSE HA 停止了 Oracle服务。 那么,如何给甲方一个交代呢?在和 ROSE售后经过多次沟通后,
故障现象: 用服务器上面的(客户端)sql server management  stutio 去连接本服务器上的sql server 数据库,如下图:点击连接不报任何错,就是连接不上,一直处于等待状态; 但是通过windows 身份验证是可以连接的,并且是可以正常操作的,如下图:服务器名字不在是个IP,要选择local. 通过这个现象可判断出 数据库本身的服务(通过任务管理器中也可以看出来)是没有问题,只是连接方面出现问题:网络,端口或者是监听之类的问题。 这是网上查到的一篇文档:经验证我的这里是 没有
《 Oracle DBA 工作笔记》第二章 常用工具和问题分析   一.1    BLOG 文档结构图     一.2    本文简介 建荣的新书《 Oracle DBA 工作笔记》第二章的目录如下图,主要讲解了 SQL*Plus 、 exp/imp 、 expdp/impdp 以及常见的问题分析,第二章的目录如下:     下边小麦苗将自己阅读完第二章后整理的一些内容分享给大家。 一.3    第一章内容修改 一.3.1    删除数据库的几种方式 这个内容是第一章( http://blog.itpub
工作中可能需要某一天各个时间段的ash报告或awr报告,手动一个一个生成太费力了.利用 dbms_workload_repository 包再配合sqlplus的spool 可以使这件事情简单一些. 以下示例: 一.批量生成一天的ash报告 1.生成查询语句 #此处是按照15分钟的间隔时间,生成前一天所有的ash报告  的查询语句 select 'spool ash_'||db_unique_name||'_'||inst_id||'_'||to_char(trunc(sysdate-1)+level/9
分区索引分为本地索引和全局索引,但对于在分区表上建索引,一般用的比较多的还是普通索引和本地分区索引,而全局分区索引相对用的比较少. 以下测试为验证:分区表上 的本地分区索引 因为查询条件引起跨分区,是否改为普通索引更合适. 以下测试: oracle version:11.2.0.4 建测试表: drop table SCOTT.TB_TEST01; create table SCOTT.TB_TEST01 partition by range (CREATED) (   partition P_2015
关于半自动化搭建Data Guard,自己花了一些时间,总算是把这件事情继续推进了一下,还是再啰嗦一句,为什么不自动化,因为安全。主库就是主库,任何变更都要手工检查审核,自动化的工作在备库和中控端来完成。我希望自己的脚本能够只知道主库的IP,不用一次又一次连过去配置和检查,当然要完成自动化还是半自动化,有些网友也提醒的极是,那就是规范和标准。 预先条件: 1.目前的设计是基于11.2.0.4的版本,当然这个很容易定制,在此是作为一个基本的标准,作为环境的初始化和Data Guard对的搭建的基线。 2.默认
   前段时间有个开发的同事向我咨询一个问题,     开发同事:Oracle会存在一个用户插入数据,已经提交了;但是另外一个用户还查询不到吗?都是同一张表     jeanron:   不会的。     开发同事: 我们现在一个用户写入,程序日志是说已经写入;可是读取的用户还读取不到,在线延迟5分钟可能的问题在哪儿?或者你帮忙监控一下?     jeanron:   是Oracle吗,MySQL还可能有这种情况     开发同事: Oracle,MySQL是什么情况下会这样?     jeanron: 
【故障处理】 ORA-19809 错误处理 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ① ORA-19809: limit exceeded for recovery files 错误的处理方法 RMAN-03009: failure of backup command on ORA_DISK_1 channel at 07/26/2016 17