Restic: 복구가 훨씬 빠를 수 있습니다.

160mbit/sec는 실제로 느리게 보입니다. 나는 1Gbps ftth 연결을 통해 onedrive에서 다운로드하는 작은 macbook pro에서 200Mbps에 가까워지고 있었습니다. 귀하의 시스템 및 저장소에 대한 액세스 없이는 구체적으로 말할 수 없지만 다음은 특정 순서 없이 문제를 좁힐 수 있는 몇 가지 사항입니다.

• 단일 스레드에서 단일 팩 파일을 다운로드하는 데 걸리는 예상 시간. rclone 32x 다운로드 테스트에서 이를 계산할 수 있지만 http 요청 오버헤드도 추정할 수 있도록 curl을 사용하여 개별 팩을 다운로드하는 시간을 알고 싶습니다.
• 복원 중에 S3에서 실제로 얼마나 많은 restic이 다운로드되는지 OS 통계를 확인합니다. 이것은 복원이 개별 팩 파일을 여러 번 다운로드하는지 여부를 알려줍니다(가능하지만 간과하지 않는 한 자주 발생하지 않아야 함).
• S3 동시성 수준은 5개의 연결 로 제한되는 것으로 보입니다. 이것은 위에서 주어진 단일 스레드 속도 추정치를 볼 수 있는 복원 속도를 설명할 수 있습니까? 복원 프로그램과 일치하도록 S3 백엔드 연결 제한을 늘리면 어떻게 됩니까?
• 복원 중 네트워크 사용률을 그래프로 표시하여 간격이나 속도 저하가 있는지 확인합니다.
• 복원에서 해당 364GB 파일을 제외하고 어떤 일이 발생하는지 확인하십시오. 개별 파일은 현재 순차적으로 복원되므로 이 하나의 파일은 평균 다운로드 속도를 크게 왜곡할 수 있습니다.

안녕하세요!

답장을 보내 주셔서 감사합니다. 이것은 파헤치는 것이 흥미로웠다.

tl;dr: s3 연결을 늘리는 것이 핵심이지만 제공하는 성능 향상은 이상하게도 일시적입니다.

1. rclone --transfers 1을 사용하여 단일 디렉토리의 팩(총 3062개 파일, 총 13GB)을 전송하면 233mbit/sec로 실행됩니다. 해당 모드에서 단일 스레드 및 단일 https 연결로만 실행되고 있음을 lsof로 확인했습니다. 최고 속도는 --transfers 32(8.5gbit/sec, 기본적으로 이 i3.8xlarge ec2 인스턴스의 회선 속도)로 달성됩니다. 두 경우 모두 스트라이프 nvme 어레이에 기록합니다.
2. 몇 가지 통계를 수집하게 되어 기쁩니다. 하지만 구체적으로 무엇을 보고 싶습니까? (하지만 필수가 아닐 수도 있으니 아래를 참고하세요)
3. 여기에서 하나의 돌로 두 마리의 새를 죽일 것입니다! 다음 은 복원 중 네트워크 사용률

• 이 PR과 병합된 주식 재고(commit c0572ca15f946c622d9c4009347dc4d6c31cba4c)
• workerCount가 32로 충돌하고 filesWriterCount가 128로 충돌한 restic
• 이전 변경 사항으로 제한 + s3 연결이 32로 증가했습니다.
• 이전 변경 사항과 함께 resitc + s3 연결이 64로 증가했습니다.
• --transfers 32가 있는 rclone 데이터/ 디렉토리 이동

대역폭 번호는 kbps이며 10분에 걸쳐 3초 간격으로 측정되었습니다. restic 실행의 경우, 우리는 restic이 파일을 실제로 복원하기 시작한 _after_ 데이터 수집을 시작했습니다(즉, 시작 시간과 restic이 디렉토리 계층을 재생성하는 실행 시작 시 소비한 시간을 제외합니다. 모든 실행 동안, 인스턴스는 25%를 초과하지 않았습니다.

workerCount를 늘리면 약간의 충돌이 발생하지만 S3 동시성은 실제 승리가 있는 것처럼 보입니다. 그러나 강력하게 시작하는 동안(때로는 rclone 속도에 가까워지기도 함!) 속도가 갑자기 떨어지고 나머지 실행 기간 동안 유지됩니다. restic은 또한 "[경로 수정됨]에 대한 오류 무시: 캐시 용량이 충분하지 않음: 요청된 2148380, 사용 가능한 872640"과 같은 오류를 발생시킵니다. 이 오류는 더 낮은 s3 동시성과 함께 발생하지 않습니다.

보시다시피 rclone 성능은 높게 시작하여 높게 유지되므로 쓰기가 인스턴스의 버퍼 캐시로 이동한 다음 디스크로 플러시될 때 정지되는 상황이 아닙니다. nvme 어레이는 처리량 측면에서 네트워크 파이프보다 빠릅니다.

1. 복원하는 동안 디스크/네트워크 IO를 측정하기 때문에 하나의 큰 파일이 하나의 요인이라고 생각하지 않습니다. 따라서 단일 파일이 완전히 복원되는 데 시간이 걸릴 수 있다는 사실은 우리의 수치에 영향을 미치지 않습니다. 여기를 보고 있습니다.

위의 내용을 감안할 때 합리적인 속도를 얻으려면 S3 동시성을 높이는 것이 필요하지만 성능이 떨어지는 이유(및 캐시 오류와 관련이 있는지 여부)를 파악해야 합니다.

테스트에 사용할 수 있는 빠른 i3 인스턴스와 일부 s3 공간 및 대역폭을 만드는 것이 도움이 된다면 저에게 알려주십시오. 기꺼이 후원해 주십시오.

1. 233mbit/sec 곱하기 32는 7456이며 8.5gbit/sec보다 약간 작습니다. 이상합니다. 단일 스레드 다운로드가 다중 스레드 다운로드의 스트림당 처리량보다 빠를 것으로 예상했습니다. 그러나 이것이 무엇을 의미하는지 확실하지 않습니다.

2. 나는 restic이 동일한 팩을 계속해서 다시 다운로드하지 않는지 확인하려고 했습니다. 제 생각에 그래프는 재다운로드가 문제가 아님을 보여주므로 적어도 지금은 아닙니다. 따라서 더 많은 통계가 필요하지 않습니다.

3. 그래프 스케일을 확인할 수 있습니까? rclone은 "1,000,000kbps"인 경우 "1000000"으로 표시된 줄 주위를 맴돌며, 이는 "1Gbps"를 의미하며 앞서 언급한 "8.5 gbit/sec" 숫자와 일치하지 않습니다.

4. 내가 말했듯이 개별 파일은 순차적으로 복원됩니다. 233mbit/s에서 364GB 다운로드는 약 3.5시간이 소요되며, 팩당 오버헤드와 암호 해독으로 인해 더 오래 걸릴 수 있습니다. 이 모두는 순차적으로 발생합니다. 나머지 복원에 소요되는 시간을 모른 채 3.5시간이 중요하지 않은 것으로 버릴 수 있는지 여부를 알 수 없습니다.

not enough cache capacity 오류의 경우 AveragePackSize 를 저장소에서 가장 큰 팩 파일의 크기로 늘리십시오(얼마나 크나요? btw?) 그리고 캐시 크기를 더 잘 조정하는 방법을 생각해야 합니다. 준비가 되지 않았습니다. 아직 대답.

안녕하세요!

죄송합니다. 그래프의 스케일은 kbit/sec가 아니라 KB/sec입니다. 따라서 첫 번째 행의 1,012,995는 8.1gbit/sec입니다.

파일이 순차적으로 복원되는 것은 이해했지만 단일 파일에 대한 팩 검색에 대한 병렬 처리가 없다는 것은 이해하지 못했습니다. 그것은 당신의 제한 요소가 되기 때문에 큰 파일이 있는 백업의 경우 확실히 약간의 걸림돌입니다. 그런 이유로 여기에 약간의 병렬 처리가 있으면 환상적일 것입니다.

10개의 무작위 버킷을 샘플링할 때 최대 팩 크기는 12MB 바로 아래이고 평균 팩 크기는 4.3MB입니다.

더 많은 작업자와 S3 연결로 인해 (workerCount + 5) * averagePackSize의 packCacheCapacity를 초과할 수 있습니다. 나는 그것을 시도하고 오류가 사라지는지 확인합니다.

더 많은 작업자와 S3 연결로 인해 (workerCount + 5) * averagePackSize의 packCacheCapacity를 초과할 수 있습니다. 나는 그것을 시도하고 오류가 사라지는지 확인합니다.

캐시 크기는 5MB 팩 파일 크기와 workerCount 기준으로 계산됩니다. workerCount 늘리면 캐시 크기가 늘어납니다. 따라서 메모리 누수가 있거나 순수한 우연에 의해 많은 12MB 파일을 캐시해야 하는 복원이 필요합니다. averagePackSize 를 12MB로 올리면 어느 쪽인지 알 수 있습니다.

AveragePackSize가 12로 설정된 캐시 오류가 없습니다.

도움이 될 만한 다른 정보가 있으면 알려주세요! 다시 한번 감사합니다.

복원이 진행됨에 따라 병렬 처리가 손실되는 것처럼 보이고 대용량 파일과 관련이 없는 것 같습니다. 테스트 케이스를 구성하고 다시 보고하겠습니다.

안녕하세요!

세 가지 다른 인공 파일 믹스를 사용하여 프로덕션 파일 믹스에서 보고 있던 성능 저하를 재현하려고 했습니다.

모든 테스트에서 c0572ca15f946c622d9c4009347dc4d6c31cba4c를 S3 연결을 128로, workerCount를 128로, filesWriterCount를 128로, AveragePackSize를 12 * 1024 * 1024로 늘렸습니다.

모든 테스트는 중복 제거의 영향을 피하기 위해 임의의 데이터가 있는 파일을 사용했습니다.

첫 번째 테스트에서는 4,000개의 100MB 파일을 만들고 백업했으며 100개의 디렉터리(총 ~400GB)에 균등하게 분할했습니다. i3.8xlarge 인스턴스의 스트라이프 nvme 볼륨에서 백업 및 복원이 실행되었습니다. 백업 버킷은 인스턴스와 동일한 리전에 위치했습니다(us-west-1).

이 파일 조합을 통해 전체 복원에서 병렬 처리 또는 속도 손실 없이 평균 9.7gbit/sec(!)의 속도를 보았습니다. 이 수치는 rclone 수치와 같거나 그 이상이며 본질적으로 라인 속도입니다. 이는 환상적입니다.

그런 다음 400,000개의 1MB 파일을 생성하고 백업하여 100개의 디렉터리(다시 총 ~400GB)에 균등하게 분할했습니다.

위와 동일한(우수한) 결과입니다.

마지막으로 디렉터리당 10GB 파일 1개로 40개의 디렉터리를 만들었습니다. 여기, 상황이 흥미로워졌습니다.

restic은 S3에 대한 40개의 연결로 40개의 동시 복원만 수행할 수 있기 때문에 이 복원이 약간 느릴 것으로 예상했습니다.

그러나 Restic은 쓰기를 위해 40개 파일을 모두 열고 40개 파일에 동시에 쓰기를 수행하지만 S3에 대한 단일 TCP 연결만 한 번에 40개가 아닌 열린 상태로 유지합니다.

보고 싶은 통계나 도구를 알려주세요.

"빠른" 테스트 중에 128개의 S3 연결이 있는지 확인할 수 있습니까?

예, 있었습니다.

궁금합니다... 대용량 파일 지원은 솔직히 제 우선 순위 목록에서 높지 않지만 앞으로 몇 주 안에 이를 살펴볼 시간이 생길 것입니다. 내가 하기 전에 이것을 파헤치고 싶은 사람이 있다면 알려주세요.

더 많은 테스트를 수행했는데 실제로 파일 크기가 청어인 것처럼 보입니다. AWS 연결 수를 주도하는 것은 파일 수입니다.

4개의 디렉터리에 128개의 10MB 파일이 있는 restic은 128개의 파일 모두에 쓰는 중이더라도 AWS에 대한 6개의 연결만 엽니다.

4개의 디렉토리에 512개의 10MB 파일이 있는 경우 restic은 한 번에 128개의 파일을 열어도 수명 동안 18개의 연결을 엽니다.

4개의 디렉터리에 5,120개의 10MB 파일이 있는 restic은 수명 동안 AWS에 대한 연결을 75개만 열어 한 번에 128개의 파일을 열어둡니다.

이상한!

Go S3 클라이언트가 http 연결을 풀링 및 재사용하지 않았다면 정말 놀랐을 것입니다. 대부분의 경우 동시 작업자 수와 열린 TCP 소켓 사이에는 일대일 상관 관계가 없습니다. 예를 들어 어떤 이유로든 복원이 다운로드된 팩을 느리게 처리하는 경우 동일한 S3 연결을 여러 작업자가 공유합니다.

구현 복잡성의 대부분을 담당하고 여기에 보고된 속도 저하를 일으킬 가능성이 매우 높은 현재 동시 복원 프로그램의 두 가지 속성이 있습니다.

• 개별 파일이 처음부터 끝까지 복원됩니다.
• 진행 중인 파일의 수가 최소로 유지됩니다.

구현은 훨씬 간단하고 메모리를 덜 사용하며 많은 경우에 파일 blob을 순서에 관계없이 작성하고 진행 중인 파일을 원하는 수만큼 허용하는 데 동의하면 훨씬 빠를 것입니다.

단점은 복원이 끝날 때까지 주어진 파일에서 얼마나 많은 데이터가 이미 복원되었는지 알 수 없다는 것입니다. 특히 복원이 충돌하거나 종료되는 경우 혼란스러울 수 있습니다. 따라서 파일 시스템에서 10GB 파일을 볼 수 있습니다. 실제로 파일 끝에 몇 바이트만 기록되어 있습니다.

@fd0 현재 시작부터 끝까지 복원을 개선할 가치가 있다고 생각하십니까? 개인적으로, 나는 그것이 내 부분에 대한 엔지니어링임을 인정할 준비가 되었으며 동의한다면 더 간단한 비순차적 구현을 ​​제공할 수 있습니다.

Restic이 표준 출력으로 복원을 지원하는지 기억나지 않습니다. 그렇다면 분명히 처음부터 끝까지 복원을 유지해야 합니다(특별한 경우일 수 있음).

@ifedorenko 저는 개인적으로 단순화를 선호합니다. 특히 성능 향상과 함께라면 더욱 그렇습니다. 그래도 장단점을 이해하려고 노력하고 있습니다.

단점은 복원이 끝날 때까지 주어진 파일에서 얼마나 많은 데이터가 이미 복원되었는지 알 수 없다는 것입니다.

여기에서 동시에 작성된 수천 개의 파일에 대해 이야기하고 있지 않다면 작성된 바이트에 대한 파일 이름의 맵을 사용할 수 있습니까? 분명히 파일 시스템에서 정보를 사용할 수 있도록 하지는 않지만 진행 보고를 위해 여전히 수행할 수 있습니다. (그리고 중단된 복원을 재개하려면 아마도 파일의 blob과 오프셋에서 null이 아닌 바이트를 확인하는 것뿐일까요? 잘 모르겠습니다.)

Restic이 표준 출력으로 복원을 지원하는지 기억나지 않습니다. 그렇다면 분명히 처음부터 끝까지 복원을 유지해야 합니다(특별한 경우일 수 있음).

나는 그것이 어떻게 작동하는지 확신하지 못합니다. 복원은 여러 파일이기 때문에 어떻게 든 인코딩하고 어떻게 든 분리해야한다고 생각합니다.

여기에서 동시에 작성된 수천 개의 파일에 대해 이야기하고 있지 않다면 작성된 바이트에 대한 파일 이름의 맵을 사용할 수 있습니까?

가장 간단한 구현은 개별 Blob을 쓰기 위해 파일을 열고 닫는 것입니다. 이것이 너무 느린 것으로 판명되면 열린 파일 핸들을 캐싱하고 이미 열린 파일을 선호하도록 팩 다운로드를 주문하는 등 여러 Blob 쓰기를 위해 파일을 열린 상태로 유지하는 방법을 찾아야 합니다.

복원은 이미 어떤 Blob이 어떤 파일에 기록되었고 무엇이 아직 보류 중인지 추적합니다. 이 부분이 많이 바뀔 거라고는 생각하지 않습니다. 진행 상황은 별도의 데이터 구조로 추적되며 변경될 것으로 예상하지 않습니다.

중단된 복원을 재개하려면 파일의 blob과 오프셋에서 null이 아닌 바이트를 확인하는 것뿐일까요?

Resume은 디스크에 있는 파일의 체크섬을 확인하여 여전히 복원해야 하는 Blob을 결정해야 합니다. 복원이 순차적이든 비순차적이든 상관없이 이것이 사실이라고 생각합니다. 예를 들어, resume이 정전으로부터 복구된다면, 정전 전에 모든 파일 블록이 디스크로 플러시되었다고 가정할 수 없다고 생각합니다. 즉, 파일에 간격이 있거나 부분적으로 기록된 블록이 있을 수 있습니다.

@pmkane #2101을 사용해도

전적으로. 이번 주에 여행을 가지만 가능한 한 빨리 테스트하고 다시 보고할 것입니다.

@ifedorenko 나는 이 PR을 시도했고

짐(, 3172070, 0) 반환된 오류, 12.182749645s 이후 재시도: EOF

마스터는 잘 복원됩니다.

내 복원 명령은 다음과 같습니다.

/usr/local/bin/restic.outoforder -r s3:s3.amazonaws.com/[redacted] -p /root/.restic_pass 복원 [snapshotid] -t .

디버그에 도움이 되도록 제공할 수 있는 추가 정보를 알려주십시오.

얼마나 많은 동시 S3 다운로드 요청을 허용합니까? 128이라면 32로 제한할 수 있습니까(우리가 알고 있는)?

준관련... 실제 저장소에 색인 파일이 몇 개 있는지 아십니까? 메모리 복원기에 필요한 양을 추정하려고 합니다.

연결 제한을 지정하지 않았으므로 기본적으로 5로 설정되어 있다고 가정합니다.

-o s3.connections=2 및 -o s3.connections=1에서 동일한 오류가 발생합니다.

현재 index/ 폴더에 85개의 인덱스 Blob이 있습니다. 총 크기는 745MB입니다.

흠. 오늘 나중에 컴퓨터에 도착하면 다시 살펴보겠습니다. Btw, "returned error, retrying"은 오류가 아닌 경고이므로 복원 실패와 관련이 있거나 그냥 red herring일 수 있습니다.

어떻게 놓쳤는지 확실하지 않습니다... 대부분의 경우 복원 프로그램이 백엔드에서 모든 팩 파일을 완전히 읽지 않았습니다. 지금 수정해야 합니다. @pmkane 테스트를 다시 시도할 수 있습니까?

소용돌이를 줄게!

이 수정으로 파일이 성공적으로 복원되었음을 확인했습니다. 지금 성능을 테스트 중입니다.

안타깝게도 마스터보다 느린 것 같습니다. 모든 테스트는 위에서 설명한 i3.8xlarge 인스턴스에서 실행됩니다.

workerCount가 8(기본값)인 경우 잘못된 분기가 86mbit/sec로 복원되었습니다.

workerCount가 32로 증가하면 평균 160mbit/sec로 조금 더 나아졌습니다.

이 분기의 CPU 사용률은 마스터보다 훨씬 높지만 두 경우 모두 인스턴스 CPU를 최대로 사용하지 않습니다.

일화에 따르면 복원 ​​UI는 마치 어딘가에서 잠금을 놓고 경쟁하는 것처럼 무언가가 "고정"되어 있는 것처럼 보입니다.

자세한 내용, 프로파일링 또는 복제할 테스트 인스턴스를 제공하게 되어 기쁩니다.

확인을 위해 복원자 및 s3 백엔드 작업자 수를 모두 32로 설정했습니까?

관찰한 행동을 설명할 수 있는 몇 가지 생각:

• 개별 파일에 대한 쓰기는 여전히 직렬화됩니다. 나는 이것이 빠른 대상 파일 시스템에서 문제가 되지 않을 것이라고 _추측_했지만 결코 측정하지 않았습니다.
• 각 BLOB 주변의 파일 열기/닫기는 확실히 복원기 오버헤드에 기여합니다. macos에서 이것을 측정했을 때 ~70초 동안 "파일 열기, 1바이트 쓰기, 파일 닫기"를 100,000번 할 수 있었으며, 이는 100,000 blob을 쓰는 오버헤드에 가깝습니다. 테스트는 정말 간단했고 실제 오버헤드는 훨씬 더 높을 수 있습니다.
• 현재 높은 CPU 사용률에 대한 그럴듯한 설명이 없습니다. 비순차 구현은 각 blob을 한 번만 해독하며(마스터는 각 대상 파일에 대해 blob 암호를 해독함) 마스터에 비해 부기가 훨씬 적습니다. 아마도 "희박한" 파일 쓰기는 실제로 희박하지 않고 Go 또는 OS가 CPU를 많이 사용하는 작업을 수행해야 합니다. 잘 모르겠어.

이봐 거기!

좋아요. workerCount는 internal/restorer/filerestorer.go에서 8 또는 32로 설정되었고 -o s3.connections=32는 두 경우 모두 restic cli를 통해 전달되었습니다.

다음은 순서가 잘못된 분기가 8명의 작업자로 파일을 복원하는 동안 추적 데이터의 최상위 보기입니다.

작업자가 자주 발생하는 상당한(>500-1000ms) 일시 중지가 있는 것 같습니다.

나는 이것에 더 많은 시간을 할애하기로 결정하고 4KiB 블록에서 10GiB 임의 바이트를 생성하는 간단한 독립형 테스트를 작성하여 시작했습니다. 내 목표는 내 시스템이 바이트를 이동하는 속도를 평가하는 것이었습니다. 놀랍게도 이 테스트는 내 macbook pro(2018, 2.6GHz Intel Core i7)에서 실행하는 데 18.64초가 걸렸습니다. 이는 ~4.29 Gigabits/s 또는 10G 이더넷이 할 수 있는 것의 약 절반으로 해석됩니다. 그리고 이것은 암호화나 네트 또는 디스크 I/O가 없습니다. 그리고 저는 Xoshiro256** prng를 사용하고 있었습니다. math/rand 는 약 2배 더 느렸으며, 이는 물론 요점에서 완전히 벗어났습니다. 요점은 복원 프로그램이 10G 네트워크를 포화시키기 위해 여러 스레드에서 Blob을 처리해야 하므로 다중 스레드 net i/o 자체로는 충분하지 않다는 것입니다.

그리고 재미를 위해 비교 가능한 Rust impl은 3.1초 만에 10GiB의 임의 바이트를 생성하고 Java는 10.77초 만에 생성합니다. 그림을 이동 :-)

흥미로운 테스트!

나는 restic이 현재 가장 큰 파일을 복원하는 데 걸리는 시간에 따라 속도가 제한된다는 것을 이해합니다.

그러나 지금은 restic이 여기에서 보는 160mbit/sec보다 훨씬 빠르게 단일 파일을 복원할 수 있다는 것을 알고 있기 때문에 이것이 우리의 차단기가 아닙니다.

마스터와 이 분기에서 현재 최상의 시나리오를 얻기 위해 빠른 SSD와 S3에 10MB 파일로 구성된 100GB 테스트 리포지토리를 구성하고 몇 가지 숫자를 실행하겠습니다.

안녕하세요, 매개변수를 사용하여 작업자 수를 변경하거나 코드에서 직접 수행해야 하는 방법이 있습니까? 우리는 또한 느린 복원 문제를 가지고 있으며 우리가 가지고 있는 것을 어떻게든 개선하고 싶습니다... 이 부분을 개선하는 데 도움이 되는 테스트에 기여할 수 있는지 알려주세요!

감사 해요!

@robvalca 어떤 백엔드를 사용합니까? rclone 이 저장소를 대상 시스템에 얼마나 빨리 복사합니까? 정지 복원 속도는 무엇입니까?

지금 당장은 무슨 일이 일어나고 있는지 잘 모르겠습니다. 따라서 로컬에서 문제를 재현하는 데 사용할 수 있는 테스트 리포지토리와 단계를 제공할 수 있다면 정말 유용할 것입니다("테스트 리포지토리"란 데이터 부탁드립니다).

@ifedorenko 우리는 S3(ceph+radosgw)를 백엔드(저희가 관리)로 사용하고 있습니다. rclone을 사용하여 repo를 복사하려고 시도했으며 결과는 다음과 같습니다.

rclone 복사 -P 원격:cboxback-aabbcc/ /var/tmp/restic/aabbcc/
전송: 127.309G / 127.309GB, 100%, 45.419MBytes/s, ETA 0s
오류: 0
확인: 0 / 0, -
이전: 25435 / 25435, 100%
경과 시간: 47m50.2s

"stock" restic 0.9.4를 사용하여 repo를 복원하는 데 ~8시간이 걸렸습니다. 두 경우 모두 32개의 S3 연결과 동일한 대상 호스트를 사용하고 있습니다. 이 포럼 스레드 에 조금 더 많은 정보를 넣었습니다.

나는 당신이 테스트 할 수 있도록 repo를 준비하고 준비가되면 알려 드리겠습니다.
많은 도움을 주셔서 감사합니다!

@robvalca 내 out-order-restore 분기를 사용하여 복원을 시도할 수 있습니까? 분기는 매우 큰 파일의 복원 성능을 개선해야 하며, 이는 귀하가 직면한 문제인 것 같습니다.

분기가 복원 성능을 향상시키지 않으면 테스트 리포지토리를 공개 s3 버킷에 업로드하고 여기에 버킷 이름과 리포지토리 암호를 게시하십시오.

@pmkane 다수의 동일하거나 거의 동일한 파일을 복원할 수 있습니까? 그것이 노동자들 사이의 논쟁을 설명할 것이라고 생각합니다.

편집: 실제로 최신 #2101을 사용하여 복원 성능 테스트를 다시 시도할 수 있습니까? 동일한 파일에 대한 동시 쓰기 및 여러 파일에 대한 동일한 Blob을 더 잘 처리해야 합니다.

@ifedorenko , 지금은 주문 외 버전이 훨씬 좋습니다! 내가 rclone으로 가지고 있는 것에 더 가까운 1시간도 채 걸리지 않았습니다. 내 테스트에서 추출하여 유용하게 사용할 수 있는 몇 가지 설명(첨부된 플롯도 참조하세요!):

• 정상적인 0.9.4 에서 프로세스는 200MB/sec 최고점으로 더 빠르게 시작되며 S3 측에서 초당 거의 50 requests 얻습니다. 몇 분 후에 성능 저하가 발생하고 나머지 프로세스 동안 요청이 1 정도로 줄어들고 속도는 ~ 5MB/sec 입니다.
• "ooo" 버전의 경우 전송 속도는 40MB/sec 및 ~ 8 S3 요청이 모든 프로세스 동안 안정적입니다.
• 내가 알아차린 또 다른 사실은 S3 연결을 늘려도 거의 개선되지 않는다는 것입니다. 이것이 예상되는 것입니까?

32개의 연결:

Created 2197 directories, listed 171.141 GiB in 20930 files
Restored 171.136 GiB in 170258 files

real    57m54.588s
user    229m25.229s
sys 6m51.763s

64개 연결

real    53m13.876s
user    242m57.081s
sys 7m12.455s

• 마지막으로 다른 저장소(51G, 1.3M 작은 파일, 많은 중복)로 테스트를 수행했으며 여전히 0.9.4보다 훨씬 빠릅니다.

0.9.4

real    16m6.966s
user    25m4.116s
sys 4m19.424s

0.9.4-ooo:

real    8m14.375s
user    14m30.107s
sys 3m41.538s

따라서 대용량 파일을 개선할 뿐만 아니라 모든 경우를 개선합니다!!

그리고 btw, 복원의 새로운 진행률 보기가 좋습니다!! 8)

다른 테스트를 하고 싶다면 알려주세요.

감사 해요!

피드백을 주셔서 감사합니다. @robvalca , 매우 유용합니다.

• 내가 알아차린 또 다른 사실은 S3 연결을 늘려도 거의 개선되지 않는다는 것입니다. 이것이 예상되는 것입니까?

죄송합니다. 동시 복원 작업자 수를 늘리려면 코드를 변경해야 한다는 점을 잊어버렸습니다. 현재 8로 하드코딩되어 있습니다.
https://github.com/ifedorenko/restic/blob/099f51c01c189a84b96be86ce6be61a45e3705fc/internal/restorer/filerestorer.go#L22

다른 테스트를 하고 싶다면 알려주세요.

https://github.com/restic/restic/issues/2074#issuecomment -443759511의 앞부분에서 언급한 순서가 잘못된 복원 중에 명백한 작업자 경합을 일으키는 원인이 무엇인지 아직 모릅니다. 이 특정 커밋을 테스트할 수 있습니까?
https://github.com/ifedorenko/restic/commit/d410668ce3a8c7284d86a2b06bf42a0e654d43bc? 리포지토리에서 경합을 관찰하면 이는 pmkane의 데이터에만 국한되지 않으며 최근 변경 사항으로 경합이 수정되었음을 의미합니다.

도움을 주셔서 다시 한 번 감사드립니다.

안녕하세요 여러분 -- 여전히 이것을 모니터링하고 있지만 절대적으로 늪에 빠져 있습니다. 이번 주말에 확인하고 ifedorenko@d410668로 계속 번식할 수 있는지 확인하겠습니다

@ifedorenko 감사합니다. 32명의 작업자와 함께 프로세스가 30분으로 훨씬 빨라져서 좋은 결과입니다. 또한worker/s3.connections를 64/64, 128/128로 늘리려고 시도했지만 거의 동일한 결과를 얻는 개선 사항이 없습니다. 어쨌든 현재 결과에 만족합니다.

나는 또한 당신이 나를 가리킨 https://github.com/ifedorenko/restic/commit/d410668 버전을 시도했고 여기에 추적의 스크린샷이 있습니다. 나는 이런 종류의 도구에 대한 경험이 많지 않지만 @pmkane 결과와 비슷한 것 같습니다. 8명의 작업자와 -o s3.connections=32

@robvalca 그래서 ifedorenko@d410668 은 렸죠 ? 이것은 좋은 소식입니다. 알려진 모든 문제를 해결했을 가능성이 큽니다. 업데이트 해주셔서 감사합니다.

@ifedorenko 아니요, 언급하는 것을 잊었습니다. 동일한 수의 작업자(8) 및 S3.connections(32)를 사용하는 지점장(순서 없음)과 성능이 거의 동일합니다. 둘 다 ~55m가 소요되었으며, 이는 rclone(~47m)으로 리포지토리를 전송하는 시간과 일치합니다.

다른 매개변수로 테스트하고 싶다면 알려주세요 ;)

사용 사례에서 성능 문제의 원인을 찾았습니다. 대용량 파일의 복원 성능은 특정 파일 크기를 초과하면 비선형적입니다.

테스트를 위해 S3에서 새 리포지토리를 만든 다음 임의의 데이터가 포함된 6개의 파일을 리포지토리에 백업했습니다. 파일 크기는 1, 5, 10, 20, 40 및 80GB였습니다.

이전 테스트와 마찬가지로 테스트는 i3.8xlarge 인스턴스에서 실행되었으며 빠른 스트라이프 SSD에서 백업 및 복원이 수행되었습니다.

백업 시간은 예상대로 선형적이었습니다(8, 25, 46, 92, 177, 345초).

그러나 복원 시간은 다음과 같았습니다.

1GB, 5초
5GB, 17초
10GB, 33초
20GB, 85초
40GB, 256초
80GB, 807s

따라서 대용량 파일 및 복원 성능에 이상한 일이 발생합니다.

버킷의 이름은 pmk-large-restic-test이고 버킷과 해당 콘텐츠는 공개됩니다. us-west-1에 있고 나머지 repo 비밀번호는 password입니다.

파일의 스냅샷 ID는 다음과 같습니다.

1GB: 0154ae25
5GB: 3013e883
10GB: 7463efa8
20GB: 292650c6
40GB: 5acb4bee
80GB: d1b7e323

내가 제공할 수 있는 더 많은 데이터가 있으면 알려주세요!

@pmkane https://github.com/ifedorenko/restic/tree/out-order-restore 분기의 최신 헤드를 사용했는지 확인할 수 있습니까? ?

그래, 내가 했어. 언급하지 못해 죄송합니다.

(ead78b3을 사용하여 모든 실행에서 32개의 작업자와 32개의 s3 연결 사용)

해당 버킷에 액세스하기 위해 특별한 작업을 수행해야 하는지 알고 있습니까? 이전에 공개 버킷을 사용한 적이 없으므로 내가 잘못하고 있는지 또는 사용자가 액세스 권한이 없는지 확실하지 않습니다. (내 팀의 버킷에 잘 액세스할 수 있으므로 내 시스템이 일반적으로 s3에 액세스할 수 있음을 알고 있습니다.)

@ifedorenko 야,

죄송합니다. 공개 버킷 정책을 적용했지만 버킷 자체의 객체를 업데이트하지 않았습니다. 지금 액세스할 수 있어야 합니다. 읽기 권한만 부여했으므로 --no-lock을 사용해야 합니다.

예. 지금 저장소에 액세스할 수 있습니다. 오늘 밤 나중에 가지고 놀 것입니다.

그리고 테스트가 도움이 되거나 더 쉬운 경우 동일한 파일을 고속 SSD의 리포지토리로/에서 복원할 때 유사한 성능 특성을 확인하여 S3를 방정식에서 제외합니다.

@pmkane 로컬에서 문제를 재현할 수 있으며 해당 버킷에 더 이상 액세스할 필요가 없습니다. 이것은 매우 유용했습니다. 감사합니다.

@ifedorenko , 환상적입니다. 버킷을 삭제하겠습니다.

@pmkane 시간이 있을 때 최신 out-order-restore 브랜치를 다시 시도하십시오. ec2에서 이것을 테스트할 시간이 없었지만 내 맥북 복원은 디스크 쓰기 속도에 의해 제한되는 것으로 보이며 지금은 rclone과 일치합니다.

@ifedorenko , 그것은 매우 유망하게 들립니다. 지금 시험을 치르고 있습니다.

@ifedorenko , 빙고.

파일 크기가 혼합된 133GB에 해당하는 Blob(최대 크기는 78GB)을 단 16분 만에 복원했습니다. 이전에는 이 복원에 하루 중 더 많은 시간이 걸렸을 것입니다. 나는 우리가 restoreWorkers의 수를 가지고 노는 것으로 이것을 더 빨리 얻을 수 있다고 생각하지만, 현재로서는 충분히 빠릅니다.

이 작업에 대한 귀하의 노력에 감사드립니다!

그리고 후세를 위해: 우리의 복원 성능은 8->16에서 두 배, 다시 16->32 복원 작업자에서 두 배입니다. 32->64는 32 위에 ~50% 범프에만 적합하며 이 시점에서 약 3gbit/sec로 복원합니다. rclone과 거의 동등합니다.

restic에서 최고의 성능을 추출하는 데 필요한 구성의 양을 최소화하려는 욕구가 있다는 것을 알고 있지만, 이것은 특히 큰 파일 세트를 가진 사용자에게 충분히 큰 점프이므로 다음을 지정할 수 있으면 좋을 것입니다. 런타임에 작업자 수

복원이 여전히 최대 유선 속도를 얻을 수 없는 이유를 잘 모르겠습니다. 중복 Blob 해시 검사가 있으므로 책임이

시도해 보겠습니다.

안녕하세요 여러분, 최신 pull request #2195를 사용하여 몇 가지 테스트를 실행했으며 성능이 계속 향상되고 있습니다!

(20k 작은 파일, 2x70G 파일, 총 170G)

8w_32c

real    27m46.185s
user    24m31.290s
sys 3m55.153s

32w_32c

real    15m30.904s
user    24m1.982s
sys 4m55.128s

64w_32c

real    18m37.566s
user    23m33.684s
sys 5m3.024s

64w_64c

real    17m12.314s
user    23m44.318s
sys 4m43.090s

32w에서 64w로 성능이 떨어지는지 확실하지 않습니다(여러 번 테스트했으며 합법적인 것 같습니다). 그 과정에서 그래프를 몇 개 첨부했는데, 성능 저하나 한계가 있는 것 같은데, 이 정도는 되어야 할까요? 예를 들어 64명의 작업자가 있는 경우 프로세스는 6gbit/sec에서 시작하지만 그 이후에는 프로세스가 끝날 때까지 1gbit/sec 미만으로 떨어집니다(이는 큰 파일을 처리하는 시간에 해당한다고 생각합니다). 첫 번째 스크린샷은 32w, 32c이고 두 번째 스크린샷은 64w, 32c입니다.

나는 또한 @pmkane에 동의합니다. 명령줄에서 작업자 번호를 변경하는 것이 유용할 것입니다. 가능한 한 빨리 데이터를 복원하려는 재해 복구 시나리오에 매우 유용합니다. 동료 #2178이 이에 대한 풀 리퀘스트를 했습니다.

어쨌든 개선된 점에 정말 감동했습니다! 감사합니다 @ifedorenko

++. @ifedorenko에게 감사드립니다. 이것은 게임을 완전히 바꾸는 것입니다.

자세한 보고서 @robvalca에 감사드립니다. AWS(또는 GCP 또는 Azure) 또는 로컬에서 내가 할 수 있는 테스트 리포지토리를 제공할 수 있습니까? 내 테스트에서 큰 파일 복원 속도 저하를 보지 못했고 무슨 일이 일어나고 있는지 알고 싶습니다.

@pmkane 나도 런타임에 이러한 것들을 구성하고 싶습니다. 내 제안은 --option 옵션을 만들어 일반 플래그나 명령을 어지럽히지 않도록 하는 것이지만, 특이한 상황을 실험하거나 조정하려는 '고급' 사용자를 위한 것입니다. 문서화할 필요도 없으며 --option experimental.fooCount=32 와 같이 신뢰할 수 없음을 분명히 하는 이름을 지정할 수 있습니다.

안녕하세요 @ifedorenko , s3.cern.ch/restic-testrepo 정크 데이터로 공개 저장소를 만들었습니다. 그것은 내가 시도한 것과 거의 같은 모양이며(많은 작은 파일과 몇 개의 매우 큰 파일) 또한 이것(첨부된 플롯)에서 동일한 동작을 재현할 수 있습니다. 저장소의 비밀번호는 restic 입니다. 액세스하는 데 문제가 있으면 알려주십시오.

@robvalca 테스트 저장소를 사용하여 문제를 재현할 수 없습니다. AWS(us-east-2, s3 repo, i3.4xlarge 2x nvme raid0 target)에서 32명의 작업자와 32개의 연결을 사용할 때 안정적인 0.68GB/s의 복원 속도를 봅니다(총 복원 시간 6분 20초). 대상 시스템은 10GB/s를 오랫동안 유지할 수 없습니다. 추측할 수 있다면 적어도 이 문제를 추가로 해결하려면 먼저 확인해야 합니다.

@pmkane 흥미롭게도 나는 당신의 관찰을 확인할 수 없습니다. 위에서 언급했듯이 최신 out-of-order-restore-no-progress 분기를 사용하여 0.68GB/s의 복원 속도를 보고(복원은 CPU 바운드로 보임), 중복 Blob 해시 검사를 비활성화하면 0.81GB/s를 봅니다(복원이 CPU로 보이지 않음). 경계). "최대 10Gbps" 네트워크가 얼마나 더 빨라질 수 있을지는 모르겠지만, 우리는 이미 "수익 감소" 영역에 많이 진입했다고 생각합니다.

@ifedorenko 나는 진심으로 다시 동의합니다. 수익 감소. 우리에게는 충분히 빠른 속도입니다.

@ifedorenko 흥미

병합되는 상태가 궁금합니다. @cbane 의

곧... 👀

#2195가 병합되었으므로 닫습니다. 이 문제에 대한 세부 사항이 해결되지 않은 경우 자유롭게 다시 열 수 있습니다. 이 호에서 논의된 유형이 아닌 개선해야 할 사항이 여전히 있는 경우 새 호를 여십시오. 감사 해요!