У меня в настройке балансировщика нагрузки задействовано 2 сервера. эти 2 сервера зеркалируют друг друга. основное использование blanacer - обслуживание статических файлов. Назовем их Сервер A и Сервер B.
Сервер A получит файл с удаленного хоста в другой сети. эти извлекаемые удаленные файлы являются медиафайлами для веб-сайта сообщества, поэтому rsync необходимо запускать каждые 30 минут, чтобы файлы оставались синхронизированными. Другой мудрый пользователь увидит битые изображения и т. Д. Сервер A также обслуживает файлы через http, пиковое время 400 МБ / с.
Сервер B выполняет rsync с файлами на сервере A, для обеспечения согласованности rsync также запускается каждые 30 минут. Сервер B также обслуживает файлы через http, пиковое время 400 МБ / с.
Нагрузка на A и B была очень высокой: средняя нагрузка: 8,00, 8,10, 7,68 и более.
Как я могу улучшить свою настройку, чтобы снизить нагрузку на сервер и повысить эффективность rsync?
Спасибо
Это зависит от того, что вызывает такую высокую загрузку процессора. Если высокая загрузка процессора вызвана Rsync, генерирующим контрольные суммы файлов, вы можете кое-что сделать.
Контрольные суммы могут вам и не понадобиться. По умолчанию rsync решает, что файл отличается в зависимости от времени модификации и размера файла. Если вы добавите "-c", он определит, что файл отличается, сравнивая контрольные суммы. Опустите этот параметр, если вам не нужны контрольные суммы.
Если вам действительно нужны контрольные суммы, в некоторых случаях может сработать кеширование контрольной суммы. Если файлы, которые вы синхронизируете, не меняются часто, вы можете генерировать контрольные суммы один раз в день в задании cron, и rsync будет использовать сгенерированные контрольные суммы. Rsync по-прежнему будет генерировать контрольные суммы для любых новых файлов или для любых файлов, которые имеют другое время модификации или размер, чем при создании контрольной суммы.
Эта информация основана на rsync 3.0.5, но должна работать так же в 3.0.6. Вам нужно будет перекомпилировать rsync; кеширование контрольной суммы - это патч. Вот что я использовал для компиляции rsync:
rsync_version="3.0.5"
scriptroot="Set this to your working directory."
mkdir -p $scriptroot/rsync-source/rsync-working
cd $scriptroot/rsync-source/rsync-working
tar xvzf ../rsync-${rsync_version}.tar.gz
tar xvzf ../rsync-patches-${rsync_version}.tar.gz
cd $scriptroot/rsync-source/rsync-working/rsync-${rsync_version}
patch -p1 < patches/checksum-reading.diff
./configure
make
Затем используйте rsyncsums для генерации контрольных сумм. При вызове rsync используйте "--sumfiles=lax"вариант.
Многие сайты предлагают -avzuh для архивирования. После некоторого тестирования я обнаружил, что это была -z (сжатие), из-за которой у меня это длилось вечно (создание резервной копии с моего портативного жесткого диска объемом 500 г с работы на дом), даже если не было внесено никаких изменений.
С -z это заняло около 1 часа (без изменений), а без - около 30 секунд.
Вы не указываете версию, которую используете. Если вы используете RHEL / Centos, скорее всего, вы застряли на версии 2.x. Проблема с 2.x заключается в том, что он сканирует все каталоги и отправляет список файлов ПЕРЕД любой передачей. Это плохо, потому что, если дерево достаточно велико, оно может быть вытолкнуто из кеша при фактическом запуске передачи, что приводит к удвоению активности диска. Кроме того, если соединение нестабильно, вы никогда ничего не передадите, потому что соединение преждевременно разорвется.
Однако, начиная с версии 3.0, структура каталогов проверяется по мере продвижения. Для обновления до 3.x на RHEL / Centos я только что загрузил SRPM Fedora (версия 10 и ниже, потому что формат изменился и немного несовместим с RHEL) из http://koji.feodraproject.org, и выпустил:
rpmbuild --rebuild rsync.xxxx.src.rpm
Вам необходимо установить новый пакет на обе машины.
И для балансировки нагрузки, и для аварийного переключения / аварийного восстановления я начинаю экспериментировать с DRBD - это как RAID-1 по сети.
Придерживаясь rsync, если вы в основном зеркалируете статический набор файлов, передайте rsync список файлов, таким образом, rsync не будет тратить изначально время на опрос вашей локальной файловой системы для создания списка файлов - экономит много времени. Списки файлов довольно крутые - если вы включите в список каталог, rsync будет динамически сканировать и отправлять этот каталог (т.е. если указанный каталог склонен к частым изменениям)
Вы используете вторичный сетевой адаптер для зеркалирования, верно?
В зависимости от частоты изменения файлов и количества файлов, может быть лучше дождаться изменений, а затем отправлять только уведомления. Это намного лучше, если частота модификаций низкая, а общее количество файлов велико. В этом случае rsync будет обращаться к диску для stat () всех файлов, чтобы увидеть, были ли они изменены.
http://inotify-tools.sourceforge.net/ есть простой пример (см. пример 1) о том, как грубо связать inotify (монитор модификации файлов) Linux с rsync.
В идеале это должно быть интегрировано в сам rsync (я думаю, что где-то есть экспериментальная версия, которая сделала это, но сейчас не могу ее найти ...)
Запустите rsync с -v вариант, чтобы вы могли видеть, что он работает и когда работает. Также зарегистрируйте его вывод, чтобы увидеть, когда он запускается и когда заканчивается.
Вы уверены, что причиной высокой нагрузки является rsync? Может дело в другом. Вы можете проверить это, отключив rsync или изменив его на rsync каждые 60 минут, и посмотреть, снизится ли нагрузка.
Использовать vmstat чтобы увидеть, что делает ваш сервер. Это много ввода-вывода? Или это подкачка? Ты можешь использовать iostat чтобы узнать, что использует ваш ввод-вывод. Ваш сервер работает медленно из-за использования большого количества ЦП? или много подкачки? Или много дискового ввода-вывода?
Какая у вас оперативная память? Сколько используется? Linux использует неиспользуемую оперативную память в качестве кеша для диска. Если у вас больше ОЗУ, ввод-вывод «улучшится».
Какие у вас диски? Вы можете получить больше дисков или более быстрые диски и совершить набег на них. это повысит производительность.
Rsync версии 3.1 не имеет такой же медленной задержки запуска, как более ранние версии. Средняя загрузка 4.0 для каждого сеанса rsync не является чем-то необычным.
Я бы порекомендовал что-то вроде:
find source -ctime -1 -print | rsync -avR --files-from - B:dest