MySQL OOM 系列三 摆脱MySQL被Kill的厄运

前面两章，我们分析了Linux内存分配的策略以及Linux通过使用 OOM_Killer的机制解决了“超售”引起的风险，MySQL同其他的应用程序一样，在操作系统允许的范围内也是可以超售的，一般人理解，Innodb_buffer_pool必须小于实际物理内存，否则MySQL会启动失败。其实这是一个误区，这个不是MySQL层控制的，这个是操作系统（OS）层控制的，就是前面提到的/proc/sys/overcommit_memory控制OS是否允许“超售”。如果允许“超售”，则Innodb_buffer_pool可以远远超过实际的内存空间大小，但是这部分空间是没有使用的。我们可以做个小实验，见下图：

MySQL的Innodb_buffer_pool开了5G，但实际内存只有3G。
讲了这么多，现在言归正传，回到我们最早提到的RDS实例被OS Kill掉的问题上来，前面我们也提到了，一旦实例可用内存不足，MySQL一般都会成为OOM_Killer的首选目标。这里就涉及到两个问题：

1.为什么会内存不足？
2.如何让MySQL摆脱被Kill的厄运？
首先我们来看一下第一个问题。内存不足这个问题产生原因很多，但是主要就两个方面，第一个是MySQL自身内存的规划有问题。第二个就是一般部署MySQL的服务器，都会部署很多的监控或者定时任务脚本，而这些脚本往往缺少必要的内存限制，导致在高峰期的时候占用大量的内存，导致触发Linux OOM_Killer机制，MySQL就无辜牺牲了。
那如何才能让MySQL摆脱被Kill的厄运呢？ MySQL被Kill的根源在于Linux超售的内存分配机制，前面也提到了，只要存在这种超售的机制，就不可能完全避免某一个应用程序被Kill的风险。那要使得MySQL一定不会被Kill掉，只能禁止操作系统超出实际内存空间的分配内存。但是前面我们也提过，对于部署了MySQL的服务器，我们不建议这么做，因为MySQL的很多内存都是刚开始申请了，并不是立即使用的，OS一旦禁止超售，这不仅对MySQL自身内存规划提出更苛刻的要求，同时也存在内存无法充分利用的问题。同时，MySQL的每个连接的私有内存是动态分配的，如果分配不到，就会直接导致服务器Crash，这样也会增加MySQL Crash的风险。
既然受限于操作系统，无法完全做到避免被Kill，那只能尽量降低MySQL被Kill的几率。我觉得至少可以做下面3个事情：

1)合理的规划MySQL的内存使用。
2)调整OOM_adj参数，将MySQL被OOM_Killer锁定的优先级降低。
3)加强内存的监控和报警，一旦报警，DBA应该迅速介入，Kill掉一些占用较多内存的连接。

赞 (0)

相关推荐

  • percona-toolkit之pt-kill 杀掉mysql查询或连接的方法

    pt-kill 是一个非常简单的 杀mysql线程和查询的 工具. 主要是为了防止一些长的查询 长时间占用 系统资源,而对线上业务造成影响的情况. 主要作用: 从show processlist 中获取满足条件的连接或者从包含show processlist的文件中读取满足条件的连接并打印或者杀掉或者执行其他操作. 我们这里主要用来防止某些select操作时间过长,从而影响其他线上SQL. 安装: 安装percona-toolkit即可 使用范例: pt-kill --log-dsn D=tes

  • 批量 kill mysql 中运行时间长的sql

     KILL语法 KILL [CONNECTION | QUERY] thread_id 每个与mysqld的连接都在一个独立的线程里运行,您可以使用SHOW PROCESSLIST语句查看哪些线程正在运行,并使用KILL thread_id语句终止一个线程. KILL允许自选的CONNECTION或QUERY修改符: · KILL CONNECTION与不含修改符的KILL一样:它会终止与给定的thread_id有关的连接. · KILL QUERY会终止连接当前正在执行的语句,但是会保持连接的

  • MySQL Slave 触发 oom-killer解决方法

    最近经常有收到MySQL实例类似内存不足的报警信息,登陆到服务器上一看发现MySQL 吃掉了99%的内存,God ! 有时候没有及时处理,内核就会自己帮我们重启下MySQL,然后我们就可以看到 dmesg 信息有如下记录: Mar 9 11:29:16 xxxxxx kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0 Mar 9 11:29:16 xxxxxx kerne

  • Mysql使用kill命令解决死锁问题(杀死某条正在执行的sql语句)

    在使用mysql运行某些语句时,会因数据量太大而导致死锁,没有反映.这个时候,就需要kill掉某个正在消耗资源的query语句即可, KILL命令的语法格式如下: KILL [CONNECTION | QUERY] thread_id 每个与mysqld的连接都在一个独立的线程里运行,您可以使用SHOW PROCESSLIST语句查看哪些线程正在运行,并使用KILL thread_id语句终止一个线程. KILL允许自选的CONNECTION或QUERY修改符:KILL CONNECTION与不

  • MySQL OOM 系统二 OOM Killer

    MySQL OOM 系统二 OOM Killer

    这里就涉及到一个问题,到底Kill掉谁呢?一般稍微了解一些Linux内核的同学第一反应是谁用的最多,就Kill掉谁.这当然是Linux内核首先考虑的一种重要因素,但是也不完全是这样的,我们查一些Linux的内核方面的资料,可以知道其实Kill谁是由/proc/<pid>/oom_score来决定的,这个值每个进程一个,是由Linux内核的oom_badness()函数负责计算的.那下面我们来仔细读一读badness()函数. 在badness()函数的注释部分,写明了badness()函数的处

  • MySQL OOM 系列三 摆脱MySQL被Kill的厄运

    MySQL OOM 系列三 摆脱MySQL被Kill的厄运

    前面两章,我们分析了Linux内存分配的策略以及Linux通过使用 OOM_Killer的机制解决了"超售"引起的风险,MySQL同其他的应用程序一样,在操作系统允许的范围内也是可以超售的,一般人理解,Innodb_buffer_pool必须小于实际物理内存,否则MySQL会启动失败.其实这是一个误区,这个不是MySQL层控制的,这个是操作系统(OS)层控制的,就是前面提到的/proc/sys/overcommit_memory控制OS是否允许"超售".如果允许&q

  • MySQL OOM 系列一 Linux内存分配

    MySQL OOM 系列一 Linux内存分配

    RDS(网易云关系数据库服务)上线已经有一段时间,陆续不断有产品迁入到了RDS中,在线上运维的过程中,也遇到了一些曾经没有考虑到,或者考虑的不全的东西.后续有时间可以分享给大家. 今天想提到的是线上一个4G的RDS实例,发生了OOM(out of memory)的问题,MySQL进程被直接Kill掉了.在解释这个问题的时候,我们首先需要从Linux系统内存分配策略讲起.     一般写C语言程序,我们习惯使用malloc动态的申请内存空间(Java由JVM负责内存管理),malloc函数会向操作

  • Mysql精粹系列(精粹)

    关于Mysql整理的需要记忆和熟练掌握的内容 1. /* 查看操作 */ ------------------------------------------------------------------------------------------------------- 1. /* 查看操作 */ SHOW PROCESSLIST -- 显示哪些线程正在运行 SHOW VARIABLES -- 查看变量 2. /* 数据库操作 */ --------------------------

  • sqlserver、Mysql、Oracle三种数据库的优缺点总结

    一.sqlserver优点:易用性.适合分布式组织的可伸缩性.用于决策支持的数据仓库功能.与许多其他服务器软件紧密关联的集成性.良好的性价比等:为数据管理与分析带来了灵活性,允许单位在快速变化的环境中从容响应,从而获得竞争优势.从数据管理和分析角度看,将原始数据转化为商业智能和充分利用Web带来的机会非常重要.作为一个完备的数据库和数据分析包,SQLServer为快速开发新一代企业级商业应用程序.为企业赢得核心竞争优势打开了胜利之门.作为重要的基准测试可伸缩性和速度奖的记录保持者,SQLServ

  • 安装MySQL常见的三种方式

    目录 安装MySQL的方式常见的有三种: rpm包形式 通用二进制形式 源码编译 1,rpm包形式 (1) 操作系统发行商提供的 (2) MySQL官方提供的(版本更新,修复了更多常见BUG)www.mysql.com/downloads 关于MySQL中rpm包类型的介绍: MySQL-client         客户端组件  MySQL-debuginfo      调试MySQL的组件  MySQL-devel          想针对于MySQL编译安装PHP等依赖于MySQL的组件包

  • MySQL OOM（内存溢出）的解决思路

    OOM全称"Out Of Memory",即内存溢出. 内存溢出已经是软件开发历史上存在了近40年的"老大难"问题.在操作系统上运行各种软件时,软件所需申请的内存远远超出了物理内存所承受的大小,就叫内存溢出. 内存溢出产生原因多种多样,当内存严重不足时,内核有两种选择: 直接panic 杀掉部分进程,释放一些内核. 大部分情况下,会杀掉导致OOM的进程,然后系统恢复.通常我们会添加对内存的监控报警,例如:当memory或swap使用超过90%时,触发报警通知,需要及

  • MySQL系列之十三 MySQL的复制

    MySQL系列之十三 MySQL的复制

    目录 一.MySQL复制相关概念 二.简单的一主一从架构实现 1.新数据库搭建主从架构 2.旧数据库新加从服务器 三.级联复制架构实现 四.主主复制架构 五.半同步复制的实现 六.加密传输复制的实现 七.MySQL复制的相关指令和变量总结 一.MySQL复制相关概念 主从复制:主节点将数据同步到多个从节点 级联复制:主节点将数据同步到一个从节点,其他的从节点在向从节点复制数据 同步复制:将数据从主节点全部同步到从节点时才返回给用户的复制策略叫同步复制 异步复制:只要数据写入到主节点就立即返回给用

  • MySQL系列之开篇 MySQL关系型数据库基础概念

    目录 一.基础概念 二.数据库管理技术的发展 三.关系型数据库(RDBMS)概念 四.RDBMS设计范式 一.基础概念 数据(Data)是描述事物的符号记录,是指利用物理符号记录下来的.可以鉴别的信息. 1.数据库(Database,DB)是指长期储存在计算机中的有组织的.可共享的数据集合.数据要按照一定的数据模型组织.描述和存储,具有较小的冗余度.较高的数据独立性,系统易于扩展,并可以被多个用户分享. 数据的三个基本特点: 永久存储 有组织 可共享 2.数据库管理系统(DBMS)是专门用于建立

  • MySQL系列之九 mysql查询缓存及索引

    MySQL系列之九 mysql查询缓存及索引

    目录 一.MySQL的架构 二.查询缓存(Query Cache) 哪些查询可能不会被缓存: 查询缓存相关的服务器变量: 查询缓存相关的状态变量: 三.索引 1.索引类型: 2.高性能索引策略: 3.索引的优化建议 4.索引的创建与删除 四.EXPLAIN命令 五.SQL语句性能优化 一.MySQL的架构 连接器 连接池,安全认证.线程池.连接限制.检查内存.缓存 SQL接口 DML.DDL SQL解析器,对SQL语句的权限检查.解析为二进制程序 优化器,优化访问路径 缓存cache,buffe

  • MySQL系列之十 MySQL事务隔离实现并发控制

    MySQL系列之十 MySQL事务隔离实现并发控制

    目录 一.并发访问控制 二.事务Transactions 1.事务遵循ACID原则: 2.事务的生命周期 3.事务的隔离级别 4.死锁 一.并发访问控制 实现的并发访问的控制技术是基于锁: 锁分为表级锁和行级锁,MyISAM存储引擎不支持行级锁:InnoDB支持表级锁和行级锁: 锁的分类有读锁和写锁,读锁也被称为共享锁,加读锁的时候其他的人可以读:写锁也称为独占锁或排它锁,一个写锁会阻塞其他读操作和写操作: 锁还分为隐式锁和显式锁,隐式锁由存储引擎自行管理,显式锁是用户手动添加锁: 锁策略:在锁

随机推荐