☰

Передача Rsync через SSH очень медленная

tag-icon • tag-icon backup rsync
Передача Rsync через SSH очень медленная

Я делаю удаленное резервное копирование моего сайта. Весь каталог занимает около 70 ГБ с общим количеством файлов около 5 000 000. Вот команда, которую я запускаю на своем сервере резервного копирования:

rsync -ah -e ssh --delete --link-dest=/backups/2013.09.06 [email protected]:/var/www/backups/2013.09.07

Процесс выполняется более 48 часов и просто зависает.

Я запустил strace -pпроцесс rsync на клиенте (веб-сервере, на котором расположен сайт) и увидел, что процесс периодически останавливается на selectкоманде, заканчивающейся = 0 (Timeout)через некоторое время, а затем продолжается.

open("mysite/files/1694201", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=10083, ...}) = 0
read(3, "\r\n\320\224\320\265\321\201\321\217\321\202\321\214 \320\273\320\265\321\202, \321\210\320\265\321\201\321\202\321"..., 10083) = 10083
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999998})
write(1, "\374\17\0\7", 4)              = 4
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999999})
write(1, "\320\260\320\262\320\260\320\271\321\202\320\265...\320\232\320\270\320\264\320\260\320\271\321\202\320\265 \320\274"..., 4092) = 4092
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999999})
write(1, "\374\17\0\7", 4)              = 4
select(2, NULL, [1], [1], {60, 0})      = 0 (Timeout)

Процесс зависает на последней строке примерно на минуту.

Почему это может происходить? Почему процесс длится так долго и никогда не доходит до конца? Что могут 0 (Timeout)означать те, что в strace?

На обоих серверах запущен rsync 3.0.9, ввод-вывод не перегружен.

решение1

Что могут означать эти 0 (Timeout) в strace?

Почитайте о 5-м параметрепередано для выбора.

Очевидно, rsync (сам по себе) не подходит для выбранного вами метода резервного копирования файлов. Он должен генерировать хэш для каждого из 5 миллионов файлов и отправлять его по сети, чтобы просто узнать, изменилось ли что-нибудь.

Если бы это был я, я бы оформил это в скрипт, работающий на исходном сервере, который

  1. Проверяет время (tstart) начала предыдущей успешной синхронизации.

  2. Находит все файлы на источнике, у которых mtime > tstart

  3. rsync эти файлы изменены на резервном сервере

например

#!/bin/bash

touch newrun
find /var/www -newer lastrun -exec rsync ....
rm -f lastrun
mv newrun lastrun

решение2

Вы уверены, что у вас 5 миллиардов файлов?

Я бы предпочел tgz и rsync, а не tgz, поскольку первоначальное сравнение src с dst займет целую вечность, если у вас несколько «обычных» жестких дисков, а не высокоскоростной SAN или SSD.

где ваш процесс идет медленно? во время передачи файлов или во время начальной проверки src<->dst? (отправка инкрементного списка файлов ...)

Я бы проверил IOWAIT на обоих концах, если это возможно. и, если на машинах есть md-raid, cat /proc/mdstatus. Очень плохая производительность ввода-вывода может быть результатом перестройки raid (но это очень маловероятно).

и я бы переслал один большой файл с --progressвключенным rsync-переносом, чтобы проверить скорость сети.

подсказки по отладке(Вам следует проверить каждое возможное узкое место, хотя бы для того, чтобы убедиться: проблема НЕ в этом)

  • попробуйте rsync с -avzh --progress --stats
  • io-производительность локально
  • производительность сети
  • hd/raid-status (SMART), проверка на наличие неисправного оборудования

Связанный контент