Почему я вижу такую низкую пропускную способность SMB?

Question

Хорошо, есть немного больше истории, чем подразумевает название.

Предпосылки и среда: я копирую несколько ТБ со старого сервера Ubuntu на новый сервер Windows 2012 через SMB. (Технически, это стандартное оборудование, но здесь они серверы.) Все находятся в гигабитной локальной сети, а старая версия Ubuntu имеет связанный интерфейс. Я полагаю, что на сервере Ubuntu есть две карты Ethernet Rosewill PCI-e 1x, а на сервере Windows - одна достаточно хорошая карта PCI Intel Ethernet.

На конечном компьютере (на сервере Windows) работает пул хранения с четностью более 4х2 ТБ дисков. Он работает под управлением новой ReFS от Microsoft. Исходный компьютер (сервер Ubuntu) работает с программным зеркалом RAID. Это хорошо работает EXT4.

Два сервера работают через один гигабитный коммутатор. Я экспериментировал с разрывом связи на исходном компьютере (Ubuntu) без каких-либо улучшений.

Проблема: у меня нет проблем с передачей на разумных скоростях с других компьютеров на сервер Windows. Другие компьютеры могут хранить 50-80 МБ / с без особых затруднений, но скорость передачи с этого сервера Ubuntu достигает не более 20 МБ / с. 4+ ТБ со скоростью 20 МБ / с занимает много времени (примерно 2,3 дня), и мне интересно, что я могу сделать, чтобы выяснить, где находится узкое место.

Симптомы: ЦП на обоих компьютерах минимален и, конечно, не слишком загружен. Жесткие диски на обоих компьютерах активны, но не перегружены, а загрузка процессора составляет почти 0% по крайней мере на сервере Ubuntu.

Я провел трассировку Wireshark в течение 35 секунд (предположительно, достаточно долго, чтобы убедиться, что все ACK были для новых пакетов) и заметил, что было довольно много вещей, которых я не ожидал. (1) Не было никаких контрольных сумм для ACK (и НЕКОТОРЫХ SMB-пакетов) от Windows до Ubuntu. Однако Wireshark утверждает, что это может быть связано с «разгрузкой контрольной суммы IP». Хорошо, у меня там очень хорошая карта. Я полагаю, возможно, что сетевая карта может делать вычисления контрольной суммы. Хорошо. Двигаемся дальше ... (2) "TCP ACKed невидимый сегмент". С этим у меня проблема. Номер ACK находится в допустимом диапазоне от того, что я могу сказать, и часто есть огромные блоки этих сообщений. Возможно, Wireshark слишком медленный?

Резюме: Скорость передачи отстой (20 МБ / с по гигабитному Ethernet), и я не знаю почему. Wireshark утверждает, что Windows ACKing вещи, которые никогда не были отправлены Ubuntu.

Угадайте: мое первоначальное предположение заключается в том, что более дешевые карты Розвилла заболочены. Мое второе предположение состоит в том, что программные RAID-подобные вещи на одном конце или другом заполняются чем-то, что нужно делать.

Answer 1

Ваш разрыв в производительности совпадает с обычным опытом, когда Samba (не уверен, что это все еще значение по умолчанию; это было в течение длительного времени) настроен с размером буфера сокета чтения и записи по умолчанию 1024 байта.

Я часто видел это на компьютерах с Linux и Mac. Надеюсь, это еще не тот случай.

В конфигурационном файле samba есть аргумент сокета, в котором вы можете установить размер буфера сокета для чтения и записи. Предлагаем вам установить 8192 байта (8 КиБ). 4 или 8 КБ часто похожи, но я не проверял это на гигабитной ссылке.

Кроме того, не ожидайте, что одно соединение TCP получит выгоду от связанной ссылки, трафик почти всегда будет проходить через одну из ссылок; в противном случае вы получите много неупорядоченных пакетов; так что ожидайте только преимущества балансировки нагрузки при обслуживании нескольких клиентов. Даже в этом случае вы должны посмотреть на разные режимы соединения и знать, что по крайней мере для соединения в "режиме 4" (IEEE 802.3ad) в основном существует два режима хэширования передачи, которые определяют, на какой подчиненный интерфейс отправлять сообщения. Существует хеширование уровня 2 (по умолчанию) и хеширование уровня 3. Если вы отправляете большую часть ваших данных через шлюз, хэш уровня 2 не будет хорошо распределяться, так как MAC-адрес шлюза будет таким же. Попробуйте использовать слой 3 вместо.

Answer 2

Однажды у меня было две карты Ethernet в одном компьютере с Ubuntu, и по какой-то причине он не работал должным образом - они оба соперничали за одинаковые пакеты, как мне казалось, поэтому иногда я получал ответ, иногда нет, в зависимости от того, захватила ли другая сетевая карта упакованный. Это было странно. Должно быть, я каким-то образом неправильно его настроил, но я бы подумал, что это сработает. Карты, конечно, имели уникальные IP-адреса.

В любом случае, было бы просто попробовать это, используя только ОДНУ Ethernet-карту в машине, подключенной к сети, чтобы исключить это.