Docker容器中的MySQL永远不会释放内存，并且经常崩溃导致内存不足

Question

具有32GB RAM的主机。 Mysql 5.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 RAM。
即使我的大型请求完成后，内存使用率几乎总是增加并且永远不会清除。超过14GB时会崩溃。 “刷新查询缓存”永远不会更改此图，“刷新表”通常不会受到很大影响，然后又会快速增长。当数据库请求又大又重时，很快就达到了限制，否则就很慢。
/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吗？

Answer 1

您的ulimit -a报告指示打开文件限制为1024。在LX中，ulimit -n 24000将启用更多文件句柄供MySQL使用。
为了使新限制在LX关闭期间保持不变，请重新启动该URL https://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/
您的详细信息可能会略有不同。

查看我最近关于DOCKER缺少CLOSE（）来释放资源的评论。

Rate Per Second =您的my.cnf [mysqld]部分要考虑的RPS建议

# 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，复制整个块，然后开始 日期时间为＃，我的网址为[mysqld]部分的END，使用＃AND空格键引导SAME NAMED变量禁用新的变量块之前的行，停止服务/启动服务。
在docker world将CLOSE（）放置到位之前，您仍然会崩溃，但要在当天晚些时候。您的许多PER CONNECTION变量已被过度提供，有些可能仍然存在，但可能仍然存在。

有关其他建议，请查看我的个人资料，网络个人资料以获取联系信息，包括我的Skype ID。期待您的回音。

Answer 2

当我将mysql升级到v8.0.12时，我倾向于认为这是mysql v5的错误导致的。情况变得很好-内存可以按预期定期释放，即使在繁重的请求期间也是如此。