Restic: 명령줄 옵션으로 메모리 소비 줄이기

레스틱에 관심을 가져주셔서 감사합니다. 제가 강연에서 언급한 약 300MiB의 램 수는 (주로) 두 가지 용도로 사용됩니다.

• scrypt(암호) 계산: scrypt에 대한 상수는 현재 하드 코딩되어 있으며 현재 시스템에서 scrypt가 얼마나 어려운지 자동으로 파악하는 코드를 추가하는 #17이 있습니다.
• 메모리에 백업할 블롭/팩 버퍼가 여러 개 있는 경우: 이는 허용되는 최대 동시성과 밀접하게 연결됩니다. 이를 위해 자동 조정 코드도 갖고 싶지만 명령줄 옵션도 가능합니다.

위의 내 요점을 요약하자면: 그것은 계획되어 있고 어느 시점에서 구현될 것입니다.

나에게 좋은 소리. 그런 다음 해당 기능을 추적하기 위해 이 문제를 계속 공개하고 싶습니다.

동의.

서버 관점에서도 이 주제에 관심이 있으므로 메모리가 부족할 필요는 없지만 "아직 충분하지 않습니다". :) 예를 들어 ~950GB의 데이터( scanned 64173 directories, 2147728 files in 2:41 )가 있는 메일 서버가 있고 2GB의 RAM이 있는 OOM에 restic( ionice -c 3 nice -n 19 )이 있습니다. restic(파일당/GB/....당)에 대한 메모리 요구 사항을 계산하는 데 알려진 숫자가 있습니까? (나는 모든 종류의 다른 VM에서 restic으로 OOM을 만났습니다. 이러한 요구 사항이 미리 알려지면 삶이 더 쉬워지고 메모리 소비를 줄이는 방법이 있다면 좋을 것입니다.)

감사 해요!

내 경험은 1.5TB 저장소 크기(백업용)에 대해 약 4GB의 RAM입니다. prune은 훨씬 더 많은 것을 필요로 합니다(~9-10GB의 RAM).

메모리 사용량은 주로 특정 시스템의 데이터 크기가 아니라 저장소 크기에 따라 다릅니다. 따라서 나머지 저장소 자체가 ~1TB인 경우 2GB RAM(스왑 없음)이 있는 시스템에서 100KB 파일을 백업하는 것은 불가능합니다.

여기:

• 짓다:
  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.8G

이에 대한 진전이 있습니까? 제한적이지만 메모리 소진으로 인해 백업이 더 이상 완료되지 않습니다(1.5TB 저장소, ~23G RAM, b2 백엔드 사용). Afaik, 현재 동시성은 소스 자체를 수정해야만 수정할 수 있지만(https://github.com/restic/restic/issues/979#issuecomment-374359647), 이것은 실제로 유지 관리할 수 없습니다.

메모리 사용 요구 사항과 관련하여 변경된 사항이 있습니까?

나는 또한이 문제에 직면 해 있습니다. 2GB 시스템 250GB 저장소. 달리기:

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

(또한 3/7에서 메모리 사용을 줄이기 위해 4/14를 사용) 1.7G가 걸립니다. 잘못된 시스템이 두뇌를 교체하기 때문에 명령을 완료하는 데 10~12시간이 걸릴 수 있습니다. 또한 시스템은 스와핑 때문에 다른 어떤 것에도 거의 쓸모가 없습니다.

나는 소박한 것을 좋아하지만 이것은 지속 가능하지 않습니다.

누군가이 문제의 실제 제안이 무엇인지 명확히 할 수 있습니까? 내 말은, 메모리 소비/요구 사항을 더 작게 만들 수 있다면 왜 그렇게 하지 않고 대신 더 적은 메모리를 사용할 수 있도록 명령줄 스위치가 있어야 합니까?

가능한 경우 더 적은 공간을 할당하면 프로세스가 느려지므로 기본적으로 이 작업을 수행하지 않아도 된다고 가정합니다.

메모리 사용과 관련하여 이미 개선이 있었으며 일부는 파이프라인에 있습니다.
원칙적으로 저는 메모리 사용량을 줄이면 훨씬 더 넓은 분야의 장치에서 restic을 사용할 수 있다는 @rawtaz 의 주장을

그렇긴 하지만, 특히 속도를 위해 거래하는 메모리 사용량을 더 줄일 수 있는 가능성이 물론 있습니다. 나는 #2794에서 인덱스 관련 가능성에 대해 작업하기 시작했습니다.

이에 대한 적절한 솔루션은 디스크에 있는 저장소 인덱스를 사용하거나 #1988에서 논의된 대로 클라이언트가 인덱스의 일부만 로드하도록 허용합니다.