Ладно, в этой истории есть немного больше, чем следует из названия.
Предыстория и окружающая среда: Я копирую несколько ТБ со старого сервера Ubuntu на новый сервер Windows 2012 по SMB. (Технически, это обычное оборудование, но здесь они серверы.) Все подключены к гигабитной локальной сети, а старый ящик Ubuntu имеет связанный интерфейс. Я полагаю, что сервер Ubuntu имеет две карты Rosewill PCI-e 1x ethernet, а сервер Windows имеет одну достаточно хорошую карту PCI Intel ethernet.
На конечном компьютере (сервер Windows) запущен Storage Pool с четностью на 4 дисках по 2 ТБ. На нем запущен новый ReFS от Microsoft. На исходном компьютере (сервер Ubuntu) запущено программное зеркало RAID. На нем запущен старый добрый EXT4.
Два сервера работают через один гигабитный коммутатор. Я экспериментировал с разрывом связи на исходном компьютере (Ubuntu) без каких-либо улучшений.
Проблема: У меня нет проблем с передачей на разумной скорости с других компьютеров на сервер Windows. Другие компьютеры могут удерживать 50-80 МБ/с без особых проблем, но передача с этого сервера Ubuntu не превышает 20 МБ/с. 4+ ТБ при 20 МБ/с занимает много времени (примерно 2,3 дня), и мне интересно, что я могу сделать, чтобы выяснить, где узкое место.
Симптомы: CPU на обоих компьютерах довольно минимальна и, конечно, не чрезмерно загружена. Жесткие диски на обоих компьютерах активны, но не перегружены, а CPU IOwait почти 0% по крайней мере на сервере Ubuntu.
Я провел трассировку Wireshark в течение 35 секунд (вероятно, достаточно долго, чтобы убедиться, что все ACK были для новых пакетов) и заметил, что было довольно много вещей, которых я не ожидал. (1) Не было никаких контрольных сумм для ACK (и НЕКОТОРЫХ пакетов SMB) от Windows до Ubuntu. Однако Wireshark утверждает, что это может быть из-за «разгрузки контрольной суммы IP». Хорошо, у меня там довольно хорошая карта. Я предполагаю, что, возможно, сетевая карта может выполнять расчеты контрольной суммы. Отлично. Двигаемся дальше... (2) «TCP ACKed невидимый сегмент». С этим у меня проблема. Номер ACK находится в приемлемом диапазоне, насколько я могу судить, и часто встречаются огромные блоки этих сообщений. Возможно, Wireshark просто слишком медленный?
Краткое содержание: Скорость передачи данных отстой (20 МБ/с через гигабитный Ethernet), и я не знаю почему. Wireshark утверждает, что Windows подтверждает то, что Ubuntu никогда не отправляла.
Догадки: Моя первая догадка заключается в том, что более дешевые карты Rosewill завалены. Моя вторая догадка заключается в том, что программные RAID-подобные штуки на одном или другом конце завалены работой.
решение1
Ваш разрыв в производительности совпадает с распространенной ситуацией, когда Samba (не уверен, является ли это все еще значением по умолчанию; долгое время это было так) настроена с размером буфера сокета чтения и записи по умолчанию в 1024 байта.
Я часто видел это на машинах Linux и Mac. Надеюсь, что это не так.
В файле конфигурации samba есть аргумент опции сокета, с помощью которого можно задать размер буфера сокета для чтения и записи. Предлагаю установить оба значения на 8192 байта (8 КиБ). 4 или 8 КБ часто совпадают, но я не проверял это на гигабитном соединении.
Кроме того, не ожидайте, что одно TCP-соединение выиграет от связанного канала, трафик почти всегда будет проходить через один из каналов; в противном случае вам придется иметь дело с большим количеством неупорядоченных пакетов; поэтому ожидайте выгоды от балансировки нагрузки только при обслуживании нескольких клиентов. Даже в этом случае вам следует изучить различные режимы связывания и знать, что для связывания по крайней мере "mode 4" (IEEE 802.3ad) в основном есть два режима хэширования передачи, которые определяют, какой подчиненный интерфейс отправлять. Существует хэширование уровня 2 (по умолчанию) и хэширование уровня 3. Если вы отправляете большую часть своих данных через шлюз, хэш уровня 2 не будет хорошо распределяться, так как MAC-адрес шлюза будет тем же самым. Рассмотрите возможность использования вместо этого уровня 3.
решение2
У меня когда-то было две карты Ethernet на одном компьютере Ubuntu, и по какой-то причине он не работал должным образом — они обе, казалось, конкурировали за одни и те же пакеты, поэтому иногда я получал ответ, иногда нет, в зависимости от того, захватывала ли другая сетевая карта упакованный пакет. Это было странно. Должно быть, я как-то неправильно его настроил, но я думал, что он просто заработает. Конечно, у карт были уникальные IP-адреса.
В любом случае, вам будет проще попробовать это всего с ОДНОЙ картой Ethernet в машине, подключенной к сети, просто чтобы исключить эту возможность.