Назад | Перейти на главную страницу

Проблемы с производительностью AWS RDS MySQL

Мы находимся в процессе переноса наших баз данных из экземпляра MSSQL Server AWS RDS на экземпляр AWS MySQL 8.0.17 RDS.

Наше веб-приложение использует ORM / hibernate для взаимодействия с базой данных, при этом 1 приложение привязано к 1 базе данных.

сервер базы данных в настоящее время содержит 172 db, примерно 260 таблиц на db (всего 44 479 таблиц), настройка с 1 пользователем с доступом ко всем db (есть только 4 других пользователя system / aws, возвращенных из "select * from mysql.user" )

процесс запуска приложения требует ORM для проверки informaton_schema

К сожалению, в настоящее время для запуска одного веб-приложения требуется более 10 минут, так как база данных MySQL, похоже, изо всех сил пытается получить доступ к information_schema, обычно застряла в статусе «проверка разрешений» на срок до 5 секунд, а также, похоже, выполняет сотни эти поиски в базе данных

на нашем промежуточном сервере одно и то же веб-приложение запустилось менее чем за минуту из-за наличия только 8 дБ, а не 172

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

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

innodb_stats_on_metadata=0 innodb_stats_persistent=0

Есть ли у кого-нибудь идеи о том, как мы можем оптимизировать MySQL для получения желаемой производительности.

Любая помощь / совет по ускорению наших запросов схемы приветствуется

---- Больше информации ----

Спасибо за ответы. По запросу ниже приведены URL-адреса Pastebin для получения дополнительной информации.

Глобальный статус - pastebin.com/Je40S48C Показать переменные - pastebin.com/FaN66Zrn

Что касается ОЗУ, то это взято с промежуточного сервера, который является экземпляром RDS (db.t3.small), поэтому имеет только 2 ГБ ОЗУ и 2 виртуальных ЦП. Я пытаюсь подключиться только к двум базам данных, а остальные - фиктивны, чтобы имитировать живое количество таблиц. Первоначально мы заметили это на db.r5.4xlarge, который имеет 128 ГБ ОЗУ и 16 виртуальных ЦП, поэтому я уверен, что память или ЦП не являются проблемой. Как только наше приложение будет запущено

Скорость в секунду = RPS

Рекомендации для вашего промежуточного сервера Группа параметров AWS RDS [mysqld] раздел

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, которые помогут повысить производительность.