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'"

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

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

★★

Всем, кто указывает (или думает о) модели накопителя, делая этот тест из ТС - аккуратней, а то и патч Бармина вам подсунут, а вы и не заметите! В скрипте нигде не указывается накопитель, и он нигде не задействуется в тесте.

zendrz ★★
()

Для того, чтобы не мерять скорость работы процессора по занулению байтов в памяти, надо создать файл в tmpfs или создать ramdisk и читать от туда. Если, кончено, у вас есть столько памяти, чтобы копирование длилось минимум секунду (16-64 Гб).

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

я ж говорил конский конь - в 4 раза моего ишака перепрыгнул...

amd_amd ★★★★★
()

if=/dev/zero of=/dev/null

полон тред людей, указывающих накопитель

Пиндец, серьёзно? Откуда столько нубов?

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

не указывается накопитель, и он нигде не задействуется в тесте

почему тогда такая разница в показаниях при смене накопителя?

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

Вот уж не знаю. Свой ноут разбирать я не буду, но втыкание-вытыкание флешок не влияют на мои показания

zendrz ★★
()
   1024=1.7 GB/s
   2048=3.2 GB/s
   4096=5.8 GB/s
   8192=9.6 GB/s
  16384=14.6 GB/s
  32768=17.7 GB/s
  65536=22.4 GB/s
 131072=24.4 GB/s
 262144=25.1 GB/s
 524288=25.8 GB/s
1048576=25.8 GB/s
2097152=25.8 GB/s
4194304=26.4 GB/s
8388608=24.4 GB/s
16777216=21.7 GB/s
33554432=17.8 GB/s

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

Свой ноут разбирать я не буду

это ноут так дунул? какой хоть процессор?

cat /proc/cpuinfo

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

Ага, факторов много, но караван идёт со скоростью самого медленного верблюда.
А самый медленный - всё ещё диски.

Minona ★★☆
()

Кстати, большой read_ahead для random_read вреден.
А для тестирования ФС есть fio

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

Но 3 проца – это не статистика. Больше бы людей поделились.

Какой-то селерон 2002 года

   1024=625 MB/s
   2048=1,2 GB/s
   4096=2,0 GB/s
   8192=3,2 GB/s
  16384=4,3 GB/s
  32768=3,0 GB/s
  65536=1,9 GB/s
 131072=1,4 GB/s
 262144=992 MB/s
 524288=865 MB/s
1048576=859 MB/s

n450

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

t9300

   1024=859 MB/s
   2048=1,7 GB/s
   4096=3,1 GB/s
   8192=5,2 GB/s
  16384=7,7 GB/s
  32768=7,9 GB/s
  65536=9,0 GB/s
 131072=9,8 GB/s
 262144=10,3 GB/s
 524288=10,5 GB/s
1048576=10,7 GB/s

q8200

   1024=870 MB/s
   2048=1.7 GB/s
   4096=3.1 GB/s
   8192=5.2 GB/s
  16384=7.6 GB/s
  32768=7.6 GB/s
  65536=8.6 GB/s
 131072=9.3 GB/s
 262144=9.8 GB/s
 524288=10.0 GB/s
1048576=8.1 GB/s

5820k

   1024=1,8 GB/s
   2048=3,3 GB/s
   4096=5,9 GB/s
   8192=9,6 GB/s
  16384=13,6 GB/s
  32768=16,0 GB/s
  65536=19,3 GB/s
 131072=20,8 GB/s
 262144=20,8 GB/s
 524288=19,7 GB/s
1048576=19,9 GB/s

P.S. Тесты на raspberry pi и nokia n900 не удались.

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

это не относится к ФС, но на i7-6500U

   1024=2.7 GB/s
   2048=4.8 GB/s
   4096=7.3 GB/s
   8192=11.2 GB/s
  16384=14.0 GB/s
  32768=14.8 GB/s
  65536=17.1 GB/s
 131072=17.8 GB/s
 262144=17.6 GB/s
 524288=17.3 GB/s
1048576=17.0 GB/s
но это тест в бэкграунде. на проце крутится куча задач. нагрузка на проц без теста примерно 15%. с тестом - около 30%.

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

Не согласен с такой правкой.

Работа с ФС может быть двух типов:

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

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

Таким образом: размер блока должен быть компромиссным для прямого чтения с диска и чтения кэша из оперативки. Ориентироваться лучше как раз на dd zero>null.

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

Pentium III Coppermine

   1024=383 MB/s
   2048=702 MB/s
   4096=1.2 GB/s
   8192=1.5 GB/s
  16384=659 MB/s
  32768=382 MB/s
  65536=400 MB/s
 131072=415 MB/s
 262144=419 MB/s
 524288=422 MB/s
1048576=420 MB/s

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

поменять там /dev/nvme на имя твоего накопителя

самый умный что ли? говорят тебе не работает! размеры выводит - скоростей нет...

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

Если ты будешь бездумно вводить в консоль, что тебе предлагают – найдётся шалун, который тебе дас код, который затирает всю ФС.

Тебе дали проверить скорость чтения с диска nvme, которого у тебя нет. Замени на тот, который есть, и всё будет работать.

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

Странно. Скорее всего, скоростей нет потому что ошибка какая-то выдаётся. Хотя я не представляю какое блочное устройство не поддерживает «direct» чтение. Запусти просто

dd iflag=direct if=/dev/nvme0n1 of=/dev/null

и глянь что оно говорит

chaos_dremel ★★
()

Автору надо получше знать теорию, dd качество диска не измеряют, он даст инфу только про линейное чтение. В реальной работе идёт рандомное чтение и тут большой блок = затык.

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

а, я не заметил шо тут только ноуты меряются.
я у себя замерил на компе, и опубликовал.

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

которого у тебя нет. Замени на тот, который есть

офигеть еще один советчик - естественно заменил, скоростей нет!

найдётся шалун

уже брал тут таких за жопу - не помню кто точно, но общественность сказала это нормально, мол это было предложение измерить скорость на стороннем пустом носителе, а не на системном... и вообще думать надо прежде чем!

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

При чём тут повторное чтение из оперативки? По твоим же тестам копирования данных, повторное чтение из оперативки почти не ускоряется, но при этом первое чтение, которое идёт как раз с диска, внезапно становится быстрее.

Более того, кто тебе сказал, что чтения кеша в оперативной памяти будет идти блоками как-то связанными с readahead? Хочешь проверить кеш в оперативе на чтение – скопируй два-три раз dd’шкой один и тот же файл в /dev/null, чтобы он закешировался, а потом прогони это же копирование, но с разным размером блока.

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

В реальной работе идёт рандомное чтение и тут большой блок = затык.

На сколько я знаю, ext4 старается избегать фрагментации, поэтому в «реальной работе» чаще всего будет последовательное чтение.

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

кто тебе сказал, что чтения кеша в оперативной памяти будет идти блоками как-то связанными с readahead?

Никто не сказал. Надо потестить.

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

поэтому в «реальной работе» чаще всего будет последовательное чтение.

Ага, именно поэтому все переходят на SSD. Точно. Последовательное чтение. А я то думал, вот дураки. Дешевле же сделать RAID на несколько HDD и скорость линейного чтения будет больше гига в секунду, и объём огромный. Странно, почему ж так не делают…

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

На сколько я знаю, ext4 старается избегать фрагментации, поэтому в «реальной работе» чаще всего будет последовательное чтение.

Фрагментация есть везде. А в случае с мелкими файлами даже без фрагментации будет рандом

Для тестов лучше возьмите https://linuxcenter.kz/page/%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D0%BC-%D1%81-phoronix-test-suite-%D0%B8%D0%BB%D0%B8-%D0%BA%D0%B0%D0%BA-%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C-%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%B2%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D1%85-%D0%BC%D0%B0%D1%88%D0%B8%D0%BD-%D0%B2-linux-2.html

phoronix-test-suite run system/fio

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

Они не знали секрета из ОП

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

Посмотрел разные случаи – прямой зависимости между размером read_ahead_kb, кэшами L2/L3 и скоростью чтения не видно. Видимо, для конкретного железа только опытным путём можно найти подходящий размер блока.

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

кто тебе сказал, что чтения кеша в оперативной памяти будет идти блоками как-то связанными с readahead?

Скопировал пробную папку с видюшками с read_ahead_kb 1 Кб – 1м24сек. Копирование из кэша – 3 сек. Т.е. read_ahead_kb никак не влияет на кэш.

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

В btrfs commit 30 сек по умолчанию. В xfs коммита вообще нет

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

device=external-journal

Если плевать на целостность данных на hdd (например для /tmp)

Журнал на рамдиске и монтировать data=journal,nobarrier

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

SSD хороший недалек от рамдиска. Если журнал раздела ФС на HDD сделать на SSD наверняка будет интересный результат при рандомных операциях

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

dd iflag=direct if=/dev/nvme0n1 of=/dev/null

вот так другое дело

отказано в доступе

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

журнал … сделать на SSD

Думаю, тут лучше замутить bcache или lvm-cache –cachemode writeback, и не извращаться над фс

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

У меня нет малинки, извини.

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

Зачем этот тест? Особенно, когда система загружается за несколько секунд, а копирование на другой раздел ограничено пропускной способностью интерфейсов?

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

Если интерфейсы медленные, то смысла никакого нет. С быстрыми жёсткими дисками, вроде NVMe, ограничения могут быть уже от оверхеда системных вызовов, поэтому их сокращение может увеличить и без того реактивную скорость.

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

Возможно этот тест актуален не для десктопа, а на серверах, где производительность действительно важна? Я-то все со своей ноутбучной колокольни.

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

lvm-cache –cachemode writeback

Я тут подумал, можно же извариться и запихать кеш для hdd в zram. Будет быстрый и ненадежный /tmp, который не боится более ТБ записанных данных в день.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.