Вернуться




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




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

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

 

Ответ 1

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

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

 

Вот команда, которую вы будете использовать для rsync:

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

 

Ответ 2

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

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

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

 В этих документах говорится о туннелировании rsync через SSH, но, если вы просто перемещаете данные по частной локальной сети, вам не нужен SSH (я предполагаю, что вы находитесь в частной локальной сети).

 

Ответ 3

При перемещении 80 Тб данных (миллионы крошечных файлов), переход от rsync к tar оказался намного быстрее.

# медленный способ

rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

 

и переключившись на tar...

# быстрый способ

cd /mnt/backups/

tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

 

Поскольку эти серверы находятся в одной локальной сети, место назначения смонтировано по NFS на исходной системе, которая выполняет push. Чтобы сделать это еще быстрее, мы решили не сохранять время хранения файлов:

mount -o remount,noatime /mnt/backups

mount -o remount,noatime /mnt/destination01

 

Ответ 4

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

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

$ time fast-archiver -c -o /dev/null /db/data

пропуск символической ссылки /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: Удаление ведущих '/' из имен пользователей

tar: /db/data/base/16408/12445.2: файл изменился при чтении

tar: /db/data/base/16408/12464: файл изменен по мере чтения

32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k

0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Для передачи файлов между серверами вы можете использовать fast-archiver с помощью ssh, как показано ниже:

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

 

Ответ 5

Есть несколько возможных решений:

  • Сетевая файловая система (NFS), и затем скопируйте их чем угодно, например, Midnight Commander (mc), Nautilus (от gnome). Я использовал NFS v3 с хорошими результатами.

  • Samba (CIFS), и затем скопируйте файлы с чем угодно, но неизвестно, насколько это эффективно.

  • HTTP с , wget --mirror или любой другой клиент HTTP. Будьте осторожны, чтобы не иметь неприятных символических ссылок или вводящих в заблуждение индексных файлов. Если все, что у вас есть, это MP3, тогда все должно нормально сработать.

  • rsync. Я использовал его с довольно хорошими результатами, и одна из его приятных особенностей то, что вы можете прервать и возобновить передачу позже.

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

 

Ответ 6

Я могу предложить следующее улучшение (если bash ваша оболочка). Это добавит параллельное сжатие, индикатор выполнения и проверку целостности по сетевому каналу:

tar c file_list |

    tee >(sha512sum >&2) |

    pv -prab |

    pigz -9 |

    ssh [user@]remote_host '

        gunzip |

        tee >(sha512sum >&2) |

        tar xC /directory/to/extract/to

    '

 

pv это хорошая программа просмотра прогресса для вашего соединения, а pigz параллельная программа gzip, которая использует столько потоков, сколько есть у вашего процессора по умолчанию (я думаю, до 8 максимум). Вы можете настроить уровень сжатия, чтобы лучше соответствовать соотношению процессора и пропускной способности сети, и поменять его местами с pxz -9e и pxz -d, если у вас намного больше процессоров, чем пропускной способности. Вам нужно только проверить, что две контрольные суммы совпадают после завершения.

Эта опция полезна для очень больших объемов данных, а также для сетей с высокой задержкой, но не очень полезна, если связь нестабильна и падает. В таких случаях лучшим выбором будет rsync, поскольку он может возобновить работу.

Пример вывода:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e - ]

 176MiB [9.36MiB/s] [9.36MiB/s] [ <=> ]

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e -

 

Для блочных устройств:

dd if=/dev/src_device bs=1024k |

    tee >(sha512sum >&2) |

    pv -prab |

    pigz -9 |

    ssh [user@]remote_host '

        gunzip |

        tee >(sha512sum >&2) |

        dd of=/dev/src_device bs=1024k

    '

 

Также убедитесь, что они одинакового размера, или ограничьте их с помощью count=, skip=, seek= и т. д.

Когда я копирую файловые системы таким образом, я часто сначала делаю:

dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs

 чтобы обнулить большую часть неиспользуемого пространства, что ускоряет перенос.

 

Ответ 7

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

Я бы использовал следующее на принимающей машине:

cd <destdir>

netcat -l -p <port> | gunzip | cpio -i -d -m

 

Затем на передающей стороне:

cd <srcdir>

find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>.

 

Это имеет следующие преимущества:

Отсутствие нагрузки на процессор при шифровании, которое есть в ssh.

gzip -1 обеспечивает легкое сжатие без загрузки процессора, так что это хороший компромисс, дающий небольшое сжатие при сохранении максимальной пропускной способности (возможно, это не так выгодно для данных MP3). Если вы можете разделить файлы на группы, вы можете запустить два или более каналов параллельно и действительно обеспечить насыщение пропускной способности сети.

Например,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>

find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

 

Примечания:

Независимо от способа передачи, я бы, вероятно, запустил rsync или unison после этого, чтобы убедиться, что передача прошла успешно.

Вы можете использовать tar вместо cpio, если хотите.

Даже если вы используете ssh, я бы убедился, что он сам не использует сжатие, и вместо этого передавал бы через gzip -1 самостоятельно, чтобы избежать перегрузки процессора (или, по крайней мере, установите CompressionLevel, равным 1).



Если вам понравилась эта статья поделитесь ею с друзьями, тем самым вы помогаете нам развиваться и добавлять всё больше интересного и полезного контента!




Cхожие статьи





Команды Linux. Шпаргалка

Команды Linux. Шпаргалка

Я часто забываю команды терминала и обычно сохраняю их себе на компьютер в ...

21 Февраля 2021    Linux


Переход с Windows на Linux

Переход с Windows на Linux

После того как Microsoft перестали поддерживать Windows 7, а после и вовсе ...

21 Февраля 2021    Linux


REOS. Игровой Linux

REOS. Игровой Linux

Еще несколько лет назад Linux считался не более, чем операционной системой ...

21 Февраля 2021    Linux




Напишем