대용량 파일 (~ 20GB)을 복사하는 cp에 대한 빠른 대안이 있습니까?

저는 대학원생이며 제가 일하는 그룹은 Linux 클러스터를 유지 관리합니다. 클러스터의 각 노드에는 고유 한 로컬 디스크가 있지만 이러한 로컬 디스크는 상대적으로 작으며 자동 백업 기능이 없습니다. 따라서이 그룹은 많은 TB의 저장 공간이있는 파일 서버를 소유합니다. 필자는 상대적인 Linux 초보자이므로 속도, 네트워킹 기능 등의 측면에서 파일 서버의 사양이 무엇인지 잘 모르겠습니다. 로컬 디스크가 I / O 측면에서 파일 서버보다 훨씬 빠르다는 경험을 알고 있습니다 . 약 12 명 정도의 사람들이 파일 서버를 사용합니다.

사용 cp로컬 디스크 중 하나에 파일 서버로부터 20 ~ 기가 바이트 파일을 복사하는 것은 (에 따라 평균 실시간으로 11.5 분 정도 걸립니다 time). 나는 cp(1) time그러한 사본의 시스템 시간이 ~ 45 초에 불과하다는 것을 알려 주기 때문에이 작업이 효율적이지 않다는 것을 알고있다 . (2) top복사 하는 동안 검사 할 때 % CPU 는 상당히 낮습니다 (검사에 의해 평균적으로 대략 0-10 % ).

사용하여 cp동일한 로컬 디스크의 다른 폴더에 로컬 디스크에 한 폴더에서 같은 20 ~ 기가 바이트 파일을 복사하는 시간이 덜 걸립니다 - 실시간으로 구분 (~에 따라 시스템 시간 51 초에 대한 time). 따라서 파일 서버는 예상대로 로컬 디스크보다 다소 느리지 만 현저하게 느리지는 않습니다. 로컬에서 동일한 로컬로 복사하는 것이 9 분보다 빠르지 않다는 것에 놀랐습니다.

파일 서버에서 로컬 디스크 중 하나로 200 ~ 200 개의 큰 파일 (각 ~ 20GB)을 복사해야합니다. 그래서 내 질문은 : Linux에서 큰 파일을 복사 하는 것보다 빠른 대안이 cp있습니까? (또는 cp복사 속도를 높이는 데 사용할 수 있는 플래그가 있습니까?)이 복사 시간을 1 분 정도 단축 할 수 있어도 큰 도움이 될 것입니다.

새롭고 더 빠른 하드웨어 디스크를 구입한다고 확신하지만 이러한 리소스에 액세스 할 수 없습니다. 나는 또한 시스템 관리자가 아니며 – (초보자) 사용자이므로 디스크에있는로드에 대한 자세한 정보에 액세스 할 수 없습니다. 매일 약 12 ​​명이 파일 서버를 사용하지만이 특정 노드 / 로컬 디스크를 사용하는 유일한 사람이라는 것을 알고 있습니다.

복사하는 동안 % CPU 가 낮아야합니다. CPU는 디스크 컨트롤러에 "섹터 XY의 데이터를 Z의 메모리 버퍼로 가져옵니다"라고 지시합니다. 그런 다음 다른 것을 수행합니다 (또는 아무것도 없으면 잠자기). 데이터가 메모리에 있으면 하드웨어가 인터럽트를 트리거합니다. 그런 다음 CPU는이를 몇 번 복사해야하며 네트워크 카드에 "메모리 위치 A, B 및 C에서 패킷을 전송합니다"라고 알려줍니다. 그런 다음 다른 일로 돌아갑니다.

~ 240mbps를 추진하고 있습니다. 기가비트 LAN에서는 800mbps 이상을 수행 할 수 있어야합니다.

1. 그것은 파일 서버를 사용하는 모든 사람과 공유 할 수 있습니다.
2. 이는 파일 서버가 쓰기를 처리 할 수있는 속도에 의해 제한되며 디스크 I / O 대역폭은 모든 사용자가 공유합니다.
3. 파일 서버 (NFS, CIFS (Samba), AFS 등)에 액세스하는 방법을 지정하지 않았습니다. 네트워크 마운트를 조정해야 할 수도 있지만 절반 정도는 기본값이 보통입니다.

병목 현상을 추적 iostat -kx 10하는 데 유용한 명령이 될 것입니다. 로컬 하드 디스크의 활용도를 보여줍니다. 파일 서버에서이 파일을 실행할 수 있으면 파일 서버 사용량이 얼마나되는지 알려줍니다.

일반적인 해결책은 병목 현상을 가속화하는 것입니다. 물론 예산이 없습니다. 그러나 더 빠른 접근 방법을 찾을 수있는 몇 가지 특별한 경우가 있습니다.

• 파일을 압축 할 수 있고 빠른 CPU가있는 경우, 최소한의 압축 작업 이 더 빠를 수 있습니다. 뭔가 lzop또는 어쩌면 gzip --fastest.
• 여기저기서 약간의 비트 만 변경 한 다음 파일을 다시 보내면 델타 전송 만 훨씬 빨라집니다. 불행히도 rsync델타를 찾으려면 양쪽에서 파일을 읽어야하기 때문에 실제로 도움이되지 않습니다. 대신 파일을 변경할 때 델타를 추적하는 무언가가 필요합니다 ... 여기의 대부분의 접근 방식은 앱마다 다릅니다. 그러나 device-mapper (새로운 dm-era target 참조 ) 또는 btrfs 와 같은 것을 조작 할 수 있습니다.
• 동일한 데이터를 여러 머신에 복사하는 경우 udpcast와 같은 것을 사용하여 한 번에 모든 머신에 전송할 수 있습니다.

그리고 당신은 sysadmin이 아니라는 것을 알고 있기 때문에 sysadmin을 가지고 있다고 생각합니다. 또는 적어도 파일 서버 및 네트워크를 담당하는 사람. 당신은 아마 그 / 그녀 / 그들에게 물어볼 것입니다, 그들은 당신의 설정의 세부 사항에 훨씬 익숙해야합니다. 시스템 관리자는 적어도 어느 정도의 전송 속도를 기대할 수 있는지 알려줄 수 있어야합니다.

이 방법은 더 빠른 대안 일 수 있으며 이틀 동안 네트워크를 방해하지 않습니다. 하나 또는 두 개의 큰 USB (있는 경우 USB 3) 또는 FireWire 디스크를 가져 와서 서버에 연결하고 파일을 디스크. 디스크를 로컬 컴퓨터로 운반하십시오. 파일을 기기에 복사하십시오.

효율적인 정의는 거꾸로입니다. 보다 효율적인 구현은 CPU 시간을 덜 낭비 합니다. 로컬 복사본에서 평균 74MB / s의 처리량 (읽기 + 쓰기)을 기록하고 있습니다. 이는 단일 하드 디스크가 얻는 것만 큼 좋습니다.

직접 SSH (또는 SFTP) 액세스 권한이있는 경우 (sysadmin에게 문의) scp압축 ( -C) 과 함께 사용할 수 있습니다 .

scp -C you@server:/path/to/yourfile .

물론 파일이 압축 가능한 경우에만 유용하며 암호화를 사용하여 (SSH를 통해) 압축을 사용하므로 더 많은 CPU 시간이 사용됩니다.

cp구현 가능성이 높습니다 병목 현상이 아니다. iotop서버와 클러스터 노드 를 통해 IO 사용량을 관찰 하십시오. 이를 통해 성능을 향상시킬 수있는 아이디어를 얻을 수 있습니다.

또 다른 팁은 동일한 호스트에서 동일한 데이터를 복사하지 않는 것입니다. 예를 들어, 네트워크를 통해 파일 서버에서 모든 클러스터 노드로 배포 할 동일한 20G 파일이있는 경우 파일을 한 서버에서 모든 클라이언트가 아닌 피어 투 피어 방식으로 복사하면 훨씬 빠르게 작동합니다. 구현하기가 조금 더 복잡하지만 직접 연결 허브와 같은 일부 명령 줄 p2p를 사용해 볼 수도 있습니다.

해당 20G 파일 내에서 일부는 공통적이며 일부는 클러스터 노드에 고유 한 경우 공통 및 특정 부분으로 분할 한 다음 p2p 방식으로 공통 부분을 분배하는 것을 고려하십시오.

해당 파일의 특성 / 내용은 약간의 차이를 만들 수 있습니다. 한 컴퓨터에서 다른 컴퓨터로 ~ 20GB 씩 200 개의 파일을 복사해야한다는 것을 알고 있습니다.

해당 파일이 압축 가능하거나 유사하거나 동일한 조각 인 경우 두 가지 접근 방식이 있습니다.

• 복사하기 전에 압축하거나 zip 활성화 된 컴퓨터간에 터널을 만듭니다. 따라서 네트워크가 병목 현상이면 조금 더 빨라집니다

• 파일이 매우 유사하거나 공통 컨텐츠를 공유하는 경우 rsync 사용하십시오 . 파일에서 공통적 인 것을 찾는 데 시간이 걸리고 , 공통적 인 것을 기반으로 파일을 재구성하기 때문에 파일을 그대로 복사 할 필요가 없습니다 .

편집하다

해당 파일을 여러 번 복사해야합니까 ?? (복사본-> 해당 파일 사용-> 컴퓨터 A의 파일에서 무언가 변경-> 파일을 컴퓨터 B에 다시 복사)

그렇다면 rsync가 도움이 될 것입니다. 버전간에 동등한 것이 무엇인지 감지하고 변경되지 않은 것을 복사하지 않기 때문입니다.

그리고 세 번째 방법 : 위의 내용이 올바른 경우 (파일 변경 후 모든 파일을 두 번째 컴퓨터에 다시 복사) binary diff첫 번째 컴퓨터에서 변경된 내용을 두 번째 컴퓨터에서 변경 하려고 시도 할 수 있습니다.

여기에서 다음을 볼 수 있습니다. 암호화는 전송되는 데이터의 양을 증가시킬 수 있으므로 좋지 않습니다.

두 시스템간에 복사하는 경우 병목 현상은 물론 서버 간의 연결입니다.

로컬로 복사하는 경우 프로세스 진행 방식을 확인하십시오. 단일 스레드이므로 표준 Linux 유틸리티는 다음을 사용합니다.

- for all blocks in a file
      read a block
      write a block

이 작업에는 동시성이 없습니다.

작업 속도를 높이려면 다음과 같이 사용할 수 있습니다.

  buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte

자세한 내용은 buffer (1) 매뉴얼 페이지를 참조하십시오.

buffer 명령은 복사 프로세스를 동시에 실행하기위한 두 프로세스 (하나는 읽기 및 다른 하나는 쓰기)를 설정하고 공유 메모리 버퍼를 사용하여 두 프로세스간에 데이터를 통신합니다. 공유 메모리 버퍼는 기록되지 않은 데이터의 덮어 쓰기와 이미 작성된 데이터의 쓰기를 방지하는 클래식 원형 버퍼입니다. 디스크에서 테이프로의 전송에서 복사 시간의 약 10-20 %를 차단하기 위해이 프로그램을 사용했습니다.

전체 클러스터를 동시에 업데이트해야하는 경우 P2P 전파 알고리즘을 사용해보십시오.

https://github.com/lg/murder 는 트위터가 사용하는 것입니다

있다 BTSync 당신은뿐만 아니라 시도 할 수있다.

로컬 컴퓨터에서 서버로 동일한 파일 집합을 자주 복사하는 경우 여기 저기 약간 변경됩니다. rsync 또는 DVCS (예 : hg 또는 git)를 사용하여 전송 속도를 높일 수 있습니다.

git 또는 hg는 델타를 추적 및 감지하고 해당 델타 만 전송할 수 있습니다. 자식을 사용하는 경우 양쪽에 저장소의 전체 기록이 있으므로 델타를 찾는 것이 매우 저렴합니다.

rsync는 롤링 체크섬 알고리즘 형식을 사용하여 다른쪽에 대한 사전 지식없이 델타를 감지합니다. rsync가 델타를 계산하는 데 더 많은 작업이 필요하지만 전체 파일 히스토리를 저장할 필요는 없습니다.

모든 파일을 단일 아카이브로 압축하려고 할 수 있습니다 (압축 할 필요는 없음). 내 경험상 하나의 아카이브를 복사하면 많은 수의 개별 파일을 복사하는 것보다 빠릅니다.

bbcp 사용해보십시오 . 우리 환경에서 테스트 한 결과 cp에는 일종의 관리자가 내장되어있었습니다. 거버너를 탈퇴 할 때 서버에 전화를 걸고 중단을 일으킬 수 있으므로주의하십시오. 우리의 경우 복사를 위해 서버를 오프라인 상태로 만들었으므로 더 빠를수록 좋습니다. 이로 인해 전송 시간이 몇 시간 단축되었습니다.

복사하기 전에 대상 파일이 존재하지 않는지 확인하십시오.

때로는 동일한 호스트 (네트워크를 사용하지 않음)에서 복사하는 것만으로도 시간이 얼마나 걸리는지 놀랍습니다.

다른 cp 질문에 대한 내 대답은 여기를 참조 하십시오 . 간단히 말해 기존 파일을 덮어 쓰는 것은 파일을 자르거나 연결을 해제 한 다음 복사하는 것보다 훨씬 느립니다. 후자는 1.2GB 파일보다 8 배 빠릅니다.