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

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

Это все круто, но я все ещё не вижу от тебя дизайн-документа. Вот когда доставишь — тогда и поговорим.

на текущий момент от тебя я вообще ничего не вижу

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

на текущий момент от тебя я вообще ничего не вижу

То есть дизайн-документа мы не дождемся? Ну что и требовалось, в общем-то.

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

без гарантий компенсации в случае реализации - нет

что и требовалось доказать - ты способен только на предёж в лужу

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

отдавал несколько гигабайт в секунду

Быдлокиллеры просто зависли бы вместе со всем остальным.

Нет. earlyooom и nohang прекрасно обрабатывают выделения гигабайт в секунду. И tail /dev/zero, и stress без проблем обрабатываются.

Пример вывода nohang: http://okturing.com/src/6704/body

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

юзерспейс-гипервизор с кучей процессов? Хром, например, ЕМНИП, так и работает, не?

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

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

Небось сходил и поставил галку «оптимизировать работу служб»?

Про 95 и NT4 утверждать не берусь, а в остальных — всё по умолчанию.

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

Как ядро отличит gui оболочку от не гуи оболочки?

если среди mmap()леных регионов памяти есть X-овые либы - это уже признак что это GUI

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

Почему не настроено? Посмотри что у тебя выдаст sysctl -a | grep admin

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

И? Ну в смысле DISPLAY есть у всего, включая вызванный из сабшелла less.

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

на тех системах и галку отмечать будет некому

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

Ты это по опыту пишешь или так треплешся? Как часто он тебя спасал? И почему у меня 99% случаях все зависает? Своп есть.

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

Никогда не видел чтобы у меня ООМ убивал gimp или blender, firefox.

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

юзер всегда мог залогиниться в рута и кильнуть что там из апликух выжрало всю память?

Не надо никуда логиниться, открой для себя Alt-SysRq-F уже.

no-such-file ★★★★★
()
Ответ на: комментарий от LinuxDebian

По опыту. Когда dirsrv едет крышей к нему приходит OOM, но все остальное остается на месте (а dirsrv может быть перезапущен systemd, но как правило этого не происходит, не зря же он крышей едет).

Shaman007 ★★★★★
()

Ой, гевалт! Я только что понял, что сообщение в рассылке было от birdie.

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

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

darkenshvein ★★★★★
()
Ответ на: комментарий от post-factum

псс. какой планировщик рекомендуется использовать с pf-ядром?
спасибо.

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

Во-первых, процесс с наибольшим количеством памяти убьет OOM-killer

Если вдруг еще не ответили но вся проблема в том что этого как раз и не происходит. Уж не знаю деталей как это работает но все повисает намертво с тем же браузером и вкладками. Самое интересное что сторонние утилиты помогают, я последние пол года всегда держу запущенным nohang.

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

Мне нужно переписать все существующие тулзы, да? Опять?

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

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

Вангую, если так сделать, то весь интернет заполнится хоровым воплем «да склолько же этому вашему проклятому линуксу нужно памяти?!» А может и не заполнится. Браузер будет убит OOM пока камент строчится %)

ДА! Только перед смертью браузер должен выдать сообщение «вы пытались открыть несуразно пузатый сайт, браузер будет прибит, жалуйтесь сайтостроителям». Народ наплюет на фейсбуки, все мировое сайтописание развернется в сторону минимализма. Вспомните Гейца - «640к должно хватить всем». Только эту фразу надо произносить не как предсказание, а угрожающим тоном. И вы поймете ее настоящий смысл.

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

ДА! Только перед смертью браузер должен выдать сообщение

Он не может.

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

Постом выше как раз писал об этом: в любой программе чуть сложнее консольного калькулятора невозможно адекватно отреагировать на отказ ОС в выделении памяти.


Джин вылез из бутылки и назад невпихуем.

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

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

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

Ну так пишите же, пишите!

А то на словах выходит так, что те кто могут, не умеют.
А те кто умеют — то ли не хотят, то ли не могут.

Наверное заговор иллюминати производителей чипов DRAM.

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

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

vaddd ★☆
()
Ответ на: комментарий от cvs-255

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

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

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

Только после этого все с удивлением узнают, что после хрома нельзя уже ззапустить файрфокс. Или наоборот. Потому что криворуки программисты не привыкли просить сколько надо — это же трудно считать и «неоптимально»! Проще просить хорошо так с запасом! А даже если ты аккуратен, то под тобой — сотни библиотек, которые тоже не очень заботятся быть точными и нежадными.

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

malloc() при нехватке памяти должен возвращать NULL, а fork() - фейлиться. И пускай хром сам решает, что ему не запускать, съесть памяти больше, чем можно ему не выйдет.

cvs-255 ★★★★★
()

пользователи [..] просто откажутся от использования Линукс

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

beastie ★★★★★
()
Ответ на: комментарий от cvs-255

malloc() при нехватке памяти должен возвращать NULL

Это ровно то, что происходит при vm.overcommit_memory=2. Сделай и увидишь чудную картину: после запуска хромиума с парой десятков вкладок что-либо еще запустить будет трудновато. Именно потому что говнософтописатели не думают о количестве запрошенной памяти.

Именно поэтому в линуксячье ядро и включили костыль в виде «эвристического» overcommit-а. И именно это порождает ту проблему, которой «почетная истеричка ЛОРа», г-н birdie заспамил LKM, opennet и тутошние просторы.

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

И этот позорник уже лет 15, не меньше, доканывает всех воплями о «недостатках» линукса. Ему бы розог по жопе да отправить учиться, но, видимо, не поможет.

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

Во-вторых, помимо NULL, должен быть зарезервирован объем памяти для рута, чтобы можно было переключиться в консоль ядра и убить жручий процесс

Система не должна вставать раком когда хром выжрал всю память! Если хром жручий - страдать от этого должен только хром или еще что-то жручее, но не базовый UI! система всегда должна иметь возможность дать пользователю убить жручий процесс.

cvs-255 ★★★★★
()
Последнее исправление: cvs-255 (всего исправлений: 3)
Ответ на: комментарий от unanimous

И именно это порождает ту проблему, которой «почетная истеричка ЛОРа», г-н birdie заспамил LKM, opennet и тутошние просторы.

Ну и зачем такое «решение», если система становится абсолютно неюзабельна?

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