Действительно ли опция «bs» в «dd» улучшает скорость?


58

Время от времени мне говорят, что для увеличения скорости «дд» я должен тщательно выбирать правильный «размер блока».

Даже здесь, на ServerFault, кто-то другой писал, что « ... оптимальный размер блока зависит от оборудования… » (iain) или « ... идеальный размер будет зависеть от вашей системной шины, контроллера жесткого диска, конкретного диска сам и драйверы для каждого из тех ... " (chris-s)

Поскольку мои ощущения были немного другими ( кстати, я подумал, что время, необходимое для глубокой настройки параметра bs, было намного выше полученного усиления с точки зрения экономии времени и что значение по умолчанию было разумным ), сегодня я просто пошел через некоторые быстрые и грязные тесты.

Чтобы снизить внешние воздействия, я решил прочитать:

  • с внешней карты MMC
  • с внутреннего раздела

а также:

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

В следующей таблице я изложил свои выводы, прочитав 1 ГБ данных с разными значениями «bs» ( необработанные числа можно найти в конце этого сообщения ):

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

В основном получается, что:

  • MMC: при bs = 4 (да! 4 байта) я достиг пропускной способности 12 МБ / с. Не столь отдаленные значения по отношению к максимуму 14.2 / 14.3, которые я получил от bs = 5 и выше;

  • HDD: при bs = 10 я достиг 30 МБ / с. Конечно, ниже, чем 95,3 МБ, полученное по умолчанию с bs = 512, но ... также значительным.

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

Сказав все вышесказанное, теперь возникает вопрос: может ли кто-нибудь объяснить (хакер ядра?), Каковы основные компоненты / системы, участвующие в такой пропускной способности, и действительно ли оно стоит усилий при указании значения bs выше значения по умолчанию?


Случай MMC - необработанные числа

шс = 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

шс = 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

шс = 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

шс = 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

шс = 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

шс = 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

шс = 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

шс = 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

Корпус жесткого диска - необработанные числа

шс = 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

шс = 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

шс = 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

шс = 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

шс = 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

2014 Macbook Pro Retina копирование на 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 КБ. Заполнение страницы с прочтением <4k сложнее, чем сохранение одинакового размера чтения и размера страницы.
  • Большинство размеров блоков файловой системы установлены на 4 КБ.
  • Это не достаточно маленькое число (может быть, для твердотельных накопителей сейчас), чтобы вызвать издержки системного вызова, но недостаточно большое, чтобы потреблять много памяти.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.