Мне нужно было перенести файл виртуального диска KVM объемом 20 ГБ , хранящий корневую файловую систему виртуальной машины 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как было предложено в одном ответе на serverfault. Это вряд ли помогло. Наконец, я отключил сжатие.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следует рассматривать только как удобство. Если файл может быть значительно сжат, то лучше сначала сжать его в источнике, передать сжатую форму и, наконец, выполнить сжатие в месте назначения. Инструменты, которые выполняют сжатие и распаковку быстро (например, pbzip2 ), будут более полезными .
источник
scpвключает время, потраченное на сжатие / распаковку. Указанные значения могут показаться удивительными, если бы это было не так.Кроме того, помимо сжатия, nc получает лучшую скорость, потому что он также не шифрует. Сжатие без потерь основано на поиске избыточных участков данных, которые при выполнении на сетевом уровне вы можете посмотреть максимум на [размер буфера] байтов, тогда как при завершении всего файла сначала это байты [размер файла] в пределах которого можно охотиться и обрабатывать повторяющиеся предложения байтов.
Также для перемещения образов дисков вы должны использовать инструмент с поддержкой файловой системы, такой как ntfsclone / partclone, потому что даже сжатие не может превзойти простое пропускание нераспределенных блоков - ваша скорость передачи бесконечна, если вам не нужно передавать какие-либо данные. Также не забудьте уничтожить файлы подкачки и гибернации в разделе Windows, или вы копируете мусор, который он просто выбросит и все равно создаст заново.
источник