У меня есть база данных MYSQL, размещенная на RDS с 16 ГБ ОЗУ. Я использую r4.large с 20 ГБ хранилища SSD общего назначения. Мы используем микросервисную архитектуру и 6 бэкэнд-контейнеров. Таким образом, запрос попадет в RDS с этих 6 внутренних серверов.
Операция в нашем приложении имеет больше операций чтения и записи. Мы пробуем нагрузочный тест нашего приложения и используем от 10 до 20 пользователей для нагрузочного теста. Но во время тестирования и когда мы привлекли почти 20 пользователей для нагрузочного теста, мы отметили, что время отклика действительно велико. Проверяя показатели RDS, мы выяснили, что объем свободной памяти уменьшился с 15 ГБ до почти 1 ГБ и также не увеличился.
Основная проблема, с которой мы столкнулись, заключалась в том, что когда мы снова тестировали нагрузку с использованием 10 пользователей, время отклика было действительно большим. Это было несопоставимо с первоначальными результатами тестирования 10 пользователей.
Я не уверен, что проблема связана с освобождаемой памятью или другим фактором. Как я могу разобраться в проблеме и решить ее? Любая помощь будет оценена.
Сколько данных в вашей базе данных? Если это несколько ГБ, значит, он загружается в оперативную память; загрузка не пойдет дальше innodb_buffer_pool_size
, который, вероятно, настроен на что-то ниже 16G.
Что в вашем "нагрузочном тесте"? Это те же запросы, которые будут у вас в производстве? Или это что-то просто для теста. Я спрашиваю, потому что бенчмаркинг часто вызывает собственные проблемы.
Высокое время отклика - либо в запросах отсутствуют индексы (и т. Д.), Либо тест разработан для стресс-тестирования. Последний часто жертвует временем отклика в ошибочной попытке увидеть, сколько пользователей можно обработать. Плохое время отклика оттолкнет пользователей, тем самым аннулируя результат нагрузочного теста «он может обрабатывать до N пользователей».
Укажите, какой тип приложения, как выглядят запросы, как выглядит схема, какие запросы "медленные" и т. Д.