MySQL 5.7 OOM问题诊断——就是这么简单

最新推荐文章于 2023-05-31 16:52:34 发布
转载 最新推荐文章于 2023-05-31 16:52:34 发布 · 232 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：http://www.cnblogs.com/xibuhaohao/p/10838460.html
文章标签：

#数据库

风清扬又道：“单以武学而论，这些魔教长老们也不能说真正已窥上乘武学之门。他们不懂得，招数是死的，发招之人却是活的。死招数破得再妙，遇上了活招数，免不了缚手缚脚，只有任人屠戮。这个‘活’字，你要牢牢记住了。学招时要活学，使招时要活使。倘若拘泥不化，便练熟了几千万手绝招，遇上了真正高手，终究还是给人家破得干干净净。”

今天，来谈谈MySQL的OOM（out of memory）问题诊断。之前，这类问题的定位对于普通用户来说并不怎么简单。但是在MySQL 5.7中，OOM问题的定位变得极其容易。还没掌握的小伙伴赶快来看下吧。通常来说，发生OOM时可在系统日志找到类似的日志提示：

[3207032.031552] bash invoked oom-killer: gfp_mask=0x280da,order=0, oom_score_adj=0

[3207032.031561] bash cpuset=/ mems_allowed=0-1

[3207032.031566] CPU: 1 PID: 5019 Comm: bash Not tainted3.10.0-327.22.2.el7.x86_64 #1

[3207032.031568] Hardware name: Huawei Technologies Co.,

[3207032.031570] ffff8802322b7300 00000000922e27ce ffff8803f0c9baf8 ffffffff816360fc

[3207032.031576] ffff8803f0c9bb88 ffffffff8163109c ffff88003547bde0 ffff88003547bdf8

[3207032.031579] 0000000000000206 ffff8802322b7300 ffff8803f0c9bb70 ffffffff81128c7f

[3207032.031583] Call Trace:

[3207032.031596] [<ffffffff816360fc>] dump_stack+0x19/0x1b

[3207032.031600] [<ffffffff8163109c>] dump_header+0x8e/0x214

[3207032.031614] [<ffffffff81128c7f>] ? delayacct_end+0x8f/0xb0

[3207032.031620] [<ffffffff8116d20e>] oom_kill_process+0x24e/0x3b0

[3207032.031623] [<ffffffff8116cd76>] ? find_lock_task_mm+0x56/0xc0

[3207032.031626] [<ffffffff8116da36>] out_of_memory+0x4b6/0x4f0

[3207032.031630] [<ffffffff81173c26>] __alloc_pages_nodemask+0xaa6/0xba0

[3207032.031637] [<ffffffff811b7eba>] alloc_pages_vma+0x9a/0x150

[3207032.031643] [<ffffffff81197a85>] handle_mm_fault+0xb85/0xf50

[3207032.031648] [<ffffffff81641d80>] __do_page_fault+0x150/0x450

[3207032.031651] [<ffffffff816420a3>] do_page_fault+0x23/0x80

[3207032.031656] [<ffffffff8163e308>] page_fault+0x28/0x30

MySQL 5.7的库performance_schema新增了以下这几张表，用于从各维度查看内存的消耗：

  • memory_summary_by_account_by_event_name

  • memory_summary_by_host_by_event_name

  • memory_summary_by_thread_by_event_name

  • memory_summary_by_user_by_event_name

  • memory_summary_global_by_event_name

简单来说，就是可以根据用户、主机、线程、账号、全局的维度对内存进行监控。同时库sys也就这些表做了进一步的格式化，可以使得用户非常容易的观察到每个对象的内存开销：

细心的同学可能会发现，默认情况下performance_schema只对performance_schema进行了内存开销的统计。但是在对OOM进行诊断时，需要对所有可能的对象进行内存监控。因此，还需要做下面的设置：

mysql> update performance_schema.setup_instruments set

enabled = 'yes' where name like 'memory%';

Query OK, 310 rows affected (0.00 sec) Rows matched: 380 Changed: 310 Warnings: 0

但是这种在线打开内存统计的方法仅对之后新增的内存对象有效：

如想要对全局生命周期中的对象进行内存统计，必须在配置文件中进行设置，然后重启：

通过上面的结果，有小伙伴是不是已经发现可疑的内存使用了呢？memory/innodb/os0file这个对象使用了1.42G内存，而整个数据库实例的Buffer

Pool只有1.05G。那么这时就可以去bugs.mysql.com上去搜索下。果不其然，是一官方已知问题，并已在5.7.14中修复。

通过类似方法Inside君已经定位了5起OOM问题。当然，这里Inside君只是给了一个思路，活学活用，才能达到无招胜有招的至臻境界。

转载于:https://www.cnblogs.com/xibuhaohao/p/10838460.html

mysql 5.7 oom_MySQL 5.7 OOM问题诊断——就是这么简单
weixin_39889214的博客
01-20 281
Inside君最近把金庸先生的笑傲江湖重看了三遍，感慨良多。很多工作、管理、生活、学习上的问题都能在其中一窥究竟，而那是年轻时所不能体会的一种感悟。比如下面的这段话：风清扬又道：“单以武学而论，这些魔教长老们也不能说真正已窥上乘武学之门。他们不懂得，招数是死的，发招之人却是活的。死招数破得再妙，遇上了活招数，免不了缚手缚脚，只有任人屠戮。这个‘活’字，你要牢牢记住了。学招时要活学，使招时要活使。倘...
mysql 1.42_MySQL 5.7 OOM问题诊断--就是这么简单_Mysql_数据库
weixin_39596975的博客
01-27 284
Inside 君最近把金庸先生的笑傲江湖重看了三遍，感慨良多。很多工作、管理、生活、学习上的问题都能在其中一窥究竟，而那是年轻时所不能体会的一种感悟。比如下面风清扬的这段话：风清扬又道：“单以武学而论，这些魔教长老们也不能说真正已窥上乘武学之门。他们不懂得，招数是死的，发招之人却是活的。死招数破得再妙，遇上了活招数，免不了缚手缚脚，只有任人屠戮。这个‘活’字，你要牢牢记住了。学招时要活学，使招时要...
MySQL OOM 系统二 OOM Killer
09-10
前面一节重点分享了Linux的内存分配策略，基于上述的分配策略，为了规避超售的风险，Linux采了一种OOM Killer的机制，即系统可用内存（包括Swap）即将使用完之前，选择性的Kill掉一些进程以求释放一些内存
mysql 5.7 oom_MySQL异常OOM排查
weixin_36309562的博客
02-07 295
#!/usr/bin/python#coding: utf8"""跟踪一段时间内dml趋势，用ES分析Usage:python dml2es.py | logstash -f /etc/logstash/conf.d/t_binlog.conf"""importjsonimportosimportsysimportloggingfrom datetime importdatetimefrom py...
mysqlOOM
weixin_30915951的博客
07-21 257
https://cloud.tencent.com/developer/article/1005397 转载于:https://www.cnblogs.com/WCFGROUP/p/11223070.html
mysql5.7 OOM内存溢出问题排查
cdrcsy的专栏
09-20 5670
MySQL内存泄露排查。 单位：  B是Byte的缩写，B就是Byte，也就是字节（Byte）；b是bit的缩写，b就是bit，也就是比特位（bit）。     8bit（比特位）=1Byte（字节）；     1024Byte（字节）=1KB(千字节)；     1024KB（千字节）=1MB（兆字节）;     1024MB=1GB;     1024GB=1TB; 如何知道mysqld...
使用docker部署mysql5.7
Mr.Zheng的博客
08-27 384
前言 该贴仅限于初级学习环境搭建，不涉及容器排布，docker-compose或者k8s不在此操作，所以该贴不用于生产！ 创建宿主机目录 mkdir -p /root/docker-mysql/data mkdir -p /root/docker-mysql/conf my.cnf vim /root/docker-mysql/conf/my.cnf 编写以下内容 [mysqld] innodb_data_file_path=ibdata1:5M;ibdata2:5M:autoextend bind-
MySQL OOM（内存溢出）的解决思路
09-08
MySQL OOM（内存溢出）是数据库管理中常见的问题，可能导致系统稳定性下降，甚至服务器崩溃。本文主要讨论如何解决MySQL的内存溢出问题，提供了一套详细的排查和处理方案。 首先，了解内存溢出的基本概念。OOM（Out...
MySQL OOM问题处理一则
12-14
MySQL OOM（Out of Memory）问题通常发生在服务器内存不足时，操作系统为了回收内存，会选择终止占用内存较高的进程，如MySQL服务。在这个特定的案例中，MySQL数据库服务由于配置不当，导致了服务器出现OOM现象。 ...
mysql 5.7线程池oom_一个神奇的bug：OOM？优雅终止线程？系统内存占用较高？
weixin_39908462的博客
01-27 360
摘要：该项目是DAYU平台的数据开发(DLF)，数据开发中一个重要的功能就是ETL(数据清洗)。ETL由源端到目的端，中间的业务逻辑一般由用户自己编写的SQL模板实现，velocity是其中涉及的一种模板语言。Velocity之OOMVelocity的基本使用Velocity模板语言的基本使用代码如下：1. 初始化模板引擎2. 获取模板文件3. 设置变量4. 输出在ETL业务中，Velocity模...
mysql oom_MySQL OOM 系统二 OOM Killer
weixin_35813719的博客
01-20 187
这里就涉及到一个问题，到底Kill掉谁呢？一般稍微了解一些Linux内核的同学第一反应是谁用的最多，就Kill掉谁。这当然是Linux内核首先考虑的一种重要因素，但是也不完全是这样的，我们查一些Linux的内核方面的资料，可以知道其实Kill谁是由/proc//oom_score来决定的，这个值每个进程一个，是由Linux内核的oom_badness()函数负责计算的。那下面我们来仔细读一读bad...
MySQL OOM
喝醉酒的小白
05-31 2194
如果MySQL所在的cgroup设置了较小的内存限制，当MySQL进程占用的内存超过了限制时，cgroup的OOM杀手会终止该进程。调整cgroup的资源限制：如果MySQL所在的cgroup设置了较小的内存限制，可以考虑适当增加cgroup的内存限制，以满足MySQL进程的内存需求。同时，监控MySQL的内存使用情况和性能指标，以便及时调整参数并优化系统的内存管理。当系统的内存资源耗尽并出现OOM情况时，操作系统会使用OOM杀手来选择并终止使用过多内存的进程，以便回收内存并保护系统的稳定性。
mysql5.7+内存管理_MySQL 5.7 OOM问题诊断——就是这么简单
weixin_35436969的博客
01-20 590
原标题：MySQL 5.7 OOM问题诊断——就是这么简单Inside君最近把金庸先生的笑傲江湖重看了三遍，感慨良多。很多工作、管理、生活、学习上的问题都能在其中一窥究竟，而那是年轻时所不能体会的一种感悟。比如下面的这段话：风清扬又道：“单以武学而论，这些魔教长老们也不能说真正已窥上乘武学之门。他们不懂得，招数是死的，发招之人却是活的。死招数破得再妙，遇上了活招数，免不了缚手缚脚，只有任人屠戮。这...
mysql 5.7 win8,MySQL 5.7 OOM问题诊断——就是这么简单
weixin_39968946的博客
03-23 138
[3207032.031552] bash invoked oom-killer: gfp_mask=0x280da,order=0, oom_score_adj=0[3207032.031561] bash cpuset=/ mems_allowed=0-1[3207032.031566] CPU: 1 PID: 5019 Comm: bash Not tainted3.10.0-327.22....
大数据量查询容易OOM？试试MySQL流式查询
zlt2000的博客
01-04 1800
一、前言 程序访问 MySQL 数据库时，当查询出来的数据量特别大时，数据库驱动把加载到的数据全部加载到内存里，就有可能会导致内存溢出（OOM）。 其实在 MySQL 数据库中提供了流式查询，允许把符合条件的数据分批一部分一部分地加载到内存中，可以有效避免OOM；本文主要介绍如何使用流式查询并对比普通查询进行性能测试。   二、JDBC实现流式查询 使用JDBC的 PreparedStatement/Statement 的 setFetchSize 方法设置为 Integer.MIN_VALUE.
mysql 5.7 214_MySQL 5.7 OOM问题诊断——就是这么简单
weixin_42513152的博客
01-19 333
[3207032.031552] bash invoked oom-killer: gfp_mask=0x280da,order=0, oom_score_adj=0[3207032.031561] bash cpuset=/ mems_allowed=0-1[3207032.031566] CPU: 1 PID: 5019 Comm: bash Not tainted3.10.0-327.22....
【20180611】MySQL OOM
weixin_33922670的博客
06-11 811
关于MySQL OOM的排查思路 服务器发生内存泄露 如何确认服务器发生内存泄漏: 一般执行free -m就查看内存的使用情况就可以了。假如cached和used的值相差特别大的话，安么这个时候我们可以认为发生了内存泄漏。（一般在CentOS6的版本上面可以这么认为,但是这个说法暂时还没有一个比较可信的依据） buffer和cache的区别: buffer: 缓冲，为了提高内存和硬盘之间的数...
mysql sys库 oom_MySQL OOM解决方案
weixin_42393452的博客
01-20 522
在Linux系统中部署MySQL服务，经常会遇到MySQL因为OOM(out of memory)的原因被操作系统Kill，导致数据库服务异常。要分析该问题，首先我们需要了解一下Linux内存分配的基本策略。一、Linux内存分配策略一般写C语言程序，我们习惯使用malloc动态的申请内存空间(Java由JVM负责内存管理)，malloc函数会向操作系统申请一段连续的内存单元，然后返回这段空间的起...
e3base 340440 1 0 2023 ? 00:00:00 /bin/sh /opt/TDP/mysql-8.0.19/bin/mysqld_safe --defaults-file=/opt/TDP/mysql-8.0.19/etc/my.cnf --user=e3base e3base 340886 340440 1 2023 ? 15-07:45:34 /opt/TDP/mysql-8.0.19/bin/mysqld --defaults-file=/opt/TDP/mysql-8.0.19/etc/my.cnf --basedir=/opt/TDP/mysql-8.0.19 --datadir=/e3base/mysqldata --plugin-dir=/opt/TDP/mysql-8.0.19/lib/plugin --log-error=/opt/TDP/mysql-8.0.19/logs/mysql.log --pid-file=/opt/TDP/mysql-8.0.19/pid/mysql.pid --socket=/opt/TDP/mysql-8.0.19/mysql.sock --port=3306这俩进程有什么区别？
最新发布
07-10
<think>我们正在讨论的是MySQL中`mysqld_safe`和`mysqld`两个进程的区别。根据引用内容，我们可以总结如下： 1. **mysqld_safe** 是一个启动脚本，用于启动和监控 **mysqld** 进程（即MySQL服务器主进程）。 2. **mysqld_safe** 是 **mysqld** 的父进程（引用[1]和引用[3]）。 3. 在Linux系统中，当我们通过服务脚本（如`/etc/init.d/mysql start`）启动MySQL时，实际上执行的是`mysqld_safe`（引用[1]）。 4. `mysqld_safe` 提供了一些安全特性，例如在服务器崩溃时自动重启，以及将错误日志重定向到文件等（引用[2]和引用[4]）。 **两者核心区别**： | 特性 | mysqld_safe | mysqld (直接运行) | |--------------|------------------------------------------------|---------------------------------------| | **进程性质** | 守护进程脚本（Shell脚本） | 数据库主进程（二进制程序） | | **主要功能** | 启动、监控、重启mysqld，管理日志和错误处理 | 实际处理SQL请求和数据存储 | | **运行方式** | 作为mysqld的父进程，通过`nohup`后台运行mysqld | 可直接在前台运行（调试时） | | **崩溃恢复** | 支持自动重启（默认行为） | 自身无重启机制 | | **日志管理** | 重定向错误日志到文件（通过`--log-error`选项） | 依赖启动参数配置日志 | ### 详细解析 #### 1. **启动流程差异** - **通过`mysqld_safe`启动**（生产环境标准方式）： ```bash /bin/sh /path/to/mysqld_safe --defaults-file=/etc/my.cnf ``` 该脚本会： - 解析配置文件（如`my.cnf`） - 设置环境变量（如`LD_LIBRARY_PATH`） - 用`nohup`启动`mysqld`并脱离终端（引用[3]）： ```bash nohup /path/to/mysqld ... > /dev/null 2>&1 & ``` - 持续监控`mysqld`进程状态（引用[1]） - **直接运行`mysqld`**（仅限调试）： ```bash /path/to/mysqld --defaults-file=/etc/my.cnf ``` - 进程直接在前台运行（占用终端） - 崩溃后不会自动重启 - 日志输出直接到终端（除非手动重定向） #### 2. **监控与容错机制** - `mysqld_safe` 会监控子进程 `mysqld` 的状态。如果 `mysqld` 意外终止（如段错误），`mysqld_safe` 会自动重启它（引用[4]展示了重启失败场景）。 - 直接运行 `mysqld` 无此保护——进程退出后服务即中断。 #### 3. **日志与错误处理** - `mysqld_safe` 强制将 `mysqld` 的标准错误（stderr）重定向到日志文件（通过 `--log-error` 指定位置），这是生产环境的关键特性（引用[4]中的错误日志路径为`/var/log/mysqld.log`）。 - 直接运行 `mysqld` 时，错误信息默认打印到控制台（除非显式配置日志文件）。 #### 4. **环境配置** - `mysqld_safe` 会在启动前设置必要的运行时环境（如库路径、核心文件生成配置），而直接运行 `mysqld` 需手动配置（引用[2]中提到的`--basedir`、`--datadir`等参数）。 --- ### 为什么生产环境必须用`mysqld_safe`？ 1. **高可用保障**：自动重启机制避免服务长时间中断。 2. **日志集中管理**：确保错误日志持久化存储（关键于故障排查）。 3. **安全隔离**：通过`--user`选项以非root身份运行`mysqld`（引用[3]中`--user=mysql`）。 > **注意**：在MySQL 5.7+版本中，官方推荐使用`systemd`管理服务（如`systemctl start mysqld`），其底层仍调用`mysqld_safe`或直接集成其功能[^5]。 --- ### 操作示例：如何查看进程树 ```bash $ pstree -p | grep mysql |-mysqld_safe(6488)---mysqld(3324)-+-{mysqld}(3326) |-{mysqld}(3327) ... ``` - 进程ID 6488：`mysqld_safe`（父进程） - 进程ID 3324：`mysqld`（子进程） --- ### 常见问题分析 **Q: 为什么`mysqld_safe`会报`Killed`错误？** 如引用[4]所示： ```log /usr/bin/mysqld_safe: line 183: 23638 Killed ... ``` 原因：底层`mysqld`进程被系统杀死（通常因OOM或手动`kill -9`）。此时`mysqld_safe`会尝试重启，但若资源不足将循环失败。 --- §§相关问题§§ 1. 如何配置`mysqld_safe`的自动重启策略？ 2. 在`systemd`管理的系统中，`mysqld_safe`是否仍然需要？ 3. `mysqld_safe`和`mysqld`的内存使用关系是怎样的？ 4. 如何诊断`mysqld_safe`频繁重启`mysqld`的问题？</think>### MySQL 中 `mysqld_safe` 与 `mysqld` 进程的区别解析 #### 一、核心区别概览 | **特性** | **`mysqld_safe`** | **直接运行 `mysqld`** | |------------------|-------------------------------------------------|----------------------------------------| | **进程性质** | 守护进程脚本（Shell脚本） | 数据库主进程（二进制程序） | | **主要功能** | 启动/监控/重启 `mysqld`，提供安全保护 | 实际执行数据库操作（SQL处理、存储等） | | **运行方式** | 通过 `/bin/sh` 解释执行 | 直接执行二进制文件 | | **进程关系** | `mysqld_safe` 是 `mysqld` 的父进程（引用[1][3]） | 无父进程保护 | | **崩溃恢复** | 支持自动重启（核心功能） | 崩溃后直接退出 | | **日志管理** | 自动重定向错误日志（引用[4]） | 需手动配置日志输出 | --- #### 二、详细功能对比 1. **`mysqld_safe` 的核心作用** - **进程监控与重启** 持续监控 `mysqld` 状态，在其崩溃时自动重启（引用[4]中体现的容错机制）： ```bash while true; do mysqld "$@" & # 启动mysqld wait $! # 监控退出状态 [ $? -eq 0 ] && break # 正常退出则终止循环 sleep 2 # 异常退出时等待后重启 done ``` - **安全增强** 强制以非root用户运行（通过 `--user=mysql` 参数，引用[3]），降低权限风险。 2. **`mysqld` 的核心作用** - **数据库引擎** 直接处理SQL查询、事务管理、数据存储等核心功能。 - **配置加载** 解析 `my.cnf` 配置文件，初始化存储引擎和内存池。 --- #### 三、启动流程差异（以标准服务启动为例） ```mermaid graph TD A[/etc/init.d/mysql start] --> B[调用 mysqld_safe 脚本] B --> C[/bin/sh 解释执行 mysqld_safe] C --> D[加载环境变量和配置] D --> E[用 nohup 启动 mysqld 进程] E --> F[持续监控 mysqld 状态] F -- 崩溃 --> E F -- 正常退出 --> G[结束] ``` > **关键点**： > - 直接运行 `mysqld` 会跳过蓝色流程（监控/保护层） > - 生产环境必须通过 `mysqld_safe` 启动（引用[1][3]） --- #### 四、典型场景分析 1. **崩溃恢复场景**（引用[4]） ```log /usr/bin/mysqld_safe: line 183: 23638 Killed MySQL Daemon failed to start. Starting mysqld: [FAILED] ``` - `mysqld_safe` 检测到 `mysqld` 被 `kill -9` 强制终止 - 尝试重启失败后抛出错误（若直接运行 `mysqld` 则无此提示） 2. **版本切换场景**（引用[2]） 通过 `--mysqld-version=max` 启动定制版本： ```bash mysqld_safe --mysqld-version=max # 实际启动 mysqld-max ``` --- #### 五、生产环境实践建议 1. **必须使用 `mysqld_safe` 的场景** - 高可用部署（需自动恢复） - 安全合规要求（非root用户运行） - 日志集中管理需求 2. **直接运行 `mysqld` 的调试场景** ```bash # 仅用于调试（无保护机制） /usr/sbin/mysqld --console --debug ``` > **总结**：`mysqld_safe` 是 MySQL 服务的安全守护层，提供关键的保护和运维功能；而 `mysqld` 是实际执行数据库操作的引擎进程。两者协同构成完整的 MySQL 服务[^1][^3]。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值