Вычисление памяти MySQL (MariaDB) и прирост использования

Вопрос или проблема

Я использовал калькулятор памяти mysql (http://www.mysqlcalculator.com), чтобы оценить использование памяти моего выделенного сервера mysql с 8 ГБ ОЗУ и 4 ЦП.

Вот фактические цифры и расчет моего использования:

binlog_cache_size                   32.00 KB
innodb_buffer_pool_size             5120.00 MB
innodb_log_buffer_size              8.00 MB
join_buffer_size                    1.00 MB
key_buffer_size                     128.00 MB
max_connections                     150
query_cache_size                    0
read_buffer_size                    128.00 KB
read_rnd_buffer_size                256.00 KB
sort_buffer_size                    2.00 MB
thread_stack                        292.00 KB
tmp_table_size                      32.00 MB
=================================== ==========
Total Max Memory                    5841.73 MB
=================================== ==========

В течение недели память постоянно увеличивалась намного выше расчетных показателей, пока не использовала почти все 8 ГБ и не снижалась обратно, пока движок не перезапускался.

Поэтому я предполагаю, что есть какая-то переменная, которая была исключена из расчета и вызывает это чрезмерное использование.

Есть ли предложения, что я могу сделать, чтобы устранить эту проблему?

Хорошо, кажется, что есть ошибка в этом калькуляторе (http://www.mysqlcalculator.com/).

tmp_table_size

Должен включаться в расчеты по соединениям, а не в базовые расчеты памяти.

Базовые переменные памяти – это те, которые перечислены выше max_connections, а переменные по соединениям перечислены ниже.

Это сильно изменило расчет и объясняет, почему фактическое использование не совпадало с расчетами.

Это опубликовано благодаря: @Christopher Schultz

SELECT ( @@key_buffer_size
+ @@query_cache_size
+ @@innodb_buffer_pool_size
+ @@innodb_additional_mem_pool_size
+ @@innodb_log_buffer_size
+ @@max_connections * ( @@read_buffer_size
+ @@read_rnd_buffer_size
+ @@sort_buffer_size
+ @@join_buffer_size
+ @@binlog_cache_size
+ @@thread_stack
+ @@tmp_table_size )
) / (1024 * 1024 * 1024) AS MAX_MEMORY_GB;

Вам также стоит обратить внимание на этот отличный калькулятор от Releem.

https://releem.com/tools/mysql-memory-calculator

mysqlcalculator.com, к сожалению, не учитывает некоторые важные настройки. И другой ответ не совсем полный. Это из удобной статьи по настройке MySQL/MariaDB:

SELECT (
       (
           @@binlog_file_cache_size +
           @@innodb_buffer_pool_size +
           @@innodb_log_buffer_size +
           @@key_buffer_size +
           @@query_cache_size +
           ( @@max_connections *
               ( @@binlog_cache_size +
                 @@binlog_stmt_cache_size +
                 @@bulk_insert_buffer_size +
                 @@join_buffer_size +
                 @@max_allowed_packet +
                 @@read_buffer_size +
                 @@read_rnd_buffer_size +
                 @@sort_buffer_size +
                 @@thread_stack +
                 @@tmp_table_size
               )
           ) +
           ( @@slave_parallel_threads * 
             ( @@slave_parallel_max_queued )
           ) +
           ( @@open_files_limit * 1024)
       ) / 1024 / 1024 / 1024) AS max_memory_GB;

Отрегулируйте эти настройки, пока все не поместится в вашу ОЗУ.

Раскрытие информации: я написал упомянутую статью.

Ответ или решение

Расчет потребления памяти MySQL (MariaDB) и использование ресурсов

Вопрос о потреблении памяти в MySQL (или MariaDB) является одним из самых актуальных среди администраторов баз данных. Постепенное возрастание потребления памяти может указывать на различные проблемы, которые необходимо устранить для оптимизации работы сервера. Рассмотрим нюансы, связанные с вашим случаем; а также предоставим рекомендации по его решению.

Анализ ситуации

На вашем сервере, имеющем 8 ГБ оперативной памяти и 4 процессора, вы провели расчет использования памяти, используя калькулятор MySQL. Однако, по истечении недели работы, память стабильно увеличивалась и приближалась к пределу 8 ГБ, не возвращаясь обратно, до перезагрузки сервера. Этот факт указывает на наличие ошибок в расчетах и возможных неучтенных параметров конфигурации.

В вашем случае, первоначальный калькулятор упустил важные аспекты, касающиеся присоединенной памяти к соединениям, такие как:

  1. tmp_table_size – размер временных таблиц, который должен рассчитываться как часть подключения, а не как базовое значение.

Это приводит к значительным отличиям между расчетом и фактическим потреблением, поскольку при каждом подключении к базе создается отдельное подразделение памяти для временных таблиц, что может указывать на потенциальную утечку памяти или неправильную настройку.

Рекомендации по дополнительному анализу

Для более точного расчета общего потребления памяти следует использовать альтернативный подход, который включает все значимые конфигурационные переменные. Пример SQL-запроса для вычисления максимального объема потребляемой памяти, учитывая все параметры, показан ниже:

SELECT (
   (
       @@key_buffer_size +
       @@query_cache_size +
       @@innodb_buffer_pool_size +
       @@innodb_log_buffer_size +
       ( @@max_connections *
           ( @@read_buffer_size +
             @@read_rnd_buffer_size +
             @@sort_buffer_size +
             @@join_buffer_size +
             @@binlog_cache_size +
             @@thread_stack +
             @@tmp_table_size )
       )
   ) / (1024 * 1024 * 1024)
) AS MAX_MEMORY_GB;

Этот запрос позволяет точнее оценить максимальный размер памяти и обнаружить, какие параметры в наибольшей степени способствуют росту использования.

Дополнительные аспекты для рассмотрения

  1. Параметры соединения: Поскольку количество активных соединений может динамически меняться, это напрямую влияет на память. Оцените, какое максимальное количество соединений было достигнуто. Убедитесь, что параметр max_connections соответствует реальным нуждам.

  2. Утечки памяти: Если ваше приложение не освобождает ресурсы, выделенные для соединений, это может приводить к накапливанию памяти с течением времени. Используйте инструменты мониторинга (например, Performance Schema или сторонние решения) для отслеживания роста использования памяти.

  3. Проверка журналов: Обратите внимание на логи MySQL на наличие ошибок, связанных с коннектами и выполнением запросов, которые могут быть индикатором неправильной работы.

Заключение

Поддержание оптимального уровня потребления памяти Ваша база данных является ключевым аспектом для обеспечения ее стабильной и быстрой работы. Если вы столкнулись с проблемой увеличение использования памяти на сервере MySQL (MariaDB), правильная оценка потребления памяти с учетом всех возможных параметров становится необходимым шагом.

Рекомендуем также ознакомиться с калькуляторами памяти, такими как те, что представлены на Releem или Shattered Silicon, которые помогут вам более точно прогнозировать использование ресурсов и увеличить эффективность работы вашего сервера.

Оцените материал
Добавить комментарий

Капча загружается...