Вопрос или проблема
Я использовал калькулятор памяти 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
=================================== ==========
Итого максимальная память 5841.73 MB
=================================== ==========
На протяжении недели объем памяти просто продолжает увеличиваться гораздо выше оценочных показателей, пока не займёт практически всю доступную оперативную память в 8 ГБ и не опускается обратно, пока движок не будет перезапущен.
Так что я предполагаю, что есть какая-то переменная, которая не была учтена в расчёте и вызывает это чрезмерное использование.
Есть ли какие-нибудь предложения о том, что я могу сделать, чтобы устранить эту проблему?
Хорошо, похоже, что в этом калькуляторе есть ошибка (http://www.mysqlcalculator.com/).
tmp_table_size
Должен быть включен в расчеты на соединение, а не в расчеты базовой памяти.
Переменные базовой памяти — это те, которые перечислены выше max_connections, а переменные на соединение перечислены ниже.
Это значительно изменило расчеты и объясняет, почему фактическое использование не совпадало с расчетами.
Это courtesy of: @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;
К сожалению, 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): Проблемы с утечками и рекомендации
Вопросы, связанные с памятью в системах управления базами данных, становятся все более актуальными в условиях высоких нагрузок и ограниченных ресурсов. Когда память вашей системы начинает превышать ожидаемые пределы, это может вызвать замедление работы, проблемы с производительностью и, в конечном счете, обрушение сервера. Рассмотрим, как правильно оценить использование памяти MariaDB и выявить источники увеличения потребления памяти.
Оценка использования памяти
Вы начали с использования калькулятора памяти MySQL, который, к сожалению, не учел все переменные, что является распространенной проблемой. Правильное начисление памяти должно учитывать как базовые настройки, так и настройки, относящиеся к каждому соединению.
Ваша первоначальная оценка памяти:
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
Тем не менее, как вы упомянули, переменная tmp_table_size
должна быть включена в расчеты, относящиеся к соединениям. Выглядит это так:
Конкретные переменные и их влияние
Для точной оценки памяти необходимо учитывать дополнительные переменные. Общую формулу для максимального использования памяти можно оформить следующим образом:
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) AS MAX_MEMORY_MB;
Проблемы с утечками памяти
На практике вы заметили, что потребление памяти растет с течением времени. Возможные причины этого могут включать:
- Неэффективные запросы: Оптимизация SQL-запросов может значительно снизить использование оперативной памяти.
- Неправильные настройки переменных: Регулировка переменных, таких как
max_connections
,tmp_table_size
,innodb_buffer_pool_size
, может помочь устранить утечки. - Долговременные временные таблицы: Проверьте, нет ли лишних временных таблиц, которые не очищаются автоматически.
- Неоптимизированные индексы: Неправильное индексирование может потребовать больше памяти для хранения информации.
- Параметры конфигурации: Настройки, такие как
innodb_file_per_table
иinnodb_log_file_size
, могут влиять на распределение памяти.
Рекомендации по оптимизации
- Мониторинг: Используйте инструменты мониторинга, такие как
MySQL Enterprise Monitor
илиPrometheus
, чтобы отслеживать использование памяти в реальном времени. - Анализ запросов: Регулярно анализируйте и оптимизируйте запросы с помощью
EXPLAIN
, чтобы снизить нагрузку на память. - Настройка параметров: Используйте представленные формулы для регулярной корректировки параметров конфигурации.
- Очистка неиспользуемых подключений: Убедитесь, что у вас нет неактивных соединений, которые занимают память.
Заключение
Эффективное управление памятью в MySQL (MariaDB) — это сложный и многоступенчатый процесс. Правильно рассчитав потребление памяти и устранив возможные утечки, вы сможете значительно улучшить производительность вашего сервера. Постоянный мониторинг и оптимизация конфигурации помогут поддерживать эффективность системы и предотвратить её крах.