The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD, opennews (??), 07-Янв-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


48. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  –1 +/
Сообщение от Онаним (?), 07-Янв-21, 18:58 
Кеш ZFS, к сожалению - вещь в себе, которая именно что "жрёт память", потому что отдача памяти назад ОС при необходимости затруднена.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

55. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +3 +/
Сообщение от zzz (??), 07-Янв-21, 19:18 
Линуксопроблемы, разделившие дисковый кэш и кэш ZFS.
Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +1 +/
Сообщение от Онаним (?), 07-Янв-21, 19:19 
Как раз таки ZFSопроблемы, кэш ZFS на системный кеш не ложится что в пингвинах, что в бзде.
Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (35), 07-Янв-21, 21:12 
Так вроде в соляре этот кеш интегрирован в системный (или наоборот), в таком случае, у ZFS нет проблем с этим. Она просто инородная и все остальные ядра не разработаны под неё.
Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  –1 +/
Сообщение от Онаним (?), 08-Янв-21, 18:56 
Есть смысл труп обсуждать? :)
Ответить | Правка | Наверх | Cообщить модератору

126. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +1 +/
Сообщение от Аноним (-), 09-Янв-21, 19:26 
> Так вроде в соляре этот кеш интегрирован в системный (или наоборот)

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

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

101. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  –1 +/
Сообщение от пох. (?), 09-Янв-21, 14:00 
Ну так это проблема систем с неотключаемым ненужно-"системнымкэшом".

У BSD НЕТ никакого "системного кэша", если ты до сих пор не в курсе. Что вызывает нешуточный батхерт у любителей портировать туда линуксный мусор, кстати. Поскольку тот вообще не в курсах, что так бывает.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

109. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 09-Янв-21, 15:45 
Извини, но ты гонишь :D
Оно у них называется "буфером", но суть та же.

"FreeBSD has a unified buffer cache. This means that ALL AVAILABLE MEMORY IS A BUFFER CACHE for all device IO."

Ответить | Правка | Наверх | Cообщить модератору

127. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (-), 09-Янв-21, 19:27 
В бздях пох такой же эксперт как и в линуксе :)
Ответить | Правка | Наверх | Cообщить модератору

143. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +1 +/
Сообщение от пох. (?), 09-Янв-21, 20:12 
> Извини, но ты гонишь :D
> Оно у них называется "буфером", но суть та же.

нет, не та же.

> "FreeBSD has a unified buffer cache. This means that ALL AVAILABLE MEMORY
> IS A BUFFER CACHE for all device IO."

а это и просто бред сивой кобылы.

Ну да, с тем же успехом можно сказать что all available memory is arc в случае zfs. К счастью, можно все же сделать, чтоб не all. А то какой-нибудь просто шелл внезапно уезжает из под тебя по sigbus.

Чтобы полностью осознать отличия - можешь попробовать запустить пресловутый ntfs3g. Только не забудь отключить зависимости при сборке, а то там-то, из-за древности технологии, вручную подложен костылик.

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

160. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 09-Янв-21, 21:01 
Нет. ZFS делает аллокации сам, и отдаёт когда сочтёт нужным, не сообщая ядру, что и как может отдать. А страницы буферов/кеша дропаются/отписываются ядром и отдаются при запросе на аллокацию. В этом и вся разница.
Ответить | Правка | Наверх | Cообщить модератору

161. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 09-Янв-21, 21:02 
ALL AVAILABLE MEMORY поэтому и возможно, что оно не препятствует собственно аллокациям. Системный кеш может хоть на всю память распухнуть - но если в ней будет потребность, ядро его освобождает.
Ответить | Правка | Наверх | Cообщить модератору

187. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от пох. (?), 10-Янв-21, 23:08 
Б-ть, ничего что zfs и есть ядро, его часть?

> А страницы буферов/кеша дропаются/отписываются ядром

мистическим таким ядром в сферическом вакууме, конечно же. Волшебным прямо. А как функцию из чуждой лицензии вызовет - сразу все волшебство пропадает.
А не где попало натыканным как попало кодом. Причем mpu-safe, и при этом старающимся избегать global lock где только можно - поэтому зохавать обычно в десять раз быстрее и проще, чем что-то отдать.

> В этом и вся разница.

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

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

А у поганой freebsd нет команды free, нишва6одные оне.
А vmstat всех палит, и никакого спокойного сна :-(

Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

189. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 10-Янв-21, 23:39 
В ZFS свой собственный кеш, который оторван от системного совершенно.
Что в бзде, что в ZoL.
Ответить | Правка | Наверх | Cообщить модератору

193. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от пох. (?), 10-Янв-21, 23:46 
БТЬ.... НЕТ никакого волшебного "системного". Кэш zfs - он настолько же "системный", как и любой другой.

Отдельный вопрос, что линyпси с их странностями пытаются кэшировать внутри драйвера блочного устройства, и, похоже, даже O_DIRECT не помогает от этого избавиться. Но это их проблемы.

Ответить | Правка | Наверх | Cообщить модератору

215. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (215), 11-Янв-21, 15:24 
Ты что! В zfs/arc.c особый kmem_cache_alloc, волшебный.
Ответить | Правка | Наверх | Cообщить модератору

251. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от пох. (?), 12-Янв-21, 20:34 
> Ты что! В zfs/arc.c особый kmem_cache_alloc, волшебный.

Он лежит в /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c
В bsd он просто однострочник-преобразователь аргументов, вызывает uma_zalloc. Точно так же как любой другой код в ядре, которому нужна zone memory. Никакого "волшебного" в нее не завезли:
% find /usr/src/sys/ -type f -print0 | xargs -0 grep -l uma_zalloc
/usr/src/sys/kern/sys_generic.c
/usr/src/sys/kern/kern_time.c
/usr/src/sys/kern/kern_rangelock.c
/usr/src/sys/kern/kern_cpuset.c
/usr/src/sys/kern/uipc_mqueue.c
[skip, оставлю избранные фрагменты]
/usr/src/sys/kern/kern_mbuf.c
/usr/src/sys/kern/vfs_cache.c
/usr/src/sys/kern/vfs_aio.c
/usr/src/sys/kern/tty_outq.c
/usr/src/sys/kern/kern_thread.c
/usr/src/sys/kern/tty_inq.c
/usr/src/sys/kern/vfs_lookup.c
/usr/src/sys/ofed/drivers/infiniband/ulp/sdp/sdp_main.c
/usr/src/sys/x86/iommu/intel_gas.c
/usr/src/sys/dev/iser/icl_iser.c

"Волшебство" самого чорного характера ты найдешь не там, а в abd.c
Этого вот не было до 11 версии. Подарочек от пингвиноидов, и хрен теперь выпилишь.
Я ж показывал недавно - там лежит половина размера ARC. Порезанная по 4k.

А что там у ла..запрещенноенавпопеннетеслово - у них спрашивай, мне совершенно неинтересно.

Очевидно, совсем г-но, иначе бы iX не дали пропасть прекрасному.

P.S. пока этот find работал, стало еще веселее - arc радостно отрос до 473M (то есть честно отрабатывает свой хлеб). abd тоже не лох - он теперь 310
Напоминаю - всей памяти у виртуалки - гигабайт.


Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

211. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от пох. (?), 11-Янв-21, 14:05 
Все, я заканчиваю дискуссию. Если человек свято верит в чудеса - у нас за оскорбление чуйств сажают.

Конечно же, есть еще какое-то "более ядро" чем то ядро, в котором у нас и работает zfs.


Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

183. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (-), 10-Янв-21, 03:49 
> Ну да, с тем же успехом можно сказать что all available memory
> is arc в случае zfs.

Тут ключевой вопрос - а может ли кернел это быстро забрать взад когда сие потребуется программам? А то иначе может получиться довольно дурацки - в системе вагон свободной памяти, его заняли под буферизацию, а тут кто-то из прог попросил память которой якобы дофига. А ей в ответ - а вот тебе?! Что за бред? Не говоря о том что нынче прогеры размякли и к mem alloc failure часто не готовы морально, так что дальше идет фееричнейший UB.

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

186. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от пох. (?), 10-Янв-21, 10:37 
> Тут ключевой вопрос - а может ли кернел это быстро забрать взад когда сие потребуется программам?

Быстро - не может, чудес не бывает.
Вот тебе старый линукс, с еще человекочитаемым free:
             total       used       free     shared    buffers     cached
Mem:       3085136    2863632     221504          0     415804    1005072
-/+ buffers/cache:    1442756    1642380
Swap:      4194300      52244    4142056

Чего бы он в swap залез, когда оно "free"? И зачем-то держит зазор, пусть и 5%, хотя весь тот своп бы поместился и еще осталось.

Причина вполне банальная - быстро отдать это cached не получится. Чтобы оттуда отдать - надо перебрать табличку структурок, состоящую, на минутку, у нас 4k pages, из 251268 (блжад!) айтимов - желательно не первые попавшиеся оттуда выбрасывать, а хотя бы те к которым долго не было обращений (лучшее, что умеет линукс).
Кстати, для этого потребуется память, нужна ж нам табличка кандидатов из той таблички на вынос ;-) Добавь сюда что системы у нас дохреллион-процессорные и все это через локи.

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

И вот эти механизмы - они сложные, не всегда быстрые и завязаны на кучу внутренних систем ядра. Неаккуратное вмешательство в них ведет к 12309 в лучшем случае (в худшем - к lockup, когда негде взять память, чтобы поискать свободную память, потому что мы уже ищем свободную память и память для этого кончилась).

Кстати, никто не обещал тебе, что это единственное место в системе, где есть динамически расходуемая память, и что ее вообще надо сейчас трогать (представь систему с основными дисками на nfs, или, того хуже, ceph). К сожалению, в линуксе нет никакого общедоступного способа ее посмотреть, и даже понять, относится ли она к "buffers" или показывается просто как занятая ядром.

> Не говоря о том что нынче прогеры размякли и к mem alloc failure часто не готовы морально

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

Ответить | Правка | Наверх | Cообщить модератору

190. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 10-Янв-21, 23:40 
В swap он залез, потому что алгоритмы такие. Ставь vm.swappiness = 1 , будет меньше залезать. Но не в ноль.
Плюс мог залезть когда был реальный оверкоммит, а освобождать не торопится - пока обращений не будет.
Ответить | Правка | Наверх | Cообщить модератору

192. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 10-Янв-21, 23:41 
(освобождать - в смысле назад в RAM затягивать, освободить-то в любой момент может, если аппликуха отдаст)
Ответить | Правка | Наверх | Cообщить модератору

196. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от пох. (?), 11-Янв-21, 00:02 
> В swap он залез, потому что алгоритмы такие.

вопрос не в этом, а почему у нас при этом _пропадает_ даром память, хотя она свободная.

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

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

230. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 12-Янв-21, 10:22 
Она не пропадает. Как только приложение её попросит - ОС ему даст, не ломаясь.
Более того, даст и из cache/buffers при необходимости, не дожидаясь, как с ZFS, освобождения из ARC.
Сама всё снимет и даст.
Ответить | Правка | Наверх | Cообщить модератору

191. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (191), 10-Янв-21, 23:40 
> отдать - надо перебрать табличку структурок, состоящую, на минутку, у нас
> 4k pages, из 251268 (блжад!) айтимов - желательно не первые попавшиеся
> оттуда выбрасывать, а хотя бы те к которым долго не было
> обращений (лучшее, что умеет линукс).

Head seek винча занимает больше. Так что девы купили ссд. А проблемы начинаются тогда, когда какая-то часть системных дел оказывается залоченой на такие скорости железа. Туда же и флешки с скоростью мег в секунду. 256 pps, можешь посчитать сколько времени оно гиг будет отбирать. Сейчас доформатирую дискетку^W отберу память и покажу тебе интерактивность.

> Кстати, для этого потребуется память, нужна ж нам табличка кандидатов из той
> таблички на вынос ;-)

А список кандидатов на вынос не держится постоянно? Или в чем смысл его постоянно аллоцировать, если он часто нужен? А те циферки не мировая константа и зависят от настроек swappiness и вокруг. Дистры могли за это время дефолты поменять, например. Решив что RAM прибавилось и теперь не обязательно хрустеть диском до тех пор пока реально не прижмет, например.

> Добавь сюда что системы у нас дохреллион-процессорные и все это через локи.

Локам давно дали бой, твое 2.6.чтототам для которого это релевантно и 5.10 скорее всего 2 большие разницы. В btrfs на эту тему патчи активно прут, они там локи перетряхнули, роботы репортят приколы с стрельбой палок раз в год, естественно в RC и до юзеров не долетит.

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

Может и найду. Но mm/ нынче довольно большой и сложный, копаться в нем должна быть хорошая причина. Кстати, если ты думал что знания о всем этом мировая константа, как тебе c843966c556d7370bb32e7319a6d164cb8c70ae2 допустим? Да, ему меньше года, так что в 2.6.чотам оно не так.

> И вот эти механизмы - они сложные, не всегда быстрые и завязаны
> на кучу внутренних систем ядра.

Они сложные. А что до не всегда быстрые, большие головы все же воротят core techs дабы "не всегда быстрые" случалось поменьше, им за это денег даже платят. При том железо тоже эволюционирует, пример чему и даден выше (изначально найдено как git log mm/vmscan.c вокруг других любопытных изменений).

> Неаккуратное вмешательство в них ведет к 12309 в лучшем случае (в худшем - к lockup,
> когда негде взять память, чтобы поискать свободную память, потому что мы уже ищем
> свободную память и память для этого кончилась).

Я делаю с Linux много странного г-на в разных конфигах. Но именно это я видел только в 1 случае: в роутерах где контрек настраивают неверно, так что он сжирает RAM, а когда она кончается под тяжелым флудом, отобрать неоткуда т.к. контрек тоже ядро, трололо. Но это вообще ошибка конфигурации. Систембилдер лох.

> К сожалению, в линуксе нет никакого общедоступного способа ее посмотреть, и
> даже понять, относится ли она к "buffers" или показывается просто как
> занятая ядром.

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

> они часто еще более неготовы к подождать, пока освободится

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

> (ты в линку в бравзере ткнул - и у тебя повисло все вообще -

При 12309 таки повиснет сперва браузер. А остальное - только если ты будешь дергаться как муха в паутине провоцируя новые аллокации другими прогами.

Один програмер как-то сказал: если система тупит, хучшее что можно сделать это начать дергаться. Это все только усугубит. Это, кстати, вообще видовый програмер, но идея достаточно универсальна.

> потому что понадобилась память отобразить инвалидо-френдли индикатор бурной деятельности,
> и система пошла поискать - пупсики ж не поймут такого)

У лично меня в моих конфигах это все вообще проблемой не является. Но я все же умею пингвинов готовить и разбираться с поведением которое мне не симпатично. И вместо воплей как все плохо у меня обычно находится твик настроек, а то и радикальный пересмотр подходов. У меня нет свопа, кроме zram. И для него более релевантно то что написано в c843966c556d7370bb32e7319a6d164cb8c70ae2 - но боже упаси это механическому винчу вкрутить.

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру