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

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

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

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

Нет. Dirty - это когда данные есть, но они неправильные. А тут кеш (данные) может просто неожиданно пропасть, вместе еще объем уменьшится.

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

В смысле неправильные?

Не нравится слово «неправильные», тогда - «несогласованные». Когда данные разные у разных источников, в данном случае источники - кеш и диск.

Если только два равнозначных источника, то трудно прийти к однозначному решению, какой источник правильный. Только решением сверху, например, «в кеше правильные данные, пишем из кеша на диск», «второй диск в raid1 неправильный, пишем с первого диска на второй».

И, вообще, термин «грязные» данные - это жаргон, и каждая «кучка людей» понимает его по разному.

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

Вот тут от оверхеда страдает SSD не в силах записать несколько десятков гигабайт. А говорили самсунги хорошо умеют записывать.

Speed Test, RAMdisk vs. SSD vs. Raid vs. SATA vs. SAS - 673

https://www.youtube.com/watch?v=3zup22S-RzE

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

Там синглкор говно из-за низких частот, ну и плюс NUMA.

anonymous
()

Нищук в треде, у кого хуже?

   1024=7.0 GB/s
   2048=12.0 GB/s
   4096=18.0 GB/s
   8192=23.8 GB/s
  16384=28.2 GB/s
  32768=28.7 GB/s
  65536=31.0 GB/s
 131072=32.2 GB/s
 262144=31.3 GB/s
 524288=30.6 GB/s
1048576=30.8 GB/s
2097152=30.9 GB/s
4194304=31.1 GB/s
8388608=31.0 GB/s
16777216=26.3 GB/s
33554432=18.5 GB/s
anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.