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

Как повысить производительность AWS RDS - обновления с интенсивным чтением и записью

После поиска и прочтения такого количества сообщений, комментариев и обсуждений я обнаружил, что не нашел ни одного, относящегося к моей проблеме.

У меня несколько развертываний AWS EC2 с одним RDS в одной зоне доставки us-west-2 (c)

Я тестирую нагрузку на инстансы, намного меньшую, чем я ожидал очень скоро. Меня беспокоит производительность при загрузке обновлений. Мы будем часто получать обновления по 1000 записей за раз, будем брать и сравнивать наши данные и обновлять наши данные по мере необходимости. Следовательно, одно чтение и одна запись для каждой записи. За час к нам приходит 100 000 обновлений - не редкость.

В настоящее время у меня есть база данных MySQL на RDS класса AWS t2.medium, на котором запущено 5 процессов обновления при 22% ЦП и менее 1 ГБ памяти.

Даже с такими маленькими числами время чтения для поиска в базе данных из 106,3 КБ записей занимает от 2 до 3 полных секунд, а время записи - еще 2 секунды.

Мне нужно подумать о том, как улучшить это время чтения / записи.

Дополнительная информация: у меня тоже работает экземпляр реплики. Сайты, управляемые CMS (100 и растущие ежедневно), подключаются к экземпляру реплики для своего контента.

Спасибо!

Я собираюсь превратить свои комментарии выше в ответ.

Инстансы T2 получают только доля процессора - 10% для t2.micro, 40% для t2.medium. Вы получаете кредиты ЦП, которые накапливаются, но как только вы их используете, производительность ЦП снижается. Вы также получаете более низкую производительность сети и ввода-вывода, поскольку вам приходится совместно использовать ресурсы физических машин.

Я подозреваю, что в вашем тестировании закончились кредиты ЦП, поэтому вас ограничивают. Ты можешь отслеживать кредиты ЦП в CloudWatch это покажет, верна ли моя догадка.

Прав я или нет, инстансы t2 не подходят для систем, в которые постоянно поступает работа. C4 или другой общий экземпляр, вероятно, будет вашим лучшим выбором. Вы можете отслеживать использование памяти базы данных и ЦП в CloudWatch, чтобы определить, какой размер экземпляра базы данных вам нужен.

Обратите внимание на узкое место диска: IOPS диска. RDS будет ограничивать запрос ввода-вывода, если он не предоставлен. На SSD выделяется 3iops / ГБ. Итак, если у вас есть 100 ГБ, выделенные для SSD, вы можете максимально увеличить блок 3x100 = 300 iops.
Если вы платите за выделенный SSD, вы можете выделить больше iops.

В то время как для стандартного (магического) хранилища дополнительный заряд на миллион iops и всплеск составляет 40-200 iops.

Пожалуйста, проверьте свой журнал RDS io, чтобы определить лучшую стратегию disk io. Ссылка на дополнительную информацию: https://stackoverflow.com/questions/18777070/aws-rds-provisioned-iops-really-worth-it

В итоге я создал c4.xlarge EC2 и использовал его в качестве моего сервера MariaDB 10. Из-за большого объема трафика в настоящее время и значительного увеличения, связанного с новыми маркетинговыми кампаниями, я не мог полагаться на RDS, не тратя несколько сотен в месяц. И я нашел множество жалоб на AWS RDS с проблемами, похожими на мои.

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

Всем спасибо за мысли и комментарии!

  • Стивен