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

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

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

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

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

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

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

Убедитесь, что --checksum не используется

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

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

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

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

Параметры ОС по умолчанию не подходят для этой ситуации.

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

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

Посмотри на "namei cache"

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

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

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 как можно лучше. Вам нужно настроить ОС, добавить ОЗУ, получить более быстрые диски, изменить файловые системы и т. Д.

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

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

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

Эй, а что не так с 5 минутами?

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

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

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

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

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

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

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

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

Используйте rsync в режиме демона на стороне сервера, чтобы ускорить процесс вывода списка / контрольной суммы:

• Демон Rsync: действительно ли это полезно?
• http://giantdorks.org/alain/achieve-faster-file-transfer-times-by-running-rsync-as-a-daemon/

Обратите внимание, что он не зашифрован, но его можно туннелировать без потери улучшения производительности листинга.

Кроме того, использование rsync для сжатия, а не ssh, должно улучшить производительность.