Restic: Reducir el consumo de memoria con la opción de línea de comandos

Oye, gracias por tu interés en Restic. La cantidad de alrededor de 300MiB de RAM que mencioné en la charla se usa para dos cosas (principalmente):

• cálculo de scrypt (contraseña): las constantes de scrypt están codificadas de forma rígida en este momento, y hay # 17 para agregar código que determina automáticamente qué tan difícil debería ser scrypt para el sistema actual
• Tener varios búferes de blobs / paquetes para realizar copias de seguridad en la memoria: esto está estrechamente relacionado con la concurrencia máxima permitida. Para esto también me gustaría tener un código de autoajuste, pero también es probable que exista una opción de línea de comando.

Para resumir mis puntos anteriores: está planeado y se implementará en algún momento.

Suena bien para mí. Entonces, me gustaría mantener este problema abierto para rastrear esa característica.

Acordado.

Me interesaría este tema también desde la perspectiva del servidor, por lo que no necesariamente poca memoria, pero "todavía no es suficiente". :) Por ejemplo, tengo un servidor de correo con ~ 950GB de datos ( scanned 64173 directories, 2147728 files in 2:41 ) y con 2GB de RAM encontré OOM con restic (corriendo por debajo de ionice -c 3 nice -n 19 ). ¿Existen números conocidos para calcular las necesidades de memoria para restic (por archivo / por GB / ....)? (Me encontré con OOM con restic en todo tipo de VM diferentes, sabía que esas necesidades de antemano harían la vida más fácil, y si hubiera alguna forma de reducir el consumo de memoria, sería genial).

¡Gracias!

Mi experiencia es de alrededor de 4 GB de RAM para un tamaño de repositorio de 1,5 TB (para respaldo). podar requiere aún más (~ 9-10 GB de RAM).

El uso de memoria no depende principalmente del tamaño de los datos en una máquina en particular, sino principalmente del tamaño del repositorio. Por lo tanto, es imposible hacer una copia de seguridad de un archivo de 100 KB en una máquina con 2 GB de RAM (sin intercambio) si el repositorio restante es de ~ 1 TB.

Aquí:

• Construir:
  restic 0.8.3 (v0.8.3-11-gda77f4a2) compiled with go1.9.4 on linux/amd64
• Dimensiones (pero en realidad creo que la mayoría de esos archivos (muchos clones de repositorios, cachés de metadatos, directorios de compilación, etc.) están realmente excluidos y los números informados por restic reflejan la cantidad total):
  118775 directories 829113 files 129.220 GiB
• Uso de memoria: alrededor de 3.8G por ejecución diaria

¿Hay algún progreso en esto? Amo restic, pero mis copias de seguridad ya no se completan debido al agotamiento de la memoria (repositorio de 1.5TB, usa ~ 23G RAM, backend b2). Afaik, actualmente la concurrencia solo se puede modificar modificando la fuente en sí (https://github.com/restic/restic/issues/979#issuecomment-374359647), pero esto no es realmente mantenible.

¿Ha cambiado algo en términos de requisitos de uso de memoria?

También me encuentro con este problema. Sistema de 2GB Repositorio restic de 250GB. Corriendo:

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

(también usando 4/14 para tratar de reducir el uso de memoria de 3/7) toma 1.7G. Puede llevar 10 o 12 horas completar el comando porque el sistema deficiente está cambiando sus cerebros. Además, el sistema es prácticamente inútil para cualquier otra cosa debido al intercambio.

Me gusta el restic pero esto no es sostenible.

¿Alguien puede aclarar cuál es la sugerencia real en este tema? Quiero decir, si el consumo / requisitos de memoria se pueden reducir, ¿por qué no deberíamos hacer eso y, en su lugar, tener un interruptor de línea de comando para permitir el uso de menos memoria?

Supongo que asignar menos espacio, si es posible, significaría que el proceso es más lento, por lo que justificaría no hacer esto de forma predeterminada.

Ya ha habido mejoras con respecto al uso de la memoria y algunas otras están en proceso.
En principio, estoy a favor de la argumentación de @rawtaz de que reducir el uso de memoria permitirá que restic sea utilizable en un campo mucho más amplio de dispositivos.

Dicho esto, por supuesto, existen posibilidades de reducir aún más el uso de la memoria, especialmente el cambio de velocidad. Empecé a trabajar en posibilidades relacionadas con el índice en # 2794

Una solución adecuada para esto probablemente usará un índice de repositorio en disco o permitirá a los clientes cargar solo partes del índice como se discutió en # 1988.