Про ZFS prefetch (2)

Продолжение вот этого вот текста, теперь более систематически.

АХТУНГ. Все описанные ниже эксперименты (и прошлая серия экспериментов) - относятся ТОЛЬКО к FreeBSD-12. На 10.3-11.0 (РЕЛИЗНЫХ, в -stable все похоже хуже) картина принципиально другая и деградации скорости чтения при маленькой глубине префетча нет.

Провел вчерашнее утро, а затем - вечер за стендом,  который схематически показан на картинке (там 7 дисков, потом добавил и восьмой).

А именно:

  • FreeBSD 12.0-CURRENT #6 r306297M
  • i5-2400, 16GB RAM
  • Диски подключены к LSI-9211-8i (IT-mode, прошит без BIOS для быстроты загрузки)
  • Диски - 1Tb WD RE (WD1003FBYX), трансфер ~130MB/s с быстрых дорожек и ~98 с медленных.

И из всего этого благолепия я строил ZFS:

  • RAIDZ2 (ибо меня интересует именно оно)
  • или страйп (из интересу)
  • ashift=12 (но сделал один эксперимент с ashift=9, значимой разницы не увидел)
  • из 5, 6, 7 и 8 дисков
  • recordsize=1m (но сделал один эксперимент с 128k, убедился что длинные чтения-записи несколько медленнее).

А дальше смотрел на скорости записи:

dd if=/dev/zero of=/ztest/dataset/100gfile bs=1m count=100k

И на скорости чтения, которые мерял программой fio, которая или читала файл целиком, или работала 200 секунд:

[global]
rw=read
direct=1
bs=16M
runtime=200
[0]
filename=/ztest/dataset/100gfile

При измерениях скорости чтения, менялся параметр vfs.zfs.zfetch.max_distance, который ставился в значения 8m (default), 80m, 800m и 1753.7m (на самом деле я приписывал к стандартному значению 0, 00 в хвосте и потом единичку в начале, поэтому последнее значение такое не круглое).

Результаты сведены в таблицу:

Disk count

Write MB/s

Read MB/s

Prefetch =8m

80m

800m

1753.7m

RAIDZ2

5 HDD

282

194

250

328

381

6 HDD

514

163

204

326

427

7 HDD

630

219

292

402

534

8 HDD

745

227

307

462

626

Stripe

5 HDD

656

338

458

593

627

6 HDD

778

403

555

702

833

7 HDD

898

464

669

822

865

8 HDD

1015

520

784

950

974

В эту таблицу не вошли еще два дополнительных параметра:

  • Равномерность нагрузки на диски. Если в двух словах, то
    • 6 HDD/RAIDZ2: при маленькой глубине префетча загружены в моменте (iostat -x 5, т.е. 5-секундное усреднение!) только 4 диска из 6, при увеличении глубины - происходит некоторое /но недостаточное/ уравнивание.
    • Во всех остальных случаях нагрузка выглядит достаточно равномерной.
  • Равномерность скорости чтения: чем мельче префетч, тем равномернее. При префетче на 1.75gb "график чтения", точнее "посекундная выдача fio" выглядит пилообразно, "около нуля" - "сильно больше среднего" - "около нуля"

Значит о чем я думаю, глядя на эту кучу битого кирпича:

  1. ZFS в текущих версиях FreeBSD как-то не очень оптимизирован под однопоточное чтение (неудивительно, но вот хотелось бы таки вменяемых гайдов по оптимизации, может быть надо какую другую гайку крутить).
  2. Размер префетча явно имеет смысл увеличивать как минимум до "число дисков * объем одной дорожки". Объем дорожки я оцениваю, чисто от фонаря, как 20Mb.
  3. 6-дисковый RAIDZ2 - будучи оптимальным по потерям места (2^N+2 дисков), что, впрочем, не так важно для больших recordsize, явно плох в смысле чтения по причине нагрузки только на 4 диска из 6. Может быть механизм разбрасывания контрольных сумм плохо справляется именно при моих параметрах (ashift, recordsize), но мне от этого не легче т.к. большой размер записи вроде как всегда быстрее, а ashift дан в ощущениях большими дисками.
    Буду, по всей видимости, 6-дисковый массив переделывать в 7-дисковый.

P.S. Не просите померять еще что-то, стенд разобрал, собирать его снова - это опять минимум на полдня.

P.P.S. Почему на 6-дисковом страйпе чтение оказалось быстрее записи - удивляюсь, но вчера не перемерял (так то выборочно делал повторные замеры и убеждался, что все в пределах вменяемого разброса в единицы процентов), потому что время было уже к полуночи.

Comments

Кстати, во всех свежих FreeBSD (10.x, 11.x, 12) сломан L2ARC если у вас включено сжатие на пуле (хотя бы где-нибудь, на одной FS из многих).

Нет сжатия.

И эти тесты были без L2ARC, естественно.

Я просто на всякий случай предупредил, а то вот у меня тут страдание. Купил SSD а толку нет (а у меня торренты и L2ARC сильно бы помогал).

А в чем выражается "сломан", кстати?

Они научили L2ARC хранить прямо сжатое, блоки как на самом пуле. И в какой-то момент оно сходит с ума и явно хранит лажу. Потому что, во-первых, ALLOCATED растёт до 4x SIZE (у меня есть, конечно, сжатое, но максимум 2x и не торренты, а мой хомяк да порты и прочее системное, а торренты и фотографии, очевидно, не сжаты, так что сжатие 4x в принципе является признаком лажи и даже в 2x я не верю на активном массиве данных), а, во-вторых, начинаются сыпаться checksum errors (именно у L2ARC а не вообще) как из ведра (десятки тысяч в минуту). Так что явно там что-то налажали.
Я писал в fs@, Гапон попросил всяких отладочных логов, я ему послали он пропал. Пару недель назад, если как бы не три недели уже.

storage: ~# uname -a
FreeBSD storage.mgn 10.3-RELEASE-p1 FreeBSD 10.3-RELEASE-p1 #0 r298876M: Sun May  1 12:55:28 CEST 2016     root@dev.nas4free.org:/usr/obj/nas4free/usr/src/sys/NAS4FREE-amd64  amd64
storage: ~# zpool status
  pool: main
 state: ONLINE
  scan: scrub repaired 0 in 0h31m with 0 errors on Mon May 30 16:58:37 2016
config:

        NAME        STATE     READ WRITE CKSUM
        main        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0
            da6     ONLINE       0     0     0
          raidz2-1  ONLINE       0     0     0
            ada4    ONLINE       0     0     0
            ada3    ONLINE       0     0     0
            ada0    ONLINE       0     0     0
            ada5    ONLINE       0     0     0
            ada1    ONLINE       0     0     0
            ada2    ONLINE       0     0     0
        cache
          da0       ONLINE       0     0     0
          da7       ONLINE       0     0     0

errors: No known data errors
storage: ~# zfs get all main
NAME  PROPERTY              VALUE                  SOURCE
main  type                  filesystem             -
main  creation              Wed May 18 17:36 2016  -
main  used                  1.76T                  -
main  available             12.3T                  -
main  referenced            137K                   -
main  compressratio         1.56x                  -
main  mounted               yes                    -
main  quota                 none                   default
main  reservation           none                   default
main  recordsize            128K                   default
main  mountpoint            /mnt/main              local
main  sharenfs              off                    default
main  checksum              on                     default
main  compression           lz4                    local

Или я куда-то не туда смотрю?

Не туда. Покажи zpool list -v и, главное, zfs-stats -L (из одноимённого порта) Вот моё, недавно перезагружался, так что до 4x уже не дотикало:

> zpool list -v
NAME          SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zroot        39.9G  11.8G  28.1G         -    48%    29%  1.00x  ONLINE  -
  gpt/root   39.9G  11.8G  28.1G         -    48%    29%
zstor        13.6T  8.53T  5.10T         -    21%    62%  1.00x  ONLINE  -
  raidz1     13.6T  8.53T  5.10T         -    21%    62%
    ada1         -      -      -         -      -      -
    ada2         -      -      -         -      -      -
    ada3         -      -      -         -      -      -
    ada4         -      -      -         -      -      -
    ada5         -      -      -         -      -      -
cache            -      -      -         -      -      -
  gpt/l2arc   185G   370G  16.0E         -     0%   199%
> zfs-stats -L

------------------------------------------------------------------------
ZFS Subsystem Report                            Mon Dec  5 21:47:43 2016
------------------------------------------------------------------------

L2 ARC Summary: (DEGRADED)
        Passed Headroom:                        660.24k
        Tried Lock Failures:                    83.65k
        IO In Progress:                         3.38k
        Low Memory Aborts:                      6
        Free on Write:                          20.72k
        Writes While Full:                      18.32k
        R/W Clashes:                            0
        Bad Checksums:                          974.32k
        IO Errors:                              0
        SPA Mismatch:                           32.31m

L2 ARC Size: (Adaptive)                         370.31  GiB
        Header Size:                    0.02%   62.62   MiB

L2 ARC Evicts:
        Lock Retries:                           76
        Upon Reading:                           0

L2 ARC Breakdown:                               10.81m
        Hit Ratio:                      25.08%  2.71m
        Miss Ratio:                     74.92%  8.10m
        Feeds:                                  235.04k

L2 ARC Buffer:
        Bytes Scanned:                          21.01   TiB
        Buffer Iterations:                      235.04k
        List Iterations:                        939.28k
        NULL List Iterations:                   177.47k

L2 ARC Writes:
        Writes Sent:                    100.00% 187.44k

------------------------------------------------------------------------

>

ну или может у тебя недостаточно новая версия :)

P.S. вместо zfs-stats можно sysctl kstat.zfs.misc.arcstats.l2_cksum_bad

А, ну да, у тебя релизная ветка, туда мёрджа этого не было.

Как-то непривычно повезло. Обычно я как раз в такие баги люблю влетать. :)

А в 12-current сломан ZFS целиком, см. красное предупреждение в посте.

А вот это я бы уже репортил. Учитывая, что ZFS они стараются держать синхронным между ветками и эта регрессия может легко попасть и в 10 и в 11.

Я завтра сведу это в таблицу и тогда зарепорчу уже.

Я тут весь вечер сижу - скачать memstick-образ, записать на флешку, забутиться, создать пул, прогнать 4 (8 тестов).
10.1, 10.2,10.3,11.0, 12-20161130

Ну, главное, что не потеряется. Но вообще, Гапон как-то пропал совсем, а кто ещё?..

Тесты интересные. Выводы, как по мне, не имеют право на жизнь :-). Видна явно аномально низкая скорость последовательного чтения при настройках по умолчанию. Предположу, что на шестидисковой конфигурации raidz2 средний размер запроса на чтения опять был в районе 32k и я так понимаю причина не найдена?

Для 5-дисковой - 112-113k (но я в уме считал, не калькулятором).
Для 6-дисковой записан только размер при записи (128к) и судя по тому что я другие не записывал - при чтении было так же :)

Ну и вот главное - скажите какую гайку крутить и я ее покручу.

Крутить все гайки - не могу, жизнь коротка.

Вот наверное надо покрутить гайку 'FreeBSD 10.1' (то есть до 10.3), кстати.

Не хочу быть занудой и писать много букв :-). Попробую кратко. Моё мнение, zfs оптимизирована как раз для последовательного чтения (в отличии от случайного). Для загрузки диска на 100% для последовательного чтения обычно достаточно 2-3 запроса курсирующих от процесса к диску (получается 256-384k на диск в идеальном случае, а с учётом распределения в zfs данных по vdev - наверно по 4-6MB на диск максимум), поэтому использовать такие огромные окна префетча - это нонсенс.
"Для 6-дисковой записан только размер при записи (128к) и судя по тому что я другие не записывал - при чтении было так же :)" - не верю, что при поступлении 4 одновременных запросов чтения по 128k на разные диски в итоге общая скорость пула чуть выше, чем у одиночного диска. У меня сейчас нет столько свободных дисков, что бы проверить, но первое гугление даёт такой результат: https://calomel.org/zfs_raid_speed_capacity.html. Понятно, что не совсем ясна методика измерений, но показательно соотношение скорости записи и чтения.
На счёт версии FreeBSD - я уже недели три-четыре держу/испытываю основные данные на 11 версии и доволен :-). Изменения по сравнению с 10.1 были, но, как по мне, не существенные.
На счёт гаек - я свои гайки уже описывал. Если возникнет желание попробовать - не вопрос. Думаю из этих 8 дисков можно получить около 900MB/s при однопоточном последовательном чтении.

См. ниже: FreeBSD10.1 дает вменяемые и понятные результаты (и окна префетча там нет в регулировках)
Я постепенно, за вечер, попробую все это же дело на 10.2, 10.3, 11.0, если и на 11 (с флешки) все хорошо - значит прикол где-то в моем loader.conf

Сомнительно, чтобы родная для Солярки ФС затачивалась на последовательное чтение.
Особенно если вспомнить про 16 головок на 1 шпинделе... Про SSD вообще молчу, но для них оптимизаций, может, и нет ещё.

zfs позиционируется, как универсальная файловая система. Поэтому должна бы в принципе настраиваться под любую нагрузку. По моему же личному мнению/опыту некоторые сценарии/патерны на ней скажем так "не очень". Возможно моё мнение и субъективно :-).
Для настройки последовательного чтения в zfs разработан блочный префетч (который всегда выключен по умолчанию), довольно навороченный файловый префетч. Для зеркала предусмотрено/разработано почти удвоение скорости последовательного чтения. В шедуллере выделена отдельная очередь для предвыбираемого последовательного чтения. Всё это регулируется/настраивается. Теперь вопрос - у какой файловой системы есть такие развитые средства и самое главное какая комбинация (файловая + рэйд) на любой операционной системе может дать сопоставимый результат по скорости последовательного чтения? Вот для примера, прямо сейчас с работающего круглосуточно пула (из 4 дисков - 2 диска со скоростью в начале 195MB/s и два 175MB/s) холодное последовательное чтение большого (32GB) файла 562MB/s, одновременное последовательное чтение двух больших (по 32Gb) файлов 300+290MB/s, повторное чтение (метаданные в кэше) - 640MB/s и 350+342MB/s соответственно.

Крутите FAT и страйпы.
ZFS - для параноиков а не для Хаккененов.

Значит рассказываю:
FreeBSD 10.1 с флешки
Создаем пул (recordsize > 128k не создается), 6 дисков.
Запись dd bs=1m - 439MB/s
чтение (dd bs=1m) - 441MB/s
Получается, что-то они там перемудрили в 10.3-11.x-12.

Для 6-дискового пула при чтении - в моменте работают 4 диска из 6, но по суммарному iostat - выравниваются.

Буду теперь 7 пробовать.

7HDD, RAIDZ2=> 633(W)/599(R)
Размер блока чтения - в районе 100+ килобайт

Пошел качать FreeBSD 10.2

Уже похоже на правду :-). В 10.1 размер префетча 256 * 128k = 32MB.

Ну вот опупея, но в другом разрезе, да.
6/7 дисков 1m/128k recordsize (там где ставится 1m), версия FreeBSD

Интеллектуальное занятие.....

Я так понимаю у тебя появился свет в конце туннеля :-). В самый раз спросить - какая по твоему "теоретическая" верхняя планка производительности последовательного чтения raidz2 относительно полной производительности всех дисков, входящих в пул? Какое количество дисков в raidz2 может "теоретически" дать максимальную производительность последовательного чтения относительно полной производительности пула (здесь прийдётся опираться на твои результаты)? Как по мне вопросы интересные, требующие размышлений, к тому же ответы помогут тебе найти ориентир в дальнейшей настройке и я заодно приобщусь к пониманию raidz2 ;-).

Я вопроса не понял, что такое "производительность чтения относительно полной производительности пула"?
raidz2 относительно страйпа что ли?

Для ответа на этот вопрос надо знать внутреннюю организацию данных в raidz2. То есть вот условно говоря, если *вдруг* нам удается организовать данные так, что контрольные суммы и данные лежат "целыми дорожками" (ну там для 7 дисков, на каждом диске "5 дорожек данных, 2 дорожки контрольных сумм", то при такой организации оверхеда можно практически избежать: при нормальном чтении мы никогда не читаем.

Может ли такое наблюдаться на практике - я не знаю. На практике я вижу для некоторых (не самых новых :) версий FreeBSD превышение скорости чтения над записью на 12-14% (для мегабайтной recordsize). В идеальном случае были бы 6/4 и 7/5, такого нет и близко.

Под полной производительностью пула имелся в виду результат test_all на тестируемом участке. Относительная производительность - это % от неё.
Картинка распределения данных в raidz по дискам от разработчиков довольно известная, вроде даже ты :-) ссылку в этом блоге когда-то давал. Наверняка можно посмотреть распределение блоков по zdb, но наверно твоих результатов достаточно для понимания.
Можно ещё перефразировать - какой результат тебя бы устроил :-) ?
Что имелось ввиду под "6/4 и 7/5"?

Я не знаю что такое test_all.

6/4, 7/5 это вот что:
- в гипотетической идеальной ситуации мы можем получить при записи на 7-дисковый массив "скорость 5x одиночный диск" (плюс-минус метадата). И примерно столько и получаем, кстати.
- при чтении, если вдруг случайно метадата разлеглась так, что мы ее никогда не читаем - в 7/5 раза быстрее должны бы читать

ZFS, вроде, сконструирована именно так, чтобы и данные и метадата (в особенности!) были максимально равномерно размазаны по дискам.

test_all - в предыдущий раз я давал файл-задание fio для одновременного последовательного чтения со всех дисков.
С записью согласен. Верхний потолок - производительность самого медленного диска в raidz2 умножить на количество дисков в raidz2 минус 2. И ещё всё таки минус затраты на запись метаданных. Здесь наверно можно поиграться их уменьшить, но выигрыш наверно будет исчисляться единицами процента. При измерении dd нужно учитывать, что после показа завершения записи на диски может продолжаться запись ещё несколько секунд (writeback).
По чтению почти согласен :-). Думаю нужно обращать внимание не на метаданные, а на расположение контрольных блоков. Моё предположение, что для конфигурации raidz2 в 7 дисков потолок последовательного чтения будет приблизительно равен потолку записи или немного больше, а вот для 6 (что то мне подсказывает) возможно и значительно больше потолка записи.

Тут вот другая история, тоже вот непонятная.
Сдаунгрейдил один ящик, с 12-current на 11.0-releng, стало хорошо, скорость и чтения и записи 400+ (там 5x4Tb в raidz2).

Сдаунгрейдил другой ящик с 11-stable на 11.0-releng. Хорошо не стало. В этом ящике 6x6Tb, raidz2

Ага. Говно хлещет при создании файла! То есть если читать файл, созданный на кривой версии - медленно.
Пересоздал тестовый файл - вот по iostat вижу что стало нормально (нет, 2 диска из 6 простаивают, но это как раз нормально)

Я бы не спешил с выводами о проблемах zfs в 12 версии. Есть ещё драйвер LSI ;-). Наверно для уточнения потребуется проверить работу пула хотя бы на набортном контроллере.

11-stable vs 11-releng проверялись на другом ящике, как раз с набортным контроллером (C236)
Вот пишу пост в соседнем окошке, ожидайте.

А 12 to 11-releng - там адаптек.

А тесты мои - были на LSI (я вынимал адаптек вместе с егонной сохраненной конфигурацией, сувал LSI, подключал другие диски).
То есть разнообразие максимально вот изучено.

Вот, все утро убито на эту вот херню: http://blog.lexa.ru/2016/12/06/freebsd_zfs_read_11_stable_tozhe_polomana...

Перечитай ещё раз http://blog.lexa.ru/2016/12/05/pro_zfs_prefetch.html. Особенно про версии FreeBSD.

Не исключено, что в 10.3-STABLE (не releng) ровно эта же херня. Ветки то частично параллельные.

Вот куда буду копать - это создать два файла, 11.0 и 11-stable и почитать их другой системой.

Да, сорцы остались от 10.
Там совсем свежая десятка была, от 5 ноября, судя по svn log | head

И самое свежее там про ZFS вот такое:

r307331 | mav | 2016-10-14 21:43:17 +0300 (Fri, 14 Oct 2016) | 2 lines

Bump __FreeBSD_version for todays ZFS merges.

Все, убег.

Как показал последний эксперимент, проблема в on-disk структурах: http://blog.lexa.ru/2016/12/06/slow_zfs_read_problema_ne_v_kode_a_v_dann...

То есть если я, к примеру, на 11-stable создал плохой файл, то потом на 10.3 он будет читаться медленно, даже если сама 10.3 - хорошая.

Интересная развязка :-). Получается аллокатор выделял место под записываемые блоки на дисках не последовательно?

Ну ничего в голову не приходит другого.

zdb наверное умеет такое показать, но я не умею его читать.

Может заметил - какой средний размер запроса был при чтении "быстрого" файла?

Ну вот сейчас в бою (tar cvf; tar xvf) - в районе 120-128к

Гоню. ~128 - это на запись (5 дисков в raidz1, ashift=12)
На чтение вижу 170 (5 дисков в raidz2, ashift=12)

Не интересно там, где было raidz2 из 6 и ~32kB. Если будет оказия - черкани.

Ну вот data move дойдет до - и тогда.

Ну вот чтение "хорошего" файла выглядит так (это 5сек-усреднение):

device     r/s   w/s     kr/s     kw/s  ms/r  ms/w  ms/o  ms/t qlen  %b
ada1         0     0      0.0      0.0     0     0     0     0    0   0
ada2      1175     0 150479.7      0.0     1     0     0     1    0  43
ada3      1175     0 150479.7      0.0     0     0     0     0    0  40
ada4      1200     0 153600.3      0.0     2     0     0     2    0  57
ada5      1153     0 147705.9      0.0     3     0     0     3    6  81
ada6         0     0      0.0      0.0     0     0     0     0    0   0

два диска простаивают, на 4-х запросы 128kb

Плохой файл не сохранился.

Похоже раньше кто-то дробил блоки. Мысли есть, но я думаю там быстро разберутся.
Статистика красивая. Вроде бы подтверждается гипотеза, что на 6 дисках raidz2 это много сдвинутых условно raid4, но похоже уменьшить величину столбика до нужного размера не удастся и как следствие загрузить все 6 дисков.

Ну вот "раньше" ("плохие файлы") загрузка постепенно вращалась между дисками. То есть ada1/ada6 (в данном примере) не были всегда нулевыми.

Сейчас же - там строго нули. Меня это раздражает и так как все едино данные опять двигать, я думаю туда 7-й диск докупить, благо на новой материнке 8 портов, а не 6.

Ты хочешь сказать, что сейчас raidz2 на 6 дисках превратился в полный аналог raid4 с двумя дисками чётности? Хотя, если сейчас никто не дробит блоки и все записываемые блоки идеально деляться на 4 и минимальный размер записываемого блока 4х4=16kB, то всё наверно может быть :-). Но как по мне, если это так, то это тоже не нормально. Ещё вопрос, если это диски со скоростью 200MB/s, то кто съел 50MB/s? Хотя может быть это пролёт над метаданными или чтение ближе к концу дисков. Если гипотеза о raid4 подтвердится, то получается, что на многопоточной нагрузке 7 дисков в raidz2 явно будут смотреться лучше (там всё должно размазаться, но проверить желательно). Да, чем больше я "приобщаюсь" к raidz2 тем больше вопросов возникает. Получается эффективность при последовательном чтении чуть больше 50% (610/1180).

Там не 200. Там 185/120 (начало, хвост) у быстрых и 162/113 у более медленных.

Это dd if=/dev/ada.. of=/dev/null bs=1m skip=0m/5m

Пул заполнен на 44%, куда лег тестовый файл - хрен пойми (ну то есть zdb пойми, но я не буду в его выдаче разбираться)

Тогда вполне нормально.

Сделал датасет с recordsize=128k. Там оно выглядит не столь позорно:

device     r/s   w/s     kr/s     kw/s  ms/r  ms/w  ms/o  ms/t qlen  %b
ada1      1733     0 126703.6      0.0     0     0     0     0    0  57
ada2      1611     0 124128.9      0.0     1     0     0     1    0  59
ada3       984     0  83488.9      0.0     1     0     0     1    2  50
ada4      1260     0 126317.5      0.0     1     0     0     1    3  70
ada5       858     0  83709.9      0.0     1     0     0     1    0  57
ada6      1082     0 123662.8      0.0     2     0     0     2    3  79

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

При этом, 7-й диск добавляет изрядно: http://blog.lexa.ru/2016/12/06/freebsd_zfs_read_speed_oni_ubili_kenni.html

И я его таки буду ставить, потому что данные все едино двигать придется.

Действительно веселее :-). Значит распределение контрольных блоков зависит от разных причин. Для raidz2 больший recordsize явно предпочтительней. Я бы ещё потестировал 512kB на 6 дисковой конфигурации, это избавит стек ввода-вывода от дополнительной разборки/cборки запросов (все запросы к данным =MAXPHYS), хотя выгода наверно мизерная, но зато немного снизится латентность.
В 7 дисковом raidz2 ты явно получишь плюс полную скорость добавленного диска как по чтению, так и по записи (наверно даже ещё больше). А из минусов - получается только небольшие (~1%) дополнительные потери по занимаемому объёму. Плюсов намного больше :-).
Если всё равно будешь двигать данные, то могу на почту выслать все мои "гайки". Может что-то подскажет, а может понравится :-). Только адрес сбросишь.

Гайки без комментариев смысла не имеют.

Гайкам с комментариями буду очень рад, потому что читать исходники я вот точно не буду, а документации на новомодные гайки практически нету (Evil tuning guide, но оно не безумно новое)

Никаких исходников, всё предельно просто. Просто моё понимание/опыт на данный момент как выжать максимум из дисков. Почта нужна что бы послать один файл (если захочешь попробовать).

или сравнить).

А, я не понял вопроса.

Мой e-mail общеизвестен (и если любую страницу проскроллить до низа, он там есть): lexa@lexa.ru

А вот тот же пул, другой датасет, совсем большие файлы (кино)

ada1      1143     0 146271.7      0.0     0     0     0     0    0  37
ada2       728     0  93202.3      0.0     0     0     0     0    0  23
ada3       730     0  93349.3      0.0     1     0     0     1    0  29
ada4      1143     0 146271.7      0.0     0     0     0     0    0  44
ada5       416     0  53216.5      0.0     1     0     0     1    0  24
ada6       413     0  52922.4      0.0     1     0     0     1    0  16

 

Висит не очень ровно, но хотя бы два диска не стоят.

recordsize=1m

Файлы созданы tar xvf

Ничего не понимаю.

А на следующем датасете - опять два стоят. Бардак в стране

  raidz2             22,4T  10,1T    572      0   568M      0
    gpt/6G-2RG0BNRJ      -      -    569      0   142M      0
    gpt/6G-2RG0DGLG      -      -    569      0   142M      0
    gpt/6G-2RG6GKHR      -      -    568      0   142M      0
    gpt/6G-K1GJRNVD      -      -    570      0   142M      0
    gpt/6G-K1GK3S3D      -      -      1      0   101K      0
    gpt/6G-NCGPM4VS      -      -      0      0      0      0

 

Если я правильно понял - 6T диски перекочевали на адаптек? Если это так, то интересно как изменилась начальная скорость у дисков? По поводу "бардака" напишу ниже и начну новый комментарий, а то мало места :-).

Нет, 6T - сейчас на чипсетном контроллере (с236). До того были на LSI.

Вообще же - описывать миграцию железа на моих двух ящиках - это можно сагу писать.

Как по мне, то висит очень даже ровно :-).
932002 + 53216 = 146418

Хочется же 6x140

Я уже начал писать про "6х140" в новом комментарии. Но всё же интересно - какая начальная скорость дисков стала на интеловском чипсетном контроллере?

Я же тут где-то писал, 195-198 у быстрых и 162 у медленных.
На LSI было вроде бы чуть быстрее, типа 205 и 175.

Сегодня я в этот ящик еще раз полезу, потому что 7-й диск уже заказан, через часа полтора заберу, суну тогда LSI еще раз и еще раз посмотрю

Странно, интеловский контроллер всегда был одним из самых быстрых и имел самую низкую латентность. А точно включен режим AHCI ?

Ну по идее и интел и LSI должны сильно больше 2 гигабит уметь уж в любом случае.

Залезу туда по локоть сегодня - посмотрю и в BIOS.

Грузится так:
ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
ada1: ACS-2 ATA SATA 3.x device

Подозреваю что апчхи - включен.

У меня давненько не было современных матерей, а в старых данный режим включался в биосе. Для dd с bs=1M скорость чтения в начале у меня обычно немного превосходила даташитовскую.

В современных AHCI - скорее всего default, я уж и забыл чтобы менял.

Боюсь сглазить :-).
Посмотрел даташит у HE8 6T - 195MB/s.
Нашёл в старом посте:
fiolog3: read : io=18942MB, bw=193363KB/s, iops=188, runt=100312msec.

Я запутался и перемерял и не вижу теперь 160.
По очереди, потому что я не знаю как fio хвост померять, поэтому dd bs=1m count=5k:
He8: 196/122 голова/хвост (skip=5m). Это десятичные гигабайты, три старшие значащие цифры в выводе dd
7k6000: 227/125
Контроллер интел, пул экспортирован, IO нет.

160 получается при skip=2m (т.е. "скорость серединки"), сейчас уже не восстановить откуда цифра.

Чтобы сунуть LSI-контроллер - надо питальник отвинчивать. Я уже так утомился с этим ящиком, что не буду.

Успокоил :-))).
Для fio смещение задаётся - offset=5t. Я отлаживаю/тестирую только в начале, а дальше всё должно быть хорошо :-).

I like to move it, move it, move it.
С ящика на ящик, места впритык, поэтому пишу на zpool на котором вообще-то бэкапы.
Подключено к контроллеру на Z68 и там два порта SATA3 (один - системный SSD, второй - часть тома) и 4 порта SATA2.
И видно, насколько эти порты разные, причем SATA2 - лучше.

(впрочем, возможно что там SATA3 вообще сделаны на каком-то левом чипе, не полезу в спеки)

Да, ahci включен с ходу, не менял.

Да, при этом 5-дисковый raidz1 ведет себя нормально, там чтение по всем 5 дискам размазано.
То есть похоже вот этот самый "сдвиг контрольной суммы через мегабайт" попадает всегда в одну дырочку.

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

Или может быть на системе (где raidz1) минимальный размер записымаемого блока меньше, даже не знаю.

raidz1 - recordsize и ashift такие же (1m/12)

Те же диски, новый пул (-O recordsize=1m), dd блоками по 1m:

ada1      1368     0 175206.3      0.0     0     0     0     0    0  36
ada2       689     0  88217.6      0.0     2     0     0     2    0  35
ada3       686     0  87859.2      0.0     1     0     0     1    0  27
ada4       678     0  86912.0      0.0     3     0     0     3    5  45
ada5      1366     0 174873.5      0.0     2     0     0     2    5  82
ada6       681     0  87296.0      0.0     2     0     0     2    2  40

 

Явно получше, минимальная скорость поднялась до 175MB. Я внизу описал, чего по моему мнению следует ожидать. Думаю только 175/195=0,9 оставляет шансы немного повысить скорость чтения, но наверно незначительно.
Кстати у того же calomel-я "минимальная_скорость_чтения" на такой же конфигурации всего 0,68 от даташитовской :-).

Ну да, получше, но я не понимаю что происходит.
Те же диски. Та же конфигурация пула (и диски, скорее всего, в том же порядке в командную строку попали потому что /dev/gpt/6G-* т.е. алфавитный порядок)
Та же машина, материнка, контроллер. Все то же.

Разница вот только в том, что "тот" пул был создан на "той, кривой" FreeBSD, а этот сейчас - на 11.0-releng

Для raidz порядок вхождения дисков в пул не играет никакой роли, все по любому будут равнятся на самый медленный, что по записи, что по чтению. Такой уж дизайн :-). Ту проблему на которую ты наткнулся mav понятно описал и я не вижу какая может быть связь. Может действительно тогда скорость диска была 142/0,9=158 MB/s на тестируемом участке, а не 195MB/s, как сейчас?

Там могут быть и другие проблемы, на которые я не наткнулся (или, точнее, не сумел отрепортить так, чтобы начали чинить).

При этом, понятно, вот с этим пулом из 6Tb-дисков я, после его заливки в начале ноября, экспериментировал уже с заполненным наполовину, то есть примерно с серединками дисков же.

Но зато есть "необъяснимо низкая" скорость чтения массива 7xHDD raidz2 с recordsize=128k. Она /примерно/ такая же как у raidz2 6xhdd и как у raidz3 7xhdd.
При этом с записью все ок, она заметно быстрее (700 и 800Mb/sec). И с recordsize=1m все хорошо и r и w.

Так как я 128k не собираюсь использовать вовсе (у меня один датасет 64k, остальные 1m) то мне плевать, но тем не менее вот такое наблюдение (воспроизводимое, два раза перемерял с разрушением датасета)

Тьфу, прямо вот "мы ведем свой репортаж"
raidz1 7xhdd - тоже медленный. Изрядно медленный.

Вечером опубликую табличку суммарную.

128к на 7 дисковом raidz2 имеет сдвиг контрольных сумм на 5 дисков на каждой recordsize и там такой патерн получается, что мало чего объединяется в MAXPHYS при агрегации запросов на диск (да ты и сам можешь посмотреть размер среднего запроса). А на 7дисковом raidz2 дотянул по чтению до 900MB/s?

Как считать мегабайты. В десятичном виде - дотянул. Если считать что в мегабайте 2^20 байтов, то 860 :)

7-дисковый raidz1 (не два): 550 запись и 900+ чтение, результат устойчивый.

Короче, ждите вечером отчета (и он будет финальным - я задолбался и начинаю возвращать данные взад)

Я, как и все производители дисков, перешёл на десятичные мегабайты, да так оно и удобнее :-). Ладно дождёмся твоей таблицы ;-).

таблицу тогда тоже сделаю в десятичных мб, так проще и мне.

В-общем, надо было не последовательно идти, а делением пополам.
FreeBSD 10.1, 10.2, 10.3, 11.0 - все зашибись.
12-CURRENT (snapshot от 30 ноября - флешка готовая) - вышеописанная жопа.

Задумался как аккуратно сделать даунгрейд, блин. Но кажется при установленной compat-11 можно (попробовать :)

CURRENT ведь для любителей нетрадиционного секса. А у Вас "боевой "сервер"".
Опытные товарищи строго рекомендуют сидеть на предыдущей мажорной версии FreeBSD.

"Много лет ничего не было", а было, наоборот, хорошо.

Интересно, чем таким хитрым raidz2 отличается от raidz1?

Еще одним блоком четности на отдельном шпинделе, то есть это "как RAID6"

Как и всегда в HEAD, в ядре 12 по дефолту включена куча дебага, которая негативно влияет на производительность. Точно весь дебаг повыкидыван из ядра перед тестами?

Да, тут ядро без WITNESS/INVARIANTS

А вот тесты с memstick (следующая запись) - ну какой был мемстик, такой и был. То есть 12-current там с отладкой. Но качественно на результат это не влияет.

upd: вспомнил еще, в прошлый подход к снаряду я сравнивал
GENERIC
GENERIC-NODEBUG
GENERIC-NODEBUG + увеличенный MAXPHYS

И принципиальной разницы (скорость чтения то падает ВДВОЕ) не увидел.

Там гораздо больше, чем только WITNESS/INVARIANTS. В GENERIC/head:

# For full debugger support use (turn off in stable branch):
options BUF_TRACKING # Track buffer history
options DDB # Support DDB.
options FULL_BUF_TRACKING # Track more buffer history
options GDB # Support remote GDB.
options DEADLKRES # Enable the deadlock resolver
options INVARIANTS # Enable calls of extra sanity checking
options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS
options WITNESS # Enable checks to detect deadlocks and cycles
options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed
options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones

Ну да, и на то есть kernconf=GENERIC-NODEBUG

Вижу тебя продолжает беспокоить неравномерность загрузки дисков в raidz2, поэтому попробую разложить всё по полкам. Рассмотрим raidz2 из 7дисков, recordsize=1M, sectorsize=4k (ashift=12) и идеальный случай - на большом участке расположены только данные (метаданными пока пренебрегаем). Recordsize формируется так: на двух дисках контрольные суммы по 52х4k, на одном диске данные 52x4k и на четырех дисках - данные 51x4k. Получается у следующей recordsize контрольные суммы сдвинуты на три диска и так по кругу (для лучшего представления желательно нарисовать эту картинку на бумаге). Возврат контрольных сумм на исходные диски произойдёт через 7 recordsize (получается патерн расположения данных и контрольных сумм у каждого диска повторяется каждые 7 recordsize). Сам патерн имеет такую последовательность: контрольная сумма (52х4k), данные (51х4k), опять контрольная сумма (52х4k) и самый длинный непрерывный участок данных на диске - (51+52+51+51)х4k. Теперь оценим длину дорожки диска. Пусть в начале диска скорость чтения равна 180MB/s и скорость вращения 7200rpm, тогда информационная емкость дорожки в начале диска будет больше 180/120=1,5MB (больше потому что необходимо учитывать время перехода на следующую дорожку/цилиндр). Отсюда вытекает, что все диски при чтении будут задействованны, будут проходить все дорожки и вычитывать только ~71% (256/360) данных их общего количества данных на дорожке. Небольшой выигрыш видится только в случае, если контрольная сумма попадёт в конец дорожки и можно будет раньше начать переход на следующую дорожку/цилиндр, хотя и здесь есть сомнения. В итоге получаем, что верхний потолок скорости одного последовательного чтения на raidz2 из 7 дисков не будет превосходить 7*0,71*(скорость_самого_медленного_диска), то есть получили почти 5*(скорость_самого_медленного) и это в идеальном случае. На реальных данных должно быть ещё ниже :-(.
Теперь рассмотрим 6 дисков в raidz2. Ты наблюдаешь чтение только с 4 и значит верхний потолок не более 4*(скорость_самого_медленного) :-). Если происходит "не частое" смещение контрольных сумм и начинается чтение со всех дисков, то видно, что сумарная скорость чтения не изменяется :-). Поэтому всё аналогично.
Берём данные из таблицы твоего следующего поста и проверяем. Для raidz2 из 6 получаем скорость "самого медленного" 521/4=130MB/s и для raidz2 из 7 - 659/5=132MB/s. Всё сходится до +- погрешность, хотя в первом случае при чтении задействованы были 4 диска, а во втором 7 :-). Можно ещё предположить, что скорость рельного "самого медленного" WD1003FBYX была где-то на 10% выше.
Но у конфигурации из 6 есть "теоретический" ресурс. Если бы при записи смена дисков для контрольных сумм происходила для одного диска на величину больше длины дорожки (допустим 2MB), то можно было бы при соответствующем увеличении окна префетча задействовать все диски и получить условно "через-дорожечное" чередование. Это дало бы ощутимый прирост скорости последовательного чтения. В алгоритме балансировки зеркала в zfs применено "через-дорожечное" чередование, поэтому разработчикам известен этот приём и наверно есть весомые причины почему он не применён в некоторых подходящих конфигурациях raidz, хотя кто его знает ;-).
Вот как то так.

Add new comment