Когда я тестирую свои собственные экземпляры «10 Gigabit» (c3.8xlarge) с помощью iperf, я не вижу скорости передачи, превышающей 1,73 Гбит / с. Это как минимум в четыре раза хуже, чем то, что сообщает блогер из scaleablelogic, где тесты показывают результаты 7 Гбит / с и 9,5 Гбит / с.
Я тестирую между двумя экземплярами c3.8xlarge, расположенными в одной и той же зоне и регионе, поэтому это должны быть оптимальные условия для тестирования. Один c3.8xlarge действует как сервер iperf, а другой как клиент iperf. Оба инстанса запускаются с Amazon Linux AMI 2013.09.2 - ami-5256b825 (64-разрядная версия).
Почему я вижу такие плохие результаты?
На что следует обратить внимание, если я хочу повысить пропускную способность?
AWS Support признает, что скорость 10 GbE может быть достигнута только между экземплярами в частной сети подсети. Это требует, чтобы использовался частный IP-адрес, а не общедоступный IP-адрес, который в моем случае всегда достигает 1,73 Гбит / с. Это может измениться в зависимости от зоны и региона. Если вы видите другие результаты, опубликуйте их здесь.
Это означает, что когда дело доходит до внешней пропускной способности, c3.8xlarge (или аналогичные экземпляры 10 GbE) предлагают ужасную ценность по сравнению с меньшими экземплярами с «высокими» сетевыми возможностями. Экземпляр c1.medium стоит 1/16 от стоимости c3.8xlarge, но он обеспечивает более половины пропускной способности (~ 0,95 Гбит / с) экземпляра c3.8xlarge 10 GbE (~ 1,7 Гбит / с).
Видеть эта тема на форумах Wowza, где можно найти ответы на AWS Support.
Из-за уровня виртуализации сетевой уровень не может напрямую использовать DMA, и ЦП должен копировать данные туда и обратно, тратя время на softtirq. В этом случае, когда у вас передано слишком много пакетов, вам нужно указать ядру использовать для этого более одного ядра процессора.
Вы можете контролировать это, выполнив watch -n1 cat /proc/softirqs
и глядя на NET_RX.
К счастью, есть функция под названием пакетное управление которые позволяют нам использовать больше ядер ЦП для приема и передачи пакетов.
Чтобы позволить ЦП использовать более одного ядра для приема пакетов, вы можете сделать echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
Для перехода вы можете сделать echo f0 > /sys/class/net/eth0/queues/tx-0/xps_cpus
Таким образом, первые 4 ядра будут использоваться для приема, а следующие 4 ядра - для передачи.
f => 1+2+4+8 = 15 in hexadecimal
f0 => 16+32+64+128 = 240 in hexadecimal
Надеюсь, это поможет вам, мы какое-то время интересовались реальной пропускной способностью EC2 для общественности. Мы только что завершили запуск нескольких экземпляров Wowza Edge на экземплярах C4.8xl, и у нас не было проблем со скоростью 6+ Гбит / с на экземпляр. За http://www.aerospike.com/blog/boosting-amazon-ec2-network-for-high-throughput/, приведенные ниже тесты кажутся очень точными:
* Пропускная способность сети Amazon предлагает ряд типов инстансов с разным объемом памяти и ЦП. Однако что не очень хорошо «документировано», так это возможности сети, которые просто классифицируются как низкие, умеренные, высокие и 10 Гбит / с. Основываясь на наших экспериментах с серверами Aerospike на AWS и iperf на AWS, мы смогли лучше определить эти категории по следующим числам:
Я не уверен, как вы запускаете iperf для своих тестов, но иногда его нужно запускать в многопоточном режиме, чтобы получить результаты, которые лучше отражают фактическую максимальную пропускную способность базового сетевого стека. Я видел, что иногда необходимо увеличивать количество потоков до 96, чтобы получить то, что казалось близким к оптимальной пропускной способности.