У меня есть две машины Debian Linux, подключенные через 1 Гбит LAN. Я могу измерить это с помощью необработанной передачи файлов HTTP с wget который получает около 100 МБ / с в любом направлении.
Когда я сейчас использую scp, максимум без сжатия я получаю около 15 МБ / с. Включение сжатия с помощью -C flag дает мне, в зависимости от содержимого, до 50 МБ / с.
Тем не менее, есть много пропускная способность здесь потрачена впустую. Я долго не беспокоился, пока мне действительно не пришлось подумать о передаче очень больших файлов журналов, и я просто понял, насколько странно медленным scp является. Для меня естественно использовать scp, даже в среде компании, потому что вся инфраструктура настроена для этого.
Что так сильно ограничивает производительность scp? Связано ли это с ЦП из-за шифрования? Когда я использую htop похоже, что он не использует многоядерные процессоры, только один из четырех процессоров максимален.
Есть ли способ увеличить пропускную способность? У меня есть HTTP-серверы и samba, но для перемещения файлов между Linux-машинами я обычно использую SSH, именно так я и вырос. Но сейчас это заставляет меня задуматься, кажется, мне нужно рассмотреть другие способы передачи больших объемов данных.
HTTP используется только для определенного приложения в PHP / Java / любом другом, а самба используется по некоторым особым причинам, нам нужен доступ с компьютеров Windows.
Наверное, дело в шифровании. Вы можете попробовать scp с разными шифрами, например:
scp -c arcfour src dest
Просмотрите страницу руководства ssh_config, чтобы узнать о доступных Шифрах. RC4 (arcfour) - быстрый шифр, но, вероятно, не такой безопасный, как некоторые альтернативы.
Частично это может быть связано с внутренней реализацией OpenSSH. Взгляни на HPN-SSH для достойного объяснения одной из причин узких мест и исправлений для OpenSSH, которые могут решить эту проблему (если вы желаете исправлять и перестраивать из исходного кода).