☰

Obnam的预期表现如何？或者：为什么这么慢？

tag-icon • tag-icon backup performance
Obnam的预期表现如何？或者：为什么这么慢？

最近几天我一直在使用 obnam，虽然它看起来非常有前途，并且似乎基本上提供了我想要的备份工具的所有功能，但我对其性能感到非常失望。事实上，它太慢了，我怀疑 obnam 甚至没有在这里出错，但我的环境中的某些东西导致了它。

所以我主要想知道，是否有其他人正在使用 obnam 或者足够了解其内部结构来识别问题。

据我所知，到目前为止，obnam 似乎为每个备份的文件创建了一个单独的 gpg 进程。从 htop、strace 和 iostat 来看，初始备份的速度主要受到不断分叉的限制，而 CPU 和驱动器（不涉及网络）大多在低于 20% 的利用率下闲置。

我的备份大约有 500.000 个文件，总共 170 GiB 的数据。因此，对于每次备份运行，gpg 都会分叉 500.000 次。事实上，我什至并不感到惊讶，第一次运行需要几乎一整天的时间，而另一次运行需要三个多小时且大多数文件未更改。但这真的是 obnam 用户所期望的性能吗？作为比较：rsnapshot 的增量运行（相同数据、相同计算机、相同驱动器）大约需要四分钟。当然，不涉及加密，但这不应该那重要的。

那么，坦白地问：其他人的机器是否也无法每秒运行 gpg（加密一小块数据）超过 50 次，最终使 obnam 成为一个几乎无法使用的慢工具？还是只有我这样？

（FWIW，我的机器是 Core i5-2500，具有 8G RAM 和 SSD 驱动器，运行 Gentoo。备份是在 HDD 上完成的，但我无法观察到备份到 SSD 的任何区别，因为它不是 I/O -边界。）

答案1

以下是关于如何加速 obnam 的好读物（可能运行速度快 10 倍）：http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

摘要：将“--lru-size=1024 --upload-queue-size=512”添加到命令行或配置文件中。请注意，它会稍微增加 obnam 的内存使用量。

答案2

我想我会通过几种方式来解决这个问题。首先，我会尝试使用以下方法自行诊断。

1.obnam日志

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测试本身中获取此信息之前，可以了解系统 + 网络连接的理论最大值应该是多少。

附加数据点

#1 - 比较 obnam 与 rsnapshot 的博客文章

找到这篇博文，作者在其中对该类别中的几个选项进行了比较。文章标题为：比较 rsnapshot 和 obnam 的计划大型备份。

这篇文章强调了一些非常糟糕的表现，IMO，obnam这似乎与你所描述的相符。

奥南性能

完全备份 /home 后（这需要几天时间！），几天后进行新的运行（由 Linux time 命令计时）：

备份3443706个文件，127小时48分49秒上传94.0 GiB，平均速度214.2 KiB/s830个文件； 1.24 GiB (0 B/s) 实际 7668m56.628s 用户 4767m16.132s 系统 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 GB 的更改数据……机器上的负载并不高，无论是在 CPU 方面，还是在 RAM 方面。 /backups/backup_home 中的磁盘使用量为 5.7T，/home 的磁盘使用量为 6.6T，因此似乎存在一些重复数据删除。

快照性能

/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

因此：6.3TB 的完整备份大约需要 1.5 天。一天后的增量备份需要：

     [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 分钟...更改的数据达到 21GB。

*阁楼与obnam

不是那么彻底，但提到了 的缺点之一obnam是它相对于 . 非常慢attic。

奥布南优点：

  • 有据可查
  • 活跃的邮件列表
  • 可用套餐

奥布南缺点：

  • 非常慢
  • 大备份

阁楼优点：

  • 备份小得多（即使没有重复数据删除）
  • 更好的重复数据删除
  • 快多了

阁楼缺点：

  • 存储库格式未记录
  • 不是一个庞大的用户社区

显示的一些测试数据似乎表明速度obnam确实很慢。

通过一般的 WiFi 连接，从本地 SSD 到远程 HD：

    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

参考

答案3

Obnam 的默认配置（截至 2015 年 2 月 8 日）不适用于备份具有大量小文件的目录。我遇到了与上面提到的完全相同的问题。

我的解决方案是将 --lru-size=8192 --upload-queue-size=8192 添加到命令行。这解决了问题，并将沮丧的 Obnam 用户变成了非常快乐的用户。 （我现在的标准配置文件中有这些设置。）

不幸的是，Obnam 的教程没有预先提到这些设置的重要性。常见问题解答提供了更多详细信息。对于具有许多小文件的系统来说，设置性能参数确实是强制性的。

相关内容