rsync가 NFS보다 빠른 이유는 무엇입니까?

며칠 전에 나는 다소 이상하다고 생각했다. 동일한 데이터를 복사하고 나중에라는 NFS 마운트로 rsync를 실행했습니다 /nfs_mount/TEST. 이것은 /nfs_mount/TEST호스팅 /에서 내 보낸 nfs_server-eth1. 두 네트워크 인터페이스의 MTU는 9000이며, 스위치 간 점보 프레임도 지원합니다. 내가 rsync -av dir /nfs_mount/TEST/네트워크 전송 속도 X MBps를 얻습니다. 내가 rsync -av dir nfs_server-eth1:/nfs_mount/TEST/네트워크 전송 속도를 2X MBps 이상으로 얻는 다면 . 내 NFS 마운트 옵션은 nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp입니다.

결론 : 두 전송 모두 동일한 네트워크 서브넷, 동일한 와이어, 동일한 인터페이스, 동일한 데이터 읽기, 동일한 디렉토리에 쓰기 등을 거치게됩니다. 차이점은 NFSv3을 통한 것이고 다른 하나는 rsync를 통한 것입니다.

클라이언트는 Ubuntu 10.04, 서버 Ubuntu 9.10입니다.

어떻게 rsync가 훨씬 빠릅니까? NFS를 그 속도와 일치시키는 방법?

감사

편집 : rsync를 사용하여 NFS 공유 또는 SSH를 NFS 서버에 쓰고 로컬로 씁니다. rsync -av명확한 목적지 디렉토리로 시작하여 두 번 . 내일 나는 평범한 사본으로 시험 할 것이다.

Edit2 (추가 정보) : 파일 크기는 1KB-15MB입니다. 파일이 이미 압축되어 있으므로 성공하지 않고 더 압축하려고했습니다. 나는 그것에서 tar.gz파일을 만들었습니다 dir. 패턴은 다음과 같습니다.

• rsync -av dir /nfs_mount/TEST/ = 가장 느린 전송;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= 점보 프레임이 활성화 된 가장 빠른 rsync; 점보 프레임이 없으면 약간 느리지 만 여전히 NFS에 직접 전송하는 것보다 훨씬 빠릅니다.
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = 그것의 non-tar.gz와 거의 같습니다;

함께 테스트 cp및 scp:

• cp -r dir /nfs_mount/TEST/=보다 약간 빠르지 rsync -av dir /nfs_mount/TEST/만 여전히 상당히 느립니다 rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
• scp -r dir /nfs_mount/TEST/= 전체적으로 가장 빠름, 약간 극복 됨 rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = 그것의 non-tar.gz와 거의 같습니다;

결론 :이 결과에 근거 :이 테스트의 경우 tar.gz 큰 파일 또는 많은 작은 파일을 사용하는 경우 큰 차이가 없습니다. 점보 프레임을 켜거나 끄는 것도 거의 차이가 없습니다. cp그리고 scp빨리 각각의보다 rsync -av등가물. 내 보낸 NFS 공유에 직접 쓰는 것은 사용 된 방법에 관계없이 SSH를 통해 동일한 디렉토리에 쓰는 것보다 훨씬 느립니다 (최소 2 회).

이 경우 차이점 cp과 rsync관련이 없습니다. 나는 시도하기로 결정 cp하고 scp2 배의 차이를 - 그들은 같은 패턴을 보여주고 그들이 할 경우 바로 볼 수 있습니다.

내가 사용 rsync하거나 cp두 경우 모두 NFS가 SSH를 통해 동일한 명령의 전송 속도에 도달하지 못하게하는 이유를 이해할 수 없습니다.

SSH를 통해 같은 장소에 쓰는 것보다 NFS 공유에 쓰는 속도가 2 배 느린 이유는 무엇입니까?

Edit3 (NFS 서버 / etc / exports 옵션) : rw,no_root_squash,no_subtree_check,sync. 클라이언트의 / proc / mounts는 다음을 보여줍니다 : nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

다들 감사 해요!

전송 속도는 느리지 않지만 쓰기 대기 시간이 길어질 수 있습니다. 동기화 대신 NFS 공유 비동기를 마운트하고 속도 차이가 없는지 확인하십시오. ssh를 통해 rsync하면 원격 rsync 프로세스가 비동기 적으로 (빠르게) 기록합니다. 그러나 동기식으로 마운트 된 nfs 공유에 쓸 때는 쓰기가 즉시 확인되지 않습니다. NFS 서버는 쓰기에 성공했다는 확인을 NFS 클라이언트에 보내기 전에 디스크 (또는 컨트롤러 캐시 일 가능성이 큼)에 도달 할 때까지 기다립니다.

'비동기'가 문제를 해결하는 경우 쓰기 도중 NFS 서버에 문제가 발생하면 디스크의 데이터가 일치하지 않을 수 있습니다. 이 NFS 마운트가이 데이터 (또는 다른 데이터)의 기본 스토리지가 아닌 한 괜찮을 것입니다. 물론 rsync-over-ssh가 실행되는 동안 / 후에 nfs 서버의 플러그를 뽑으면 동일한 보트에있을 수 있습니다 (예 : rsync return 'finished', nfs server crash, 쓰기 캐시의 커밋되지 않은 데이터가 손실 됨) 디스크에 데이터가 일치하지 않습니다).

테스트 (새 데이터를 동기화하는) 문제는 아니지만 ssh를 통한 rsync는 체크섬을 계산하고 필요한 파일 목록을 생성하는 동안 단일 바이트가 전송되기 전에 원격 서버에서 CPU 및 IO를 많이 요구할 수 있음에 유의하십시오. 업데이트되었습니다.

NFS는 공유 프로토콜이며 Rsync는 파일 전송에 최적화되어 있습니다. 파일에 대한 공유 액세스를 제공하는 대신 가능한 빨리 파일을 복사하는 것이 목표 라는 우선 순위 를 알고있을 때 수행 할 수있는 많은 최적화가 있습니다 .

도움이 될 것입니다 : http://en.wikipedia.org/wiki/Rsync

Rsync는 파일간에 변경된 비트 만 전송하는 파일 프로토콜입니다. NFS는 원격 디렉토리 파일 프로토콜로 SMB와 같은 방식으로 모든 것을 처리합니다. 이 둘은 다르며 목적이 다릅니다. Rsync를 사용하여 두 NFS 공유간에 전송할 수 있습니다.

이건 재미 있네. 고려하지 않았을 가능성은 전송중인 파일의 내용 / 유형입니다.

작은 파일 (예 : 개별 파일의 전자 메일)이 많은 경우 전체 MTU를 사용하지 않아 NFS 효율성이 저하 될 수 있습니다 (TCP over UDP에서는 가능성이 낮을 수 있음).

또는 압축률이 높은 파일 / 데이터, 빠른 CPU 및 CPU 속도 (*)가없는 네트워크가있는 경우 ssh 링크를 통한 암시 적 압축만으로 속도를 높일 수 있습니다.

세 번째 가능성은 파일 (또는 파일의 한 버전)이 대상에 이미 존재한다는 것입니다. 이 경우 rsync 프로토콜이 파일 전송을 저장하기 때문에 속도가 향상됩니다.

(*)이 경우 '속도'는 네트워크가 데이터를 전송할 수있는 속도와 비교하여 CPU가 데이터를 압축 할 수있는 속도를 나타냅니다. 예를 들어 5MB는 유선을 통해 전송하지만 CPU를 1 초에 5MB를 1MB로 압축 할 수 있습니다. 이 경우 압축 데이터의 전송 시간은 1 초보다 약간 길지만 압축되지 않은 데이터는 5 초입니다.

또한 처리량을 높이기 위해 -e "ssh Ciphers = arcfour"를 사용합니다.

모든 파일을 한 장소에서 다른 장소로 복사하는 것이 목표라면 tar / netcat이 가장 빠른 옵션입니다. 파일에 많은 공백이 있다는 것을 알고 있으면 -i 옵션을 사용하십시오.

출처 : tar cvif-/ path / to / source | nc 목적지 포트 번호 목적지 : cd / path / to / source && nc -l 포트 번호 | 타르 xvif-

데이터가 압축 가능하다는 것을 알고 있다면 tar 명령에서 압축을 사용하십시오. -z -j -Ipixz

나는 pixz의 팬입니다 .. 병렬 xz, 그것은 큰 압축을 제공하고 네트워크 대역폭에 내가 가지고있는 CPU의 수를 조정할 수 있습니다. 대역폭이 느린 경우 더 높은 압축을 사용하므로 네트워크보다 CPU를 더 많이 기다리고 있습니다. 빠른 네트워크가있는 경우 매우 낮은 압축을 사용합니다.

출처 : tar cvif-/ path / to / source | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, 0을 무시하고 12 개의 CPU 코어를 사용하는 레벨 2 pixz 압축 DESTINATION : nc -l PORTNUM | 타르 -Ipixz -xvif

압축 수준과 코어를 올바르게 조정하면 데이터 세트에 따라 네트워크를 포화 상태에 가깝게 유지할 수 있고 병목 현상이 디스크가되는 충분한 압축을 수행 할 수 있어야합니다 (일반적으로 읽기 및 쓰기 디스크 시스템이있는 경우 쓰기 쪽 똑같다).

rsync의 경우 tar가 해당 옵션을 사용하는 방식과 유사하게 0을 건너 뛰므로 NFS보다 적은 데이터를 전송합니다. NFS는 데이터에 대해 가정 할 수 없으므로 NFS 프로토콜 오버 헤드와 함께 모든 바이트를 전송해야합니다. rsync에 약간의 오버 헤드가 있습니다.

netcat에는 기본적으로 없음이 있습니다. 관심있는 데이터 만 포함하는 전체 TCP 패킷을 보냅니다.

netcat을 사용하면 scp와 마찬가지로 모든 소스 데이터를 항상 보내야하며 rsync와 같이 선택적으로 선택할 수 없으므로 증분 백업이나 그런 종류에는 적합하지 않지만 데이터 복사 또는 보관에는 적합합니다.

nfsshare에 파일 잠금 설정이 있습니까? 비활성화 된 경우 훨씬 더 많은 성능을 얻을 수 있습니다.

속도의 증가는 적어도 부분적으로 "rsync src host : / path"가 원격 시스템에서 로컬 프로세스를 전송 / 수신하여 I / O를 절반으로 줄임으로써 발생한다고 가정합니다.