Điều gì làm hạn chế hiệu suất của scp?

Tôi có hai máy Debian Linux được kết nối qua 1 Gbit LAN. Tôi có thể đo lường điều này bằng cách truyền tệp HTTP thô với tốc độ wgetkhoảng 100MB / giây theo bất kỳ hướng nào.

Khi tôi sử dụng scp, mức tối đa mà không nén tôi nhận được là khoảng 15MB / s . Kích hoạt tính năng nén với -Ccờ mang lại cho tôi, tùy thuộc vào nội dung, tối đa 50MB / s .

Tuy nhiên, dường như có rất nhiều băng thông bị lãng phí ở đây. Tôi đã không bận tâm trong một thời gian dài cho đến khi tôi thực sự phải suy nghĩ về một số lần chuyển logfile rất lớn và chỉ nhận ra sự chậm chạp kỳ lạ như thế nào scp. Đó là điều tự nhiên đối với tôi để sử dụng scp, ngay cả trong môi trường công ty, bởi vì tất cả các cơ sở hạ tầng được thiết lập cho nó.

Điều gì giới hạn hiệu suất của scp rất nhiều? Có phải CPU bị ràng buộc vì mã hóa? Khi tôi sử dụng htop, có vẻ như nó không sử dụng CPU đa lõi, chỉ một trong bốn CPU là tối đa.

Có cách nào để tăng thông lượng? Tôi đã có sẵn máy chủ HTTP và samba, nhưng để di chuyển các tệp giữa các máy Linux, tôi thường chỉ sử dụng SSH, đó là cách tôi lớn lên cùng với nó. Nhưng điều này bây giờ khiến tôi suy nghĩ về nó, có vẻ như tôi cần xem xét các cách chuyển khác cho một lượng lớn dữ liệu.

HTTP chỉ được sử dụng cho ứng dụng cụ thể trong PHP / Java / bất cứ điều gì và samba được sử dụng vì một số lý do đặc biệt chúng tôi cần truy cập từ các máy Windows.

Có lẽ đó là mã hóa. Bạn có thể thử scp với các mật mã khác nhau, ví dụ:

scp -c arcfour src dest

Kiểm tra trang hướng dẫn ssh_config để biết Mật mã có sẵn. RC4 (arcfour) là một mật mã nhanh, nhưng có lẽ không an toàn như một số lựa chọn thay thế.

Một phần của nó có thể liên quan đến việc triển khai OpenSSH nội bộ. Hãy xem HPN-SSH để có lời giải thích hợp lý cho một lý do cho các tắc nghẽn và bản vá cho OpenSSH có thể giải quyết nó (nếu bạn sẵn sàng vá và xây dựng lại từ nguồn).