-
mysql查看线程占用内存_MySQL查看线程内存占用情况
2021-01-26 20:11:101.背景内存使用情况，决定着...2.资源检查在操作系统层面，可以通过free命令查看系统内存资源使用情况，通过top -c命令查看进程使用内存占用情况。root:~# free -mttotal used free shared buff/cache available...展开全文1.背景
内存使用情况，决定着MySQL的性能，内存使用率过高会使系统响应时间变长，严重时内存耗尽还会出现OOM的情况。
2.资源检查
在操作系统层面，可以通过free命令查看系统内存资源使用情况，通过top -c命令查看进程使用内存占用情况。
root:~# free -mt
total used free shared buff/cache available
Mem: 16046 14928 201 13 917 753
Swap: 0 0 0
Total: 16046 14928 201
free命令显示内存占用情况：
总内存： 16046MB ≈ 16GB
已用内存： 14928MB ≈ 14.9GB
可用内存： free + buff/cache = 1118MB ≈ 1.1GB
即可用内存比例： 1.1GB / 16GB = 6.8%，通常我们系统监控内存低于10%就会告警。
查看系统进程，检查内存占用情况。
top - 16:11:01 up 71 days, 7:23, 1 user, load average: 0.09, 0.07, 0.20
Tasks: 188 total, 1 running, 187 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.1 us, 0.6 sy, 0.0 ni, 97.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16431688 total, 208716 free, 15291936 used, 931036 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 766408 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6626 mysql 20 0 16.064g 0.014t 6436 S 12.0 91.0 66694:13 /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --basedir=/usr/local/mysql --datadir=/data/mysql --plugin-dir=/usr/local/mysql/lib/plugin --user=mysq+
通过top -c命令发现mysql进程占用内存%MEM (91.0%)，接下来检查下mysql是哪些线程和事件占用较高内存的。 首先检查实例的共享内存分配情况几个参数配置：
共享内存
mysql> select VARIABLE_NAME, VARIABLE_VALUE, concat(VARIABLE_VALUE/1024/1024,' MB') AS VARIABLE_VALUE_MB from information_schema.SESSION_VARIABLES where variable_name in ('innodb_buffer_pool_size','innodb_log_buffer_size','innodb_additional_mem_pool_size','key_buffer_size','query_cache_size');
+-------------------------+----------------+-------------------+
| VARIABLE_NAME | VARIABLE_VALUE | VARIABLE_VALUE_MB |
+-------------------------+----------------+-------------------+
| KEY_BUFFER_SIZE | 33554432 | 32 MB |
| QUERY_CACHE_SIZE | 1048576 | 1 MB |
| INNODB_LOG_BUFFER_SIZE | 67108864 | 64 MB |
| INNODB_BUFFER_POOL_SIZE | 10737418240 | 10240 MB |
+-------------------------+----------------+-------------------+
4 rows in set, 1 warning (0.00 sec)
检查了Innodb buffer的内存参数设置值10240MB = 10G， 占总内存 10G/16GB = 62.5%，该值设置在合理的范围内，详细的参数介绍可以参考官方文档，当系统内存严重不足时， 快速恢复可以降低共享内存，调整该参数后，内存会立马释放：
mysql> set global innodb_buffer_pool_size=8589934592;
Query OK, 0 rows affected (0.00 sec)
mysql> select VARIABLE_NAME, VARIABLE_VALUE, concat(VARIABLE_VALUE/1024/1024,' MB') AS VARIABLE_VALUE_MB from information_schema.SESSION_VARIABLES where variable_name in ('innodb_buffer_pool_size','innodb_log_buffer_size','innodb_additional_mem_pool_size','key_buffer_size','query_cache_size');
+-------------------------+----------------+-------------------+
| VARIABLE_NAME | VARIABLE_VALUE | VARIABLE_VALUE_MB |
+-------------------------+----------------+-------------------+
| KEY_BUFFER_SIZE | 33554432 | 32 MB |
| QUERY_CACHE_SIZE | 1048576 | 1 MB |
| INNODB_LOG_BUFFER_SIZE | 67108864 | 64 MB |
| INNODB_BUFFER_POOL_SIZE | 8589934592 | 8192 MB |
+-------------------------+----------------+-------------------+
4 rows in set, 1 warning (0.00 sec)
mysql> system free -mt
total used free shared buff/cache available
Mem: 16046 13020 2081 13 944 2666
Swap: 0 0 0
Total: 16046 13020 2081
这里我们为了快速释放系统内存，调整了INNODB_BUFFER_POOL_SIZE值后，可用内存恢复2G。
Session私有内存
共享内存中介绍的内存空间是实例创建时即分配的内存空间，并且是所有连接共享的。而出现 OOM 异常的实例通常都是由于下面各个连接私有的内存造成的。
mysql> select VARIABLE_NAME, VARIABLE_VALUE, concat(VARIABLE_VALUE/1024/1024,' MB') AS VARIABLE_VALUE_MB from information_schema.SESSION_VARIABLES where variable_name in ('read_buffer_size','read_rnd_buffer_size','sort_buffer_size','join_buffer_size','binlog_cache_size','tmp_table_size');
+----------------------+----------------+-------------------+
| VARIABLE_NAME | VARIABLE_VALUE | VARIABLE_VALUE_MB |
+----------------------+----------------+-------------------+
| SORT_BUFFER_SIZE | 33554432 | 32 MB |
| READ_RND_BUFFER_SIZE | 33554432 | 32 MB |
| READ_BUFFER_SIZE | 16777216 | 16 MB |
| BINLOG_CACHE_SIZE | 32768 | 0.03125 MB |
| TMP_TABLE_SIZE | 67108864 | 64 MB |
| JOIN_BUFFER_SIZE | 134217728 | 128 MB |
+----------------------+----------------+-------------------+
6 rows in set, 1 warning (0.00 sec)
这里的私有内存JOIN_BUFFER_SIZE=128MB， 默认值是256KB。用于普通索引扫描、范围索引扫描和不使用索引而执行全表扫描的联接的缓冲区的最小大小。通常获得快速连接的最佳方法是添加索引。在无法添加索引时，增加join_buffer_size的值，以获得更快的完全连接。为两个表之间的每个完整连接分配一个连接缓冲区。对于没有使用索引的几个表之间的复杂联接，可能需要多个联接缓冲区。
除非使用块嵌套循环或批处理键访问算法，否则设置大于保存每个匹配行所需的缓冲区不会有任何好处，并且所有连接至少分配最小的大小，因此在全局将该变量设置为大值时要小心。最好保持全局设置较小，只在执行大型连接的会话中将会话设置更改为较大的值。如果全局大小大于使用它的大多数查询所需要的大小，那么内存分配时间可能会导致显著的性能下降。
通过检查私有内存，我们发现这是的JOIN_BUFFER_SIZE全局设置较大。
内存监控
MySQL5.7版本通过performance_schema可以方便的查看内存占用情况， 前提是要打开监控，执行如下SQL语句，打开内存监控。
mysql> update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';
mysql> select * from performance_schema.setup_instruments where name like 'memory%innodb%' limit 20;
+-------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+-------------------------------------------+---------+-------+
| memory/innodb/adaptive hash index | YES | NO |
| memory/innodb/buf_buf_pool | YES | NO |
| memory/innodb/dict_stats_bg_recalc_pool_t | YES | NO |
| memory/innodb/dict_stats_index_map_t | YES | NO |
| memory/innodb/dict_stats_n_diff_on_level | YES | NO |
| memory/innodb/other | YES | NO |
| memory/innodb/row_log_buf | YES | NO |
| memory/innodb/row_merge_sort | YES | NO |
| memory/innodb/std | YES | NO |
| memory/innodb/trx_sys_t::rw_trx_ids | YES | NO |
| memory/innodb/partitioning | YES | NO |
| memory/innodb/api0api | YES | NO |
| memory/innodb/btr0btr | YES | NO |
| memory/innodb/btr0bulk | YES | NO |
| memory/innodb/btr0cur | YES | NO |
| memory/innodb/btr0pcur | YES | NO |
| memory/innodb/btr0sea | YES | NO |
| memory/innodb/buf0buf | YES | NO |
| memory/innodb/buf0dblwr | YES | NO |
| memory/innodb/buf0dump | YES | NO |
+-------------------------------------------+---------+-------+
20 rows in set (0.00 sec)
该命令是在线打开内存统计，所以只会统计打开后新增的内存对象，打开前的内存对象不会统计，建议您打开后等待一段时间再执行后续步骤，便于找出内存使用高的线程。
内存相关表
这里我们查看performance_schema相关的内存监控表有哪些，分别可以统计哪些信息。
mysql> show tables like '%memory%';
+-----------------------------------------+
| Tables_in_performance_schema (%memory%) |
+-----------------------------------------+
| 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 |
+-----------------------------------------+
5 rows in set (0.00 sec)
以上表的监控统计，分别统计线程、帐户、用户、主机间接执行内存操作等信息，每个内存汇总表都有一个或多个分组列，用于指示表如何聚合事件，参考如下表介绍：
表名
说明
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
每个事件名的全局内存操作
(一)统计事件消耗内存
mysql> select event_name, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_global_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc LIMIT 10;
+---------------------------------------+---------------------------+
| event_name | SUM_NUMBER_OF_BYTES_ALLOC |
+---------------------------------------+---------------------------+
| memory/sql/JOIN_CACHE | 966665202302976 |
| memory/memory/HP_PTRS | 304457132043176 |
| memory/innodb/mem0mem | 29273314618616 |
| memory/sql/thd::main_mem_root | 18376092762472 |
| memory/sql/Filesort_buffer::sort_keys | 3155343016712 |
| memory/sql/String::value | 2708659513792 |
| memory/sql/test_quick_select | 2146347475648 |
| memory/sql/QUICK_RANGE_SELECT::alloc | 1961041015680 |
| memory/mysys/IO_CACHE | 1463097599496 |
| memory/sql/TABLE | 635194922117 |
+---------------------------------------+---------------------------+
10 rows in set (0.01 sec)
注意到 “memory/sql/JOIN_CACHE” 消耗的内存最大。
(二)统计线程消耗内存
mysql> select thread_id, event_name, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_by_thread_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10;
+-----------+-----------------------+---------------------------+
| thread_id | event_name | SUM_NUMBER_OF_BYTES_ALLOC |
+-----------+-----------------------+---------------------------+
| 1922626 | memory/innodb/mem0mem | 1984233347055 |
| 1922439 | memory/innodb/mem0mem | 1404615671548 |
| 1954681 | memory/innodb/mem0mem | 1375641196768 |
| 1922431 | memory/innodb/mem0mem | 1350354644688 |
| 1954682 | memory/innodb/mem0mem | 1099479913383 |
| 1922625 | memory/innodb/mem0mem | 1097551130366 |
| 2686170 | memory/innodb/mem0mem | 992829979036 |
| 1922433 | memory/innodb/mem0mem | 874412348141 |
| 1922438 | memory/innodb/mem0mem | 863348539942 |
| 1922432 | memory/innodb/mem0mem | 754779357792 |
+-----------+-----------------------+---------------------------+
10 rows in set (0.02 sec)
上面统计结果发现到 “memory/innodb/mem0mem” 事件消耗的内存最多。
(三)统计账户消耗内存
mysql> select USER, HOST, EVENT_NAME, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_by_account_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10;
+-------------------+---------------+-----------------------+---------------------------+
| USER | HOST | EVENT_NAME | SUM_NUMBER_OF_BYTES_ALLOC |
+-------------------+---------------+-----------------------+---------------------------+
| c********** | 192.168.*.* | memory/sql/JOIN_CACHE | 638622579556352 |
| c********** | 192.168.*.* | memory/sql/JOIN_CACHE | 276949456912384 |
| b********** | 192.168.*.* | memory/memory/HP_PTRS | 166067384571544 |
| b********** | 192.168.*.* | memory/memory/HP_PTRS | 76145767762936 |
| b********** | 192.168.*.* | memory/sql/JOIN_CACHE | 42176612401152 |
| z********** | 192.168.*.* | memory/memory/HP_PTRS | 30219030003816 |
| s********** | 192.168.*.* | memory/innodb/mem0mem | 16114310343537 |
| b********** | 192.168.*.* | memory/sql/JOIN_CACHE | 9070736048128 |
| c********** | 192.168.*.* | memory/innodb/mem0mem | 4787044880366 |
| a********** | 192.168.*.* | memory/memory/HP_PTRS | 4764584763968 |
+-------------------+---------------+-----------------------+---------------------------+
10 rows in set (0.16 sec)
这里把相关敏感信息脱敏了，从上面发现用户 c* 占用内存最大。 事件还是memory/sql/JOIN_CACHE
(四)统计主机消耗内存
mysql > select HOST, EVENT_NAME, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_by_host_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10;
+---------------+-------------------------------+---------------------------+
| HOST | EVENT_NAME | SUM_NUMBER_OF_BYTES_ALLOC |
+---------------+-------------------------------+---------------------------+
| 192.168.*.* | memory/sql/JOIN_CACHE | 681148560703488 |
| 192.168.*.* | memory/sql/JOIN_CACHE | 286124345917440 |
| 192.168.*.* | memory/memory/HP_PTRS | 166777472915704 |
| 192.168.*.* | memory/memory/HP_PTRS | 76851688652536 |
| 192.168.*.* | memory/memory/HP_PTRS | 30227900416896 |
| 192.168.*.* | memory/innodb/mem0mem | 16117796446781 |
| 192.168.*.* | memory/memory/HP_PTRS | 7457591548256 |
| 192.168.*.* | memory/innodb/mem0mem | 6596914688112 |
| 192.168.*.* | memory/sql/thd::main_mem_root | 5979929501808 |
| 192.168.*.* | memory/sql/thd::main_mem_root | 4795924383312 |
+---------------+-------------------------------+---------------------------+
10 rows in set (0.07 sec)
通过上面的主机，也能快速定位是哪台主机占用内存大，有必要时可以重启该主机的应用。
(五)统计用户消耗内存
mysql> select USER, EVENT_NAME, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_by_user_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10;
+-------------------+-------------------------------+---------------------------+
| USER | EVENT_NAME | SUM_NUMBER_OF_BYTES_ALLOC |
+-------------------+-------------------------------+---------------------------+
| c**************** | memory/sql/JOIN_CACHE | 915572036468736 |
| b**************** | memory/memory/HP_PTRS | 242213179169888 |
| b**************** | memory/sql/JOIN_CACHE | 51247348449280 |
| z**************** | memory/memory/HP_PTRS | 30225123465960 |
| b**************** | memory/memory/HP_PTRS | 21863256050496 |
| s**************** | memory/innodb/mem0mem | 16116655699153 |
| e**************** | memory/sql/thd::main_mem_root | 9554995144176 |
| c**************** | memory/innodb/mem0mem | 6360931505366 |
| a**************** | memory/memory/HP_PTRS | 4765617785408 |
| s**************** | memory/sql/thd::main_mem_root | 3074066885016 |
+-------------------+-------------------------------+---------------------------+
10 rows in set (0.06 sec)
找到问题事件或线程后，您可以排查业务代码和环境，解决内存高的问题。上面统计结果发现到 “memory/sql/JOIN_CACHE” 事件消耗的内存最大。调整全局JOIN_BUFFER_SIZE=32MB，再观察内存占用情况。
mysql> set global join_buffer_size=33554432;
Query OK, 0 rows affected (0.00 sec)
mysql> quit
mysql> select VARIABLE_NAME, VARIABLE_VALUE, concat(VARIABLE_VALUE/1024/1024,' MB') AS VARIABLE_VALUE_MB from information_schema.SESSION_VARIABLES where variable_name in ('read_buffer_size','read_rnd_buffer_size','sort_buffer_size','join_buffer_size','binlog_cache_size','tmp_table_size');
+----------------------+----------------+-------------------+
| VARIABLE_NAME | VARIABLE_VALUE | VARIABLE_VALUE_MB |
+----------------------+----------------+-------------------+
| SORT_BUFFER_SIZE | 33554432 | 32 MB |
| READ_RND_BUFFER_SIZE | 33554432 | 32 MB |
| READ_BUFFER_SIZE | 16777216 | 16 MB |
| BINLOG_CACHE_SIZE | 32768 | 0.03125 MB |
| TMP_TABLE_SIZE | 67108864 | 64 MB |
| JOIN_BUFFER_SIZE | 33554432 | 32 MB |
+----------------------+----------------+-------------------+
6 rows in set, 1 warning (0.00 sec)
mysql> select * from information_schema.processlist where COMMAND='sleep' and Time>1000 order by Time desc;
这里会话参数调整后，需同时调整/etc/my.cnf的配置，下次服务启动永久生效，另外之前连接的会话线程由于已分配了该buffer大小，调整后内存并不会马上释放。
完。
-
检查mysql内存使用率_MySQL查看线程内存占用情况
2021-01-18 20:03:491.背景内存使用情况，决定着...2.资源检查在操作系统层面，可以通过free命令查看系统内存资源使用情况，通过top -c命令查看进程使用内存占用情况。root:~# free -mttotal used free shared buff/cache available...展开全文1.背景
内存使用情况，决定着MySQL的性能，内存使用率过高会使系统响应时间变长，严重时内存耗尽还会出现OOM的情况。
2.资源检查
在操作系统层面，可以通过free命令查看系统内存资源使用情况，通过top -c命令查看进程使用内存占用情况。
root:~# free -mt
total used free shared buff/cache available
Mem: 16046 14928 201 13 917 753
Swap: 0 0 0
Total: 16046 14928 201
free命令显示内存占用情况：
总内存： 16046MB ≈ 16GB
已用内存： 14928MB ≈ 14.9GB
可用内存： free + buff/cache = 1118MB ≈ 1.1GB
即可用内存比例： 1.1GB / 16GB = 6.8%，通常我们系统监控内存低于10%就会告警。
查看系统进程，检查内存占用情况。
top - 16:11:01 up 71 days, 7:23, 1 user, load average: 0.09, 0.07, 0.20
Tasks: 188 total, 1 running, 187 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.1 us, 0.6 sy, 0.0 ni, 97.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16431688 total, 208716 free, 15291936 used, 931036 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 766408 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6626 mysql 20 0 16.064g 0.014t 6436 S 12.0 91.0 66694:13 /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --basedir=/usr/local/mysql --datadir=/data/mysql --plugin-dir=/usr/local/mysql/lib/plugin --user=mysq+
通过top -c命令发现mysql进程占用内存%MEM (91.0%)，接下来检查下mysql是哪些线程和事件占用较高内存的。 首先检查实例的共享内存分配情况几个参数配置：
共享内存
mysql> select VARIABLE_NAME, VARIABLE_VALUE, concat(VARIABLE_VALUE/1024/1024,' MB') AS VARIABLE_VALUE_MB from information_schema.SESSION_VARIABLES where variable_name in ('innodb_buffer_pool_size','innodb_log_buffer_size','innodb_additional_mem_pool_size','key_buffer_size','query_cache_size');
+-------------------------+----------------+-------------------+
| VARIABLE_NAME | VARIABLE_VALUE | VARIABLE_VALUE_MB |
+-------------------------+----------------+-------------------+
| KEY_BUFFER_SIZE | 33554432 | 32 MB |
| QUERY_CACHE_SIZE | 1048576 | 1 MB |
| INNODB_LOG_BUFFER_SIZE | 67108864 | 64 MB |
| INNODB_BUFFER_POOL_SIZE | 10737418240 | 10240 MB |
+-------------------------+----------------+-------------------+
4 rows in set, 1 warning (0.00 sec)
检查了Innodb buffer的内存参数设置值10240MB = 10G， 占总内存 10G/16GB = 62.5%，该值设置在合理的范围内，详细的参数介绍可以参考官方文档，当系统内存严重不足时， 快速恢复可以降低共享内存，调整该参数后，内存会立马释放：
mysql> set global innodb_buffer_pool_size=8589934592;
Query OK, 0 rows affected (0.00 sec)
mysql> select VARIABLE_NAME, VARIABLE_VALUE, concat(VARIABLE_VALUE/1024/1024,' MB') AS VARIABLE_VALUE_MB from information_schema.SESSION_VARIABLES where variable_name in ('innodb_buffer_pool_size','innodb_log_buffer_size','innodb_additional_mem_pool_size','key_buffer_size','query_cache_size');
+-------------------------+----------------+-------------------+
| VARIABLE_NAME | VARIABLE_VALUE | VARIABLE_VALUE_MB |
+-------------------------+----------------+-------------------+
| KEY_BUFFER_SIZE | 33554432 | 32 MB |
| QUERY_CACHE_SIZE | 1048576 | 1 MB |
| INNODB_LOG_BUFFER_SIZE | 67108864 | 64 MB |
| INNODB_BUFFER_POOL_SIZE | 8589934592 | 8192 MB |
+-------------------------+----------------+-------------------+
4 rows in set, 1 warning (0.00 sec)
mysql> system free -mt
total used free shared buff/cache available
Mem: 16046 13020 2081 13 944 2666
Swap: 0 0 0
Total: 16046 13020 2081
这里我们为了快速释放系统内存，调整了INNODB_BUFFER_POOL_SIZE值后，可用内存恢复2G。
Session私有内存
共享内存中介绍的内存空间是实例创建时即分配的内存空间，并且是所有连接共享的。而出现 OOM 异常的实例通常都是由于下面各个连接私有的内存造成的。
mysql> select VARIABLE_NAME, VARIABLE_VALUE, concat(VARIABLE_VALUE/1024/1024,' MB') AS VARIABLE_VALUE_MB from information_schema.SESSION_VARIABLES where variable_name in ('read_buffer_size','read_rnd_buffer_size','sort_buffer_size','join_buffer_size','binlog_cache_size','tmp_table_size');
+----------------------+----------------+-------------------+
| VARIABLE_NAME | VARIABLE_VALUE | VARIABLE_VALUE_MB |
+----------------------+----------------+-------------------+
| SORT_BUFFER_SIZE | 33554432 | 32 MB |
| READ_RND_BUFFER_SIZE | 33554432 | 32 MB |
| READ_BUFFER_SIZE | 16777216 | 16 MB |
| BINLOG_CACHE_SIZE | 32768 | 0.03125 MB |
| TMP_TABLE_SIZE | 67108864 | 64 MB |
| JOIN_BUFFER_SIZE | 134217728 | 128 MB |
+----------------------+----------------+-------------------+
6 rows in set, 1 warning (0.00 sec)
这里的私有内存JOIN_BUFFER_SIZE=128MB， 默认值是256KB。用于普通索引扫描、范围索引扫描和不使用索引而执行全表扫描的联接的缓冲区的最小大小。通常获得快速连接的最佳方法是添加索引。在无法添加索引时，增加join_buffer_size的值，以获得更快的完全连接。为两个表之间的每个完整连接分配一个连接缓冲区。对于没有使用索引的几个表之间的复杂联接，可能需要多个联接缓冲区。
除非使用块嵌套循环或批处理键访问算法，否则设置大于保存每个匹配行所需的缓冲区不会有任何好处，并且所有连接至少分配最小的大小，因此在全局将该变量设置为大值时要小心。最好保持全局设置较小，只在执行大型连接的会话中将会话设置更改为较大的值。如果全局大小大于使用它的大多数查询所需要的大小，那么内存分配时间可能会导致显著的性能下降。
通过检查私有内存，我们发现这是的JOIN_BUFFER_SIZE全局设置较大。
内存监控
MySQL5.7版本通过performance_schema可以方便的查看内存占用情况， 前提是要打开监控，执行如下SQL语句，打开内存监控。
mysql> update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';
mysql> select * from performance_schema.setup_instruments where name like 'memory%innodb%' limit 20;
+-------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+-------------------------------------------+---------+-------+
| memory/innodb/adaptive hash index | YES | NO |
| memory/innodb/buf_buf_pool | YES | NO |
| memory/innodb/dict_stats_bg_recalc_pool_t | YES | NO |
| memory/innodb/dict_stats_index_map_t | YES | NO |
| memory/innodb/dict_stats_n_diff_on_level | YES | NO |
| memory/innodb/other | YES | NO |
| memory/innodb/row_log_buf | YES | NO |
| memory/innodb/row_merge_sort | YES | NO |
| memory/innodb/std | YES | NO |
| memory/innodb/trx_sys_t::rw_trx_ids | YES | NO |
| memory/innodb/partitioning | YES | NO |
| memory/innodb/api0api | YES | NO |
| memory/innodb/btr0btr | YES | NO |
| memory/innodb/btr0bulk | YES | NO |
| memory/innodb/btr0cur | YES | NO |
| memory/innodb/btr0pcur | YES | NO |
| memory/innodb/btr0sea | YES | NO |
| memory/innodb/buf0buf | YES | NO |
| memory/innodb/buf0dblwr | YES | NO |
| memory/innodb/buf0dump | YES | NO |
+-------------------------------------------+---------+-------+
20 rows in set (0.00 sec)
该命令是在线打开内存统计，所以只会统计打开后新增的内存对象，打开前的内存对象不会统计，建议您打开后等待一段时间再执行后续步骤，便于找出内存使用高的线程。
内存相关表
这里我们查看performance_schema相关的内存监控表有哪些，分别可以统计哪些信息。
mysql> show tables like '%memory%';
+-----------------------------------------+
| Tables_in_performance_schema (%memory%) |
+-----------------------------------------+
| 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 |
+-----------------------------------------+
5 rows in set (0.00 sec)
以上表的监控统计，分别统计线程、帐户、用户、主机间接执行内存操作等信息，每个内存汇总表都有一个或多个分组列，用于指示表如何聚合事件，参考如下表介绍：表名说明
(一)统计事件消耗内存
mysql> select event_name, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_global_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc LIMIT 10;
+---------------------------------------+---------------------------+
| event_name | SUM_NUMBER_OF_BYTES_ALLOC |
+---------------------------------------+---------------------------+
| memory/sql/JOIN_CACHE | 966665202302976 |
| memory/memory/HP_PTRS | 304457132043176 |
| memory/innodb/mem0mem | 29273314618616 |
| memory/sql/thd::main_mem_root | 18376092762472 |
| memory/sql/Filesort_buffer::sort_keys | 3155343016712 |
| memory/sql/String::value | 2708659513792 |
| memory/sql/test_quick_select | 2146347475648 |
| memory/sql/QUICK_RANGE_SELECT::alloc | 1961041015680 |
| memory/mysys/IO_CACHE | 1463097599496 |
| memory/sql/TABLE | 635194922117 |
+---------------------------------------+---------------------------+
10 rows in set (0.01 sec)
注意到 “memory/sql/JOIN_CACHE” 消耗的内存最大。
(二)统计线程消耗内存
mysql> select thread_id, event_name, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_by_thread_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10;
+-----------+-----------------------+---------------------------+
| thread_id | event_name | SUM_NUMBER_OF_BYTES_ALLOC |
+-----------+-----------------------+---------------------------+
| 1922626 | memory/innodb/mem0mem | 1984233347055 |
| 1922439 | memory/innodb/mem0mem | 1404615671548 |
| 1954681 | memory/innodb/mem0mem | 1375641196768 |
| 1922431 | memory/innodb/mem0mem | 1350354644688 |
| 1954682 | memory/innodb/mem0mem | 1099479913383 |
| 1922625 | memory/innodb/mem0mem | 1097551130366 |
| 2686170 | memory/innodb/mem0mem | 992829979036 |
| 1922433 | memory/innodb/mem0mem | 874412348141 |
| 1922438 | memory/innodb/mem0mem | 863348539942 |
| 1922432 | memory/innodb/mem0mem | 754779357792 |
+-----------+-----------------------+---------------------------+
10 rows in set (0.02 sec)
上面统计结果发现到 “memory/innodb/mem0mem” 事件消耗的内存最多。
(三)统计账户消耗内存
mysql> select USER, HOST, EVENT_NAME, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_by_account_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10;
+-------------------+---------------+-----------------------+---------------------------+
| USER | HOST | EVENT_NAME | SUM_NUMBER_OF_BYTES_ALLOC |
+-------------------+---------------+-----------------------+---------------------------+
| c********** | 192.168.*.* | memory/sql/JOIN_CACHE | 638622579556352 |
| c********** | 192.168.*.* | memory/sql/JOIN_CACHE | 276949456912384 |
| b********** | 192.168.*.* | memory/memory/HP_PTRS | 166067384571544 |
| b********** | 192.168.*.* | memory/memory/HP_PTRS | 76145767762936 |
| b********** | 192.168.*.* | memory/sql/JOIN_CACHE | 42176612401152 |
| z********** | 192.168.*.* | memory/memory/HP_PTRS | 30219030003816 |
| s********** | 192.168.*.* | memory/innodb/mem0mem | 16114310343537 |
| b********** | 192.168.*.* | memory/sql/JOIN_CACHE | 9070736048128 |
| c********** | 192.168.*.* | memory/innodb/mem0mem | 4787044880366 |
| a********** | 192.168.*.* | memory/memory/HP_PTRS | 4764584763968 |
+-------------------+---------------+-----------------------+---------------------------+
10 rows in set (0.16 sec)
这里把相关敏感信息脱敏了，从上面发现用户 c* 占用内存最大。 事件还是memory/sql/JOIN_CACHE
(四)统计主机消耗内存
mysql > select HOST, EVENT_NAME, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_by_host_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10;
+---------------+-------------------------------+---------------------------+
| HOST | EVENT_NAME | SUM_NUMBER_OF_BYTES_ALLOC |
+---------------+-------------------------------+---------------------------+
| 192.168.*.* | memory/sql/JOIN_CACHE | 681148560703488 |
| 192.168.*.* | memory/sql/JOIN_CACHE | 286124345917440 |
| 192.168.*.* | memory/memory/HP_PTRS | 166777472915704 |
| 192.168.*.* | memory/memory/HP_PTRS | 76851688652536 |
| 192.168.*.* | memory/memory/HP_PTRS | 30227900416896 |
| 192.168.*.* | memory/innodb/mem0mem | 16117796446781 |
| 192.168.*.* | memory/memory/HP_PTRS | 7457591548256 |
| 192.168.*.* | memory/innodb/mem0mem | 6596914688112 |
| 192.168.*.* | memory/sql/thd::main_mem_root | 5979929501808 |
| 192.168.*.* | memory/sql/thd::main_mem_root | 4795924383312 |
+---------------+-------------------------------+---------------------------+
10 rows in set (0.07 sec)
通过上面的主机，也能快速定位是哪台主机占用内存大，有必要时可以重启该主机的应用。
(五)统计用户消耗内存
mysql> select USER, EVENT_NAME, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_by_user_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10;
+-------------------+-------------------------------+---------------------------+
| USER | EVENT_NAME | SUM_NUMBER_OF_BYTES_ALLOC |
+-------------------+-------------------------------+---------------------------+
| c**************** | memory/sql/JOIN_CACHE | 915572036468736 |
| b**************** | memory/memory/HP_PTRS | 242213179169888 |
| b**************** | memory/sql/JOIN_CACHE | 51247348449280 |
| z**************** | memory/memory/HP_PTRS | 30225123465960 |
| b**************** | memory/memory/HP_PTRS | 21863256050496 |
| s**************** | memory/innodb/mem0mem | 16116655699153 |
| e**************** | memory/sql/thd::main_mem_root | 9554995144176 |
| c**************** | memory/innodb/mem0mem | 6360931505366 |
| a**************** | memory/memory/HP_PTRS | 4765617785408 |
| s**************** | memory/sql/thd::main_mem_root | 3074066885016 |
+-------------------+-------------------------------+---------------------------+
10 rows in set (0.06 sec)
找到问题事件或线程后，您可以排查业务代码和环境，解决内存高的问题。上面统计结果发现到 “memory/sql/JOIN_CACHE” 事件消耗的内存最大。调整全局JOIN_BUFFER_SIZE=32MB，再观察内存占用情况。
mysql> set global join_buffer_size=33554432;
Query OK, 0 rows affected (0.00 sec)
mysql> quit
mysql> select VARIABLE_NAME, VARIABLE_VALUE, concat(VARIABLE_VALUE/1024/1024,' MB') AS VARIABLE_VALUE_MB from information_schema.SESSION_VARIABLES where variable_name in ('read_buffer_size','read_rnd_buffer_size','sort_buffer_size','join_buffer_size','binlog_cache_size','tmp_table_size');
+----------------------+----------------+-------------------+
| VARIABLE_NAME | VARIABLE_VALUE | VARIABLE_VALUE_MB |
+----------------------+----------------+-------------------+
| SORT_BUFFER_SIZE | 33554432 | 32 MB |
| READ_RND_BUFFER_SIZE | 33554432 | 32 MB |
| READ_BUFFER_SIZE | 16777216 | 16 MB |
| BINLOG_CACHE_SIZE | 32768 | 0.03125 MB |
| TMP_TABLE_SIZE | 67108864 | 64 MB |
| JOIN_BUFFER_SIZE | 33554432 | 32 MB |
+----------------------+----------------+-------------------+
6 rows in set, 1 warning (0.00 sec)
mysql> select * from information_schema.processlist where COMMAND='sleep' and Time>1000 order by Time desc;
这里会话参数调整后，需同时调整/etc/my.cnf的配置，下次服务启动永久生效，另外之前连接的会话线程由于已分配了该buffer大小，调整后内存并不会马上释放。
完。
-
mysql 查看进程占用内存_如何查看进程中各线程的存储空间占用情况
2021-03-14 20:55:56已采纳1、查看物理CPU的个数[root@MysqlCluster01 ~]# cat /proc/cpuinfo |grep “physical id”|sort |uniq|wc -l12、查看逻辑CPU的个数[root@MysqlCluster01 ~]# cat /proc/cpuinfo |grep “processor”|wc -l43、...展开全文
已采纳
1、查看物理CPU的个数
[root@MysqlCluster01 ~]# cat /proc/cpuinfo |grep “physical id”|sort |uniq|wc -l
1
2、查看逻辑CPU的个数
[root@MysqlCluster01 ~]# cat /proc/cpuinfo |grep “processor”|wc -l
4
3、查看CPU是几核(即，核心数)
[root@MysqlCluster01 ~]# cat /proc/cpuinfo |grep “cores”|uniq
cpu cores : 4
4、查看CPU的主频
[root@MysqlCluster01 ~]# cat /proc/cpuinfo |grep MHz|uniq
cpu MHz : 2499.982
5、当前操作系统内核信息
[root@MysqlCluster01 ~]# uname -a
Linux MysqlCluster01 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
6、当前操作系统发行版信息
[root@MysqlCluster01 ~]# cat /etc/issue
CentOS release 6.4 (Final)
Kernel \r on an \m
7、内存使用情况
[root@MysqlCluster01 ~]# free -m
total used free shared buffers cached
Mem: 7863 2738 5125 0 141 835
-/+ buffers/cache: 1761 6102
Swap: 3967 0 3967
取消
评论
-
mysql 线程占用_RDS MySQL如何查看消耗内存高的事件和线程
2021-01-19 15:11:29您也可以参考如下SQL语句，查看详细的监控信息。select * from sys.x$memory_by_host_by_current_bytes;select * from sys.x$memory_by_thread_by_current_bytes;select * from sys.x$memory_by_user_by_current_...展开全文您也可以参考如下SQL语句，查看详细的监控信息。
select * from sys.x$memory_by_host_by_current_bytes;
select * from sys.x$memory_by_thread_by_current_bytes;
select * from sys.x$memory_by_user_by_current_bytes;
select * from sys.x$memory_global_by_current_bytes;
select * from sys.x$memory_global_total;
select * from performance_schema.memory_summary_by_account_by_event_name;
select * from performance_schema.memory_summary_by_host_by_event_name;
select * from performance_schema.memory_summary_by_thread_by_event_name;
select * from performance_schema.memory_summary_by_user_by_event_name;
select * from performance_schema.memory_summary_global_by_event_name;
select event_name,
current_alloc
from sys.memory_global_by_current_bytes
where event_name like '%innodb%';
select event_name,current_alloc from sys.memory_global_by_current_bytes limit 5;
select m.thread_id tid,
USER,
esc.DIGEST_TEXT,
total_allocated
FROM sys.memory_by_thread_by_current_bytes m,
performance_schema.events_statements_current esc
WHERE m.`thread_id` = esc.THREAD_ID \G
-
mysql查看占用内存或者CPU高的SQL
2020-12-14 16:55:12实时查看mysql进程中占用CPU，内存最多的操作系统线程ID top -p 2341 -H 根据操作系统线程ID，查看mysql数据库中对应的线程ID select thread_id,name ,PROCESSLIST_ID,THREAD_OS_ID from threads where thread_os_... -
mysql 线程占用cpu使用率_mysqlCPU占用过高解决方案
2021-01-19 00:53:10最近压测一个接口，发现吞吐率一直上不去，平均响应时间达到13秒多。压测线程组设置如下：200个线程，60秒内执行完成，每个线程循环60次。可以归纳为每秒启动200个线程。...top #查看CPU情况mysqld占用CPU资源... -
记一次Mysql占用内存过高的优化过程
2017-12-26 13:44:37一.环境说明 操作系统：CentOS 6.5 ...1.某日发现公司线上系统的Mysql某个实例的从库长时间内存占用达到60%如下图 2.于是开始按照以下步骤排查： (1).查看mysql里的线程，观察是否有长期运行或阻塞的sql： show ful -
java mysql被占用内存_Java进程占用内存过高，排查解决方法
2021-01-19 09:31:54如下图：解决方法：A:可能是代码原因导致的问题：1、使用命令：top查看当前进程的状态2、从上图可以看到PID：916的java进程占用内存较大。定位线程问题(通过命令查看PID 为25894 进程的线程情况),命令：# ps p 916 -... -
MySQL查看内存消耗过高的线程事件
2020-05-21 17:56:25环境信息 版本 服务 ...Ubuntu 16.04.6 LTS ...mysql 5.7.25 ...内存是重要的性能参数，内存使用率过...通过free命令查看系统内存资源使用情况，通过top -c 命令查看进程使用内存占用情况，如下 root@ubuntu:~# free -mt -
java比mysql耗内存_java高cpu占用和高内存占用
2021-01-27 01:51:05高cpu占用1、top命令：Linux命令。可以查看实时的CPU使用情况。也可以查看最近一段时间的CPU使用情况。2、PS命令：Linux命令。强大的进程状态监控命令。可以查看进程以及进程中线程的当前CPU使用情况。属于当前状态... -
mysql防止内存溢出_mysql内存溢出处理
2021-01-18 18:20:51主库实列发生OOM，实例进程由于占用内存达到linux系统的最大阈值，导致linux系统kill了mysql实例进程，可以通过如下方式查看mysql使用了多少内存：查看每个线程占用多少内存，然后乘以正在运行的线程(也就是排查... -
mysql 占用cpu高_mysqlCPU占用过高解决方案
2021-01-18 23:48:16最近压测一个接口，发现吞吐率一直上不去，平均响应时间达到13秒多。压测线程组设置如下：200个线程，60秒内执行完成，每个线程循环60次。可以归纳为每秒启动200个线程。...top #查看CPU情况mysqld占用CPU资源... -
mysql内存优化
2019-03-13 16:25:00一.环境说明：操作系统：CentOS 6.5 x86_64数据库：Mysql 5.6.22服务器：阿里云VPS，32G Mem，0 swap二....查看mysql里的线程，观察是否有长期运行或阻塞的sql：show full processlist经查看，没有发现相关线程，可... -
MySQL线程用完，新连接无法连接解决
2016-10-14 11:49:44问题：MySQL服务器所支持的最大连接数是有上限的，每个连接都会占用一定的内存资源，因此当客户端访问MySQL服务器处理完相应的操作后，就应该断开连接释放内存资源。如果服务器有大量的闲置连接，这样就会白白的浪费... -
apache mysql好慢_真正解决WordPress后台卡反应慢问题，Apache内存释放及优化mysql
2021-01-26 15:26:53实际设置中可以根据apache-status查看apache实时连接状态，查看其中线程占用数目情况来进行相应的调整，我的服务器最后设置如下：ThreadsPerChild 500MaxRequestsPerChild 10000其中ThreadLimit是占用系统线程数限制... -
wordpress mysql 优化_真正解决WordPress后台卡反应慢问题，Apache内存释放及优化mysql...
2021-02-05 01:17:39实际设置中可以根据apache-status查看apache实时连接状态，查看其中线程占用数目情况来进行相应的调整，我的服务器最后设置如下：ThreadsPerChild 500MaxRequestsPerChild 10000其中ThreadLimit是占用系统线程数限制... -
MySQL常用命令
2020-01-03 11:09:14--查看每个线程占用多少内存，然后乘以正在运行的线程（也就是排查sleep的）。 SELECT ( ( @@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@join_buffer_size + @@binlog_cache_size + @@... -
Java程序问题 和MySQL 数据库的性能问题解决思路
2013-07-03 17:18:29如果有一个线程占用CPU过高，有两种可能：没有内存了，Java垃圾回收线程不停地运行尝试回收内存，但是每次无法收回，确认：jstat -gcutil pid 1s 观察10多秒钟就能发现了，看是不是内存使用率接近100%... -
mysql数据库my.cnf配置文件
2019-04-22 13:59:30# MySQL的最大连接数，如果服务器的并发连接请求量比较大，建议调高此值，以增加并行连接数量，当然这建立在机器能支撑的情况下，因为如果连接数越多，介于MySQL会为每个连接提供连接缓冲区，就会开销越多的内存，... -
解决Java从MySQL读取大量数据时卡…
2015-10-10 09:24:10今天晚上突然有个服务无法启动。这个服务在启动的时候会从数据库中加载一些数据。查看日志：有开始加载的日志，但没有完成加载的日志，判断...再用jstack查看线程栈，发现线程卡在JDBC底层的TCP套接字读取上： -- -
服务器内存被占满不释放的解决过程
2020-10-28 11:31:51CentOs7+服务部署完10秒，查看内存被占80%+ 本人近期遇到的问题： 项目架构为springboot+dubbo+mysql+redis 服务在本地环境运行没有问题，部署到线上10秒左右，好多的功能页面出现超时以及加载慢的问题， 问题排查：... -
解决Java从MySQL读取大量数据时卡在SocketInputStream.socketRead0的问题
2016-05-19 16:00:00今天晚上突然有个服务无法启动。这个服务在启动的时候会从数据库中加载一些数据。查看日志：有开始加载的日志，但没有完成加载的日志，判断...再用jstack查看线程栈，发现线程卡在JDBC底层的TCP套接字读取上： -- -
Linux、docker、kubernetes、MySql、Shell、kafka、RabbitMQ、PostgreSQ运维快餐
2018-06-21 14:52:00检查端口占用 lsof -i:[port] netstat -anp |grep [port] 监控网络客户TCP连接数 ...输出进程内存的状况，分析线程堆栈 pmap 统计文档容量 du -sh [目录|文件|正则] 例如：查看日志文件大小，从而判定日... -
[Linux]常用命令笔记
2018-11-30 09:10:05常用命令 ...top 查看线程占用 查看网络信息时 ifconfig无法找到问题 yum install net-tools 关闭firewall： systemctl stop firewalld.service #停止firewall systemctl disable firewalld.ser... -
请求很卡，怎样定位问题
2018-03-11 19:09:00首先使用 ps aux|grep mysql 找出pid，然后使用 top -p pid 查看cpu和内存占用。 查看java进程内存使用：jmap -heap pid 查看java进程各线程栈：jstack pid 查看java进程gc：jstat -gcutil 1000m... -
autocare使用命令
2019-06-03 08:37:00Linux ...可以用下面的命令将 cpu 占用率高的线程找出来:ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpufree -thMem：表示物理内存统计-/+ buffers/cached：表示物理内存的缓存统计 MySQL ...
mysql
订阅