Пятница - день установки патчей

1. Закрыл гештальт с OS X 10.11.6: обновляется clover, потом накатывается апдейт

Можно не ставить инсталлятором, а два .EFI-файлика заменить (замену брать, к примеру, вот тут).

2. В комментариях навели на вот это вот: https://svnweb.freebsd.org/base?view=revision&revision=317064

Этот патч уже вошел в FreeBSD 11.1 (у меня была 11.0), обновился на нее.

Мне показалось что с большими каталогами по самбе действительно стало работать сильно быстрее. Каких-то тестов не делал, но вот чтение метаданных в каталоге с 5000 равчиками было медленно, а стало более вменяемо.

 

Comments

Возник вопрос: эти метаданные читаются из "тела" каждого файла? и если да, то каков средний их размер?

Да, из тела.
Там "десятки килобайт" (т.е. 0.1%).

Вообще, конечно от формата зависит.
Может быть "десяток килобайт", может наверное быть и "килобайты".

Может быть вовсе ноль, но это редкий случай (дамп сенсора)

Под просмотром большого каталога я понимал получение только информации о файлах данного каталога, а здесь немного другая задача. Для hdd в raidz и recordsize=1m оно как бы по определению не может быть быстро. По сути определяющим будет время случайного доступа большими блоками, а у zfs в данной конфигурации с этим проблемы.

Ну вот тем не менее - мне кажется, что это место тоже стало быстрее.

Сам по себе листинг 5к файлов - вменяемо быстрый и так.

А ведь получается, что это почти идеальный патерн для работы L2ARC. В связи с планами перехода на 11.1 начал присматриваться и к кешированию на ссд. Можешь показать zfs-stats -IE?

ZFS-stats у меня не показателен совсем т.к. L2 разрешен только на некоторых датасетах. А скажем там где кино и подобное - нет, соответственно цифры заниженные.

Реальная эффективность кэша при работе именно с равчиками - процентов 70-90 получается в зависимости от интенсивности работы с каталогом. Это по zfs-mon.

Сейчас zfs-stats показывает вот такое, но
а) маленький аптайм, я апгрейдился же
б) я делал эксперименты именно по кэшируемости в L2 (вот тот самый tar cf /dev/null large-folder, который обсуждали уже весной), поэтому цифры выше реальных

FreeBSD 11.1-RELEASE-p1 #1 r322394: Fri Aug 11 12:55:37 MSK 2017 lexa
11:57AM  up 3 days, 22:58, 1 users, load averages: 0,10 0,18 0,16

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

ARC Efficiency:                                 18.33m
        Cache Hit Ratio:                62.16%  11.39m
        Cache Miss Ratio:               37.84%  6.94m
        Actual Hit Ratio:               39.41%  7.22m

        Data Demand Efficiency:         88.11%  6.67m
        Data Prefetch Efficiency:       32.53%  8.21m

        CACHE HITS BY CACHE LIST:
          Anonymously Used:             29.74%  3.39m
          Most Recently Used:           37.30%  4.25m
          Most Frequently Used:         26.11%  2.97m
          Most Recently Used Ghost:     1.35%   154.11k
          Most Frequently Used Ghost:   5.50%   626.04k

        CACHE HITS BY DATA TYPE:
          Demand Data:                  51.59%  5.88m
          Prefetch Data:                23.45%  2.67m
          Demand Metadata:              6.07%   691.54k
          Prefetch Metadata:            18.88%  2.15m

        CACHE MISSES BY DATA TYPE:
          Demand Data:                  11.44%  793.43k
          Prefetch Data:                79.90%  5.54m
          Demand Metadata:              8.28%   574.23k
          Prefetch Metadata:            0.39%   26.77k

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

Спасибо. Всё равно интересно. А какой объём ARC и L2ARC на этой машине?

ARC Size: 55.76% 16.17 GiB
Target Size: (Adaptive) 55.76% 16.17 GiB
Min Size (Hard Limit): 12.50% 3.62 GiB
Max Size (High Water): 8:1 29.00 GiB

L2: сейчас занято 258G из 500 возможных.

Да, вот по опыту.
Реальные цифры от реальной моей работы с L2 (без тестов на забитие кэша) начинаются через 2-3 недели аптайма.

Реальный аптайм (не летом) - ну вот с сентября по июнь.

Если можно, ещё iostat -Ix одного hdd из пула и ssd (L2ARC). А я за причинённые хлопоты, постараюсь, что-то подсказать. Может и пригодится :-).

Пул
lexa@home-gw:~/LibRaw# iostat -Ix ada1
extended device statistics
device r/i w/i kr/i kw/i qlen tsvc_t/i sb/i
ada1 1033717.0 318054.0 105220584.5 21312396.0 0 7152.0 2879.3

SSD:
lexa@home-gw:~/LibRaw# iostat -Ix nvd0
extended device statistics
device r/i w/i kr/i kw/i qlen tsvc_t/i sb/i
nvd0 10021895.0 2139627.0 1280477009.0 271255656.5 0 16580.2 1359.5

(но есть второй пул, на других дисках - и статистика ZFS, понятно, суммарная)

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

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

Я почти уверен, что статистика сильно испорчена моими экспериментами.

А в ситуации, когда я смотрю на живую (zfs-mon) и понятную (*) статистику - там эффективность префетча сильно выше.

(*) имеется в виду, что в это время на сервере нету, к примеру, большого бэкапа и/или верификации бэкапа.

Это понятно и период небольшой, но экперименты иногда дают для понимания больше информации. А сколько по памяти приблизительно был процент попадания в ARC за длительный период с использованием L2ARC.

Меня два месяца (с небольшим перерывом) не было дома, не помню ничего по памяти.

Вот запустил верификацию бэкапа. Вижу такое:

ZFS real-time cache activity monitor
Seconds elapsed: 197

Cache hits and misses:
                                  1s    10s    60s    tot
                     ARC hits:   398    332    368    264
                   ARC misses:   336    292    323    232
         ARC demand data hits:   335    286    314    224
       ARC demand data misses:     0      0      0      1
     ARC demand metadata hits:     2      2      2      2
   ARC demand metadata misses:     0      0      0      0
       ARC prefetch data hits:    61     43     50     38
     ARC prefetch data misses:   336    292    323    231
   ARC prefetch metadata hits:     0      2      2      1
 ARC prefetch metadata misses:     0      0      0      0
                   L2ARC hits:     0      0      0      0
                 L2ARC misses:   336    292    323    232
                  ZFETCH hits:  1458   1361   1525   1085
                ZFETCH misses:  2662   2473   2617   1792
           VDEV prefetch hits:     0      0      0      0
         VDEV prefetch misses:     0      0      0      0

Cache efficiency percentage:
                          10s    60s    tot
                  ARC:  53.21  53.26  53.23
      ARC demand data: 100.00 100.00  99.56
  ARC demand metadata: 100.00 100.00 100.00
    ARC prefetch data:  12.84  13.40  14.13
ARC prefetch metadata: 100.00 100.00 100.00
                L2ARC:   0.00   0.00   0.00
               ZFETCH:  35.50  36.82  37.71
        VDEV prefetch:   0.00   0.00   0.00

Это, конечно, повод еще раз подумать про размер записи на бэкапном томе....

Но доля бэкапов-верификаци в общем ZFS-трафике у меня очень велика.

Собственно вот:
 

 zpool iostat
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zbackup     3,05T  1,48T     12      6  10,9M  1,89M
zdata       16,8T  21,2T      2      2  2,03M   291K
----------  -----  -----  -----  -----  -----  -----

90% В записи и 80 в чтении.

Вот запустил бэкап (стадия записи).
zfs-mon -a кажет:
ZFETCH hits: 0 0 0 0
ZFETCH misses: 5760 7632 6172 6172

Понятно откуда плохая (общая) статистика по Zfetch

Я не пользуюсь zfs-mon и сразу не соображу, что это значит. Нужно будет посмотреть. Но если при primarycache=metadata происходит файловая упреждающая выборка (интересно куда и зачем?), а затем её результат сразу выбрасывается, то это похоже на баг :-). Вечером постараюсь проверить.

primarycache=all
secondarycache = metadata

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

Сегодня на свежую голову ещё раз глянул и понял, что моя интерпретация статистики префетча была неверна. Для понимания прочитал файл в 262144 рекордсайз (файл точно читался первый раз) и вычленил статистику:
CACHE HITS BY DATA TYPE:
Demand Data: 197533
Prefetch Data: 2

CACHE MISSES BY DATA TYPE:
Demand Data: 170
Prefetch Data: 261974

Получается CACHE MISSES чесно показал, что данных в кеше не было (170 + 261974=262144) и префетч послал 99,9% запросов. А вот с CACHE HITS поинтереснее :-). Получается, если запрос от приложения пришёл в ARC, когда ещё выполнялся запрос префетча, то хит не начисляется, а если рекордсайз уже была к этому времени прочитана, то начисляется. Prefetch Data: 2 - списываю на то, что на пуле в это время был ещё один не очень активный пользователь. В итоге получается, что первое чтение файла дало в статистику (только по данным) 100% MISSES и 75% HITS от размера файла :-). По метаданным понятно, что хитов было значительно больше. И кстати, у меня Data Prefetch Efficiency ещё меньше, чем у тебя :-), что теперь тоже вполне объяснимо.

Меня вот больше интересует, что такое ZFETCH miss при записи.
Ну то есть следует принять как данность, что при записи там все (примерно) miss, ну и успокоиться.

Если честно, то я не совсем понимаю что такое ZFETCH (только догадываюсь :-)). miss может быть только у чтения. А запись новых файлов или поверх старых?

Новые файлы.

Вот надо таки прочитать исходники zfs-mon, тогда будет понятно какие переменные оно так обзывает

Разумно :-).
Ещё спрошу - NVMe ssd в FreeBSD не было проблем? И вот ещё - после опыта эксплуатации при выборе NVMe ssd на что обратить внимание?

Не было проблем. Но эта штука покупалась ровно под L2ARC, никаких других файловых систем там нет и не планировалось. Загрузка тоже не с нее.

"на что обратить внимание" я, честно говоря, не знаю, потому что у меня это вот единственный nvme под FreeBSD, он сразу завелся и стало хорошо.
Я выбирал из следующих соображений
- скорость чтения (!) - особо высокая не нужна, я все едино по 10G туда хожу, т.е. гигабайт с копейками - более чем. Скорость записи - ну тем более.
- "гарантированный объем записи" - с учетом того, что в реальности он много больше, чем заявляет производитель - особо на этот параметр не смотрел.
- и с учетом первого момента - выбрался Patriot Hellfire. Он сильно медленнее других моих NVME-шек (числом два: 950-й самсунг "под систему" и плекстор M8Pe "под локальные файлы), но и сильно дешевле, раза в полтора.
Смотрел еще на Intel 600p (еще дешевле), но он еще медленнее и уже медленее 10G.

Эксплуатация - ну скажем месяца три активных (минус лето, когда на эти тома никто не писал), за это время записано - 10Tb (т.е. 20 раз перезаписан). Заявленный ресурс - кажется 400Tb, то есть даже формального ресурса хватит, при таком же использовании, на ~10 лет.

Спасибо. Я пока оставил в претендентах 950-960 самсунг и M8PeY :-) (правда ещё соблазняет по сходной цене почти новый Intel 750). После чтения обзоров беспокоит нагрев и возможный троттлинг, особенно у M8PeY. У меня пока главные критерии выбора - скорость записи на уже заполненном ssd и производительность при смешанной нагрузке. Хочу ещё посмотреть как, L2ARC освобождает место под новые записи после полного заполнения. Заметил у тебя пишет и читает в среднем почти по 128kB, значит пишет в основном данные. А у меня слабое место промахи метадаты. Вот и родилась идея загнать всю её L2ARC :-). Получается если будет сжатие, то средний размер записи может быть сильно меньше.

Сегодня обратил внимание. Ты же вроде боролся с вымыванием кеша? И ещё - если затем следует верификация, то часть данных может быть прочитана из кеша. Тогда какой смысл в верификации?

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

А если primarycache=all, то тогда точно нет никакого смысла в recordsize=64k (особенно для бекапов). Кстати, недавно узнал, что если размер файла меньше recordsize, то размер записи добивается до ближайшего кратного ashift. А вот если больше recordsize, то последняя recordsize уже не обрезается. Для меня пока не понятна сия логика :-).

Ну решили что оверхед меньше 50% - не оверхед :)

А вот верификация для бэкапа, который сделали на recordsize=64k (отчего скорость верификации упала и верну я обратно 1m):

ZFS real-time cache activity monitor
Seconds elapsed: 155

Cache hits and misses:
                                  1s    10s    60s    tot
                     ARC hits:  2491   2696   2772   2706
                   ARC misses:  2283   2595   2643   2573
         ARC demand data hits:  2224   2549   2613   2542
       ARC demand data misses:    21     19     19     19
     ARC demand metadata hits:    17     18     17     16
   ARC demand metadata misses:     0      0      0      0
       ARC prefetch data hits:   246    125    138    145
     ARC prefetch data misses:  2262   2576   2623   2554
   ARC prefetch metadata hits:     4      4      4      4
 ARC prefetch metadata misses:     0      0      0      0
                   L2ARC hits:     0      0      0      0
                 L2ARC misses:  2283   2595   2643   2573
                  ZFETCH hits:  1295   1536   1561   1524
                ZFETCH misses:  1190   1313   1348   1314
           VDEV prefetch hits:     0      0      0      0
         VDEV prefetch misses:     0      0      0      0

Cache efficiency percentage:
                          10s    60s    tot
                  ARC:  50.95  51.19  51.26
      ARC demand data:  99.26  99.28  99.26
  ARC demand metadata: 100.00 100.00 100.00
    ARC prefetch data:   4.63   5.00   5.37
ARC prefetch metadata: 100.00 100.00 100.00
                L2ARC:   0.00   0.00   0.00
               ZFETCH:  53.91  53.66  53.70
        VDEV prefetch:   0.00   0.00   0.00

на этом разделе - secondarycache=metadata.

У меня тоже есть датасет /backup c primarycache=metadata. На машине только ARC ограниченный 14GB. Файловая упреждающая выборка включена (правда я туда только каждый час сбрасываю), но подобной картинки не наблюдаю.

ZFS Subsystem Report Tue Aug 15 17:03:09 2017
------------------------------------------------------------------------
FreeBSD 11.0-RELEASE-p3 #14: Sun Nov 13 13:40:47 EET 2016 admin
5:03PM up 81 days, 8:32, 1 users, load averages: 0.16, 0.08, 0.05

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

ARC Efficiency: 232.33m
Cache Hit Ratio: 80.84% 187.83m
Cache Miss Ratio: 19.16% 44.50m
Actual Hit Ratio: 80.70% 187.48m

Data Demand Efficiency: 97.05% 28.92m
Data Prefetch Efficiency: 25.65% 1.16m

CACHE HITS BY CACHE LIST:
Anonymously Used: 0.11% 214.08k
Most Recently Used: 2.64% 4.95m
Most Frequently Used: 97.18% 182.53m
Most Recently Used Ghost: 0.04% 67.39k
Most Frequently Used Ghost: 0.03% 63.87k

CACHE HITS BY DATA TYPE:
Demand Data: 14.95% 28.07m
Prefetch Data: 0.16% 296.35k
Demand Metadata: 84.87% 159.41m
Prefetch Metadata: 0.03% 50.44k

CACHE MISSES BY DATA TYPE:
Demand Data: 1.92% 853.44k
Prefetch Data: 1.93% 858.99k
Demand Metadata: 96.09% 42.77m
Prefetch Metadata: 0.06% 26.43k

(лучше конечно моноширинным)

Add new comment