У меня есть Linux, который я использую как файловый сервер. У меня есть ежемесячное задание cron, которое обрабатывает содержимое диска с данными, а затем копирует его через scp на другой компьютер для безопасного хранения. Размер полученного архива составляет около 300 ГБ, и обычно для завершения копирования требуется около полутора дней (через соединение Wi-Fi 802.11g).
Сегодня я заметил, что моя работа по резервному копированию еще не завершена и выполняется уже 3 дня. Проверяя целевую машину, я мог видеть, что пока скопировано только около трети данных, и, похоже, они растут со скоростью <300 КБ / сек.
С помощью iperf между двумя машинами я вижу, что пропускная способность моей сети составляет около 20 Мбит / с, что примерно соответствует тому, что я ожидаю от соединения 802.11g.
С помощью dd if=srcfile of=/dev/null на исходной машине я могу читать около 45 МБ / с с исходного диска (внешнего USB-накопителя).
с помощью dd if=/dev/zero of=/destdrive/tmp.dat на конечном компьютере я могу записать около 30 МБ / с на целевой диск (внутренний диск SATA). Кажется немного медленным для диска SATA, но не безосновательно медленным (и уж точно не медленным на 300 КБ / с).
Итак, я, похоже, исключил пропускную способность сети и пропускную способность диска на обоих концах, так где еще я могу найти источник узкого места?
Почему вы используете scp для копирования больших файлов в первую очередь? scp имеет свои накладные расходы (шифрование, проверка подлинности и т. д.).
Ты можешь использовать rsync (rsync очень хорошо подходит для передачи больших файлов по ssh, потому что он может продолжать передачу, которая была прервана по какой-либо причине. Поскольку он использует хэш-функции для обнаружения одинаковых блоков файлов, функция продолжения является довольно надежной.) или какой-либо другой инструмент.
Пожалуйста, посмотрите этот пост. Копирование больших файлов по сети быстрее
Если вы все равно хотите использовать scp, вам следует использовать traceroute и tcpdump и iftopчтобы увидеть пакеты от источника к месту назначения. Может быть, вы найдете что-нибудь необычное.
Убедитесь, что опция -l не включена для ограничения пропускной способности. Кроме того, похоже, что есть опция -v, которая даст представление о том, что происходит при следующем запуске.
Подробный режим. Заставляет scp и ssh (1) печатать отладочные сообщения об их ходе. Это полезно при отладке проблем с подключением, аутентификацией и конфигурацией.
На это уже был дан ответ. Цитата из ответа.
scp использует интерактивный терминал, чтобы распечатать этот причудливый индикатор выполнения. Печать этого вывода в файл вообще не имеет смысла, поэтому scp определяет, когда его вывод перенаправляется куда-то еще, кроме терминала, и отключает этот вывод.
Полный ответ
https://stackoverflow.com/questions/3890809/bash-stdout-redirect-of-commands-like-scp
Страница руководства SCP
Я также столкнулся с низкой производительностью SCP при копировании файлов ~ 150-300 КБ / с вместо 10 МБ / с. Также я заметил, что на целевом сервере 1 ядро ЦП было занято на 100%, пока я копировал файл. Я немного погуглил и нашел предложение: отключить "Оптимизировать размер буфера подключения" в параметрах подключения SCP. Это помогло. После отключения этой опции скорость увеличилась до ожидаемого сетевого уровня, нагрузка на CPU на сервере значительно снизилась.