У меня MySQL 5.7.27 под Ubuntu 16.04.4, 64-битная, 4 ГБ оперативной памяти и твердотельные накопители (это виртуальная машина). Я наблюдаю за ростом резидентной памяти в mysqld до тех пор, пока ресурсы не станут доступными, и операционная система убивает / перезапускает mysqld.
Некоторый фон - Система используется для сбора информации из удаленных местоположений, при этом по одному объекту собирается из каждого местоположения. Каждый объект может иметь много сотен точек данных. Для каждого удаленного местоположения есть две базы данных, которые поддерживают две ситуации: каждое местоположение для каждого клиента (но у одного клиента может быть много - тысячи - таких местоположений), а в некоторых ситуациях это может быть много тысяч объектов, собираемых из каждогоудаленное местоположение. Две БД соответствуют необработанным данным, собранным и «обработанным» сводкам. Кроме того, существует одна дополнительная БД для каждого администратора записи клиента и другие данные о каждом удаленном местоположении. Таким образом, общее количество БД составляет C * (1 + 2L) - C для клиента, L для местоположения. Первая БД 2L имеет 32 таблицы и минимальный размер 2 МБ (но у меня есть хотя бы один пример, который имеет 5,9 ГБ - не в этом текущем наборе выборок) - он «очищается» в начале каждого события сбора;вторая имеет 12 таблиц, и типичный размер в текущем наборе выборок составляет 1 МБ (хотя это накапливается для каждого события сбора).
Удаленный сбор выполняется периодически, скажем, раз в неделю или раз в месяц, для каждого удаленного местоположения. ,После каждой коллекции запускается процесс для суммирования данных из ВСЕХ баз данных 2L в одну объединяющую.
В системе с проблемой есть C (1 + 2L), равный чуть более 5000. Когда выполняется процесс суммирования, резидентная память mysqld (при просмотре с использованием top) увеличивается с 800 МБ до чуть ниже3GB. Процесс суммирования завершается, и затем может выполняться снова через некоторое время. Этот процесс завершает аккуратно и правильно выдаёт результаты запроса и закрывает соединения с БД. Приложение - это PHP 7.2.24 CLI, работающий локально (т. Е. С использованием сокетов, а не TCP).
Я попытался "настроить":
open_files_limit = 11000
table_open_cache = 5200
innodb_lru_scan_depth = 128
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 1073741824
(см. open_files_limit , table_open_cache , innodb_lru_scan_depth , innodb_flush_log_at_trx_commit , innodb_buffer_pool_size изменится * * * * * * * * * * * * * * * * * *роста использования памяти. Я также запускал show engine performance_schema status; в трех случаях: когда резидентная память была на 2459 МБ, 2478 МБ и 2910 МБ. Между этими тремя примерами я видел различия только в следующих показателях:
2459MB 2478MB 2910MB
(digest_hash).count 4676 -> 4837 -> 4958
(filename_hash).count 121118 -> 121139 -> 121214
(table_share_hash).count 27229 -> 27247 -> 27276
mutex_instances.count 29696 -> 30720 -> 31744
mutex_instances.memory 3801088 -> 3932160 -> 4063232
performance_scheme.memory 426293432 -> 426424504 -> 4266886648
rwlock_instances.count 400384 -> 400384 -> 401408
rwlock_instances.memory 51249152 -> 51249152 -> 51380224
Я ожидаю, что в конце каждого прогона суммирования либо "временное" пространство буфера в mysqld будет освобождено, либопросто использовать повторно при следующем запуске этого процесса, учитывая, что он фактически выполняет одинаковую последовательность запросов (и очень похожие обновления) для одного и того же набора баз данных / таблиц. Тот факт, что объем памяти увеличивается, подсказывает мне, что в mysqld есть утечка памяти, или что преднамеренный «буфер», связанный с каким-либо условием сбоя (соединения, блокировки, мьютексы?), Является, по крайней мере, частью причины памятирост. Я предлагаю последнее, потому что я бы посмотрел на то, что сохранится в mysqld между последующими запусками этого процесса суммирования.
Я также попытался запустить mysqltuner.pl (см. http://mysqltuner.com),, но это также вызываетпроблема роста памяти, которая, несомненно, связана с количеством баз данных. Однако, если я могу сослаться на https://dev.mysql.com/doc/refman/5.7/en/database-count-limit.html, независимо от того, какое ограничение MySQL может иметь или не иметь количество баз данных и таблиц, приведенные здесь цифры не являются значимыми дляСам MySQL, даже если они могут быть в базовой ОС. Признаюсь, я был впечатлен тем, что сервер, по-видимому, обрабатывал более 1000 SELECTS в секунду в системе с не очень высокими характеристиками.
Итак , на какие параметры «мониторинга» мне следует обратить внимание, чтобы помочь с настройкой mysql, ОС или платформы, и какие параметры настройки (mysql / OS) были бы наиболее полезны в этой ситуации? Я мог бы просто воспользоваться подходом Jaws ( "Нам понадобится лодка побольше" ), но если проблема, с которой я сталкиваюсь , это памятьутечка, то просто добавление ОЗУ просто откладывает неизбежное.