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
Ответ на: комментарий от greenman


должен быть зарезервирован объем памяти для рута


admin_reserve_kbytes

«Замечено, что на процессы запускаемые от root-a через systemd эта самая зарезервированная в размере admin_reserve_kbytes оперативка не выделяется, а просто себе болтается без дела, и в этом можно убедится опытным путём.»

https://www.remoteshaman.com/unix/common/overcommitting-linux-memory-and-admi...

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

всех воплями о «недостатках» линукса

Всё так. Проблема не в линуксе, а в сборщиках дистрибутивов, не включающих юзерспейсные обработчики в поставку по умолчанию. Ибо проблема давно решена в юзерспейсе.

Это не линукс плохой, а состав дистров по умолчанию плохой (earlyoom не включен).

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

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

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

top - 10:27:00 up 3 days,  2:37,  1 user,  load average: 0.19, 0.24, 0.22
Tasks: 252 total,   1 running, 186 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4.8 us,  1.0 sy,  0.0 ni, 93.9 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  8072132 total,   761304 free,  3301412 used,  4009416 buff/cache
KiB Swap:  8388604 total,  8388604 free,        0 used.  3939588 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND        
20220 ****      20   0 20.766g 274968  93048 S   0.3  3.4  10:02.89 WebExtensions                   

Это одна из строчек вывода top: процесс принадлежит firefox-y. В столбце «VIRT» выводится объем аллоцированной (но не используемой) памяти. Там 20G! Это при том, что в системе 8 Gb оперативы и 8 Gb свопа, т.е. такой объем памяти недоступен по-любому. И это один сраный файрфокс.

Как прикажете решать проблему?

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

резервирует в разы, а то и в десятки раз больше памяти, чем использует

Напомните, что в этом плохого? У меня оверкоммит в единице, брат жив, система не виснет.

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

Напомните, что в этом плохого?

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

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

Это при том, что в системе 8 Gb оперативы и 8 Gb свопа, т.е. такой объем памяти недоступен по-любому. И это один сраный файрфокс. Как прикажете решать проблему?

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

Пруф: мой десктоп, так котром overcommit=0.

загнать систему в состояние thrashing, из которого довольно трудно выйти

В юзерспейсе для этого даже есть https://github.com/tobixen/thrash-protect

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

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

Ты меня за идиота что ли держишь? Конечно, это не проблема, когда не используют. Это становится проблемой, (thrashing) когда начинают использовать, возможно даже одновременно.

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

Поведение системы при запрете оверкоммита: https://imgur.com/a/p9j67KA

Жду оправданий сторонников такого подхода.

К чему приводит запрет оверкоммита:

- неполная утилизация доступной памяти;

- неожиданное поведение программ когда выделенный лимит заканчивается.

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

Настоящее решение проблемы — лимиты.

1. Лимиты препятствуют утилизации памяти.

2. Лимитируемые процессы могут вести себя непредсказуемо, см https://imgur.com/a/p9j67KA

Настоящее решение лежит в юзерспейсных обработчиках, и это решение прекрасно работает.

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

1. Лимиты препятствуют утилизации памяти.

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

2. Лимитируемые процессы могут вести себя непредсказуемо, см https://imgur.com/a/p9j67KA

Наглейшее 4.2
Вы же постом выше сознались, что включили легаси режим malloc(), на который тут пол-треда разные граждане слюной истекали.
Что ж такое, почему не нравится? :)

решение лежит в юзерспейсных обработчиках, и это решение прекрасно работает

Юзерспейсный обработчик убивает процесс. Он не даёт ему работать.
Поставленная машине задача не выполнена.

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

При этом пользователь имеет выбор: может позакрывать программы и дать жирной задаче спокойно отработать. Может прибить. А может наоборот запускать что-то ещё.
Что хочет, то и делает.

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

Вы же постом выше сознались, что включили легаси режим malloc()

Это https://imgur.com/a/p9j67KA получено при overcommit_memory=2, overcommit_ratio=80

Юзерспейсный обработчик убивает процесс.

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

Поставленная машине задача не выполнена.

Задача - минимизировать ущерб при разруливании нехватки памяти. Запрет оверкоммита с этип справляется хуже.

Но он продолжает работать и рано или поздно завершится успешно.

На картинках выше опытным путем показано, что процессы валятся на ошибках, а не завершаются корректно или по воле юзера.

Что хочет, то и делает.

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

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

гетти сожрал всю память? ну и ну.

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

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

при overcommit_memory=2

Ну вот, а дальше

процессы валятся на ошибках

Зато в порядок в компьютере, лол.
Вон как жирнософт к стенке поставили.

Задача - минимизировать ущерб при разруливании нехватки памяти.

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

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

Именно.


Осталось выяснить, как всё это бессмысленное и беспощадное твикерство относится к лимитам cgroups?

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

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

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

настрой лимиты нормально, горе ты моё луковое.

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

А иначе сколько памяти не дай хром и лиса всё сожрут.

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

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

Вон как жирнософт к стенке поставили.

К стаенке поставили случайные просессы, которые пытались выделить память. Жирнософт выжил.

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

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

Проблема не в том, что памяти мало, а в том, как система реагирует на нехватку памяти, если она случается.

Вопроса два: 1. Как недопустить нахватку памяти. 2. Как систему заставить адекватно реагировать на нехватку, если она все же случилась.

Именно второй вопрос обозначен в ОП-посте.

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

Проблема не в том, что памяти мало

Вот те на, приехали

а в том, как система реагирует на нехватку памяти, если она случается.

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

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

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

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

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

паровозными свистками, жалобными письмами

Неплохой вариант. Юзерспейсные обработчики умеют уведомлять пользователя о нехватке памяти через уведомления notify-send, что позволяет пользователю заблаговременно отреагировать.

hakavlad ★★★
()
5 декабря 2019 г.

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

Einstok_Fair ★★☆
()
24 февраля 2020 г.
Ответ на: комментарий от aidaho

Должна сообщить приложению, которое запрашивает больше памяти, чем есть, что все, приехали, памяти больше нет.

Легко:

sudo sysctl -w vm.overcommit_memory=2

Ограничение оверкоммита ограничивает виртуальную память, а не реальную. Приложения будут падать при полупустой памяти или при полупустом свопе, как здесь https://imgur.com/a/p9j67KA.

Лучшее решение - юзерспейсные обработчики, способные реагировать как при исчерпании физической памяти и свопа, так и реагировать на заморозку десктопа при активном своппинге на основе метрик PSI.

Демо: обработка нехватки памяти при исчерпании свопа: https://youtu.be/PLVWgNrVNlc.

Демо: прекращение заморозки десктопа при активном своппинге на основе метрик PSI: https://youtu.be/Y6GJqFE_ke4.

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

Хорошо бы подвести некий итог

Некоторые итоги уже имеют практическое воплощение: Fedora 32 Workstation будет поставляться с включенным по умолчанию earlyoom. А Леннарт планирует включить oomd в systemd, и это не шутка.

hakavlad ★★★
()
28 августа 2020 г.
Ответ на: комментарий от KivApple

Почему нельзя так настроить систему, чтобы oom killer пришел до выкидывания неанонимных страниц памяти или же вовсе запретить их выкидывать?

Вообще-то можно: https://github.com/hakavlad/prelockd

hakavlad ★★★
()
13 марта 2021 г.
Ответ на: комментарий от darkenshvein

надо выделять кусок неприкосновенной памяти для гуя тогда)

uresourced уже применяется в Fedora Workstation 33

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

Подключитесь по SSH и прибейте руками еще

sshd[666]: error: fork: Cannot allocate memory
hakavlad ★★★
()
Ответ на: комментарий от reprimand

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

какую проблему?

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