docker容器中的mysql从不释放内存,经常崩溃导致内存不足

kognpnkq  于 2021-06-19  发布在  Mysql
关注(0)|答案(2)|浏览(1348)

带有32gb ram的主机。MySQL5.7.21在docker容器中工作,使用以下命令运行: docker run --restart=always --name mydb5721 -v ... -e MYSQL_ROOT_PASSWORD=... -e MYSQL_USER=... -e MYSQL_PASSWORD=... -p ...:3306 --memory 14G --memory-swap 14G --health-interval=10s --health-timeout=10s --health-retries=3 --health-cmd='/bin/bash /var/lib/mysql/healthcheck.sh' mysql:5.7.21 --verbose & 所以没有交换和14gb内存。
内存使用几乎总是在增长,而且永远不会被清除,即使在我的大请求完成之后。当超过14gb限制时就会崩溃。”flush query cache“永远不会改变这个图形,”flush tables“通常不会受到很大影响,然后又会快速增长。当db请求很大且很重时,会很快达到限制,否则会很慢。

/etc/mysql/mysql.conf.d文件:

[mysqld]
innodb_force_recovery = 6
user=root
max_allowed_packet=1500M
bind-address=0.0.0.0
key_buffer_size=1024M
max_connections=200
table_open_cache=64
query_cache_limit=4M
query_cache_size=512M
innodb_buffer_pool_size=7G
server-id=2
log-slave-updates=1

innodb_log_buffer_size          = 16M
innodb_log_file_size            = 250M

pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
datadir         = /var/lib/mysql
log-error      = /var/log/mysql/error.log
symbolic-links=0
skip-host-cache
skip-name-resolve

sql-mode="NO_AUTO_VALUE_ON_ZERO"

innodb_file_per_table = 1
table_open_cache = 2048
innodb_open_files = 2048
sort_buffer_size = 128M
read_buffer_size = 128M
read_rnd_buffer_size = 1M
thread_stack = 128M
query_cache_type = 0
thread_cache_size = 32
max_heap_table_size = 256M
tmp_table_size = 1G
innodb_buffer_pool_instances = 4
innodb_read_io_threads = 8
innodb_write_io_threads = 8

performance_schema = 0
innodb_flush_log_at_trx_commit = 2

slow_query_log=1
long_query_time=40
slow-query-log-file=/var/log/mysql/slow_queries.log
general_log=0

innodb_flush_method=O_DIRECT
innodb_tmpdir=/tmp

secure-file-priv = ""

我的主要问题是:
-docker是有罪的还是mysql(因为没有docker我从来没有mysql的问题)?
-为什么即使在我的查询完成后内存也不会释放?
-解决方案是否会迁移到mariadb?

62o28rlo

62o28rlo1#

我倾向于认为这是mysql v5的错误,因为当我将mysql升级到v8.0.12时,情况变得很好——即使在大量请求期间,内存也会按预期定期释放。

clj7thdc

clj7thdc2#

你的ulimit-a报告指出打开的文件限制为1024个。在lx中,ulimit-n24000将为mysql启用更多的文件句柄。
要使新限制在lx关闭期间保持不变,请重新启动并查看此urlhttps://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/
你的细节可能略有不同。
查看我最近关于docker缺少close()以释放资源的评论。
rate per second=rps为my.cnf[mysqld]部分考虑的建议


# 20180924 1442  mysqlservertuning.com

read_rnd_buffer_size=256K  # from 1M  to reduce handler_read_rnd_next RPS
read_buffer_size=256K  # from 128M will increase handler_read_next RPS 
innodb_io_capacity_max=20000  # from 2000 to take advantage of SSD IOPS capacity
innodb_io_capacity=10000  # from 200 to take advantage of SSD IOPS capacity
tmp_table_size-256M  #  from 1G to be matched to max_heap_table_size
key_buffer_size=64M  # from 1G to conserve RAM, key_blocks_used is less than 1%
innodb_lru_scan_depth=100  # from 1024 to conserve CPU cycles every SECOND
innodb_thread_concurrency=24  # from 0 (unlimited) for your 16 cpu's reported by iostat
table_open_cache=4096  # from 2048 to reduce opened_tables count
table_definition_cache=2048  # from 1424 to reduce opened_table_definitions count
query_cache_size=0  # from ~512M because query_cache_type=0 (off) to conserve RAM
query_cache_limit=0  # from ~4M because query_cache_type=0 (off) to conserve RAM

考虑到您的情况,备份您当前的my.cnf,复制整个块,从#date time开始,将我的网址复制到[mysqld]部分的末尾,用#和空格键引导同一命名变量以禁用新变量块之前的行,停止服务/启动服务。
在docker world将close()设置到位之前,仍然会有崩溃,但会在当天稍晚的时候发生。您的每个连接的许多变量都配置过多,有些可能仍然存在,但可能可以生存。
如需其他建议,请查看我的个人资料,包括我的skype id联系信息的网络配置文件。期待您的回复。

相关问题