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

Странная производительность операций ввода-вывода в секунду на инстансах AWS R3.large и R4.large

Я использовал 4 тома GP2 EBS по 10 ГБ с RAID0 в образе Windows Server 2012R2, как описано здесь: http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/raid-config.html Я использовал тип экземпляра R3.large.

Я ожидал увидеть 4 * 3000 (12K IOPS), когда разрывной пул будет заполнен, но я постоянно получаю только до 7480 IOPS. Это хорошо.

После этого я изменил тип экземпляра на R4.large, который должен использовать более новую версию процессора (Broadwell вместо Ivy Bridge) и, скорее всего, быстрее. Все остальное я оставил прежним, те же диски, та же ОС, тот же тест: производительность была хуже, чем у R3.large, около 6480 IOPS.

В чем проблема? Почему более новое поколение той же группы экземпляров (R- "Memory Intensive") будет работать хуже, чем раньше?

Ваше ограничение, похоже, исходит из сетевых ограничений на тип экземпляра, а не из самой EBS.

Между строк требуется некоторое чтение, но Оптимизированные экземпляры EBS документация рассказывает интересную историю - ваши цифры на самом деле лучше, чем предполагаемое количество операций ввода-вывода в секунду, которые, по утверждениям, могут поддерживать типы инстансов.

Экземпляры EBS Optimized имеют два сетевых пути, один из которых предназначен для подключения EBS, вместо того, чтобы иметь только один сетевой путь, общий для всего IP-трафика, входящего и исходящего из экземпляра ... поэтому, хотя в документации это не указано явным образом, скорости кажутся одинаковыми независимо от того, оптимизирован ли экземпляр для EBS или нет, с той разницей, что для оптимизированных экземпляров трафик EBS не обязательно должен совместно использовать один и тот же канал. Общая пропускная способность экземпляра удваивается: половина выделяется для EBS, а половина - для всего остального.

Вы упомянули об использовании экземпляра r3.large, и он не показан в таблице ... но если мы экстраполируем назад от r3.xlarge, числа там будут довольно маленькими.

Как отмечено в документации, оценки IOPS равны «Округленное приближение на основе 100% рабочей нагрузки только для чтения» и что, поскольку соединения с указанной скоростью являются полнодуплексными, числа могут быть больше при сочетании чтения и записи.

type       network mbits/s mbytes/s estimated peak IOPS

r4.large            400       50        3,000
r4.xlarge           800      100        6,000

r3.large            250       31.25     2,000 (ratio-based speculation)
r3.xlarge           500       62.5      4,000

Тестирование одного из моих r3.large путем сканирования первых 512 МБ из 500 ГБ тома gp2, похоже, подтверждает эту скорость сети. Этот компьютер не оптимизирован для EBS и не обрабатывал значительную рабочую нагрузку во время проведения этого теста. Это согласуется с моими предыдущими наблюдениями о r3.large. В течение некоторого времени я предполагал, что эти машины имеют скорость подключения только 0,25 Гбит / с, но казалось, что этот тест стоит повторить. Это, конечно, система Linux, но все основные принципы должны соблюдаться.

# sync; echo 1 > /proc/sys/vm/drop_caches; dd if=/dev/xvdh bs=1M count=512 | pv -a > /dev/null
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 14.4457 s, 37.2 MB/s
[35.4MB/s]

Это очень похоже на сетевое соединение со скоростью ~ 250 мегабит / с, что, когда вам нужна пропускная способность хранилища, не является большой пропускной способностью. Как ни странно, если ваша рабочая нагрузка подходит для кредитной модели ЦП t2, вы действительно получите лучшую производительность от t2, чем от r3.