Duplicity 恒定内存使用量(duply)

Duplicity 恒定内存使用量(duply)

我发现在所有运行 Duplicity 作为 S3 备份工具的服务器上,Duplicity 的内存使用量都持续处于高水平。

Duplicity 不是应该运行其备份任务并在之后终止其作业吗,还是我在这里遗漏了什么?

duply -v
duply version 2.0.1
(http://duply.net)

Using installed duplicity version 0.7.11, python 2.7.6, gpg 1.4.16 (Home: ~/.gnupg), awk 'GNU Awk 4.0.1', grep 'grep (GNU grep) 2.16', bash '4.3.11(1)-release (x86_64-pc-linux-gnu)'.

我正在使用 Duply 来管理每台服务器上的配置文件,其中之一如下:

GPG_KEY='FOO'
GPG_PW='FOO'

TARGET='s3://s3-eu-central-1.amazonaws.com/foo-bucket/bar-location'

export AWS_ACCESS_KEY_ID='FOO'
export AWS_SECRET_ACCESS_KEY='FOO'

# base directory to backup
SOURCE='/'

# exclude folders containing exclusion file (since duplicity 0.5.14)
# Uncomment the following two lines to enable this setting.
FILENAME='.duplicity-ignore'
DUPL_PARAMS="$DUPL_PARAMS --exclude-if-present '$FILENAME'"

# Time frame for old backups to keep, Used for the "purge" command.
# see duplicity man page, chapter TIME_FORMATS)
MAX_AGE=2M

# Number of full backups to keep. Used for the "purge-full" command.
# See duplicity man page, action "remove-all-but-n-full".
MAX_FULL_BACKUPS=2

# Number of full backups for which incrementals will be kept for.
# Used for the "purge-incr" command.
# See duplicity man page, action "remove-all-inc-of-but-n-full".
MAX_FULLS_WITH_INCRS=1

# activates duplicity --full-if-older-than option (since duplicity v0.4.4.RC3)
# forces a full backup if last full backup reaches a specified age, for the
# format of MAX_FULLBKP_AGE see duplicity man page, chapter TIME_FORMATS
# Uncomment the following two lines to enable this setting.
MAX_FULLBKP_AGE=1M
DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE "

# sets duplicity --volsize option (available since v0.4.3.RC7)
# set the size of backup chunks to VOLSIZE MB instead of the default 25MB.
# VOLSIZE must be number of MB's to set the volume size to.
# Uncomment the following two lines to enable this setting.
VOLSIZE=100
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "

# more duplicity command line options can be added in the following way
# don't forget to leave a separating space char at the end
#DUPL_PARAMS="$DUPL_PARAMS --put_your_options_here "

这是运行备份的 cronjob:

12 3 * * * nice -n19 ionice -c2 -n7 duply database backup_verify_purge --force --name foo_database >> /var/log/duplicity.log 2>&1

26 3 * * * nice -n19 ionice -c2 -n7 duply websites backup_verify_purge --force --name foo_websites >> /var/log/duplicity.log 2>&1

53 4 * * * nice -n19 ionice -c2 -n7 duply system backup_verify_purge --force --name foo_system >> /var/log/duplicity.log 2>&1

这是 24 小时的内存使用情况图表:

在此处输入图片描述

答案1

我使用的配置与您几乎相同,并且内存使用情况也非常相似。我的 python 和 gpg 的版本稍新一些,而且我没有使用 duply。duplicity 是 0.7.11。

我测试过的一台机器(el6)将大约 350 万个文件备份到 s3,最大内存占用约 3G。从此备份中恢复单个文件最大占用约 3.9G RAM:

29067 root     /opt/duplicity/bin/python2         0  3893924  3893957  3894704

另一台正在备份约 750 万个文件的机器(el5)当前运行时使用了 1.9G 资源。

想知道与您的帖子相关的两件事:

  1. 这种内存使用情况正常吗?我认为当备份卷中有大量文件时,这可能是正常的。如果不是,我应该预计使用多少内存来备份 3.5M 个文件(约 50G)到 s3 或 swift(如果重要的话)。
  2. 将 --volsize 参数更改为小于 200M 有帮助吗?我在变更日志中注意到 .7.11 大大增加了默认卷大小。

还有什么可以减少内存使用量吗?

抱歉,我无法回答您的问题,但我觉得这篇文章很有意义,因为我们似乎正在处理类似的问题。我查看了相当多的内容,除了与 2012 年左右的 bug 相关的内容外,没有发现太多关于正常 duplicity 内存使用的信息。

谢谢!

答案2

看起来我的问题是由通过 apt-get 安装的 Duplicity 版本引起的。

安装 tarball 版本解决了内存问题。

以下是更多信息: https://answers.launchpad.net/duplicity/+question/577611

答案3

还从 Kenneth 那里看到了这一点,这可能与大文件有关:

Kenneth Loafman (kenneth-loafman) 于 2016-02-26 写道:对于大型文件,会生成大量签名并保留,直到文件完成。要缓解此问题,请使用“--max-blocksize=20480”或更高版本来避免此问题。

答案4

我有同样的问题,有人能解决这个问题吗?

我已经更新了 duplicity、python-boto,尝试使用较高的 --max-blocksize,但失败了。它可以毫无问题地备份到 FTP 位置,如果我尝试备份到 S3,则会因 OOM kill 而失败...

奇怪的是,我有相同的生产服务器和暂存服务器,并且暂存服务器在执行此操作时正常备份到 S3,使用 600mb RAM。生产服务器占用了 3GB 以上,然后出现故障。

相关内容