gzip을 통한 파이프 'dd'가 직접 복사보다 훨씬 빠른 이유는 무엇입니까?

79

네트워크의 컴퓨터에서 100Mbit / s 회선을 통해 동일한 네트워크의 다른 컴퓨터로 경로를 백업하고 싶었습니다. 이를 위해 나는했다

dd if=/local/path of=/remote/path/in/local/network/backup.img

이것은 약 50 ~ 100 kB / s의 매우 낮은 네트워크 전송 속도를 제공하여 영원히 가져갔습니다. 그래서 나는 그것을 멈추고 전송량을 줄 이도록 훨씬 작게 만들기 위해 즉시 gzipping하려고 시도했습니다. 그래서 나는

dd if=/local/path | gzip > /remote/path/in/local/network/backup.img.gz

그러나 이제는 1MB / s의 네트워크 전송 속도를 얻으므로 10 ~ 20 배 더 빠릅니다. 이것을 알아 차린 후 나는 여러 경로와 파일에서 이것을 테스트했으며 항상 동일했습니다.

파이핑을 dd통해 gzip스트림의 바이트 길이를 크게 줄이는 대신 전송 속도를 크게하는 이유는 무엇 입니까? 압축하는 동안 CPU 소비가 높기 때문에 전송 속도가 약간 감소 할 것으로 예상했지만 이제는 이중 플러스를 얻습니다. 행복하지는 않지만 궁금합니다. ;)

— 푸 바
소스

1

초기 Unix 파일 저장의 표준 블록 크기는 512 바이트입니다. 모든 것이 유닉스 / 리눅스의 파일이기 때문에 거의 모든 것이 기본값이되었습니다. 대부분의 유틸리티의 최신 버전은 dd가 아닌 증가했습니다.

— DocSalvager 2016 년

간단한 대답은 dd대기 gzip파이프 로 1MB / s로 출력 된다는 것 입니다 . 블록 크기와 관련이 거의 없습니다.

— Tullo_x86

100

dd기본적으로 매우 작은 블록 크기 인 512 바이트 (!!)를 사용합니다. 즉, 많은 작은 읽기 및 쓰기입니다. dd첫 번째 예에서 순진하게 사용 된은 페이로드가 매우 작은 수많은 네트워크 패킷을 생성하여 처리량을 줄인 것으로 보입니다 .

반면에 gzip더 큰 버퍼로 I / O를 수행 할 수있을만큼 똑똑합니다. 즉, 네트워크를 통한 더 적은 수의 큰 쓰기입니다.

dd더 큰 bs=매개 변수로 다시 시도 하여 이번에 더 잘 작동하는지 확인할 수 있습니까?

20

고마워, 직접 복사 를 시도 하고 약 3 또는 4 MB / s의 빠른 네트워크 전송의 gzip블록 크기를 시도했습니다 bs=10M. 높은 blocksize + gzip는 small blocksize +와 비교하여 아무것도 변경하지 않았습니다 gzip.

— Foo Bar

7

어떤 높은 블록 크기를보고 싶다면 gzip 다음에 또 다른 dd를 시도하십시오.

— Joshua

gzip은 자체 출력 버퍼링을 수행합니까, 아니면 stdio 만 사용합니까?

— Barmar

@Barmar 소스를 올바르게 읽으면 단순히 write(3)버퍼에 s합니다.

@CongMa 당신은 또한 gzip 대신 pigz를 사용하고 시도 할 수 있습니다, 그것은 더 빠르게 작동합니다

— GioMac

4

조금 늦었지만 추가 할 수 있습니다 ...

한 인터뷰에서 비트-비트 데이터를 복제하는 가장 빠른 방법이 무엇인지 묻고 dd또는 dc3dd( DoD funded )를 사용하여 대략적으로 응답했습니다 . 면접관은 배관이 있음을 확인 dd하기 위해 dd이 단순히 허용으로, 더 효율적인 동시 읽기 / 쓰기 또는 프로그래머의 관점에서 stdin/stdout, 따라서 ultimatly 배로 쓰기 속도 및 halfing 전송 시간을.

dc3dd verb=on if=/media/backup.img | dc3dd of=/dev/sdb

— 사 디크 테킨
소스

1

나는 그것이 사실이라고 생각하지 않습니다. 방금 시도했습니다. dd status=progress if=/dev/zero count=100000 bs=1M of=/dev/null22.5GB / s, dd status=progress if=/dev/zero count=100000 bs=1M | dd of=/dev/null bs=1M2.7GB였습니다. 따라서 파이프가 느려집니다.

— falsePockets

0

공이 맞아 압축되지 않은 디스크 블록을 원격 호스트로 스트리밍하고 있습니다. 네트워크 인터페이스, 네트워크 및 원격 서버가 제한됩니다. 먼저 DD의 성능을 향상시켜야합니다. 디스크 버퍼 메모리와 일치하는 bs = 매개 변수를 지정하면 디스크에서 최고의 성능을 얻습니다. 예를 들어 bs = 32M이라고 가정하십시오. 그러면 드라이브 버퍼에서 sata 또는 sas line rate 해협으로 gzip의 버퍼가 채워집니다. 디스크는 순차 전송에 더 치우쳐서 더 나은 처리를 제공합니다. Gzip은 스트림의 데이터를 압축하여 사용자의 위치로 보냅니다. NFS를 사용하는 경우 nfs 전송을 최소화 할 수 있습니다. SSH를 사용하는 경우 SSH 캡슐화 및 암호화 오버 헤드가 발생합니다. netcat을 사용하는 경우 헤드를 통한 암호화가 없습니다.

— 로버트
소스

0

여기서 말하는 "전송 속도"가로보고 있다고 가정합니다 dd. 실제로 dd초당 10 배의 데이터 양을 전송 하기 때문에 이것은 실제로 의미 가 있습니다 ! 그러나 dd네트워크를 통해 전송되지 않습니다. 해당 작업이 gzip프로세스 에서 처리되고 있습니다.

일부 컨텍스트 : gzip내부 버퍼를 지울 수있는 한 빨리 입력 파이프에서 데이터를 소비합니다. gzip버퍼가 비는 속도 는 몇 가지 요소에 따라 다릅니다.

I / O 쓰기 대역폭 (네트워크에 의해 병목 현상이 발생하고 일정하게 유지됨)
I / O 읽기 대역폭 (현대 컴퓨터의 로컬 디스크에서 읽는 1MB / s보다 훨씬 높으므로 병목 현상이 발생하지 않습니다)
압축률 (10 배속으로 약 10 %로 가정하여 로그 파일이나 XML과 같이 반복성이 높은 텍스트를 압축하고 있음을 나타냅니다)

따라서이 경우 네트워크는 100kB / s를 처리 할 수 있으며 gzip약 10 : 1의 데이터를 압축합니다 (CPU에 의해 병목 현상이 발생하지 않음). 즉, 100kB / s를 출력하는 동안 1MB / s를 소비gzip 할 수 있으며 소비 속도 dd는 볼 수 있습니다.

— 툴로 _x86
소스