my33_内存满导致mysqld被kill
监控报警发现MGR的一个节点故障，查看时发现LVS已经发生切换，LVS切到了MGR新的写节点上了，排查原因
/var/log/message
Mar :: db10 kernel: crond invoked oom-killer: gfp_mask=0x3000d0, order=, oom_score_adj=
Mar :: db10 kernel: crond cpuset=/ mems_allowed=-
Mar :: db10 kernel: CPU: PID: Comm: crond Tainted: G OE ------------ 3.10.-693.21..el7.x86_64 #
Mar :: db10 kernel: Hardware name: Inspur SA5212M4/YZMB--, BIOS 4.1. //
Mar :: db10 kernel: Call Trace:
Mar :: db10 kernel: [<ffffffff816ae7c8>] dump_stack+0x19/0x1b
Mar :: db10 kernel: [<ffffffff816a9b90>] dump_header+0x90/0x229
Mar :: db10 kernel: [<ffffffff810ecec2>] ? ktime_get_ts64+0x52/0xf0
Mar :: db10 kernel: [<ffffffff8114140f>] ? delayacct_end+0x8f/0xb0
Mar :: db10 kernel: [<ffffffff8118a884>] oom_kill_process+0x254/0x3d0
Mar :: db10 kernel: [<ffffffff8118a32d>] ? oom_unkillable_task+0xcd/0x120
Mar :: db10 kernel: [<ffffffff8118a3d6>] ? find_lock_task_mm+0x56/0xc0
Mar :: db10 kernel: [<ffffffff8118b0c6>] out_of_memory+0x4b6/0x4f0
Mar :: db10 kernel: [<ffffffff816aa694>] __alloc_pages_slowpath+0x5d6/0x724
Mar :: db10 kernel: [<ffffffff811912a5>] __alloc_pages_nodemask+0x405/0x420
Mar :: db10 kernel: [<ffffffff8108859d>] copy_process+0x1dd/0x1970
Mar :: db10 kernel: [<ffffffff81121930>] ? audit_filter_rules.isra.+0x280/0xf90
Mar :: db10 kernel: [<ffffffff81089ee1>] do_fork+0x91/0x320
Mar :: db10 kernel: [<ffffffff8108a1f6>] SyS_clone+0x16/0x20
Mar :: db10 kernel: [<ffffffff816c0ad4>] stub_clone+0x44/0x70
Mar :: db10 kernel: [<ffffffff816c0715>] ? system_call_fastpath+0x1c/0x21
Mar :: db10 kernel: Mem-Info:
Mar :: db10 kernel: active_anon: inactive_anon: isolated_anon:# active_file: inactive_file: isolated_file:# unevictable: dirty:
writeback: unstable:# slab_reclaimable: slab_unreclaimable:# mapped: shmem: pagetables: bounce:# free: free_pcp: free_cma:
Mar :: db10 kernel: Node DMA free:13540kB min:8kB low:8kB high:12kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB iso
lated(anon):0kB isolated(file):0kB present:15984kB managed:15900kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kern
el_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned: all_unreclaimable? yes
Mar :: db10 kernel: lowmem_reserve[]:
Mar :: db10 kernel: Node DMA32 free:250600kB min:1176kB low:1468kB high:1764kB active_anon:1442100kB inactive_anon:464kB active_file:0kB inactive_file:0kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1934208kB managed:1722948kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:1740kB slab_reclaimable:
kB slab_unreclaimable:7640kB kernel_stack:368kB pagetables:1132kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned: all_unre
claimable? yes
Mar :: db10 kernel: lowmem_reserve[]:
Mar :: db10 kernel: Node Normal free:54592kB min:43744kB low:54680kB high:65616kB active_anon:62871276kB inactive_anon:371740kB active_file:12kB inactive_f
ile:24kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:65011712kB managed:63961888kB mlocked:0kB dirty:0kB writeback:0kB mapped:1028kB shmem:1190332kB slab_
reclaimable:124084kB slab_unreclaimable:45492kB kernel_stack:4768kB pagetables:92984kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned: all_unreclaimable? no
Mar :: db10 kernel: lowmem_reserve[]:
Mar :: db10 kernel: Node Normal free:68040kB min:45176kB low:56468kB high:67764kB active_anon:64843172kB inactive_anon:349996kB active_file:0kB inactive_file:160kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:67108864kB managed:66056756kB mlocked:0kB dirty:192kB writeback:0kB mapped:50080kB shmem:947300kB slab_reclaimable:100392kB slab_unreclaimable:77980kB kernel_stack:28736kB pagetables:170020kB unstable:0kB bounce:0kB free_pcp:640kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned: all_unreclaimable? no
Mar :: db10 kernel: lowmem_reserve[]:
Mar :: db10 kernel: Node DMA: *4kB (U) *8kB *16kB *32kB (U) *64kB (U) *128kB (U) *256kB *512kB *1024kB (U) *2048kB (UM) *4096kB (M) = 13540kB
Mar :: db10 kernel: Node DMA32: *4kB (UEM) *8kB (UEM) *16kB (UEM) *32kB (UEM) *64kB (UEM) *128kB (UEM) *256kB (UEM) *512kB (UEM) *1024kB (EM) *2048kB (E) *4096kB = 250600kB
Mar :: db10 kernel: Node Normal: *4kB (UEM) *8kB (UM) *16kB (M) *32kB (M) *64kB *128kB *256kB *512kB *1024kB *2048kB *4096kB = 54756kB
Mar :: db10 kernel: Node Normal: *4kB (UEM) *8kB (UM) *16kB *32kB *64kB *128kB *256kB *512kB *1024kB *2048kB *4096kB = 66660kB
Mar :: db10 kernel: Node hugepages_total= hugepages_free= hugepages_surp= hugepages_size=1048576kB
Mar :: db10 kernel: Node hugepages_total= hugepages_free= hugepages_surp= hugepages_size=2048kB
Mar :: db10 kernel: Node hugepages_total= hugepages_free= hugepages_surp= hugepages_size=1048576kB
Mar :: db10 kernel: Node hugepages_total= hugepages_free= hugepages_surp= hugepages_size=2048kB
Mar :: db10 kernel: total pagecache pages
Mar :: db10 kernel: pages in swap cache
Mar :: db10 kernel: Swap cache stats: add , delete , find /
Mar :: db10 kernel: Free swap = 0kB
Mar :: db10 kernel: Total swap = 0kB
Mar :: db10 kernel: pages RAM
Mar :: db10 kernel: pages HighMem/MovableOnly
Mar :: db10 kernel: pages reserved
Mar :: db10 kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Mar :: db10 kernel: [ ] systemd-journal
Mar :: db10 kernel: [ ] lvmetad
Mar :: db10 kernel: [ ] - systemd-udevd
Mar :: db10 kernel: [] irqbalance
Mar :: db10 kernel: [] chronyd
Mar :: db10 kernel: [] - dbus-daemon
Mar :: db10 kernel: [] smartd
Mar :: db10 kernel: [] lsmd
Mar :: db10 kernel: [] rsyslogd
Mar :: db10 kernel: [] rngd
Mar :: db10 kernel: [] systemd-logind
Mar :: db10 kernel: [] atd
Mar :: db10 kernel: [] crond
Mar :: db10 kernel: [] supervise
Mar :: db10 kernel: [] run
Mar :: db10 kernel: [] tuned
Mar :: db10 kernel: [] - sshd
Mar :: db10 kernel: [] agetty
Mar :: db10 kernel: [] hooagentd
Mar :: db10 kernel: [] hooagent
Mar :: db10 kernel: [] master
Mar :: db10 kernel: [] qmgr
Mar :: db10 kernel: [] wonder-agent
Mar :: db10 kernel: [] - logmon
Mar :: db10 kernel: [] screen
Mar :: db10 kernel: [] bash
Mar :: db10 kernel: [] screen
Mar :: db10 kernel: [] bash
Mar :: db10 kernel: [] screen
Mar :: db10 kernel: [] bash
Mar :: db10 kernel: [] mysqld_safe
Mar :: db10 kernel: [] mysqld
Mar :: db10 kernel: [] mysqld_exporter
Mar :: db10 kernel: [ ] bbmon
Mar :: db10 kernel: [ ] pickup
Mar :: db10 kernel: [ ] trivial-rewrite
Mar :: db10 kernel: [ ] crond
Mar :: db10 kernel: [ ] sh
Mar :: db10 kernel: [ ] dbvip
Mar :: db10 kernel: [ ] python
Mar :: db10 kernel: [ ] msval
Mar :: db10 kernel: Out of memory: Kill process (mysqld) score or sacrifice child
Mar :: db10 kernel: Killed process (mysqld) total-vm:297727728kB, anon-rss:127612364kB, file-rss:0kB, shmem-rss:0kB
直接原因是下面这个mysqld进程被杀
Mar :: db10 kernel: Killed process (mysqld) total-vm:297727728kB, anon-rss:127612364kB, file-rss:0kB, shmem-rss:0kB
然后往上面看，mysqld占用的内存是70多G，系统物理内存是128G
Mar :: db10 kernel: [] mysqld
再往上看涉及到了node0、node1、hugepages_total，swap，这主要是numa和大页相关，先跳过这两个问题，既然这里是70多Gmysqld就被kill掉了，那我先设置mysqlbuffer_pool为 64G，先为防止该问题再出现加一道保险，然后再慢慢排查
mysql> show variables like '%pool_size%';
+-------------------------+-------------+
| Variable_name | Value |
+-------------------------+-------------+
| innodb_buffer_pool_size | |
+-------------------------+-------------+
row in set (0.00 sec) mysql> select ***;
+-------------------+
| *** |
+-------------------+
| |
+-------------------+
row in set (0.00 sec) mysql>
mysql>
mysql> set global innodb_buffer_pool_size=;
Query OK, rows affected (0.00 sec) mysql> show global variables like '%pool_size%';
+-------------------------+-------------+
| Variable_name | Value |
+-------------------------+-------------+
| innodb_buffer_pool_size | |
+-------------------------+-------------+
row in set (0.00 sec)
注意，配置文件也要修改一下；修改后OS会慢慢释放一些内存，当然，那些正在使用内存不会被释放。
再回头看这个内存问题，从日志中可以看出OS对内存处理的顺序是numa-->大页-->swap，numa内存不足，查看大页，最后查看了swap，暂时跳过numa、大页的问题，先看swap，系统想使用swap时，发现swap为0，然后就kill了mysql
Mar :: db10 kernel: total pagecache pages
Mar :: db10 kernel: pages in swap cache
Mar :: db10 kernel: Swap cache stats: add , delete , find /
Mar :: db10 kernel: Free swap = 0kB
Mar :: db10 kernel: Total swap = 0kB
系统想去要535067个页的内存，去swap找，结果系统没有swap，后面系统打印出各进程的内存使用情况，发现mysqld进程占用的内存最多，就杀掉了mysqld进程，从而有了可回收的内存；看到这里一个方案就出来了-->加swap，物理内存128G，加swap 64G，这里提一下swap是磁盘上的一块空间，访问swap当然没有访问内存快，同时，在内存不足与swap空间进行交互时，对OS的性能也是一种损耗，所以swap不是越多越好，这里加64G，加swap的过程略。内存向swap中放的通常是冷数据，这些冷数据是可以定期回收的。
再看这个numa，当时安装迁移数据库的时候，安装是在centos7.4上安装的，centos7.4默认是关闭numa，确切说默认没有配置numa，直接将原系统（centos6.2）上的配置文件复制过来，做一些简单调整，就开始安装了数据库，那numa是怎么回事？
查看现运行库numa相关参数，发现该参数是ON，配置文件是复制来的，这说明复制来的配置文件是ON
mysql> show variables like '%numa%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| innodb_numa_interleave | ON |
+------------------------+-------+
row in set (0.00 sec)
配置文件中有
loose_innodb_numa_interleave =
查看mysql官方的参数说明，这个参数开启以为着系统使用了numa的MPOL_DEFAULT特性，并且要求系统开启numa功能
Enables the NUMA interleave memory policy for allocation of the InnoDB buffer pool. When innodb_numa_interleave is enabled, the NUMA memory policy is set to MPOL_INTERLEAVE for the mysqld process. After the InnoDB buffer pool is allocated, the NUMA memory policy is set back to MPOL_DEFAULT. For the innodb_numa_interleave option to be available, MySQL must be compiled on a NUMA-enabled Linux system.
查看原来的系统，原来的centos6.2系统果然是开启了numa的
$ numastat
node0 node1
numa_hit
numa_miss
numa_foreign
interleave_hit
local_node
other_node
而新系统centos7.4默认没有开启numa，解决方案随之就出来了，关闭innodb_numa_interleave参数，mysql5.7.9默认关闭该参数，现版本是mysql5.7.24,删除配置文件中该参数即可，重启实例才能生效。由于前面缩小了内存，并加了swap，这里只重启读节点（读节点重启时lvs流量先切到其他节点），写节点只修改配置。由于服务器节点比较多，修改的内容也比较重要，统一修改完后，要再回头一一验证一下，以防遗漏。
关于大页，hugepages_total=0表示大页是关闭的，mysql关闭大页的参数有以下两个，默认也为关闭
mysql> show variables like 'large_page%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| large_page_size | |
| large_pages | OFF |
+-----------------+-------+
rows in set (0.00 sec)
大页关闭时的状态
$ grep Huge /proc/meminfo
AnonHugePages: 39612416 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
根据日志分析，解决方案也出来了，但真正的问题未没有解决，mysql的内存为什么会使用这么多，128G不够用？是什么占用了内存？
mysql使用内存=
key_buffer_size
+ query_cache_size
+ tmp_table_size
+ innodb_buffer_pool_size
+ innodb_additional_mem_pool_size
+ innodb_log_buffer_size + max_connections
×( sort_buffer_size
+ read_buffer_size
+ read_rnd_buffer_size
+ join_buffer_size
+ thread_stack
+ binlog_cache_size)
以上是mysql内存的占用部分，依次排查，发现binlog_cache_size参数在不久前从16M调整到了128M，系统的连接高时可到5000，可想相乘以后需要的内存有多大；解决方案--binlog_cache_size是会话级的，恢复该参数为16M.官方关于该参数的解释
The size of the cache to hold changes to the binary log during a transaction. A binary log cache is allocated for each client if the server supports any transactional storage engines and if the server has the binary log enabled (--log-bin option).
在一个事务运行期间，binlog_cache_size会缓存该事务修改的内存到binlog日志中。这意味着对于select语句，该参数不生效，但对于DML语句，就会按该参数分配资源，当系统的DML并发高时，占用的内存就多。
话外音：
前不久新入职一个数据库专家，给了优化的建议，大约修改了10个参数，加上这个，已经回退了两个参数。他是根据他之前公司的经验修改的，但他之前的公司没什么并发，同时对参数的含义理解也有误，不像这里单库并发能到四五千。修改现有线上系统前，一定要对修改的内容做充分的调研，最好是模拟一下线上运行环境，再进行上线。
my33_内存满导致mysqld被kill的更多相关文章
- Linux下禁止使用swap及防止OOM机制导致进程被kill掉
首先解释两个概念: swap:在linux里面,当物理内存不够用了,而又有新的程序请求分配内存,那么linux就会选择将其他程序暂时不用的数据交换到物理磁盘上(swap out),等程序要用的时候再读 ...
- [转]Linux下防止进程使用swap及防止OOM机制导致进程被kill掉
首先解释两个概念:swap:在linux里面,当物理内存不够用了,而又有新的程序请求分配内存,那么linux就会选择将其他程序暂时不用的数据交换到物理磁盘上(swap out),等程序要用的时候再读进 ...
- 记因PHP的内存溢出导致的事故之解决
如果对您有用记得关注,更多干货. 今天上午刚到公司,就有同事在公司群里反映某个计划任务出现问题了.我就怀着刨根问底的心,去查看了log.发现挺有意思的一个问题,PHP内存溢出导致脚本执行失败.那就一起 ...
- REDIS 内存满时删除策略
REDIS 内存满时删除策略
- Linux索引节点(Inode：no space for device)用满导致的一次故障
问题描写叙述 在storm測试环境集群上上nimbus和supervisor自己主动挂调.重新启动时显示no space for device,也不能创建,加入文件及文件夹,df -h查看 ilesy ...
- RDS数据库磁盘满导致实例锁定
问题描述: 阿里云RDS空间不足,进行报警.收到报警后.对数据库中不重要的数据备份后执行delete删除操作.执行成功后发现数据删掉了.但是数据库的空间并没有释放.数据占用空间反而越来越大,最后RDS ...
- kafka 磁盘写满导致 InternalError
tailf kafka/log/server.log [2019-12-19 17:19:05,121] FATAL (main kafka.server.KafkaServerStartable 1 ...
- 内存回收导致关键业务抖动案例分析-论云原生OS内存QoS保障
蒋彪,腾讯云高级工程师,10+年专注于操作系统相关技术,Linux内核资深发烧友.目前负责腾讯云原生OS的研发,以及OS/虚拟化的性能优化工作. 导语 云原生场景,相比于传统的IDC场景,业务更加复杂 ...
- 技术分享 | MySQL中MGR中SECONDARY节点磁盘满，导致mysqld进程被OOM Killed
欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答 在MGR测试中,人为制造磁盘满问题后,节点被oom killed 问题描述 在对 ...
随机推荐
- h5存储的优点
1.解决4k大小问题2.解决请求头常带存储信息的问题3.解决关系型存储问题4.可以跨浏览器
- python 单双引号交替的json串
单双引号交替的json串 1.常见的json串,类似于这种{"isSucess":true, "name":"yoyo", "st ...
- 解决jquery操作checkbox火狐下第二次无法勾选问题
最近在学习jQuery(版本jquery-1.9.1.js),要求用jQuery实现全选/全不选.反选,在IE(IE8)中没有问题,但在火狐浏览器中调试的时候出现了一些小问题,达不到效果. html代 ...
- 一套最全的JavaScript 语言基础知识点总结（思维导图10张）
1.DOM基础操作 2.数组基础 3.函数基础 4.运算符 5.流程控制语句 6.正则表达式 7.字符串函数 8.数据类型 9.变量 10.window对象
- 动态内存分配存在的问题（内存空洞）------c++程序设计原理与实践（进阶篇）
new的问题究竟在哪里呢?实际上问题出在new和delete的结合使用上.考察下面程序中内存分配和释放过程: while(1){ Big* p=new big; //...... Small* n1= ...
- ubuntu14.04，安装Gnome 15.10 （桌面）
Linux:ubuntu14.04 Gnome:15.10 更新最新版Gnome的一个好处:更新了ubuntu的软件源,我们可以使用ubuntu的软件中心获取更多需要的软件!! ubuntu默认的桌面 ...
- 光猫烽火Hg220破解超级口令实用图文教程（亲测）
1.用光猫背后的useradmin 帐号和密码登录 192.168.1.12.然后下载http://192.168.1.1/backupsettings.conf3.用记事本打开,ctrl+F,查找关 ...
- kali linux之webshell
webacoo(web backdoor cookie) 类终端的shell 编码通信内容通过cookie头传输,隐蔽性较强 cm:base64编码的命令 cn:服务器用于返回数据的cookie头的名 ...
- blog搬家须知
我的博客即将入驻“云栖社区”,诚邀技术同仁一同入驻. 地址:这里. 不过这里也是会同步更新的
- bzoj1565【NOI2009】植物大战僵尸（最小割）
题目描述 Plants vs. Zombies(PVZ)是最近十分风靡的一款小游戏.Plants(植物)和Zombies(僵尸)是游戏的主角,其中Plants防守,而Zombies进攻.该款游戏包含多 ...