Почему несколько подключений с одного и того же хоста обеспечивают лучшую пропускную способность, чем несколько подключений с разных хостов?
Я подозреваю, что это что-то связано с ядром (Linux), но подтверждение очень поможет.
Подробнее У меня есть 1 процесс-получатель, назовем его R. Он принимает входящие соединения и получает данные с помощью select ().
У меня есть 3 процесса-отправителя S1, S2, S3. Они подключаются к R и отправляют данные с фиксированной скоростью, то есть по 200 Мбит / с каждый.
Если S1, S2 и S3 находятся на одной машине, я получаю лучшие результаты, чем каждый из них на другой машине. (R в обоих случаях находится на какой-то другой машине)
Пример: R на host0, S1, S2, S3 на host2, R получает со скоростью 600 Мбит / с
R на host0, S1 на host1, S2 на host2, S3 на host3, R получает со скоростью 480 Мбит / с
Для меня это выглядит нелогично, я ожидал обратного, поскольку во втором случае отправителям не нужно совместно использовать сетевую карту и процессор (не то чтобы процессор или сетевая карта были узкими местами ...)
[Вышеупомянутые хосты - это узлы в кластере Linux с выделенным полнодуплексным гигабитным коммутатором. Они работают под управлением 2.6.24-24-generic (я думаю, последняя версия Ubuntu)]
Я считаю, что это классический вопрос эффективности конвейера.
В случае нескольких хостов-отправителей все они начнут отправлять кадры Ethernet через провод. Эти кадры достигнут задней панели коммутатора и будут помещены в очередь на порту, подключенном к host0. Host0 будет получать их как можно быстрее, но отправители быстро заполнят коммутатор гораздо большим количеством кадров в секунду, чем может доставить порт коммутатора host0. Они пытаются протолкнуть 3 гигабит / с через порт, который может читать только 1 гигабит / с.
Обычно коммутатор может буферизовать эти кадры, если они накапливаются в очереди port0. Но они не могут творить чудеса. Таким образом, коммутатор начнет сбрасывать рамы в пол. В результате будет потеряно множество TCP-пакетов. В этом можно убедиться, проверив увеличение этого счетчика на хостах-отправителях:
netstat -s | grep 'повторная передача сегментов'
Как вы понимаете, повторные передачи только усугубят перегрузку - даже с алгоритмом отсрочки.
Если есть только один хост, он будет передавать со скоростью 1 гигабит / с. И приемник, вероятно, получит все кадры Ethernet, и он должен работать нормально. Я также предлагаю провести индивидуальный тест с использованием UDP, и вы получите еще лучшие результаты. Хороший инструмент для этой задачи - iperf.
Удачи!
В целях обсуждения я предполагаю, что для связи используется TCP / IP. Если это не так, прокомментируйте и дайте мне знать.
Вероятно, вы можете взять пакетный захват и получить полную информацию, но это, вероятно, смещает точку конфликта с единого скоординированного стека TCP / IP на одной машине на несколько отдельных стеков TCP / IP на отдельных машинах и гигабитный стек. переключатель мог быть el-cheapo, который действительно не может его разрезать.
В вашем исходном сценарии один сервер отправляет на другой сервер, используя тот же стек IP. Большинство сетевых адаптеров серверов в наши дни имеют разгрузку TCP и множество аппаратных средств, поэтому они могут довольно хорошо координировать стек IP, с тем, какие кадры и когда отправляются, и выполнять правильное чередование. Это, вероятно, делает стандартный сетевой адаптер доступнее, чем большинство коммутаторов, которые вы можете купить. Однако, перемещая это на отдельные серверы, вы перемещаете точку конфликта на коммутатор, который действительно осведомлен только до уровня 2 (отправка кадра на x MAC-адрес), когда ему необходимо чередовать несколько высокопроизводительных соединений с один порт, у него может просто быть действительно плохой чип и память, что вызывает несогласованные задержки (известные как джиттер), переполнение или даже пропадание кадров. Это потому, что раньше все, что нужно было коммутатору, - это копировать кадры с порта 1 на порт 2 и наоборот, но теперь у него много работы, поскольку у него много кадров, поступающих из 3 источников, которые он должен пытаться чередовать. в течение микросекунд.
Тем не менее, я должен упомянуть некоторые из более простых вещей, которые также могут быть здесь проблемой:
Если у вас немного плохой кабель или есть небольшая защемление, и вы получаете дополнительное сопротивление на проводе, это может повлиять на пропускную способность, всегда проверяйте потерянные пакеты / кадры и обязательно проверяйте свои интерфейсы на наличие ошибок. Не знаю, насколько хорошо это переносится на linux, но на FreeBSD netstat -I покажет количество ошибок ввода / вывода.
Кроме того, убедитесь, что у вас нет ошибок автосогласования, что один из интерфейсов настроен на полудуплекс. Это не очень распространено на гигабитных скоростях, но может быть очень распространено при смешивании 100 Мб с гигабитными скоростями, и Solaris особенно плохо справляется с переговорами.
Я подозреваю, что это связано с тем, как коммутатор управляет конкуренцией; с 1 отправителем конкуренция отсутствует, с 3 отправителями, все нажимающие так быстро, как они могут, коммутатор может начать отбрасывать пакеты, вызывая откат TCP и повторную передачу.
Я полагаю, вы можете проверить это, вставив 3 карты в приемник и подключив их напрямую к отправителям (не думайте, что вам нужны кроссоверные кабели для гигабита)