我发现在所有运行 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 资源。
想知道与您的帖子相关的两件事:
- 这种内存使用情况正常吗?我认为当备份卷中有大量文件时,这可能是正常的。如果不是,我应该预计使用多少内存来备份 3.5M 个文件(约 50G)到 s3 或 swift(如果重要的话)。
- 将 --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 以上,然后出现故障。