Пятница - день установки патчей
lexa - 11/Авг/2017 18:43
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
чтение метаданных в каталоге с 5000 равчиками
Возник вопрос: эти метаданные читаются из "тела" каждого файла? и если да, то каков средний их размер?
Да, из тела.
Да, из тела.
Там "десятки килобайт" (т.е. 0.1%).
Вообще, конечно от формата
Вообще, конечно от формата зависит.
Может быть "десяток килобайт", может наверное быть и "килобайты".
Может быть вовсе ноль, но это редкий случай (дамп сенсора)
"десяток килобайт"
Под просмотром большого каталога я понимал получение только информации о файлах данного каталога, а здесь немного другая задача. Для hdd в raidz и recordsize=1m оно как бы по определению не может быть быстро. По сути определяющим будет время случайного доступа большими блоками, а у zfs в данной конфигурации с этим проблемы.
Ну вот тем не менее - мне
Ну вот тем не менее - мне кажется, что это место тоже стало быстрее.
Сам по себе листинг 5к файлов - вменяемо быстрый и так.
чтение метаданных в каталоге с 5000 равчиками
А ведь получается, что это почти идеальный патерн для работы L2ARC. В связи с планами перехода на 11.1 начал присматриваться и к кешированию на ссд. Можешь показать zfs-stats -IE?
ZFS-stats у меня не
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:
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
Если можно, ещё iostat -Ix одного hdd из пула и ssd (L2ARC). А я за причинённые хлопоты, постараюсь, что-то подсказать. Может и пригодится :-).
Пулlexa@home-gw:~/LibRaw#
Пул
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
ZFETCH hits: 0 0 0 0
Я не пользуюсь zfs-mon и сразу не соображу, что это значит. Нужно будет посмотреть. Но если при primarycache=metadata происходит файловая упреждающая выборка (интересно куда и зачем?), а затем её результат сразу выбрасывается, то это похоже на баг :-). Вечером постараюсь проверить.
primarycache=all
primarycache=all
secondarycache = metadata
Тогда всё попадает в ARC и до
Тогда всё попадает в 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
Сегодня обратил внимание. Ты же вроде боролся с вымыванием кеша? И ещё - если затем следует верификация, то часть данных может быть прочитана из кеша. Тогда какой смысл в верификации?
Я сейчас и не вспомню почему
Я сейчас и не вспомню почему поменял, но кажется совсем уж без кэша получается совсем уж медленно (не столько акронисом, там ок, сколько тайм-машинами маковскими, хотя они ходят всего-то по гигабиту)
А если primarycache=all, то
А если 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
(лучше конечно моноширинным)