Последние несколько дней я играл с obnam, и, хотя он выглядит очень многообещающе и, кажется, предлагает практически все, что я когда-либо хотел в инструменте резервного копирования, я довольно разочарован его производительностью. На самом деле, это так медленно, я подозреваю, что обнам здесь даже не виноват, но что-то в моей среде вызывает это.
Поэтому я в основном задаюсь вопросом: кто-то еще использует obnam или знает его внутренности достаточно хорошо, чтобы, возможно, выявить проблему.
Из того, что я мог сказать до сих пор, obnam, кажется, разветвляет отдельный процесс gpg для каждого файла, для которого выполняется резервное копирование. Судя по htop, strace и iostat, скорость первоначального резервного копирования в основном ограничена постоянным разветвлением, тогда как ЦП и накопители (без участия сети) в основном работают на холостом ходу ниже 20%.
Моя резервная копия составляет около 500 000 файлов с общим объемом данных 170 ГБ. Таким образом, для каждого запуска резервного копирования gpg разветвляется 500.000 раз. На самом деле, я даже не удивлен, что на первоначальный прогон уходит почти целый день и более трех часов на другой прогон с большинством файлов без изменений. Но действительно ли этого должны ожидать пользователи Obnam? Для сравнения: инкрементный запуск rsnapshot (те же данные, тот же компьютер, те же диски) занимает около четырех минут. Конечно, шифрование не используется, но это не должно быть настолько значительным.
Итак, спросите прямо: неужели машина другого не может запускать gpg (шифрование небольшого куска данных) также более 50 раз в секунду, что в конечном итоге делает obnam почти невероятно медленным инструментом? Или это только у меня так?
(FWIW, моя машина - Core i5-2500 с 8 ГБ ОЗУ и SSD-дисками, работающими под управлением Gentoo. Резервное копирование выполняется на жесткий диск, но я не заметил никакой разницы в резервном копировании на SSD, поскольку это не ввод-вывод -связанный.)
источник
--lru-size=256 --upload-queue-size=128Что будет хорошим значением для моей Ubuntu с 8 ГБ ОЗУ, которая должна выполнять резервное копирование на довольно медленный онлайн-сервер с только 2 ГБ ОЗУ?Я думаю, что я бы атаковал эту проблему несколькими способами. Для начала я бы попытался сам поставить диагноз, используя следующие методики.
1. Журналы обнам
Для начала вы можете регистрировать сообщения от
obnamтак:Вы можете увеличить уровень регистрации через
--log-levelкоммутатор, чтобы получить больше деталей.2. Профилирование
Вы также можете получить профиль того, что
obnamделает следующим образом из этого отрывка в часто задаваемых вопросах проекта :3. Откройте тикет
Если производительность все еще не определена в результате какого-либо самостоятельного расследования, я бы открыл билет на веб-сайте проекта . Судя по тому, что мне удалось собрать, разработчики (и) несколько отзывчивы, и они, вероятно, будут лучшими в устранении проблем с их проектом.
obnamпохоже, использует только SFTP, поэтому должно быть достаточно очевидно, что является причиной проблемы. Я также хотел бы рассмотреть возможность определения базовой производительности SFTP, чтобы вы могли увидеть, какой теоретический максимум должен быть у вашей системы + сетевого подключения, прежде чем пытаться получить эту информацию из самихobnamтестов.Дополнительные точки данных
# 1 - сообщение в блоге, сравнивающее obnam и rsnapshotНашел этот пост в блоге, где автор сделал сравнение нескольких вариантов в этой категории. Статья называется: Сравнение rsnapshot и obnam для запланированных больших резервных копий .
В статье подчеркивалась некоторая очень низкая производительность, IMO,
obnamкоторая, казалось бы, сочеталась с тем, что вы описываете.производительность
производительность rsnapshot
* чердак против обнамаНе так тщательно, но упоминает, что одним из минусов
obnamявляется то, что он очень медленный противattic.Приведены некоторые данные тестирования, которые, кажется, указывают на то, что
obnamэто действительно очень медленно.Ссылки
источник
Стандартная конфигурация Obnam (по состоянию на 2015-02-08) не подходит для резервного копирования каталогов с большим количеством маленьких файлов. У меня была точно такая же проблема, как упомянуто выше.
Решением для меня было добавить --lru-size = 8192 --upload-queue-size = 8192 в командную строку. Это решило проблему и превратило разочарованного в очень счастливого пользователя Obnam. (У меня есть эти настройки в моих стандартных файлах конфигурации сейчас.)
К сожалению, в руководстве Obnam не упоминается заранее, насколько важны эти настройки. FAQ дает более подробную информацию. Установка параметров производительности действительно обязательна в системах с большим количеством маленьких файлов.
источник