Вопрос: Более быстрый rsync огромного каталога, который не был изменен


Мы используем rsync для резервного копирования серверов.

К сожалению, сеть для некоторых серверов медленная.

Rsync занимает до пяти минут, чтобы обнаружить, что в огромных каталогах ничего не изменилось. Эти огромные деревья каталогов содержат множество небольших файлов (около 80 тыс. Файлов).

Я полагаю, что клиенты rsync отправляют данные для каждого из файлов 80k.

Поскольку сеть работает медленно, я бы хотел избежать отправки 80 тыс. Информации о каждом файле.

Есть ли способ сказать rsync сделать хэш-сумму дерева подкаталогов?

Таким образом, клиент rsync отправил бы только несколько байтов для огромного дерева каталогов.

Обновить

До сих пор моя стратегия - использовать rsync, Но если различные инструменты подходят здесь лучше, я могу переключиться. Оба (сервер и клиент) находятся под моим контролем.

Update2

В одном каталоге есть 80k файлов дерево, В каждом отдельном каталоге не более двух файлов или подкаталогов

Update3

Подробная информация о медлительности сети:

time ssh einswp 'cd attachments/200 && ls -lLR' >/tmp/list
real    0m2.645s

Размер файла tmp / list: 2MByte

time scp einswp:/tmp/list tmp/
real    0m2.821s

Вывод: scp имеет одинаковую скорость (не удивительно)

time scp einswp:tmp/100MB tmp/
real    1m24.049s

Скорость: 1,2 МБ / с


7
2018-01-04 08:53


Источник


Вы можете прочитать zsync. Я не использовал его сам, но из того, что я читал, он предварительно отображает метаданные на стороне сервера и может просто ускорить передачу в вашем случае. В любом случае, стоит попробовать. Помимо этого, единственное другое решение, о котором я знаю, - это синхронизация на блочном уровне в реальном времени, которая поставляется с некоторыми решениями san / nas. - Aaron


Ответы:


Некоторые несвязанные моменты:

80K - это много файлов.

80 000 файлов в одном каталоге? Никакая операционная система или приложение не обрабатывают эту ситуацию очень хорошо по умолчанию. Вы просто заметили эту проблему с помощью rsync.

Проверьте версию rsync

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

Даже старый rsync обрабатывает большие каталоги довольно хорошо по ссылкам с высокой задержкой ... но файлы 80k невелики ... он огромен!

Тем не менее, использование памяти rsync прямо пропорционально количеству файлов в дереве. Большие каталоги занимают большое количество оперативной памяти. Медленность может быть связана с отсутствием ОЗУ с обеих сторон. Проведите тестовый прогон, наблюдая за использованием памяти. Linux использует любое оставшееся ОЗУ в качестве дискового кеша, поэтому, если у вас мало оперативной памяти, меньше кэширования диска. Если у вас заканчивается RAM, и система начинает использовать swap, производительность будет очень плохой.

Удостоверьтесь, что -checkum не используется

--checksum (или -C) требует чтения каждого блока каждого файла. Вы, вероятно, можете справиться с поведением по умолчанию, просто прочитав время модификации (сохраненное в inode).

Разделите работу на небольшие партии.

Есть несколько проектов, таких как Gigasync который «раскроет рабочую нагрузку, используя perl для рекурсии дерева каталогов, создавая небольшие списки файлов для передачи с помощью rsync».

Дополнительное сканирование каталога будет большим объемом накладных расходов, но, возможно, это будет чистая победа.

Для этой ситуации не установлены значения по умолчанию ОС.

Если вы используете Linux / FreeBSD / etc со всеми значениями по умолчанию, производительность будет ужасной для всех ваших приложений. По умолчанию предполагаются меньшие каталоги, поэтому, чтобы не тратить ОЗУ на негабаритные кеши.

Настройте свою файловую систему, чтобы лучше обрабатывать большие каталоги: Большие размеры папок замедляют производительность ввода-вывода?

Посмотрите на «кеш-имя»,

В BSD-подобных операционных системах есть кеш, который ускоряет поиск имени в inode («кеш-имя»). Для каждого каталога есть кеш-имя. Если он слишком мал, это помеха больше, чем оптимизация. Поскольку rsync выполняет lstat () для каждого файла, к нему поступает доступ к каждому из 80k-файлов, что может привести к выходу вашего кеша. Изучите, как настроить производительность файловой директории в вашей системе.

Рассмотрим другую файловую систему

XFS был разработан для обработки больших каталогов. Видеть Файловая система большого количества файлов в одном каталоге

Может быть, 5 минут - это лучшее, что вы можете сделать.

Рассмотрите возможность вычисления количества блоков диска и подсчитайте, как быстро вы должны ожидать, что аппаратное обеспечение сможет читать многие блоки.

Возможно, ваши ожидания слишком высоки. Посмотрите, сколько блоков диска должно быть прочитано для выполнения rsync без измененных файлов: каждый сервер должен будет прочитать каталог и прочитать один индексный дескриптор для каждого файла. Предположим, что ничего не кэшировано, потому что, возможно, файлы 80k, вероятно, взорвали ваш кеш. Предположим, что это 80k блоков, чтобы сохранить математику простой. Это около 40 миллионов данных, которые должны быть прочитаны за несколько секунд. Однако, если между каждым блоком требуется поиск диска, это может занять гораздо больше времени.

Таким образом, вам нужно будет прочитать около 80 000 блоков диска. Как быстро ваш жесткий диск может это сделать? Учитывая, что это случайный ввод-вывод, а не длинное линейное чтение, 5 минут могут быть довольно хорошими. Это 1 / (80000/600), или диск читается каждые 7,5 мс. Это быстро или медленно для вашего жесткого диска? Это зависит от модели.

Тест против чего-то подобного

Другой способ подумать об этом. Если файлы не изменились, ls -Llr делает то же количество активности диска, но никогда не читает никаких файлов (только метаданных). Время ls -Llr для запуска - ваша верхняя граница.

  • Является ли rsync (без изменений файлов) значительно медленнее, чем ls -Llr? Затем параметры, которые вы используете для rsync, можно улучшить. Может быть -C или какой-либо другой флаг, который читает больше, чем просто каталоги и метаданные (данные inode).

  • Является ли rsync (без файлов изменено) почти так же быстро, как ls -Llr? Затем вы настроили rsync как можно лучше. Вы должны настроить ОС, добавить ОЗУ, получить более быстрые диски, изменить файловые системы и т. Д.

Поговорите со своими разработчиками

Файлы 80k - это просто плохая конструкция. Очень немногие файловые системы и системные инструменты прекрасно справляются с такими большими каталогами. Если имена файлов - abcdefg.txt, рассмотрите их сохранение в файле abdc / abcdefg.txt (обратите внимание на повторение). Это разбивает каталоги на более мелкие, но не требует огромного изменения кода.

Также ... рассмотрите возможность использования базы данных. Если у вас есть файлы 80k в каталоге, возможно, ваши разработчики работают над тем, что то, что они действительно хотят, это база данных. MariaDB или MySQL или PostgreSQL были бы гораздо лучшим вариантом для хранения больших объемов данных.

Эй, что случилось с 5 минутами?

И, наконец, 5 минут действительно так плохо? Если вы запускаете эту резервную копию один раз в день, 5 минут - это не так много времени. Да, я люблю скорость. Однако, если 5 минут «достаточно хороши» для ваших клиентов, то это достаточно хорошо для вас. Если у вас нет письменного соглашения об уровне обслуживания, как насчет неофициальной дискуссии с вашими пользователями, чтобы узнать, как быстро они ожидают, что резервные копии будут приняты.

Я полагаю, вы не задавали этот вопрос, если не было необходимости улучшать производительность. Однако, если ваши клиенты довольны 5 минутами, объявите победу и перейдем к другим проектам, требующим ваших усилий.

Обновить: После некоторого обсуждения мы определили, что узким местом является сеть. Я собираюсь порекомендовать 2 вещи, прежде чем сдаться :-).

  • Попытайтесь выжать больше полосы пропускания из трубы с сжатием. Однако для сжатия требуется больше CPU, поэтому, если ваш процессор перегружен, это может ухудшить производительность. Попробуйте rsync с и без -z, и сконфигурируйте свой ssh ​​с сжатием и без него. Время все 4 комбинации, чтобы увидеть, если кто-либо из них выполняет значительно лучше, чем другие.
  • Просмотрите сетевой трафик, чтобы увидеть, есть ли паузы. Если есть паузы, вы можете найти, что их вызывает и оптимизировать. Если rsync всегда отправляет, то вы действительно находитесь на своем пределе. Ваш выбор:
    • более быстрая сеть
    • нечто иное, чем rsync
    • перемещайте источник и место назначения ближе друг к другу. Если вы не можете этого сделать, можете ли вы rsync на локальном компьютере, а затем rsync в реальном пункте назначения? Это может быть полезно для этого, если система должна быть отключена во время первоначального rsync.

19
2018-01-05 14:50



80K - это много файлов: есть 80k файлов в одном каталоге дерево, В каждом отдельном каталоге не более 2k файлов / подкаталогов. - guettli
Проверьте версию rsync: done, Убедитесь, что -checksum не используется: сделано. Разделите работу на небольшие партии: Спасибо, я посмотрю на gigasync. OS по умолчанию не сделаны для этой ситуации: сделано (узким местом является сеть, а не ОС). Посмотрите на «кеш-имя»: сделано (это нетто, а не OS). Рассмотрим другую файловую систему: снова сеть, а не ОС. Может быть, 5 минут - это лучшее, что вы можете сделать: я думаю, это может быть намного быстрее. Поговорите с вашими разработчиками (используйте DB): Это будет гигантское изменение. Возможно, файловая система с лучшей поддержкой резервного копирования решит ее. - guettli
2k файлов в каталоге намного лучше. Спасибо за обновление. Вы не упоминали, что сеть была медленной. Это низкая пропускная способность, высокая латентность или и то, и другое? rsync обычно хорошо работает на каналах с высокой задержкой (он был разработан кем-то, работающим над его кандидатом наук в Австралии, имея дело с компьютерами в США). Попробуйте сделать это «ls -lLR» через ssh и время, необходимое для передачи результата. "time ssh remotehost 'cd / dest && ls -lLR'> / tmp / list". Убедитесь, что / tmp / list создан на локальном хосте. - TomOnTime
да, сеть медленная. Жаль. - guettli
Как медленно? Если вы используете «scp» для копирования файла 100M, как долго это займет? Кроме того, каков вывод «time ssh remotehost» cd / dest && ls -lLR '> / tmp / list "? - TomOnTime


Нет, это невозможно с rsync, и это было бы совсем неэффективно в другом отношении:

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


3
2018-01-04 10:49



AFAIK rsync проверяет время и размер. Если оба совпадения, файл не передается снова (по крайней мере, в настройках по умолчанию). Достаточно отправить хэш кортежей (имя файла, размер, время). Нет необходимости проверять содержимое. - guettli
Да, вы правы, но во всяком случае, rsync не делает этого. - Sven♦


Для синхронизации большого количества файлов (где мало что изменилось), также стоит установить noatime на исходном и целевом разделах. Это экономит время записи на диск для каждого неизмененного файла.


1
2017-08-26 11:08



Да, опция noatime имеет смысл. Мы используем его с нескольких лет. Я предполагаю, что нужна альтернатива rsync. - guettli