“dd”의 “bs”옵션이 실제로 속도를 향상 시킵니까? 낮을수록 dd에 의해 생성

때때로, 나는 “dd”의 속도를 높이기 위해 적절한 “블록 크기”를 신중하게 선택해야한다고 들었습니다.

여기서도 ServerFault에서 다른 사람 … 최적의 블록 크기는 하드웨어에 따라 다릅니다 …(iain) 또는 ” … 완벽한 크기는 시스템 버스, 하드 드라이브 컨트롤러, 특정 드라이브에 따라 다릅니다 그 자체와 그 각각의 드라이버 …(chris-s)

내 느낌이 조금 달랐기 때문에 ( BTW : bs 매개 변수를 깊게 조정하는 데 필요한 시간이 시간 절약 측면에서받은 이득보다 훨씬 높았으며 기본값은 합리적이라는 것을 알았습니다.) 빠르고 더러운 벤치 마크를 통해

외부 영향을 줄이기 위해 나는 다음과 같이 읽기로 결정했습니다.

  • 외부 MMC 카드에서
  • 내부 파티션에서

과:

  • 관련 파일 시스템이 마운트 해제 된 상태
  • “쓰기 속도”와 관련된 문제를 피하기 위해 출력을 / dev / null로 전송합니다.
  • 적어도 HDD와 관련하여 HDD 캐싱의 몇 가지 기본 문제를 피하십시오.

다음 표에서는 “bs”값이 다른 1GB의 데이터를 읽은 결과를보고했습니다 ( 이 메시지의 끝에서 원시 숫자를 찾을 수 있음 ).

여기에 이미지 설명을 입력하십시오

기본적으로 다음과 같이 나타났습니다.

  • MMC : bs = 4 (예! 4 바이트)에서 12MB / s의 처리량에 도달했습니다. 먼 거리의 값은 최대 14.2 / 14.3으로 ws = 5 이상에서 얻었습니다.

  • HDD : bs = 10으로 30MB / s에 도달했습니다. 기본 bs = 512로 95.3MB보다 낮았지만 중요합니다.

또한 CPU sys-time이 bs 값에 반비례한다는 것은 매우 분명했습니다 (그러나 bs가 낮을수록 dd에 의해 생성 된 sys-call의 수가 많을수록 합리적으로 들립니다).

위의 모든 것을 말 했으므로 이제 질문 : 누군가가 (커널 해커?) 그러한 처리량과 관련된 주요 구성 요소 / 시스템이 무엇인지, 그리고 기본값보다 높은 bs를 지정하는 노력의 가치가 있는지 설명 할 수 있습니까?


MMC 사례-원시 숫자

bs = 1M

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1M count=1000
1000+0 record dentro
1000+0 record fuori
1048576000 byte (1,0 GB) copiati, 74,1239 s, 14,1 MB/s

real    1m14.126s
user    0m0.008s
sys     0m1.588s

bs = 1k

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1k count=1000000
1000000+0 record dentro
1000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 72,7795 s, 14,1 MB/s

real    1m12.782s
user    0m0.244s
sys     0m2.092s

bs = 512

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=512 count=2000000
2000000+0 record dentro
2000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 72,867 s, 14,1 MB/s

real    1m12.869s
user    0m0.324s
sys     0m2.620s

bs = 10

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=10 count=100000000
100000000+0 record dentro
100000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 70,1662 s, 14,3 MB/s

real    1m10.169s
user    0m6.272s
sys     0m28.712s

bs = 5

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=5 count=200000000
200000000+0 record dentro
200000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 70,415 s, 14,2 MB/s

real    1m10.417s
user    0m11.604s
sys     0m55.984s

bs = 4

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=4 count=250000000
250000000+0 record dentro
250000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 80,9114 s, 12,4 MB/s

real    1m20.914s
user    0m14.436s
sys     1m6.236s

bs = 2

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=2 count=500000000
500000000+0 record dentro
500000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 161,974 s, 6,2 MB/s

real    2m41.976s
user    0m28.220s
sys     2m13.292s

bs = 1

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1 count=1000000000
1000000000+0 record dentro
1000000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 325,316 s, 3,1 MB/s

real    5m25.318s
user    0m56.212s
sys     4m28.176s

HDD 케이스-원시 숫자

bs = 1

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1 count=1000000000
1000000000+0 record dentro
1000000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 341,461 s, 2,9 MB/s

real    5m41.463s
user    0m56.000s
sys 4m44.340s

bs = 2

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=2 count=500000000
500000000+0 record dentro
500000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 164,072 s, 6,1 MB/s

real    2m44.074s
user    0m28.584s
sys 2m14.628s

bs = 4

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=4 count=250000000
250000000+0 record dentro
250000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 81,471 s, 12,3 MB/s

real    1m21.473s
user    0m14.824s
sys 1m6.416s

bs = 5

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=5 count=200000000
200000000+0 record dentro
200000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 66,0327 s, 15,1 MB/s

real    1m6.035s
user    0m11.176s
sys 0m54.668s

bs = 10

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=10 count=100000000
100000000+0 record dentro
100000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 33,4151 s, 29,9 MB/s

real    0m33.417s
user    0m5.692s
sys 0m27.624s

bs = 512 (캐싱을 피하기 위해 읽기 오프셋)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=512 count=2000000 skip=6000000
2000000+0 record dentro
2000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 10,7437 s, 95,3 MB/s

real    0m10.746s
user    0m0.360s
sys 0m2.428s

bs = 1k (캐싱을 피하기 위해 읽기 오프셋)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1k count=1000000 skip=6000000
1000000+0 record dentro
1000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 10,6561 s, 96,1 MB/s

real    0m10.658s
user    0m0.164s
sys 0m1.772s

bs = 1k (캐싱을 피하기 위해 읽기 오프셋)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1M count=1000 skip=7000
1000+0 record dentro
1000+0 record fuori
1048576000 byte (1,0 GB) copiati, 10,7391 s, 97,6 MB/s

real    0m10.792s
user    0m0.008s
sys 0m1.144s



답변

당신이 한 일은 읽기 속도 테스트입니다. 실제로 다른 장치에 블록을 복사하는 경우 다른 장치가 작성하려는 데이터를 받아들이는 동안 읽기가 일시 중지 된 경우 (이 경우 하드 디스크 인 경우) 읽기 장치에서 회전 대기 시간 문제가 발생할 수 있습니다. 회전 지연 시간이 적을수록 HDD에서 1M 청크를 읽는 것이 훨씬 빠릅니다.

하드 디스크를 복사 할 때 또는 기본값 bs=1M을 사용 하는 것보다 지정하여 속도가 더 빠릅니다 bs=4k. 30 ~ 300 %의 속도 향상을 이야기하고 있습니다. 매일하는 것이 아니라면 절대적으로 최상의 튜닝을 할 필요가 없습니다. 그러나 기본값보다 더 나은 것을 선택하면 실행 시간이 단축 될 수 있습니다.

실제로 사용하는 경우 몇 가지 다른 숫자를 시도하고 dd프로세스에 SIGUSR1신호를 보내 상태 보고서를 발행하여 진행 상황을 확인할 수 있습니다.

✗ killall -SIGUSR1 dd
1811+1 records in
1811+1 records out
1899528192 bytes (1.9 GB, 1.8 GiB) copied, 468.633 s, 4.1 MB/s


답변

내부 하드 디스크와 관련하여, 적어도 장치에서 읽을 때 블록 계층 은 적어도 512 바이트 인 하나의 섹터를 검색해야합니다.

따라서 1 바이트 읽기를 처리 할 때 섹터 정렬 바이트 검색의 디스크에서만 실제로 읽습니다. 나머지 511 번은 캐시에 의해 제공됩니다.

다음과 같이이를 증명할 수 있습니다.이 예 sdb에서는 관심 디스크입니다.

# grep sdb /proc/diskstats
8      16 sdb 767 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359
...
# dd if=/dev/sdb of=/dev/null bs=1 count=512
512+0 records in
512+0 records out
512 bytes (512 B) copied, 0.0371715 s, 13.8 kB/s
# grep sedb /proc/diskstats
8      16 sdb 768 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359
...

네 번째 열 (읽기 수)은 1 바이트 읽기를 요청 했음에도 불구하고 1 회의 읽기만 발생했음을 나타냅니다. 이것은이 장치 (SATA 2 디스크)가 최소한 섹터 크기를 반환 해야하기 때문에 예상되는 동작 입니다. 커널은 단순히 전체 섹터를 캐싱합니다.

이러한 크기 요청에서 가장 큰 역할을하는 요소는 시스템 호출로 인해 읽기 또는 쓰기가 발생하는 오버 헤드입니다. 실제로 <512에 대한 호출을 발행하는 것은 비효율적입니다. 매우 큰 읽기는 더 많은 메모리를 사용하는 대신 적은 시스템 호출을 요구합니다.

4096은 일반적으로 다음과 같은 이유로 읽을 수있는 ‘안전한’숫자입니다.

  • 캐싱을 사용하여 읽을 때 (기본값) 페이지는 4k입니다. <4k 읽기로 페이지를 채우는 것은 읽기 및 페이지 크기를 동일하게 유지하는 것보다 더 복잡합니다.
  • 대부분의 파일 시스템 블록 크기는 4k로 설정되어 있습니다.
  • syscall 오버 헤드를 유발할만큼 작은 수는 아니지만 (현재 SSD의 경우) 많은 메모리를 소비하기에 충분한 수는 아닙니다.

답변