Який найшвидший спосіб надсилати величезну кількість даних між двома комп’ютерами? [зачинено]

Це ситуація, в якій я часто буваю:

• У мене є джерело-сервер із жорстким диском на 320 ГБ і 16 ГБ оперативної пам’яті ( точні специфікації доступні тут , але оскільки це питання, з яким я часто стикаюся і на інших машинах, я вважаю за краще відповідь працювати на будь-якій "розумна" машина Linux)
• У мене є резервний сервер з кількома терабайтми місця на жорсткому диску ( точні характеристики тут , див. Відмову від відповідальності вище)

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

1. Два комп'ютери фізично розташовані поруч, тож я можу провести кабелі між ними.
2. Я в локальній мережі, і я використовую новий-ish маршрутизатор , а це означає, що швидкість моєї мережі повинна "в ідеалі" бути 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

Зауважте, якщо ви використовуєте ddGNU 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. Незважаючи на те, що ви використовуєте «новий-маршрутизатор», ви впевнені, що маршрутизатор підтримує 1Gbps? Не всі нові маршрутизатори підтримують 1Gbps. Крім того, якщо це не маршрутизатор корпоративного рівня, ви, ймовірно, втратите додаткову пропускну здатність передачі, щоб маршрутизатор був неефективним. Хоча, виходячи з того, що я знайшов нижче, схоже, ви перевищуєте 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 / кросівки
2. Пряме кріплення NFS, потім локальне cpабоrsync

Перший залежить від того, чи можна перенести накопичувач фізично. Це не завжди так.

Друга працює напрочуд добре. Як правило, ми максимізуємо 1gbps з'єднання досить легко за допомогою прямого кріплення NFS. Ви ніде не наблизитесь до цього за допомогою scp, dd over ssh або будь-якого подібного (ви часто отримуєте максимальну ставку, підозріло близьку до 100 мбіт). Навіть на дуже швидких багатоядерних процесорах ви потрапите в вузьке місце на максимальній пропускній здатності криптовалюти одного з ядер на найповільнішій з двох машин, яка гнітюче повільна порівняно з повнорозрядним процесором або rsync на незашифрованому мережевому кріпленні. Іноді ви на деякий час потрапите на стіну iops і застрягнете біля ~ 53MB / s замість більш типових ~ 110MB / s, але це, як правило, недовговічно, якщо фактично джерело чи пункт призначенняодин привід, то ви можете бути обмеженими стійкою швидкістю самого диска (що досить різниться з випадкових причин, про які ви не будете знати, поки ви фактично не спробуєте) - Мех.

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

EDIT

Я помітив деяку балаканину щодо стиснення ... не стискайте з'єднання. Це сповільнить вас так само, як і криптошар. Вузьке вузьке місце завжди буде одноядерним, якщо стиснути з'єднання (і ви навіть не отримаєте особливо гарного використання шини цього ядра). Найповільніше, що ви можете зробити у своїй ситуації - це використовувати зашифрований, стислий канал між двома комп'ютерами, що сидять поруч один з одним на 1gbps або вище з'єднання.

МАЙБУТНЕ ДОКАЗАННЯ

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

Я думаю, що в майбутньому такі поняття, як SCTP, будуть перенесені на більш цікаве місце, де типові зв'язки (або внутрішньо пов'язані по спектру каналізовані волокна з'єднання) є типовими, і кожен канал може приймати потік, незалежний від інших, і кожен Потік можна стиснути / зашифрувати паралельно тощо. Це було б чудово! Але це не так сьогодні в 2015 році, і хоча фантазування та теоретизація є приємною, більшість з нас не мають власних кластерів зберігання, які працюють у кріокамерній подачі даних безпосередньо до нутрощів Blue Gene / Q, що генерують відповіді для Уотсона. Це просто не реальність. Також ми не встигаємо проаналізувати навантаження наших даних вичерпно, щоб зрозуміти, чи є стиснення хорошою ідеєю чи ні - сама передача була б закінчена, перш ніж ми закінчили аналіз,

Але ...

Часи змінюються, і моя рекомендація щодо стиснення та шифрування не витримає. Я дуже хотів би, щоб ця порада була скасована в типовому випадку дуже скоро. Це полегшило б моє життя.

Чудовим інструментом, яким я користувався в минулому, є bbcp. Як видно тут: https://www.slac.stanford.edu/~abh/bbcp/ .

Дивіться також http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

У мене були дуже великі швидкості передачі за допомогою цього інструменту.

Якщо ви отримуєте перший пропуск якось (через провід / кросівки / що завгодно), ви можете розглянути rsyncпевні варіанти, які можуть значно пришвидшити подальший переказ. Дуже хорошим шляхом було б:

rsync -varzP sourceFiles destination

Параметри: багатослівний, режим архіву, рекурсивний, стиснення, частковий прогрес

Додано за наполяганням оригінального плаката в коментарях до відповіді zackse, хоча я не впевнений, що це найшвидше за типових обставин.

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

Фактичного /dev/tcp/каталогу немає . Це особливий синтаксичний вислів, який командує bashстворити сокет TCP, підключити його до вказаного пункту призначення, а потім зробити те саме, що робить звичайне перенаправлення файлів (а саме замінити відповідний стандартний потік сокетом за допомогою dup2 (2)).

Таким чином, можна транслювати дані ddабо tarна вихідній машині безпосередньо через TCP. Або, навпаки, tarпряму передачу даних або щось подібне безпосередньо через TCP. У будь-якому випадку, одна зайва сітка усувається.

Примітки про мережу

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

Також я не впевнений, чи приймає GNU netcat -qкомутатор.

Перенесення образу диска

(По лінії відповіді Zackse.)
Про місце призначення:

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опцію, щоб відключити стиснення, якщо процесор - це горловина пляшки.

Якщо бюджет не є основним питанням, ви можете спробувати підключити накопичувачі за допомогою "роз'єм накопичувача" Intel Xeon E5 12. Цей роз'єм зазвичай настільки потужний, що на ньому можна навіть запустити поточне серверне програмне забезпечення. З обох серверів!

Це може здатися цікавою відповіддю, але ви дійсно повинні врахувати, чому ви переміщуєте дані між серверами, і якщо великий з загальною пам’яттю та сховищем може мати більше сенсу.

Не впевнені в поточних специфікаціях, але повільна передача може бути обмежена швидкістю диска, а не мережею?

Якщо ви дбаєте лише про резервні копії, а не про байт для байтової копії жорсткого диска, то я б рекомендував backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html Налаштування трохи болить, але це швидко передається.

Мій початковий час передачі приблизно 500G даних склав близько 3 годин. Подальші резервні копії трапляються приблизно за 20 секунд.

Якщо вас не цікавлять резервні копії, але вони намагаються синхронізувати речі, тоді rsync або unison краще відповідатиме вашим потребам.

Байт для копіювання байта на жорсткому диску, як правило, є жахливою ідеєю для резервного копіювання (ніяких інкременталів, економії місця, диск не може бути використаний, вам потрібно створити резервну копію "порожнього простору", і вам потрібно створити резервну копію сміття (на зразок файлу підкачки 16 G або 200G основних дампів чи інших подібних). Використовуючи rsync (або backuppc чи інші), ви можете вчасно створити "знімки", щоб ви могли перейти до "як виглядала ваша файлова система 30 хвилин тому" дуже мало накладних.

Однак, якщо ви дійсно хочете передати байт для байтової копії, тоді ваша проблема полягає в передачі, а не в отриманні даних з накопичувача. З 400 Гб оперативної пам’яті передача файлів 320G займе дуже тривалий час. Використання протоколів, які не зашифровані - це варіант, але незалежно від того, вам просто доведеться сидіти там і чекати кілька годин (по мережі).

Незалежно від програми, я зазвичай виявляв, що "перетягування" файлів по мережі швидше, ніж "натискання". Тобто, увійти в цільовий комп'ютер і зробити зчитування швидше, ніж увійти у вихідний комп'ютер і зробити запис.

Крім того, якщо ви збираєтесь використовувати проміжний накопичувач, врахуйте це: Отримайте зовнішній накопичувач (як пакет, або окремий диск, підключений до док-станції), який використовує eSATA, а не USB. Потім на кожному з двох комп’ютерів або встановіть карту з портом eSATA, або отримайте простий адаптерний кабель, який підводить один із внутрішніх портів SATA до зовнішнього роз'єму eSATA. Потім підключіть накопичувач до джерела комп'ютера, увімкніть його та дочекайтеся його автоматичного монтажу (ви зможете встановити мануально, але якщо ви робите це неодноразово, ви можете також помістити його у свій файл fstab). Потім скопіюйте; ви будете писати з тією ж швидкістю, що і на внутрішній привід. Потім відключіть привід, вимкніть живлення, підключіть до іншого комп’ютера, увімкніть живлення, дочекайтеся автоматичного встановлення та прочитайте.

Я порекомендую вам ознайомитись з командою NIC. Це включає використання декількох мережевих з'єднань, які працюють паралельно. Якщо припустити, що вам дійсно потрібно більше 1 Гбіт передачі, і що 10 Гбіт є непомірною витратою, 2 Гбіт, що надається NIC-групуванням, буде незначною вартістю, і ваші комп'ютери вже можуть мати додаткові порти.

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

Якщо ви не хочете робити криміналістику файлової системи, використовуйте програму скидання / відновлення для вашої файлової системи, щоб уникнути копіювання вільного простору, який FS не використовує. Залежно від того, яка файлова система у вас є, зазвичай це збереже всі метадані, в тому числі ctime. Номери inode можуть змінюватися, однак, знову ж таки, залежно від файлової системи (xfs, ext4, ufs ...).

Ціль відновлення може бути файлом у цільовій системі.

Якщо ви хочете зображення з повним диском з таблицею розділів, ви можете ddпершим 1 М диска отримати таблицю розділів / завантажувачі / речі, але потім xfsdumpрозділи.

Я не можу сказати з вашого інформаційного дампа, яку файлову систему ви насправді маєте. Якщо це BSD ufs, то я думаю, що є програма скидання / відновлення. Якщо це ZFS, ну і IDK, може щось бути.

Як правило, повноцінне копіювання дисків навколо занадто повільне для нічого, крім ситуацій відновлення. Ви також не можете робити додаткові резервні копії.

Ви також можете налаштувати системи на спільне зберігання!

Я вважаю, що вони знаходяться поруч, і ви, ймовірно, зробите це знову і знову ....

Як щодо перехресного кабелю Ethernet? Замість того, щоб покладатися на бездротові швидкості, ви обмежені на дротовій швидкості свого NIC.

Ось подібне запитання з деякими прикладами такого рішення.

Мабуть, сьогодні достатньо лише типового кабелю Ethernet. Очевидно, чим краще ваш NIC, тим швидше передача.

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

Удачі!

Редагувати:

@Khrystoph торкнувся цього у своїй відповіді

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

Якщо ви хочете зробити це з ssh, погляньте на HPN SSH . Він вирішує проблеми з вікном і додає багатопотокове шифрування. На жаль, вам потрібно буде відновити ssh як на клієнті, так і на сервері.

Гаразд, я намагався відповісти на це запитання для двох комп’ютерів із "дуже великими трубами" (10Gbe), які "близькі" один до одного.

Проблема, з якою ви стикаєтесь тут, полягає в тому, що більшість компресій буде вузьким місцем на процесорі, оскільки труби такі великі.

продуктивність для передачі файлу 10 Гб (підключення до мережі 6 Гб [лінод], нестискаються дані):

$  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), файл 10 ГБ:

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 як труба для netcat" або "mbuffer" також, здавалося, максимізували процесор за допомогою gzip або mbuffer, тому не призвели до швидшого перенесення таких великих труб. lz4 може допомогти. Крім того, деякі з матеріалів, які я спробував здійснити, призвели до пошкоджених передач дуже великих (> 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

При повільному (ер) з'єднанні компресія, безумовно, може допомогти. Якщо у вас великі труби, дуже швидке стискання може допомогти легко стислими даними, не намагалися.

Стандартною відповіддю для "синхронізації жорстких дисків" є rsync файлів, що дозволяє уникнути передачі, де це можливо.

Ще один варіант: використовуйте "паралельний scp" (так чи інакше), тоді він буде використовувати більше ядер ...