Какова ожидаемая производительность Obnam? Или: почему это так медленно?

Последние несколько дней я играл с 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, поскольку это не ввод-вывод -связанный.)

Вот хорошее прочтение о том, как ускорить работу obnam (может работать в 10 раз быстрее): http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

Сводка: добавьте "--lru-size = 1024 --upload-queue-size = 512" в вашу командную строку или файл конфигурации. Обратите внимание, что это немного увеличивает использование памяти obnam.

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

1. Журналы обнам

Для начала вы можете регистрировать сообщения от obnamтак:

$ obnam --log obnam.log

Вы можете увеличить уровень регистрации через --log-levelкоммутатор, чтобы получить больше деталей.

--log=FILE          write log entries to FILE (default is to not write log
                    files at all); use "syslog" to log to system log, or
                    "none" to disable logging
--log-level=LEVEL   log at LEVEL, one of debug, info, warning, error,
                    critical, fatal (default: info)

2. Профилирование

Вы также можете получить профиль того, что obnamделает следующим образом из этого отрывка в часто задаваемых вопросах проекта :

Если OBNAM_PROFILEпеременная среды содержит имя файла, данные профилирования сохраняются там и могут быть просмотрены позже с помощью obnam-viewprof:

  $ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | less

Проблемы производительности, которые не связаны с конкретной настройкой, также можно наблюдать с помощью obnam-benchmark tool.

3. Откройте тикет

Если производительность все еще не определена в результате какого-либо самостоятельного расследования, я бы открыл билет на веб-сайте проекта . Судя по тому, что мне удалось собрать, разработчики (и) несколько отзывчивы, и они, вероятно, будут лучшими в устранении проблем с их проектом.

obnamпохоже, использует только SFTP, поэтому должно быть достаточно очевидно, что является причиной проблемы. Я также хотел бы рассмотреть возможность определения базовой производительности SFTP, чтобы вы могли увидеть, какой теоретический максимум должен быть у вашей системы + сетевого подключения, прежде чем пытаться получить эту информацию из самих obnamтестов.

Дополнительные точки данных

Нашел этот пост в блоге, где автор сделал сравнение нескольких вариантов в этой категории. Статья называется: Сравнение rsnapshot и obnam для запланированных больших резервных копий .

В статье подчеркивалась некоторая очень низкая производительность, IMO, obnamкоторая, казалось бы, сочеталась с тем, что вы описываете.

производительность

После полного резервного копирования / home (что заняло несколько дней!), Через несколько дней потребовался новый запуск (синхронизация по команде времени Linux):

Резервное копирование 3443706 файлов, загрузка 94,0 ГиБ за 127х48м49с при средней скорости 214,2 КиБ / с830 файлов; 1,24 ГиБ (0 б / с), реальный 7668м56,628 с, пользователь 4767м16,132 с, сис 162м48,739 с

Из файла журнала obname:

   2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 written=0
   2012-11-21 23:09:36 INFO VFS: baseurl=/backups/backup_home read=2727031576964 written=150015706142 
   2012-11-21 23:09:36 INFO Backup performance statistics: 
   2012-11-21 23:09:36 INFO * files found: 3443706 
   2012-11-21 23:09:36 INFO * uploaded data: 100915247663 bytes (93.9846482715 GiB) 2012-11-21 23:09:36 INFO * duration: 460128.627629s 
   2012-11-21 23:09:36 INFO * average speed: 214.179341663 KiB/s
   2012-11-21 23:09:36 INFO Backup finished. 2012-11-21 23:09:36 INFO Obnam ends
   2012-11-21 23:09:36 INFO obnam version 1.2 ends normally

Итак: ~ 5 дней на резервное копирование ~ 100 ГБ измененных данных ... На машинах была невысокая нагрузка, ни с точки зрения процессора, ни с точки зрения оперативной памяти. Использование диска в / backups / backup_home составило 5,7 т, использование диска в / home - 6,6 т, так что, похоже, существует некоторая дедупликация.

производительность rsnapshot

Полная резервная копия / home для (в соответствии с файлом журнала):

   [27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started   
   [27/Nov/2012:12:55:31] echo 17632 > /var/run/rsnapshot.pid 
   [27/Nov/2012:12:55:31] mkdir -m 0700 -p /backups/backup_home_rsnapshot/    
   [27/Nov/2012:12:55:31] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ 
   [27/Nov/2012:12:55:31] /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /home /backups/backup_home_rsnapshot/daily.0/localhost/
   [28/Nov/2012:23:16:16] touch /backups/backup_home_rsnapshot/daily.0/
   [28/Nov/2012:23:16:16] rm -f /var/run/rsnapshot.pid
   [28/Nov/2012:23:16:16] /usr/bin/rsnapshot daily: completed successfully

Итак: ~ 1,5 дня для полной резервной копии 6,3 ТБ. Инкрементное резервное копирование через день заняло:

     [29/Nov/2012:13:10:21] /usr/bin/rsnapshot daily: started
     [29/Nov/2012:13:10:21] echo 20359 > /var/run/rsnapshot.pid
     [29/Nov/2012:13:10:21] mv /backups/backup_home_rsnapshot/daily.0/ /backups/backup_home_rsnapshot/daily.1/
     [29/Nov/2012:13:10:21] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:10:21] /usr/bin/rsync -a --delete --numeric-ids -- relative --delete-excluded --link-dest=/backups/backup_home_rsnapshot/daily.1/localhost/ /home/backups/backup_home_rsnapshot/daily.0/localhost/
     [29/Nov/2012:13:25:09] touch /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:25:09] rm -f /var/run/rsnapshot.pid
     [29/Nov/2012:13:25:09] /usr/bin/rsnapshot daily: completed successfully

Итак: 15 минут ... и измененные данные составили 21 ГБ.

Не так тщательно, но упоминает, что одним из минусов obnamявляется то, что он очень медленный против attic.

Обнам плюсы:

• хорошо документированы
• активный список рассылки
• пакеты доступны

Обнам минусы:

• очень медленно
• большие резервные копии

Чердак плюсы:

• намного меньшие резервные копии (даже без дедупликации)
• гораздо лучше дедупликация
• намного быстрее

Чердак минусы:

• формат хранилища не задокументирован
• небольшое сообщество пользователей

Приведены некоторые данные тестирования, которые, кажется, указывают на то, что obnamэто действительно очень медленно.

От локального SSD до удаленного HD, через так себе Wi-Fi соединение:

    rsync:           0:24  0:01
    Attic ssh:       0:28  0:05
    Attic sshfs:     0:51  0:08
    Obnam sftp:      8:45  0:21
    Obnam sshfs:    25:22  0:22

Ссылки

• Обнам настраивает сообщение в блоге

Стандартная конфигурация Obnam (по состоянию на 2015-02-08) не подходит для резервного копирования каталогов с большим количеством маленьких файлов. У меня была точно такая же проблема, как упомянуто выше.

Решением для меня было добавить --lru-size = 8192 --upload-queue-size = 8192 в командную строку. Это решило проблему и превратило разочарованного в очень счастливого пользователя Obnam. (У меня есть эти настройки в моих стандартных файлах конфигурации сейчас.)

К сожалению, в руководстве Obnam не упоминается заранее, насколько важны эти настройки. FAQ дает более подробную информацию. Установка параметров производительности действительно обязательна в системах с большим количеством маленьких файлов.