Производительность 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 между ними. Это может отрицательно сказаться на шлейфе.
2) При отправке как можно быстрее, почему переключение TCP_NODELAY оказывает гораздо большее влияние на максимальную пропускную способность по шлейфу, чем по сети?
Не уверен, как вы пришли к такому выводу, но loopback vs network реализованы по-разному, и если вы попытаетесь довести их до предела, вы столкнетесь с различными проблемами. Интерфейсы Loopback (как упоминалось в ответ на 1) вызывают накладные расходы tx + rx на одном компьютере. С другой стороны, сетевые адаптеры имеют # лимитов с точки зрения количества выдающихся пакетов, которые они могут иметь в своих циклических буферах и т.д., Что приведет к совершенно другим узким местам (и это сильно отличается от чипа и чипа, и даже от коммутатора, который их)
3) Как мы можем обнаружить и проанализировать контроль перегрузки TCP как потенциальное объяснение низкой производительности?
Контроль перегрузки запускается только в случае потери пакетов. Вы видите потерю пакетов? В противном случае вы, вероятно, нажимаете ограничения на размер окна tcp и коэффициенты латентности сети.
4) Есть ли у кого-нибудь другие теории относительно причины этого явления? Если да, то какой метод доказать теорию?
Я не понимаю феномен, о котором вы здесь говорите. Все, что я вижу в вашей таблице, это то, что у вас есть несколько сокетов с большим буфером отправки - это может быть совершенно законным. На быстрой машине ваше приложение, безусловно, будет способно генерировать больше данных, чем сеть может откачивать, поэтому я не уверен, что вы классифицируете как проблему здесь.
Последнее замечание: небольшие сообщения создают гораздо более высокую производительность в вашей сети по разным причинам, например:
- существует фиксированная накладная плата (для заголовков mac + ip + tcp), и чем меньше полезная нагрузка, тем больше накладных расходов у вас будет.
- многие ограничения NIC относятся к # выдающихся пакетов, что означает, что вы столкнетесь с узкими местами NIC с гораздо меньшим количеством данных при использовании меньших пакетов.
- сама сеть как служебная накладная плата, поэтому максимальное количество данных, которые вы можете перекачивать через сеть, зависит от размера пакетов снова.
Ответ 2
1 или 2) Я не уверен, почему вы вообще пытаетесь использовать loopback, я лично не знаю, насколько он будет имитировать реальный интерфейс и насколько он будет действительным. Я знаю, что Microsoft отключает NAGLE для интерфейса loopback (если вам интересно). Взгляните на эту ссылку, там обсуждается это.
3) Я бы внимательно рассмотрел первые несколько пакетов в обоих случаях и посмотрел, если вы получаете серьезную задержку в первых пяти пакетах. См. здесь
Ответ 3
Это та же проблема, с которой я столкнулся. При передаче 2 МБ данных между двумя компонентами, работающими на одной машине RHEL6, требуется 7 секунд. Когда размер данных велик, время неприемлемо. Для передачи 10 МБ данных потребовалось 1 мин.
Затем я попытался отключить TCP_NODELAY
. Он решил проблему
Это не происходит, когда два компонента находятся в двух разных машинах.