当前位置: 主页 > JAVA语言

java如何排查内存泄露-PeterZaitsev如何使用内存该文章中有很多有用的技巧

发布时间:2023-06-22 09:15   浏览次数:次   作者:佚名

Troubleshooting

对crash的数据库进行故障分析并不是一件快乐的事情,尤其是 MySQL 的日志中没有提供 crash 原因的情形。比如当 MySQL 内存耗尽。在 2012年 Peter Zaitsev 写了一篇文章 分析MySQL如何使用内存

该文章中有很多有用的技巧。使用新版本的 MySQL (5.7+) 和 performance_schema,我们能够更轻松地解决 MySQL 内存分配问题。

在本文中,我将向您展示如何使用 P_S。

首先,MySQL由于内存不足而崩溃的主要情况有3种:

为MySQL 尝试分配比可用内存更多的内存,比如:没有正确设置 innodb_buffer_pool_size。这种场景比较容易修复。

服务器上还有一些其他进程可以分配 RAM。应用程序(Java、Python、PHP)、Web 服务器甚至备份进程(即 mysqldump)。如果确定问题的根源是这些进程导致的,修复起来就很简单了。

c 内存泄漏怎么排查_qt内存泄漏排查方法_java如何排查内存泄露

MySQL 内存泄漏。这是最坏的情况,我们需要进行故障排除。

二 从哪里开始排除 MySQL 内存泄漏

以下是我们可以开始的内容(假设它是 Linux 服务器):

2.1 检查Linux 操作系统java如何排查内存泄露,配置文件和参数

通过检查 MySQL 错误日志和 Linux 日志文件(即 /var/log/messages 或 /var/log/syslog)来识别崩溃。您可能会看到一个条目说 OOM Killer 杀死了 MySQL。每当 MySQL 被 OOM 杀死时,“dmesg”也会显示有关它周围情况的详细信息。

检查可用内存:

free -g

qt内存泄漏排查方法_c 内存泄漏怎么排查_java如何排查内存泄露

cat /proc/meminfo

使用命令 top 或 htop 检查哪些应用程序正在使用 RAM(参见常驻内存与虚拟内存)

检查MySQL配置:检查/etc/my.cnf或一般的/etc/my*(包括/etc/mysql/*等文件)。MySQL 可能使用不同的 my.cnf( run ps ax| grep mysql ) 运行。

运行 vmstat 5 5 以 查看系统是否通过虚拟内存进行读/写以及是否正在交换。

对于非生产环境,我们可以使用其他工具(如Valgrind、gdb等)来检查MySQL的使用情况。

2.2 检查 MySQL 内部

现在我们可以通过MySQL运行机制以便查找潜在的内存泄漏因素。MySQL 在很多地方分配内存,尤其是:

qt内存泄漏排查方法_c 内存泄漏怎么排查_java如何排查内存泄露

表缓存

启用 Performance_schema功能

show engine performance_schema status 并查看最后一行。

InnoDB(运行 show engine innodb status 并检查缓冲池部分,为 buffer_pool 和相关缓存分配的内存)

在内存中的临时表(找到运行内存中的所有表:select * from information_schema.tables where engine='MEMORY')

Prepared 语句,当它没有被解除分配时(通过运行 show global status like 检查通过解除分配命令准备的命令的数量 Com_prepare_sql;

show global status like 'Com_dealloc_sql'

java如何排查内存泄露_c 内存泄漏怎么排查_qt内存泄漏排查方法

好消息是从 5.7 开始,我们可以基于 performance_schema 查询内存使用情况。如何使用呢?

开启收集内存的统计信息

UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%';

执行sql

select event_name, current_alloc, high_alloc from sys.memory_global_by_current_bytes where current_count > 0;

通常情况下,第二部的结果集会展示具体的代码模块使用了比较多的内存。它通常是不言自明的,我们可以搜索mysql的bugs 或者可以去检查 MySQL 源代码。

举个例子java如何排查内存泄露, ,这篇文章展示了 mysql为触发器分配了过多的内存。

c 内存泄漏怎么排查_qt内存泄漏排查方法_java如何排查内存泄露

mysql> select event_name, current_alloc, high_alloc from memory_global_by_current_bytes where current_count > 0;
+--------------------------------------------------------------------------------+---------------+-------------+
| event_name | current_alloc | high_alloc |
+--------------------------------------------------------------------------------+---------------+-------------+
| memory/innodb/buf_buf_pool | 7.29 GiB | 7.29 GiB |
| memory/sql/sp_head::main_mem_root | 3.21 GiB | 3.62 GiB |
...

虽然 buf_buf_pool 占用了7G ,但是系统依然为存储过程对象分配3G内存,显然分配的内存太大了。根据文档描述 sp_head 代表这个存储程序的一个实例,它可能是任何类型(存储过程、函数、触发器、事件)。在上述情况下,这个mysql有潜在的内存泄漏。

注意:

其实官方并不承认 存储过程对象导致内存使用量持续增加是个bug。官方给的建议是调整参数 table_open_cache_instances。

另外我们可以通过如下语句 查看具体是哪个模块在消耗大量内存。

mysql> select substring_index(
-> substring_index(event_name, '/', 2),
-> '/',
-> -1
-> ) as event_type,
-> round(sum(CURRENT_NUMBER_OF_BYTES_USED)/1024/1024, 2) as MB_CURRENTLY_USED
-> from performance_schema.memory_summary_global_by_event_name
-> group by event_type
-> having MB_CURRENTLY_USED>0;
+--------------------+-------------------+
| event_type | MB_CURRENTLY_USED |
+--------------------+-------------------+
| innodb | 0.61 |
| memory | 0.21 |
| performance_schema | 106.26 |
| sql | 0.79 |
+--------------------+-------------------+
4 rows in set (0.00 sec)

三 小结