LINUX.ORG.RU
ФорумTalks

Линукс ядро не может мягко обрабатывать ситуации с нехваткой памяти

 , , ,


4

3

На Reddit уже почти полтысячи комментариев по поводу проблемы в Линукс ядре: оно не может мягко обрабатывать ситуации с нехваткой памяти.

Оригинальное сообщение в LKML:

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

Шаги:

1) Загружаемся с параметром mem=4G
2) Выключаем поддержку swap (sudo swapoff -a)
3) Запускаем любой веб браузер, например, Chrome/Chromium или/и Firefox
4) Начинаем открывать вкладки с сайтами и смотрим как уменьшается объём свободной памяти

Как только возникает ситуация, что новая вкладка требует больше оперативной памяти, чем доступно, система практически полностью зависает. Вы даже с трудом сможете двигать курсором мыши. Индикатор жёсткого диска будет моргать без остановки (мне не ясно почему). Вы не сможете запустить новые приложения или закрыть текущие запущенные.

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

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

В комментариях Reddit некоторые пользователи предлагают включить swap, но это не решает проблему, а только её отодвигает и часто усугубляет.

Подробности

Перемещено Shaman007 из linux-general

anonymous

Ответ на: комментарий от aidaho

Ты не видишь разницы между динамическими лимитами и статическими, что заданы через cgroups?

Deleted
()

Та надо просто Xorg в ядре запилить. Тогда ядро сможет выделить ему гарантированную область памяти и интерфейс будет отзывчивым. Домохозяйки будут довольны, на остальные минусы можно закрыть глаза. Мы переедем на openbsd.

maverik ★★
()
Ответ на: комментарий от Deleted

пусть вебмакаки перепишут весь интернет с браузерами, живо!

Это говнище невозможно переписать. Просто его надо запускать в загончике, где оно больше чем разрешено хозяином сожрать не сможет, вот и всё.

А нормальный софт пусть пользуется всеми благами.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

А нормальный софт пусть пользуется всеми благами

Это ты про Xorg, который тоже может сожрать гигов 8 оперативки при некоторых раскладах? XD

Deleted
()
Ответ на: комментарий от Deleted

Ещё не забывай про прочую обвязку.

Раньше Compiz прилично так тёк, что там за день уже на гигабайт.

То же самое и с Gnome Shell было. И никому до этого особо и дело не было, пока Gnome не засадили дефолтом в Ubuntu, и завыли массово. Подняли скандал по куче линуксовых бложиков.

А тоже самое в Fedora было — ну подтекало ну и ладно.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от fornlr

Обработать ситуацию ОЗУшного поноса оно не сможет (когда приложение прорвало).

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

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

Ну и обратной стороной является сам периодический опрос (ака баланс потребляемого CPU против оперативного реагирования).

Откуда там потребление CPU? Там же какой-ниубдь /proc/XXX/status тупо читается. Раз в секунду, или даже 5 раз в секунду - вообще ни о чём. Тем более, если речь о какой-то интерактивной гуйне, реакция пользователя на которую по-любому будет больше секунды, то вообще не имеет смысла делать опрос чаще чем эта секунда.

Мда. И эти люди что-то про программирование пытаются втирать.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Как демон опрашивающий раз в секунду остановит писец, когда приложения выделят критическое количество ОЗУ за гораздо меньший срок?

А когда пользователь тормоз смотрит на это окно «у нас тут пипец», и отреагирует — это вообще огромная куча времени пройдёт (этак секунд 15).

Поэтому ну не катит такой абстрактный наблюдатель.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от Deleted

Это ты про Xorg, который тоже может сожрать гигов 8 оперативки при некоторых раскладах? XD

Помнится иксы (тогда ещё X86Free) текли во времена первопней и двухголовых матроксов G450. С тех пор такой фигни не припомню. Может иксы тут совсем не при чём, просто какой-ниубдь очередной электрон миллиард невидимых окошек создаёт?

Stanson ★★★★★
()

Сначала придумали overcommit, чтобы облегчить жизнь говнокодерам. Теперь героически с этим борются.

Pacmu3ka
()
Ответ на: комментарий от fornlr

Как демон опрашивающий раз в секунду остановит писец, когда приложения выделят критическое количество ОЗУ за гораздо меньший срок?

Браузер всё-же не сжирает всё ОЗУ как жаба - мгновенно. Это относительно долгий процесс.

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

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

А тут смотря какой механизм применять. Либо мы убиваем без спроса, либо спрашиваем пользователя.

Просто не надо изобретать велосипед. Ну есть же пример macOS. К сожалению не знаю как оно там работает в нутриях.

Но внешне создаётся впечатление такого строго начальника, который в случае пережора просто говорит «всем стоять, сейчас пользователь король 👑 будет решать кого прибить».

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

fornlr ★★★★★
()
Ответ на: комментарий от Deleted

Конечно поручик ни при чём, это вокруг ему все в штаны наваливают

Это ты про вебню? Ну да, говном запахло только когда этот поручик вебмакачьей дивизии в приличное общество припёрся.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Это ты про вебню?

Это я про твой манямирок.

Deleted
()
Ответ на: комментарий от Stanson

Это ты про вебню?

Это какой-то диагноз. Главное постоянно употребляешь «ну тыпые вебмакаки» совершенно ни к месту.

Ну оно понятно, есть такое психологический приём у поехавших. Они так свою самооценку поднимают. Глупо со стороны выглядит конечно, но есть такое.

PS: А я главное глянул на github на код на c/с++. И вроде проекты небольшие, но уже в них так запашком веет. А зато писанины тут на уровня программиста чёрного пояса.

fornlr ★★★★★
()
Ответ на: комментарий от fornlr

всем стоять

Кстати, в Линуксе есть и заморозка процессов.

Deleted
()
Ответ на: комментарий от fornlr

То-то у меня разожравшийся иллюстратор тачку намертво вешает.

Dispetcher14 ★★★★★
()
Ответ на: комментарий от aidaho

все же по дефолту он туда сначала не анонимные страницы кидать начнет. Это надо swappines занижать, чтобы у страниц приоритет был равный

SR_team ★★★★★
()
Ответ на: комментарий от KivApple

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

SR_team ★★★★★
()
Ответ на: комментарий от fornlr

А тут смотря какой механизм применять. Либо мы убиваем без спроса

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

либо спрашиваем пользователя.

Ну вроде как об этом и раздаются стоны же - дайте нам гуйню как в божественной макоси и всё такое.

Но внешне создаётся впечатление такого строго начальника, который в случае пережора просто говорит «всем стоять, сейчас пользователь король 👑 будет решать кого прибить».

STOP послать нетрудно.

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

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

Stanson ★★★★★
()
Ответ на: комментарий от fornlr

Это какой-то диагноз. Главное постоянно употребляешь «ну тыпые вебмакаки» совершенно ни к месту.

«тупые вебмакаки» всегда к месту. Я ни одной умной не встречал ни разу.

Они так свою самооценку поднимают.

PS: А я главное глянул на github на код на c/с++. И вроде проекты небольшие, но уже в них так запашком веет.

Конечно, они ж не сжирают гигабайты ОЗУ, жабокодеру это как серпом по яйцам. :)

Можешь ещё на sourceforge поискать, где-нибудь в районе linux-7110

А зато писанины тут на уровня программиста чёрного пояса.

Жабокодерам пояса выдают? Не знал...

Stanson ★★★★★
()
Ответ на: комментарий от SR_team

все же по дефолту он туда сначала не анонимные страницы кидать начнет.

Неанонимные страницы вообще не попадают в swap.
Их нет смысла писать на диск, потому что они уже на диске.

Это надо swappines занижать, чтобы у страниц приоритет был равный

Всё так, только наоборот: при swappiness 100 приоритеты равны.
И это, на мой взгляд, достаточно разумный вариант.

Но поскольку выкинуть неанонимную страницу в краткосрочной перспективе дешевле, то по дефолту ими жертвуют активнее.

aidaho ★★★★★
()
Ответ на: комментарий от aidaho

4.2, я проверял. Но действительно редко.

1) у меня перед тем как это мистическое событие случится пройдут все эти получасовые этапы с попытками освободить память и срабатыванием OOM killer-а. И после этого malloc() всё равно не вернёт NULL
2) Интересно что у тебя случается когда ты просишь несколько гб памяти одним куском, при том что физически свободно 300 мегабайт. Оно тебе не вернёт NULL, а в процессе записи в эту область будет что? Кто тебе NULL будет возвращать?

reprimand ★★★★★
()
Ответ на: комментарий от kirk_johnson

Ну у него решает. А у других ломает.

я накидал лишь примерный вариант решения этой проблемы

конечную реализацию можно было бы сделать лучше и продуманнее дабы не попадать в странные ситуации которые ты назвал

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

Интересно что у тебя случается когда ты просишь несколько гб памяти одним куском, при том что физически свободно 300 мегабайт. Оно тебе не вернёт NULL, а в процессе записи в эту область будет что? Кто тебе NULL будет возвращать?

Всё так. NULL уже некому возвращать. Ядру остаётся только крутиться волчком.

aidaho ★★★★★
()
Ответ на: комментарий от reprimand

Если что, go, haskell и прочие gc язычки любят зааллоцировать себе гигабайты (а то и терабайты) памяти одним куском, чтобы упростить алогоритм сборки мусора.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Если что, go, haskell и прочие gc язычки любят зааллоцировать себе гигабайты (а то и терабайты) памяти одним куском, чтобы упростить алогоритм сборки мусора.

К сожалению, я отлично это знаю и видел собственными глазами.

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

Ну и вот. Серьезно, виртуальная память это ок. Просто купите памяти так, чтобы хватало с запасом. У меня с 16G таких проблем лет десять уже не было.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

примерно как и с 12309

нагородили костылей чтобы отодвинуть проблему подальше, потому что некому её решать и всем насрать

reprimand ★★★★★
()
Ответ на: комментарий от fornlr

Как демон опрашивающий раз в секунду остановит писец, когда приложения выделят критическое количество ОЗУ за гораздо меньший срок?

earlyoom опрашивает до 10 раз в секунду, справляется с выделением памяти на максимальной скорости через stress.

nohang имеет настраиваемую частоту опроса, можно любую частоту выставить.

hakavlad ★★★
()
Ответ на: комментарий от kirk_johnson

воз и ныне там

Воз и ныше там если не использовать юзерспейсные обработчики.

Если использовать юзерспейсные обработчики - проблема полностью решаема.

hakavlad ★★★
()
Ответ на: комментарий от hakavlad

Ну как решаема: часть твоего софта будет убита. Если тебе жизненно важно быстро решить свои вопросики, а тебе система софт убивает, то скорее наоборот.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

часть твоего софта будет убита

Смерть одного процесса - это лучше, чем полная потеря системы при зависании.

hakavlad ★★★
()
Ответ на: комментарий от kirk_johnson

если части твоего скрипта не умеют работать с ограниченным объемом памяти - то это их проблемы
если этот софт рассчитывает, что malloc() будет адекватно возвращать NULL когда заканчивается память, но malloc() этого не делает и у тебя вся работа накрывается медным тазом, то это проблема linux

reprimand ★★★★★
()
Ответ на: комментарий от Stanson

Существование жабы - это не писец, это жованый крот.

Я конечно догадываюсь, что это фигура речи, но вы могли бы, в порядке исключения, разъяснить основные отличия?

TomBOY ★★
()
Ответ на: комментарий от Stanson

юзер один фиг больше секунды тупить будет, прежде чем выберет кого убить

Никто не будет тупить. Позовут «Васю» и тот сам нажмёт, что нужно.
Если «Васи» нет, то будут в телефоне впашку писать гневные посты.

TomBOY ★★
()
Ответ на: комментарий от Stanson

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

Более того, интерфейс к SIGSTOP/SIGCONT давно реализован в TDE/twin.

aidaho ★★★★★
()
Ответ на: комментарий от reprimand

если части твоего скрипта не умеют работать с ограниченным объемом памяти - то это их проблемы
если этот софт рассчитывает, что malloc() будет адекватно возвращать NULL когда заканчивается память, но malloc() этого не делает и у тебя вся работа накрывается медным тазом, то это проблема linux

Я бы может и согласился, если бы увидел хоть одну софтину, которая может пережить отказ в malloc().
Такое наверное только в драйверах есть.

Завернуть каждый malloc() в обработчик, который сможет что-то корректное сделать, кроме смерти с сообщением «out of memory», в каждом случае возврата NULL — почти нереальная задача, учитывая что сделать это надо не запрашивая ни единого нового блока памяти.

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

aidaho ★★★★★
()
Ответ на: комментарий от i-rinat

Ты знаешь, что делает Windows, если отключить своп вообще? Она создаёт своп-файл сама, но тайком, внутри C:\WINDOWS.

Откуда информация?

question4 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.