Согласно тому, что я знаю о gp2 из документов AWS (ссылка), диски gp2 быстро разрываются, когда их размер меньше 1000 ГБ. После того, как диск станет больше 1000 ГБ, базовая производительность превысит 3000 IOPS, поэтому термин «взрыв» не может применяться.
Однако, как я вижу в моей текущей базе данных prod с хранилищем gp2 объемом 2 ТБ, пакетный баланс все еще каким-то образом применим ко мне, и хранилище работает значительно быстрее, а пакетный баланс больше 0.
Судя по всему, есть изменения в термине AWS Burst. Кто-нибудь знает современные термины, чтобы я мог соответствующим образом спланировать свое оборудование?
Сама метрика @Marcin не имеет большого значения. Важно то, что ясно видно, что скорость ввода-вывода в базе данных ухудшается, когда баланс становится равным 0. Это означает, что баланс действительно имеет значение.
Какой экземпляр БД вы используете?
@Marcin db.m5.2xlarge
db.m5 - экземпляр на основе Nitro. Метрика взрыва вообще не должна сообщаться для вас. Это сбивает с толку. Я думаю, что если вы не получите удовлетворительного ответа на SO, возможно, вам придется обратиться в службу поддержки AWS, чтобы разобраться в этом.
@Marcin Дело в том, что поддержка AWS составляет 7% от ежемесячного счета, а это означает, что мне придется потратить около 2 тысяч долларов США, чтобы спросить о том, что на самом деле должно быть описано в их документах. Поэтому я дал шанс ТАК сначала :)





Я столкнулся с этой проблемой при работе с EFS: предоставление достаточной емкости (хранилище и пропускная способность) — это одно, а обеспечение максимальной емкости — совсем другое. В этом случае кажется, что вы столкнулись с той же проблемой. Превышение вашей взрывной мощности. Если у вас есть приложение с большим количеством операций чтения, рассмотрите возможность использования реплики или схемы кэширования. В качестве альтернативы вы можете увеличить свой диск с 2 ТБ до 4 ТБ или изучить подготовленное решение iops.
Для gp2 более 1 ТБ пропускная способность не имеет значения. Как вы можете «превзойти» его? У вас есть дополнительная информация или ссылки на это?
Максимальное количество операций ввода-вывода в секунду для GP2 составляет 16000. Если вы превысите это значение, вы столкнетесь с ограничениями пропускной способности. io1 облегчит это. aws.amazon.com/blogs/database/…
@MichaelQuale Согласно вашей ссылке и моей ссылке в вопросе «Функция пакетной передачи ограничена объемами, равными или меньшими, чем 1 ТиБ хранилища». Однако мое хранилище составляет 2 ТБ, и я все еще вижу некоторое влияние взрыва. Я не должен ощущать этого воздействия, согласно статье. Поэтому я задаю свой вопрос, чтобы прояснить это.
На снимке экрана я вижу, что AWS уже обеспечивает производительность, которую они обещали для вашего экземпляра (6K IOPS, постоянно).
Таким образом, остается вопрос: почему до сих пор существует взрывная производительность, которая позволяет увеличить производительность до > 11 000 операций ввода-вывода в секунду (с 7:00 до 9:00) в течение ограниченного времени.
Я предполагаю, что ограничение на пакетную передачу 3K IOPS предназначено только для экземпляров с объемом менее 1 ТБ. Например, для большего размера вы можете увеличить «Базовую производительность + 3 000 операций ввода-вывода в секунду» (около 9 000 в вашем случае), пока не закончится кредит ввода-вывода. Я не видел ни одного документа по этому поводу, хотя
Верно. Конечно, хорошо, что есть какой-то "неожиданный всплеск", но то, что он недокументирован и противоречит текущей документации - не круто, ведь правила должны быть понятны всем.
Я сделал запрос в поддержку AWS по этому поводу. Это была длинная ветка, в которой я узнал несколько важных фактов. Я сохранил свою беседу по этой ссылке, чтобы она не потерялась для сообщества.
Ответ: баланс burts может по-прежнему применяться для хранилища объемом более 1 ТБ, поскольку может быть несколько томов для обслуживания хранилища. Если объем меньше 1 ТБ, для этого тома используется пакетный баланс.
Другие факты, которые были неясны для меня:
Спасибо, что проследили и обновили это. Когда я впервые прочитал это, я сравнил взрывной кредит с некоторыми предыдущими боевыми шрамами AWS.
Если вы проверяете непосредственно в CloudWatch Metrics, а не в консоли RDS, отображается ли то же самое?