mdadm [я просто оставлю это здесь]

Given a working set close to ARC size an L2ARC can actually hurt performance. If a system has a 14GB ARC and a 13GB working set, adding an L2ARC device will rob ARC space to map the L2ARC. If the reduced ARC size is smaller than the working set reads will be evicted from the ARC into the (ostensibly slower) L2ARC.

Это как минимум надо понимать про L2ARC. Но дальше надо гуглить.

Из ZFS best practice http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide

In addition to the in-memory ARC cache, ZFS employs a second level, L2ARC on-disk cache. In a typical configuration, there would be large pool of spindle disks, and a smaller number of SSD's or other high performance devices dedicated to cache. Using L2ARC cache devices may accelerate read operations, especially when some data is read repeatedly, and cannot fit in the system memory ARC cache. This is particularly likely when active processes are consuming the system memory, and in high performance machines which may already be maxed out for RAM. For example, if a machine maxes out at 128G ram, and requires 120G of ram for active processes, and frequently needs to read some data files from disk, then performance could likely be increased by adding a few hundred G of SSD cache devices.

Ты посмотри - у тебя то твои l2arc, забиты полностью?

Кэши разогреты, uptime большой очень.

Ты знаешь, а вот с трудом верится мне, в эффективность работы L2ARC, если не особо вникаешь чего делаешь... Да и zil тоже.

Я говорю это не того ради, чтобы показаться умным, но я испытываю некоторые сомнения, и вот смотри почему! Я высказываю свои мысли и понимания по данному вопросу, и предлагаю тебе покритиковать меня, а может быть и в чём-то согласиться со мной! Пишу я всё это не просто так, я собираюсь крутить и дальше довольно серьёзный продакшн на zfs. И мне хочется понять..!

Поехали:

• zil (по-умолчанию), будет отрабатывать только на синхронную запись. То есть она никак не поможет быстро сложить фоточки в виртуалочке, или нечто подобное на вроде cp /tmp/a /tmp/b. Когда мы в zvol размещаем том, и говорим kvm - что вот тебе O_DIRECT, то внутри вирт. машины, появляется возможность открывать файлы как в async, так и sync режиме. И не более того! В общем случае, zil поднимет скорость записи в СУБД. И не более. То есть, в общем случае мало того, что zil, не имеет смысла делать более 3-5gb (максимум формула, это: теоретическая скорость записи всего RAID*5, ибо синк из zil на блины по умолчанию идёт раз в пять секунд. Ну тут пруфов - вагон и телега), так и нужно понимать, что чуда не будет, и вся async будет писаться сразу на блины.
• то что ты, используешь в zil десктопные диски - ходишь по лезвию ножа. Не в том плане, что там MLC. А в том, плане, что в десктопных SSD нету защиты от внезапного пропадания питания. И если хост резко зависнет или останется без питания - совершенно точно пропадёт часть данных, с весьма печальными последствиями.
• как работает ARC+L2ARC? - Всё что не помещается в ARC, с энной периодичностью и энным объёмом уходит в L2ARC. см: l2arc_write_max, l2arc_headroom.
• какова цена за L2ARC? - Цена очень высокая! И вот почему: по-умолчанию, L2ARC, отжирает 1/4 от ARC своими метаданными, вот пруф: arc_meta_limit. Можно посмотреть текущее положение вещей: arc_meta_used, l2_hdr_size. И есть формула: 1/5. Вот не уверенный, но всё же пруф: https://forums.freenas.org/index.php?threads/formula-for-size-of-l2arc-needed... - более другие пруфы, тоже можно найти. То есть, если ARC, ограничен размером, в 10гб, то лишь 2гб, уйдут для l2arc, а следовательно, l2arc, больше чем 10гб - смысла не имеет ровном счётом никакого. И даже более того, я не однократно встречал сообщения в Интернет, когда люди добавляя l2arc большого размера, не думая, получали не то что падения производительности, а и вовсе серьёзные проблемы, вплоть до глюков и зависаний всего этого добра!
• как работает ARC в ZoL? - Работает, оно след. образом: отжирает до zfs_arc_max, и отдавать оно будет его только тем процессам, которые УЖЕ запущены в ОС. То есть, если памяти свободной не будет на сервере, при запуске очередного kvm, получим: «unable to allocate of memory». По сему, ARC нужно тюнить. И это похоже по большей части особенность именно реализации в ZoL.
• l2arc будет держать в себе лишь самые часто запрашиваемые данные, т.е. основное чтение всё равно будет идти с блинов. И чуда тут снова - никакого нету.
• в ZoL, нету грамотного планировщика при чтении из mirror дисков, т.е.: если в зеркале три диска, ускорения в 3x на чтении не получим. В ZoL, только round robin чтение. - Пруф из рассылки ZoL, потерял, к сожалению.

Буду рад комментариям!

Я тоже придерживаюсь такого мнения, например, при прочих равных условиях, на сервер с 144Гб ОЗУ ставить l2arc ssd смысла меньше, чем на сервер с 64Гб ОЗУ.

Совершенно логичное мнение! Другое дело, потюнить может что-то имеет смысл на сервере с малым кол-вом ОЗУ. Чтобы побольше поставить l2arc! Уменьшить объём ARC, за счёт размещения там метаданных для L2ARC.

Уменьшить объём ARC, за счёт размещения там метаданных для L2ARC.

Но даже тут, у ZoL - есть проблемы!!! https://github.com/zfsonlinux/zfs/issues/1132

И поведение ZoL, крайне интересное может быть... https://github.com/zfsonlinux/zfs/issues/1261 - вот так вот, они живут в своём мирке, и на кеширование L2ARC, внезапно, может уйти, всего лишь с десяток не запланированных гигабайт ОЗУ.

А читая, вот такие посты, https://github.com/zfsonlinux/zfs/issues/1261#issuecomment-57500723 - я и вовсе задумываюсь о целесообразности включения l2arc! Замечу, что тикет всё ещё открыт!

Ну ты загнул с уклоном в андерграунд. Обсуждаемые технологии - стандартные и проверенные годами, не вижу смысла подвергать сомнению их эффективность. И l2arc и zil работают. Проверить их эффективность элементарно можно по iostat (оценить загруженность ssd) или по увеличению iops на одной и той же инсталляции без l2arc/zil и с ними, вместе или по отдельности, в зависимости от задачи. Конечно, многое зависит от юзкейса и паттерна чтения-записи, наверняка можно изобразить синтетический тест который покажет неэффективность или даже негативный вклад этих технологий, но на реальных задачах это работает и работает эффективно.

то что ты, используешь в zil десктопные диски - ходишь по лезвию ножа. А в том, плане, что в десктопных SSD нету защиты от внезапного пропадания питания.

Согласен, десктопные ssd для zil не хорошо. Внезапная пропажа питания, кстати, волнует меньше всего, в силу ряда причин. Да и инсталляций с zil всего две и обе принадлежат мне, клиенты на части не порвут.

По сему, ARC нужно тюнить.

Это очевидно и все, кто использует ZoL делают это, по крайней мере определяется options zfs zfs_arc_max=сколько_то_памяти

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

P.S. Если не доверяешь вполне конкретной реализации zfs - zfsonlinux, но zfs нужна по тем или иным причинам, то вполне можно сделать стораджи zfs на freebsd или illumos, раздать по iscsi linux-хостам.

Речи нету о том, что я не доверяю. Я хочу разобраться, и мне интересно посмотреть, на твои реальные цифры (с серверов с uptime) того что я привёл. Например, ты можешь оценить: объём занятого пространства в l2arc, можешь оценить сколько у тебя в ARC занимают места метаданные от l2arc. Можешь посмотреть статистику l2arc/arc. Ну и разделиться данными выкладками. Это не требует перезагрузки. За одно и сам посмотришь на сколько это эффективно. Давай я тебе скажу так: у меня есть одна база довольно не торопливая на HDD живущая. - Медленная она... Добавил я туда l2arc - разницы нету. Вот и стало мне интересно... --- Завтра постараюсь выцепить и выложить свои данные!

А вообще, да, меня унесло из mdadm в zfs (чего уж там... нравится она мне). Ну и вообще, пока ты тут общаешься, ты реален, адекватен, по этому я вижу смысла узнать побольше об опыте. Скоро приедут ко мне железки, буду поднимать ряд узлов на zfs. По сему, хочется учесть свои ошибки, и узнать как делают другие!

Например, мне очень интересно узнать, про hotspare у тебя. Будет у меня в каждом сервере по 6 НЖМД +2SSD. Вот я прикидываю как бы мне организовать хранение данных. Пока я склоняюсь к «raid10» на zfs. Ибо мне важна надёжность, и скорость чтения, и не плохая скорость записи.

Дано:

• В машине: 64гб. ОЗУ.
• 2 одинаковых SSD.
• 6 одинаковых HDD.

Что надо:

• Самое важное: надёжное хранение данных.
• Чуть менее важное: Высокая скорость чтения.
• По возможности шустрая запись.
• Простота.

Планирую:

• SSD mirror zil - 5Gb
• mdadm+lvm: на каждом HDD под ОС.
• На оставшемся пространстве HDD - raid10 zfs. При том, по три диска в каждом плече!
• ARC - 10gb
• compression
• zvol 64k

В свете нюансов zfs on linux, и требований с учётом приоритетности, вроде должно быть адекватно. Если потребуется, добавлю потом l2arc. Что скажешь?

И ещё: насколько я понимаю, L2ARC после перезагрузки превращается в тыкву. Так-как метаданные для него, хранимые в ОЗУ стираются. И его наполнение, начинается снова.

l2arc это обычный кэш, без всяких хитрых таблиц в памяти.

arc таки держит таблицу соответствия l2arc, правда я хз откуда далдон взял 1 к 5.

It costs some DRAM to reference the L2ARC, at a rate proportional to record size. For example, it currently takes about 15 Gbytes of DRAM to reference 600 Gbytes of L2ARC - at an 8 Kbyte ZFS record size. If you use a 16 Kbyte record size, that cost would be halve - 7.5 Gbytes. This means you shouldn't, for example, configure a system with only 8 Gbytes of DRAM, 600 Gbytes of L2ARC, and an 8 Kbyte record size - if you did, the L2ARC would never fully populate.

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

В солярисах нет.

Можешь посмотреть статистику l2arc/arc. Ну и разделиться данными выкладками

Да, могу. Как посмотреть статистику?

Планирую:

SSD mirror zil - 5Gb
mdadm+lvm: на каждом HDD под ОС.
На оставшемся пространстве HDD - raid10 zfs. При том, по три диска в каждом плече!
ARC - 10gb
compression
zvol 64k

Несколько раз, встречал, что 1/5. Ссылку на форум привёл. Откуда на форумах берут - хз. По сему собственно и спрашиваю. Документация на oracle - годная. Теперь хорошо бы спросить в рассылке ZoL. Спрошу может на днях.

Да, могу. Как посмотреть статистику?

Примерно так (насколько я понимаю), я тебе почикал тут малость (сервер после reboot):

# arc_summary.py

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

L2 ARC Size: (Adaptive)                         3.14    MiB
        Compressed:                     29.55%  951.50  KiB
        Header Size:                    0.00%   0       Bytes

L2 ARC Breakdown:                               34.67k
        Hit Ratio:                      0.00%   0
        Miss Ratio:                     100.00% 34.67k
        Feeds:                                  102.94k

L2 ARC Writes:
        Writes Sent:                    100.00% 21

Well, for starters your L2ARC should never exceed about 5x your RAM.. you've got 4x that... As a general rule using L2ARCs with <64GB of RAM is just waste of time because the total allocatable size is too small for most people.

Вот такие глупости ещё нашёл.

В общем, примерно ясно мне с l2arc. Буду считать.

arc_summary.py

Дай ссылку на рабочий вариант, я скачал какой-то он не работает.

As a general rule using L2ARCs with <64GB of RAM is just waste of time because the total allocatable size is too small for most people.

Сдаётся мне это враньё.

Вот смотри, есть ведёрко старое с 32Гб ОЗУ (arc 8Гб), харды там:

системный:
ata-WDC_WD740GD-00FLC0_WD-WMAKE2350790
кэш:
ata-PLEXTOR_PX-128M6S_P02430105117
zfs:
ata-WDC_WD10EFRX-68FYTN0_WD-WCC4J5CD912D
ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0723174
ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0974354
ata-WDC_WD10EFRX-68PJCN0_WD-WCC4JNV9500T
1Тб spare + 2Тб раздел xfs:
ata-WDC_WD3000F9YZ-09N20L0_WD-WCC5D0121576

zpool status

pool: dpool
 state: ONLINE
  scan: scrub repaired 0 in 1h43m with 0 errors on Thu Feb 25 16:37:24 2016
config:

	NAME                                          STATE     READ WRITE CKSUM
	dpool                                         ONLINE       0     0     0
	  mirror-0                                    ONLINE       0     0     0
	    ata-WDC_WD10EFRX-68FYTN0_WD-WCC4J5CD912D  ONLINE       0     0     0
	    ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0723174  ONLINE       0     0     0
	  mirror-1                                    ONLINE       0     0     0
	    ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0974354  ONLINE       0     0     0
	    ata-WDC_WD10EFRX-68PJCN0_WD-WCC4JNV9500T  ONLINE       0     0     0
	logs
	  sdf2                                        ONLINE       0     0     0
	cache
	  sdf1                                        ONLINE       0     0     0
	spares
	  sdg1                                        AVAIL   

На этом хозяйстве l2arc 80Гб даёт реальный приход. На этой машине много lxc-контейнеров их там постоянно заливают, клонируют, запускают, внутри контейнеров базы есть. Когда я смотрю iostat при активной работе, больше всего читает с ssd.

Он должен поставляться с ZoL, прямо в deb пакете. Начиная с 0.6.4 кажется: arcstat.py arc_summary.py. Они уже лежат даже в PATH. Только потабать нужно. :)

Он должен поставляться с ZoL, прямо в deb пакете.

У меня нет, взял отсюда:
https://github.com/zfsonlinux/zfs/tree/master/cmd/arc_summary

Насчёт arc наврал, не 8, а 16Гб максимум. Вот такая фигня с кэшами:

ZFS Subsystem Report				Thu Mar 03 23:04:12 2016
ARC Summary: (HEALTHY)
	Memory Throttle Count:			0

ARC Misc:
	Deleted:				15.50m
	Mutex Misses:				511
	Evict Skips:				511

ARC Size:				100.27%	15.61	GiB
	Target Size: (Adaptive)		100.00%	15.57	GiB
	Min Size (Hard Limit):		0.20%	32.00	MiB
	Max Size (High Water):		498:1	15.57	GiB

ARC Size Breakdown:
	Recently Used Cache Size:	18.34%	2.86	GiB
	Frequently Used Cache Size:	81.66%	12.75	GiB

ARC Hash Breakdown:
	Elements Max:				2.26m
	Elements Current:		94.92%	2.15m
	Collisions:				7.18m
	Chain Max:				7
	Chains:					391.73k

ARC Total accesses:					123.54m
	Cache Hit Ratio:		95.18%	117.59m
	Cache Miss Ratio:		4.82%	5.96m
	Actual Hit Ratio:		95.02%	117.39m

	Data Demand Efficiency:		98.34%	72.97m
	Data Prefetch Efficiency:	17.25%	3.02m

	CACHE HITS BY CACHE LIST:
	  Most Recently Used:		10.42%	12.26m
	  Most Frequently Used:		89.41%	105.13m
	  Most Recently Used Ghost:	0.28%	327.11k
	  Most Frequently Used Ghost:	0.71%	836.22k

	CACHE HITS BY DATA TYPE:
	  Demand Data:			61.02%	71.76m
	  Prefetch Data:		0.44%	521.57k
	  Demand Metadata:		38.51%	45.28m
	  Prefetch Metadata:		0.02%	24.08k

	CACHE MISSES BY DATA TYPE:
	  Demand Data:			20.36%	1.21m
	  Prefetch Data:		42.01%	2.50m
	  Demand Metadata:		37.16%	2.21m
	  Prefetch Metadata:		0.46%	27.65k

L2 ARC Summary: (HEALTHY)
	Low Memory Aborts:			2
	Free on Write:				78.99k
	R/W Clashes:				20
	Bad Checksums:				0
	IO Errors:				0

L2 ARC Size: (Adaptive)				85.98	GiB
	Compressed:			89.20%	76.70	GiB
	Header Size:			0.11%	95.82	MiB

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

L2 ARC Breakdown:				5.96m
	Hit Ratio:			15.47%	921.64k
	Miss Ratio:			84.53%	5.03m
	Feeds:					70.00k

L2 ARC Writes:
	Writes Sent:			100.00%	61.19k

File-Level Prefetch: (HEALTHY)
DMU Efficiency:					345.60m
	Hit Ratio:			96.81%	334.56m
	Miss Ratio:			3.19%	11.04m

	Colinear:				11.04m
	  Hit Ratio:			0.06%	6.19k
	  Miss Ratio:			99.94%	11.03m

	Stride:					331.26m
	  Hit Ratio:			99.89%	330.89m
	  Miss Ratio:			0.11%	364.32k

DMU Misc: 
	Reclaim:				11.03m
	  Successes:			3.68%	406.21k
	  Failures:			96.32%	10.63m

	Streams:				3.67m
	  +Resets:			0.02%	796
	  -Resets:			99.98%	3.66m
	  Bogus:				0

У тебя, всего 15% из l2arc считывается. Пруф: https://docs.oracle.com/cd/E51475_01/html/E52873/analytics__statistics__cache...

Так, что... Быть может не столь глупое утверждение, что на маленьких RAM, l2arc, смысла имеет не много, и ОЗУ под l2arc, может лучше отдать в ARC.

Слушай, подскажи пож-та по spare дискам. Сейчас пробую сию штуку на файлах, делаю примерно вот так:

zpool set autoreplace=on tst

Вот такое устроил:

        NAME                     STATE     READ WRITE CKSUM
        tst                      DEGRADED     0     0     0
          mirror-0               DEGRADED     0     0     0
            /root/test/qqq1.zfs  ONLINE       0     0     0
            /root/test/qqq2.zfs  UNAVAIL      0     0     0  corrupted data
        spares
          /root/test/spare.zfs   AVAIL

zfs-zed - настроил. На почту он мне сыпет всё что валится из zpool events. Однако никакой автозаменой тут и не пахнет. zed.rc - поглядел. Раскоментил чтобы при плохих чексумах и при i/o error делал spare.

В общем ничего не помогает. Только руками, spare подключается. :(

У тебя точно zfs-zed - автоматом цепляет spare??? Если да, то при каких условиях?

Вот так же примерно делаю: https://github.com/zfsonlinux/zfs/issues/3695 spare не цепляется.

Так же, наткнулся на этот баг: https://github.com/zfsonlinux/zfs/issues/2808

В общем ничего не помогает. Только руками, spare подключается. :(

Аналогично. Полтора года назад, когда начали zol внедрять один мой «таджик» «проверял» эту фичу, я был уверен, что она рабочая. Проверил сам в виртуалке, дабы железки не насиловать - нет, spare автоматом не цепляется.
Я тебе скажу страшное, проверил я это дело на freebsd, так вот hot spare и на freebsd 10.2 не работает...

P.S. Круто я облажался, теперь intelfx на моих костях попляшет :)

И так во всем, типа «я неипически крутой спец», но на деле нехера не знаю, «знания» нагуглил. Ха-ха-ха!

P.S. Круто я облажался, теперь intelfx на моих костях попляшет :)

На форуме лажаться можно, главное не облажаться в продакшене. :) И в этом я вижу своеобразную пользу форума. Я из этой ветки, к примеру многое извлёк для себя. Ну и ты я думаю тоже, кое-чего подцепил. Например, узнал, что l2arc - на деле, не особо эффективен. Хотя, вопрос спорный, ибо ARC хранит в первую очередь фрагментированные блоки. Всё последовательное чтение - выгоднее выполнять напрямую с HDD :) На самом деле, я быть может ещё копну в сторону l2arc, и у меня есть некоторое мнение, что после reboot, оно и вовсе в тыкву превращается, и потом снова копится с нуля. :)

Что же касается spare дисков - они написали в zol свой демон велосипед, который по сути парсит логи, и исполняет скрипты, как только видит некоторые события в логах. Вот и всё. И я видел, что там у них могут быть проблемы со spare, всего лишь из-за криво написанного рег. выражения, по грепу спаре драйвов. Ну не видит рег. выражение их и всё. Некоторые смельчаки, чинят это в одну строку кода на shell (там собственно всё на shell).

Другое дело, что в этом демоне, ещё куча багов, и все баги на которые я наткнулся, имеются на github у них. Почему не чинят - не знаю.

Что касаемо - моей проблемы с mdadm - по твоим советам, да и разобрался сам, теперь сотворил на шлюзе, raid1 + hotspare. И в автозагрузку сказал чтобы smart - не более 7 сек. ждал, после чего выкидывал на фиг. Буду теперь помучать старые диски) Смотреть как они умирают.

И что в ZFS диски не разу ни фалтились? Он у тебя сколько работает? Пару месяцев? Надеюсь ты на своем примере понял, что HotSpare это не необходимая для RAID фишка, а в моем случае даже вредная, так как мне не нужно начало ребилда в ЧНН.

начало ребилда в ЧНН.

ЧНН? А ограничивать скорость ребилда оно не умеет? Типа, ребилдить только в простое.

И что в ZFS диски не разу ни фалтились? Он у тебя сколько работает? Пару месяцев?

Не, где то полтора года назад начали zol внедрять везде где только можно. Диски вылетали, выяснил, zfs replace делали. Я вроде как организую, денюжку вкладываю, непосредственно эксплуатацией почти не занимаюсь, есть нанятые одмины, обратная связь не всегда, как выяснилось, имеет место быть.