Мне нужно передать огромное количество 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).
Linux