Производительность Linux Loopback с включенным TCP_NODELAY

Недавно я столкнулся с интересной проблемой производительности TCP при выполнении некоторых тестов производительности, которые сравнивали производительность сети и производительность шлейфа. В моем случае производительность сети превышала производительность loopback (сеть 1Gig, одна и та же подсеть). В случае, когда я занимаюсь задержками, это имеет решающее значение, поэтому TCP_NODELAY включен. Лучшая теория, которую мы придумали, заключается в том, что контроль перегрузки TCP поддерживает пакеты. Мы провели анализ пакетов, и мы можем определенно увидеть, что пакеты хранятся, но причина не очевидна. Теперь вопросы...

1) В каких случаях и почему, если бы связь по шлейфу была медленнее, чем по сети?

2) При отправке как можно быстрее, почему переключение TCP_NODELAY оказывает гораздо большее влияние на максимальную пропускную способность по шлейфу, чем по сети?

3) Как мы можем обнаружить и проанализировать контроль перегрузки TCP как потенциальное объяснение низкой производительности?

4) Есть ли у кого-нибудь другие теории относительно причины этого явления? Если да, то какой метод доказать теорию?

Вот несколько примеров данных, сгенерированных простым приложением С++ для point to point:

Transport     Message Size (bytes)  TCP NoDelay   Send Buffer (bytes)   Sender Host   Receiver Host   Throughput (bytes/sec)  Message Rate (msgs/sec)
TCP           128                   On            16777216              HostA         HostB           118085994                922546
TCP           128                   Off           16777216              HostA         HostB           118072006                922437
TCP           128                   On                4096              HostA         HostB            11097417                 86698
TCP           128                   Off               4096              HostA         HostB            62441935                487827
TCP           128                   On            16777216              HostA         HostA            20606417                160987
TCP           128                   Off           16777216              HostA         HostA           239580949               1871726
TCP           128                   On                4096              HostA         HostA            18053364                141041
TCP           128                   Off               4096              HostA         HostA           214148304               1673033
UnixStream    128                   -             16777216              HostA         HostA            89215454                696995
UnixDatagram  128                   -             16777216              HostA         HostA            41275468                322464
NamedPipe     128                   -             -                     HostA         HostA            73488749                574130

Вот еще несколько полезных сведений:

Я вижу эту проблему только с небольшими сообщения
HostA и HostB имеют одинаковые аппаратный комплект (Xeon [email protected], 32 ядра всего /128 Gig Mem/1Gig Nics)
ОС - это RHEL 5.4 kernel 2.6.18-164.2.1.el5)

Спасибо

Ответ 1

1) В каких случаях и почему, если бы связь по шлейфу была медленнее, чем по сети?

Loopback устанавливает настройку пакета + tcp chksum для обоих tx + rx на том же компьютере, поэтому ему нужно сделать 2x столько же обработки, в то время как с двумя машинами вы разбиваете tx/rx между ними. Это может отрицательно сказаться на шлейфе.

Не уверен, как вы пришли к такому выводу, но loopback vs network реализованы по-разному, и если вы попытаетесь довести их до предела, вы столкнетесь с различными проблемами. Интерфейсы Loopback (как упоминалось в ответ на 1) вызывают накладные расходы tx + rx на одном компьютере. С другой стороны, сетевые адаптеры имеют # лимитов с точки зрения количества выдающихся пакетов, которые они могут иметь в своих циклических буферах и т.д., Что приведет к совершенно другим узким местам (и это сильно отличается от чипа и чипа, и даже от коммутатора, который их)

Контроль перегрузки запускается только в случае потери пакетов. Вы видите потерю пакетов? В противном случае вы, вероятно, нажимаете ограничения на размер окна tcp и коэффициенты латентности сети.

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

Последнее замечание: небольшие сообщения создают гораздо более высокую производительность в вашей сети по разным причинам, например:

существует фиксированная накладная плата (для заголовков mac + ip + tcp), и чем меньше полезная нагрузка, тем больше накладных расходов у вас будет.
многие ограничения NIC относятся к # выдающихся пакетов, что означает, что вы столкнетесь с узкими местами NIC с гораздо меньшим количеством данных при использовании меньших пакетов.
сама сеть как служебная накладная плата, поэтому максимальное количество данных, которые вы можете перекачивать через сеть, зависит от размера пакетов снова.

Ответ 2

1 или 2) Я не уверен, почему вы вообще пытаетесь использовать loopback, я лично не знаю, насколько он будет имитировать реальный интерфейс и насколько он будет действительным. Я знаю, что Microsoft отключает NAGLE для интерфейса loopback (если вам интересно). Взгляните на эту ссылку, там обсуждается это.

3) Я бы внимательно рассмотрел первые несколько пакетов в обоих случаях и посмотрел, если вы получаете серьезную задержку в первых пяти пакетах. См. здесь

Ответ 3

Это та же проблема, с которой я столкнулся. При передаче 2 МБ данных между двумя компонентами, работающими на одной машине RHEL6, требуется 7 секунд. Когда размер данных велик, время неприемлемо. Для передачи 10 МБ данных потребовалось 1 мин.

Затем я попытался отключить TCP_NODELAY. Он решил проблему

Это не происходит, когда два компонента находятся в двух разных машинах.