Под нагрузкой система становится неотзывчивой

[DTF]

Добры день.
Имеем систему KUbuntu 18.04, 8Гб оперативки и процессор Intel Core i7-479, про который lscpu говорит:

CPU(s): 8
On-line CPU(s) list: 0-7
Потоков на ядро: 2
Ядер на сокет: 4
Сокетов: 1

(т.е. четырехъядерный процессор с эмуляцией 8ми ядер?)


В ненагруженном состоянии top показывает вот такую ситуацию:

Код: Выделить всё

top - 15:18:59 up 43 min,  4 users,  load average: 3,17, 11,35, 7,53
Tasks: 238 total,   1 running, 171 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2,4 us,  0,8 sy,  0,0 ni, 96,4 id,  0,5 wa,  0,0 hi,  0,0 si,  0,0 st
КиБ Mem :  8080884 total,  6544816 free,   973364 used,   562704 buff/cache
КиБ Swap:  2097148 total,  1401600 free,   695548 used.  6850212 avail Mem

Система отзывчива, т.е. сразу реагиурет на нажаите кнопок.


Если запустить компиляцию в 4 потока (/usr/bin/cmake --build . --target all -- -j4), то картинка станет такой:

Код: Выделить всё

top - 15:29:33 up 53 min,  4 users,  load average: 2,47, 2,87, 4,57
Tasks: 258 total,   6 running, 186 sleeping,   0 stopped,   0 zombie
%Cpu(s): 51,9 us,  2,6 sy,  0,0 ni, 45,3 id,  0,1 wa,  0,0 hi,  0,1 si,  0,0 st
КиБ Mem :  8080884 total,  3161184 free,  3911656 used,  1008044 buff/cache
КиБ Swap:  2097148 total,  1703680 free,   393468 used.  4067756 avail Mem 

Система остается отзывчивой.


А вот если запустить компиляцию без ограничения количества потоков (/usr/bin/cmake --build . --target all), то начнется лютый трэш:

1. Система почти перестает отзываться на движения мыши и нажатия кнопок на клавиатуре. Время реакции несколько десятков секунд
2. По показаниям top, количество доступной памяти (avail Mem) падает вплоть до 21716 Кб.
3. Опять же по показаниям top, запускается 10 процессов под названием cc1plus, каждый из которых ест от 50% до 92% cpu.
4. Вся эта вакханалия продолжается около минуты, потом процессы cc1plus завершаются, система становится более-менее отзывчивой, в терминале, где была запущена сборка виден прогресс
5. Снова запускается куча процессов cc1plus и всё повторяется.

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


Собственно вопросы:

• Это вообще нормально в 2018 году, что процессы графического интерфейса не имеют приоритета перед пользовательскими процессами, и если пользователь запускает тяжелую операцию, то тормозить начинает ВСЁ?
• Как поправить проблему? В идеале хотелось бы, чтобы не тормозил не только интерфейс, но и, к пример, видео на ютубе.

[alv]

Очень сильно улыбнуло.

Это вообще нормально в 2018 году, что процессы графического интерфейса не имеют приоритета перед пользовательскими процессами, и если пользователь запускает тяжелую операцию, то тормозить начинает ВСЁ?

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

Как поправить проблему? В идеале хотелось бы, чтобы не тормозил не только интерфейс, но и, к пример, видео на ютубе.

В идеале по русски это называется - и рыбку съесть, и... эээ... кое-куда не сесть.
Поправить проблему очень просто - определитесь с приоритетами. Если для Вас важнее видео на ютубе - ограничте число потоков при компиляции, для того параметр -j# и придуман.
Если важнее таки скорость компиляции (для чего обычно и покупают многоядерные и гипертрейдинговые процессоры с предельными тактовыми частотами, типа Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz - ведь о нём речь идёт?) - то уж примиритесь с тем, что комфортно буде смотреть ютубу после выполнения работы, под пиво/водку/коньяк (нужное дописать).

[devilr]

Кстати, вроде и в 2018 году вполне актуально правило при сборке "количество ядер + 1". Хотя, можно и не прибавлять единичку.
В любом случае, команда "собрать всё любой ценой" будет приводить к тому, что "ютубчик" не впишется в эту концепцию и будет успешно задавлен. Как и все остальное, не имеющее отношение к, собственно, сборке.
Имхо.

[Vascom]

Можешь запускать сборку с пониженным приоритетом через nice.

[DTF]

Ну хорошо, ютубчик тут лишний.
Но что насчет графического интерфейса?

Ведь, допустим, некая программа в результате бага (или злого умысла создателя) выжрала все ресурсы.
Пользователь не сможет даже остановить ее, потому что интерфейс не работает.
Что тогда делать? Компьютер выключать?

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

Можешь запускать сборку с пониженным приоритетом через nice.

А nice разве влияет на управление памятью? Мне казалось, через него управляют временем cpu...
Но это частное решение для задачи, про которую заранее известно, что она ресурсоемкая.
А если это неизвестно заранее?

[Vascom]

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

[Vascom]

Если мало памяти - добавляй её, используйте ssd или отключай swap.

[serzh-z]

Это вообще нормально в 2018 году, что процессы графического интерфейса не имеют приоритета перед пользовательскими

А что такое "процесс графического интерфейса"? Бесконечный цикл, запущенный из графического эмулятора терминала - это процесс графического интерфейса? Или компилятор, запущенный из IDE?

Не уверен, что в Linux можно решить проблему автоматической приоритизации простым способом.

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

[serzh-z]

отключай swap

Ой не надо. Своп нужен не только и не столько для расширения памяти. =)

[Vascom]

Надо. Я отключил свап и всё отлично. При достаточном размере ОЗУ он совершенно не нужен.

[alv]

Ну хорошо, ютубчик тут лишний.
Но что насчет графического интерфейса?

Ведь, допустим, некая программа в результате бага (или злого умысла создателя) выжрала все ресурсы.
Пользователь не сможет даже остановить ее, потому что интерфейс не работает.
Что тогда делать? Компьютер выключать?

Переход в любую текстовую консоль - Alt+Control+F#, затем

Код: Выделить всё

$ ps aux

для выявления ресурсосожравшего процесса, затем (в общем случае от администратора)

$ sudo kill ###

где ### номер процесса-пожирателя. Для гарантии добавить опцию -9 - при ней процесс будет прибит в любом случае.
Ещё есть SysReq, но я уже забыл, когда к ним приходилось обращаться.
И вообще, что бы тут обсуждаем? Возможность максимально быстрой компиляции при комфортном просмотре ютуба, или нападение врагов народа?
С первым случаем всё ясно, нельзя бежать быстро и тащить большой груз. А от врагов народа надо защищаться другими способами.

[alv]

отключай swap

Ой не надо. Своп нужен не только и не столько для расширения памяти. =)

Ох это предмет для священного обсуждения на многие страницы (пока до баб с водкой дело не дойдёт).
Да, согласен, свап нужен для всякоразных вещей. Однако на стандартном пользовательском десктопе ни одна из этих вещей почти никогда не задействована. И жу меньше всего при компиляции.
PS Уже не помню сколько лет живу без свапа - и вреда ни малейшего...
PPS И не только я - а все, кто слушает моих советов, в не выкиньпедиков.

[DTF]

Переход в любую текстовую консоль - Alt+Control+F#, затем

Затем мы ждем минуту-другую. И то, если мы на 100% уверены, что система не намертво зависла, у выполняет ресурсоемкую задачу, и в консоль переключится, просто попозже.

И вообще, что бы тут обсуждаем?

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

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

[Vascom]

В таком случае программу прибьёт OOM killer. И без свапа это случится быстрее, а может и сама порога упадёт в сегфолт.
Но в любом случае отслеживать запуск и работу таких программ дело не системы, а пользователя.

[alv]

Не уверен, что в Linux можно решить проблему автоматической приоритизации простым способом.

Насколько я знаю, эту задачу не удавалось решить никому - и даже не простым способом. И не только в Linux'е.

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

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

[Vascom]

Кстати, а что ты компилишь? Дай проверить на наших системах.

[alv]

Если мало памяти - добавляй её, используйте ssd или отключай swap.

Универсальный рецепт.
Впрочем, к вопросу о распарллеливании задач на машинах с многоядерными и мультитрейдинговыми процессорами это не имеет ни малейшего отношения (с) Киса Воробьянинов

[serzh-z]

Ох это предмет для священного обсуждения на многие страницы (пока до баб с водкой дело не дойдёт).

Даже и не знаю чего тут можно обсуждать. Все описано в документации к ядру.

Надо. Я отключил свап и всё отлично. При достаточном размере ОЗУ он совершенно не нужен.

Однако на стандартном пользовательском десктопе ни одна из этих вещей почти никогда не задействована.

Пардон, но складывается впечатление, что вы просто не понимаете, как работает менеджер памяти в UNIX и для чего нужна подкачка страниц (swap area, а не какая-нибудь "add more cheap and slow memory area").

Такое ощущение, что те, кто советует купить больше планок и отключить своп - сидят на зарплате у производителей чипов. Вы покупайте, покупайте, а потом ломайте менеджер памяти так, чтобы половина планок у вас была вставлена просто так, без дела. =)

[serzh-z]

Насколько я знаю, эту задачу не удавалось решить никому - и даже не простым способом. И не только в Linux'е.

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

[alv]

Насколько я знаю, эту задачу не удавалось решить никому - и даже не простым способом. И не только в Linux'е.

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

А я вот не встречал тех, кто в Windows компилил бы в фоне Open/LibreOffice или там Qt/KDE, и при этом комфортно смотрел бы Youtybe. Или массово собирал бы iso-образы с XZ-компрессией.
Или у них там ни компиляторы, ни компрессоры больше одного ядра загрузить не могут?
PS Впрочем, я давно не встречал никого, кто в Windows делал бы что-то серьёзное. Или вообще что-то делал...

[alv]

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

Вi будете очень удивлены тем, что менеджер памяти в разных UNIX'ах работает по разному? Например, в Linux'е и FreeBSD - очень по разному (за другие не скажу).

Такое ощущение, что те, кто советует купить больше планок и отключить своп - сидят на зарплате у производителей чипов.

А Вы намекните про это производителям чипов - может, они нас на зарплату зачислят
А то без жалования мы скромно так говорим - что своп не нужен начиная с 8 ГБ. Правда, я и при 4-х без него обходился. И даже не догадывался, что при этом ломаю менеджер памяти - на моей памяти он никогда на это не жаловался...

[DTF]

А что такое "процесс графического интерфейса"? Бесконечный цикл, запущенный из графического эмулятора терминала - это процесс графического интерфейса? Или компилятор, запущенный из IDE?

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

• Процесса, который сообщает программам о пользовательских событиях (кликах мышки, нажатиях и т.п.)
• Штатного процесса, который запускает программы. В моем случае, это, видимо, связка из X и KDE
• У менеджера задач (т.е. программы, которая может показывать использование ресурсов и убивать зажравшиеся программы)

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

Так вот о том и речь! Гуй есть и в винде и в линуксе, но почему-то винда может понять где гуй, а линукс нет.
Кстати, в 9x гуй тормозил при загруженной системе. Но вот MS это поборола. MacOS не видел, но уверен, что там тоже такой проблемы нет.
Потому и написал про 2018 год.

В таком случае программу прибьёт OOM killer. И без свапа это случится быстрее, а может и сама порога упадёт в сегфолт.

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

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

Ну система должна дать пользователю возможность хотя бы посмотреть какая программа ест ресурсы.

Кстати, а что ты компилишь? Дай проверить на наших системах.

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

[serzh-z]

Например, в Linux'е и FreeBSD - очень по разному (за другие не скажу).

Штоа? Заглянул в https://www.freebsd.org/doc/en_US.ISO88 ... pages.html - даже приписка в конце есть, про проактивное вытестение страниц в FreeBSD. Если бы механизм подкачки страниц там работал иначе, то он бы, вероятно, и назывался по-другому.

Я все же поясню:

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

Ненужные - это, например те, которые уже были обработаны и исполнены (в случае с сегментом кода) и больше к ним обращение уже никогда выполняться не будет (код инициализации приложения, например). Или те, к которым очень давно не выполнялось обращение. То есть, нет смысла держать такие страницы в памяти. Память нужно использовать - для страничного кеша, например, или для других процессов.

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

У анонимных же страниц (в которых размещается стек и данные) такого связанного файла нет и вытеснить их просто некуда. Когда ядру понадобится, например, больше памяти для страничного кеша или для другого процесса, то оно (менеджер памяти) начнет выбирать какие ненужные страницы можно вытеснить или удалить из памяти. Поскольку своп отключен, то анонимные страницы, даже те, к которым не было доступа в последние несколько лет, с тех пор как включили сервер, =) трогать нельзя. Остаются file-backed страницы - сегменты кода, шаренные библиотеки и т.д. Даже если они нужны.

И так вот получается: слишком умный пользователь отключил область подкачки - "она же медленная, я лучше больше планок куплю" - и раз мы не можем в нее вытеснить ненужные анонимные страницы, то начинаем удалять/загружать куски кода с диска, а анонимную память всяких сонные демонов, просыпающихся раз в неделю, вытеснить никуда не можем, она становится резидентной. =)

Даже если какой-нибудь, скажем, демон при своем запуске запросил гигабайт памяти, а потом ее освободил и уснул до перезагрузки, то эта память так и останется при нем, в пуле менеджера памяти libc. Менеджер виртуальной памяти не сможет ее переиспользовать и отдать кому-то еще.

[Bizdelnick]

А то без жалования мы скромно так говорим - что своп не нужен начиная с 8 ГБ. Правда, я и при 4-х без него обходился. И даже не догадывался, что при этом ломаю менеджер памяти - на моей памяти он никогда на это не жаловался...

Я сталкивался с одной ситуацией, когда swap был полезен (не считая suspend-to-disk). Дело было в кривых версиях webkit (причём именно разных версиях, там этот баг то чинят, то возвращают), который при инициализации запрашивает у ядра какие-то лютые гигабайты памяти, и потом их не использует. Но если такого объёма свободной памяти физически нет, процесс благополучно прибивается OOM-киллером. Swap позволяет избежать прибития. Но это, конечно, кривизна webkit виновата, а не какие-то особенности менеджера памяти.

[serzh-z]

Ну это некая подсистема, которая отвечает за интерфейс.

Ядро ничего не знает ни про какие GUI. Программа и программа. Можно, наверное, придумать какие-нибудь эвристики, которые позвролят предположить, что это приложение GUI, типа: самый-самый родительский процесс - это процесс, который обращается к KMS - Xorg, gnome-session и т.д., а все остальные - это низкоприоритетные процессы. Но тогда любой процесс, запущенные из, скажем, gnome-terminal, будет не отличим от остальных "интерфейсных" процессов.

Так вот о том и речь! Гуй есть и в винде и в линуксе, но почему-то винда может понять где гуй, а линукс нет.

В Windows все завязано на окна - любое нетерминальное приложение имеет скрытое окно. Их легко отличить: либо оконное приложение, либо консольное, либо сервис. И все это гвоздями вкорячено в API.

[serzh-z]

лютые гигабайты памяти, и потом их не использует.

кривизна webkit

Это не кривизна. Просто так вот устроены процессы в UNIX. Если памяти нужна, то она запрашивается процессом и распределяется менеджером памяти libc, т.е. просто граница процесса подвигается вперед, пул доступной памяти увеличивается (libc), а потом из него процессу выделяется блок памяти. А когда процесс эту память освобождает, то она просто отправляется в пул свободной памяти, но граница процесса назад не двигается (brk(2)), просто потому, что это было бы сложно и накладно.

[Bizdelnick]

Гарантированный приоритет должен быть, как минимум, у

Если б он и был, то он бы ничем в данной ситуации не помог. У Вас система тормозит не из-за загрузки процессора, а из-за свопинга. Можете легко проверить: запустите сборку через nice.

Гуй есть и в винде и в линуксе, но почему-то винда может понять где гуй, а линукс нет.

Винда при свопинге тоже тупит. Чудес не бывает.

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

У Вас есть такая возможность. Просто это будет происходить ооооочееень меееедлеееннооо.

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

C++, boost, шаблон на шаблоне и шаблоном погоняет? В том, что компиляция таких вещей жрёт память, точно нет ничего сверхъестественного. Просто подберите число потоков, при котором тормозов не наблюдается, и используйте его.

[Bizdelnick]

Это не кривизна. Просто так вот устроены процессы в UNIX. Если памяти нужна, то она запрашивается процессом и распределяется менеджером памяти libc, т.е. просто граница процесса подвигается вперед.

Это именно кривизна. Речь идёт о памяти, которая фактически не нужна и использоваться не будет. А освобождение памяти тут вообще ни при чём, освобождать ещё нечего.

[DTF]

Ядро ничего не знает ни про какие GUI

А при чем тут ядро? Оно и не должно знать про GUI. Ядро могло бы предоставлять функционал типа "Для процессов A, B, C и D всегда держать резерв X мегабайт оперативы и Y промилле процессорного времени".
А какие конкретно процессы должны получить эти привилегии решали бы разработчихи X/DE/дистрибутивов.

C++, boost, шаблон на шаблоне и шаблоном погоняет?

Блин, да какая разница-то. Проблема не в том, что компиляция трудоемка. Проблема в том, что случайно запущенный трудоемкий процесс подвешивает систему.

Если б он и был, то он бы ничем в данной ситуации не помог. У Вас система тормозит не из-за загрузки процессора, а из-за свопинга

Вы меня неправильно поняли. Под словом приоритет я понимал не только приоритет при получении процессорного времени, но и приоритет доступа к другим ресурсам, памяти, в данном случае.
То, что с дефолтными настройками свопится память DE - неправильно

[Bizdelnick]

Вы меня неправильно поняли. Под словом приоритет я понимал не только приоритет при получении процессорного времени, но и приоритет доступа к другим ресурсам, памяти, в данном случае.

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