Restic: Reduza o consumo de memória com a opção de linha de comando

Ei, obrigado pelo seu interesse no restic. O número de cerca de 300 MiB de RAM que mencionei na palestra é usado para duas coisas (principalmente):

• calculando scrypt (senha): as constantes para scrypt estão codificadas agora, e há # 17 para adicionar código que automaticamente descobre quão difícil deve ser a criptografia para o sistema atual
• ter vários buffers de blobs / packs para fazer backup na memória: isso está fortemente acoplado à simultaneidade máxima permitida. Para isso, também gostaria de ter um código de ajuste automático, mas uma opção de linha de comando também é provável.

Para resumir meus pontos acima: Está planejado e será implementado em algum momento.

Parece bom para mim. Gostaria de manter este problema em aberto para rastrear esse recurso, então.

Concordou.

Eu estaria interessado neste tópico também de uma perspectiva de servidor, portanto, não necessariamente pouca memória, mas "ainda não o suficiente". :) Por exemplo, eu tenho um servidor de e-mail com ~ 950GB de dados ( scanned 64173 directories, 2147728 files in 2:41 ) e com 2GB de RAM eu encontrei OOM com restic (rodando em ionice -c 3 nice -n 19 ). Existe algum número conhecido para calcular as necessidades de memória para restic (por arquivo / por GB / ....)? (Eu encontrei OOM com restic em todos os tipos de VMs diferentes, sabia que essas necessidades antecipadamente tornariam a vida mais fácil, e se houvesse alguma maneira de reduzir o consumo de memória, seria ótimo.)

Obrigado!

Minha experiência é de cerca de 4 GB de RAM para tamanho de repositório de 1,5 TB (para backup). prune leva ainda mais (~ 9-10 GB de RAM).

O uso de memória depende principalmente não do tamanho dos dados em uma máquina específica, mas principalmente do tamanho do repositório. Portanto, é impossível fazer backup de um arquivo de 100 KB na máquina com 2 GB de RAM (sem troca) se o repositório do Restic em si tiver cerca de 1 TB.

Aqui:

• Construir:
  restic 0.8.3 (v0.8.3-11-gda77f4a2) compiled with go1.9.4 on linux/amd64
• Dimensões (mas eu realmente acredito que a maioria desses arquivos - muitos clones de repositório, caches de metadados, diretórios de construção, etc. - são realmente excluídos e os números relatados pelo restic refletem a quantidade total):
  118775 directories 829113 files 129.220 GiB
• Uso de memória: cerca de 3,8 G por execução diária

Existe algum progresso nisso? Amo restic, mas meus backups não são mais concluídos devido ao esgotamento da memória (repositório de 1,5 TB, usa ~ 23G RAM, backend b2). Afaik, atualmente a simultaneidade só pode ser modificada modificando a própria fonte (https://github.com/restic/restic/issues/979#issuecomment-374359647), mas isso não é realmente sustentável.

Alguma coisa mudou em termos de requisitos de uso de memória?

Eu também estou enfrentando esse problema. Repo de restic de sistema de 2GB 250GB. Correndo:

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

(também usando 4/14 para tentar reduzir o uso de memória de 3/7) leva 1.7G. Pode levar de 10 a 12 horas para completar o comando porque o sistema deficiente está perdendo a cabeça. Além disso, o sistema é praticamente inútil para qualquer outra coisa por causa da troca.

Eu gosto do Restic, mas isso não é sustentável.

Alguém pode esclarecer qual é a sugestão real nesta edição? Quero dizer, se o consumo / requisitos de memória podem ser reduzidos, por que não devemos simplesmente fazer isso e, em vez disso, ter uma opção de linha de comando para permitir o uso de menos memória?

Presumo que alocar menos espaço, se possível, significaria que o processo é mais lento, de modo que justificaria não fazer isso por padrão?

Já houve melhorias em relação ao uso de memória e algumas outras estão em processo.
Em princípio, estou de acordo com a argumentação de @rawtaz de que reduzir o uso de memória permitirá que o restic seja utilizável em um campo muito mais amplo de dispositivos.

Dito isso, é claro que há possibilidades de reduzir ainda mais o uso de memória, especialmente trocando por velocidade. Comecei a trabalhar em possibilidades relacionadas ao índice em # 2794

Uma solução adequada para isso provavelmente usará um índice de repositório em disco ou permitirá que os clientes carreguem apenas partes do índice conforme discutido em # 1988.