Я испытываю постоянное высокое использование памяти из-за Duplicity на всех серверах, на которых он используется в качестве инструмента резервного копирования для S3.
Разве 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 "
Вот задание cron для запуска резервного копирования:
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-часовой график использования памяти:
Похоже, моя проблема была вызвана версией Duplicity, установленной через apt-get.
Установка версии tarball решила проблемы с памятью.
Вот дополнительная информация: https://answers.launchpad.net/duplicity/+question/577611
Я использую почти такую же конфигурацию, что и вы, и наблюдаю очень похожее использование памяти. Мои python и gpg немного новее, и я не использую duply. двуличность - 0,7.11.
Одна из машин (el6), на которой я тестировал, поддерживала около 3,5 миллионов файлов на s3 и имела максимум 3g памяти res. Восстановление одного файла из этой резервной копии занимает максимум 3,9 ГБ ОЗУ:
29067 root /opt/duplicity/bin/python2 0 3893924 3893957 3894704
Другая машина (el5), которая выполняет резервное копирование около 7,5 миллионов файлов, в настоящее время использует во время работы разрешение 1,9 ГБ.
Хотите знать две вещи, которые имеют отношение к вашему сообщению:
Что-нибудь еще, что может уменьшить использование памяти?
Извините, я не могу ответить на ваш вопрос, но я считаю, что этот пост актуален, поскольку мы, похоже, сталкиваемся с аналогичной проблемой. Я немного огляделся и мало что вижу о нормальном использовании дублирующей памяти, за исключением того, что связано с ошибкой от ~ 2012 года.
Спасибо!
У меня такая же проблема, кому-нибудь удалось решить эту проблему?
Я обновил дублированность, python-boto, попробовал с высоким --max-blockize и не повезло. Он без проблем выполняет резервное копирование на FTP-сервер, если я попытаюсь выполнить резервное копирование на S3 в случае сбоя с помощью OOM kill ...
Странно, что у меня есть производственный и промежуточный серверы, которые одинаковы, и при этом обычно выполняется резервное копирование на S3 с использованием 600 МБ ОЗУ. Производственный сервер съедает 3 ГБ +, а затем выходит из строя.
Также видел это у Кеннета, что может иметь отношение к огромным файлам:
Кеннет Лоафман (kenneth-loafman) написал 26 февраля 2016 года: «В огромных файлах генерируется большое количество подписей, которые хранятся до тех пор, пока файл не будет готов. Чтобы смягчить эту проблему, используйте "--max-blocksize = 20480" или выше, чтобы избежать этой проблемы.