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

[1130220]Думаю, я бы атаковал этот вопрос парой способов. Для начала я бы попробовал сам поставить диагноз, используя следующие методики.[12134]1. Журналы obnam[12135]Для начала вы можете вести журнал сообщений из [1130634]obnam[1130635] так:[12136]Вы можете увеличить уровень протоколирования с помощью переключателя [1130636]--log-уровня[1130637], а также получить более подробную информацию.[12137]2. Профилирование[12138]Также можно получить профиль того, что делает [1130638]obnam[1130639] следующим образом из этого отрывка в FAQs[1130641] проекта [1130640]:[12139]Если переменная окружения [1130860]OBNAM_PROFILE[1130861] содержит имя файла, то в файле данные профилирования сохраняются там, и могут быть просмотрены позже с помощью [1130862]obnam-viewprof[1130863]:[12140]$ OBNAM_PROFILE=obnam.prof obnam.prof ... obnam-viewprof obnam.prof | less [12141] Проблемы с производительностью, не связанные с конкретной установкой, могут также наблюдайте с помощью инструмента [1130866]obnam-benchmark[1130867].[12142]3. Откройте тикет [12143]Если производительность все еще не определена, то я бы открыл тикет на сайте проекта [1130648]. Из того, что мне удалось собрать, разработчики в некоторой степени отзывчивы, и они, скорее всего, будут лучшими в устранении проблем со своим проектом.[12144]obnam[1130651], похоже, использует только SFTP, так что должно быть вполне очевидно, что вызывает проблему. Я бы также рассмотрел возможность базирования производительности SFTP самостоятельно, чтобы вы могли увидеть, какой теоретический максимум должен быть с вашей системой + сетевым подключением, прежде чем пытаться получить эту информацию из самих тестов [1130652]obnam[1130653].[12145]Дополнительные точки данных[12146]#1 - пост в блоге, сравнивающий obnam с rsnapshot[12147]Нашёл этот пост в блоге, где автор сделал сравнение нескольких вариантов в этой категории. Статья озаглавлена: [1130654]Сравнение rsnapshot и obnam для резервного копирования больших копий по расписанию[1130655].[12148]В статье были отмечены очень низкая производительность, IMO, с [1130656]obnam[1130657], что, похоже, не может не радовать.[12149]obnam производительность[12150]После полного резервного копирования /дома (что заняло несколько дней! ), новый запуск, который произошел через несколько дней (время по команде времени Linux):[12151]Резервное копирование 3443706 файлов, загрузка 94.0 GiB в 127h48m49s со средней скоростью 214.2 KiB/s830 файлов; 1. 24 Гигабайта (0 Б/с) реально 7668m56.628s пользователь 4767m16.132s sys 162m48.739s[12152]Из файла журнала obname:[12153]2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 write=0 2012-11-21 23:09:36 ИНФО VFS: baseurl=/backups/backup_home read=2727031576964 write=150015706142 2012-11-21 23:09:36 Статистика резервного копирования ИНФО: 2012-11-21 23:09:36 ИНФО * найдены файлы: 3443706 2012-11-21 23:09:36 ИНФО * загруженные данные: 100915247663 байт (93.9846482715 GiB) 2012-11-21 23:09:36 ИНФО * продолжительность: 460128.627629s 2012-11-21 23:09:36 ИНФО * средняя скорость: 214.179341663 KiB/s 2012-11-21 23:09:36 Резервное копирование ИНФО завершено. 2012-11-21 23:09:36 ИНФО Завершилась Обьнам 2012-11-21 23:09:36 ИНФО обнам версия 1.2 заканчивается нормально [12154] Итак: ~5 дней для резервного копирования ~100 ГБ измененных данных... Загрузка не была высокой. на машинах, ни с точки зрения процессора, ни с точки зрения оперативной памяти. Диск использование в /backups/backup_home было 5.7T, использование диска /home было 6.6T, так что, похоже, есть какой-то дедуп.[12155]rsnapshot performance[12156]A full backup of /home to (в соответствии с лог-файлом):[1130673] [1130674] [1130870] [27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started [27/Nov/2012:12:55:31] эхо 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: выполнено успешно [12157] Итак: ~1,5 дня для полного резервного копирования 6,3 ТБ. Инкрементальное резервное копирование a днем позже взял:[1130677] [1130678] [1130872] [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 -- относительный --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: выполнено успешно [12158] Итак: 15 минут... и измененные данные составили 21 ГБ. [12159] *аттик против обнама* [1130256] Не так подробно, но упоминает, что одним из недостатков [1130682] obnam[1130683] является то, что он очень медленный по сравнению с [1130684] attic[1130685]. [12160]Obnam pros:[12161]хорошо документированный[12162]активный список рассылки[12163]доступные пакеты[12164]Obnam минусы:[12165]очень медленное [12166]большое резервное копирование[12167]Attic pros:[12168]намного меньшее резервное копирование (даже без дедупликации)[12169]намного лучшая дедупликация[12170]намного быстрее[12171]аттик[12171]аттик[1130685]: Формат репозитория [12172]не документирован[12173]не большое пользовательское сообщество[12174] Показаны некоторые данные тестирования, которые, похоже, указывают на то, что [1130702]obnam[1130703] просто очень медленный. [12175]От локального SSD к удаленному HD, через так называемое wifi соединение:[12176]rsync: 0:24 0:01 Attic ssh: 0:28 0:05 Attic sshfs: 0:51 0:08 Обнамский sftp: 8:45 0:21 Обнамские sshfs: 25:22 0:22 [12177]References[12178]Obnam tweaks post[12179]

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

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

.

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

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

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