Чому scp з компресією відбувається повільніше, ніж без?

Мені потрібно було перенести файл Vdisk KVM розміром 20 Гб , зберігаючи кореневу файлову систему CentOS 6,5 ВМ, з одного лабораторного сервера на інший. Великий розмір файлу і той факт, що я колись стискав такий файл vdisk до кількох сотень мегабайт, змусив мене інстинктивно включити компресію, 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 Мб / с.

Чи не слід було стиснення бути швидшим?

EDIT: Я не знаю, чому це питання було скасовано. Я думав, що тут є чому навчитися.

Отримавши 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 МБ / с. Цей приклад потрапляє у випадку повільного з’єднання, як було зазначено на сторінці man.

У мене є випадок, коли новостворене зображення vdisk для розділу 20 ГБ має стислий розмір всього 200 МБ. З швидкістю передачі близько 25 Мб / с, ми могли зробити копіювання всього за 8 секунд замість понад 13 хвилин! Зрозуміло, що scpбез стиснення в цьому випадку неефективно і scp -Cще гірше.

Я здогадуюсь, головний урок, який тут засвоїли, - це те, що його scp -Cслід вважати лише зручністю. Якщо файл можна значно стиснути, то краще спершу стиснути його на джерело, перенести стиснуту форму і, нарешті, dcompress у пункті призначення. Інструменти, які швидко стискають і декомпресують (наприклад, pbzip2 ), будуть кориснішими .

Цитування man ssh(яка база використовується scp):

Стиснення бажано на модемних лініях та інших повільних з'єднаннях, але лише уповільнить роботу у швидких мережах.

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

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

Також для переміщення зображень на дисках ви повинні використовувати інструмент, відомий для файлової системи, як ntfsclone / partclone, оскільки навіть компресія не може перемогти просто пропускаючи неподілені блоки - швидкість передачі нескінченна, якщо вам не потрібно передавати будь-які дані. Також не забудьте знищити файли swap та сплячки на розділі Windows, або ви копіюєте мотлох, він просто викине та відтворить все одно.