Какой самый быстрый способ отправки огромных объемов данных между двумя компьютерами? [закрыто]

Это ситуация, в которой я часто бываю:

• У меня есть исходный сервер с жестким диском на 320 ГБ и 16 ГБ оперативной памяти ( точные спецификации доступны здесь , но, поскольку я часто сталкиваюсь с этой проблемой на других машинах, я бы предпочел, чтобы ответ работал на любом «разумная» машинка Linux)
• У меня есть резервный сервер с несколькими терабайтами пространства на жестком диске ( точные спецификации здесь , см. Отказ от ответственности выше)

Я хочу передать 320 ГБ данных с исходного сервера на целевой сервер (в частности, данные с /dev/sda).

1. Два компьютера находятся рядом друг с другом, поэтому я могу проложить кабели между ними.
2. Я нахожусь в локальной сети, и я использую новый маршрутизатор , что означает, что скорость моей сети должна «в идеале» быть 1000 Мбит, верно?
3. Безопасность не проблема. Я нахожусь в локальной сети, и я доверяю всем машинам в сети, включая маршрутизатор.
4. (необязательно). Мне не обязательно нужна подписанная контрольная сумма данных, но базовая проверка ошибок (например, пропущенные пакеты или невозможность чтения диска) должна обнаруживаться, а не просто исчезать в выводе.

Я искал этот вопрос в Интернете и проверил несколько команд. Наиболее часто встречается следующее:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Эта команда оказалась слишком медленной (она выполнялась в течение часа, получая только около 80 ГБ через данные). Для тестового пакета объемом 1 ГБ потребовалось около 1 минуты и 22 секунд, и в итоге он оказался вдвое быстрее, когда не был сжат. Результаты также могут быть искажены из-за того, что переданный файл меньше, чем объем ОЗУ в исходной системе.

Кроме того (и это было проверено на 1ГБ тестовых образцах), у меня возникают проблемы, если я использую gzipкоманду и dd; Полученный файл имеет другую контрольную сумму при извлечении на целевом объекте, чем при прямой передаче. Я все еще пытаюсь понять, почему это происходит.

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

netcat отлично подходит для таких ситуаций, когда безопасность не является проблемой:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Обратите внимание: если вы используете ddиз GNU coreutils, вы можете отправить SIGUSR1процессу, и он отправит прогресс в stderr. Для BSD ddиспользуйте SIGINFO.

pv еще более полезен в сообщении о прогрессе во время копирования:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

1. Как использовать быстрое сжатие.

   • Независимо от вашего носителя передачи данных - особенно для сети или USB - вы будете работать с пакетами данных для чтения, кэширования и записи, и они точно не будут синхронизированы.
   • Помимо встроенного программного обеспечения диска, дискового кэша и кэша ядра / оперативной памяти, если вы также можете каким-либо образом использовать ЦП системы, чтобы сконцентрировать объем данных, передаваемых за пакет, то вам следует это сделать .
   • Любой алгоритм сжатия будет автоматически обрабатывать разреженные входные данные максимально быстро, но очень немногие будут обрабатывать все остальное при пропускной способности сети.
   • lz4 Ваш лучший вариант здесь:

     LZ4 - это очень быстрый алгоритм сжатия без потерь, обеспечивающий скорость сжатия 400 МБ / с на ядро, масштабируемую с помощью многоядерного процессора. Он также имеет чрезвычайно быстрый декодер со скоростью в несколько ГБ / с на ядро, что обычно достигает предела скорости ОЗУ в многоядерных системах.

2. Желательно не искать без необходимости.

   • Это может быть трудно измерить.

   • Если на устройстве, с которого вы копируете, много свободного места, и устройство не было недавно обнулено, но все исходные файловые системы должны быть скопированы, то, вероятно, стоит сначала сделать это. что-то вроде:

     </dev/zero tee >empty empty1 empty2; sync; rm empty*

   • Но это зависит от того, на каком уровне вы должны читать источник. Обычно желательно прочитать устройство от начала до конца из его /dev/some_diskфайла устройства, потому что чтение на уровне файловой системы обычно включает в себя поиск вперед и назад и вокруг диска не последовательно. И поэтому ваша команда чтения должна выглядеть примерно так:

     </dev/source_device lz4 | ...

   • Однако, если ваша исходная файловая система не должна передаваться целиком, тогда чтение на уровне файловой системы довольно неизбежно, и поэтому вы должны объединить входное содержимое в поток. paxкак правило, является лучшим и наиболее простым решением в этом случае, но вы также можете подумать mksquashfs.

     pax -r /source/tree[12] | lz4 | ...
     mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...

3. Вы не шифровать ssh.

   • Добавлять служебные данные шифрования на доверенный носитель не нужно, и это может серьезно повлиять на скорость устойчивой передачи, поскольку считываемые данные должны быть прочитаны дважды .
   • ПГСЧ нужны чтения данных или , по крайней мере , некоторые из них, чтобы поддерживать случайности.
   • И, конечно же, вам необходимо передать данные.
   • Вам также необходимо перенести сами издержки на шифрование, что означает больше работы для меньшего количества данных, передаваемых за пакет .

   • И поэтому скорее вы должны использовать netcat( или, как я предпочитаю, nmapпроект более способныйncat ) для простой сетевой копии, как было предложено в другом месте:

     ###  on tgt machine...
     nc -l 9999 > out.lz4
     ###  then on src machine...
     ... lz4 | nc tgt.local 9999

Есть несколько ограничений, которые могут ограничивать скорость передачи.

1. В канале с пропускной способностью 1 Гбит / с присутствуют сетевые издержки. Обычно это снижает фактическую пропускную способность до 900 Мбит / с или менее. Тогда вы должны помнить, что это двунаправленный трафик, и вы должны ожидать значительно меньше, чем 900 Мбит / с.

2. Даже если вы используете «новый маршрутизатор», вы уверены, что маршрутизатор поддерживает 1 Гбит / с? Не все новые маршрутизаторы поддерживают 1 Гбит / с. Кроме того, если это не маршрутизатор корпоративного уровня, вы, скорее всего, потеряете дополнительную пропускную способность, так как маршрутизатор будет неэффективным. Хотя, исходя из того, что я нашел ниже, похоже, что вы получаете скорость выше 100 Мбит / с.

3. Возможна перегрузка сети другими устройствами, использующими вашу сеть. Вы пытались использовать напрямую подключенный кабель, как вы сказали, что вы могли сделать?

4. Какой объем дискового ввода-вывода вы используете? Вероятно, вы ограничены не сетью, а дисководом. Большинство жестких дисков со скоростью 7200 об / мин получат только около 40 МБ / с. Вы используете рейд вообще? Вы используете SSD? Что вы используете на удаленном конце?

Я предлагаю использовать rsync, если ожидается, что это будет выполнено повторно для резервных копий. Вы также можете использовать scp, ftp (s) или http, используя загрузчик, такой как filezilla, на другом конце, поскольку он будет распараллеливать соединения ssh / http / https / ftp. Это может увеличить пропускную способность, так как другие решения находятся на одной трубе. Один канал / поток все еще ограничен тем фактом, что он является однопоточным, что означает, что он может быть даже связан с процессором.

С rsync вы избавляетесь от сложности вашего решения, а также разрешаете сжатие, сохранение разрешений и частичную передачу. Есть несколько других причин, но, как правило, это предпочтительный метод резервного копирования (или запуска систем резервного копирования) крупных предприятий. Commvault фактически использует rsync под своим программным обеспечением в качестве механизма доставки резервных копий.

Исходя из приведенного вами примера 80 ГБ / ч, вы получаете около 177 Мбит / с (22,2 МБ / с). Я чувствую, что вы можете легко удвоить это с помощью rsync на выделенной линии Ethernet между двумя блоками, поскольку мне удалось получить это в моих собственных тестах с rsync поверх гигабит.

Мы занимаемся этим регулярно.

Мы используем два основных метода:

1. SATA / ESATA / Sneakernet
2. Прямое монтирование NFS, затем локальное cpилиrsync

Первое зависит от того, можно ли физически переместить привод. Это не всегда так.

Второй работает на удивление хорошо. Как правило, мы максимально легко подключаемся к соединению в 1 Гбит / с с помощью прямых подключений NFS. Вы не приблизитесь к этому с помощью scp, dd over ssh или чего-либо подобного (вы часто получаете максимальную скорость, подозрительно близкую к 100mpbs). Даже на очень быстрых многоядерных процессорах вы столкнетесь с узким местом при максимальной пропускной способности шифрования одного из ядер на самой медленной из двух машин, что удручающе медленно по сравнению с полнопроцессорным процессором cp или rsync при незашифрованном монтировании сети. Изредка вы можете ненадолго ударить по стене iops и застревать со скоростью ~ 53 МБ / с вместо более типичных ~ 110 МБ / с, но обычно это недолгое время, если источник или пункт назначения на самом деле не являютсяодин диск, тогда вы можете быть ограничены постоянной скоростью самого диска (который достаточно варьируется по случайным причинам, о которых вы не узнаете, пока не попробуете его) - ме.

NFS может немного раздражать в настройке, если он находится в незнакомом дистрибутиве, но, вообще говоря, это был самый быстрый способ заполнить трубы максимально полно. В прошлый раз, когда я делал это со скоростью 10 Гбит / с, я так и не узнал, превысило ли это соединение, потому что передача была закончена еще до того, как я вернулся, чтобы взять немного кофе - так что, возможно, у вас есть какой-то естественный предел. Если у вас есть несколько сетевых устройств между источником и назначением, вы можете столкнуться с некоторыми небольшими задержками или сбоями из-за эффекта слияния в сети, но обычно это будет работать через офис (без другого трафика, который его портит) или от одного конца центра обработки данных до другой (если у вас нет какой-либо фильтрации / проверки, происходящей внутри, в этом случае все ставки отключены ).

РЕДАКТИРОВАТЬ

Я заметил некоторую болтовню о сжатии ... не сжимайте соединение. Это замедлит вас так же, как и криптослой. Узким местом всегда будет одно ядро, если вы сожмете соединение (и вы даже не получите особенно хорошего использования шины этого ядра). Самое медленное, что вы можете сделать в вашей ситуации, - это использовать зашифрованный сжатый канал между двумя компьютерами, расположенными рядом друг с другом при скорости соединения 1 Гбит / с или выше.

БУДУЩАЯ ЗАЩИТА

Этот совет действует с середины 2015 года. Это почти наверняка не будет иметь место в течение слишком многих лет. Так что принимайте все с большой долей соли, и если вы регулярно сталкиваетесь с этой задачей, то попробуйте различные методы на реальных нагрузках вместо того, чтобы представить, что вы получите что-то близкое к теоретическим оптимумам или даже к наблюдаемым скоростям сжатия / криптографии, типичным для таких вещей, как веб трафик, большая часть которого является текстовой (protip: массовые передачи обычно состоят в основном из изображений, аудио, видео, файлов базы данных, двоичного кода, форматов офисных файлов и т. д., которые уже сжатыпо-своему и очень мало выигрывают от выполнения еще одной процедуры сжатия, размер блока сжатия которой почти гарантированно не будет соответствовать вашим уже сжатым двоичным данным ...).

Я полагаю, что в будущем такие концепции, как SCTP, будут перенесены в более интересное место, где типичные связанные соединения (или внутренние волоконно-оптические соединения с привязкой по спектру) являются типичными, и каждый канал может принимать поток независимо от других, и каждый поток может быть сжат / зашифрован параллельно и т. д. Это было бы замечательно! Но это не так сегодня в 2015 году, и хотя фантазии и теоретизирование - это хорошо, у большинства из нас нет собственных кластеров хранения, работающих в криокамере, которые подают данные непосредственно во внутреннюю часть Blue Gene / Q, генерируя ответы для Watson. Это просто не реальность. Также у нас нет времени на тщательный анализ полезных данных, чтобы выяснить, является ли сжатие хорошей идеей или нет - сама передача была бы закончена до того, как мы закончили анализ,

Но...

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

Отличный инструмент, который я использовал в прошлом bbcp. Как видно здесь: https://www.slac.stanford.edu/~abh/bbcp/ .

Смотрите также http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

У меня были очень высокие скорости передачи с этим инструментом.

Если вы получили первый проход каким-либо образом (через провод / sneakernet / что угодно), вы можете изучить rsyncнекоторые параметры, которые могут значительно ускорить последующие передачи. Очень хороший путь будет:

rsync -varzP sourceFiles destination

Варианты: подробный, режим архива, рекурсивный, сжатие, частичный прогресс

Добавлен по настоянию оригинального постера в комментариях к ответу Зацзе, хотя я не уверен, что он самый быстрый в типичных обстоятельствах.

bashимеет специальный синтаксис перенаправления:
Для вывода:      > /dev/tcp/ IP-  / порт.
Для ввода:       < /dev/tcp/ IP-  / порт.
IP- запрет должен быть либо десятичным, либо десятичным, либо именем хоста; Запрет порта может быть либо десятичным числом, либо именем порта из /etc/services.

Там нет актуального /dev/tcp/каталога. Это специальный синтаксический kludge, который отправляет команду bashна создание TCP-сокета, подключает его к указанному месту назначения, а затем делает то же самое, что и обычное перенаправление файлов (а именно, заменяет соответствующий стандартный поток на сокет с помощью dup2 (2)).

Следовательно, можно передавать данные с ddили tarна исходный компьютер напрямую через TCP. Или, наоборот, для потоковой передачи данных tarили чего-то подобного напрямую через TCP. В любом случае один лишний netcat исключается.

Заметки о netcat

Существует несоответствие в синтаксисе между классическим netcat и GNU netcat . Я буду использовать классический синтаксис, к которому я привык. Заменить -lpс -lГНУ Netcat.

Кроме того, я не уверен, принимает ли GNU netcat -qпереключатель.

Передача образа диска

(По линии ответа Заксе.)
По назначению:

nc -lp 9999 >disk_image

По источнику:

dd if=/dev/sda >/dev/tcp/destination/9999
 

Создание архива tar.gz, с tar

По назначению:

nc -lp 9999 >backup.tgz

По источнику:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Заменить .tgzс .tbzи czс , cjчтобы получить bzip2-сжатый архив.

Перенос с немедленным расширением в файловую систему

Также с tar.
По назначению:

cd backups
tar x </dev/tcp/destination/9999

По источнику:

tar c files or directories to be transferred |nc -q 1 -lp 9999

Это будет работать без -q 1, но netcat застрянет, когда данные закончились. См. Tar (1) для объяснения синтаксиса и предостережений tar. Если существует много файлов с высокой избыточностью (низкой энтропией), то можно попробовать сжатие (например, czа xzне cи x), но если файлы типичные и сеть достаточно быстрая, это только замедлит процесс. Посмотрите ответ mikeserv для деталей о сжатии.

Альтернативный стиль (порт назначения слушает)

По назначению:

cd backups
nc -lp 9999 |tar x

По источнику:

tar c files or directories to be transferred >/dev/tcp/destination/9999

Попробуйте предложения относительно прямых соединений и избегания зашифрованных протоколов, таких как ssh. Затем, если вы все еще хотите добиться максимальной производительности, прочитайте этот сайт: https://fasterdata.es.net/host-tuning/linux/, чтобы получить советы по оптимизации окон TCP.

Я хотел бы использовать этот скрипт, который я написал, который нуждается в socatпакете.

На исходном компьютере:

tarnet -d wherefilesaretosend pass=none 12345 .

На целевой машине:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Если vbufпакет (Debian, Ubuntu) присутствует, отправитель файла покажет ход данных. Приемник файлов покажет, какие файлы получены. Опция pass = может использоваться там, где данные могут быть представлены (медленнее).

Редактировать:

Используйте -nопцию, чтобы отключить сжатие, если процессор - горлышко бутылки.

Если бюджет не является основной проблемой, вы можете попробовать подключить диски с 12-ядерным разъемом Intel Xeon E5. Этот разъем, как правило, настолько мощный, что на нем даже можно запустить текущее серверное программное обеспечение. С обоих серверов!

Это может показаться забавным ответом, но вы должны подумать, почему вы перемещаете данные между серверами, и если больший объем с общей памятью и хранилищем может иметь больше смысла.

Не уверен насчет текущих характеристик, но медленная передача может быть ограничена скоростью диска, а не сети?

Если вы заботитесь только о резервных копиях, а не о байтовой копии жесткого диска, я бы порекомендовал backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html Это немного затрудняет настройку, но переносится очень быстро.

Мое начальное время передачи около 500G данных было около 3 часов. Последующие резервные копии происходят примерно через 20 секунд.

Если вы не заинтересованы в резервном копировании, но пытаетесь синхронизировать данные, тогда rsync или unison будут лучше соответствовать вашим потребностям.

Байт для байт-копии жесткого диска, как правило, является ужасной идеей для целей резервного копирования (без приращений, без экономии места, диск не может быть использован, вам нужно сделать резервную копию «пустого места», и вам нужно создать резервную копию мусора (например, файл подкачки 16 ГБ или 200 ГБ дампов ядра или что-то подобное.) Используя rsync (или backuppc или другие), вы можете создавать «моментальные снимки» во времени, чтобы вы могли перейти к «тому, как ваша файловая система выглядела 30 минут назад» с помощью очень мало накладных расходов.

Тем не менее, если вы действительно хотите перенести байт за байтовую копию, ваша проблема будет заключаться в передаче, а не в получении данных с диска. При отсутствии 400 ГБ ОЗУ передача файлов 320 ГБ займет очень много времени. Использование протоколов, которые не зашифрованы, является опцией, но, несмотря ни на что, вам просто придется сидеть там и ждать несколько часов (по сети).

Независимо от программы, я обычно обнаруживал, что «вытягивание» файлов по сети происходит быстрее, чем «выталкивание». То есть вход на конечный компьютер и чтение выполняется быстрее, чем вход на исходный компьютер и выполнение записи.

Кроме того, если вы собираетесь использовать промежуточный диск, учтите следующее: получите внешний диск (либо в виде пакета, либо отдельный диск, подключенный к док-станции), который использует eSATA, а не USB. Затем на каждом из двух компьютеров либо установите карту с портом eSATA, либо подключите простой переходной кабель, который подключает один из внутренних портов SATA к внешнему разъему eSATA. Затем подключите диск к исходному компьютеру, включите диск и дождитесь его автоматического монтирования (вы можете монтировать его вручную, но если вы делаете это несколько раз, вы можете также поместить его в файл fstab). Затем скопируйте; вы будете писать с той же скоростью, что и на внутренний диск. Затем отключите диск, выключите его, подключите к другому компьютеру, включите питание, дождитесь автоматического подключения и прочитайте.

Я собираюсь рекомендовать вам взглянуть на NIC-teaming. Это предполагает использование нескольких сетевых подключений, работающих параллельно. Предполагая, что вам действительно требуется передача более 1 ГБ, и что 10 ГБ являются чрезмерно дорогостоящими, 2 ГБ, предоставляемые объединением сетевых карт, будут незначительными, и ваши компьютеры уже могут иметь дополнительные порты.

FWIW, я всегда использовал это:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

Суть этого метода заключается в том, что он будет поддерживать права доступа к файлам / папкам между компьютерами (при условии, что на обоих компьютерах существуют одни и те же пользователи / группы) (также я обычно делаю это для копирования образов виртуальных дисков, поскольку могу использовать параметр -S для обработки разреженных файлов. )

Только что проверил это между двумя занятыми серверами и управлял ~ 14 ГБ за 216 с (около 64 МБ / с) - может быть лучше для выделенных машин и / или сжатия ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

Если вы не хотите выполнять экспертизу файловой системы, используйте программу dump / restore для вашей файловой системы, чтобы избежать копирования свободного места, которое не использует FS. В зависимости от того, какая у вас файловая система, обычно сохраняются все метаданные, в том числе ctime. номера инодов могут измениться, опять же, в зависимости от того, какая файловая система (xfs, ext4, ufs ...).

Целью восстановления может быть файл в целевой системе.

Если вам нужен полный образ диска с таблицей разделов, вы можете ddсначала 1M диска получить таблицу разделов / загрузчики / вещи, но затем xfsdumpразделы.

Я не могу сказать из твоего информационного дампа, какая у тебя файловая система. Если это BSD UFS, то я думаю, что есть программа дампа / восстановления. Если это ZFS, ну IDK, может быть что-то.

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

Вы также можете настроить системы для общего хранилища!

Я считаю, что они рядом друг с другом, и вы, вероятно, будете делать это снова и снова ....

Как насчет кабеля кроссовера Ethernet? Вместо того, чтобы полагаться на беспроводные скорости, вы ограничены скоростью проводной сети вашего сетевого адаптера.

Вот похожий вопрос с некоторыми примерами такого решения.

Видимо, в настоящее время достаточно обычного Ethernet-кабеля. Очевидно, что чем лучше ваша сетевая карта, тем быстрее передача.

Подводя итог, если какая-либо настройка сети необходима, она должна быть ограничена простой установкой статических IP-адресов для вашего сервера и резервного компьютера с маской подсети 255.255.255.0

Удачи!

Редактировать:

@Khrystoph затронул это в своем ответе

Некоторые люди рекомендуют пропустить ssh, потому что шифрование замедлит вас. Современные процессоры могут на самом деле быть достаточно быстрыми в 1 Гб, но у OpenSSH есть проблемы с его внутренней реализацией окон, которая может существенно замедлить вас.

Если вы хотите сделать это с помощью ssh, взгляните на HPN SSH . Это решает проблемы окон и добавляет многопоточное шифрование. К сожалению, вам нужно пересобрать ssh как на клиенте, так и на сервере.

Хорошо, я попытался ответить на этот вопрос для двух компьютеров с «очень большими трубами» (10Gbe), которые «близки» друг к другу.

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

производительность для передачи файла 10 ГБ (сетевое соединение 6 ГБ [linode], несжимаемые данные):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

И две коробки по 10 Gbe, немного более старые версии netcat (CentOs 6.7), файл 10GB:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

Так что в одном случае netcat использовал меньше процессоров, а в другом socat, так что YMMV.

С netcat, если у него нет опции «-N -q 0», он может передавать усеченные файлы, будьте осторожны ... другие опции, такие как «-w 10», также могут привести к усеченным файлам.

Практически во всех этих случаях происходит максимальная загрузка процессора, а не сети. scpМаксимальная скорость около 230 МБ / с, привязка одного ядра при 100% загрузке.

Iperf3, к сожалению, создает поврежденные файлы. Некоторые версии netcat, кажется, не передают весь файл, очень странно. Особенно старые версии этого.

Различные заклинания "gzip as pipe to netcat" или "mbuffer" также, похоже, максимально загружали процессор с помощью gzip или mbuffer, поэтому не приводили к более быстрой передаче с такими большими каналами. lz4 может помочь. Кроме того, некоторые из попыток gzip pipe, которые я пытался сделать, привели к поврежденным передачам для очень больших (> 4 ГБ) файлов, поэтому будьте осторожны там :)

Еще одна вещь, которая может работать особенно для более высокой задержки (?), Это настроить параметры tcp. Вот руководство, в котором упоминаются рекомендуемые значения:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm и https://fasterdata.es.net/host-tuning/linux/ (из другого ответа) возможно настройки IRQ: https://fasterdata.es .net / хост-тюнинг / 100г настройка /

предложения от linode, добавьте в /etc/sysctl.conf:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

Кроме того, они хотели бы, чтобы вы запустили:

 /sbin/ifconfig eth0 txqueuelen 10000 

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

Также может стоить настроить размер окна: https://iperf.fr/iperf-doc.php#tuningtcp

С медленными (er) соединениями сжатие может определенно помочь. Если у вас большие каналы, очень быстрое сжатие может помочь с легко сжимаемыми данными, не пробуйте.

Стандартный ответ для «синхронизации жестких дисков» - rsync файлы, что позволяет избежать передачи, где это возможно.

Другой вариант: использовать «параллельный scp» (так или иначе), тогда он будет использовать больше ядер ...