Чому scp такий повільний і як зробити це швидше?

59

Я намагаюся скопіювати пакет файлів, scpале це дуже повільно. Це приклад з 10 файлами:

$ time scp cap_* user@host:~/dir
cap_20151023T113018_704979707.png    100%  413KB 413.2KB/s   00:00    
cap_20151023T113019_999990226.png    100%  413KB 412.6KB/s   00:00    
cap_20151023T113020_649251955.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_284028464.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_927950468.png    100%  413KB 413.0KB/s   00:00    
cap_20151023T113022_567641507.png    100%  413KB 413.1KB/s   00:00    
cap_20151023T113023_203534753.png    100%  414KB 413.5KB/s   00:00    
cap_20151023T113023_855350640.png    100%  412KB 411.7KB/s   00:00    
cap_20151023T113024_496387641.png    100%  412KB 412.3KB/s   00:00    
cap_20151023T113025_138012848.png    100%  414KB 413.8KB/s   00:00    
cap_20151023T113025_778042791.png    100%  413KB 413.4KB/s   00:00    

real    0m43.932s
user    0m0.074s
sys 0m0.030s

Дивна річ у тому, що швидкість передачі становить близько 413 КБ / с, а розмір файлу - близько 413 КБ, тому він дійсно повинен передавати один файл в секунду, однак це займає приблизно 4,3 секунди на файл.

Будь-яка ідея, звідки береться цей наклад, і чи є спосіб зробити це швидше?

scp time batch-jobs

— ларан
джерело

3

Яку швидкість ви очікуєте (тобто чи є ще один протокол, який показує більш високу швидкість передачі між цими ж двома машинами)? Що станеться, коли ви скачуєте значно більший файл (можливо, з'єднання всіх ваших файлів 413 Кб)?

— даг

6

Схоже, віддалена система, можливо, намагається вирішити IP-адресу клієнта на ім'я, і вам доведеться почекати тайм-аут, перш ніж тривати сеанс. Ви можете дослідити виправлення цього (наприклад, додати свою IP-адресу до файлу / etc / hosts призначення).

— wurtel

4

Варто зазначити, що прапор -C дозволяє стиснути під час передачі. Незважаючи на те, що ваша проблема здається накладними передачами, стиснення в основному "безкоштовне" і майже завжди допомагає.

— Сем

@wurtel: Я не бачу того, що ти бачиш, все, що я бачу, це часи. У будь-якому випадку повинен бути лише один зворотний дзвінок DNS.

— James Reinstate Моніка Полк

Ви покладаєтесь на SCP для безпеки або лише для віддаленого копіювання?

— Фрайхейт

17

@ wurtel коментар, ймовірно, правильний: багато накладних витрат встановлюють кожне з'єднання. Якщо ви зможете встановити, що ви отримаєте швидші перекази (а якщо не можете, просто скористайтеся способом rsyncвирішення @ roaima ). Я зробив експеримент, перенісши файли подібного розміру ( head -c 417K /dev/urandom > foo.1і зробив кілька копій цього файлу) на хост, який потребує певного часу для підключення (HOST4), і той, який реагує дуже швидко (HOST1):

$ time ssh $HOST1 echo


real    0m0.146s
user    0m0.016s
sys     0m0.008s
$ time scp * $HOST1:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m0.337s
user    0m0.032s
sys     0m0.016s
$ time ssh $HOST4 echo


real    0m1.369s
user    0m0.020s
sys     0m0.016s
$ time scp * $HOST4:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m6.489s
user    0m0.052s
sys     0m0.020s
$

1

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

— Лоран

1

Отже, Ваша гіпотеза: чи створює нове з'єднання один раз для кожного файлу?

— rogerdpack

59

Ви можете використовувати rsync(понад ssh), який використовує єдине з'єднання для передачі всіх вихідних файлів.

rsync -avP cap_* user@host:dir

Якщо у вас немає rsync(і чому не!?) , Ви можете використовувати tarз sshподібним чином, що дозволяє уникнути створення тимчасового файлу:

tar czf - cap_* | ssh user@host tar xvzfC - dir

rsyncЄ кращим, при інших рівних умовах , тому що це перезапускати у разі переривання.

— roaima
джерело

6

Ви говорите, що одне scpвиклик не використовує єдине з'єднання для передачі всіх файлів?

— CVn

1

У випадку з tarpipe немає потреби в f -кожній стороні, оскільки tar за замовчуванням виводить / читає з stdout / stdin. Так tar cz cap_* | ssh user@host tar xvzC dirби і зробили.

— тремтіння

1

@tremby не обов'язково. tarможна компілювати з різними значеннями за замовчуванням (дивіться, tar --show-defaultsчи використовуєте ви тар GNU чи /etc/default/tarіншим способом, і в обох випадках не забудьте TAPEзмінну оточення)

— roaima

1

@ MichaelKjörling спочатку я припускав, що scpстворить нове з'єднання для кожного файлу, але при спогаді - і після подвійної перевірки tshark- зрозумів, що я помиляюся. На даний момент я вже не впевнений, чому ОП scpповинні брати так довго один файл.

— roaima

@roaima, цікаво, дякую. Я ніколи не помічав, що stdin / stdout поки не є типовим. BSD tar на моєму Mac під час роботи не згадує TAPE env var на своїй довільній сторінці, хоча GNU tar на моїй машині Linux це робить.

— тремтіння

15

Час переговорів про передачу вимагає часу. Взагалі, операції над n файлами з байтів b займають багато, набагато довше, ніж одна операція над одним файлом з n * b байтів. Це також справедливо, наприклад, для вводу / виводу диска.

Якщо ви уважно подивитесь, то побачите, що швидкість передачі в цьому випадку становить розмір_файла_файлу / сек.

Щоб ефективніше переносити файли, з'єднайте їх разом із ними tarта перенесіть тарбол:

tar cvf myarchive.tar cap_20151023T*.png

або, якщо ви також хочете стиснути архів,

tar cvzf myarchive.tar.gz myfile*

Стискати чи ні, залежить від вмісту файлу, наприклад. якщо вони JPEG або PNG, стиснення не матиме жодного ефекту.

— dr01
джерело

У PNG використовуються дефлятори, і зціджувати їх також безглуздо.

— Arthur2e5

Я б сказав, що тому, що стискання смоли не має негативних наслідків, коли файли неможливо далі стискати, - це хороша практика просто поставити-z

— Centimane

1

@ Увійдіть, якщо їх неможливо стиснути або мережа швидка, це сповільнить роботу.

— Davidmh

@Davidmh це було б на значну суму? Я думаю, що стиснення вже стисненого файлу було б досить швидким, оскільки воно справді просто перегляне, що він може стиснути, і виявить, що це нічого. Залежно я здогадуюсь, якщо tarзазвичай проходить другий прохід для стиснення або якщо він би одночасно стискав і архівував

— Centimane

3

@ У моєму випадку (дані про сучасний HD-7000 об / хв, процесор високого класу, дуже швидка мережа, зовсім не хвастощі), дьоготь без стиснення суто пов'язаний з IO, але при цьому -zпов'язаний з процесором і набагато повільніше. gzip завжди намагатиметься стиснути, отже, уповільнення; зрештою, ви не можете сказати, чи стискається рядок байтів, поки ви не спробували її стиснути. У моїй настройці, навіть при передачі простих текстових файлів, rsync без стиснення є найшвидшим на 2-3 рази порівняно з найлегшим стисненням. Звичайно, YMMV.

— Давідм

6

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

HPN-SSH - це виправлена версія OpenSSH, яка збільшує розмір цих буферів. Це має велику різницю в швидкості передачі scp (див. Графіки на сайті, але я також кажу з особистого досвіду). Звичайно, щоб отримати переваги, необхідні для встановлення HPN-SSH на всіх своїх хостах, але це варто того, якщо вам регулярно потрібно передавати великі файли навколо.

— Менно Смітс
джерело

5

Я використовував описану тут техніку, яка використовує паралельні gzip та netcat для швидкого стиснення та копіювання даних.

Він зводиться до:

# SOURCE: 
> tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | nc -l 8888

# TARGET:
> nc <source host> 8888 | pigz -d | tar xf - -C /

При цьому використовується tar для збору файлу або файлів. Потім використовує pigz, щоб отримати багато потоків процесора для стискання та надсилання файлу, мережева передача використовує netcat. На приймальній стороні netcat прослуховує потім стискає (паралельно) і untars.

— Фрейхейт
джерело

3

ncне шифрується. Додайте трохи ssh -Dмагії?

— Arthur2e5

це насправді досить блискуче

— Джабран Саїд

5

Щойно ця проблема робила передачу великого файлу mp4 з сайту на сайт scp. Отримував ~ 250 КБ / с. Після відключення захисту від повені UDP на брандмауері призначення передача зросла до 6,5 МБ / с. При вмиканні FP швидкість знизилася до ~ 250 КБ / с.

Відправник: cygwin, приймач: Fedora 20, брандмауер Sophos UTM.

Для чого SSH використовує UDP? @ superuser.com - Це не безпосередньо з того, що я читаю.

Переглядаючи журнал брандмауера, виявлення затоплення відбувалося як у вихідних, так і в цільових портах 4500 через загальнодоступні IP-адреси, а не на приватні VPN-адреси приватного сайту на сайт. Тож здається, що моя проблема, ймовірно, обходиться NAT обхідною ситуацією, коли scpдані TCP в кінцевому рахунку шифруються та інкапсулюються в пакети ESP та UDP і, отже, підлягають FP. Щоб видалити scpз рівняння, я запустив операцію копіювання файлів Windows через VPN і помітив схожі показники роботи scpз та без включеного FP. Також пройшов iperfтест на TCP і помітив 2 Мбіт / сек з FP, і 55 Мбіт / сек без.

Як NAT-T працює з IPSec? @ cisco.com

— bvj
джерело