Некоторые несвязанные моменты:
80K - это много файлов.
80000 файлов в одном каталоге? Ни одна операционная система или приложение по умолчанию не справляются с этой ситуацией. Вы просто заметили эту проблему с rsync.
Проверьте версию rsync
Современный rsync обрабатывает большие каталоги намного лучше, чем в прошлом. Убедитесь, что вы используете последнюю версию.
Даже старый rsync довольно хорошо обрабатывает большие каталоги по ссылкам с высокой задержкой ... но файлы размером 80 КБ не велики ... они огромны!
Тем не менее, использование памяти rsync прямо пропорционально количеству файлов в дереве. Большие каталоги занимают большое количество оперативной памяти. Замедление может быть связано с нехваткой оперативной памяти с обеих сторон. Сделайте тестовый прогон, наблюдая за использованием памяти. Linux использует любую оставшуюся оперативную память в качестве дискового кэша, поэтому, если у вас мало оперативной памяти, кеширование диска уменьшается. Если у вас заканчивается ОЗУ и система начинает использовать своп, производительность будет очень плохой.
Убедитесь, что --checksum не используется
--checksum(или -c) требует чтения каждого блока каждого файла. Вы, вероятно, можете обойтись с поведением по умолчанию, просто читая времена модификации (хранящиеся в inode).
Разделите работу на небольшие партии.
Есть некоторые проекты, такие как Gigasync, которые « уменьшают рабочую нагрузку, используя perl для рекурсии дерева каталогов, создавая небольшие списки файлов для передачи с помощью rsync».
Дополнительное сканирование каталогов будет сопряжено с большими накладными расходами, но, возможно, это будет чистый выигрыш.
По умолчанию ОС не созданы для этой ситуации.
Если вы используете Linux / FreeBSD / etc со всеми настройками по умолчанию, производительность будет ужасной для всех ваших приложений. Значения по умолчанию предполагают меньшие каталоги, чтобы не тратить ОЗУ на кэши большого размера.
Настройте свою файловую систему так, чтобы она лучше справлялась с большими каталогами: замедляют ли папки большого размера производительность ввода-вывода?
Посмотрите на "кэш имен"
Подобные BSD операционные системы имеют кэш, который ускоряет поиск имени в inode (кэш "namei"). Для каждого каталога есть кэш namei. Если он слишком мал, он является помехой, а не оптимизацией. Поскольку rsync выполняет lstat () для каждого файла, для каждого из файлов размером 80 тыс. Осуществляется доступ к inode. Это может привести к перегрузке вашего кэша. Узнайте, как настроить производительность файловых каталогов в вашей системе.
Рассмотрим другую файловую систему
XFS была разработана для обработки больших каталогов. Смотрите Файловая система большое количество файлов в одном каталоге
Возможно, 5 минут - лучшее, что вы можете сделать.
Подумайте о том, как рассчитать, сколько дисковых блоков читается, и подсчитайте, как быстро вы должны ожидать, что аппаратное обеспечение сможет читать такое количество блоков.
Может быть, ваши ожидания слишком высоки. Подумайте, сколько дисковых блоков нужно прочитать, чтобы выполнить rsync без измененных файлов: каждому серверу нужно будет прочитать каталог и прочитать по одному индексу на файл. Давайте предположим, что ничего не кешируется, потому что, ну, 80к файлов, вероятно, испортили ваш кеш. Скажем, это 80k блоков для простоты математики. Это около 40 миллионов данных, которые должны быть прочитаны в течение нескольких секунд. Однако, если между каждым блоком требуется поиск диска, это может занять гораздо больше времени.
Итак, вам нужно прочитать около 80000 дисковых блоков. Как быстро ваш жесткий диск может это сделать? Учитывая, что это случайный ввод-вывод, а не длинное линейное чтение, 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 (обратите внимание на повторение). Это разбивает каталоги на более мелкие, но не требует огромных изменений в коде.
Также .... рассмотрите возможность использования базы данных. Если у вас есть 80 тыс. Файлов в каталоге, возможно, ваши разработчики работают над тем, что им действительно нужна база данных. MariaDB или MySQL или PostgreSQL были бы намного лучшим вариантом для хранения больших объемов данных.
Эй, что не так с 5 минут?
Наконец, 5 минут действительно так плохо? Если вы запускаете эту резервную копию один раз в день, 5 минут - это не много времени. Да, я люблю скорость. Однако, если 5 минут «достаточно хорошо» для ваших клиентов, то это достаточно хорошо для вас. Если у вас нет подписанного SLA, как насчет неофициальной дискуссии с вашими пользователями, чтобы узнать, насколько быстро они ожидают создания резервных копий.
Я предполагаю, что вы не задавали этот вопрос, если не было необходимости улучшать производительность. Однако, если ваши клиенты довольны 5 минутами, объявите победу и переходите к другим проектам, которые требуют ваших усилий.
Обновление: после некоторого обсуждения мы определили, что узким местом является сеть. Я собираюсь рекомендовать 2 вещи, прежде чем я сдаюсь :-).
- Попробуйте выжать из канала больше пропускной способности при сжатии. Однако сжатие требует больше ресурсов процессора, поэтому, если ваш процессор перегружен, производительность может ухудшиться. Попробуйте rsync с и без
-z, и настройте ваш ssh с и без сжатия. Время все 4 комбинации, чтобы увидеть, если какие-либо из них работают значительно лучше, чем другие.
- Наблюдайте за сетевым трафиком, чтобы увидеть, есть ли какие-либо паузы. Если есть паузы, вы можете найти, что их вызывает, и оптимизировать их там. Если rsync всегда отправляет, то вы действительно находитесь на своем пределе. Ваш выбор:
- более быстрая сеть
- что-то кроме rsync
- переместите источник и пункт назначения ближе друг к другу. Если вы не можете этого сделать, можете ли вы rsync на локальный компьютер, а затем rsync к реальному месту назначения? Это может быть полезно, если во время начальной rsync система не работает.