Швейцарские физики выбирают nohang для обработки нехватки памяти

Что-то мне этот nohang не помог, поведение при нехватке ОЗУ прежнее – висяков нет, но отзывчивость снижается.

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

поведение при нехватке ОЗУ прежнее

Совсем-совсем прежнее? Даже не убил никого?

У меня он несколько раз ломался, поэтому переполз на earlyoom.

В чем заключалась поломка, если не секрет? и давно ли это было?

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

Имейте в виду, что с 20.04 он работает намного лучше из-за более нового ядра и поддержки PSI

Но ждать от питоноподелки какой-то особой стабильности я бы не стал..

Совсем-совсем прежнее? Даже не убил никого?

Мог прибить Blender со сценой, отжиравшей 8+ ГБ, но не стал… А, кстати, ему обязательно нужен PSI в ядре? А то я поленился включать.

арчлинукс, nohang-git из aur. Просто как-то заметил, что он прекратил запускаться

Может это было это - https://github.com/hakavlad/nohang/issues/90. Однако проблема была исправлена течение суток и устранена с обновлением. Дело не в питоне, а в быстром развитии. Последняя версия 0.1 и развитие фактически шло по роллинг модели. Много изменений было со времени последнего релиза, бывали и множественные поломки. Однако последние полгода стабильность есть и поддерживается обратная совместимость, релиз 1.0 на подходе.

Мог прибить Blender со сценой, отжиравшей 8+ ГБ, но не стал

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

ему обязательно нужен PSI в ядре?

Вообще-то нет. earlyoom и вовсе не поддерживает PSI, например. Без поддержки PSI демон может реагировать на объемы доступной памяти и свопа. Однако поддержка PSI позволяет реагировать на заморозку десктопа при интенсивном своппинге. Например, без поддержки PSI возможна заморозка при активном своппинге, еасли пространство подкачки большое и расположено на медленном диске. Вам не нужна поддержка PSI, если у вас нет пространства подкачки. Тут пример успешной работы с PSI и заморозки без PSI - https://github.com/hakavlad/nohang/issues/98.

Сдыдоба, 21 век нехватка памяти и еще и чинит это надо, не шучу ни фига.

если у вас нет пространства подкачки

В смысле дисковой подкачки?

Купи уже оперативы, лол, ты прям одержим oom-шизой.

В смысле дисковой подкачки?

Пространства подкачки на любом устройстве - HDD, SSD, zram. Метрики PSI не мониторятся, если SwapTotal=0. При этом ответ возможен только на нехватку MemAvailable.

Купи уже оперативы, лол, ты прям одержим oom-шизой.

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

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

То есть, ядро не делает различий между обычным свапом и zram`oм?

SwapFree и SwapTotal в /proc/meminfo существуют вне зависимости от типа свопа. Киллеры реагируют на цифры в meminfo, тип свопа не имеет значения.

Понял, спасибо за объяснение.

/proc/meminfo это текстовый файл. По крайней мере, его можно читать cat`oм. Киллеры парсят текстовый файл, или есть какие-то системные вызовы для того, чтобы узнать эти значения?

Но ждать от питоноподелки какой-то особой стабильности я бы не стал..

ИМХО Python для обработчика оом это халтура, должен быть исключительно компилируемый язык с статичным выделением памяти, чтобы не прийти в тупик при её нехватке и обязательном запрете её сброса в своп.

Python для обработчика оом это халтура

Всё так. Однако я и не программист. Написание качественных программ на компилируемых языках мне неведомо. И да, к вашим услугам обработчики, написанные на компилируемых языках: earlyoom (C), oomd (C++), low-memory-monitor (C). Однако: earlyoom не поддерживает PSI, oomd убивает процессы только группами и не помогает без пространства подкачки и сильно грузит ЦПУ, low-monory-monitor вообще опасен и убивает агрессивно и преждевременно: https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/issues/10. nohang - лучшее решение для десктопа: конфигурабелен, аккуратен, поддерживает PSI, достаточно энергоэкономен, поддерживает опционально GUI уведомления. Python позволил написать гибкое эффективное решение.

чтобы не прийти в тупик при её нехватке и обязательном запрете её сброса в своп

mlockall() в nohang выполняется и отлично работает.

бамп годному треду

Что так прижало с этим оом киллером ? Предполагаю что более менее проблемы с памятью решены в дистрибутиве о котором нельзя писать в силу того что элитка забанит по mistake ведь она как не приемлет ничего кроме своих корявых дистрибутивов в которых эта проблема не решаема по тому что красиво писать и создавать сим линки это две логически разные вещи.

григоорий залогинься

Однако я и не программист. Написание качественных программ … мне неведомо

не расстраивайся, программистам тоже неведомо

Работаю швейцарским физиком. В Цюрихе у нас ни о каком nohang не слышно. Статья обман