Mysql в контейнере Docker никогда не освобождает память и регулярно вылетает из-за нехватки памяти

Question

Хост с 32 ГБ оперативной памяти.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 &
, поэтому без подкачки и с 14 ГБ ОЗУ.
Использование памяти почти всегда растет и никогда не очищается, даже после моих больших запросовзавершены.И он падает, когда превышает предел 14 ГБ.«Очистка кеша запросов» никогда не меняет этот график, «очистка таблиц» обычно не сильно затрагивается, а затем снова быстро растет.Когда 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 (потому что у меня никогда не было этой проблемы с mysql без докера)?
- почему память никогда не освобождается даже после завершения моих запросов?
- будет лимиграция решения в MariaDB?

Answer 1

Я склонен думать, что это ошибка mysql v5, когда я обновляю mysql до v8.0.12, ситуация стала хорошей - память регулярно освобождается, как и ожидалось, даже во время тяжелого запроса.

Answer 2

В вашем отчете 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 () для освобождения ресурсов.

Скорость в секунду = RPS.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], ведите ЖЕПеременная NAMED с пробелом # AND для отключения строки перед новым BLOCK переменных, остановки службы / запуска службы.
Пока в мире докеров не появится CLOSE (), у вас все еще будут происходить сбои, но чуть позжедень.Многие из ваших переменных PER CONNECTION были ПЕРЕДАНО, некоторые еще могут быть, но, вероятно, выжившими.

Для дополнительных предложений, пожалуйста, просмотрите мой профиль, Сетевой профиль для контактной информации, включая мой Skype ID.С нетерпением ждем от вас.