MySQL内存使用的查看方式详解

前言

本文主要给大家介绍了关于MySQL内存使用查看的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧

使用版本:MySQL 5.7

官方文档

在performance_schema有如下表记录内存使用情况

mysql> show tables like '%memory%summary%';
+-------------------------------------------------+
| Tables_in_performance_schema (%memory%summary%) |
+-------------------------------------------------+
| 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  |
+-------------------------------------------------+

每个内存统计表都有如下统计列:

* COUNT_ALLOC,COUNT_FREE:对内存分配和释放内存函数的调用总次数

* SUM_NUMBER_OF_BYTES_ALLOC,SUM_NUMBER_OF_BYTES_FREE:已分配和已释放的内存块的总字节大小

* CURRENT_COUNT_USED:这是一个便捷列,等于COUNT_ALLOC - COUNT_FREE

* CURRENT_NUMBER_OF_BYTES_USED:当前已分配的内存块但未释放的统计大小。这是一个便捷列,等于SUM_NUMBER_OF_BYTES_ALLOC - SUM_NUMBER_OF_BYTES_FREE

* LOW_COUNT_USED,HIGH_COUNT_USED:对应CURRENT_COUNT_USED列的低和高水位标记

* LOW_NUMBER_OF_BYTES_USED,HIGH_NUMBER_OF_BYTES_USED:对应CURRENT_NUMBER_OF_BYTES_USED列的低和高水位标记

内存统计表允许使用TRUNCATE TABLE语句。使用truncate语句时有如下行为:

* 通常,truncate操作会重置统计信息的基准数据(即清空之前的数据),但不会修改当前server的内存分配等状态。也就是说,truncate内存统计表不会释放已分配内存

* 将COUNT_ALLOC和COUNT_FREE列重置,并重新开始计数(等于内存统计信息以重置后的数值作为基准数据)

* SUM_NUMBER_OF_BYTES_ALLOC和SUM_NUMBER_OF_BYTES_FREE列重置与COUNT_ALLOC和COUNT_FREE列重置类似

* LOW_COUNT_USED和HIGH_COUNT_USED将重置为CURRENT_COUNT_USED列值

*  LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重置为CURRENT_NUMBER_OF_BYTES_USED列值

* 此外,按照帐户,主机,用户或线程分类统计的内存统计表或memory_summary_global_by_event_name表,如果在对其依赖的accounts、hosts、users表执行truncate时,会隐式对这些内存统计表执行truncate语句

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

mysql> select event_name,current_alloc from sys.memory_global_by_current_bytes limit 10;
+-----------------------------------------------------------------------------+---------------+
| event_name         | current_alloc |
+-----------------------------------------------------------------------------+---------------+
| memory/performance_schema/events_statements_history_long   | 13.66 MiB |
| memory/performance_schema/events_statements_history_long.sqltext  | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.tokens  | 9.77 MiB |
| memory/performance_schema/events_statements_summary_by_digest.tokens | 9.77 MiB |
| memory/performance_schema/table_handles     | 9.06 MiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 8.67 MiB |
| memory/sql/String::value       | 6.02 MiB |
| memory/performance_schema/memory_summary_by_thread_by_event_name  | 5.62 MiB |
| memory/performance_schema/events_statements_summary_by_digest  | 4.88 MiB |
| memory/sql/TABLE        | 4.35 MiB |
+-----------------------------------------------------------------------------+---------------+

默认情况下performance_schema只对performance_schema进行了内存开销的统计。根据你的MySQL安装代码区域可能包括performance_schema、sql、client、innodb、myisam、csv、memory、blackhole、archive、partition和其他。

查看innodb相关的内存监控是否开启,默认不开启

mysql> SELECT * FROM performance_schema.setup_instruments
 -> WHERE NAME LIKE '%memory%';
+--------------------------------------------------------------------------------+---------+-------+
| NAME          | ENABLED | TIMED |
+--------------------------------------------------------------------------------+---------+-------+
| memory/performance_schema/mutex_instances     | YES | NO |
| memory/performance_schema/rwlock_instances     | YES | NO |
| memory/performance_schema/cond_instances     | YES | NO |
| memory/performance_schema/file_instances     | YES | NO |
| memory/performance_schema/socket_instances     | YES | NO |
| memory/performance_schema/metadata_locks     | YES | NO |
| memory/performance_schema/file_handle      | YES | NO |
| memory/performance_schema/accounts      | YES | NO |
| memory/performance_schema/events_waits_summary_by_account_by_event_name | YES | NO |
| memory/performance_schema/events_stages_summary_by_account_by_event_name | YES | NO |
| memory/performance_schema/events_statements_summary_by_account_by_event_name | YES | NO |
| memory/performance_schema/events_transactions_summary_by_account_by_event_name | YES | NO |
| memory/performance_schema/memory_summary_by_account_by_event_name  | YES | NO |
| memory/performance_schema/events_stages_summary_global_by_event_name  | YES | NO |
| memory/performance_schema/events_statements_summary_global_by_event_name | YES | NO |
| memory/performance_schema/memory_summary_global_by_event_name   | YES | NO |
| memory/performance_schema/hosts      | YES | NO |
| memory/performance_schema/events_waits_summary_by_host_by_event_name  | YES | NO |
| memory/performance_schema/events_stages_summary_by_host_by_event_name  | YES | NO |
| memory/performance_schema/events_statements_summary_by_host_by_event_name | YES | NO |
| memory/performance_schema/events_transactions_summary_by_host_by_event_name | YES | NO |

可以通过条件缩小范围:

mysql> SELECT * FROM performance_schema.setup_instruments
 WHERE NAME LIKE '%memory/innodb%';
+-------------------------------------------+---------+-------+
| NAME     | ENABLED | TIMED |
+-------------------------------------------+---------+-------+
| memory/innodb/adaptive hash index  | NO | NO |
| memory/innodb/buf_buf_pool  | NO | NO |
| memory/innodb/dict_stats_bg_recalc_pool_t | NO | NO |
| memory/innodb/dict_stats_index_map_t | NO | NO |
| memory/innodb/dict_stats_n_diff_on_level | NO | NO |
| memory/innodb/other   | NO | NO |
| memory/innodb/row_log_buf   | NO | NO |
| memory/innodb/row_merge_sort  | NO | NO |
| memory/innodb/std    | NO | NO |
| memory/innodb/trx_sys_t::rw_trx_ids | NO | NO |

对所有可能的对象进行内存监控。因此,还需要做下面的设置:

mysql> update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';
Query OK, 306 rows affected (0.00 sec)
Rows matched: 376 Changed: 306 Warnings: 0

但是这种在线打开内存统计的方法仅对之后新增的内存对象有效,重启数据库后又会还原设置:

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

[mysqld]
performance-schema-instrument='memory/%=COUNTED'

可以使用sys库下的memory_global_by_current_bytes表来查询相同的底层数据,该模式表显示了全局服务器内当前内存使用情况,按分配类型进行细分。

mysql> SELECT * FROM sys.memory_global_by_current_bytes
 WHERE event_name LIKE 'memory/innodb/buf_buf_pool'\G
*************************** 1. row ***************************
 event_name: memory/innodb/buf_buf_pool
 current_count: 1
 current_alloc: 131.06 MiB
current_avg_alloc: 131.06 MiB
 high_count: 1
 high_alloc: 131.06 MiB
 high_avg_alloc: 131.06 MiB

此sys模式查询通过current_alloc()代码区域聚合当前分配的内存:

mysql> SELECT SUBSTRING_INDEX(event_name,'/',2) AS
 code_area, sys.format_bytes(SUM(current_alloc))
 AS current_alloc
 FROM sys.x$memory_global_by_current_bytes
 GROUP BY SUBSTRING_INDEX(event_name,'/',2)
 ORDER BY SUM(current_alloc) DESC;
+---------------------------+---------------+
| code_area   | current_alloc |
+---------------------------+---------------+
| memory/innodb  | 843.24 MiB |
| memory/performance_schema | 81.29 MiB |
| memory/mysys  | 8.20 MiB |
| memory/sql  | 2.47 MiB |
| memory/memory  | 174.01 KiB |
| memory/myisam  | 46.53 KiB |
| memory/blackhole  | 512 bytes |
| memory/federated  | 512 bytes |
| memory/csv  | 512 bytes |
| memory/vio  | 496 bytes |
+---------------------------+---------------+

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对我们的支持。

(0)

相关推荐

  • Mysql5.6启动内存占用过高解决方案

    vps的内存为512M,安装好nginx,php等启动起来,mysql死活启动不起来看了日志只看到对应pid被结束了,后跟踪看发现是内存不足被killed; 调整my.cnf 参数,重新配置(系统默认配置太高直接占用400M内存,小玩家玩不起呢)即可 performance_schema_max_table_instances=200 table_definition_cache=200 table_open_cache=128 下面附一个相关的my.cnf配置文件的说明 [client] po

  • MySQL大内存配置方案 如my-medium.ini、my-huge.ini等

    MySql noinstall-5.1.xx-win32 配置(原创) 1.解压mysql-noinstall-5.1.xx-win32.zip 到你喜欢的目录,例如:d:\php\mysql 2.在根目录d:\php\mysql中有五个配置信息文件: my-small.ini (内存 <= 64M) my-medium.ini (内存 128M ) my-large.ini (内存 512M) my-huge.ini (内存 1G-2G) my-innodb-heavy-4G.ini (内存

  • MySQL 5.5.49 大内存优化配置文件优化详解

    一.配置文件说明 my-small.cnf my-medium.cnf my-large.cnf my-huge.cnf my-innodb-heavy-4G.cnf 二.详解 my-innodb-heavy-4G.cnf 三.配置文件优化 注:环境说明,CentO5.5 x86_64+MySQL-5.5.32 相关软件下载:http://yunpan.cn/QtaCuLHLRKzRq 一.配置文件说明 Mysql-5.5.49是Mysql5.5系列中最后一个版本,也是最后一个有配置文件的版本,

  • MySQL占用内存较大与CPU过高测试与解决办法

    更改后如下: innodb_buffer_pool_size=576M ->256M InnoDB引擎缓冲区占了大头,首要就是拿它开刀 query_cache_size=100M ->16M 查询缓存 tmp_table_size=102M ->64M 临时表大小 key_buffer_size=256m ->32M 重启mysql服务后,虚拟内存降到200以下. 另外mysql安装目录下有几个文件:my-huge.ini .my-large.ini.my-medium.ini..

  • MySql减少内存占用的方法详解

    前言 默认设置下,mysql会初始化很大的内存块用于缓存数据库查询数据. 但我的小主机只有640mb的内存,top查询发现他吃了我30% 的内存总量,差不多200MB. 但这个数据库里只有几MB的数据,感觉这设置很不合理. 经过爬文,终于把内存占用降到了128MB 实现方法 直接修改 /etc/mysql/mysql.conf.d/mysqld.cnf 在配置末尾追加如下配置 performance_schema_max_table_instances=150 table_definition_

  • mysql服务性能优化—my.cnf_my.ini配置说明详解(16G内存)

    此配置是老男孩生产线上使用的配置,在培训的时候,他给的,我在这里,对各参数添加了中文说明 这配置已经优化的不错了,如果你的mysql没有什么特殊情况的话,可以直接使用该配置参数 MYSQL服务器my.cnf配置文档详解 硬件:内存16G [client] port = 3306 socket = /data/3306/mysql.sock [mysql] no-auto-rehash [mysqld] user = mysql port = 3306 socket = /data/3306/my

  • MySQL内存使用的查看方式详解

    前言 本文主要给大家介绍了关于MySQL内存使用查看的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧 使用版本:MySQL 5.7 官方文档 在performance_schema有如下表记录内存使用情况 mysql> show tables like '%memory%summary%'; +-------------------------------------------------+ | Tables_in_performance_schema (%memor

  • Python写入MySQL数据库的三种方式详解

    目录 场景一:数据不需要频繁的写入mysql 场景二:数据是增量的,需要自动化并频繁写入mysql 方式一 方式二 总结 大家好,Python 读取数据自动写入 MySQL 数据库,这个需求在工作中是非常普遍的,主要涉及到 python 操作数据库,读写更新等,数据库可能是 mongodb. es,他们的处理思路都是相似的,只需要将操作数据库的语法更换即可. 本篇文章会给大家分享数据如何写入到 mysql,分为两个场景,三种方式. 场景一:数据不需要频繁的写入mysql 使用 navicat 工

  • mysql备份的三种方式详解

    一.备份的目的 做灾难恢复:对损坏的数据进行恢复和还原需求改变:因需求改变而需要把数据还原到改变以前测试:测试新功能是否可用 二.备份需要考虑的问题 可以容忍丢失多长时间的数据:恢复数据要在多长时间内完: 恢复的时候是否需要持续提供服务:恢复的对象,是整个库,多个表,还是单个库,单个表. 三.备份的类型 1.根据是否需要数据库离线 冷备(cold backup):需要关mysql服务,读写请求均不允许状态下进行:温备(warm backup): 服务在线,但仅支持读请求,不允许写请求:热备(ho

  • 深入C/C++浮点数在内存中的存储方式详解

    任何数据在内存中都是以二进制的形式存储的,例如一个short型数据1156,其二进制表示形式为00000100 10000100.则在Intel CPU架构的系统中,存放方式为  10000100(低地址单元) 00000100(高地址单元),因为Intel CPU的架构是小端模式.但是对于浮点数在内存是如何存储的?目前所有的C/C++编译器都是采用IEEE所制定的标准浮点格式,即二进制科学表示法.在二进制科学表示法中,S=M*2^N 主要由三部分构成:符号位+阶码(N)+尾数(M).对于flo

  • 为何不要在MySQL中使用UTF-8编码方式详解

    MySQL的UTF-8编码方式 MySQL 从 4.1 版本开始支持 UTF-8,也就是 2003 年,然而目前流行的UTF-8 标准(RFC 3629)是在此之后规定的.正因此,才造就了MySQL中的UTF-8与我们日常开发中的UTF-8不一致,从到导致了些问题.MySQL的UTF-8只支持每个字符最多三个字节,而真正的 UTF-8 是每个字符最多四个字节. 问题复现 有数据库表如下:utf8编码方式 往数据库存一条记录: @Test public void testInsert() { Us

  • keras 两种训练模型方式详解fit和fit_generator(节省内存)

    第一种,fit import keras from keras.models import Sequential from keras.layers import Dense import numpy as np from sklearn.preprocessing import LabelEncoder from sklearn.preprocessing import OneHotEncoder from sklearn.model_selection import train_test_s

  • MySql二进制连接方式详解

    使用mysql二进制方式连接 您可以使用MySQL二进制方式进入到mysql命令提示符下来连接MySQL数据库. 实例 以下是从命令行中连接mysql服务器的简单实例: 复制代码 代码如下: [root@host]# mysql -u root -p Enter password:****** 在登录成功后会出现 mysql> 命令提示窗口,你可以在上面执行任何 SQL 语句. 以上命令执行后,登录成功输出结果如下: Welcome to the MySQL monitor. Commands

  • 查看当前mysql使用频繁的sql语句(详解)

    #mysql -uroot -p 输入密码 mysql> show full processlist;    查看完全的SQL语句 mysql> show processlist;         查看整体情况 这样子可以针对SQL语句进行优化. 以上这篇查看当前mysql使用频繁的sql语句(详解)就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持我们.

  • MySql各种查询方式详解

    目录 新增 聚合查询 分组查询 条件查询 联合查询 自连接 合并查询 新增 insert into B select * from A://将A表的信息通过查询新增到B表中去 聚合查询 count://返回到查询的数据总和 sum://返回到查询的数据总和(只对数字有意义) 只对数字有意义 avg/max/min;//返回查询数据的平均值/最大值/最小值(只对数字有意义) 分组查询 select * from 表名 group by 分组条件: 这里是先执行分组,再根据分组执行每个组的聚合函数.

  • MySql连接查询方式详解

    目录 1. 什么是连接查询 2. 连接查询的方式 3. 内连接 1. 等值连接 2. 非等值连接 3. 自连接 4. 外连接 1. 右外连接 2. 左外连接 5. 多张表(两张以上)连接 1. 什么是连接查询 从一张表中单独查询,称为单表查询. 跨表查询,多张表联合其来查询,称为连接查询. 2. 连接查询的方式 内连接: 等值连接 非等值连接 自连接 外连接: 左外连接(左连接) 右外连接(右连接) 当对多张表进行查询,没有任何限制的时候,返回的值是笛卡尔积 3. 内连接 1. 等值连接 查询每

随机推荐