висим стабильненько

Eugene Grosbein написал(а) к Slawa Olhovchenkov в Apr 18 18:17:45 по местному времени:

01 апр. 2018, воскресенье, в 01:08 NOVT, Slawa Olhovchenkov написал(а):

EG>> и чем освобождение такой памяти отличается от "поджаться и сбросить
EG>> лишнее"?
SO> она не освобождается какой-то выделенной подсистемой.

Даже при вызове lowmem hook? Но ведь это тупо баг.

Eugene
--- slrn/1.0.2 (FreeBSD)

Slawa Olhovchenkov написал(а) к Eugene Grosbein в Apr 18 17:32:06 по местному времени:

Нello Eugene!

01 Apr 18, Eugene Grosbein writes to Slawa Olhovchenkov:

EG>>> и чем освобождение такой памяти отличается от "поджаться и сбросить
EG>>> лишнее"?
SO>> она не освобождается какой-то выделенной подсистемой.
EG> Даже при вызове lowmem hook? Но ведь это тупо баг.

можешь подискутировать в листах (не со мной, я мнения не имею)

формально -- нет, при вызове lowmem hook этого не происходит.
после вызова lowmem hook (из vmpageout_scan(vm_dom[0], pass > 0)) происходит вызов uma_reclaim(), кторый транслируется в вызов wakeup(&uma_reclaim_needed) который приводит к просыпанию треда uma_reclaimworker().
который, кстати, еще раз активиирует lowmem hook.

... Большой пpогpамме - большие глюки
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Eugene Grosbein написал(а) к Slawa Olhovchenkov в Apr 18 23:11:19 по местному времени:

01 апр. 2018, воскресенье, в 15:32 NOVT, Slawa Olhovchenkov написал(а):

EG>>>> и чем освобождение такой памяти отличается от "поджаться и сбросить
EG>>>> лишнее"?
SO>>> она не освобождается какой-то выделенной подсистемой.

EG>> Даже при вызове lowmem hook? Но ведь это тупо баг.
SO> можешь подискутировать в листах (не со мной, я мнения не имею)

А мы про которую именно подсистему сейчас, не освобождающую свободную
память при вызове lowmem hook?

SO> формально -- нет, при вызове lowmem hook этого не происходит.
SO> после вызова lowmem hook (из vmpageout_scan(vmdom[0], pass > 0)) происходит
SO> вызов umareclaim(), кторый транслируется в вызов wakeup(&uma_reclaimneeded)
SO> который приводит к просыпанию треда umareclaimworker().
SO> который, кстати, еще раз активиирует lowmem hook.

Eugene
--- slrn/1.0.2 (FreeBSD)

Slawa Olhovchenkov написал(а) к Eugene Grosbein в Apr 18 19:04:14 по местному времени:

Нello Eugene!

01 Apr 18, Eugene Grosbein writes to Slawa Olhovchenkov:

EG>>>>> и чем освобождение такой памяти отличается от "поджаться и сбросить
EG>>>>> лишнее"?
SO>>>> она не освобождается какой-то выделенной подсистемой.

EG>>> Даже при вызове lowmem hook? Но ведь это тупо баг.
SO>> можешь подискутировать в листах (не со мной, я мнения не имею)

EG> А мы про которую именно подсистему сейчас, не освобождающую свободную
EG> память при вызове lowmem hook?

если мы про официальное дерево сырцов -- то про любую, имеющую выделенный zone.
umareclaim_worker -- часть ядра, а arclowmem -- часть подсистемы zfs.

SO>> формально -- нет, при вызове lowmem hook этого не происходит.
SO>> после вызова lowmem hook (из vmpageout_scan(vmdom[0], pass > 0))
SO>> происходит вызов uma_reclaim(), кторый транслируется в вызов
SO>> wakeup(&umareclaimneeded) который приводит к просыпанию треда
SO>> umareclaimworker(). который, кстати, еще раз активиирует lowmem
SO>> hook.


... Ничто так не подрывает веру в людей, как просмотр логов сквида
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Eugene Grosbein написал(а) к Alex Korchmar в Apr 18 02:09:00 по местному времени:

30 марта 2018, пятница, в 17:16 NOVT, Alex Korchmar написал(а):

EG>> А я уже напарывался, когда утилитка типа ifconfig или ещё какая,
EG>> использующая kldload() / даже в портах такие есть / говорит,
EG>> ой - не шмогла! Да тот же самый mpd5 для организации L2TP/IPSEC-туннеля.
AK> ну мне как-то трудно представить, зачем мне такой туннель на отдельно
AK> взятую систему, если только изначально она не предназначалась работать с
AK> туннелями.

А сегодня легче представить по сравнению с месяц назад?

Eugene
--
И у священных источников живут алчные монахи. (Дхарма)
--- slrn/1.0.2 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Apr 18 00:40:14 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> ну мне как-то трудно представить, зачем мне такой туннель на отдельно
AK>> взятую систему, если только изначально она не предназначалась работать с
AK>> туннелями.
EG> А сегодня легче представить по сравнению с месяц назад?
у меня сто лет уже нет сервисов в стране Навозных Петухов, мне без надобности.

А юзерам ничего не поможет.

> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Apr 18 17:24:29 по местному времени:

25 апр. 2018, среда, в 22:40 NOVT, Alex Korchmar написал(а):

AK>>> ну мне как-то трудно представить, зачем мне такой туннель на отдельно
AK>>> взятую систему, если только изначально она не предназначалась работать с
AK>>> туннелями.
EG>> А сегодня легче представить по сравнению с месяц назад?
AK> у меня сто лет уже нет сервисов в стране Навозных Петухов, мне без надобности.

Это не связано с сервисами.

AK> А юзерам ничего не поможет.

Вопрос не про абстрактных юзеров, а про тебя.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.2 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Apr 18 14:34:38 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> у меня сто лет уже нет сервисов в стране Навозных Петухов, мне без
AK>> надобности.
EG> Это не связано с сервисами.
AK>> А юзерам ничего не поможет.
EG> Вопрос не про абстрактных юзеров, а про тебя.
пока каналы наружу вообще есть - меня не касается. А когда кончатся - меня не
спасут кривые туннели.

Я тебе еще в 2014м говорил, что времена, когда можно было ограничиться
миграцией любимых бложеков подальше от Скаленовстана - кончились.
Сейчас надо мигрировать себя, и побыстрее. Визу в Штаты уже получить почти
невозможно, скоро закроются и другие ходы, поползешь на брюхе через Финский,
а-ля ВИЛ.

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

(я, собственно, пытаюсь понять - в данном случае бритва Хэнлона
вообще применима, или у людей с 2k BTC в заначке она не играет.)

> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Slawa Olhovchenkov в Feb 19 00:57:22 по местному времени:

25 марта 2018, воскресенье, в 17:45 NOVT, Slawa Olhovchenkov написал(а):

SO> ты зря так думаешь.
SO> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP
SO> mbufjumbopage: 4096, 16777216, 987894, 759655,8205734907395, 0, 0
SO> вот тебе пожалуйста 3ГБ свободной память в mbuf.
SO> она действительно свободная, т.е. сейчас не используется mbuf jubmbo.
SO> а я видел и 40ГБ.
SO> и когда у нас будет дефицит памяти, ты можешь быстро-быстро конечно что-то из
SO> ARC выкинуть.
SO> только во-первых это будет все же что-то наверное нужное, в отличии от
SO> вышепоказанного. а во-вторых оно вообще-то не попадет в систему. оно попадет во
SO> что-то типа (если специально не применить некоторых трюков, а трюки эти таки
SO> немножко дорогие, см.ниже.)
SO> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP
SO> ziodata_buf1048576: 1048576, 0, 217577, 1604,14972433811, 0, 0
SO> (вот тут у нас 1.6Г свободной памяти)
SO> и потом её оттуда достанут, если pressure будет продолжаться. как и из jumbo. и
SO> из остальных мест. и после этого свободной памяти окажется ДОХУЯ.

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

На 11.2-STABLE/amd64 r335757 что-то "потом" у меня так и не произошло
на восьми гигабайтах RAM, когда память кончилась совсем: ZFS ARC выкушал
немного менее своего лимита в 3GB, firefox выжрал 5GB RSS плюс Xorg
плюс xfce4, в итоге в свопе более 3.5GB, Free около нуля, Wired более 4.5GB,
полный трешинг vm с десятками мегабайт page-in/page-out в секунду,
firefox убивался несколько минут, хотя и сдох в конце концов.

Я даже после этого вышел в single user mode и экспортировал пул ZFS,
что дропнуло размер ARC до 44 мегабайт, но Wired остался как был,
включая 1.8 гигабайта "свободных" в adb_chunk и более 450 мегабайт
в dnodet, 350M в zio_buf_512, 226M в zio_buf_16384, 173M в dmu_buf_implt
и ещё 136M в ziodata_buf131072.

Где всё это время был pagedaemon, я так и не понял.

Eugene
--- slrn/1.0.3 (FreeBSD)

Slawa Olhovchenkov написал(а) к Eugene Grosbein в Feb 19 12:32:16 по местному времени:

Нello Eugene!

13 Feb 19, Eugene Grosbein writes to Slawa Olhovchenkov:

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

EG> На 11.2-STABLE/amd64 r335757 что-то "потом" у меня так и не произошло
EG> на восьми гигабайтах RAM, когда память кончилась совсем: ZFS ARC выкушал
EG> немного менее своего лимита в 3GB, firefox выжрал 5GB RSS плюс Xorg
EG> плюс xfce4, в итоге в свопе более 3.5GB, Free около нуля, Wired более
EG> 4.5GB, полный трешинг vm с десятками мегабайт page-in/page-out в
EG> секунду, firefox убивался несколько минут, хотя и сдох в конце концов.

EG> Я даже после этого вышел в single user mode и экспортировал пул ZFS,
EG> что дропнуло размер ARC до 44 мегабайт, но Wired остался как был,
EG> включая 1.8 гигабайта "свободных" в adb_chunk и более 450 мегабайт
EG> в dnodet, 350M в zio_buf_512, 226M в zio_buf_16384, 173M в dmu_buf_implt
EG> и ещё 136M в ziodata_buf131072.

я тебя не понимаю. вот ты всех учишь -- пиши было ли что нестандартное в конфигурации?
а сам?
патчи какие-то наложенны? нет? тогда зачем ты мне пишешь?
да, без патчей как-то так и будет. (и не только и не обязательно с arc. с mbuf* тоже такое бывает. я про это уже года два как знаю)
для минимально хорошего результата нужно хотя бы мой патч.
а для совсем хорошего надо 12 версию, D16667, еще один патч от меня, который нигде пока не опубликован (только послан markj) и модификация моего патча для arc.c

если D16667 спортировать на 11 версию -- то и там можно все сделать.

EG> Где всё это время был pagedaemon, я так и не понял.

отдыхал, если у тебя был vm.vfree_min < vm.stats.vm.v_freecount

при твоем объеме памяти vm.vfreemin довольно невилика, если что. мегабайт 20-30, что ли.

... Не все то глюк, что блестит
--- GoldED+/BSD 1.1.5-b20110223-b20110223