Restic: Réduisez la consommation de mémoire avec l'option de ligne de commande

Hé, merci pour votre intérêt pour restic. Le nombre d'environ 300 Mo de RAM que j'ai mentionné dans l'exposé est utilisé pour deux choses (principalement) :

• calculer scrypt(mot de passe) : les constantes de scrypt sont actuellement codées en dur, et il y a #17 pour ajouter du code qui détermine automatiquement à quel point scrypt devrait être dur pour le système actuel
• avoir plusieurs tampons de blobs/packs à sauvegarder en mémoire : ceci est étroitement lié à la simultanéité maximale autorisée. Pour cela, j'aimerais également avoir un code de réglage automatique, mais une option de ligne de commande est également probable.

Pour résumer mes points ci-dessus : c'est prévu et sera mis en œuvre à un moment donné.

Cela me semble bien. J'aimerais garder ce problème ouvert pour suivre cette fonctionnalité, alors.

D'accord.

Je serais également intéressé par ce sujet du point de vue du serveur, donc pas nécessairement peu de mémoire mais "toujours pas assez". :) Par exemple, j'ai un serveur de messagerie avec ~ 950 Go de données ( scanned 64173 directories, 2147728 files in 2:41 ) et avec 2 Go de RAM, je suis tombé sur OOM avec restic (sous ionice -c 3 nice -n 19 ). Existe-t-il des nombres connus pour calculer les besoins en mémoire pour restic (par fichier/par Go/....) ? (Je suis tombé sur OOM avec restic dans toutes sortes de machines virtuelles différentes, sachant que ces besoins initiaux rendraient la vie plus facile, et s'il y avait un moyen de réduire la consommation de mémoire, ce serait formidable.)

Merci!

Mon expérience est d'environ 4 Go de RAM pour une taille de dépôt de 1,5 To (pour la sauvegarde). prune prend encore plus (~ 9-10 Go de RAM).

L'utilisation de la mémoire ne dépend principalement pas de la taille des données sur une machine particulière, mais principalement de la taille du référentiel. Il est donc impossible de sauvegarder un fichier de 100 Ko sur une machine avec 2 Go de RAM (pas de swap) si le référentiel restic lui-même fait environ 1 To.

Ici:

• Construire:
  restic 0.8.3 (v0.8.3-11-gda77f4a2) compiled with go1.9.4 on linux/amd64
• Dimensions (mais je crois en fait que la majorité de ces fichiers - beaucoup de clones de référentiel, de caches de métadonnées, de répertoires de construction, etc. - sont en fait exclus et les nombres rapportés par restic reflètent le montant total):
  118775 directories 829113 files 129.220 GiB
• Utilisation de la mémoire : environ 3,8 G par exécution quotidienne

Y a-t-il des progrès à ce sujet? J'adore restic, mais mes sauvegardes ne se terminent plus en raison d'un épuisement de la mémoire (référentiel de 1,5 To, utilise ~ 23 Go de RAM, backend b2). Afaik, actuellement, la concurrence ne peut être modifiée qu'en modifiant la source elle-même (https://github.com/restic/restic/issues/979#issuecomment-374359647), mais ce n'est pas vraiment maintenable.

Est-ce que quelque chose a changé en termes d'exigences d'utilisation de la mémoire ?

Je suis également confronté à ce problème. Système de 2 Go Repo restic de 250 Go. Fonctionnement:

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

(en utilisant également 4/14 pour essayer de réduire l'utilisation de la mémoire de 3/7) prend 1,7 Go. Cela peut prendre 10 ou 12 heures pour terminer la commande parce que le système pauvre échange sa cervelle. De plus, le système est à peu près inutile pour autre chose à cause de l'échange.

J'aime le restic mais ce n'est pas durable.

Quelqu'un peut-il clarifier quelle est la suggestion réelle dans ce problème? Je veux dire, si la consommation/les exigences de mémoire peuvent être réduites, pourquoi ne devrions-nous pas simplement le faire et avoir à la place un commutateur de ligne de commande pour permettre d'utiliser moins de mémoire ?

Je suppose qu'allouer moins d'espace, si possible, signifierait que le processus est plus lent, donc cela justifierait de ne pas le faire par défaut ?

Il y a déjà eu des améliorations en ce qui concerne l'utilisation de la mémoire et d'autres sont en cours.
En principe, je suis d' accord avec l'argumentation de

Cela dit, il existe bien sûr des possibilités de réduire davantage l'utilisation de la mémoire, en particulier en échangeant contre la vitesse. J'ai commencé à travailler sur les possibilités liées à l'index dans #2794

Une solution appropriée pour cela utilisera très probablement un index de référentiel sur disque ou permettra aux clients de ne charger que des parties de l'index, comme indiqué dans #1988.