rsync를 사용하여 약 28TB 이미지를 36TB RAID 5에 복사했습니다. 소스에는 SSD가 있고 대상에는 RAID 5 구성의 6개의 8TB 7200 SATA3 512e 드라이브가 있습니다.
서버는 10G 광섬유 연결을 통해 연결됩니다. 그들은 스위치에 있는 유일한 두 대의 기계입니다.
소스는 CentOS 6.8이고 대상은 Ubuntu 18.04입니다.
HDD가 600MB/s의 전체 쓰기 속도를 얻지 못할 것이라는 것을 알고 있지만, 적어도 200MB/s 범위를 기대할 때 현재는 65MB/s만 얻고 있습니다.
속도는 약 72MB/s에서 시작하여 점차 83MB/s로 증가한 다음 약 1시간 동안 65MB/s로 떨어졌습니다. 현재 5일간 이전이 진행 중입니다.
이것은 매우 느린 것 같습니다. 속도를 높이는 방법에 대한 제안이나 왜 그렇게 느린지에 대한 설명을 듣고 싶습니다. 실행할 명령:
rsync -a --info=progress2 user@sourceserver:/images/library/ /images/library
업데이트:
ssh + tar를 사용하여 디렉토리를 테스트했습니다. (rsync 대신)
55초 만에 24G를 전송할 수 있었으며 이는 허용됩니다. 그런 다음 전체 데이터 세트에 적용합니다. 앞서 언급한 느린 전송 속도로 빠르게 돌아왔습니다.
그런 다음 전송을 중지하고 단일 디렉터리 테스트를 시도했는데 55초 만에 24G에 도달했습니다.
그래서 한 번에 한 디렉토리씩 tar + ssh 스크립트를 작성했습니다. 처음 두 디렉터리는 빠르지만 빠르게 느려집니다.
이제 마지막으로 확인한 디렉토리에서 17G에 20분을 소비했습니다.
RAID 5 문제일 수 있나요?
업데이트: 방금 확인한 빠른 속도는 페이지 캐시에서 데이터를 전송하는 것 같습니다. (같은 디렉터리에서 다시 테스트하고 삭제했습니다.) 새 디렉터리를 사용하니 24G 속도가 3분 정도 느려졌습니다. 하지만 쓰기 잠재력을 보여주는 것 같습니다.
문제는 소스에 있을 수도 있다고 생각합니다. ssh + tar를 사용하여 여러 프로세스(6)를 실행해 보았으나 크롤링 속도가 느렸습니다. netcat을 시도했지만 ssh + tar보다 빠르지 않습니다. 현재 가장 안정적이고 빠른 방법은 3초 간격으로 각 디렉터리를 반복하는 스크립트에서 ssh(arcfour) + tar를 사용하는 것입니다. 이 방법을 사용하면 약 6~7분 안에 35G 복사본이 생성됩니다.
지금까지 이틀 밤 자정 이후 전송 시간이 거의 두 배로 늘어난 것을 확인했으며 스크립트를 중지하고 다시 시작할 때까지 그 속도를 유지했습니다.
참고: 소스 파일 시스템은 xfs이고 대상 파일 시스템은 ext4입니다. 글이 길어져서 죄송합니다. 작은 28TB 파일을 전송하는 가장 빠른 방법을 찾는 데 좋은 연습이 될 것 같습니다.
답변1
두 가지 점:
- 첫째, rsync는 기본적으로 SSH를 통해 작동합니다. 그것은느린. 출력을 확인하세요맨 위또는맨 위다음과 같은 내용이 표시될 수 있습니다.
최고 - 18:04:39 최대 113일, 3:47, 사용자 3명, 로드 평균: 0,50, 0,59, 0,62
타슈: 총 489개, 앙 쿠르 4개, 베일 485개, 아레테 0개, 좀비 0개
%Cpu: 40,7 ut, 14,5 sy, 0,0 ni, 36,3 id, 3,4 wa, 0,0 hi, 5,1 si, 0,0 st
MiB 메모리: 총 7976,3, 212,8 libr, 2717,9 util, 5045,7 탬프/캐시
MiB Éch: 총 8583,0, 8381,2 libr, 201,8 util. 4598,0 메모리 할당
PID 유틸리티. PR NI VIRT RES SHR S %CPU %MEM TEMPS+ COM.
27262 emmanuel20 0 33956 7924 4204 R 58,3 0,1 0:21.51 ssh
31185 emmanuel20 0 52164 3208 2140 S 35,1 0,0 0:05.03 rsync
27249 Emmanuel20 0 1340140 158896 45432 S 8,9 1,9 4:40.63 python2
52 루트 20 0 0 0 0 R 6,3 0,0 9:51.41 kswapd0
25149 루트 20 0 324716 126192 63120 S 2,0 1,5 25:26.24 Xorg
25679 Emmanuel20 0 2555068 774108 100220 S 1,3 9,5 9:28.86 WebExtensions
rsync+ssh가 CPU를 거의 완전히 잡아먹는다는 사실을 알아차리셨나요?
- 둘째, 대상 어레이의 유형과 속도를 알 수 없습니다. 예를 들어 쓰기 캐싱이 비활성화된 하드웨어 RAID 컨트롤러인 경우 정상적인 쓰기 속도가 끔찍할 수 있습니다.
더 나은 성능을 얻는 방법:
초기 사본의 경우rsync를 사용하지 마십시오. 진지하게.동기화좋네요.동기화데이터. 그러나 이는 빈 대상을 가리키는 복사본에는 좋지 않습니다. 전작에 비해 많이 좋아지고 느려졌습니다CP. 그래서 내 제안은 다음과 같습니다.NFS를 통해 cp 사용그리고 하드웨어(가장 느린 부분, 대상 RAID, 네트워크 등)를 최대한 활용할 수 있습니다.
대상 서버에서 편집/etc/export:
/mnt/raid *(rw, 비동기, no_root_squash, no_subtree_check)
NFS를 시작합니다:systemctl restart nfs-kernel-server
- 원본 컴퓨터에서 내보내기를 설치합니다.
mount <server IP>:/mnt/raid /mnt/target
그런 다음 모든 것을 복사하십시오.
cp -av /mnt/source /mnt/target
사용하기 가장 좋습니다화면또는멀티플렉서복사본을 실행하고 예상치 못한 일(Ssh 연결 끊김 등)을 피하세요.
- 대체 솔루션: NFS를 사용할 수 없거나 다른 파일 공유 프로토콜(CIFS/SMB, Fuse-FTP, WebDav...)을 사용할 수 없는 경우 가장 좋은 옵션은 다음을 사용하는 것입니다.인터넷 고양이이것과 결합아스팔트. 중요한 부분은트래픽을 암호화하지 않음:
대상 머신에서 다음을 실행합니다.인터넷 고양이섬기는 사람:
cd /mnt/target ; nc -l -p 45724 | tar x
소스 측에서 다음 명령을 실행합니다.
cd /mnt/source; tar cf - * | nc <target IP> 45724
답변2
코어가 많고 네트워크 대역폭도 넉넉하므로 필요에 따라 병렬화하는 것이 좋습니다. 여러 rsync프로세스가 각각 파일 세트의 서로 다른 부분을 처리합니다.
답변3
결론은 작은 파일이 많기 때문에 rsync의 전송 속도가 느려진다는 것입니다.
이 경우 스트리밍 방법이 더 효율적입니다(예: ssh + tar 사용).
업데이트: 사실 제 경우에는 이것이 올바르지 않습니다(문제가 해결되지 않습니다). 저는 테스트로 사용하는 디렉터리에서 이러한 테스트를 실행하고 있습니다. 누군가 이것이 페이지 캐시에 있을 수 있다고 지적했기 때문에 새 디렉토리에서 다시 테스트를 해보았더니 속도가 급격하게 떨어졌습니다.
답변4
나는 이것이 하드웨어 문제라고 결론을 내릴 것이라고 믿습니다. 이 특정 서버는 중앙 팬 어셈블리 없이 공장에서 배송된 것으로 나타났습니다. 팬에는 RAID 카드 및 기타 구성 요소의 공기 흐름을 방지하는 덮개가 포함되어 있으므로 서버 구성에 필요합니다. 이 문제를 해결하려면 팬이 필요합니다. 이는 전송 속도가 점차 느려지는 이유를 설명할 수 있습니다. 유휴 상태에서도 카드가 눈에 띄게 따뜻해집니다. 그 이후로 중간 팬 어셈블리를 설치했으며 전송 속도는 30-40MB/s로 매우 안정적이었으며 기가비트 네트워크에서 최고 120MB/s에 달했습니다. 10G에서 인증할 수 있으면 좋겠지만 더 이상 액세스할 수 없습니다.