Огромный LA

Умирает из-за нехватки памяти, LA-высокий потому, что оно еще учитывает занятость ввода-вывода.

Судя по тому что помогает SysRq+F - да. Но почему при этом горит лампочка диска? swap отключен.

Ядро сейчас 4.11.0-14-lowlatency

Попробуйте обычное ядро.

Чувак, есть только одно решение этой проблемы: выпилить поддержку свап из ядра. Грузит тебе систему kswapd0, ты не первый с такой проблемой.

Ну или запили себе свап, но это не Ъ-way

А лампочка горит потому, что ядро сбрасывает кэши записи на диск, и постоянно читает с диска(а не из кеша, которого уже нет) файлы.

тормоза вполне себе хорошо убирает zswap.

До того как засрется и он)

swap отключен.

Догадался по заголовку.

Я задавал этот вопрос по 3-10 раз на дню когда работал в хостинге:
Чем ты руководствовался когда отключал своп?

И что ? В какой-то ОС есть рецепт сидеть на одном мегабайте рамы и юзать весь современный софт без тормозов ?

Вот объясни мне, как сделать так, чтоб не тормозило при большом использовании памяти? Что за тупой oom-killer который не хочет приходить и убивать когда надо? Как можно его настроить/переделать чтоб он приходил сразу, и убивал без промедления???

При отключении свапа система тормозит меньше времени и oom-killer приходит быстрее. Но надо еще быстрее! Как?

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

Кто тут говорит о мегабайте? Здесь дело в том, что oom-killer не выполняет своей задачи. Должно быть так: система не может выделить память > убиваем самое жручее приложение. Все довольны, хром/жирнолис падает(что и надо).

Присоединяюсь к вопросу. Не так давно по глупости случайно «открыл» многогигабайтный текстовый файл в kwrite, оно выжрало все 24ГБ оперативной памяти, ушло в своп, который был, но OOM-killer так и не пришел. Пришлось перезагружать с кнопки, т.к. SysRq отключен.

https://askubuntu.com/questions/398236/oom-killer-not-working

Это лажа, т.к. убивает не то что надо (если в критический момент выделит sshd на прием нового коннекта - свалится он, а не говнобраузер, хотя должно быть наоборот)

Неужто нельза сделать алгоритм работающий всегда?

Что блин, так сложно всегда тупо килять _самый жирный_ процесс? Это не заставит систему тормозить долго...

А вместо этого oom считает какие-то коэффициенты... >_<

Должно быть так: система не может выделить память > убиваем самое жручее приложение.

Примерно так оно и работает, за исключением одной маленькой детали: прежде чем начать убивать, система пытается избавиться от неиспользуемых страниц в кэше ФС. Загвоздка в том, что в кэше ФС находится весь код работающих приложений, большая часть этих страниц не выполняется прямо сейчас, поэтому ядро смело из выбрасывает (ведь их всегда можно прочитать с диска заново). Если этот процесс заходит далеко, система начинает дико тормозить, так как код постоянно приходится подчитывать с диска, а процесс поиска страниц для уничтожения сильно замедляется (приходится многократно обходить одни и те же страницы, пока какая-то не станет «ненужной»). Вот на это стадии и начинается вызов киллера.

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

у oom есть приоритеты, внезапно.

убивает не то что надо

так ты настрой, что надо убивать, а что не надо. См. /proc/$pid/oom_score и oom_score_adj

Эта хрень же не наследуется между потомками!

А как можно настроить насколько далеко системе надо заходить прежде чем сдаться и вызвать oom-killer???

Я чисто из интереса ждал минут 40, но чуда так и не произошло, так что, видимо, ждать надо очень долго.

С ssd обычно мучается минут 5-10 полного стояния колом. если у тебя система на hdd - наверное пару часов пришлось бы ждать...

Можно отключить оверкоммит, но тогда может оказаться, что у тебя половина памяти перестала использоваться и все килляется заранее

зачем ждать когда есть SysRq+F

Не выход -_-

Как можно отключить попытку сброса ro-сегментов приложений из памяти? Пусть кэши данных сбрасывает, но не трогает код? Или linux таки не может в десктоп и интерактивность вообще???

Как можно отключить попытку сброса ro-сегментов приложений из памяти?

Это практически эквивалентно выключению оверкоммита

Не на всех клавах он нормально работает (ноутбук у меня)

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

Разумеется ssd там был, система и 8 гигов свопа на нем. Правда тот злополучный файл лежал на hdd. Система зависла намертво в течении нескольких секунд, прежде чем я успел открыть терминал и прибить процесс. Точнее, она не зависла, а что-то делала, но на клавиатуру же не реагировала.

а я говорю про другое - не вытеснять их, а не вообще запрещать выделять.

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

Уверен?

[~]$ bash -c 'ls -lha /proc/self; echo 42 >/proc/self/oom_score_adj; bash -c "ls -lha /proc/self; cat /proc/self/oom_score_adj"'
lrwxrwxrwx 1 root root 0 14. srp 08.22 /proc/self -> 21161
lrwxrwxrwx 1 root root 0 14. srp 08.22 /proc/self -> 21163
42

Штранно О_о

У меня последний раз не сработало на chromium'е такое...

Может он сам с этим значением шаманит, падла???

Не так давно по глупости случайно «открыл» многогигабайтный текстовый файл в kwrite, оно выжрало все 24ГБ оперативной памяти, ушло в своп, который был, но OOM-killer так и не пришел.

Дык надо vim использовать и будет тебе щастье

Должно быть так: система не может выделить память > убиваем самое жручее приложение. Все довольны, хром/жирнолис падает(что и надо).

Это в теории. На практике упадёт IDE и ну ты понял — довольных не будет.

Если кто-то использует написанное на жабе говно - да, падать будет оно. Но такие ССЗБ, да и даже нетбинс жрет меньше лисы, так что вряд ли...

IDE в целом жрёт меньше, чем брузак в целом. Однако каждый отдельно взятый процесс брузака жрёт немного — просто процессов дофига (ещё один плюс лисы с её пулом процессов по сравнению с хромиумом и его «1 вкладка >= 1 процесс»).

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

Чувак, есть только одно решение этой проблемы: выпилить поддержку свап из ядра. Грузит тебе систему kswapd0, ты не первый с такой проблемой.
Ну или запили себе свап, но это не Ъ-way

Хватит даже минимального размера? Вообще говоря swap вроде был, но проблема все равно проявлялась. Сделал на честных 8Гб. это даже больше рамы.

тормоза вполне себе хорошо убирает zswap.

Учитывая не оч быстрый процессор, боюсь что сделает только хуже.

Чем ты руководствовался когда отключал своп?

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

Да - на cpulimit набрел когда искал возможность пригласить oom-killer в автоматическом режиме к определенному списку процессов.

Komodo Edit жрет меньше браузера и ... joxy - эта шняга только что выжрала больше 1Гб.

Я настолько медленных процов не щупал. Везде где может запуститься линукс, zswap помогает.

cpulimit - г-но:

The control of the used CPU amount is done sending SIGSTOP and SIGCONT POSIX signals to processes

Лучше через cgroups лимит задать

The control of the used CPU amount is done sending SIGSTOP and SIGCONT POSIX signals to processes

Божечки ты мой... Я думал он там как-то на уровне планировщика работает. OMG.

Удаляю.

На уровне планировщика работают chrt и nice. Можно самому ненужному процессу задать SCHED_IDLE и его процессорное время сильно сократится (если в системем есть другие задачи)

для специфических задач своп нужно конечно настраивать, но могу посоветовать ограничить твои жручие браузеры через cgroups посредством systemd, это просто и эффективно. вот вводный пример:
https://samthursfield.wordpress.com/2015/05/07/running-firefox-in-a-cgroup-us...

боюсь что сделает только хуже

Там lzo по дефолту, который работает очень быстро. Можно на lz4 переключить, он еще реактивнее (ценой небольшого снижения коэффициента сжатия)

без systemd это тоже делается

Вот сейчас я увидел LA 60

xeon126# uptime
 1:42PM  up 9 mins, 3 users, load averages: 890407.00, 549381.40, 254199.55

Пока не получилось. Нашел инструкцию. Сделал (не уверен что правильно):

root@alex-laptop /h/alex# cat /etc/cgconfig.conf
group vivaldi {
	cpu {
		cpu.shares = 512;
	}
	memory {
		memory.limit_in_bytes = 1073741824;
		memory.memsw.limit_in_bytes = 1073741824;
	}
}

root@alex-laptop /h/alex# cat /etc/cgrules.conf
*:vivaldi-bit cpu,memory  vivaldi/

root@alex-laptop /h/alex# service cgconfig restart
Failed to restart cgconfig.service: Unit cgconfig.service not found.

root@alex-laptop /h/alex# service cgred restart
Failed to restart cgred.service: Unit cgred.service not found.

Ты победил.