Откачивать или убивать процесс?

[vak]

Помаленьку 4.4bsd начинает оживать. Пытаюсь отловить утечку памяти в ядре, и наблюдаю забавный эффект. Есть два системных процесса, отвечающих за память: демон подкачки (swapper) и демон откачки (pagedaemon). Демон откачки старается поддерживать в ядре определенное количество пустых страниц памяти. Когда он не справляется и страниц становится критически мало, он решает откачать один из процессов целиком на диск, в область свопа. Первыми уходят спящие процессы типа init. Если памяти все еще недостаточно, наступает черед активных процессов. В какой-то момент в своп улетает единственный активный процесс - консольный шелл, и система фактически останавливается. Секунд через десять демон подкачки решает, что пора подкачать шелл обратно, и система оживает.

Это не ошибка, а фича, описанная в книжке Кирка Маккузика. Интересно, что в FreeBSD это место поправили, чтобы ядро никогда не выталкивало активные процессы в своп. Вместо этого самый большой и толстый процесс пришибается сигналом. Я склоняюсь к тому, что для встроенных систем это решение подходит лучше.

Comments

[tim-caper.livejournal.com]

Лучше консольный шелл пристрелить, чтоб не мучился? Хм.
Я склоняюсь к тому, что поддерживать в ядре определенное количество пустых страниц ценой активных процессов - порочная идея.

[nikname.livejournal.com]

А для встроенных систем не лучше что-то более риал-тайм?

[nms.livejournal.com]

Overcommit considered harmful? ;-)

[ircicq.livejournal.com]

Есть ли вообще польза в SWAP во встроенных системах без HDD?
Это же гарантированый износ Flash storage

[vit-r.livejournal.com]

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

[bowhill.livejournal.com]

Я бы наверное оставил что-нибудь на усмотрение администратора. То есть группы лимитов, приоритеты ( возможно с изменчивой эластичностью) и группы процессов. Ну и соответствия. То есть оценочная функция немного сложнее чем "съедим самого толстого".

[ircicq.livejournal.com]

"Съедим самого толстого" хорошо тем, что стимулирует программистов экономить ресурсы.

[bowhill.livejournal.com]

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

Imho, не стоит переоценивать стимуляцию программистов. Мы живём в мире, где средний программист уверен, что может обновлять свой софт 24x7 через Интернет.

[oboguev.livejournal.com]

Есть другой способ: открыть книжку "VAX/VMS Internals and Data Structures" и прочитать о том, как в правильной системе это всё было решено и прекрасно работало в production на высоких нагрузках за много лет до появления BSD.

К слову, года три назад я по параллельной нужде проглядел текст VMS-ного swapper'a и был поражён утончённостью и продуманностью алгоритмики. Главное впечатление было: "такого теперь уже не делают" -- и понятно конечно почему не делают: если система тормозит по нехватки памяти, то правильное решение в новых исторических условиях состоит в том, что нужно добавить памяти столько, чтобы никакого пейджинга не было. Но если для экзотических случаев вроде тех, с которыми ты возишься, то вот.

[sab123.livejournal.com]

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

[sab123.livejournal.com]

Это не то, что обычно понимается под оверкоммитом. Оверкоммит - это относительно всей виртуальной памяти, включая своп. А это - другой оверкоммит, физической памяти.

[sab123.livejournal.com]

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

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

[vak]

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

[vak]

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

[vak]

Так вроде нету недостатка в RTOS для pic32. Вот только с надёжностью стека TCP/IP у них вечно проблема.

[vak]

Да-да, причем во всех смыслах. :)
BSD создавалась как система для университета, чтобы 40 студентов могли запустить каждый по редактору vi и по счётной задаче, одновременно. Подумаешь, уснёт процесс на 10 секунд, пусть студент пока подумает о смысле жизни. Зато никакие процессы не убиваются, сеанс редактирования не теряется, красота. Но для встроенной системы как-то оно не комильфо.

[vak]

Совсем и не гарантированный. За четыре года возни с RetroBSD я ни разу не наблюдал изношенной SD-карточки. Думаю, там какой-нибудь алгоритм выравнивания износа имеется.

[vak]

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

[vak]

Администратора не будет, это же типа встроенный девайс.

[vak]

Спасибо за ссылочку, книжку я проштудирую.
4.3BSD тоже отлично работала на высоких нагрузках, но в 4.4 они решили переделать всю виртуальную память с нуля, то есть от Mach. Кое-что не успели отшлифовать к выпуску релиза, а потом и всю лабораторию CSRG расформировали.

[nikname.livejournal.com]

Кстати, а вы не знаете ли - какие процессоры летают в космос? В СССР мы просто троировали всё и ставили компараторы.

[vak]

На Фобос-Грунте стоял Комдив-32, говорят. Знаю, что некоторые из Элвисовских процессоров летают. Вроде бы даже с моей операционкой (uOS).

[nikname.livejournal.com]

В середине 80-х летали к580. А что там с памятью? Тогда можно было помечать битые куски, как сейчас на флэшках.

[sab123.livejournal.com]

Если ядро сожрало всю память, то система умрет так или иначе.

[vak]

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

[vak]

Про память я точно не знаю. Вроде как изобрели радиационно-устойчивую архитектуру чипов SRAM.

[vit-r.livejournal.com]

Зависит от того, что делает пользователь или целевое устройство. А то будет как с Ариан 5

[vak]

Надо правильно выбирать RTOS при разработке. Ну и системным тестированием (верификацией) не стоит пренебрегать.

[vit-r.livejournal.com]

Ох, если бы всё было "как надо", мир был бы гораздо лучшим местом.

[dvv.livejournal.com]

По-моему, ты Диспак с КРАБом описал.

[oboguev.livejournal.com]

Я вот сейчас уже не помню, а книжку с полки тащить лень: в BSD вообще было понятие working set процесса, т.е. "квоты на память" данного процесса, которую система пыталась удерживать в некоторый пределах, в зависимости от наличия свободной памяти и paging rate данного процесса -- по мере надобности и возможности сжимая или расширяя его working set, а перед тем как решиться на swap-out активных процессов, предварительно trimming их и соседей working sets до некоторого нижнего предела, но пытаясь оставить минимум резидентным? Или там как в Линуксе, один глобальный working set, и если один процесс пострел, то он всё и съел?

[nikname.livejournal.com]

С флэшками можно помечать блоки. А я помню ещё ферритовую на ЕС 1033. Мы ставили ОС МФТ и кусок памяти с ошибкой (16 КБ) накрывали разделом с системным приоритетом. Задачи туда не доходили. Но это - операционка.

[sab123.livejournal.com]

Если ядро сожрало всю память, уже никакой процесс больше не запустится.

[vak]

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

[sab123.livejournal.com]

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

[vak]

Книжка приехала, ценная вещь. Удивительно вообще, насколько много юникс и MIPS унаследовали от VAX.

Понятие working set есть, и в 4.2bsd оно работало примерно как в VMS, отслеживая каждый процесс отдельно. Но в 4.4bsd это дело решили упростить. Как в Линуксе - не знаю, не исследовал.

[sysmanone.livejournal.com]

Ничего там не унаследовали, иначе давно набор костылей был бы сменён на что-то членораздельное.