Проблемы производительности AWS RDS MySQL
Мы находимся в процессе миграции наших баз данных с экземпляра MSSQL Server AWS RDS на экземпляр AWS MySQL 8.0.17 RDS
Наше веб-приложение использует ORM/hibernate для взаимодействия с базами данных, с 1 приложением, привязанным к 1 базе данных
сервер баз данных в настоящее время содержит 172 базы данных, с примерно 260 таблицами в каждой базе данных (44 479 таблиц в общей сложности), настройка с 1 пользователем с доступом ко всем базам данных (есть только 4 других пользователя system/aws, возвращенных из "select * from mysql. user")
процесс запуска приложения требует от ORM проверки информационной схемы
к сожалению, в настоящее время запуск одного веб-приложения занимает более 10 минут, поскольку база данных MySQL, похоже, испытывает трудности с доступом к информационной схеме, обычно застревая на статусе "проверка разрешений" на 5 секунд, а также, похоже, выполняя сотни таких поисков по каждой базе данных
на нашем промежуточном сервере, то же самое веб-приложение запускалось менее чем за минуту, из-за того, что у нас было только 8 баз данных, а не 172
мы воссоздали ту же проблему медлительности, добавив дополнительные 164 базы данных на тестовый сервер, что указывает на то, что проблема заключается в количестве баз данных/таблиц на сервере
мы уже применили следующие настройки, но это не улучшило производительность:
innodb_stats_on_metadata=0 innodb_stats_persistent=0
Есть ли у кого-нибудь идеи о том, как мы можем оптимизировать MySQL дальше, чтобы получить желаемую производительность.
Любая помощь / совет по ускорению запросов к схеме будет очень признателен
---- Дополнительная информация ----
Спасибо за ваши ответы. Как и просили, ниже приведены URL-адреса Pastebin для получения дополнительной информации
Глобальный статус - pastebin.com/Je40S48C Show Variables - pastebin.com/FaN66Zrn
Что касается оперативной памяти, то вышеприведенные данные взяты с промежуточного сервера, который является экземпляром RDS (db.t3.small), поэтому имеет только 2Gb RAM и 2 vCPU. Однако я пытаюсь подключиться только к двум базам данных, а остальные являются фиктивными, чтобы имитировать живое количество таблиц. Мы изначально заметили это на db.r5.4xlarge, который имеет 128 Gb RAM и 16 vCPU, поэтому я уверен, что память или CPU не являются проблемой. Когда наше приложение запущено и работает
Скорость в секунду = RPS
Рекомендации, которые следует учитывать для промежуточного сервера Группа параметров AWS RDS [mysqld] section
innodb_change_buffer_max_size=2 # from 25 (percent) set aside from buffer pool.
innodb_buffer_pool_instances=1 # from 64 - you only have 2GB RAM, to save CPU cycles
innodb_adaptive_max_sleep_delay=20000 # from 150000 for limit of 2 second delay
innodb_io_capacity=1900 # from 200 to use more of SSD IOPS capacity
read_rnd_buffer_size=128K # from 512K to reduce handler_read_rnd_next RPS of 146,131
read_buffer_size=512K # from 128K to reduce handler_read_next RPS of 129,135
innodb_open_files=4000 # from 300 to be paired with table_open_cache of 4000
innodb_page_cleaners=2 # from 64 since you will be running with 1 instance
innodb_parallel_read_threads=2 # from 4 for no more than # cores
Вы должны обнаружить, что эти изменения значительно уменьшат загруженность ЦП.
На нашей странице служебных сценариев вы найдете бесплатные загружаемые сценарии, в частности findfragtables.sql и find-redundant-indexes.sql, которые помогут повысить производительность.