Tại sao scp với nén chậm hơn mà không có?

Tôi cần chuyển tệp vdisk 20 GB KVM , lưu trữ hệ thống tệp gốc của máy ảo CentOS 6.5, từ máy chủ phòng thí nghiệm này sang máy chủ phòng thí nghiệm khác. Kích thước tệp lớn và thực tế là tôi đã từng nén một tệp vdisk như vậy đến vài trăm byte khiến tôi có khả năng nén theo bản năng scpnhưng tôi rất ngạc nhiên khi thấy tốc độ truyền khá thấp. Sau đó, tôi đã thử bzip2kết hợp với sshvà catvà giật mình. Dưới đây là tóm tắt về các phương pháp và thông lượng trung bình.

• scp -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 11 MB / s.
• bzip2 -c vm1-root.img | ssh -l root 192.168.161.62 "bzip2 -d -c > /mnt/vdisks/vm1-root.img", 5 MB / s. Kết quả này thậm chí thấp hơn nhắc nhở tìm kiếm trên Net.
• scp -c arcfour -C vm1-root.img root@192.168.161.62:/mnt/vdisks/, 13 MB / s. Việc sử dụng này -c arcfournhư được đề xuất trong một câu trả lời trên serverfault. Nó hầu như không giúp đỡ. Cuối cùng, tôi đã tắt tính năng nén.
• scp vm1-root.img root@192.168.161.62:/mnt/vdisks/, 23 MB / s.

Không nên nén đã nhanh hơn?

EDIT: Tôi không biết tại sao câu hỏi đã bị hạ cấp. Tôi nghĩ rằng có một cái gì đó để được học ở đây.

Sau khi nhận được ssh(1)mẹo trang man từ @sven, tôi đã thử một vài phương pháp chuyển tập tin thay thế không liên quan đến nén, cả hai đều có kết quả tốt hơn.

• cat vm1-root.img | ssh -l root 192.168.161.62 "cat > /mnt/vdisks/vm1-root.img", 26 MB / s.

• nc -l 5678 > /mnt/vdisks/vm1-root.imgtrên máy thu và nc 192.168.161.62 5678 < vm1-root.imgtrên máy phát, 40 MB / s. Cổng 5678là một tùy ý có sẵn.

Sử dụng nchóa ra là phương pháp sao chép nhanh nhất!

Trong quá khứ, scp -Cđã làm việc rất tốt bất cứ khi nào tôi nghĩ rằng nó sẽ. Ví dụ: khi chuyển syslog ( /var/log/messages*) có kích thước vài GB. Tốc độ truyền không nén vài trăm KB / s sẽ tăng lên 1-2 MB / s. Ví dụ này không thuộc trường hợp kết nối chậm như đã được chỉ ra trong trang man.

Tôi có một trường hợp, một hình ảnh vdisk mới được tạo cho phân vùng 20 GB có kích thước nén chỉ 200 MB. Với tốc độ truyền khoảng 25 MB / s, chúng tôi có thể thực hiện sao chép chỉ trong 8 giây thay vì hơn 13 phút! Rõ ràng, scpkhông nén là không hiệu quả trong trường hợp này và scp -Cthậm chí còn tồi tệ hơn.

Tôi đoán, bài học chính được học ở đây là, scp -Cnên được coi là chỉ là một tiện lợi. Nếu một tệp có thể được nén đáng kể, thì tốt hơn hết là trước tiên hãy nén nó trên nguồn, chuyển biểu mẫu đã nén và cuối cùng là nén vào đích. Các công cụ thực hiện nén và giải nén nhanh chóng (ví dụ pbzip2 ) sẽ giúp ích nhiều hơn.

Trích dẫn man ssh(là cơ sở được sử dụng bởi scp):

Nén là mong muốn trên các dòng modem và các kết nối chậm khác, nhưng sẽ chỉ làm chậm mọi thứ trên các mạng nhanh.

Vấn đề là việc nén dữ liệu mất nhiều thời gian hơn sau đó chỉ cần gửi nó qua mạng.

Ngoài ra, trên đỉnh nén, nc có tỷ lệ tốt nhất vì nó cũng không mã hóa. Và nén không mất dữ liệu phụ thuộc vào việc tìm các phần dữ liệu dư thừa, khi được thực hiện ở cấp độ mạng, bạn có thể xem tối đa các byte [kích thước bộ đệm] trong đó khi được thực hiện với toàn bộ tệp trước tiên, đó là byte [kích thước tệp] trong đó để săn và crunch câu byte trùng lặp.

Ngoài ra, để di chuyển hình ảnh đĩa, bạn nên sử dụng một công cụ nhận biết hệ thống tập tin như ntfsclone / partclone vì ngay cả việc nén cũng không thể đánh bại việc bỏ qua các khối chưa được phân bổ - tốc độ truyền của bạn là vô hạn nếu bạn không phải truyền bất kỳ dữ liệu nào. Ngoài ra, đừng quên phá hủy các tệp hoán đổi và ngủ đông trên phân vùng cửa sổ hoặc bạn đang sao chép rác, nó sẽ chỉ vứt đi và tạo lại bằng mọi cách.