Чи дійсно варіант «bs» у «dd» покращує швидкість?


58

Раз у раз мені кажуть, що для збільшення швидкості "дд" я повинен ретельно вибирати правильний "розмір блоку".

Навіть тут, на ServerFault, хтось ще написав, що " ... оптимальний розмір блоку залежить від апаратного забезпечення ... " (iain) або " ... ідеальний розмір буде залежати від вашої системної шини, контролера жорсткого диска, конкретного диска себе, і драйвери для кожного з цих ... " (chris-s)

Оскільки моє відчуття було дещо іншим ( BTW: я відчував, що час, необхідний для глибокої настройки параметра bs, був набагато більшим за отриманий приріст, з точки зору економії часу, і що за замовчуванням було розумним ), сьогодні я просто пішов через деякі швидкі та брудні орієнтири.

Щоб знизити зовнішні впливи, я вирішив прочитати:

  • із зовнішньої картки MMC
  • від внутрішньої перегородки

і:

  • із пов'язаними файловими системами
  • відправлення виводу в / dev / null, щоб уникнути проблем, пов'язаних із "швидкістю запису";
  • уникаючи деяких основних проблем кешування жорсткого диска, принаймні при залученні жорсткого диска.

У наступній таблиці я повідомив про свої висновки, прочитавши 1 ГБ даних з різними значеннями "bs" ( вихідні цифри можна знайти в кінці цього повідомлення ):

введіть тут опис зображення

В основному це означає, що:

  • MMC: з bs = 4 (так! 4 байти) я досяг пропускної здатності 12 Мб / с. Не настільки далекі значення wrt до максимальних 14,2 / 14,3, які я отримав від bs = 5 і вище;

  • Жорсткий диск: з bs = 10 я досяг 30 Мб / с. Безумовно, нижчий ніж 95,3 Мб отримав за замовчуванням bs = 512, але ... також істотно.

Крім того, було дуже зрозуміло, що час роботи центрального процесора обернено пропорційний значенню bs (але це звучить розумно, оскільки чим менший bs, тим більша кількість sys-викликів, що генеруються dd).

Сказавши все вищесказане, тепер питання: чи може хтось пояснити (хакер ядра?), Що є основним компонентом / системами, що беруть участь у такій пропускній спроможності, і чи дійсно варто докласти зусиль для визначення bs, вищого за замовчуванням?


Справа ММС - необроблені цифри

bs = 1М

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

Корпус жорсткого диска - необроблені цифри

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

11
Що було б дійсно приємно - це bs=autoфункція, ddяка буде визначати та використовувати оптимальний параметр bs від пристрою.

4
Що було б надзвичайно приємно - це графік кількох bsрозмірів, побудований проти швидкості замість 15 десятків блоків коду в одному запитанні. Займав би менше місця і був би нескінченно швидшим для читання. Картина дійсно є варто thoursand слова.
MDMoore313

2
@BigHomie - Я хотів би запропонувати графік, але ... є кілька проблем "масштабування". Мабуть, знадобиться логарифмічна шкала на обох осях і ..., думаючи над цим, я подумав, що вирішити це непросту (і швидку) проблему. Тому я перейшов на "табличну" версію. Щодо "... 15 десятків блоків коду", я хотів, щоб усі мали можливість перевірити "необроблені номери", щоб уникнути будь-яких (особистих, моїх) втручань.
Даміано Верзуллі

1
@DamianoVerzulli стіл крутий, будь ласка, проігноруйте мою зухвалість, я все-таки дав вам нагороду за доведення наших забобонів, і я знаю на власні очі, що зірка з розміром байта змінить швидкість, і я можу це поставити під відповідь.
MDMoore313

1
@warren - щоб отримати 4G, ви також можете зробити bs=8k count=512Kабо bs=1M count=4Kя не пам’ятаю повноважень 2 минулих 65536
user313114

Відповіді:


24

Що ви зробили, це лише тест швидкості читання. якщо ви насправді копіюєте блоки на інший пристрій, у вас виникають паузи при читанні, коли інший пристрій приймає дані, які ви хочете записати, коли це трапляється, ви можете потрапити на проблеми із затримкою обертання на пристрої читання (якщо це жорсткий диск) і так часто набагато швидше читати 1М відрізки від жорсткого диска, коли ви рідше зустрічаєтесь із затримкою обертання.

Я знаю, коли я копіюю жорсткі диски, я отримую швидший показник, вказавши, 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

Копіювання Macbook Pro Retina 2014 року на палицю USB3 з оцінкою 90 Мб / с пише: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 status=progressпоказує 6140928 bytes (6.1 MB, 5.9 MiB) copied, 23 s, 267 kB/s. Я скасував це, оскільки це зайняло занадто багато часу. Тепер уточнюємо байтази: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 bs=1M status=progressпоказує4558159872 bytes (4.6 GB, 4.2 GiB) copied, 54 s, 84.4 MB/s
Ерік Дункан

9

Що стосується внутрішнього жорсткого диска, щонайменше - коли ви читаєте з пристрою, блок блоку повинен принаймні отримати один сектор, який становить 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 - це "безпечне" число для читання, оскільки:

  • Під час читання з кешуванням на (за замовчуванням) сторінка становить 4 к. Заповнення сторінки на <4 к читання складніше, ніж збереження читання та розміру сторінки однаковим.
  • Більшість розмірів блоків файлової системи встановлені в 4k.
  • Його недостатньо велика кількість (можливо, для SSD-дисків це зараз), щоб викликати накладні сис-кали, але не достатньо велика кількість, щоб споживати багато пам'яті.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.