Вопрос: Почему производительность TCP accept () настолько плоха под Xen?


Скорость, с которой мой сервер может принимать () новые входящие TCP-соединения, очень плохо под Xen. Тот же тест на голое металлическое оборудование показывает 3-5-кратное ускорение.

  1. Почему это так плохо под Xen?
  2. Можете ли вы настроить Xen для повышения производительности для новых TCP-соединений?
  3. Существуют ли другие платформы виртуализации, более подходящие для такого рода прецедентов?

Задний план

В последнее время я изучаю некоторые узкие места производительности встроенного Java-сервера под управлением Xen. Сервер говорит HTTP и отвечает на простые запросы TCP connect / request / response / disconnect.

Но даже при отправке ловушек трафика на сервер он не может принимать более ~ 7000 TCP-соединений в секунду (на 8-ядерном экземпляре EC2, c1.xlarge running Xen). Во время теста сервер также обнаруживает странное поведение, когда одно ядро ​​(не обязательно cpu 0) получает очень загружен> 80%, в то время как другие ядра остаются почти бездействующими. Это заставляет меня думать, что проблема связана с ядром / базовой виртуализацией.

При тестировании одного и того же сценария на голой металлической, невиртуализированной платформе я получаю результаты теста, показывающие скорости приема TCP () выше 35 000 в секунду. Это на Core i5 4-ядерная машина, работающая под управлением Ubuntu со всеми ядрами, почти полностью насыщенными. Для меня такая фигура кажется правильной.

В случае Xen снова я попытался включить / настроить почти все настройки в sysctl.conf. Включая Приемное рулевое управление а также Рулевое управление приема и прикрепление потоков / процессов к процессорам, но без видимых преимуществ.

Я знаю, что ухудшение производительности ожидается при запуске виртуализации. Но до такой степени? Более медленный, голый металлический сервер превосходит добродетель. 8-ядро в 5 раз?

  1. Это действительно ожидаемое поведение Xen?
  2. Можете ли вы настроить Xen для повышения производительности для новых TCP-соединений?
  3. Существуют ли другие платформы виртуализации, более подходящие для такого рода прецедентов?

Воспроизведение этого поведения

При дальнейшем изучении этого и выявлении проблемы я обнаружил, что Netperf инструмент тестирования производительности может моделировать аналогичный сценарий, который я испытываю. Используя TCP_CRR-тест netperf, я собрал различные отчеты с разных серверов (как виртуализированных, так и не-virt.). Если вы хотите внести свой вклад в некоторые выводы или посмотреть мои текущие отчеты, см. https://gist.github.com/985475

Как я узнаю, что эта проблема связана не с плохо написанным программным обеспечением?

  1. Сервер был протестирован на голом металлическом оборудовании, и он почти насыщает все доступные ему ядра.
  2. При использовании TCP-соединений keep-alive проблема исчезает.

Почему это важно?

В ESN (мой работодатель) Я возглавляю проект Beaconpush, сервер Comet / Web Socket, написанный на Java. Несмотря на то, что он очень эффективен и может насыщать почти любую пропускную способность, предоставляемую ему в оптимальных условиях, он по-прежнему ограничен тем, как быстро можно создавать новые TCP-соединения. То есть, если у вас есть большой отток пользователей, где пользователи приходят и уходят очень часто, многие TCP-соединения должны быть настроены / разукрашены. Мы стараемся как можно дольше смягчить эту связь. Но в итоге производительность accept () - это то, что заставляет наши ядра вращаться, и нам это не нравится.


Обновление 1

Кто то отправил этот вопрос в Hacker News, там есть некоторые вопросы / ответы. Но я постараюсь, чтобы этот вопрос обновлялся с информацией, которую я нахожу, когда я иду.

Оборудование / платформы, на которых я тестировал это:

  • EC2 с типами экземпляров c1.xlarge (8 ядер, 7 ГБ ОЗУ) и cc1.4xlarge (2x Intel Xeon X5570, 23 ГБ ОЗУ). Используемые AMI были ami-08f40561 и ami-1cad5275 соответственно. Кто-то также отметил, что «Группы безопасности» (например, брандмауэр EC2) также могут повлиять. Но для этого тестового сценария я пытался только на localhost устранить внешние факторы, такие как это. Еще один слух, который я слышал, заключается в том, что экземпляры EC2 не могут выталкивать более 100 тыс. PPS.
  • Два частных виртуализированных сервера, работающих на Xen. Один из них имел нулевую нагрузку до испытания, но не имел никакого значения.
  • Частный выделенный Xen-сервер в Rackspace. О тех же результатах есть.

Я в процессе повторного запуска этих тестов и заполнения отчетов на https://gist.github.com/985475 Если вы хотите помочь, внесите свой вклад. Это просто!

(План действий был перенесен на отдельный консолидированный ответ)


87
2018-05-22 16:39


Источник


Отличная работа, связанная с проблемой, но я считаю, что вам будет гораздо лучше обслуживаться список рассылки, относящийся к Xen, форум поддержки или даже сайт отчета об ошибках xensource, Я считаю, что это может быть какая-то ошибка планировщика - если вы возьмете количество 7000 подключений * 4 ядра / 0,80 загрузки процессора, вы получите ровно 35 000 - это число, которое вы получите, когда 4 ядра будут полностью насыщены. - the-wabbit
Ах, и еще одна вещь: попробуйте другую (более позднюю, возможно,) версию ядра для вашего гостя, если сможете. - the-wabbit
@ syneticon-dj Спасибо. Я попробовал это на cc1.4xlarge на EC2 с ядром 2.6.38. Я видел около 10% увеличения, если не ошибаюсь. Но это, скорее всего, связано с более жестким оборудованием этого типа экземпляра. - cgbystrom
спасибо за то, что он был в курсе ответов HN, это отличный вопрос. Я предлагаю переместить план действий в консолидированный ответ, возможно, поскольку это все возможные ответы на проблему. - Jeff Atwood
@jeff Переместите план действий, проверьте. - cgbystrom


Ответы:


Прямо сейчас: Небольшая производительность пакета отстой в Xen

(вместо этого перешел от вопроса к отдельному ответу)

По словам пользователя на HN (разработчик KVM?), Это связано с небольшой производительностью пакетов в Xen, а также с KVM. Это известная проблема с виртуализацией, и, по его словам, ESX VMWare справляется с этим намного лучше. Он также отметил, что KVM привносят некоторые новые функции, направленные на облегчение этого (оригинальное сообщение).

Эта информация немного обескураживает, если она правильная. В любом случае, я попытаюсь выполнить следующие шаги, пока не появится какой-то гуру Xen с окончательным ответом :)

Iain Kay из списка рассылки xen-пользователей скомпилировал этот график: netperf graph Обратите внимание на столбцы TCP_CRR, сравните «2.6.18-239.9.1.el5» и «2.6.39 (с Xen 4.1.0)».

Текущий план действий, основанный на ответах / ответах здесь и HN:

  1. Отправьте эту проблему в список рассылки, специфичный для Xen, и bugzilla xensource, как предложено syneticon-dj сообщение было отправлено в список пользователей xen, в ожидании ответа.

  2. Создайте простой патологический тестовый пример на уровне приложения и опубликуйте его.
    Создан тестовый сервер с инструкциями и опубликовано в GitHub, С этим вы сможете увидеть более реальный случай использования по сравнению с netperf.

  3. Попробуйте 32-битный гостевой экземпляр PV Xen, так как 64-битный может вызвать дополнительные накладные расходы в Xen. Кто-то упомянул об этом в HN. Не имело значения.

  4. Попробуйте включить net.ipv4.tcp_syncookies в sysctl.conf, как было предложено abofh на HN. Это очевидно мог бы улучшить производительность, поскольку рукопожатие будет происходить в ядре. Мне не повезло с этим.

  5. Увеличьте отставание от 1024 до чего-то гораздо большего, также предложенное abofh на HN. Это также может помочь, поскольку гость может потенциально принять () больше подключений во время его среза выполнения, заданного dom0 (хостом).

  6. Дважды проверьте, что conntrack отключен на всех машинах, так как он может уменьшить вдвое скорость приема (предлагается deubeulyou). Да, он был отключен во всех тестах.

  7. Проверьте «переполнение очереди очереди сообщений и переполнение буферов синхронизации в netstat -s» (предлагается mike_esspe на HN).

  8. Разделите обработку прерываний между несколькими ядрами (RPS / RFS, которые я пытался включить раньше, должны делать это, но может быть стоит попробовать снова). Предлагается adamt в HN.

  9. Отключение разгрузки сегментации TCP и ускорение разгона / сбора, как предположил Мэтт Бейли. (Невозможно на EC2 или аналогичных хостах VPS)


26
2018-05-22 23:41



+1 Определенно опубликуйте результаты работы, когда узнали! - chrisaycock
Кто-то толкнул меня в Twitter по этому вопросу. К сожалению, похоже, что эти проблемы сохраняются. Я не проводил много исследований с прошлого года. Xen МОЖЕТ быть улучшенным за это время, я не знаю. Разработчик KVM также отметил, что они рассматривают такие проблемы. Можно было бы преследовать. Кроме того, еще одна рекомендация, которую я слышал, заключается в том, чтобы попробовать OpenVZ вместо Xen / KVM, поскольку она добавляет меньше или не выполняет разбиение / перехват системных вызовов. - cgbystrom


Я обнаружил, что отключение аппаратного ускорения NIC значительно улучшает производительность сети на контроллере Xen (также верно для LXC):

Scatter-gather accell:

/usr/sbin/ethtool -K br0 sg off

Разгрузка сегментации TCP:

/usr/sbin/ethtool -K br0 tso off

Где br0 - ваш мост или сетевое устройство на хосте гипервизора. Вам нужно будет настроить это, чтобы отключить его при каждой загрузке. YMMV.


19
2018-05-22 19:09



Я второй это. У меня был сервер Windows 2003, работающий на Xen, который страдал от некоторых ужасных проблем с потерями пакетов в условиях высокой пропускной способности. Проблема исчезла, когда я отключил выключение сегмента TCP - rupello
Благодарю. Я обновил «план действий» в исходном вопросе с вашими предложениями. - cgbystrom
смотрите также cloudnull.io/2012/07/xenserver-network-tuning - Lari Hotari


Может быть, вы могли бы немного разъяснить - вы проводили тесты под Xen на своем собственном сервере или только на экземпляре EC2?

Accept - это еще один syscall, и новые соединения отличаются только тем, что первые несколько пакетов будут иметь определенные флаги - гипервизор, такой как Xen, определенно не видит никакой разницы. Другие части вашей установки могут: в EC2, например, я не удивлюсь, если бы с ними были связаны группы безопасности; conntrack также сообщила о сокращении на два приема новых подключений (PDF),

Наконец, похоже, что комбинации CPU / Kernel вызывают странное использование / зависание процессора на EC2 (и, вероятно, Xen вообще), так как О пользователе Librato,


2
2018-05-22 19:56



Я обновил вопрос и уточнил, на каком оборудовании я это пробовал. abofh также предложил увеличить отставание за пределами 1024, чтобы ускорить количество возможных accept () s во время среза выполнения для гостя. Что касается conntrack, я должен определенно проверить, что такие вещи отключены, спасибо. Я читал эту статью в Либерате, но, учитывая количество разных аппаратных средств, которые я пробовал, это не должно быть так. - cgbystrom


Убедитесь, что вы отключили iptables и другие перехватчики кода моста в dom0. Очевидно, что это применимо только к настройке Xen Bridge networking.

echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables

Это зависит от размера сервера, но на более мелких (четырехъядерный процессор) выделяет один процессор cpu для Xen dom0 и фиксирует его. Параметры загрузки Hypervisor:

dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>

Вы пытались передать физическое Ethernet-устройство PCI в domU? Должно быть хорошее повышение производительности.


0
2018-02-11 11:35