LINUX.ORG.RU
ФорумAdmin

Огромный LA

 , ,


0

1

http://joxi.ru/zANBpbPSBolVbA http://joxi.ru/12Mx7bPSMo4nlm http://joxi.ru/EA4bngyfw6DjGm

Переодически сталкиваюсь с залипанием системы. Иногда помогает только SysRq+F - сама не отлипает вообще.

Во время зависание обычно большое потребление всего, до чего может дотянуться система. Вот сейчас я увидел LA 60. Лампочка винта горела непрерывно. Убилась SysRq+F страница вэб версии хэнгаутс в Opera (читай в хроме) - она частый злостный нарушитель.

Пытался бороться с этим ограничивае потребление CPU. Навоял такой демон: https://pastebin.com/KtXYfxzN на базе чужого решения. Но видно что не очень помогает.

Обычно пожиратели браузеры которых работает 2 как правила + 2-3 окна с инспектором, клиент MEGA. Работает еще Komodo Edit но как не странно он залипает на сетевых операциях и так как я им не работаю с локальными файлами возникает подозрения на проблемы с вводом/выводом дисковой подситстемы.

Диск PLEXTOR PX-128M5Pro (1.07), планировщик любой, но сейчас deadline.

Процессор Core2Duo T6600

Ядро сейчас 4.11.0-14-lowlatency но проблемы и на 4.4 и на 4.10

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

anonymous ()
Ответ на: комментарий от Suntechnic

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

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

Deleted ()
Ответ на: комментарий от Suntechnic

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

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

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

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

swap отключен.

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

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

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

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

Deleted ()
Ответ на: комментарий от bass

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Deleted

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не выход -_-

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от timdorohin

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

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

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

Уверен?

[~]$ 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
post-factum ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от timdorohin

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

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

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

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

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

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от annulen

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

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

Удаляю.

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

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

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

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

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

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

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

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

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

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.
У меня и служб-то таких нет как в инструкции (((

Suntechnic ★★★★★ ()
Последнее исправление: Suntechnic (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.