500ms가 넘는 서버에서 멀어 지도록 MB 단위의 파일로 테라 바이트 단위의 데이터가 있다고 가정 해 봅시다.
TCP의 특성으로 인해 아래 명령은 4Mbit / s 홈 ADSL 연결 또는 기가비트 회선과 같은 사용 가능한 대역폭의 일부에서만 작동합니다.
rsync -avP --remove-source-files source.host:path/to/source/ path/to/dest
내가 사용하고 --remove-source-files내가 여러 호스트 및 대상 디렉토리를 사용해야 할 수도 있기 때문에,이 디렉토리는 항상 이전에 성공적으로 수신 된 모든 것을 포함 할 수 없습니다, 소스 디렉토리는 대기입니다.
위의 여러 명령 인스턴스를 동시에 실행하는 것이 안전하고 효과적입니까?
답변:
아니요, 실제 동작은 예측할 수 없지만 여러 인스턴스가 동시에 동일한 파일을 복사하려고 시도하고 대역폭이 낭비되어 나쁜 일이 발생할 수 있습니다.
그러나 교활한 사용 --include과 --exclude여기에서 편리 할 수 있습니다.
rsync -avP \
--include '*/' --include '[a-g]*' --exclude '*' \
source.host:path/to/source/ path/to/dest/
이 명령은 문자 a로 시작하는 파일 만로 보냅니다 g. 알파벳의 다른 부분에 대해 병렬 전송을 설정할 수 있습니다.
마지막으로 모든 전송이 완료되면 원래 rsync 명령을 다시 실행하여 ( --remove-source-files내 명령 에서 벗어난 것을 유의하십시오 ) 발생하는 모든 이상이 완화되고 원래 필터에서 놓친 파일 (도트 파일)을 확인하십시오 아마도?)도 이전됩니다.
또한, 항상 최종 슬래시를 소스 및 대상 디렉토리 (예 :)에 path/to/dest/두거나 rsync예상 한대로 수행하지 않을 수 있습니다!
그러나 rsync는 파일을 처음으로 복제하는 가장 효율적인 방법은 아닙니다. 특히 대기 시간이 길 때 (대부분의 후속 업데이트 통과를위한 것입니다).
tar데이터를 ssh다음 으로 스트리밍하는 데 사용 하는 것이 훨씬 좋습니다 .
ssh source.host tar -C path/to/source/ cfj - . | tar -C path/to/dest/ xfj -
그러면 tar 파일이 디스크에 닿지 않고 데이터를 패키지화하여 연속 스트림으로 압축하고, ssh터널을 통해 파이프 로 연결 tar하고, 로컬 끝으로 다시 연결하고, 한 번의 명령으로 파일로 다시 확장합니다.
단점은 연결이 끊어지면 쉽게 다시 시작할 수 없다는 것입니다.
타르에는 --exclude옵션 도 있지만 ( --include)는 아니므로 필요한 경우 비슷한 방식으로 스트림을 병렬화 할 수 있습니다. 다시, 당신은 아마 전송을 확인하기 위해 rsync로 마무리해야합니다.
따로 : "TCP의 특성"은 여기서 문제 가 되지 않습니다 . TCP는 정상적인 대기 시간에 링크를 포화시켜야하는 슬라이딩 윈도우 구성표를 사용하며, 그렇지 않으면 회전 하는 노브가 있습니다.
그러나 rsync의 특성은 파일을 전송하기 전에 각 파일에 대해 약간의 채팅을 수행해야하며 대기 시간이 줄어든다는 점입니다 (구현시 파이프 라이닝을 사용하여이를 최소화 함).
링크를 포화시키지 않으면 가장 먼저 시도해야 할 것은 방정식에서 rsync를 가져 오는 것입니다 ( scp적절히 큰 파일이 가능합니다). 그래도 문제가 해결되지 않으면 CPU 사용량을 확인하십시오. 압축 및 암호화에 병목 현상이있을 수 있습니다. Netcat (또는 구식 FTP)을 통해 일반 데이터를 전송할 수없는 경우 TCP를 조정해야합니다. 또한 pingTCP를 망칠 수 있으므로 패킷 손실을 확인하십시오 . 마지막으로, 체인에서 가장 느린 링크가 귀하의 링크가 아닐 수도 있습니다.