Vraag Verhoogt de "bs" -optie in "dd" echt de snelheid?


Af en toe wordt mij verteld dat om de snelheid van een "dd" te verhogen, ik zorgvuldig een juiste "blokgrootte" zou moeten kiezen.

Zelfs hier, op ServerFault, iemand anders schreef dat "... de optimale blokgrootte is afhankelijk van de hardware ..." (Iain) of "... de perfecte grootte is afhankelijk van uw systeembus, vaste-schijfcontroller, de betreffende schijf zelf en de stuurprogramma's voor elk van die ..." (Chris-s)

Omdat mijn gevoel een beetje anders was (BTW: ik dacht dat de tijd die nodig was om de bs-parameter diep af te stellen veel groter was dan de ontvangen winst, in termen van tijdbesparend, en dat de standaard redelijk was), vandaag heb ik een aantal quick-and-dirty benchmarks doorlopen.

Om externe invloeden te verminderen, besloot ik om te lezen:

  • van een externe MMC-kaart
  • van een interne partitie

en:

  • met gerelateerde bestandssystemen die zijn gemonteerd
  • verzending van de uitvoer naar / dev / null om problemen met "schrijfsnelheid" te vermijden;
  • het vermijden van een aantal basisproblemen van HDD-caching, tenminste wanneer het gaat om de HDD.

In de volgende tabel heb ik mijn bevindingen gerapporteerd, waarbij ik 1 GB aan gegevens lees met verschillende waarden van "bs" (je kunt de onbewerkte nummers vinden aan het einde van dit bericht):

enter image description here

In principe komt het er op neer dat:

  • MMC: met een bs = 4 (ja! 4 bytes), bereikte ik een doorvoer van 12 MB / sec. Een niet zo verre waarde tov het maximale 14.2 / 14.3 dat ik kreeg van bs = 5 en hoger;

  • HDD: met een bs = 10 bereikte ik 30 MB / s. Zeker lager dan de 95.3 MB kreeg met de standaard bs = 512 maar ... ook aanzienlijk.

Ook was het heel duidelijk dat de CPU-systeemtijd omgekeerd evenredig was met de bs-waarde (maar dit klinkt redelijk, want hoe lager de bs, hoe hoger het aantal sys-calls gegenereerd door dd).

Na al het bovenstaande te hebben gezegd, is nu de vraag: kan iemand uitleggen (een kernel hacker?) Wat zijn de belangrijkste componenten / systemen die betrokken zijn bij een dergelijke doorvoer, en of het echt de moeite waard is om een ​​bs hoger te specificeren dan de standaard?


MMC-zaak - onbewerkte nummers

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-behuizing - onbewerkte nummers

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 (offset van de uitlezing, om caching te voorkomen)

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 (offset van de leesactie, om caching te voorkomen)

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 (offset van de leesactie, om caching te voorkomen)

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

51
2017-12-08 20:34


oorsprong


Wat echt heel leuk zou zijn, is om een bs=auto functie in dd die de optimale bs-parameter van het apparaat zal detecteren en gebruiken.
Wat zou zijn uiterst leuk is een grafiek van meerdere bs formaten uitgezet tegen snelheid in plaats van 15 dozijn codeblokken in één vraag. Zou minder ruimte en nemen oneindig sneller te lezen. Een foto echt is een waarde van vier woorden waard. - MDMoore313
@BigHomie - Ik dacht aan het leveren van een grafiek, maar ... er zijn verschillende "schaling" -problemen. Waarschijnlijk had het een logaritmische schaal nodig op zowel as als ... terwijl ik hieraan dacht, vond ik dat het geen gemakkelijk (en snel) probleem was om op te lossen. Dus schakelde ik over naar de "tafel" -versie. Wat de "... 15 dozijn codeblokken" betreft, wilde ik dat iedereen de kans kreeg om "onbewerkte nummers" te controleren, om elke (persoonlijke, mijn-) storing te voorkomen. - Damiano Verzulli
@DamianoVerzulli de tafel is cool, negeer alsjeblieft mijn rant, ik gaf je een upvote voor het bewijzen van ons bijgeloof hoe dan ook, en ik weet uit de eerste hand dat gehannes met de bytegrootte de snelheid zal veranderen, ik zou het ook in een antwoord kunnen plaatsen. - MDMoore313
@warren - om 4G te krijgen, kunt u ook doen bs=8k count=512K of bs=1M count=4K Ik herinner me geen krachten van 2 na 65536 - user313114


antwoorden:


Wat je hebt gedaan, is alleen een leessnelheidstest. als je blokken daadwerkelijk naar een ander apparaat kopieert, pauzeer je tijdens het lezen terwijl het andere apparaat de gegevens accepteert die je wilt schrijven, als dit gebeurt, kun je problemen met rotationele latentie op het leesapparaat (als het een harde schijf is) raken het is vaak aanzienlijk sneller om 1M chunks van de harde schijf te lezen terwijl je minder vaak op die manier tegen rotatielatentie stoot.

Ik weet wanneer ik ben kopiëren harde schijven krijg ik een hogere snelheid door op te geven bs=1M dan door te gebruiken bs=4k of de standaardinstelling. Ik heb het over snelheidsverbeteringen van 30 tot 300 procent. Het is niet nodig om het op het allerbeste af te stemmen, tenzij het alles is wat je elke dag doet. maar het kiezen van iets beters dan de standaardinstelling kan uren besparen op de uitvoeringstijd.

Als u het echt gebruikt, probeer dan een paar verschillende nummers en verstuur de dd proces a SIGUSR1 signaal om een ​​statusrapport uit te brengen, zodat u kunt zien hoe het gaat.

✗ 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

22
2017-12-09 00:57



MacBook Pro Retina-kopie van 2014 naar USB3-stick met een schrijfsnelheid van 90 MB / sec: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 status=progress shows 6140928 bytes (6.1 MB, 5.9 MiB) copied, 23 s, 267 kB/s. Ik heb dit geannuleerd omdat het te lang duurde. Nu specificeert u de bytesize: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 bs=1M status=progress shows 4558159872 bytes (4.6 GB, 4.2 GiB) copied, 54 s, 84.4 MB/s - Eric Duncan


Met betrekking tot de interne harde schijf, tenminste - wanneer u vanaf het apparaat de bloklaag leest tenminste moet een sector ophalen die 512 bytes is.

Dus, bij het verwerken van een 1 byte-read die je alleen echt hebt gelezen van de schijf op de sector uitgelijnde byteterughaling. De resterende 511 keer worden opgediend door cache.

Je kunt dit in dit voorbeeld als volgt bewijzen sdb is een interessante schijf:

# 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
...

De vierde kolom (die leest telt) geeft aan dat er maar 1 meting heeft plaatsgevonden, ondanks het feit dat u 1 bytelezen hebt aangevraagd. Dit is het verwachte gedrag omdat dit apparaat (een SATA 2-schijf) moet ten minste geef de sectorgrootte terug. De kernel caching gewoon de hele sector.

De grootste factor bij het spelen in deze grootteaanvragen is de overhead van het uitgeven van een systeemaanroep voor lezen of schrijven. Het geven van de oproep voor <512 is inefficiënt. Zeer grote waarden vereisen minder systeemaanroepen ten koste van meer geheugen dat hiervoor wordt gebruikt.

4096 is meestal een 'veilig' nummer om te lezen omdat:

  • Bij het lezen met caching ingeschakeld (standaard) is een pagina 4k. Een pagina opvullen met <4k-reads is gecompliceerder dan het lees- en paginaformaat hetzelfde te houden.
  • De blokgrootte van de meeste bestandssystemen is ingesteld op 4k.
  • Het is niet een klein genoeg nummer (misschien voor SSD's is het nu) om syscall overhead te veroorzaken maar niet een voldoende groot aantal om veel geheugen te verbruiken.

7
2018-01-12 02:36