rsync를 사용하여 한 시스템에 탑재된 두 개의 볼륨(1TB)을 동기화하려고 합니다. 아마도 이것이 최선의 접근 방식은 아닐 수도 있지만 시작할 때마다 rsync가 차이점뿐만 아니라 모든 것을 다시 복사하기 때문에 무엇이 잘못될 수 있는지 알아내려고 노력하고 있습니다.
정확한 명령은 다음과 같습니다.
find . -type f|parallel -v -j 24 rsync -ar --progress /dbdata/{} /dbdata2/{}
프로세스를 병렬화하여 최대 복사 속도를 달성하려고 하기 때문입니다.
PS: 이전에 find|mkdir에 의해 생성된 디렉토리/폴더
데비안 제시
또 무엇을 제안해야 합니까? 어떤 아이디어가 있나요?
답변1
기본적으로 rsync는 로컬 복사본을 델타하지 않고 네트워크를 통한 델타만 수행합니다. 이를 추가 -no-W 하거나 재정의 할 수 있습니다 --no-whole-file. --stats발생한 일에 대한 자세한 정보가 표시됩니다. 고정 --block-size=값을 설정하면 고려해야 할 청크 크기를 선택할 수 있습니다.
답변2
병렬화는 작업 속도를 높이는 만병통치약이 아닙니다. 병렬화가 필요함독립적인또는 적어도 느슨하게 결합된 작업입니다. 병렬화는 작업이 리소스를 놓고 (너무 많이) 경쟁하지 않는 경우에만 도움이 됩니다.
rsync는 CPU 바인딩이 아닌 I/O 바인딩이므로 여러 인스턴스를 병렬로 실행해도 큰 이점이 없습니다. 복사 프로세스에 대역폭이 제한되어 있으면 병렬화를 통해 얻을 수 있는 것이 없으며 병렬화 오버헤드 때문에 손실만 있을 뿐입니다. (병렬화에는 시스템이 작업을 전환할 때 항상 오버헤드가 발생합니다. 이점이 비용을 상쇄할 때만 가치가 있습니다.)
대기 시간으로 인해 사용 가능한 대역폭을 포화시킬 수 없는 경우, 즉 rsync가 읽기가 완료될 때까지 기다리는 시간의 상당 부분을 소비하는 경우 병렬화를 통해 이점을 얻을 수 있습니다. 그러나 지연 시간이 너무 길어서 24개 병렬 인스턴스의 이점을 얻지 못할 가능성은 거의 없습니다. 대부분의 디스크 하드웨어에서 병렬 액세스는 비용이 많이 듭니다.이기다. 요청을 병렬화할 수 있는 하드웨어가 있다면 약간의 이점이 있을 수 있지만 어떤 하드웨어도 24개의 병렬 요청을 처리할 수 있을지 의문입니다. 두 가지 예를 사용해 보세요. 추측하지 말고 측정하세요.
증분 복사의 경우 이는 병목 현상이 원본과 대상 사이의 대역폭인 경우에만 최적화됩니다. 매우 빠르게 체크섬을 계산할 수 있는 로컬 rsync가 있고, 체크섬을 매우 빠르게 계산할 수 있는 원격 rsync가 있고, 그 사이에 rsync가 체크섬을 계산하는 데 걸리는 시간보다 데이터를 전송하는 데 훨씬 더 많은 시간이 걸리는 네트워크가 있는 경우, Incremental 사본이 의미가 있습니다. 로컬 파일의 경우 rsync는 체크섬을 계산하기 위해 소스와 대상을 읽어야 합니다. 증분 복사는 쓰기 속도가 읽기 속도와 거의 같은 경우에만 해를 끼칠 수 있습니다. 읽기는 최대 동일한 양의 쓰기만 차단하기 때문입니다. 쓰기가 읽기보다 상당히 느린 경우 증분 복사가 도움이 될 수 있지만 이는 다소 특이한 현상입니다. 강제 증분 전송을 통과할 수 있지만 --no-whole-file이로 인해 복사 속도가 느려지더라도 놀라지 마십시오. 다시 한번 말하지만, 추측하지 마세요.