The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлен low-memory-monitor, новый обработчик нехватки памяти для GNOME

24.08.2019 21:35

Бастьен Носера (Bastien Nocera) анонсировал новый обработчик нехватки памяти для рабочего стола GNOME - low-memory-monitor. Демон оценивает нехватку памяти через /proc/pressure/memory и при превышении порога отправляет через DBus предложение процессам о необходимости умерить аппетиты. Также демон может пытаться сохранить отзывчивость системы через запись в /proc/sysrq-trigger.

В комбинации с проведённой в Fedora работой по применению zram и прекращению использования дисковой подкачки, low-memory-monitor позволяет добиться повышения отзывчивости и качества работы на большинстве рабочих станций. Проект написан на языке C и поставляется под лицензией GPLv3. Для работы демона необходимо ядро Linux 5.2 или новее.

  1. Главная ссылка к новости (https://www.reddit.com/r/linux...)
  2. OpenNews: Ядро Linux не может мягко обрабатывать ситуации с нехваткой памяти
  3. OpenNews: Выпуск earlyoom 1.3, процесса для раннего реагирования на нехватку памяти
  4. OpenNews: Выпуск Nohang 0.1, предотвращающего OOM в пространстве пользователя
  5. OpenNews: Facebook открыл код для обработки ситуации нехватки памяти в системе
  6. lmkd - userspace lowmemorykiller daemon
Автор новости: hakavlad
Тип: Программы
Ключевые слова: memory, oom
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (98) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.94, кек (?), 16:33, 26/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот обновленное сравнение юзерспейсных киллеров earlyoom простой, лёгкий, стаб... текст свёрнут, показать
     
  • 1.1, Аноним (1), 22:59, 24/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +20 +/
    > отправляет через DBus предложение процессам о необходимости умерить аппетиты

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

     
     
  • 2.6, Аноним (6), 23:15, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    >отправляет через DBus предложение процессам о необходимости умерить аппетиты

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

     
     
  • 3.13, Xasd (ok), 23:44, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> отправляет через DBus предложение процессам о необходимости умерить аппетиты
    > С трудом верится, что процессы не будут игнорировать эти сигналы. Скорее всего почти все проги будут забивать кек на этот сигнал.

    интересно, а точно ли процессы должны слушать этот DBus а не сами лезть в /proc/pressure/memory ?

    какой толк от Демона если это всего-лишь посто прослойка?

     
     
  • 4.81, КО (?), 09:15, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Универсализм настройки. Так каждому приложению надо изобретать тот порог по которому умерять аппетит.
     
     
  • 5.83, Xasd5 (?), 10:27, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а нельзя так придумать чтобы работало без кручения руками настроек?
     
  • 4.84, Ordu (ok), 12:34, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > какой толк от Демона если это всего-лишь посто прослойка?

    Эта прослойка работает через универсальный интерфейс взаимодействия с внешней средой. Не поллинг файликов: поллинг файликов в главном цикле где хочется ограничить latency (скажем, чтобы гуй не залипал) -- это самоубийство. Тут правда псевдофс, она по идее не должна блокировать файловые операции, но я не знаю в точности, даёт ли ядро такие гарантии, и даже выяснять не хочу: при наличии оповещений по dbus, я предпочту их.

     
     
  • 5.88, Аноним (88), 13:13, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Эта прослойка работает через универсальный интерфейс взаимодействия с внешней средой

    Это откуда у гномеров руки растут?

     
     
  • 6.90, Ordu (ok), 14:43, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Эта прослойка работает через универсальный интерфейс взаимодействия с внешней средой
    > Это откуда у гномеров руки растут?

    Это через dbus. Если место роста рук у других не позволяет им использовать dbus, то тогда да, можно указать в качестве причины место роста рук.

     
  • 3.21, all_glory_to_the_hypnotoad (ok), 00:46, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Главное чтобы сам DBus дожил до нужного момента и ему не прислали чёрную метку.
     

  • 1.2, Анонидзе (?), 23:01, 24/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А чё не Earlyoom? Нормальная же штука. Или это типичный GNOME-way?
     
     
  • 2.3, Аноним (6), 23:03, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Или это типичный GNOME-way?

    This. Это поделка уровня earlyoom 0.1, c той лишь разницей, что детекцию проводит через /proc/pressure/memory вместо /proc/meminfo.

     
  • 2.7, Аноним84701 (ok), 23:17, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  Или это типичный GNOME-way?

    Очевидно же, что если убить текущую (в очередной раз) Гномо-Щель:
    https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/
    > Well, as stated in the comment, GJS’ garbage collect was indeed collecting memory when triggered. Problem is, it wasn’t being triggered at all.

    https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
    > On Ubuntu 17.10, gnome-shell starts the day on 569.9MiB for me, and ends around 2GB. It got up to 5GB over two days. Now I shutdown every night.

    Убъется весь сеанс пользователя ;)

     
     
  • 3.34, eugener (ok), 08:32, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но ведь этот баг исправили давно!
     
     
  • 4.48, Аноним84701 (ok), 12:59, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но ведь этот баг исправили давно!

    Это у них традиционное:

    https://bugzilla.gnome.org/show_bug.cgi?id=777537
    > Gnome 3.22.2 + GDM 3.22.1 : Memory leaks
    > 2017-01-20

    https://bugzilla.gnome.org/show_bug.cgi?id=789634
    > 2017-10-29

    https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
    > #64 · opened 1 year ago

    https://gitlab.gnome.org/GNOME/gnome-shell/issues/653
    > #653 · opened 10 months ago

    https://gitlab.gnome.org/GNOME/gnome-shell/issues/1359
    > #1359 · opened 2 months ago

     
  • 4.82, КО (?), 09:17, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это ж не баг, а оснопологающая фича Вяленного.
     

  • 1.4, Аноним (6), 23:12, 24/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    >В комбинации с проведённой в Fedora работой по применению zswap

    No.

    Installing and enabling zram by default (already merged):
    https://bugzilla.redhat.com/show_bug.cgi?id=1731598
    https://pagure.io/fedora-comps/pull-request/391

    Disabling disk-based swap by default:
    https://bugzilla.redhat.com/show_bug.cgi?id=1731978

    - https://pagure.io/fedora-workstation/issue/98 - Федора переходит на zram, а не zswap. Это можно, кстати, в отдельную новость выделить.

     
  • 1.5, zloykakpes (ok), 23:14, 24/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    В этой новости прекрасно всё.
     
  • 1.9, Аноним (9), 23:24, 24/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –13 +/
    опять на си, он не помогает в написании корректных программ
     
     
  • 2.10, Аноним (6), 23:28, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А у раста бинарники слишком жирные и его еще никто не выучил.
     
     
  • 3.18, Аноним (18), 23:58, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Причем тут размеры бинарников раста? Посмотри сколько рамы на твоем десктопе занимают Gnome Software + PackageKitD.
     
     
  • 4.71, Аноним (71), 23:01, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все и так плохо, давай ещё и раста подкинем, чтобы совсем адъ?
     
  • 2.11, Аноним (6), 23:29, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    в earlyoom утечек нет, хоть он и на си - стабильно 1 МБ потребляет
     
  • 2.28, Аноним (28), 02:05, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +17 +/
    > опять на си, он не помогает в написании корректных программ

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

    А от того, что вместо UB вы получаете стектрейс, программа корректной не становится.

    Однако в отличие от многих других, си помогает в написании БЫСТРЫХ программ.

     
     
  • 3.29, Hewlett Packard (?), 03:18, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • –11 +/
    Хорошее собрание типично юниксовых заблуждений времен расцвета.
     
     
  • 4.40, anonymous (??), 10:14, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А в чём конкретно заблуждение?
     
     
  • 5.76, имя_ (?), 04:01, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    в том, что до сих пор кто-то ведется на такую жырноту
     
  • 3.31, Аноним (31), 03:31, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Насчёт того, что си быстрее можно долго и бесполезно спорить, ибо цель у языка только в скармливании компилятору, от которого больше зависит. А вот то, что си максимально примитивен в плане абстрагирования от того, что происходит в машине - это факт, который кому то в плюс, а кому то в минус.
     
     
  • 4.33, Hewlett Packard (?), 04:25, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это если машина - PDP-11. Если же обсуждать то как работает что-то посовременнее, то кто там дальше от execution units, cache line bouncing или например wear leveling, Си, Haskell, или brainfuck - вопрос дискуссионный.
     
     
  • 5.50, Аноним (50), 13:13, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это если машина - PDP-11. Если же обсуждать то как работает что-то
    > посовременнее, то кто там дальше от execution units, cache line bouncing
    > или например wear leveling, Си, Haskell, или brainfuck - вопрос дискуссионный.

    Не обязательно валить все известные buzzwords в кучу, достаточно посмотреть реализацию vfprintf в musl -- она строго 32-х разрядная.

     
     
  • 6.97, Hewlett Packard (?), 03:09, 27/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Надеюсь еще и вручную оптимизированная под конкретный размер кэшей конкретной линейки CPU конкретного производителя, с ассемблерными вставками, профайлингом доведенными до совершенства скорости работы на конкретном поколении конкретной линейки CPU конкретного производителя.
     
     
  • 7.100, Аноним (50), 06:33, 27/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Надеюсь еще и вручную оптимизированная под конкретный размер кэшей конкретной линейки CPU
    > конкретного производителя, с ассемблерными вставками, профайлингом доведенными до совершенства
    > скорости работы на конкретном поколении конкретной линейки CPU конкретного производителя.

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

     
  • 3.52, Аноним (9), 13:49, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ни один язык не помогает

    Ну почему же, пресловутый раст помогает, например. Программа просто не скомпилится, а компилятор ещё и покажет как надо написать.

     
     
  • 4.58, Аноним (58), 15:57, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    -Wall -Werror
     
     
  • 5.73, DerRoteBaron (ok), 23:11, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    И половина ошибок не отловится.
    Даже -Wextra -Wpedantic. Только вынесут мозг наркоманией с приведениями численных типов одного к другому там, где это совершенно не требуется просто потому, что так в свое время сделали не подумав, а потом так же и стандартизировали.
    Не говоря о том, что ошибки компиляторов (GCC, clang) совершенно невнятные, а иногда и неочевидные. А про плюсы, где все описанные еще раз в 100 более сломано даже речи не было.
     
  • 4.99, Hewlett Packard (?), 03:18, 27/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как известно, неприятные ошибки состоят по большей части из опечаток, off-by-one error, и cache invalidation. Это чисто технические, еще большая часть ошибок логические. Как именно компилятор Rust помогает с каждым из этих типов ошибок?
     
  • 2.96, Аноним (96), 23:19, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то твой всраст не помог огнелису стать нормальным браузером. Хром, на проклятых плюсах, все так и дает ему по морде.
     
     
  • 3.98, Hewlett Packard (?), 03:15, 27/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не защищая Rust, пример-то так себе. Вложив того и столько, чего и сколько в Chrome вложил Гугл, его можно было бы сделать точно таким же (во всяком случае не хуже) на любом языке, включая COBOL и РАПИРА, или совсем без оного - прямо в машинном коде, редактируя бинарник в ed.
     

  • 1.12, Аноним (12), 23:36, 24/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Как же хорошо, что в винде нет таких проблем.
     
     
  • 2.15, denkin (ok), 23:45, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Но как плохо, что в винде проблем гораздо хуже полно)))
     
     
  • 3.20, zzz (??), 00:21, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Бяда с ентой вендой. То DKMS поломают, то в OOM-Killer завозят патчи, беспричинно убивающие всё подряд, то CVE-2012-0056. В линуксе такой фигни нет.
     
     
  • 4.22, Аноним (22), 00:50, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вы чуть перепутали названия, но в целом верно согласен.
     
  • 4.25, BlackRot (?), 01:17, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В линуксе полно другой фигни
     
  • 2.16, Xasd (ok), 23:46, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    почему хорошо? было бы хорошо если бы мы её использовали
     
  • 2.17, Albertio (ok), 23:48, 24/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно, местные зонды сами знают, как занять всю доступную память
     
     
  • 3.19, Аноним (18), 00:05, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В винде Memory Compression работает всегда, не важно сколько рамы 8 или 64 ГБ. Если нет возможности найти физически свободных адресов, произойдет одно из двух: 1. Закроется самая тяжелая программа. 2. Нарисуется окно с предложением закрыть эту самую тяжелую программу.
     
     
  • 4.30, ананим.orig (?), 03:25, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вот как?
    а в линухе compression — это сжатие, а не освобождение.
    ну типа zip. или для вас rar
     
     
  • 5.95, Аноним (95), 21:48, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ARJ
     
  • 4.37, кек (?), 09:30, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >В винде Memory Compression работает всегда

    Это означает ее низкую гибкость и невозможность отключения свопа. В линуксах zram/zswap давно доступны по желанию и гибко настраиваемы. Кому надо - ставят.

     
     
  • 5.74, Аноним (18), 00:25, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Оно не доступно при выключенном pagefile, и не нужно ничего "гибко" настраивать. Поставил ОС - работает и вместе с гибернацией из коробки всегда.
     
  • 2.27, ананим.orig (?), 01:29, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Как же хорошо, что в винде нет таких проблем

    с чего ты взял?
    сварить то вообще можешь в вантузе отключить?

     
  • 2.32, Аноним (31), 03:34, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вы забываете, что в некоторых других дистрах такой фигни тоже нет, всё зависит от понимания дистрибьютера того, какую хрень он творит. И в дистрах на линуксе полное раздолье (хотя и не предел мечтаний), а в винде у вас только один дистрибьютер.
     
  • 2.45, Аноне (?), 11:32, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Со старта 1,5 Гб при сжатии - да, нет проблем, уже зарезервировали.
     

  • 1.14, denkin (ok), 23:44, 24/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Сперва они пишут приложухи, которые жрут память, а потом они пишут еще одну приложуху, которая говорит остальным приложухам сколько им можно жрать памяти, которая тоже жрет память; а потом они напишут еще...

    Прям сказка про белого гнома какая то.

     
     
  • 2.24, Аноним (22), 00:52, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Сперва они прекращают возвращать NULL из malloc, а потом уже пишут приложухи, которые жрут память и т. д.
     
     
  • 3.26, zzz (??), 01:25, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Больше велосипедов богу велосипедов!
     
  • 2.41, anonymous (??), 10:17, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Какая разница будет сожрана память в ядре или в userspace-е? Что действительно важно, это то, что "ещё одна приложуха" жрёт память статически (и реально мало, к тому же), а не динамически.
     

  • 1.23, RedEyedMan (ok), 00:52, 25/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > On Ubuntu 17.10, gnome-shell starts the day on 569.9MiB for me, and ends around 2GB. It got up to 5GB over two days.
    > Now I shutdown every night

    "Я выключаю компьютер каждую ночь, я успешен, я свободный от задродство человек!" или тому подобное.

     
     
  • 2.38, Аноним (38), 10:03, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Окстись, гонм юзают только хомячки.
     
     
  • 3.43, Аноним (43), 10:41, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    kde plasma держу планшет неделями в слипе.
     
     
  • 4.63, Аноним (63), 16:58, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И не вывожу из него
     
     
  • 5.77, Аноним (77), 05:27, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    я тоже, причём как раз 17.10 )
     

  • 1.35, Аноним (43), 08:52, 25/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Requires Linux 5.2 or newer and GLib.
    Беполезный мусор для хипстеров. Даже поддержки последнего lts нет. Считай, все дистрибутивы кроме ролинг релизов в пролете. Да и я не знаю кем надо быть чтоб ставить 5.2.9 на свой комп. Там же может быть любая хрень вплоть до поломок фс.
     
     
  • 2.36, кек (?), 09:11, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Он еще только анонсирован, релизов не было. Через пару лет окрепнет, и дистры к нему будут готовы, даже Дебиан Стейбл.
     
  • 2.39, Аноним (38), 10:09, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Беполезный мусор для хипстеров.
    >> для GNOME

    Кеп?

     
  • 2.42, iPony129412 (?), 10:19, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А толку то делать эту новую штуку под старые ядра?
    Та же Ubuntu 18.04 LTS сейчас идёт с ядром 5.0.
    Эта штука новая будет до более вменяемое состояния написана этак через полгода.
    Так что проблемы то нет.
     

  • 1.44, JL2001 (ok), 10:49, 25/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    //offtop
    > обработчик нехватки памяти для рабочего стола GNOME

    это что, официальное признание гномеров что гном жрёт больше всех, а другим такого не надо?

     
     
  • 2.46, Аноним (6), 11:40, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >а другим такого не надо?

    А другие давно используют earlyoom, и только гномеры завезли себе персональную, только с гномом совместимую, кривую поделку.

     

  • 1.47, Аноним (47), 12:46, 25/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Что бы делать, лишь бы ядро не фиксить. Потому что все эти демоны-кильеры не решают проблемы того, что на винде программы прекрасно работают, а на линуксе либо ты выключаешь оверкоммит и проги крэшатся и не стартуют, либо ты включаешь оверкоммит и у тебя всё виснет, либо ты ставишь эти демоны и они убивают программы.

    Во всех случаях работать невозможно, и тем, кому работать нужно, приходится использовать Windows 7/8/10, все с телеметрией (для 7 телеметрию встроили в security-only обновление, даже те, кто готов нехило заплатить за отсутствие телеметрии не имеют этой возможности).

    Зачем фиксить ядро, если можно просто памяти накупить и вставить. Тех, кому неприемлимо постоянно комп всяким гoвнoм апгрейдить, наверное, за унтерменшей считают.

     
     
  • 2.49, Аноним (6), 13:13, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >ты выключаешь оверкоммит

    Если мозгов нет

    >Что бы делать, лишь бы ядро не фиксить.

    В ядре есть ООМК. Ядро не надо фиксить.

    >эти демоны-кильеры не решают проблемы

    Демоны-киллеры полностью решают проблемы.

    >ядро, если можно просто памяти накупить и вставить

    Ядро не может заменить оперативу. Тюнинг vm и вкл свопа - это не рагает проблему малого обема ОЗУ. Одкако юзерспейсные киллеры решают проблему дедлоков при нехватке памяти.

    >либо ты включаешь оверкоммит и у тебя всё виснет

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

     
     
  • 3.61, Аноним (47), 16:37, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Толсто Без оверкоммита ни единого тормоза до резета с остервенелым шуршанием ви... текст свёрнут, показать
     
     
  • 4.64, Аноним (6), 17:25, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Просто программы крешатся и перестают стартовать

    Вот именно, причем могут падать массово, зачастую рандомные и невиновные, пруф: https://imgur.com/a/p9j67KA

    В случае с юзерспейсным киллером падает только один жирный процесс, и падает мягко, по SIGTERM.

    >желание хамить

    Я лишь исправил ваши ложные утверждения.

     
     
  • 5.65, Аноним (47), 17:46, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >В случае с юзерспейсным киллером падает только один жирный процесс, и падает мягко, по SIGTERM.

    Причём тоже невиновный. В общем, метод действия у меня такой:
    1. отключается оверкоммит
    2. в случае, если приложения перестают стартовать, вручную прибивается шланг.

     
  • 2.51, Аноним (51), 13:20, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > для 7 телеметрию встроили в security-only обновление, даже те, кто готов нехило заплатить за отсутствие телеметрии не имеют этой возможности

    Соберите себе дистр без этих конкретных обновлений - и запретите обновляться вообще.

     
     
  • 3.62, Аноним (47), 16:45, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И не пускайте в интернет: критические обновления безопасности идут в комплекте с телеметрией. Единственный правильное действие тут - это не использовать винду и прочие проприетарные поделия вроде Intel ME и ARM TrustZone. Даже если это будет значить отказ от компьютеров и технологий вообще и переезд в пещеру. Действие единственно правильное, но совсем неабекватное.

    Адекватные предложения будут (кроме "надо забить на эту чепуху, больше зарабатывать, больше тратить, терпеть зонды, строем идти в неизбежное будущее, распевая гимн Единой России", я не настолько адекватный, чтобы принять эту простую стратегию, решающую все проблемы)?

     
  • 2.54, Аноним (54), 14:38, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты гонщик, когда винда начинается свопаться, все висит настолько глухо, что даже диспетчер задач вызывается десяток минут
     
     
  • 3.56, zzz (??), 15:16, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Винда на свопе начинает тупить, в линуксе при свопе даже мышка по экрану не ездит.
     
     
  • 4.60, Аноним (47), 16:20, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да фиг с ней с мышкой, magic-sysrq не работает и виртуальные консоли не переключаются.
     
  • 3.69, Аноне (?), 21:33, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Подождав несколько минут я сделал ребут и... потерял часть функционала KDE
     

  • 1.53, Аноним (54), 14:37, 25/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А нельзя тупо выделиь кусок памяти под ОС, чтобы никакое приложение не могло на него претендовать. Тогда можно будет хотя без проблем бы прибить зажравшееся приложение
     
     
  • 2.55, Аноним (6), 14:51, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    можно выделить, кто ж мешает.

    memory.min в сигруппах (на самом деле это не работает, по крайней мере в моих опытах)

     
  • 2.68, Anonim (??), 20:35, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Интересный вопрос. Кажись как-то можно прибить некоторые вещи гвоздями в памяти, но я так и не вкурил как...
     
  • 2.78, Аноним (50), 05:40, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    vm.min_free_kbytes = 393216
     
     
  • 3.79, кек (?), 07:12, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >vm.min_free_kbytes = 393216

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

     
     
  • 4.80, Аноним (50), 08:34, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>vm.min_free_kbytes = 393216
    > Это катастрофически много, к тому же бессмысленно.

    The problem has gone away completely for me after I bumped vm.min_free_kbytes way up to 393216.

    https://bugzilla.kernel.org/show_bug.cgi?id=196729#c17

    > На компах с малым размером
    > памяти это может вообще положить систему.

    Скажу больше: на калькуляторе вообще не запустится.

     

  • 1.57, Аноним (57), 15:38, 25/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не прошло и 28 лет как в линаксе начали появляться базовые вещи...
     
     
  • 2.59, Аноним (6), 16:05, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Какие, например?
     
  • 2.70, Аноне (?), 21:34, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Во времена Гнома 2 своп работал нормально
     

  • 1.66, Wilem82 (?), 18:40, 25/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Надо для Электрона такой. :)
     
     
  • 2.67, Anonim (??), 20:32, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это чтобы поделия на нем вообще не запускались?
     
  • 2.72, Аноним (72), 23:09, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для Электрона нужен перманентный киллер.
     

  • 1.75, Pistrun (?), 02:29, 26/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    >отправляет через DBus предложение процессам о необходимости умерить аппетиты.

    -SIGCHROME?

     
  • 1.85, Аноним (88), 12:58, 26/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > при превышении порога отправляет через DBus предложение процессам о необходимости умерить аппетиты

    "Окей", -- говорит dbus и падает первым. "Субботник - это когда люди, которые никогда не мусорят, убирает за теми кто никогда не убирает"

    Сам подход порочен. Это сообщение должно или отправляться юзеру, чтоб принял меры, или самостоятельно прибить зажравшееся (для чего уже есть софт типа earlyoom).

     
     
  • 2.89, Аноним (89), 14:36, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем прибивать? Просто заблочить на операции выделения памяти, пока не освободится нужное количество. А пользователь пусть сам выбирает какое из "замороженных" приложений прибить.
     
     
  • 3.92, Аноним (6), 14:47, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >заблочить на операции выделения памяти

    Обычно это приводит к MemoryError и непредсказуемому поведению https://imgur.com/a/p9j67KA

    SIGTERM обычно обрабатывается корректнее, чем ошибка выделения памяти.

     
     
  • 4.93, Аноним (89), 14:57, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если блокировка потока на выделении памяти приводить к непредсказуемому поведению, очевидно приложение написано криво. Логичным выводим из того, что new застопорился, должно быть понимание, что выделить память по какой-то причине не получается.
    В любом случае автоматически прибивать - это самая крайняя мера. Её надо всеми возможными способами избегать.
     
  • 2.91, Аноним (6), 14:44, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >dbus и падает первым

    dbus обычно защищено низким значением oom_score_adj

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

    И то и другое есть в nohang. В earlyoom нет уведомлений о низком уровне памяти.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру