mysql DB服务器中的内存泄漏

问题描述

环境:Azure实例32GB RAB 8核心CPU。数据为10GB 每周重启后,我观察到它的内存每天增加5%,就像初次重启时一样,它将增加12%,然后当我每天早上进行监视时,它总是显示出5%的增加 就像周末结束时一样,无论活跃度如何,达到40%。虽然CPU非常正常,但始终低于5%。这是我的mysql配置文件

[mysqld]
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
datadir         = /var/lib/mysql
log-error       = /var/log/mysql/error.log
bind-address    = 0.0.0.0
default_authentication_plugin= mysql_native_password
sql-mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'
#max_connections = 5000
max_connections=5000     # change on 03/10/20202 by Debashis
innodb_buffer_pool_size=18G # change on 03/10/20202 by Debashis
innodb_buffer_pool_instances=28
sort_buffer_size=100M
join_buffer_size=100M
tmp_table_size=1G
max_heap_table_size=1G  # added on 03/10/20202 by Debashis
innodb_log_file_size = 1G

# Below  added on 03/10/20202 by Debashis
innodb_log_buffer_size = 67108864

innodb_io_capacity_max = 6000
innodb_io_capacity = 4000
innodb_read_io_threads = 16
innodb_thread_concurrency = 0
innodb_write_io_threads = 16

table_open_cache=13806
open_files_limit= 27612
table_definition_cache=7303

这里是性能调谐器报告。.我在报告上没有看到太多问题..

 -- MYSQL PERFORMANCE TUNING PRIMER --
      - By: Matthew Montgomery -

MySQL Version 8.0.20 x86_64

Uptime = 2 days 0 hrs 11 min 20 sec
Avg. qps = 15
Total Questions = 2651288
Threads Connected = 22

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.

BINARY UPDATE LOG
The binary update log is enabled
The expire_logs_days is not set.
The mysqld will retain the entire binary log until RESET MASTER or PURGE MASTER LOGS commands are run manually
Setting expire_logs_days will allow you to remove old binary logs automatically
See http://dev.mysql.com/doc/refman/8.0/en/purge-master-logs.html

WORKER THREADS
Current thread_cache_size = 68
Current threads_cached = 48
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 6000
Current threads_connected = 20
Historic max_used_connections = 80
The number of used connections is 1% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

INNODB STATUS
Current InnoDB index space = 10.38 G
Current InnoDB data space = 10.12 G
Current InnoDB buffer pool free = 73 %
Current innodb_buffer_pool_size = 18.00 G
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 33.74 G
Configured Max Per-thread Buffers : 1175.85 G
Configured Max Global Buffers : 18.07 G
Configured Max Memory Limit : 1193.92 G
Physical Memory : 31.36 G

Max memory limit exceeds 90% of physical memory

KEY BUFFER
No key reads?!
Seriously look into using some indexes
Current MyISAM index space = 0 bytes
Current key_buffer_size = 8 M
Key cache miss rate is 1 : 0
Key buffer free ratio = 81 %
Your key_buffer_size seems to be fine

QUERY CACHE
You are using MySQL 8.0.20,no query cache is supported.
I recommend an upgrade to MySQL 4.1 or better

SORT OPERATIONS
Current sort_buffer_size = 100 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 100.00 M
You have had 13855 queries where a join could not use an index properly
join_buffer_size >= 4 M
This is not advised
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.

OPEN FILES LIMIT
Current open_files_limit = 10000 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cache = 13806 tables
Current table_definition_cache = 7303 tables
You have a total of 4602 tables
You have 6755 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 1.00 G
Current tmp_table_size = 1.00 G
Of 114648 temp tables,0% were created on disk
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 181 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 2651593
Your table locking seems to be fine

解决方法

您的InnoDB缓冲池很大。

innodb_buffer_pool_size=18G # change on 03/10/20202 by Debashis

这意味着缓冲区最多可以消耗18 GB的RAM,这可以解释服务器中的大内存使用情况。

内存消耗不应超过18 GB。如果您对此感到担心,请阅读Configuring InnoDB Pool Size并将其设置为较小的值。

,

这不是内存泄漏,而是缓存预热。而且,正如Marc上面指出的那样,使缓冲池大于数据大小没有好处。

您的排序和连接缓冲区大小非常大。默认值为256KB,这对于大多数使用来说是明智的。请注意,这是每个连接分配的最低数量。

如果您不确切知道自己正在做什么,请不要使用mysql调谐器-在大多数情况下,盲目听从它的建议会弊大于利。

相关问答

错误1:Request method ‘DELETE‘ not supported 错误还原:...
错误1:启动docker镜像时报错:Error response from daemon:...
错误1:private field ‘xxx‘ is never assigned 按Alt...
报错如下,通过源不能下载,最后警告pip需升级版本 Requirem...