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

Эти последние несколько дней я общался с obnam, и, хотя он выглядит очень многообещающим и, кажется, предлагает в основном все, что я когда-либо хотел в инструменте резервного копирования, я очень разочарован его производительностью. На самом деле, это так медленно, я подозреваю, что обнам здесь даже не виноват, но что-то в моей среде вызывает его.

Поэтому я в основном интересуюсь, если кто-то еще использует obnam или хорошо знает свои внутренние компоненты, чтобы идентифицировать проблему.

Из того, что я мог сказать до сих пор, obnam, похоже, развивает индивидуальный процесс gpg для каждого файла, который был скопирован. Судя по htop, strace и iostat, скорость первоначальной резервной копии в основном ограничена постоянным форсированием, в то время как центральный процессор и диски (без использования сети) в основном работают на холостом ходу ниже 20% использования.

Моя резервная копия составляет около 500 000 файлов с общим объемом 170 гигабайт. Поэтому для каждого резервного запуска gpg разветвляется 500 000 раз. На самом деле я даже не удивлен, что для первого запуска требуется почти целый день и более трех часов для другого запуска с большинством файлов без изменений. Но действительно ли это должна быть производительность пользователей, которых должны ожидать пользователи? Для сравнения: инкрементный запуск rsnapshot (одни и те же данные, одна и та же машина, одни и те же диски) занимает около четырех минут. Конечно, шифрование не используется, но это не должно быть столь значительным.

Итак, спросите прямо: неужели все остальные машины не могут запускать gpg (зашифровать небольшой кусок данных) более 50 раз в секунду, в конечном итоге делая obnam почти незаменимым медленным инструментом? Или это только я?

(FWIW, моя машина – Core i5-2500 с 8G оперативной памятью и SSD-дисками, работающая под управлением Gentoo. Резервное копирование выполняется на жесткий диск, но я не мог наблюдать никакой разницы в резервном копировании на SSD, поскольку это не I / O -связанный.)

Вот хороший пример того, как ускорить 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 logs

Для начала вы можете записывать сообщения из obnam следующим образом:

 $ obnam --log obnam.log 

Вы можете увеличить уровень ведения журнала с помощью переключателя уровня журнала, чтобы получить более подробную информацию.

 --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_PROFILE содержит имя файла, данные профилирования там хранятся и могут быть просмотрены позже с помощью obnam-viewprof :

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

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

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

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

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

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

# 1 – сообщение в блоге, сравнивающее obnam vs. rsnapshot

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

В статье была подчеркнута некоторая очень низкая производительность, ИМО, с obnam , которая, похоже, obnam с тем, что вы описываете.

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

После полного резервного копирования / дома (что заняло несколько дней!), Новый прогон, через несколько дней (время по команде Linux time):

Резервное копирование 3443706 файлов, загружено 94,0 гигабайта в 127х48м49х при 214,2 Кбайт / с средней скорости830 файлов; 1,24 GiB (0 B / s) реальный 7668m56.628s пользователь 4767m16.132s sys 162m48.739s

Из файла журнала 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.7T, использование диска / home было 6.6T, так что есть какая-то дедушка.

производительность 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

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

Obnam pros:

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

Obnam cons:

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

Аттические профи:

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

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

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

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

От локального SSD до удаленного HD через так называемое соединение wifi:

  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 изменяет сообщение в блоге

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

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

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