监控报警发现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的更多相关文章

  1. Linux下禁止使用swap及防止OOM机制导致进程被kill掉

    首先解释两个概念: swap:在linux里面,当物理内存不够用了,而又有新的程序请求分配内存,那么linux就会选择将其他程序暂时不用的数据交换到物理磁盘上(swap out),等程序要用的时候再读 ...

  2. [转]Linux下防止进程使用swap及防止OOM机制导致进程被kill掉

    首先解释两个概念:swap:在linux里面,当物理内存不够用了,而又有新的程序请求分配内存,那么linux就会选择将其他程序暂时不用的数据交换到物理磁盘上(swap out),等程序要用的时候再读进 ...

  3. 记因PHP的内存溢出导致的事故之解决

    如果对您有用记得关注,更多干货. 今天上午刚到公司,就有同事在公司群里反映某个计划任务出现问题了.我就怀着刨根问底的心,去查看了log.发现挺有意思的一个问题,PHP内存溢出导致脚本执行失败.那就一起 ...

  4. REDIS 内存满时删除策略

    REDIS 内存满时删除策略

  5. Linux索引节点(Inode:no space for device)用满导致的一次故障

    问题描写叙述 在storm測试环境集群上上nimbus和supervisor自己主动挂调.重新启动时显示no space for device,也不能创建,加入文件及文件夹,df -h查看 ilesy ...

  6. RDS数据库磁盘满导致实例锁定

    问题描述: 阿里云RDS空间不足,进行报警.收到报警后.对数据库中不重要的数据备份后执行delete删除操作.执行成功后发现数据删掉了.但是数据库的空间并没有释放.数据占用空间反而越来越大,最后RDS ...

  7. kafka 磁盘写满导致 InternalError

    tailf kafka/log/server.log [2019-12-19 17:19:05,121] FATAL (main kafka.server.KafkaServerStartable 1 ...

  8. 内存回收导致关键业务抖动案例分析-论云原生OS内存QoS保障

    蒋彪,腾讯云高级工程师,10+年专注于操作系统相关技术,Linux内核资深发烧友.目前负责腾讯云原生OS的研发,以及OS/虚拟化的性能优化工作. 导语 云原生场景,相比于传统的IDC场景,业务更加复杂 ...

  9. 技术分享 | MySQL中MGR中SECONDARY节点磁盘满,导致mysqld进程被OOM Killed

    欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答 在MGR测试中,人为制造磁盘满问题后,节点被oom killed 问题描述 在对 ...

随机推荐

  1. 数据库(学习整理)----7--Oracle导入导出数据库文件

    Oracle导入本地数据库操作手册 1.旧数据库忘记了密码,首先进入cmd:1)输入:sqlplus/nolog2)输入:connect/as sysdba3)输入:alter user sys id ...

  2. python2.7响应数据中unicode转中文

    print ("响应结果:%s" % r.content.decode('unicode_escape')) 一. 在爬虫抓取网页信息时常需要将类似"\u4eba\u75 ...

  3. channel_id以及type_id的内容

  4. 关于Html5中的单选与多选

    1.下拉列表样式: <select> <option value ="volvo">Volvo</option> <option valu ...

  5. java多线程的基本介绍

    Java多线程 1.进程与线程 进程是程序的一次动态执行过程,它需要经历从代码加载,代码执行到执行完毕的一个完整的过程,这个过程也是进程本身从产生,发展到最终消亡的过程.多进程操作系统能同时达运行多个 ...

  6. Regex 常用的正则表达式

    .校验数字的表达式 数字:^[0-9]*$ n位的数字:^\d{n}$ 至少n位的数字:^\d{n,}$ m-n位的数字:^\d{m,n}$ 零和非零开头的数字:^(0|[1-9][0-9]*)$ 非 ...

  7. 第七篇 Python面向对象

    类是对一群具有相同特征或者行为的事物的一个统称,是抽象的,不能直接使用,特征被称为属性,行为被称为方法,类就相当于制造飞机时的图纸,是一个模板,是负责创建对象的. 对象是由类创建出来的一个具体存在,可 ...

  8. webservice怎么给对方提供报文,即wsdl文件

    1.webservice发布后在网页打开服务,点击服务说明 2.打开这样一个页面,ctrl+s保存网页,后缀改为wsdl,搞定

  9. 【bzoj3456】城市规划 dp+多项式求逆

    Description 刚刚解决完电力网络的问题, 阿狸又被领导的任务给难住了. 刚才说过, 阿狸的国家有n个城市, 现在国家需要在某些城市对之间建立一些贸易路线, 使得整个国家的任意两个城市都直接或 ...

  10. bzoj1565【NOI2009】植物大战僵尸(最小割)

    题目描述 Plants vs. Zombies(PVZ)是最近十分风靡的一款小游戏.Plants(植物)和Zombies(僵尸)是游戏的主角,其中Plants防守,而Zombies进攻.该款游戏包含多 ...