Чи є більш швидка альтернатива cp для копіювання великих файлів (~ 20 ГБ)?

Я аспірант, а група, в якій працюю, підтримує кластер Linux. У кожного вузла кластера є свій локальний диск, але ці локальні диски відносно невеликі і не обладнані автоматичною резервною копією. Таким чином, група володіє файловим сервером з багатьма TB місцями для зберігання. Я відносний початківець Linux, тому я не впевнений, які є характеристики сервера файлів щодо швидкості, здатності до мережі та ін. Я знаю з досвіду, що локальні диски значно швидше, ніж файловий сервер з точки зору вводу / виводу . Близько десятка або близько людей використовують сервер файлів.

Використання cpдля копіювання файлу ~ 20 Гб з сервера файлів на один з локальних дисків в середньому займає приблизно 11,5 хвилин (відповідно time). Я знаю, що ця cpоперація не дуже ефективна, тому що (1) timeпідказує мені, що системний час для такої копії становить лише ~ 45 секунд; і тому, що (2), коли я перевіряю topпід час копіювання, % процесора досить низький (за допомогою перевірки, приблизно в середньому 0-10% ).

Використання cpдля копіювання одного і того ж файлу ~ 20 ГБ з однієї папки на локальному диску в іншу папку на цьому ж локальному диску займає менше часу - приблизно 9 хвилин у режимі реального часу (~ 51 секунди в системний час, відповідно time). Отже, очевидно, що сервер файлів дещо повільніше, ніж локальний диск, як очікувалося, але, можливо, не значно повільніше. Я здивований, що копіювання з локального на той самий локальний відбувається не швидше, ніж за 9 хвилин.

Мені потрібно скопіювати ~ 200 великих файлів - кожен ~ 20 ГБ - з сервера файлів на один з локальних дисків. Отже, моє запитання: чи існує більш швидка альтернатива cpкопіюванню великих файлів в Linux? (Або є якісь прапори в межах , cpякі я міг би використовувати , який прискорить копіювання?) Навіть якби я міг як - то збрити хвилину з цього часу копіювання, що допомогло б безмірно.

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

% CPU має бути низьким під час копіювання. Процесор повідомляє дисковому контролеру "захопити дані з секторів X – Y в буфер пам'яті на Z". Потім йде і робить щось інше (або спить, якщо нічого іншого немає). Апаратне забезпечення запускає переривання, коли дані знаходяться в пам'яті. Потім процесору доводиться копіювати його кілька разів і повідомляє мережевій карті "передавати пакети в місцях пам'яті A, B і C". Тоді це повертається до чогось іншого.

Ви натискаєте ~ 240 Мбіт / с. У гігабітній локальній мережі ви повинні мати принаймні 800 Мбіт / с, але:

1. Це спільний доступ до всіх, хто використовує файловий сервер (і, можливо, з'єднання між комутаторами тощо)
2. Це обмежено швидкістю, якою файловий сервер може керувати записом, пам’ятаючи про його пропускну здатність дискового вводу / виводу, який ділиться всіма користувачами.
3. Ви не вказали спосіб доступу до файлового сервера (NFS, CIFS (Samba), AFS тощо). Можливо, вам доведеться налаштувати мережеве кріплення, але за останнім часом, за замовчуванням, налаштування за замовчуванням зазвичай є досить розумними.

Для відстеження вузького місця, iostat -kx 10корисною буде команда. Він покаже вам використання на локальних жорстких дисках. Якщо ви можете запустити це на файловому сервері, він підкаже, наскільки зайнятий файловий сервер.

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

• Якщо файли стискаються і у вас швидкий процесор, то мінімальне стиснення під час руху може бути швидше. Щось на кшталт lzopчи, можливо gzip --fastest.
• Якщо ви змінюєте лише кілька біт тут і там, а потім надсилаєте файл назад, лише надсилання дельт буде набагато швидше. На жаль, rsyncтут не дуже допоможе, оскільки для знаходження дельти потрібно буде прочитати файл з обох сторін. Натомість вам потрібно щось, що відстежує дельту під час зміни файлу ... Більшість підходів тут залежать від програми. Але можливо, що ви могли б щось налаштувати, наприклад, пристрою-картографом (див. Нову ціль ери dm ) або btrfs.
• Якщо ви копіюєте однакові дані на декілька машин, ви можете використовувати щось на зразок udpcast, щоб одразу надсилати їх на всі машини.

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

Можливо, це може бути швидшою альтернативою, і ви не будете забивати мережу протягом двох днів: візьміть один або два великих USB (USB 3, якщо у вас є) або FireWire диски, підключіть його до сервера та скопіюйте файли на диск. Перенесіть диск на локальну машину. Скопіюйте файли на апарат.

Ваше визначення ефективності є зворотним. Більш ефективна реалізація витрачає менше процесорного часу. На локальній копії ви отримуєте в середньому близько 74 Мб / с пропускної здатності (читання + запис), що приблизно так само добре, як і один жорсткий диск.

Якщо у вас є прямий доступ SSH (або SFTP) (запитайте свого sysadmin), ви можете використовувати scpкомпресію ( -C):

scp -C you@server:/path/to/yourfile .

Звичайно, це корисно лише в тому випадку, якщо файл є стисливим, і це зажадає більше часу процесора, оскільки він буде використовувати шифрування (тому що це більше SSH) та стискання.

cpРеалізація, швидше за все , не є вузьким місцем. Спробуйте спостерігати за використанням IO через iotopсервер і вузол кластера. Це дасть вам уявлення, де можна покращити продуктивність.

Ще одна порада - уникати копіювання одних і тих же даних з одного хоста. Наприклад, якщо у вас є однаковий 20G-файл для розповсюдження з файлового сервера по всім вузлам кластера, він буде працювати набагато швидше, якщо ви копіюєте файли в режимі однорангового, а не одного сервера до всіх клієнтів. Це трохи складніше в реалізації, але ви навіть можете спробувати використовувати якийсь командний рядок p2p, як концентратор прямого підключення.

Якщо в межах цих файлів 20G деяка частина є загальною, а частина - специфічною для вузла кластера, розгляньте їх поділ на загальні та конкретні частини, а потім розподіліть загальну частину у спосіб p2p.

Характер / вміст цих файлів може дещо змінитись. Я зрозумів, що вам потрібно скопіювати 200 файлів, ~ 20 ГБ кожен, з одного комп'ютера на інший, це?

Якщо ці файли стисливі або мають подібні / однакові фрагменти, у вас є два підходи:

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

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

редагувати

Чи потрібно буде копіювати ці файли багато разів ?? (наприклад, копія -> використовувати ці файли -> змінити щось у файлах на комп'ютері A -> копіювати файли знову на комп'ютер B)

Якщо так, rsync буде корисним, тому що він спробує виявити рівне серед версій, а не скопіювати те, що не змінилося.

І третій метод: якщо вищевказане правильно (зміни файлу, а потім скопіюйте всі файли знову на другий комп'ютер), ви можете спробувати деякі binary diffпросто змінити на другому комп'ютері те, що було змінено на першому комп’ютері.

Тут я бачу наступне: шифрування не є хорошою ідеєю, оскільки це, можливо, ПОСЛІДЖИТЕ кількість даних, що передаються.

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

Якщо ви копіюєте локально, подивіться, як протікає процес, він є єдиним потоком, тому стандартні утиліти Linux використовують:

- for all blocks in a file
      read a block
      write a block

У цій операції НЕ БЕЗПЕЧЕННЯ.

Щоб пришвидшити речі, ви можете використовувати щось подібне:

  buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte

Додаткову інформацію див. У головній сторінці буфера (1).

Команда буфера встановлює два процеси для одночасного запуску процесу копіювання: один для читання, а другий для запису, і він використовує буфер спільної пам'яті для передачі даних між двома процесами. Буфер спільної пам’яті - це ваш класичний круговий буфер, який запобігає перезапису неписаних даних та запису даних, уже написаних. Я використовував цю програму, щоб відрізати близько 10-20% часу копіювання при передачі з диска на стрічку.

Чому б не спробувати алгоритм розповсюдження P2P, якщо вам потрібно одночасно оновити весь кластер?

https://github.com/lg/murder - це те, що використовується twitter

Можна також спробувати BTSync .

Якщо ви часто копіюєте одні і ті ж набори файлів з локального комп'ютера на сервер із незначними змінами тут і там. Ви можете пришвидшити передачу, використовуючи rsync або DVCS (наприклад, hg або git).

git або hg можуть відслідковувати та виявляти дельти і лише передавати ці дельти. У випадку використання git, оскільки обидві сторони мають повну історію сховища, з'ясувати дельту дуже дешево.

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

Ви можете спробувати упакувати всі файли в єдиний архів (не потрібно стискати). На мій досвід, копіювання одного архіву відбувається швидше, ніж копіювання великої кількості окремих файлів

Спробуйте bbcp . Тестування в нашому середовищі виявило, що cp вбудований у якийсь guner. Будьте обережні, тому що, коли ви знімаєте губернатор, ви можете перевести лінію на сервер і викликати відключення. У нашому випадку ми брали сервер в автономному режимі, щоб зробити копію, тому швидше було краще. Це покращило час перенесення на кілька годин.

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

Іноді дивно, скільки часу витрачається навіть на копіювання на той самий хост (жодна мережа не бере участь).

Побачити мою відповідь на інше запитання cp тут . Коротше кажучи, перезапис існуючого файлу відбувається набагато повільніше, ніж обрізання його або спочатку від’єднання, а потім копіювання. Останнє на 8 разів швидше для файлу 1,2 ГБ.