Чому трубопровід "DD" через gzip набагато швидший, ніж пряма копія?

79

Я хотів створити резервну копію шляху від комп'ютера в моїй мережі до іншого комп’ютера в тій же мережі по лінії 100 Мбіт / с. Для цього я і зробив

dd if=/local/path of=/remote/path/in/local/network/backup.img

що дало мені дуже низьку швидкість передачі мережі приблизно від 50 до 100 кБ / с, що зайняло б назавжди. Тому я зупинив це і вирішив спробувати gzipping на льоту, щоб зробити його значно меншим, щоб сума для переказу була меншою. Так я і зробив

dd if=/local/path | gzip > /remote/path/in/local/network/backup.img.gz

Але зараз я отримую щось на кшталт швидкості передачі мережі в 1 Мб / с, тому в 10 разів швидше. Помітивши це, я перевірив це на кількох контурах і файлах, і це було завжди однаково.

Чому трубопровід ddчерез gzipтакож збільшити швидкість передачі великого коефіцієнтом замість тільки зменшення bytelength потоку великого фактором? Натомість я очікував навіть невеликого зниження швидкості передачі через велике споживання процесора під час стискання, але тепер я отримую подвійний плюс. Не те, що я не задоволений, але мені просто цікаво. ;)

— Foo Bar
джерело

1

512 байт був стандартним розміром блоку для зберігання файлів у ранньому Unix. Оскільки все є файлом в Unix / Linux, воно стало за замовчуванням майже для всього. Більш новіші версії більшості комунальних служб збільшили цю, але не дд.

— DocSalvager

Проста відповідь полягає в тому, що ddвиводиться зі швидкістю 1 Мб / с ... прямо в gzipтрубу очікування . Це дуже мало стосується розміру блоку.

— Tullo_x86

100

ddза замовчуванням використовує дуже невеликий розмір блоку - 512 байт (!!). Тобто, багато малого читає і пише. Здається, що dd, використовуючи наївно у своєму першому прикладі, було генерувати велику кількість мережевих пакетів з дуже невеликим корисним навантаженням, таким чином зменшуючи пропускну здатність.

З іншого боку, gzipдосить розумний для вводу / виводу з більшими буферами. Тобто менша кількість великих записів по мережі.

Чи можете ви спробувати ddще раз із більшим bs=параметром і побачити, чи працює він краще цього разу?

20

Дякуємо, спробувала пряма копія без gzip та блокування bs=10M-> швидкої передачі мережі приблизно 3 або 4 Мб / с. Більш високий розмір + gzipнічого не змінив порівняно з малим gzip.

— Foo Bar

7

Якщо ви хочете побачити, які високі розміри блоків, спробуйте інший dd після gzip.

— Джошуа

Чи gzip робить власну вихідну буферизацію чи просто використовує stdio?

— Бармар

@Barmar Якщо я читаю джерело правильно, він просто знаходиться write(3)в буфері.

@CongMa ви також можете спробувати використовувати pigz замість gzip, він буде працювати ще швидше

— GioMac

4

Трохи пізно до цього, але чи можу я додати ...

В інтерв'ю мене одного разу запитали, який би був найшвидший метод для клонування біт-бітових даних і грубо відповів із використанням ddабо dc3dd( DoD фінансується ). Інтерв'юер підтвердив , що трубопроводи ddдля ddбільш ефективної, так як це просто дозволяє одночасне читання / запис або з точки зору програміста stdin/stdout, таким чином , ultimatly подвоєння швидкості запису і час передачі Halfing.

dc3dd verb=on if=/media/backup.img | dc3dd of=/dev/sdb

— Садік Текін
джерело

1

Я не думаю, що це правда. Я просто зараз спробував. dd status=progress if=/dev/zero count=100000 bs=1M of=/dev/nullстановив 22,5 Гб / с, був 2,7 ГБ dd status=progress if=/dev/zero count=100000 bs=1M | dd of=/dev/null bs=1M. Так труба робить це повільніше.

— falsePockets

0

Конг правильний. Ви передаєте блоки з диска, нестиснених на диск, на віддалений хост. Ваш мережевий інтерфейс, мережа та ваш віддалений сервер є обмеженням. Спочатку потрібно підвищити продуктивність DD. Визначення параметра bs =, який вирівнюється в пам'яті буфера дисків, отримає найбільшу продуктивність з диска. Скажімо, наприклад, bs = 32M. Потім це заповнить буфер gzip на протоці швидкості руху sata або sas з буфера дисків. Диск буде більш схильний до послідовного передачі, що покращує пут. Gzip стисне дані в потоці та відправить їх у ваше місцезнаходження. Якщо ви використовуєте NFS, це дозволить передачі nfs бути мінімальними. Якщо ви використовуєте SSH, тоді ви занурюєте накладні і шифрування SSH. Якщо ви використовуєте netcat, у вас немає шифрування над головою.

— Роберт
джерело

0

Я припускаю, що про "швидкість передачі", на яку ви посилаєтеся, повідомляється dd. Це насправді має сенс, адже ddнасправді передається 10-кратна кількість даних за секунду ! Однак, ddце не передача по мережі - ця робота обробляється gzipпроцесом.

Деякий контекст: gzipспоживає дані зі своєї вхідної труби так само швидко, як зможе очистити свій внутрішній буфер. Швидкість, з якою gzipспорожняється буфер, залежить від кількох факторів:

Пропускна здатність запису вводу / виводу (яка є вузькою мережею і залишається постійною)
Пропускна здатність зчитування вводу / виводу (яка буде набагато вище, ніж 1 Мб / с зчитування з локального диска на сучасній машині, таким чином, не є ймовірним вузьким місцем)
Його коефіцієнт стиснення (який я вважаю, що ваше 10-кратне прискорення буде приблизно 10%, що вказує на те, що ви стискаєте якийсь текст, що повторюється, наприклад файл журналу чи якийсь XML)

Так що в цьому випадку мережа може обробляти 100 кБ / с і gzipстискає дані приблизно в 10: 1 (і не обмежується процесором). Це означає, що в той час як він виводить 100 кБ / с, він gzipможе споживати 1 Мб / с, а швидкість споживання - це те, що ddможна побачити.

— Tullo_x86
джерело