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


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

Даже здесь, на ServerFault, кто-то еще писал что "... оптимальный размер блока зависит от оборудования ..." (Iain) или "... идеальный размер будет зависеть от вашей системной шины, контроллера жесткого диска, конкретного диска и драйверов для каждого из них ..." (Chris-ы)

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

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

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

а также:

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

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

enter image description here

В основном это говорит о том, что:

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

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

Кроме того, было очень ясно, что время sys CPU было обратно пропорционально значению 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

50
2017-12-08 20:34


Источник


Было бы очень приятно иметь bs=auto в dd который будет определять и использовать оптимальный параметр bs с устройства.
Что будет очень nice - график нескольких bs размером от 15 до 10 кодовых блоков в одном вопросе. Было бы меньше места и быть бесконечно быстрее читать. Изображение действительно является стоит слов и слов. - MDMoore313
@BigHomie - мне сложно предоставить график, но ... есть несколько проблем с масштабированием. Это должно было бы, вероятно, логарифмическая шкала на обеих осях и ... при этом думая об этом, мне трудно было решить непростую задачу (и быстро). Поэтому я переключился на «таблицу». Что касается «... 15 десятков блоков кода», я хотел, чтобы у каждого была возможность проверить «сырые номера», чтобы избежать каких-либо (личных, моих) помех. - Damiano Verzulli
@DamianoVerzulli стол крут, пожалуйста, проигнорируйте мою напыщенность, я дал вам выдержку для доказательства наших суеверий в любом случае, и я знаю из первых рук, что возиться с размером байта изменит скорость, я тоже могу ответить на этот вопрос. - MDMoore313
@warren - чтобы получить 4G, вы также можете сделать bs=8k count=512K или bs=1M count=4K Я не помню силу 2 прошлых 65536 - user313114


Ответы:


То, что вы сделали, - это только тест скорости чтения. если вы на самом деле копируете блоки на другое устройство, у вас есть паузы в чтении, в то время как другое устройство принимает данные, которые вы хотите записать, в этом случае вы можете столкнуться с проблемами задержки вращения на считываемом устройстве (если это жесткий диск) и так часто значительно быстрее считывать 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

22
2017-12-09 00:57



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 - Eric Duncan


Что касается внутреннего жесткого диска, по крайней мере - когда вы читаете с устройства, блочный слой как минимум должен получить один сектор, который составляет 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.
  • Его не малое количество (возможно, для SSD теперь это), чтобы вызвать накладные расходы на syscall, но не достаточно большое количество, чтобы потреблять много памяти.

6
2018-01-12 02:36