Restic: Уменьшите потребление памяти с помощью параметра командной строки

Привет, спасибо за интерес к отдыху. ОЗУ объемом около 300 МБ, которое я упомянул в своем выступлении, используется (в основном) для двух целей:

• вычисление scrypt (пароля): константы для scrypt жестко запрограммированы прямо сейчас, и есть # 17 для добавления кода, который автоматически определяет, насколько сложным должен быть scrypt для текущей системы
• наличие нескольких буферов BLOB-объектов / пакетов для резервного копирования в памяти: это тесно связано с максимально допустимым параллелизмом. Для этого я также хотел бы иметь код автонастройки, но также возможен вариант командной строки.

Подводя итог вышесказанному: это запланировано и будет реализовано в какой-то момент.

Звучит неплохо. Тогда я хотел бы оставить этот вопрос открытым, чтобы отслеживать эту функцию.

Согласовано.

Я был бы заинтересован в этой теме также с точки зрения сервера, так что не обязательно мало памяти, но «все еще недостаточно». :) Например, у меня есть почтовый сервер с ~ 950 ГБ данных ( scanned 64173 directories, 2147728 files in 2:41 ) и с 2 ГБ ОЗУ я столкнулся с OOM с restic (работает под ionice -c 3 nice -n 19 ). Есть ли какие-либо известные числа для расчета потребности в памяти для восстановления (на файл / на ГБ / ....)? (Я столкнулся с OOM с restic во всех видах различных виртуальных машин, зная, что эти потребности заранее упростят жизнь, и если бы был какой-либо способ уменьшить потребление памяти, это было бы здорово.)

Спасибо!

По моему опыту, около 4 ГБ ОЗУ для размера репо 1,5 ТБ (для резервного копирования). prune занимает еще больше (~ 9-10 ГБ ОЗУ).

Использование памяти в основном зависит не от размера данных на конкретной машине, а от размера репозитория. Таким образом, невозможно создать резервную копию файла размером 100 КБ на машине с 2 ГБ ОЗУ (без подкачки), если размер самого restic-репозитория составляет ~ 1 ТБ.

Здесь:

• Строить:
  restic 0.8.3 (v0.8.3-11-gda77f4a2) compiled with go1.9.4 on linux/amd64
• Размеры (но я на самом деле считаю, что большинство этих файлов - множество клонов репозитория, кеши метаданных, каталоги сборки и т. Д. - фактически исключены, и те числа, которые сообщает restic, отражают общее количество):
  118775 directories 829113 files 129.220 GiB
• Использование памяти: около 3,8 ГБ на ежедневный запуск

Есть ли в этом прогресс? Люблю отдыхать, но мои резервные копии больше не завершаются из-за нехватки памяти (хранилище 1,5 ТБ, использует ~ 23 ГБ ОЗУ, бэкэнд b2). Afaik, в настоящее время параллелизм можно изменить только путем изменения самого источника (https://github.com/restic/restic/issues/979#issuecomment-374359647), но на самом деле это не обслуживается.

Изменилось ли что-нибудь с точки зрения требований к использованию памяти?

Я тоже сталкиваюсь с этой проблемой. Система 2 ГБ 250 ГБ restic repo. Бег:

ionice -c 3 nice -n 19 ~ / local / bin / restic -r / mnt / restic -p rk check --read-data-subset 3/7

(также используется 4/14, чтобы попытаться уменьшить использование памяти с 3/7) занимает 1,7 ГБ. Выполнение команды может занять 10 или 12 часов, потому что плохая система выкидывает себе мозги. Кроме того, система практически бесполезна для чего-либо еще из-за подкачки.

Я люблю рестик, но это не рационально.

Может кто-нибудь прояснить, что на самом деле предлагается в этом вопросе? Я имею в виду, что если потребление / требования к памяти можно уменьшить, почему бы нам просто не сделать это, а вместо этого использовать переключатель командной строки, позволяющий использовать меньше памяти?

Я предполагаю, что выделение меньшего пространства, если это возможно, будет означать, что процесс будет медленнее, так что это может служить основанием для отказа от этого по умолчанию?

В отношении использования памяти уже были внесены улучшения, а некоторые другие находятся в стадии разработки.
В принципе, я придерживаюсь аргументации том, что сокращение использования памяти позволит использовать restic на гораздо более широком диапазоне устройств.

Тем не менее, есть, конечно, возможности для дальнейшего уменьшения использования памяти, особенно для скорости. Я начал работать над возможностями, связанными с индексом, в # 2794

Правильным решением для этого, скорее всего, будет использование индекса репозитория на диске или разрешение клиентам загружать только части индекса, как описано в # 1988.