После трёх месяцев разработки опубликован выпуск фонового процесса earlyoom 1.2 (https://github.com/rfjakob/earlyoom), который периодически проверяет объем доступной памяти (MemAvailable, SwapFree) и пытается на ранней стадии отреагировать на возникновения нехватки памяти.
Если объём доступной памяти меньше заданного значения, то earlyoom принудительно (через отправку SIGTERM или SIGKILL) завершит работу процесса, наиболее активно потребляющего память (имеющего самое большое значение /proc/*/oom_score), не доводя состояние системы до очистки системных буферов и мешающего работе своппинга (обработчик OOM (Out Of Memory) в ядре срабатывает когда состояние нехватки памяти уже достигло критичных значений и обычно к этому моменту система уже не реагирует на действия пользователя).
Earlyoom поддерживает отправку уведомлений о принудительно завершённых процессах на рабочий стол (с помощью notify-send), а также предоставляет возможность определения правил, в которых при помощи регулярных выражений можно задать имена процессов, завершение которых предпочтительно (опция "--prefer") или остановки которых стоит избегать (опция "--avoid").
Основные изменения в новом выпуске:
- Внедрено адаптивное время сна (адаптивная частота проверки уровня доступной памяти) для снижения нагрузки на процессор: чем меньше доступной памяти осталось, тем чаще проверяется объем доступной памяти (один раз в секунду если памяти достаточно и чаще по мере ее уменьшения);
- Удалена опция "-k" для вызова ядерного oom-killer'a (ее использование давало непредсказуемые результаты; теперь эта опция игнорируется для совместимости);
- Исправлена ошибка, приводящая к некорректному поведению после монтирования своп-раздела, если earlyoom уже был запущен;
- Реализовано ступенчатое завершение процессов: сначала происходит попытка корректного завершения процесса путем отправки ему сигнала SIGTERM, и только в случае отсутствия реакции на SIGTERM и при дальнейшем уменьшении доступной памяти происходит отправка SIGKILL процессу с наибольшим oom_score.URL: https://github.com/rfjakob/earlyoom#changelog
Новость: https://www.opennet.ru/opennews/art.shtml?num=49556
Я был доволен своей манжарой пока не запустил игрушку при 8 Гб рам и отсутствием свопа...
Думал в 2018м подобные демоны скончания оперативки щитаются стандартом в дистрибутивах, оказалось нет...
Думал kernel panic в прошлом...
А при чем тут kernel panic? С точки зрения ядра - все так и должно быть, только пользователь недоволен. У меня на нетбуке тоже Манджаро, 4 Гб памяти и нет свопа. Аналогично, все вешалось иногда, приходил OOM-killer и вешался за компанию.. Решалось через sysrq и ребут, но очень бесило. Earlyoom избавил от этого, причем на грани фантастики - хром с 20 вкладками в фоне, спереди игрушка под wine, файл-менеджер и торрент-клиент тоже где-то болтаются и все нормально. Я, правда, с той поры, немного поумнел - логинюсь через tty, красивости и ненужные сервисы\модули ядра - под нож, /tmp из оперативки на диск (+ccache) и вагон с тележкой других твиков.
Так что за то, что она вешалась - я даже благодарен, так много интересного о системе никогда не узнаешь, если тупо ждать программу с кнопкой "сделать за..шибись".
>А при чем тут kernel panic?У меня ядро 2.6.10 любило вешаться при переполнении оперативки без свапа, на прощание сообщая о kernel panic.
>Так что за то, что она вешалась - я даже благодарен, так много интересного о системе никогда не узнаешь, если тупо ждать программу с кнопкой "сделать за..шибись".Безопасный обновлятор огнепанды написал, управлялку кулерами написал, скрипт бекапа с SSD на HDD написал, теперь ещо и убивалку процесов писать на шел? xD
Думал ограничусь модом мобилки, теперь приходится мод десктопа поневоле делать...
Ужас, у меня 1.5 Гб и без свопа на WinXP ни одного раза не зависала ОС - только приложение вылетает или виснет при нехватке памяти. А тут такое, для дома не годится, это либо подход такой "серверный" либо просто позорище этот линукс
я вам страшную тайну открою -- у xp не бывает "без свопа". Даже если вручную все поотключать, она с горя создаст временный, где-то в windows\system32 или рядом.Но у нее нет overcommit, и proactive свопа тоже нет.
А я вот сейчас наблюдаю такой себе mysqld, отожравший в свопе 3 гига из четырех возможных и пытаюсь понять - убить его, от греха, или пусть так как-нибудь выживает (это именно proactive swap - то есть система решила что даже буферный кэш полезнее этих байтиков)
Ну тогда надо продолжить и сказать, что у любой Windows не бывает без свопа, даже если его отключить.
Не смешите мои подковы.
Запуск десятка приложений повесил одну ХП почти в 0 на моих глазах. курсор кажется двигался, но нельзя было даже нажать на заранее запущенный диспетчер задач, что показывал занятость 100% озу
> –3 +/–О, а вот и подоконники-некрофилы.
> 4 Гб памяти и нет свопаА нормальный купить не судьба, хотя бы с 16 гб? Или нищ и свободен?
> А нормальный купить не судьбаключевое слово, которое нище6poд ниасилил прочитать и понять (и это ты, а не предыдущий анон) - "нетбук". У тебя его никогда не было, иначе бы ты не писал глупости.
Нормальный - это который валяется в рюкзаке-косметичке не потому что нужен, а потому что "а вдруг пригодится, и вообще, зачем вынимать". Что накладывает определенные требования на размер, вес и дубовость конструкции (чтобы оно не сдохло через пол-годика такого таскания). Китайцы, закрывшие эту нишу полностью, к сожалению, не любят "инноваций" и еще десять лет собираются копировать одну-единственную удавшуюся им модель (потому что решительно неспособны создать сами ничего что купят белорожие небратья) - а это 4/32/отстегивающаяся клавиатура.
а mac air вполне может быть и не судьба - его жалко, он убьется (китаец убьется - "несите следующего, $250"), мы ж про нетбук для дела, а не для правильного сочетания с беленой бороденкой и штанишками с подворотиками, который носят до совокинга и обратно, нежно стряхивая пылинки. К тому же на mac air нет проблемы с oom ;-)
>ниасилил прочитать и понять (и это ты, а не предыдущий анон) - "нетбук".Вот именно, что осилил. У тёщи нетбук с 16гигами (делл, вроде) под офисные задачи (хром, мсофис, 1с, скайп, вотсапп, слак) и ей не хватает - забивает и свопит.
А тут человек жалуется при 4 гигах - детсад же.>Нормальный - это который валяется в рюкзаке-косметичке
Вот именно. В дамской сумочке. Пришла в офис, подключила монитор, клавомышь, работает. Приехала домой - нахреначила отчет лежа в кроватке.
Уши так что нехрен судить о людях
> Вот именно, что осилил.не осилил.
> У тёщи нетбук с 16гигами (делл, вроде)a) "у тещи"
b) dell netbook - ноль результатов, может быть вы искали dell laptop.
не производит делл классических нетбуков, похоже.> Вот именно. В дамской сумочке. Пришла в офис, подключила монитор, клавомышь, работает.
дружище, это называется не нетбук, а хреновый ноут.
Подари теще съемный жесткий диск и научи с него загружаться - чтоб ей не таскать эту тяжесть туда-сюда. Нетбуки предназначены совсем-совсем не для этого.мониторы к ним, доложу тебе, вообще подключают только для презентаций- потому что ад и израиль менять привычки на ходу два раза в день, и не нужно ни для чего.
И еще.>мониторы к ним, доложу тебе, вообще подключают только для презентаций- потому что ад и израиль
Линуксопроблемы. В десяточке подключил и работаешь.
>>мониторы к ним, доложу тебе, вообще подключают только для презентаций- потому что ад и израиль
> Линуксопроблемы. В десяточке подключил и работаешь.нет, именно десяточкопроблемы (в линуксе нет нормального интерфейса - нет проблем). Думай дальше - но для начала попроси все же у кого-то из знакомых нетбук, обозначенный именно как таковой, и попробуй денек поработать - быстро поймешь, почему.
> Вот именно, что осилил. У тёщи нетбук с 16гигами (делл, вроде)
> под офисные задачи (хром, мсофис, 1с, скайп, вотсапп, слак)
> и ей не хватает - забивает и свопит.
> А тут человек жалуется при 4 гигах - детсад же.Аноним, ты -аноним, какой смысл начёсывать себе ЧСВ, если ты аноним?
А по факту вижу что ты тупа пиз...шь и никогда в жизни не видел Linux на 16Гб.
Я тут обвешан всем чем можно: браузеры, мессенджеры, Vuze на жаве, тандырбёрты, офисы,
в фоне MySQL, апач, впн, тор, самба, мелочь всяка, ядро собирается в 64 потока,...
из 16 гигов ещё 3.2 свободны.
> Я тут обвешан всем чем можно: браузеры, мессенджеры, Vuze на жаве, тандырбёрты,
> офисы,
> в фоне MySQL, апач, впн, тор, самба, мелочь всяка, ядро собирается в
> 64 потока,...
> из 16 гигов ещё 3.2 свободны.И таки без свопа или с? А если ещё сто вкладок в хроме открыть? ;)
>> Я тут обвешан всем чем можно: браузеры, мессенджеры, Vuze на жаве, тандырбёрты,
>> офисы,
>> в фоне MySQL, апач, впн, тор, самба, мелочь всяка, ядро собирается в
>> 64 потока,...
>> из 16 гигов ещё 3.2 свободны.
> И таки без свопа или с? А если ещё сто вкладок в
> хроме открыть? ;)Какие вкладки, детская нагрузка. По 64 потока gcc+cpp+as это вам не в офисе кнопки давить.
> Решалось через sysrq и ребутЗачем ребут, если достаточно SysRq?
>> Решалось через sysrq и ребут
> Зачем ребут, если достаточно SysRq?Пиши фамилию, работу, должность, чтоб не попался при деле.
>был доволен своей манжарой пока не запустил игрушку при 8 Гб рамНужен не OOM, а демон, который при запуске проверяет количество оперативы, и если оно меньше 8гб открывает хедхантер и ищет вакансии. Ну не может быть столько оперативы у приличных людей.
>Нужен не OOM, а демон, который при запуске проверяет количество оперативы, и если оно меньше 8гбПредлагаеш хром установить?
>>Нужен не OOM, а демон, который при запуске проверяет количество оперативы, и если оно меньше 8гб
> Предлагаеш хром установить?хедхантер не откроется ;-)
Почему этот демон не включен из коробки в большинстве популярных дистров? Потребляет практически ноль ресурсов, при этом надежно предохраняет от OOM.
Этот демон на большинстве систем и не нужен. На нормальном сервере есть мониторинг, и разумный сисадмин узнает о проблемах и сможет их решить, а, главное, узнать причину. На десктопе когда курсор мышки перестанет ездить и лампочка HDD будет непрерывно гореть тоже все станет ясно без лишнего демона.Такой демон (отжирающий CPU и память) нужен на системе, где срабатывания полноценного OOM ждать не хочется и у самого пользователя не хватает квалификации отреагировать, когда активный swap только начался или когда пользователь мамкин хацкер, сконфигурировал систему вообще без swap и не понимает, что учудил.
>Такой демон (отжирающий CPU и память)У меня на htop он показывает 0% CPU и 0% нагрузки на память.
Потому что большинству пользователей это не нужно.
Если какой-то процесс потребляет больше всего памяти - это еще не повод убивать именно его. Возможно, пользователю именно этот процесс в данный момент и нужен, а убить лучше что-то менее нужное... По крайней мере у меня именно такой сценарий. Но тут уже никакая утилита не поможет.
Посути он и есть ООМ ))
> Почему этот демон не включен из коробкиПотому что безрукие удаки должны страдать.
этот демон устанавливается с браузером хром
Господа, да это же костыль.Нормальная production-ready система ОБЯЗАНА на такое штатно реагировать, как и, например, на исчерпание места на диске. Костыли НОРМАЛЬНОЙ ОС для такого не должны быть необходимы.
Пожалуйста, перестаньте считать костыли чем-то плохим. При отсутствии ног костыли - это благо. Костыли - это вариант решения проблемы.
Ну так она и реагирует, даже механизмы есть чтобы ей объяснить что надо прибить в первую очередь, а что не нужно трогать.
А то что ты можешь еще ты можешь кроме изкоробочного варианты два других поставить, ну так хорошо же.
Чо в проблемах ядра винят всю ОСь?
В твоём понимании костыль -- это то, что не включено в систему штатно? Ну дак включи этот демон в систему штатно, и он перестанет быть костылём.
> Господа, да это же костыль.ну да, линукс без них практически бесполезен
А есть такая штука, чтобы убивала (лучше как-нибудь замораживала) процесс приводящий к неотзывчивости системы в течении определенного времени? А то бывает так: что-то начинает быстро сжирать память, и, когда дело доходит до свопа, система впадает в ступор, а ждать пока своп заполнится и сработает oom killer можно еще очень долго.К слову, нормальная ОС должна обеспечивать реакцию на интерактивные команды пользователя (будь-то локальный или удаленный текстовый терминал или нажатия мышкой в GUI) с максимальным приоритетом, быстро независимо от всей остальной загрузки и использования ресурсов остальным процессами, потому что пользователь всегда главнее всех процессов.
>(лучше как-нибудь замораживала) процесс приводящий к неотзывчивости системы в течении определенного времени?пока такого нет, но теоретически можно сделать через SIGSTOP/SIGCONT
>пользователь всегда главнее всех процессов
Потомки исков имеют обычный приоритет. Это ж серверная ось в основном.
> К слову, нормальная ОС должна обеспечивать реакцию на интерактивные команды пользователя
> (будь-то локальный или удаленный текстовый терминал или нажатия мышкой в GUI)
> с максимальным приоритетом, быстро независимо от всей остальной загрузки и использованияsysctl kern.sched.interact=10 # default is 30
sysctl kern.sched.preempt_thresh=224
В итоге, даже при полной загрузке (запустив к обычному фону еще и 6 x 'python -c "while True:pass"' на двух ядрах) переключение между раб. столами, браузерами/claws проходит практически без ощутимых запинок.> ресурсов остальным процессами, потому что пользователь всегда главнее всех процессов.
Сильно зависит от сценария использования. Банальный пример: подсоединение к панели управления маршрутизатором не должно приводить к лагам или тем более обрывам голосовых соединения (IP телефон или всякие вайберы и вотсапы, не суть важно).
это же для фряхи)) а для линукса есть подобное?)
> В итоге, даже при полной загрузке (запустив к обычному фону еще и 6 x 'python -c "while True:pass"' на двух ядрах) переключение между раб. столами, браузерами/claws проходит практически без ощутимых запинокЭто что за трэшак такой, что требует напильника для того, чтобы переключение окон и рабстолов не дёргалось при нагруженном процессоре? Там что, отрисовки интерфейса на gpu до сих пор нет?
> Это что за трэшак такой, что требует напильника для того, чтобы переключение
> окон и рабстолов не дёргалось при нагруженном процессоре?О, началось развешивание лапши на уши и описание солено-пряного вкуса апельсинов.
> Там что, отрисовки интерфейса на gpu до сих пор нет?
Далеко не все в гтк/qt рисуется gpu.
> началось развешивание лапши на ушиОга, когда человек всю жизнь живёт в глухой деревне, он тоже не верит, что на свете бывают чистые мощёные тротуары вместо грязи с навозом XD
> Далеко не все в гтк/qt рисуется gpu
Что, например, в Plasma рисуется не на gpu?
>> началось развешивание лапши на уши
> Ога, когда человек всю жизнь живёт в глухой деревне, он тоже не верит, что на свете бывают чистые мощёные тротуары вместо грязи с навозом XDДа-да, все кого гордый житель Новых Васюков встретил вне своего "мегаполиса" автоматически проживают в глухих деревнях и никогда не видели вживую этих ваших бубунт или окошек с маками. Да и 12309 на самом деле миф.
О, ещё и 12309 приплёл. Всё ясно)
> О, ещё и 12309 приплёл. Всё ясно)То ли дело упомянуть "деревню, грязь и навоз", да?
> отрисовки интерфейса на gpu до сих пор нет?Открою страшную тайну тебе и всем другим фанатам "интерфейса на GPU" -- без команд от центрального процессора видеокарта ничего рисовать не будет. И если перегруженный CPU не успевает с достаточной скоростью обновлять, например, координаты перетаскиваемого окна, то никакой GPU не спасёт от дёрганий и прочих тормозов.
>> отрисовки интерфейса на gpu до сих пор нет?
> Открою страшную тайну тебе и всем другим фанатам "интерфейса на GPU"Я бы еще открыл им страшную тайну регулярного использования реальных дебина/бубунты на реальном, сравнимом (или более лучшем) железе и похожих сценариях.
Да и приколы окошек при полной загрузке тоже наблюдаются регулярно, там пользователи иногда могут и софт-ресет сделать, потому что быстрее выйдет бутнутся заново, чем ждать пять минут, пока оно рассвопится до запуска таскменеджера и еще пять минут до реакции в этом самом менеджере.
Но не всегда тот пользователь, что прокладка между стулом и монитором
> завершит работу процесса, наиболее активно потребляющего памятьА вот это не очень хорошо. Как минимум надо иметь возможность выбора из нескольких сценариев.
Ну вот НАПРИМЕР у меня типичная связка nginx->php-fpm->mysql. Все эти процессы жрут плюс минус одинаково, однако php-fpm запускает свои потоки с разными PID'ами, а mysqld один.
Подключатся десять посетителей к Вордпрессу или Джумле на таком сервере, и получится что у нас 10 разных php-fpm по 100Мб каждый, и один mysqld на 1024Мб, который будет первым на вылет, и периодически киляется OOM'ом после чего привет, 500-я и сайт(ы) в ауте.Но это же никуа не логично! Логичнее прибить пять php-fpm'ов, после чего 500Мб освободят они, и еще 500 освободит mysqld.
Всё настраивается. Как на уровне ядра (google://oom_score_adj), так и на уровне данного демона (новость://опция "--avoid").
У вас странное представление о том, как организовывать стабильность сайта. Во-первых, не надо использовать пхп. Во-вторых, нужно сначала посчитать кто сколько жрёт, потом посчитать сколько потянет ваше железо, а потом ограничить кол-во одновременных запросов - как раз что бы память не кончалась. А вы вместо этого пускаете на вход любое колво запросов, а когда это всё взрывается убиваете процессы? Это безумие.
Одно другому не мешает. Во время доработок в коде может появиться утечка памяти. Да и в обычном режиме разные страницы жрут разное кол-во памяти - предлагаете ограничиться одним одновременным запросом из-за одной редко-используемой страницы?
> Одно другому не мешает.мешает - культивирует девляпсов-недоучек, которые неспособны прочитать документацию, но думают что умеют что-то настраивать. И таких же "разработчиков"-кодошлепов, чего программу-то отлаживать, она память сожрет и сама упадет.
А потом плачутся, что искусственный интеллект не тот процесс им убил, когда уже вся система пошла в разнос.> Во время доработок в коде может появиться утечка памяти.
тесты ниасилили, доработки выполняем прямо на проде? Лимит памяти php-fpm настроить - тоже не умеем (в том числе, вот удивительно-то, его можно оверрайдить, можно вообще держать несколько по разному настроенных пулов для тяжелых но редких процессов и мелких но с большим числом запросов)
впрочем, это все - средства защиты от ошибок разработчика, а не панацея от исчерпания памяти.
если памяти не хватает - ее таки просто не хватает, пользователю вообще-то все равно, получил он 504 сразу же при входе или при попытке выполнить сложную операцию (а данные формы мы отправляем аяксом и пусть все сто полей заново заполнит). И надо добавлять память, банально.
> тесты ниасилили, доработки выполняем прямо на проде?Ни разу не видел утечек памяти в стабильных ветках программ? Серьёзно? У меня и в ядре была утечка одно время... В стабильной ветке, на стабильном дистре...
P.S.: комментировать остальные потоки незамутнённого сознания нет никакого желания
> Ни разу не видел утечек памяти в стабильных ветках программ?начинаем вилять ужом и фигурно цитировать?
я комментировал это:
> Во время доработок в коде может появиться утечка памяти.это вот - прекрасно ловится тестовой средой.
и да, напоминаю, речь шла о php и вебе - то есть то место, где "долгоиграющих", по капле, утечек не бывает. потому что время жизни процесса ограничено и можно ограничить его еще и сверх того.
> P.S.: комментировать остальные потоки незамутнённого сознания нет никакого желания
в зеркальце, кума, посмотри.
>> Во время доработок в коде может появиться утечка памяти.
> это вот - прекрасно ловится тестовой средой.Так может сказать только зелёный теоретик. Если бы оно всегда всё было так просто, то и проблемы этой не существовало бы глобально.
> и да, напоминаю, речь шла о php и вебе - то есть то место, где "долгоиграющих", по капле, утечек не бывает. потому что время жизни процесса ограничено и можно ограничить его еще и сверх того.
И снова теория. В жизни-то оно по всякому бывает. Гугли что такое нода, реактпхп и fastcgi_finish_request. Хотя и в других случаях бывают нужны долгоиграющие процессы.
P.S.: Надоело спорить с воинствующей безграмотностью.
Скачал, скомпилировал, установил, запустил сервис (сервис запустился), запускаю membomb, который идёт в комплекте, по-видимому, для целей тестирования - наглухо вешается система, никто никого не прибивает. Ubuntu 18.04 x64, 8Gb, HDD, своп включен, настройки earlyoom по умолчанию. ЧЯДНТ?
-s 100,100 или отключение свопа вовсе помогает. В общем, нужно тюнить под свою конфигурацию, похоже.
Похоже, там "и", а не "или". Даже с отключенным свопом без " -s 100,100 " не работает.
>наглухо вешается системаОна вешается вследствие процесса наполнения свопа, а не из-за OOM. По умолчанию сигкилл происходит козда остается 10% свопа свободно.
И да, пользуйтесь zram и не используйтете своп на HDD.
Не понял, а зачем всё это нужно? Своп никто в наше время уже не включает, а ограничить память процессу можно через cgroups, не?
> Своп никто в наше время уже не включаетНаглая ложь. Я включаю.
> Не понял, а зачем всё это нужно? Своп никто в наше время уже не включает, ...Заурядный не умеющий читать аноним опеннета. Речь не о свопе, а об ООМ. Отключением свопа ты не решишь проблемы ООМ. Даже наоборот приблизишь, ибо виртуальной памяти будет меньше.
> ... а ограничить память процессу можно через cgroups, не?
А можно просто прибивать те, кто сжирает слишком много, причём прибивать их только тогда, когда такое поведение приводит к проблемам.
> Заурядный не умеющий читать аноним опеннета.они не читать не умеют, им просто эти слова непонятны.
победители свопа, мнящие себя админами :-(> А можно просто прибивать те, кто сжирает слишком много, причём прибивать их только тогда,
> когда такое поведение приводит к проблемам.swap trashing это таки проблема - но такой ИИ еще не изобрели.
Успел набрать kill - молодец, не успел - press reset twice for bbs.
> Заурядный не умеющий читать аноним опеннета.Опять началось массовое осеннеe обострение ЧСВ на опеннете.
>> Заурядный не умеющий читать аноним опеннета.
> Опять началось массовое осеннеe обострение ЧСВ на опеннете.Наблюдение за не умеющими читать анонимами опеннета провоцирует. Хочешь не хочешь, а сравниваешь себя с ними.
limits.conf уже не рулит или чо?
> limits.conf уже не рулит или чо?Если бы рулил лимитс.конф, то вот эта дискуссия
https://www.reddit.com/r/linux/comments/56r4xj/why_are_low_m.../
на 480+ постов не возникла бы.
> limits.conf уже не рулит или чо?лет двадцать уже не.
С ядра 1.2, по-моему.
У кого есть лишние деньги, могут решать эту проблему способом «купить ещё памяти, нынче она дешёвая» (как здешние богатые анонимы), остальные обречены страдать.
ну вообще-то способов решить проблему нехватки памяти кроме как купить еще памяти, наука не знает в приниципе.
Проблемы неадекватного поведения системы, когда памяти не хватило конкретному процессу/процессам - это совершенно отдельная история. Они по разному, но одинаково уныло выглядят и в винде, и в фре, и в линуксе. (то есть проявляются в разных местах, и имеют разное проявление - так что иногда смена системы помогает вернуть контроль над ситуацией. Но вариант "перезагрузки ресетом", увы, никуда не девается во всех трех. За солярку вот не скажу, не напарывался.)
> ну вообще-то способов решить проблему нехватки памяти кроме как купить еще памяти,
> наука не знает в приниципе.Кроме «покупки ещё памяти» наука знает и другие средства, позволявшие с большой пользой для человечества работать ещё на килобайтах памяти. Но эти средства ныне малопопулярны, поскольку план по г-нокоду всегда горит.
> Проблемы неадекватного поведения системы, когда памяти не хватило конкретному процессу/процессам
> - это совершенно отдельная история. Они по разному, но одинаково уныло
> выглядят и в винде, и в фре, и в линуксе. (то
> есть проявляются в разных местах, и имеют разное проявление - так
> что иногда смена системы помогает вернуть контроль над ситуацией. Но вариант
> "перезагрузки ресетом", увы, никуда не девается во всех трех. За солярку
> вот не скажу, не напарывался.)Эти проблемы не из глубин космоса прилетают, а заг-нокожены конкретными людьми, «чего-то недопонявшими» в курсе про архитектуры операционных систем и при изучении языков программирования, или просто им некогда было сделать хорошо и правильно.
Особенно вот умиляют компромиссы в этой прекрасной теме. Например, MS сперва для NT сделала всё правильно, отделив GUI от ядра, но затем начальники кнутами начали подгонять рабов делать побыстрее, потому что, видите ли, «план горит». А если бы годика два-три обождали с выходом на рынок, то и GUI сразу бы красивый к системе прицепили, и поддержку файловых систем получше сделали, и в нужных местах оптимизировали (без кавычек), и железо бы подтянулось как раз к аппаратным хотелкам NT. Не пришлось бы потом четверть века играть в перегонялки с багами и кульхацкерами. Не пришлось бы героически бороться за разную совместимость, про которую не подумали загодя. Глядишь и POSIX внутре бы пригодился. А может даже и на нескольких архитектурах расцвёл бы этот цветок, как и задумывалось, а не одной сиротке x86.
В ИТ всегда побеждает самое худшее решение из имеющихся, да. «План горит».
zswap или zram может отчасти решить проблему
Программа амулет или оберег.
Лол, неужели до кого-то дошло! -__- Хотя хлопанье самого жирного не всегда может быть правильным, по-моему нужно добавить ещё список, которые юзверь разрешает хлопать первыми. Писал такую прогу, когда ещё не докупил памяти в бук и было 4 гига - она киляла именно хром. Т.к. комп подвисал всегда когда открывал много вкладок в хроме. А потом уже система изредка оттормаживалась и не мог отправить вкладки в OneTab.
>добавить ещё список, которые юзверь разрешает хлопать первымиЕсть опция --prefer, можно произвольный regex задать для имён процессов
> она киляла именно хром…, потом удаляла хромой пакет и вызывала специально обученных людей для выдачи живительных люлей недоюзверю, юзающему ЭТО вместо браузера.
> завершит работу процесса, наиболее активно потребляющего памятьОхренеть политика... Убивается активно работающее приложение, которое после скоропостижной кончины оставит на диске хз что. Почему-то винда ещё в давние лохматые годы просто уведомляла юзера "чувак, я тебе свопа добавила", и можно было работать. А эти гении программирования в 2018 году изощряются в способах проактивного убийства процессов.
> Почему-то винда ещё в давние лохматые годы просто уведомляла юзера "чувак, я тебе свопа
> добавила", и можно было работать.потому что в тех случаях, когда там "можно было работать", в линуксе своп даже не начинался.
В виду разной модели выделения памяти. И да, тогда это считали достижением.А когда по ctrl-alt-del пол-часа десктоп построчно перерисовывается на пустое место, а process manager так и не всплывает (или нельзя даже переключиться на уже открытый) - результат был в общем примерно тот же что у линуксов - семь бед, один ресет.
>Охренеть политика... Убивается активно работающее приложениеНе убивается, а корректно завершается через SIGTERM
А чем вот это "свопа добавило" полезно в современных реалиях? Программисты привыкли работать с памятью так, будто её анлим, и возможность своппинга фактически игнорируют. В итоге при своппинге на HDD всё тупит так, что его в любом случае приходится отключать, а своп на SSD как-то нелеп ввиду ограниченности циклов ячеек.А вот убийство самого жрущего процесса как раз сравнительно безопасно: в серверном софте и память обычно не течет - всё вылизано, и спонтанное убийство он нормально переживает, а уж, тем более, по SIGTERM. Браузер восстановит сессию, ничего страшного. А проблемы самописного софта, в котором течет память - это проблемы его разработчиков.
Может, конечно, неловко получиться, когда условный фотошоп в вайне ест 3 гига из 4, и тут, внезапно, браузер съедает оставшийся гиг, но киляется как раз фотошоп. Но всякий такой софт просто добавляется в --avoid.
Ну и да, учитывая, что альтернатива - перезагрузка по трём кнопкам, даже убийство фотошопа в такой ситуации не фатально. Да и он, кажется, в актуальных версиях умеет восстанавливаться после спонтанного вылета.
> Программисты привыкли работать с памятью так, будто её анлимРозгами за это надо пороть. Так, чтобы неделю сесть за клавиатуру не могли.
а что по-твоему современный программист может сделать?
"проверять malloc на null"? Так это показатель некомпетентности.Можно еще вручную померять доступную память - так делали ранние версии videolan x264 - к сожалению, они не умели отличать реальную от свопа, с интересным результатом ;-)
то есть считать память неограниченной - единственно возможное решение. Другое дело, что при этом надо заботиться о ее не расходовании впустую, а вот это для индусско-подданных сложно, и вовсе не потому, что они не понимают разницы между "неограниченно" и "можно жрать как не в себя". Просто они макаки.
эмммм. мы 50+ лет развиваем IT, но до сих пор не можем сделать так, чтобы программа знала, сколько физически памяти в машине, на которой она работает?нда, абстракции абстракций абстракций это круто, конечно. с таким подходом только со всякими костылями типа earlyoom и можно жить.
> эмммм. мы 50+ лет развиваем IT, но до сих пор не можем сделать так, чтобы программа знала,
> сколько физически памяти в машине, на которой она работает?эмм... мы вообще-то 40 из этих пятидесяти разрабатывали концепцию "виртуальной памяти", чтобы программы перестали биться об ограничение физической памяти и избавились от необходимости этого ненужного знания, с которым, кстати, не всегда и понятно, что делать.
нет. в позикс-стандартах (даже, наверное, самых наираспоследних, в которые понапихана масса всякого бреда), во всяком случае, такого не было предусмотрено.
К тому же память бывает разная - вон там товарисч, считающий себя очень умным, продемонстрировал некий код для некоей bsd. Но вряд ли он вам сможет объяснить, какую именно память пытается получить этот код. И что, кстати, нужно делать, если ее нет.
Применительно к той же freebsd: у нас есть 1. inactive 2. wired 3. Buf который есть часть этого wired и 4. еще у нас есть zfs arc - и вот какую часть из этого зоопарка вы считаете "свободной", и с какого, собственно, бодуна именно ее?
А теперь добавим к ним еще zfs abd, захваченные но незанятые сетевым стеком mbufs (на 10G там могут лежать _гигабайты_ памяти - которая в данный момент никак не используется) и кучу всякой другой хрени, о которой я просто не имею несчастья знать, которую и посмотреть-то толком хрен его знает, как.И как тут определять, что есть свободная память в принципе, и чего дальше-то делать с этим знанием?
Изумительной концепции виртуальной памяти, отучившей программистов думать, и надо говорить спасибо за все тормоза, не объясняющиеся запланированным устареванием, если на то пошло.А как торрент-клиенты определяют скорость соединения и ограничивает скачивание при забитом канале, чтоб другим не мешать? Даже никаких специальных API на уровне ОС не понадобилось.
Так и здесь никто не мешает сделать: выделение памяти идёт дольше обычного? Память забита, пошла фрагментация, хватит жрать память. Обращение к выделенной памяти даёт заметную тупку? Мы загремели в своп, и снова хватит жрать память. На каждое обращение к памяти такие проверки - долго? Да можно и не на каждое, отдельная проверялка отзывчивости памяти в отдельном потоке раз в N ms.
Нет возможности перестать жрать? Сохраняем состояние на винт и завершаем работу корректно.
Но нет, пусть будет виртуальная память и своп в случайное время с непредсказуемым для пользователя поведением. Программистам же так проще, думать меньше надо.
Всё правильно, анон. Действия по упрощению жизни программистов приводят, как правило, к ухудшению получаемой от них готовой продукции.
> а что по-твоему современный программист может сделать?
> "проверять malloc на null"? Так это показатель некомпетентности.О, опять пошли байки о вездесущности overcommit и "современный malloc никогда не возвратит 0"?
# rctl -h
user:restricted:vmemoryuse:deny=1024M/process
user:restricted:memoryuse:deny=512M/process
user:restricted:swapuse:deny=1024M
% uname -rs;whoami && cat test.c && ./test|tail
FreeBSD 11.2-STABLE
restricted
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>#define MB (1024*1024)
#define PSIZE 4096
int main(void){
size_t sum = 0;
char *ptr;
for (size_t i=0;;i++) {
if ((ptr = malloc(MB)) == NULL) {
perror("Err:");
exit(EXIT_FAILURE);
}
for (size_t j = 0;j < (MB-PSIZE-1); j += PSIZE) ptr[j] = 0;
sum += MB;
printf("allocated: %zu MB\n", sum/MB);
}
return EXIT_SUCCESS;
}
allocated: 497 MB
allocated: 498 MB
allocated: 499 MB
allocated: 500 MB
allocated: 501 MB
allocated: 502 MB
allocated: 503 MB
allocated: 504 MB
allocated: 505 MB
allocated: 506 MB
Err:: Cannot allocate memory
>> а что по-твоему современный программист может сделать?
>> "проверять malloc на null"? Так это показатель некомпетентности.
> О, опять пошли байки о вездесущности overcommit и "современный malloc никогда не
> возвратит 0"?окей, он может вернуть ноль, но только потому что косоручка, мнящий себя админом, решил что лучше автора программы и системы знает, сколько ей надо памяти. Ну так пусть сам и проверяет, нечего терять производительность - у нормальных людей эти проверки даром будут жрать cpu.
> # rctl -h
rctl: RACCT/RCTL support not present in kernel; see rctl(8) for details
то есть ты сам себе разложил отдельное от проблемы оверкомита поле уникальных грабель, и все-все разработчики под тебя, талантище, должны подстраиваться?
rctl предназначен для совершенно другой ситуации - когда на машине заведомый oversubscription, но на проблемы что чему-то не хватит памяти, админу наплевать (читай, массовый шитхостинг), пока это что-то не его, и можно ее урезать всем гораздо ниже физических лимитов.
> Ну так пусть сам и проверяет, нечего терять производительность
> - у нормальных людей эти проверки даром будут жрать cpu.Ну да, лучше пусть словит sigsegv при обращении, потому что третье приложение на электроне за это время выжрало всю оставшуюся память.
Зато целый jnz short после жирного вызова malloc сэкономили. Профит, че.
> rctl: RACCT/RCTL support not present in kernel; see rctl(8) for details
> то есть ты сам себе разложил отдельное от проблемы оверкомита поле уникальных грабель, и все-все разработчики под тебя, талантище, должны подстраиваться?Сам придумал, сам оспорил. Удобно, да.
Лады, контейнеры не нужны! Жили без этого тысячи лет, значит и дальше проживем!> rctl предназначен для совершенно другой ситуации - когда на машине заведомый oversubscription,
> но на проблемы что чему-то не хватит памяти, админу наплевать (читай,
> массовый шитхостинг), пока это что-то не его, и можно ее урезать всем гораздо ниже физических лимитов.Оversubscription будет на любой не самой новой машине с ОЗУ < 9000гигз, особенно мобильной, если запустить кроме браузера еще что-то жручее. Ну или просто долго не закрывать браузер.
А, да, я ж забыл, что у кое-кого на десктопе десяточка. Прошу звиняний, вопросы снимаются.
>> Ну так пусть сам и проверяет, нечего терять производительность
>> - у нормальных людей эти проверки даром будут жрать cpu.
> Ну да, лучше пусть словит sigsegv при обращении, потому что третье приложениену словит, результат ровно тот же - ты пойдешь искать дополнительную планку.
> на электроне за это время выжрало всю оставшуюся память.
то есть ты еще и неправильно настроил свой распрекрасный rctl, но виноват опять автор программы, которой памяти не хватило ?
> Зато целый jnz short после жирного вызова malloc сэкономили. Профит, че.
в цикле этак с 10000 итераций, например.
Я тут пытался уговорить разработчиков одной _очень_ известной софтины (очень чувствительной к подобным вещам) на проверку указателей хотя бы в тех случаях, когда там _может_ оказаться null (то есть не malloc, а неправильный набор параметров передан) - получил в ответ "знаешь, он там оказываться не должен, так что лучше мы в этом случае просто функцию вызывать не будем- это в любом случае вредный вызов". И не добавили. Там примерно сотни три таких проверок в теле рекурсивно-вызываемой функции и надо-то, причем срабатывает из этих трех сотен - с десяток максимум в одной итерации (сколько их вообще может быть - не до конца понимаю, вроде и немного).
> Сам придумал, сам оспорил. Удобно, да.
> Лады, контейнеры не нужны! Жили без этого тысячи лет, значит и дальшеконтейнеры в том виде, в котором нам их принес доцкер - не, не нужны.
контейнеры в виде jail - нужны для запуска untrusted кода, но это вовсе не означает что в них должен запускаться скачанный без регистрации и sms - у меня таким кодом, к примеру, являлся bind и syslog.
А вот чего такое я хотел бы запускать с дубово-ограниченным размером rss - что-то и придумать не могу. Особенно учитывая сколько сил как раз на платформе freebsd потрачено чтобы память задачам хоть иногда отдавалась.
> Оversubscription будет на любой не самой новой машине с ОЗУ < 9000гигз,
> особенно мобильной, если запустить кроме браузера еще что-то жручее. Ну илиесли это жручее не жалко обломить о жесткие лимиты - то зачем, прости, ты его запускал?
> просто долго не закрывать браузер.
20 0 619m 1279m 70m R 91 20.6 493:27.89 palemoon
достаточно долго?> А, да, я ж забыл, что у кое-кого на десктопе десяточка. Прошу
у десяточки я не знаю как спросить что-то похожее. Но больше недели точно одна из мурзил не закрывалась.
Там, правда, поменьше табов, что-то около сорока.> звиняний, вопросы снимаются.
да, у божественной десяточки совсем нет проблемы "выбегает на сцену oom и бросает в зрительный зал гранату". Заметим, без всяких искусственных ограничителей и ненужно-контейнеров там, где они действительно не нужны совсем.
у нее есть другие проблемы, но ей простительно.
>> на электроне за это время выжрало всю оставшуюся память.
> то есть ты еще и неправильно настроил свой распрекрасный rctl, но виноват
> опять автор программы, которой памяти не хватило ?Причем тут rctl? Можешь передергивать не так явно?
>> Зато целый jnz short после жирного вызова malloc сэкономили. Профит, че.
> в цикле этак с 10000 итераций, например.Какой-какой "например"?
Вызов в цикле 10000 раз malloc? Так и тут дополнительный jnz особой погоды не сделает. Или вы собрались на всякий случай в цикле 10000 раз проверить, не ноль ли вернул вам вызов malloc?
> на остальной передерг можешь сам придумать ответы. Заодно и красиво, с чувсвтом, толком и с расстановкой их опровергнуть.
> Программисты привыкли работать с памятью так, будто её анлим,Таких программистов сжигать в биореакторе и отлучать от профессии навсегда без права обжалования.
> А вот убийство самого жрущего процесса как раз сравнительно безопасно: в серверном
> софте и память обычно не течет - всё вылизано, и спонтанное
> убийство он нормально переживает, а уж, тем более, по SIGTERM. Браузер
> восстановит сессию, ничего страшного.В серверном софте другие настройки ведра и планировщика. Но, впрочем, это одна из причин выбирать себе на десктоп и ноут серверные редакции ОС.
> А проблемы самописного софта, в котором течет память - это проблемы его разработчиков.Нет, анон, это именно что наша проблема. Автору г-нокода плевать на мучения юзеров.
Юзерам, в свою очередь, плевать, будет ли сожравший всю память и отказавшийся вовремя корректно завершиться по SIGTERM говнокод убит перезагрузкой системы или по SIGKILL.Говнокод это объективная реальность, данная нам в ощущениях, и, поскольку не во всех случаях можно перейти на отлично-код или написать отлично-код самому, приходится как-то жить с этим явлением. Например, убивать и автоматически перезапускать каким-нибудь systemd этот говнокод до того, как он положит систему и в итоге будет всё равно убит при перезагрузке.
> Юзерам, в свою очередь, плевать, будет ли сожравший всю память и отказавшийся
> вовремя корректно завершиться по SIGTERM говнокод убит перезагрузкой системы или по
> SIGKILL.
> Говнокод это объективная реальность, данная нам в ощущениях, и, поскольку не во
> всех случаях можно перейти на отлично-код или написать отлично-код самому, приходится
> как-то жить с этим явлением. Например, убивать и автоматически перезапускать каким-нибудь
> systemd этот говнокод до того, как он положит систему и
> в итоге будет всё равно убит при перезагрузке.Кому как. Я не могу с этим сжиться. Седьмая Шапка — это уже _не_ юникс, а какой-то SystemdOS. Причём они это, похоже, понимают и сами и в мануалах пишут (см. напр. man init, ага). Пока оно работает, как настроили индусы в Редхате, всё ещё терпимо. Если что-то ломается, то седьмое поколение RHEL и его производных невозможно внятно администрировать по понятиям адекватного юникса. О написании каких-то своих полезных скриптов с учётом концептуального идиотизма системды — даже говорить неохота.
а у админа не наступит попоболь когда этот алгоритм будет убивать 1С рассчитывающую зарплату?
На мой взгляд - сама идея убивать приложение активно использующее ресурсы-
- порождение фантазии человека с запущенной формой деменции
вообще говоря операционная система не должна была дать приложению столько ресурсов чтобы оно повредило общей работе сервера... так что это проблема ОС скорее, что некое приложение откушало у нее все... или оно в нулевом круге крутится?
> вообще говоря операционная система не должна была дать приложению столько ресурсов чтобы
> оно повредило общей работе сервера... так что это проблема ОС скорее,
> что некое приложение откушало у нее все... или оно в нулевом
> круге крутится?Как много хороших, годных вопросов для одного абзаца!
Про ответы надо спросить у Торвальдса лично и заодно у Красной Шапки: как правильно настраивать ведро.
1Су всё можно. Спроси у любого бухгалтера!
А 1C не умеет во всякие там транзакции, которые в СУБД изобрели специально для того, чтобы на спонтанные перезапуски было пофигу? Лучше живой сервак с бесконечно перезапускаемой на слишком жрущей операции базой (сигнал довыделить памяти, оукей), чем мёртвый сервак, до которого удаленно достучаться и выяснить причину проблем вообще не получается.
Приложение это хорошо, но пока обходился вот такой настройкой
vm.overcommit_ratio = 200
vm.overcommit_memory = 2Делает тоже самое - прибивает процесс когда он слишком зажрался
Чем оно лучше, нежели нажатие Alt-SysRq-F при признаках исчерпания памяти?
>Alt-SysRq-FМожет не сработать вообще, и у этой комбинации нет настроек. Эта комбинация не использует SIGTERM и не срабатывает автоматически когда надо.
А вот например, на нашем предприятии запрещено говорить, что компьютеры слабые, или не хватает памяти. И этот демон будет вне закона :))
> А вот например, на нашем предприятии запрещено говорить, что компьютеры слабые, или
> не хватает памяти. И этот демон будет вне закона :))дайте угадаю - ваше предприятие - изготовитель союза с дыркой-замазанной-соплями и ракеты-носителя которая развалилась после старта?
> не доводя состояние системы до очистки системных буферов и мешающего работе своппингалучше бы сделали, чтобы системные буфферы не чистились при прессинге памяти. А то выйгрышь на спичку от очистки буфферов, а производительность дисковой подсистемы падает катострофически. Тем более у многих swap на SSD, а то и на Optain накопителях. так что вытеснить что либо в swap спасая при этом дисковые буферы выглядит не так уж глупо.
> Тем более у многих swap на SSD, а тосерьезно, есть и такие феерические долбое6ы?
> и на Optain накопителях. так что вытеснить что либо в swap
> спасая при этом дисковые буферы выглядит не так уж глупо.чудовищно глупо.
Вам нужна файловая система с промежуточным кэшем на этом ssd, раз уж у вас настолько медленное основное хранилище, а не переписывать активные задачи туда.
Для неактивных это и так происходит - но не при memory pressure, а в idle time.
ну, поставил. Система не работоспособна даже для их самописной бомбы((((
-s 100,100
Системд же есть