Почему 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 Laurent
источник
3
Какую скорость вы ожидаете (т. Е. Есть ли другой протокол, который показывает более высокие скорости передачи между теми же двумя машинами)? Что происходит, когда вы копируете намного больший файл (возможно, объединение всех файлов размером 413 КБ)?
дхаг
6
Похоже, что удаленная система может пытаться преобразовать IP-адрес клиента в имя, и вам придется ждать тайм-аут, прежде чем продолжить сеанс. Вы можете проверить исправление этого (например, добавить свой IP-адрес в файл / etc / hosts).
wurtel
4
Стоит отметить, что флаг -C включает сжатие во время передачи. Хотя ваша проблема, похоже, связана с запуском передачи, сжатие в основном «бесплатное» и почти всегда помогает.
Сэм
@wurtel: я не вижу, что вы видите, все, что я вижу, это времена. В любом случае необходим только один обратный вызов DNS.
Джеймс восстановил Монику Полк
Вы полагаетесь на SCP для обеспечения безопасности или только для удаленного копирования?
Freiheit

Ответы:

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(over 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 tar или /etc/default/tarиным образом, и в обоих случаях не забудьте TAPEпеременную окружения)
roaima
1
@ MichaelKjörling Первоначально я предполагал, что scpэто создаст новое соединение для каждого файла, но, вспомнив - и после двойной проверки tshark- я понял, что я ошибался. На данный момент я больше не уверен, почему ОП scpдолжны так долго занимать файл.
Роайма
@roaima, интересно, спасибо. Я никогда не замечал, что stdin / stdout пока не используется по умолчанию. В моей справочной странице tar BSD на моем Mac не упоминается переменная TAPE env var, а tar GNU на моей машине с Linux - нет.
дрожь
15

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

Если вы посмотрите внимательно, вы увидите, что скорость передачи в этом случае равна size_of_the_file / secs.

Для более эффективной передачи файлов объедините их вместе tar, а затем передайте архив:

tar cvf myarchive.tar cap_20151023T*.png

или, если вы также хотите сжать архив,

tar cvzf myarchive.tar.gz myfile*

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

dr01
источник
PNG используют deflate, и их сжатие также бессмысленно.
Arthur2e5
Я бы сказал, что, поскольку сжатие tar-файла не имеет негативных последствий, когда файлы не могут быть сжаты в дальнейшем, это хорошая практика, просто положить-z
Centimane
1
@ Дэйв, если они не могут быть сжаты или сеть работает быстро, это замедлит процесс.
Davidmh
@Davidmh это будет значительным количеством, хотя? Я бы подумал, что сжатие уже сжатого файла будет довольно быстрым, так как на самом деле он просто просмотрит то, что может сжать, и обнаружит, что это ничто. Зависит от того, я полагаю, если tarобычно выполняется второй проход для сжатия, или если это будет сжатие и архивирование одновременно
Centimane
3
@ В моем случае (данные на современном 7000 об / мин HD, высокопроизводительный ЦП, очень быстрая сеть, совсем не бахвальство), tar без сжатия чисто связан с вводом-выводом, но с -zограничением процессора и намного медленнее. gzip всегда будет пытаться сжать, отсюда и замедление; в конце концов, вы не можете сказать, является ли строка байтов сжимаемой, пока вы не попытались сжать ее. В моем случае, даже при передаче простых текстовых файлов, rsync без сжатия является самым быстрым в 2-3 раза по сравнению с самым легким сжатием. Конечно, YMMV.
Davidmh
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 прослушивает, затем распаковывает (параллельно) и разархивирует.

Freiheit
источник
3
ncне зашифрован ssh -DМожет быть, добавить немного магии?
Arthur2e5
это на самом деле довольно блестяще
Джабран Саид
5

Только что эта проблема была связана с передачей больших файлов mp4 между сайтами scp. Получал ~ 250 КБ / с. После отключения защиты от наводнений UDP (FP) на брандмауэре назначения скорость передачи увеличилась до 6,5 МБ / с. При повторном включении FP скорость упала до ~ 250 КБ / с.

Отправитель: cygwin, Получатель: Fedora 20, Firewall Sophos UTM.

Для чего SSH использует UDP? @ superuser.com - Это не прямо из того, что я прочитал.

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

Как NAT-T работает с IPSec? @ cisco.com

bvj
источник