Таинственный Мариадб 10.4.1.

Question

Я обновил mariadb 10.1.36 до 10.4.8 и вижу таинственное увеличение использования оперативной памяти в этой новой версии. Я также отредактировал innodb_buffer_pool_size ant, кажется, что нет никакого эффекта, если он установлен на 15M или 4G, оперативная память просто медленно увеличивается. Через некоторое время он ест целого барана и убивает убийцу марихуан, и это повторяется.

Мой сервер имеет 8 ГБ ОЗУ и увеличивается до 60-150 МБ в день. Это не страшно, но у меня есть около 150 серверов баз данных, так что это огромная проблема.

Я могу временно решить проблему, перезапустив mariadb и снова запустив ее.

Информация о сервере баз данных: базы данных: 200+ таблиц: 28200 (141 на базу данных) среднее количество активных соединений: размер 100-200 сохраненных данных: 100-350 ГБ

процессор: 4 оперативной памяти: 8 ГБ

есть моя конфигурация:

server-id=101
datadir=/opt/mysql/
socket=/var/lib/mysql/mysql.sock
tmpdir=/tmp/
gtid-ignore-duplicates=True
log_bin=mysql-bin
expire_logs_days=4
wait_timeout=360
thread_cache_size=16
sql_mode="ALLOW_INVALID_DATES"
long_query_time=0.8
slow_query_log=1
slow_query_log_file=/opt/log/slow.log
log_output=TABLE
userstat = 1
user=mysql
symbolic-links=0
binlog_format=STATEMENT
default_storage_engine=InnoDB
slave_skip_errors=1062,1396,1690innodb_autoinc_lock_mode=2
innodb_buffer_pool_size=4G
innodb_buffer_pool_instances=5
innodb_log_file_size=1G
innodb_log_buffer_size=196M
innodb_flush_log_at_trx_commit=1
innodb_thread_concurrency=24
innodb_file_per_table
innodb_write_io_threads=24
innodb_read_io_threads=24
innodb_adaptive_flushing=1
innodb_purge_threads=5
innodb_adaptive_hash_index=64
innodb_flush_neighbors=0
innodb_flush_method=O_DIRECT
innodb_io_capacity=10000
innodb_io_capacity_max=16000
innodb_lru_scan_depth=1024
innodb_sort_buffer_size=32M
innodb_ft_cache_size=70M
innodb_ft_total_cache_size=1G
innodb_lock_wait_timeout=300
slave_parallel_threads=5
slave_parallel_mode=optimistic
slave_parallel_max_queued=10000000
log_slave_updates=on
performance_schema=on
skip-name-resolve
max_allowed_packet = 512M
query_cache_type=0
query_cache_size = 0
query_cache_limit = 1M
query_cache_min_res_unit=1K
max_connections = 1500
table_open_cache=64K
innodb_open_files=64K
table_definition_cache=64K
open_files_limit=1020000
collation-server = utf8_general_ci
character-set-server = utf8
log-error=/opt/log/error.log
log-error=/opt/log/error.log
pid-file=/var/run/mysqld/mysqld.pid
malloc-lib=/usr/lib64/libjemalloc.so.1

Answer 1

Вы увлеклись увеличивающимися значениями в my.cnf.

Многие из кэшей растут до достижения своего предела, отсюда и рост памяти, который вы испытали.

Каково значение из SHOW GLOBAL STATUS LIKE 'Max_used_connections';? Большое значение max_connections подчеркивает некоторые другие значения; понизьте его.

Но, возможно, действительно плохие (ие) задействуют кеши таблиц - которые имеют единицы таблиц , а не байтов . Свернуть их много:

table_open_cache=64K
innodb_open_files=64K
table_definition_cache=64K

Answer 2

Попробуйте с tcmallo c

Environment = "LD_PRELOAD = / usr / lib / x86_64- linux -gnu / libtcmalloc_minimal.so.4.5.3.1"

Answer 3

Пожалуйста, прочитайте мои предыдущие комментарии об альтернативных распределителях памяти ...

Когда используется jemallo c:

Когда используется распределитель памяти по умолчанию:

Answer 4

Я решил это! Проблема заключается в библиотеке выделения памяти.

Если вы выполните этот запрос SQL:

ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'version_malloc_library';

Вы должны получить значение библиотеки "jemallo c". Если вы получаете только «system», у вас могут возникнуть проблемы.

Чтобы изменить это, вам нужно отредактировать любой файл .conf в этом каталоге:

/ etc / systemd / system / mariadb.service.d /

Там добавьте эту строку:

Environment = "LD_PRELOAD = / usr / lib / x86_64- linux -gnu / libjemallo c .so.1 "

(этот файл библиотеки может находиться в другой папке)

Затем необходимо перезапустить mysqld

service mysqld stop && systemctl daemon-reload && service mysqld start

Answer 5

У меня точно такая же проблема. Это из-за плохой конфигурации? Или это ошибка новой версии?

mariadb 10.1 была обновлена ​​до 10.3 как раз, когда я обновил Debian 9 до Debian 10. Я пытался решить проблему с mariadb 10.4, но ничего не изменилось.

Я хочу понизить версию, но я думаю, что это необходимый дамп всей базы данных и его восстановление, а это означает, что часы без обслуживания.

Я не думаю, что Debian 10 имеет отношение к проблеме