LINUX.ORG.RU

Делюсь опытом ускорения чтения файловой систем

 , ,


4

5

Привет, друзья! С Праздником!

Интересуясь настройкой производительности своего ноута, натолкнулся на интересный тест в комментарии файла ioblksize.h (coreutils) от автора его кода Jim Meyering:

#!/bin/bash
for i in $(seq 0 10)
	do bs=$((1024*2**$i))
    printf "%7s=" $bs
    timeout --foreground -sINT 2 \
        dd bs=$bs if=/dev/zero of=/dev/null 2>&1 \
        | sed -n 's/.* \([0-9,.]* [GM]B\/s\)/\1/p'
done

Из приложенной таблицы результатов тестов разных процессоров видно, что в среднем наибольшая скорость чтения наблюдается при размере блока 128 Кб:

                per-system transfer rate (GB/s)
   blksize   #1    #2    #3    #4    #5    #6    #7
   ------------------------------------------------
      1024  .73   1.7   2.6   .64   1.0   2.5   1.3
      2048  1.3   3.0   4.4   1.2   2.0   4.4   2.5
      4096  2.4   5.1   6.5   2.3   3.7   7.4   4.8
      8192  3.5   7.3   8.5   4.0   6.0  10.4   9.2
     16384  3.9   9.4  10.1   6.3   8.3  13.3  16.8
     32768  5.2   9.9  11.1   8.1  10.7  13.2  28.0
     65536  5.3  11.2  12.0  10.6  12.8  16.1  41.4
    131072  5.5  11.8  12.3  12.1  14.0  16.7  54.8
    262144  5.7  11.6  12.5  12.3  14.7  16.4  40.0
    524288  5.7  11.4  12.5  12.1  14.7  15.5  34.5
   1048576  5.8  11.4  12.6  12.2  14.9  15.7  36.5

Но на некоторых машинах чтение ФС очевидно быстрее с альтернативным размером блока. Так оказалось и в случае с моим N3540:

   1024=667 MB/s
   2048=1,2 GB/s
   4096=2,1 GB/s
   8192=3,2 GB/s
  16384=4,2 GB/s
  32768=5,1 GB/s
  65536=5,8 GB/s
 131072=6,2 GB/s
 262144=6,5 GB/s
 524288=6,6 GB/s
1048576=5,4 GB/s

Наблюдается очевидный пик при размере блока 512 Кб. Тем не менее, по умолчанию при подключении диска к системе параметр read_ahead_kb устанавливается в 128 Кб. Чтобы проверить, повлияет ли на скорость чтения ФС изменение размера блока по рекомендации теста Jim Meyering, я провёл ряд испытаний в максимально одинаковых условиях: сразу после загрузки, когда участвующие в тестах дирректории ещё не кэшированы. Засекал время на копирование файлов с жёсткого диска в /tmp. Использовал как системную cp, так и утилиту rsync. В тестах принимали участие процессор N3540 и SSD от одного производителя. Результат в секундах, ФС ext4.

Видео 2,4 ГбМелкие файлы (2110 шт.) 1,7 Гб
командаcp -rrsync -avhiscp -rrsync -avhis
размер блока128 Кб512 Кб128 Кб512 Кб128 Кб512 Кб128 Кб512 Кб
«холодный старт»10,6989,57921,78113,9308,6088,22716,89612,048
повторное копирование3,9052,80512,50812,4852,0482,0279,1418,990

Как видно из таблицы, с блоком 512 Кб наблюдается значительное ускорение при чтении незакэшированного содержимого диска (кэшированные файлы читаются примерно одинаково). Особенно это сказывается на работе rsync. Чтобы изменение сделать постоянным, добавил правило udev:

ACTION=="add|change", SUBSYSTEM=="block", RUN+="/bin/sh -c '/bin/echo 512 > /sys%p/queue/read_ahead_kb'"

Результатом очень доволен. Приятно узнать, что твой компьютер может больше, лучше, быстрее. А самое важное – на ожидание копирований/перемещений файлов тратится меньше драгоценного времени.

Интересно, с каким размером блока у вас файловая система работает быстрее? Поделитесь в комментариях!

★★

Наблюдается очевидный пик при размере блока 512 Кб.

Наблюдается где? Последнее измерение может быть ошибкой. Тогда получился бы очевидный результат: чем больше блок, тем быстрее чтение.

hotpil ★★★★
()
Ответ на: комментарий от hotpil

Проверь чтение блоками большего размера и посмотри на динамику. Достаточно изменить for i in $(seq 0 10), на, скажем, for i in $(seq 0 15)

rmu ★★
() автор топика
Последнее исправление: rmu (всего исправлений: 1)

timeout 2 таймаут слишком короткий. Попробуй больше, 10+ секунд. И максимум будет скорее всего зависеть от размера кеша процессора, так как зануление /dev/zero программное. Так себе тест блочной подсистемы.

А на «реальных» тестах - особенности работы контроллера ssd.

anonymous
()
Ответ на: комментарий от anonymous

Попробуй больше, 10+ секунд

Вот вывод с таймаутом 20 сек:

   1024=669 MB/s
   2048=1,2 GB/s
   4096=2,1 GB/s
   8192=3,2 GB/s
  16384=4,2 GB/s
  32768=5,0 GB/s
  65536=5,8 GB/s
 131072=6,2 GB/s
 262144=6,5 GB/s
 524288=6,6 GB/s
1048576=5,6 GB/s

А на «реальных» тестах - особенности работы контроллера ssd.

Да! В этом весь сок: дефолт на разном железе не всегда даёт лучший результат. Достаточно 2 минуты, чтобы найти подходящий размер блока именно под твой ПК – и результат будет радовать долгое время.

Так себе тест блочной подсистемы.

У меня нет оснований сомневаться в качестве теста от разработчика coreutils.

rmu ★★
() автор топика
Последнее исправление: rmu (всего исправлений: 2)
Ответ на: комментарий от rmu

Достаточно 2 минуты, чтобы найти подходящий размер блока

Нет. Твой тест грузит проц(ядро) на 100%. То есть это «странный комбинированный» тест скорости работы процессора и скорости памяти.

anonymous
()
   1024=2,0 GB/s
   2048=3,3 GB/s
   4096=5,0 GB/s
   8192=6,8 GB/s
  16384=7,7 GB/s
  32768=9,0 GB/s
  65536=9,3 GB/s
 131072=9,8 GB/s
 262144=10,0 GB/s
 524288=9,9 GB/s
1048576=10,0 GB/s
amd_amd ★★★★★
()
Ответ на: комментарий от anonymous

Твой тест

Тест не мой, а мужчины Jim Meyering. Этот тест – только подсказка для выбора блока. А правильность настройки я предлагаю определять уже реальными случаями работы с ФС (копирование, например) без 100% нагрузки процессора (если она тебя смущает в случае с dd).

rmu ★★
() автор топика
Ответ на: комментарий от rmu

У меня нет оснований сомневаться в качестве теста от разработчика coreutils.

А какой тест то, копирование из /dev/zero в /dev/null?

Minona ★★☆
()
Ответ на: комментарий от amd_amd

Интересно посмотреть на динамику изменения скорости с большим размером блока. Например, for i in $(seq 0 15).

Я понял, что нужно выбирать наименьший размер с максимальной пропускной способностью. Т.е., когда у тебя одинаковый результат на блоках 256 и 1024 Кб, то очевидно нужно устанавливать 256.

rmu ★★
() автор топика
Ответ на: комментарий от rmu
   1024=1,9 GB/s
   2048=3,3 GB/s
   4096=5,0 GB/s
   8192=6,7 GB/s
  16384=7,6 GB/s
  32768=9,0 GB/s
  65536=9,3 GB/s
 131072=9,6 GB/s
 262144=10,0 GB/s
 524288=10,2 GB/s
1048576=10,1 GB/s
2097152=8,3 GB/s
4194304=7,4 GB/s
8388608=7,7 GB/s
16777216=5,2 GB/s
33554432=5,2 GB/s
amd_amd ★★★★★
()
Ответ на: комментарий от rmu

L3. И облом, скорее всего, будет на шаг раньше размера L3.

anonymous
()
Ответ на: комментарий от rmu

ssd

   1024=1,8 GB/s
   2048=3,3 GB/s
   4096=5,6 GB/s
   8192=7,9 GB/s
  16384=10,2 GB/s
  32768=12,2 GB/s
  65536=13,3 GB/s
 131072=14,2 GB/s
 262144=14,8 GB/s
 524288=14,9 GB/s
1048576=15,2 GB/s
2097152=10,7 GB/s
4194304=8,4 GB/s
8388608=8,5 GB/s
16777216=5,2 GB/s
33554432=5,2 GB/s

amd_amd ★★★★★
()
Ответ на: комментарий от Minona

И какая тут связь с read ahead с реального девайса?

На скорость работы с ФС влияет целый ряд факторов. Один из них – пропускная способность процессора, оперативной памяти и пр.

rmu ★★
() автор топика

Ага на HDD очень показательно

1024=1,5 GB/s

2048=2,8 GB/s

anonymous
()
Ответ на: комментарий от rmu

это тест процессора, а не жёсткого диска

в сундуке 2 винчестера sid на hdd и arch на ssd - процессор всегда одинаковый...

amd_amd ★★★★★
()
Ответ на: комментарий от amd_amd

На мой скромный взгляд, разница с настройкой read_ahead_kb будет проявляться тем сильнее, чем быстрее диск. На тормозном винте и на заметно будет, а в случае со скоростным SSD процессор будет играть значительную роль.

rmu ★★
() автор топика

Накладные расходы на системные вызовы это одно, а эффект от read-ahead — другое. Вместо проверки времени выполнения dd лучше проверять время выполнения cp -r. Вполне возможно, что read-ahead в 256 kB ты получишь ещё большие скорости.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Вполне возможно, что read-ahead в 256 kB ты получишь ещё большие скорости.

Я пробовал разные настройки по несколько раз. Не стал здесь всё постить, чтобы не захламлять. Пробовал и большими и с меньшими размерами блока. Результат во всех случаях коррелировал с тестом dd zero>null.

На HDD разницы не видно, он тормозной. А с SSD был приятно удивлён.

rmu ★★
() автор топика
Ответ на: комментарий от rmu

тест процессора

хорошо, вот процессор athlon X2 II 270 + ssd kingston

   1024=2,2 GB/s
   2048=3,7 GB/s
   4096=5,9 GB/s
   8192=7,9 GB/s
  16384=9,8 GB/s
  32768=11,1 GB/s
  65536=11,5 GB/s
 131072=12,0 GB/s
 262144=12,3 GB/s
 524288=12,5 GB/s
1048576=6,2 GB/s
2097152=2,9 GB/s
4194304=2,9 GB/s
8388608=2,9 GB/s
16777216=2,9 GB/s
33554432=2,9 GB/s
а до этого был fx-4170 + ssd samsung

amd_amd ★★★★★
()
Ответ на: комментарий от amd_amd

Занимательный результат: просадка скорости в 2 раза при блоке 1024 кб.

SSD, HDD – не важно какие. Мне вот интересно узнать зависимость от кэша процессора. Пойду смотреть спецификации на твои процы.

rmu ★★
() автор топика
Ответ на: комментарий от rmu

это тест процессора

процессор athlon X2 II 270 + hdd

   1024=2,4 GB/s
   2048=3,8 GB/s
   4096=5,4 GB/s
   8192=6,6 GB/s
  16384=7,5 GB/s
  32768=8,0 GB/s
  65536=8,2 GB/s
 131072=8,4 GB/s
 262144=8,5 GB/s
 524288=8,6 GB/s
1048576=4,9 GB/s
2097152=2,9 GB/s
4194304=2,9 GB/s
8388608=3,0 GB/s
16777216=3,0 GB/s
33554432=2,9 GB/s
скорость практически такая же как у fx-4170 + hdd хотя он в 2 раза слабее, скорее всего это тест общей пропускной способности, который тестирует всю связку мать+проц+память+винт, чего зачетная штука, ау где все - давайте пиписьками меряться, не забываем указывать параметры железа...

amd_amd ★★★★★
()

тест процессора

процессор i7-3770 + hdd

   1024=1,2 GB/s
   2048=2,3 GB/s
   4096=4,3 GB/s
   8192=7,3 GB/s
  16384=11,2 GB/s
  32768=14,3 GB/s
  65536=18,1 GB/s
 131072=20,5 GB/s
 262144=21,5 GB/s
 524288=21,6 GB/s
1048576=22,1 GB/s
2097152=22,2 GB/s
4194304=22,4 GB/s
8388608=18,8 GB/s
16777216=10,6 GB/s
33554432=9,7 GB/s
по ходу дела от процессора всетаки многое зависит, потому как hdd капец тупорылый, один из первых терабайтников на котором побито часть секторов...

amd_amd ★★★★★
()
Ответ на: комментарий от amd_amd

Если суммировать твои и мои результаты, то лучшим read_ahead_kb получается четверть кэша L2. Но 3 проца – это не статистика. Больше бы людей поделились.

На твоём оборудовании увеличение скорости с SSD в случае с fx-4170 может получиться с блоком 1024 Кб, а с X2 II 270 – 512. Это нужно тестить.

rmu ★★
() автор топика
Ответ на: комментарий от amd_amd

На i7-3770 выглядит так, что профит скорости ты получишь с блоком 4 Мб. Но чтобы его выставить, ты сначала должен посмотреть, может ли диск работать с таким размером блока max_hw_sectors_kb, затем выставить max_sectors_kb 4Мб (по умолчанию здесь только 1280 Кб), и только после этого прописывать read_ahead_kb. Больше двух гигабит прибавки к скорости чтения – на мой взгляд, это круто.

C HDD можешь даже не пытаться.

rmu ★★
() автор топика
Ответ на: комментарий от amd_amd

Не знаю, понял ты или нет, вот этот тест

#!/bin/bash
for i in $(seq 0 10)
	do bs=$((1024*2**$i))
    printf "%7s=" $bs
    timeout --foreground -sINT 2 \
        dd bs=$bs if=/dev/zero of=/dev/null 2>&1 \
        | sed -n 's/.* \([0-9,.]* [GM]B\/s\)/\1/p'
done

к диску не имеет никакого отношения. Это, как писали выше, – комбинированный тест процессора/оперативки, м.б., чего-то ещё. Но он может помочь определить подходящее значение параметра read_ahead_kb уже для реального диска.

rmu ★★
() автор топика
Ответ на: комментарий от anonymous

1024= 2048= 4096= 8192= 16384= 32768= 65536= 131072= 262144= 524288= чё за хня?

Если у тебя в консоли дробная часть чисел разделяется точкой, то тебе нужно [0-9.], если запятой, то [0-9,]. Не знаю почему у тебя не работает [0-9,.] – я специально оба символа поставил, чтобы у всех нормально парсило.

rmu ★★
() автор топика

И мне чёт не спится, добавляюсь. Ноут thinkpad e470, intel i5-7200u, сток ssd SanDisk ~300Mb/s, DDR4-2400 16GB, arch

1024=887 MB/s
   2048=1.7 GB/s
   4096=3.2 GB/s
   8192=5.5 GB/s
  16384=8.7 GB/s
  32768=11.1 GB/s
  65536=14.6 GB/s
 131072=16.6 GB/s
 262144=17.4 GB/s
 524288=17.7 GB/s
1048576=18.2 GB/s
arty_bishop
()
Ответ на: комментарий от rmu

Не работает не с точкой не с запятой, сделал скрипт через echo: максимум 32768=24,4 GB/c Athlon II X2 245, какая-то нереальная цифра.

anonymous
()
Ответ на: комментарий от rmu

с HDD

i7-3770 + arch с флешки через usb

   1024=1,5 GB/s
   2048=2,8 GB/s
   4096=4,8 GB/s
   8192=8,5 GB/s
  16384=13,0 GB/s
  32768=15,9 GB/s
  65536=19,7 GB/s
 131072=22,0 GB/s
 262144=22,9 GB/s
 524288=22,9 GB/s
1048576=23,2 GB/s
2097152=23,2 GB/s
4194304=23,3 GB/s
8388608=18,6 GB/s
16777216=10,4 GB/s
33554432=9,5 GB/s
быстрее чем с винчестера через sata3

amd_amd ★★★★★
()
   1024=1.4 GB/s
   2048=2.7 GB/s
   4096=5.0 GB/s
   8192=8.2 GB/s
  16384=12.2 GB/s
  32768=14.7 GB/s
  65536=18.1 GB/s
 131072=20.1 GB/s
 262144=20.4 GB/s
 524288=20.0 GB/s
1048576=20.3 GB/s
2097152=20.2 GB/s
4194304=20.4 GB/s
8388608=20.4 GB/s
16777216=19.0 GB/s
33554432=9.0 GB/s
67108864=7.8 GB/s

CPU: 2x 10-Core Intel Xeon E5-2690 v2 (-MT MCP SMP-)

Deleted
()
Ответ на: комментарий от Deleted

Вообще, 128Кб – это не плохой вариант, не случайно его выбрали по умолчанию. Тем не менее, скорость чтения можно в некоторых случаях поднять на пару гигабит.

rmu ★★
() автор топика
   1024=3.4 GB/s
   2048=6.1 GB/s
   4096=10.8 GB/s
   8192=16.2 GB/s
  16384=21.9 GB/s
  32768=24.3 GB/s
  65536=28.5 GB/s
 131072=30.1 GB/s
 262144=30.0 GB/s
 524288=29.7 GB/s
Deleted
()

Athlon II X2 245 система на aufs+squashfs+zstd 1024=2,7 GB/c 2048=5,1 GB/c 4096=9,2 GB/c 8192=14,4 GB/c 16384=20,0 GB/c 32768=24,6 GB/c 65536=23,1 GB/c 131072=12,3 GB/c 262144=12,5 GB/c 524288=12,6 GB/c 1048576=6,8 GB/c

anonymous
()
Ответ на: комментарий от amd_amd
      Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz (306E4)
CPU Freq:  3576  3568  3569  3561  3584  3588  3577  3577  3582

RAM size:  128889 MB,  # CPU hardware threads:  40
RAM usage:   8825 MB,  # Benchmark threads:     40

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:      77768  3485   2171  75654  |    1077084  3855   2383  91840
23:      80110  3652   2235  81623  |    1087027  3968   2371  94064
24:      71847  3550   2176  77251  |    1046945  3941   2332  91894
25:      66730  3684   2068  76190  |    1032103  3910   2349  91849
----------------------------------  | ------------------------------
Avr:            3593   2163  77679  |             3919   2358  92412
Tot:            3756   2261  85045
Deleted
()

Ух как тут весело. Вот только не понятно каким боком /dev/null и /dev/zero к скорости чтения файловых систем относятся.

adn ★★★★
()
Ответ на: комментарий от rmu

Но он может помочь определить подходящее значение параметра read_ahead_kb уже для реального диска.

Что-то меня терзают смутные сомнения на счет увеличения скорости чтения от этого. Может лучше это тестировать, чем производительность /dev/zero на разных процессорах.

adn ★★★★
()

Всё хорошо, кроме неверного посыла и неверных выводов.

В коде ioblksize.h сказано следующее:

Note that this is to minimize system call overhead. Other values may be appropriate to minimize file system or disk overhead.

То-есть, когда мы тестируем связку оперативка-проц (а тест приведенный там делает именно это), мы можем судить о том какой размер блока минимизирует «нагрузку» на оперативную память и проц. Но для минимизации оверхеда в файловой системе или блочного устройства нужно тестировать файловую систему или блочное устройство, а не оперативную память. Соответственно делать выводы о том какой будет оптимальный readahead на дисковой подсистеме без учёта патернов чтения и без теста самой дисковой подсистемы в корне неправильно.

chaos_dremel ★★
()

Да, этот тест можно модифицировать так, чтобы тестировать блочное устройство (без влияния readahead) и таким образом делать какие-то выводы про оптимальный размер еденичного IO и потом уже экстраполировать эти выводы на readahead который в этот размер желательно укложить.

#!/bin/bash
for i in $(seq 0 15)
        do bs=$((1024*2**$i))
    printf "%7s=" $bs
    timeout --foreground -sINT 2 \
        dd bs=$bs iflag=direct if=/dev/nvme0n1 of=/dev/null 2>&1 \
        | sed -n 's/.* \([0-9,.]* [GM]B\/s\)/\1/p'
done
chaos_dremel ★★
()

i5 6600k Samsung 860 EVO 250GB

   1024=989 MB/s
   2048=1.9 GB/s
   4096=3.6 GB/s
   8192=6.3 GB/s
  16384=9.9 GB/s
  32768=12.8 GB/s
  65536=17.3 GB/s
 131072=19.8 GB/s
 262144=20.9 GB/s
 524288=21.4 GB/s
1048576=21.9 GB/s
hopheynananey
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.