Вопрос: Как быстро скопировать большое количество файлов между двумя серверами


Мне нужно передать огромное количество mp3-файлов между двумя сервисами (Ubuntu). Огромным я имею в виду около миллиона файлов, которые в среднем составляют 300K. Я попытался с scp но это заняло бы неделю. (около 500 КБ / с) Если я передаю один файл по HTTP, я получаю 9-10 МБ / с, но я не знаю, как перенести все из них.

Есть ли способ быстро их перевести?


81
2018-06-02 19:55


Источник


Какая у вас сеть между серверами. Я использовал кросс-сервер GB Ethernet между 1 сетевым адаптером в каждой машине. Я очень хорошо прошел через эту конфигурацию, используя SCP - Jim Blizard
Возможно, вам захочется выяснить, почему scp настолько медленный. Это может быть медленнее, чем такие вещи, как ftp из-за шифрования, но это не должно быть намного медленнее. - Zoredache
У меня есть 100 Мбит / с между ними. scp медленнее на небольших файлах (большинство из них небольшие) - nicudotro


Ответы:


Я бы порекомендовал tar. Когда деревья файлов уже схожи, выполняется rsync очень Что ж. Однако, поскольку rsync будет выполнять несколько аналитических проходов по каждому файлу, а затем скопировать изменения, он намного медленнее, чем tar для начальной копии. Эта команда, скорее всего, сделает то, что вы хотите. Он скопирует файлы между машинами, а также сохранит как разрешения, так и пользовательские / групповые владельцы.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Согласно комментарию Mackintosh ниже, это команда, которую вы используете для rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

108
2018-06-02 20:04



+1 Вариант tar более эффективен для большого количества небольших файлов, так как scp и rsync будут иметь много больше маршрутов для каждого файла по сети. - Sekenre
rsync работал лучше для меня, чем tar - nicudotro
Кроме того, если у вас много доступных CPU (с обоих концов), но (по крайней мере) медленная связь между хостами, возможно, стоит включить сжатие (gzip или bzip) в команде tar. - Vatine
@Jamie: Если вы используете ssh-agent, тогда он должен использоваться. В противном случае просто используйте параметр -i, чтобы указать, где найти закрытый ключ. См. Справочную страницу. - Scott Pack
@niXar ~ escape-символ активируется только в том случае, если SSH использует терминал. Это не тот случай, когда вы указываете удаленную команду (если вы не передаете -t опция). Поэтому ваша обеспокоенность недействительна. - Gilles


Внешний жесткий диск и доставка курьером в тот же день.


32
2018-06-02 20:00



Хе-хе ... нет сетевых технологий превосходит пропускную способность универсала, загруженного лентами, делающими 90 миль в час, а? (snicker) Я предположил, что он был в ЛВС, потому что он сказал, что получает HTTP-сообщение от 9-10 МБ / сек. - Evan Anderson
Я получаю такую ​​скорость через Интернет, но мне просто повезло, где я живу! Если это в локальной сети, то еще дешевле! - Adam
Ах, ты не смотрел на свое место. Да ... Я слышал, что подключение к Интернету в Корее довольно впечатляющее. Застрял здесь, в США, я рад получить 900 КБ / сек над «сетью» ... - Evan Anderson
Да, но вы можете получить вкусные burritos, пока вы ждете завершения загрузки, и есть только около трех полуподобных мексиканских ресторанов даже в Сеуле ... - Adam


Я бы использовал rsync.

Если вы экспортировали их через HTTP с доступными каталогами, вы можете использовать аргумент wget и -mirror.

Вы уже видите, что HTTP быстрее, чем SCP, потому что SCP шифрует все (и, таким образом, является узким местом на процессоре). HTTP и rsync будут двигаться быстрее, потому что они не шифруются.

Вот несколько документов по настройке rsync на Ubuntu: https://help.ubuntu.com/community/rsync

Эти документы говорят о туннелировании rsync через SSH, но если вы просто перемещаете данные в частной локальной сети, вам не нужен SSH. (Я предполагаю, что вы находитесь в частной локальной сети. Если вы получаете 9-10 МБ / сек через Интернет, я хочу знать, какие у вас есть соединения!)

Вот некоторые другие очень простые документы, которые позволят вам установить относительный небезопасный rsync-сервер (без зависимости от SSH): http://transamrit.net/docs/rsync/


16
2018-06-02 19:57



Хотя SCP действительно использует некоторый процессор для шифрования данных, я не думаю, что у него 100% -ное использование ЦП, поэтому процессор не является узким местом. Я заметил слишком много раз, что SCP неэффективен, когда дело доходит до быстрых передач. - Cristian Ciupitu
Учитывая, что он видел 300K для SCP и 9MB для HTTP, я предположил, что узкое место в SCP (обычно CPU) вступает в игру. Конечно, это может быть что-то еще. Без знания аппаратных характеристик рассматриваемых машин трудно сказать. - Evan Anderson
rsync почти наверняка будет использовать ssh для транспорта, поскольку это поведение по умолчанию, поэтому любые служебные данные, вызванные шифрованием в scp, также будут присутствовать в rsync - Daniel Lawson
«Вы уже видите, что HTTP быстрее, чем SCP, потому что SCP шифрует все» → WRONG. Если у него нет 10-летних серверов, он не связан с ЦП этой задачей. - niXar
@RamazanPOLAT. У вас слишком длинная командная строка. Укажите выбор файла по-разному, и он будет отлично работать для вас. Как правило, вы можете просто указать исходный каталог без подстановочного знака в конце. Вы также можете использовать --include а также --exclude аргументы, чтобы получить больше нюансов. - Evan Anderson


Без особого обсуждения, используйте netcat, сетевой швейцарский нож. Нет накладных расходов протокола, вы напрямую копируете сетевой сокет. пример

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

14
2018-06-02 20:17



К сожалению, из того, что я заметил, netcat очень неэффективен, даже если этого не должно быть. - Cristian Ciupitu
Я ниспровергаю вас, потому что это действительно ужасный совет. Существует один правильный ответ: rsync. Я мог бы перечислить все причины, по которым это лучше, но на этой странице это не поместилось, не говоря уже об этом маленьком поле комментариев. - niXar
@niXar: Если все, что вы хотите сделать, это передача одного файла (нет необходимости в дальнейшей синхронизации), тогда tarpipe - это все, что вам нужно. - Witiko
@niXar netcat - это прекрасно, если вы делаете это в защищенной среде, например, в частном vlan и / или через VPN. - Lester Cheung


С большим количеством файлов, если вы идете с rsync, Я бы постарался получить версию 3 или выше на обоих концах, Причина в том, что меньшая версия будет перечислять каждый файл, прежде чем он начнет передачу. Новая функция называется инкрементный рекурсии,

Новый алгоритм инкрементной рекурсии   теперь используется, когда rsync говорит         к другой версии 3.x. Это ускоряет переход         (до того, как все файлы были найдены), и требует гораздо меньше памяти.         См. Параметр -recursive в man-странице для некоторых ограничений.


8
2018-06-02 20:41





rsync, как и другие, уже рекомендовали. Если накладные расходы ЦП от шифрования являются узким местом, используйте другой алгоритм с меньшим потреблением процессора, например, blowfish. Например. что-то вроде

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path


5
2018-06-02 20:56



+1 для указания на изменение шифрования - Daniel Lawson
CPU не будет узким местом, если у вас нет 10G ethernet и 10-летнего процессора. - niXar
просто комментарий: шифр «-c arcfour» работает быстрее. - Arman
@niXar: Но если у вас уже есть задача для процессора на вашем компьютере, это вызывает беспокойство. - Isaac


При копировании большого количества файлов я обнаружил, что такие инструменты, как tar и rsync, более неэффективны, чем они должны быть из-за накладных расходов на открытие и закрытие многих файлов. Я написал инструмент с открытым исходным кодом, называемый fast-archiver, который быстрее, чем tar для этих сценариев: https://github.com/replicon/fast-archiver; он работает быстрее, выполняя несколько одновременных операций с файлами.

Вот пример быстрого архивирования против tar на резервную копию более двух миллионов файлов; быстрый архиватор занимает 27 минут, чтобы архивировать, против tar принимает 1 час 23 минуты.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Для передачи файлов между серверами вы можете использовать быстрый архиватор с ssh, например:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

3
2017-08-26 20:51





Я использую смолу netcat подход, за исключением того, что я предпочитаю использовать socat - намного больше возможностей для оптимизации вашей ситуации - например, путем настройки mss. (Кроме того, смеяться, если хотите, но я нахожу socat аргументы легче запомнить, потому что они согласованы). Поэтому для меня это очень распространено в последнее время, поскольку я перемещаю вещи на новые серверы:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Псевдонимы необязательны.


3
2018-06-03 06:38