Мне нужно было передать 20 ГБ KVM vdisk, хранящий корневую файловую систему виртуальной машины CentOS 6.5, с одного лабораторного сервера на другой. Большой размер файла и тот факт, что я однажды сжал такой файл виртуального диска до нескольких сотен мегабайт, заставили меня инстинктивно включить сжатие с помощью scp но я был удивлен, увидев довольно низкую скорость передачи. Потом я попробовал bzip2 в комбинации с ssh и cat и был поражен. Вот сводка методов и средней пропускной способности.
scp -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 11 МБ / с. bzip2 -c vm1-root.img | ssh -l root 192.168.161.62 "bzip2 -d -c > /mnt/vdisks/vm1-root.img", 5 МБ / с. Этот еще более низкий результат побудил поискать в сети.scp -c arcfour -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 13 МБ / с. Это использование -c arcfour как было предложено в один ответ при сбое сервера. Это вряд ли помогло. Наконец, я отключил сжатие.scp vm1-root.img root@192.168.161.62:/mnt/vdisks/, 23 МБ / с. Разве сжатие не должно было быть быстрее?
РЕДАКТИРОВАТЬ: Я не знаю, почему вопрос был отклонен. Я думал, здесь есть чему поучиться.
После получения ssh(1) Совет по странице руководства от @sven, я попробовал несколько альтернативных методов передачи файлов без сжатия, оба с лучшими результатами.
cat vm1-root.img | ssh -l root 192.168.161.62 "cat > /mnt/vdisks/vm1-root.img", 26 МБ / с.
nc -l 5678 > /mnt/vdisks/vm1-root.img на приемнике и nc 192.168.161.62 5678 < vm1-root.img на передатчике, 40 МБ / с. Порт 5678 - произвольный, который был доступен.
С помощью nc оказался самым быстрым методом копирования!
В прошлом, scp -C работал очень хорошо, когда я думал, что это будет. Например, при передаче системных журналов (/var/log/messages*) размером в несколько ГБ. Скорость передачи без сжатия в несколько сотен КБ / с увеличится до 1-2 МБ / с. Этот пример действительно подходит для случая медленного соединения, как было указано на странице руководства.
У меня есть случай, когда вновь созданный образ виртуального диска для раздела 20 ГБ имеет сжатый размер всего 200 МБ. Со скоростью передачи около 25 МБ / с мы могли сделать копирование всего за 8 секунд вместо 13 минут! Ясно, scp без сжатия в этом случае неэффективен и scp -C еще хуже.
Думаю, главный урок здесь заключается в том, что scp -C следует рассматривать только как удобство. Если файл может быть значительно сжат, то лучше сначала сжать его в источнике, передать сжатую форму и, наконец, выполнить dcompress в месте назначения. Инструменты, которые быстро выполняют сжатие и распаковку (например, pbzip2) будет большим подспорьем.
Цитирование man ssh (это база, используемая scp):
Сжатие желательно на модемных линиях и других медленных соединениях, но только замедлит работу в быстрых сетях.
Проблема в том, что сжатие данных занимает больше времени, чем просто их отправка по сети.
Кроме того, помимо сжатия, nc получает лучшую скорость, потому что также не шифрует. А сжатие без потерь основано на поиске избыточных разделов данных, которые, когда это делается на сетевом уровне, вы можете посмотреть максимум [размер буфера] байтов, где, когда выполняется сначала со всем файлом, это [размер файла] байтов. внутри которого можно искать и обрабатывать повторяющиеся байтовые предложения.
Также для перемещения образов дисков вы должны использовать инструмент, поддерживающий файловую систему, например ntfsclone / partclone, потому что даже сжатие не может победить простой пропуск нераспределенных блоков - ваша скорость передачи бесконечна, если вам не нужно передавать какие-либо данные. Также не забудьте уничтожить файлы подкачки и гибернации в разделе Windows, иначе вы копируете ненужные файлы, которые все равно будут выброшены и созданы заново.