Многие ссылки, соединяющие Нью-Йорк и AMS, часто перегружены. Это означает, что выполнение передачи по ним (например, перемещение 300 ГБ со скоростью 1 МБ / с) потребует времени по сравнению с тем, что могут предложить наши соединения.
Я сталкивался с этой проблемой в прошлом, примерно 3 года назад, когда я был действительно новичком в кодировании и Linux, я пришел к выводу, что опубликую в конце этого поста. Однако он грязный и мне это не нравится. Скрипт не работает как есть, поскольку он был написан для очень специфической среды, однако он дает вам идею.
У меня вопрос: знаете ли вы что-нибудь лучше, чем можно быстрее передавать файлы через океан?
#!/bin/sh
upto="$1"
filepath="$2"
remotepath="$3"
if [ ! -f ${filepath} ]
then
exit 0
fi
password=$(/all/script/password 10)
filesize=$(du -b ${2} | sed 's/\([0-9]*\)\(.*\)/\1/')
if [ $filesize -gt 5368709120 ]; then
parts="80"
elif [ $filesize -gt 2147483648 ]; then
parts="50"
elif [ $filesize -gt 1310720 ]; then
parts="20"
else
parts="2"
fi
splitsize=$(($filesize / $parts))
split -b "$splitsize" -a 2 "$2" /all/tmp/cup/${password}_
#UPLOAD
declare -a pwait
for tmpfile in /all/tmp/cup/${password}_*
do
scp ${tmpfile} root@${upto}.domain.com:/all/tmp/cup/ &
array_lenght=${#pwait[@]}
pwait[${array_lenght}]=$!
done
#ATTENDERE
for prid in ${pwait[@]}
do
wait $prid
done
#UNISCI FILE REMOTO
ssh root@${upto}.domain.com "cat /all/tmp/cup/${password}_* > ${remotepath} && wait && rm -f /all/tmp/cup/${password}_*"
#RIMUOVI ROBA DI TROPPO LA
#eval ssh root@${upto}.domain.com rm -f /all/tmp/cup/${password}*
#REMOVE HERE
rm -f /all/tmp/cup/${password}_*
exit 0
Предполагая, что ваша сеть не насыщенный (вопреки тому, что вы заявляете в вопросе), вам следует настроить свою ссылку, чтобы справиться с (сравнительно) высоким продукт задержки полосы пропускания как сказал Эндрю. (Статьи, указанные по этой ссылке, содержат некоторую информацию о том, что нужно настраивать, когда и почему.)
Если на самом деле ваши сетевые каналы НАСЫЩЕННЫ (перемещая максимальный объем данных, который они могут), единственным решением является увеличение пропускной способности (либо больше оптоволоконных магистралей между двумя сайтами, либо оплата другого оператора связи за транзит, чтобы разгрузить часть трафика пикового периода, или если вы используете «выделенные» ссылки, оплачивая более высокий CIR / добавляя больше цепей в цикл).
Как отличить?
Что ж, если запуск большего количества потоков дает вам больше скорости, вы еще не переполнили свою ссылку. Вы, вероятно, столкнетесь с относительно большим временем полета туда и обратно из США в Европу (по сравнению со временем туда и обратно в локальной сети).
(Здесь есть точка уменьшения отдачи, поскольку накладные расходы для большего количества TCP-соединений в конечном итоге вызовут появление других узких мест.)
Если добавление дополнительных потоков не обеспечивает чистого увеличения скорости (два потока работают с половиной чистой скорости одного), ваш канал переполнен, и вам необходимо увеличить пропускную способность для повышения производительности.
Вы должны стремиться минимизировать данные, передаваемые по каналу, используя rsync или аналогичные протоколы, если это необходимо (rsync лучше всего работает с небольшими наборами изменений для больших коллекций данных).
Никогда не недооценивайте пропускную способность ночного пакета FedEx с парой жестких дисков в нем. Специально для начальной синхронизации.
Я бы проверил параметры настройки TCP / IP, например масштабирование окна, повторную передачу, таблицу маршрутизации, а также icmp. Если все работает нормально, а сетевой стек в ОС не Windows XP, Centos 5 или что-то более раннее, чем Vista, все должно быть в порядке, поскольку многопоточное сетевое соединение не требуется. Или он не улучшился бы лучше, чем на 20%, так что фактически он просто дефрагментировал бы файловую систему и еще больше замедлил бы ее.
https://en.wikipedia.org/wiki/Bandwidth-delay_product
Продукт с высокой пропускной способностью и задержкой является важным проблемным случаем при разработке протоколов, таких как протокол управления передачей (TCP), в отношении настройки TCP, поскольку протокол может достичь оптимальной пропускной способности только в том случае, если отправитель отправляет достаточно большое количество данных до того, как они будут отправлены. требуется остановиться и дождаться получения подтверждающего сообщения от получателя, подтверждающего успешное получение этих данных. Если объем отправленных данных недостаточен по сравнению с продуктом задержки полосы пропускания, значит, канал не остается занятым, и протокол работает ниже максимальной эффективности канала.
Это основная теория, но есть и дополнительные факторы: в зависимости от вашей ОС и параметров настройки TCP у вас могут быть большие окна в игре (большие окна ускоряют работу), но, опять же, некоторые интернет-провайдеры используют "TCP Window Manipulation" как формирование и инструмент управления перегрузкой (то есть поле в середине знает, что какая-то ссылка перегружена, а затем пытается подавить источник TCP, редактируя пакеты ACK, чтобы убедить источник, что размер окна получателя мал), поэтому ваши большие окна могут не совсем быть в игре, даже если вы думаете, что они у вас включены.
Есть еще одна вещь, которая может произойти: когда очереди пакетов накапливаются в перегруженном маршрутизаторе, он может начать случайное удаление пакетов из очереди (см. Cisco Weighted Random Early Detection или WRED для краткости), но парень использует только один TCP stream имеет тенденцию отступать быстрее, чем парень, использующий кучу параллельных TCP-потоков, поэтому, используя несколько параллельных потоков, вы можете получить большую «долю» полосы пропускания в этой перегруженной очереди (за счет других, которые воздерживаются от этой техники) .
Есть забавный инструмент под названием «tcptrace», который дает вам представление о том, что происходит, при условии, что вы можете захватывать пакеты с любого конца. К сожалению, вам нужно работать с "xplot", немного ужасной программой, но с ней можно жить.