Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 06 Oct 24 10:23:41, всего сообщений: 10767
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 6839 из 10767 ===================================== RU.UNIX.BSD =
От   : Slawa Olhovchenkov               2:5030/500         25 Mar 18 19:45:44
Кому : Alex Korchmar                                       25 Mar 18 19:45:44
Тема : висим стабильненько
FGHI : area://RU.UNIX.BSD?msgid=2:5030/500+5ab7d67c
На   : area://RU.UNIX.BSD?msgid=<1187509216@ddt.demos.su>+5e2462ca
= Кодировка сообщения определена как: FIDO ===================================
Ответ: area://RU.UNIX.BSD?msgid=grosbein.net+c92e604b
==============================================================================
Hello Alex!

25 Mar 18, Alex Korchmar writes to Slawa Olhovchenkov:

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

AK> нам бы пока zfs как-нибудь победить.

ты зря так думаешь.

ITEM                   SIZE  LIMIT     USED     FREE      REQ FAIL SLEEP
mbuf_jumbo_page:       4096, 16777216,  987894,  759655,8205734907395,   0,   0

вот тебе пожалуйста 3ГБ свободной память в mbuf.
она действительно свободная, т.е. сейчас не используется mbuf jubmbo.
а я видел и 40ГБ.

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

ITEM                   SIZE  LIMIT     USED     FREE      REQ FAIL SLEEP zio_data_buf_1048576: 1048576,      0,  217577,    1604,14972433811,   0,   0

(вот тут у нас 1.6Г свободной памяти)

и потом её оттуда достанут, если pressure будет продолжаться. как и из jumbo. и из остальных мест. и после этого свободной памяти окажется ДОХУЯ.

но а) это будет потом б) мы уже повыкидывали всякое из ARC да и ARC зачем-то уменьшили в) это затратный по CPU процесс и вдобавок он тормозит много что, т.к. при этом происходит contention lock (причем по памяти).

пункт в) -- он из-за оптимизации под SMP: для того, что бы всякие подсистемы не дрались постоянно за один lock при alloc/free они живут по зонам. и если если в зону память берут достаточно дешево, то обратно в систему ты её дешево вернуть не можешь -- надо будет брать глобальный лок, вертать память, освобождать лок. это дорого. поэтому free память помещает во внутризоновый free. из него в систему подбирает кажется pagedaemon, когда начинают стучать по балде "freepages меньше лимита! ааа!". но как уже сказанно -- это дорогая операция -- локи и все такое.

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

... Пылесос -- уникальный продукт. Чем сильнее он сосет -- тем лучше.
--- GoldED+/BSD 1.1.5-b20110223-b20110223
* Origin:  (2:5030/500)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.098493 секунды