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

Kubuntu, Xubuntu и другие

Модератор: Модераторы разделов

DTF
Сообщения: 96

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

Сообщение 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
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

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

Сообщение alv »

Очень сильно улыбнуло.
DTF писал:
14.06.2018 16:19
Это вообще нормально в 2018 году, что процессы графического интерфейса не имеют приоритета перед пользовательскими процессами, и если пользователь запускает тяжелую операцию, то тормозить начинает ВСЁ?
Это было нормально со времён палеолита, и будет нормально до тех пор, пока человечество не передохнет. Выполняя тяжёлую задачу, Вы не оставляете сил для выполнения любых других
DTF писал:
14.06.2018 16:19
Как поправить проблему? :) В идеале хотелось бы, чтобы не тормозил не только интерфейс, но и, к пример, видео на ютубе.
В идеале по русски это называется - и рыбку съесть, и... эээ... кое-куда не сесть.
Поправить проблему очень просто - определитесь с приоритетами. Если для Вас важнее видео на ютубе - ограничте число потоков при компиляции, для того параметр -j# и придуман.
Если важнее таки скорость компиляции (для чего обычно и покупают многоядерные и гипертрейдинговые процессоры с предельными тактовыми частотами, типа Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz - ведь о нём речь идёт?) - то уж примиритесь с тем, что комфортно буде смотреть ютубу после выполнения работы, под пиво/водку/коньяк (нужное дописать).
Спасибо сказали:
Аватара пользователя
devilr
Сообщения: 3665
ОС: Mandriva => Gentoo (~amd64)
Контактная информация:

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

Сообщение devilr »

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

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

Сообщение Vascom »

Можешь запускать сборку с пониженным приоритетом через nice.
Спасибо сказали:
DTF
Сообщения: 96

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

Сообщение DTF »

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

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

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

Можешь запускать сборку с пониженным приоритетом через nice.
А nice разве влияет на управление памятью? Мне казалось, через него управляют временем cpu...
Но это частное решение для задачи, про которую заранее известно, что она ресурсоемкая.
А если это неизвестно заранее?
Спасибо сказали:
Аватара пользователя
Vascom
Сообщения: 1699
ОС: Fedora 32

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

Сообщение Vascom »

Что делать уже сказали.
Вредоносная программа в любом случае сможет нанести вред.
Ну и попробуй другие современные дистрибутивы, возможно это проблема убунты или твоих настроек.
Спасибо сказали:
Аватара пользователя
Vascom
Сообщения: 1699
ОС: Fedora 32

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

Сообщение Vascom »

Если мало памяти - добавляй её, используйте ssd или отключай swap.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu
Контактная информация:

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

Сообщение serzh-z »

DTF писал:
14.06.2018 16:19
Это вообще нормально в 2018 году, что процессы графического интерфейса не имеют приоритета перед пользовательскими
А что такое "процесс графического интерфейса"? Бесконечный цикл, запущенный из графического эмулятора терминала - это процесс графического интерфейса? Или компилятор, запущенный из IDE?

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

Ну если только в каком-нибудь очень специализированном дистрибутиве, собранном под очень специализированные задачи.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu
Контактная информация:

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

Сообщение serzh-z »

Vascom писал:
14.06.2018 18:06
отключай swap
Ой не надо. Своп нужен не только и не столько для расширения памяти. =)
Спасибо сказали:
Аватара пользователя
Vascom
Сообщения: 1699
ОС: Fedora 32

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

Сообщение Vascom »

Надо. Я отключил свап и всё отлично. При достаточном размере ОЗУ он совершенно не нужен.
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

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

Сообщение alv »

DTF писал:
14.06.2018 18:01
Ну хорошо, ютубчик тут лишний.
Но что насчет графического интерфейса?

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

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

$ ps aux
для выявления ресурсосожравшего процесса, затем (в общем случае от администратора)
$ sudo kill ###
где ### номер процесса-пожирателя. Для гарантии добавить опцию -9 - при ней процесс будет прибит в любом случае.
Ещё есть SysReq, но я уже забыл, когда к ним приходилось обращаться.
И вообще, что бы тут обсуждаем? Возможность максимально быстрой компиляции при комфортном просмотре ютуба, или нападение врагов народа?
С первым случаем всё ясно, нельзя бежать быстро и тащить большой груз. А от врагов народа надо защищаться другими способами.
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

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

Сообщение alv »

serzh-z писал:
14.06.2018 18:10
Vascom писал:
14.06.2018 18:06
отключай swap
Ой не надо. Своп нужен не только и не столько для расширения памяти. =)
Ох это предмет для священного обсуждения на многие страницы (пока до баб с водкой дело не дойдёт).
Да, согласен, свап нужен для всякоразных вещей. Однако на стандартном пользовательском десктопе ни одна из этих вещей почти никогда не задействована. И жу меньше всего при компиляции.
PS Уже не помню сколько лет живу без свапа - и вреда ни малейшего...
PPS И не только я - а все, кто слушает моих советов, в не выкиньпедиков.
Спасибо сказали:
DTF
Сообщения: 96

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

Сообщение DTF »

Переход в любую текстовую консоль - Alt+Control+F#, затем
Затем мы ждем минуту-другую. И то, если мы на 100% уверены, что система не намертво зависла, у выполняет ресурсоемкую задачу, и в консоль переключится, просто попозже.

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

В обоих случаях нельзя просто так взять и прибить провинившийся процесс, т.к. мы даже программу просмотра процессов открыть не можем.
Спасибо сказали:
Аватара пользователя
Vascom
Сообщения: 1699
ОС: Fedora 32

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

Сообщение Vascom »

В таком случае программу прибьёт OOM killer. И без свапа это случится быстрее, а может и сама порога упадёт в сегфолт.
Но в любом случае отслеживать запуск и работу таких программ дело не системы, а пользователя.
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

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

Сообщение alv »

serzh-z писал:
14.06.2018 18:07
Не уверен, что в Linux можно решить проблему автоматической приоритизации простым способом.
Насколько я знаю, эту задачу не удавалось решить никому - и даже не простым способом. И не только в Linux'е.
serzh-z писал:
14.06.2018 18:07
Ну если только в каком-нибудь очень специализированном дистрибутиве, собранном под очень специализированные задачи.
Ага. Например, в системе управления автоматической соковыжималкой. Но там, как Вы знаете, эта проблема решается путём выбора приоритетов... нет, не процессов, а между рыбкой и... ну Вы поняли.
Спасибо сказали:
Аватара пользователя
Vascom
Сообщения: 1699
ОС: Fedora 32

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

Сообщение Vascom »

Кстати, а что ты компилишь? Дай проверить на наших системах.
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

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

Сообщение alv »

Vascom писал:
14.06.2018 18:06
Если мало памяти - добавляй её, используйте ssd или отключай swap.
Универсальный рецепт.
Впрочем, к вопросу о распарллеливании задач на машинах с многоядерными и мультитрейдинговыми процессорами это не имеет ни малейшего отношения (с) Киса Воробьянинов
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu
Контактная информация:

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

Сообщение serzh-z »

alv писал:
14.06.2018 18:25
Ох это предмет для священного обсуждения на многие страницы (пока до баб с водкой дело не дойдёт).
Даже и не знаю чего тут можно обсуждать. Все описано в документации к ядру.
Vascom писал:
14.06.2018 18:12
Надо. Я отключил свап и всё отлично. При достаточном размере ОЗУ он совершенно не нужен.
alv писал:
14.06.2018 18:25
Однако на стандартном пользовательском десктопе ни одна из этих вещей почти никогда не задействована.
Пардон, но складывается впечатление, что вы просто не понимаете, как работает менеджер памяти в UNIX и для чего нужна подкачка страниц (swap area, а не какая-нибудь "add more cheap and slow memory area").

Такое ощущение, что те, кто советует купить больше планок и отключить своп - сидят на зарплате у производителей чипов. Вы покупайте, покупайте, а потом ломайте менеджер памяти так, чтобы половина планок у вас была вставлена просто так, без дела. =)
Последний раз редактировалось serzh-z 14.06.2018 23:29, всего редактировалось 1 раз.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu
Контактная информация:

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

Сообщение serzh-z »

alv писал:
14.06.2018 18:32
Насколько я знаю, эту задачу не удавалось решить никому - и даже не простым способом. И не только в Linux'е.
Не припоминаю, чтобы в Windows тормозил GUI, при запущенной в фоне игре или обработке RAW-файла. Но там все завязано на окна, о которых ядро все знает без посторонних графических серверров, проще понять что является GUI.
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

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

Сообщение alv »

serzh-z писал:
14.06.2018 23:13
alv писал:
14.06.2018 18:32
Насколько я знаю, эту задачу не удавалось решить никому - и даже не простым способом. И не только в Linux'е.
Не припоминаю, чтобы в Windows тормозил GUI, при запущенной в фоне игре или обработке RAW-файла. Но там все завязано на окна, о которых ядро все знает без посторонних графических серверров, проще понять что является GUI.
А я вот не встречал тех, кто в Windows компилил бы в фоне Open/LibreOffice или там Qt/KDE, и при этом комфортно смотрел бы Youtybe. Или массово собирал бы iso-образы с XZ-компрессией.
Или у них там ни компиляторы, ни компрессоры больше одного ядра загрузить не могут?
PS Впрочем, я давно не встречал никого, кто в Windows делал бы что-то серьёзное. Или вообще что-то делал...
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

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

Сообщение alv »

serzh-z писал:
14.06.2018 23:08
Пардон, но складывается впечатление, что вы просто не понимаете, как работает менеджер памяти в UNIX.
Вi будете очень удивлены тем, что менеджер памяти в разных UNIX'ах работает по разному? Например, в Linux'е и FreeBSD - очень по разному (за другие не скажу).
serzh-z писал:
14.06.2018 23:08
Такое ощущение, что те, кто советует купить больше планок и отключить своп - сидят на зарплате у производителей чипов.
А Вы намекните про это производителям чипов - может, они нас на зарплату зачислят :)
А то без жалования мы скромно так говорим - что своп не нужен начиная с 8 ГБ. Правда, я и при 4-х без него обходился. И даже не догадывался, что при этом ломаю менеджер памяти - на моей памяти он никогда на это не жаловался...
Спасибо сказали:
DTF
Сообщения: 96

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

Сообщение DTF »

serzh-z писал(а):А что такое "процесс графического интерфейса"? Бесконечный цикл, запущенный из графического эмулятора терминала - это процесс графического интерфейса? Или компилятор, запущенный из IDE?
Ну это некая подсистема, которая отвечает за интерфейс.
Гарантированный приоритет должен быть, как минимум, у
  • Процесса, который сообщает программам о пользовательских событиях (кликах мышки, нажатиях и т.п.)
  • Штатного процесса, который запускает программы. В моем случае, это, видимо, связка из X и KDE
  • У менеджера задач (т.е. программы, которая может показывать использование ресурсов и убивать зажравшиеся программы)
serzh-z писал(а):Не припоминаю, чтобы в Windows тормозил GUI, при запущенной в фоне игре или обработке RAW-файла. Но там все завязано на окна, о которых ядро все знает без посторонних графических серверров, проще понять что является GUI.
Так вот о том и речь! Гуй есть и в винде и в линуксе, но почему-то винда может понять где гуй, а линукс нет.
Кстати, в 9x гуй тормозил при загруженной системе. Но вот MS это поборола. MacOS не видел, но уверен, что там тоже такой проблемы нет.
Потому и написал про 2018 год.
Vascom писал(а):В таком случае программу прибьёт OOM killer. И без свапа это случится быстрее, а может и сама порога упадёт в сегфолт.
Почему? Она ведь может есть память не бесконечно, а просто достаточно для того, чтобы замедлить систему.
Vascom писал(а):Но в любом случае отслеживать запуск и работу таких программ дело не системы, а пользователя.
Ну система должна дать пользователю возможность хотя бы посмотреть какая программа ест ресурсы.
Vascom писал(а):Кстати, а что ты компилишь? Дай проверить на наших системах.
Ну это программа, которую разрабатывает наша контора, так что дать ее не могу. Но там нет ничего сверхъестественного.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu
Контактная информация:

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

Сообщение serzh-z »

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

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

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

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

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

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

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

Даже если какой-нибудь, скажем, демон при своем запуске запросил гигабайт памяти, а потом ее освободил и уснул до перезагрузки, то эта память так и останется при нем, в пуле менеджера памяти libc. Менеджер виртуальной памяти не сможет ее переиспользовать и отдать кому-то еще.
Последний раз редактировалось serzh-z 15.06.2018 01:20, всего редактировалось 1 раз.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

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

Сообщение Bizdelnick »

alv писал:
14.06.2018 23:38
А то без жалования мы скромно так говорим - что своп не нужен начиная с 8 ГБ. Правда, я и при 4-х без него обходился. И даже не догадывался, что при этом ломаю менеджер памяти - на моей памяти он никогда на это не жаловался...
Я сталкивался с одной ситуацией, когда swap был полезен (не считая suspend-to-disk). Дело было в кривых версиях webkit (причём именно разных версиях, там этот баг то чинят, то возвращают), который при инициализации запрашивает у ядра какие-то лютые гигабайты памяти, и потом их не использует. Но если такого объёма свободной памяти физически нет, процесс благополучно прибивается OOM-киллером. Swap позволяет избежать прибития. Но это, конечно, кривизна webkit виновата, а не какие-то особенности менеджера памяти.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu
Контактная информация:

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

Сообщение serzh-z »

DTF писал:
15.06.2018 00:20
Ну это некая подсистема, которая отвечает за интерфейс.
Ядро ничего не знает ни про какие GUI. Программа и программа. Можно, наверное, придумать какие-нибудь эвристики, которые позвролят предположить, что это приложение GUI, типа: самый-самый родительский процесс - это процесс, который обращается к KMS - Xorg, gnome-session и т.д., а все остальные - это низкоприоритетные процессы. Но тогда любой процесс, запущенные из, скажем, gnome-terminal, будет не отличим от остальных "интерфейсных" процессов.
DTF писал:
15.06.2018 00:20
Так вот о том и речь! Гуй есть и в винде и в линуксе, но почему-то винда может понять где гуй, а линукс нет.
В Windows все завязано на окна - любое нетерминальное приложение имеет скрытое окно. Их легко отличить: либо оконное приложение, либо консольное, либо сервис. И все это гвоздями вкорячено в API.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu
Контактная информация:

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

Сообщение serzh-z »

Bizdelnick писал:
15.06.2018 00:24
лютые гигабайты памяти, и потом их не использует.
Bizdelnick писал:
15.06.2018 00:24
кривизна webkit
Это не кривизна. Просто так вот устроены процессы в UNIX. Если памяти нужна, то она запрашивается процессом и распределяется менеджером памяти libc, т.е. просто граница процесса подвигается вперед, пул доступной памяти увеличивается (libc), а потом из него процессу выделяется блок памяти. А когда процесс эту память освобождает, то она просто отправляется в пул свободной памяти, но граница процесса назад не двигается (brk(2)), просто потому, что это было бы сложно и накладно.
Последний раз редактировалось serzh-z 15.06.2018 01:19, всего редактировалось 3 раза.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

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

Сообщение Bizdelnick »

DTF писал:
15.06.2018 00:20
Гарантированный приоритет должен быть, как минимум, у
Если б он и был, то он бы ничем в данной ситуации не помог. У Вас система тормозит не из-за загрузки процессора, а из-за свопинга. Можете легко проверить: запустите сборку через nice.
DTF писал:
15.06.2018 00:20
Гуй есть и в винде и в линуксе, но почему-то винда может понять где гуй, а линукс нет.
Винда при свопинге тоже тупит. Чудес не бывает.
DTF писал:
15.06.2018 00:20
система должна дать пользователю возможность хотя бы посмотреть какая программа ест ресурсы.
У Вас есть такая возможность. Просто это будет происходить ооооочееень меееедлеееннооо.
DTF писал:
15.06.2018 00:20
Ну это программа, которую разрабатывает наша контора, так что дать ее не могу. Но там нет ничего сверхъестественного.
C++, boost, шаблон на шаблоне и шаблоном погоняет? В том, что компиляция таких вещей жрёт память, точно нет ничего сверхъестественного. Просто подберите число потоков, при котором тормозов не наблюдается, и используйте его.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

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

Сообщение Bizdelnick »

serzh-z писал:
15.06.2018 00:34
Это не кривизна. Просто так вот устроены процессы в UNIX. Если памяти нужна, то она запрашивается процессом и распределяется менеджером памяти libc, т.е. просто граница процесса подвигается вперед.
Это именно кривизна. Речь идёт о памяти, которая фактически не нужна и использоваться не будет. А освобождение памяти тут вообще ни при чём, освобождать ещё нечего.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
DTF
Сообщения: 96

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

Сообщение DTF »

serzh-z писал(а):Ядро ничего не знает ни про какие GUI
А при чем тут ядро? Оно и не должно знать про GUI. Ядро могло бы предоставлять функционал типа "Для процессов A, B, C и D всегда держать резерв X мегабайт оперативы и Y промилле процессорного времени".
А какие конкретно процессы должны получить эти привилегии решали бы разработчихи X/DE/дистрибутивов.
Bizdelnick писал(а):C++, boost, шаблон на шаблоне и шаблоном погоняет?
Блин, да какая разница-то. Проблема не в том, что компиляция трудоемка. Проблема в том, что случайно запущенный трудоемкий процесс подвешивает систему.
Bizdelnick писал(а):Если б он и был, то он бы ничем в данной ситуации не помог. У Вас система тормозит не из-за загрузки процессора, а из-за свопинга
Вы меня неправильно поняли. Под словом приоритет я понимал не только приоритет при получении процессорного времени, но и приоритет доступа к другим ресурсам, памяти, в данном случае.
То, что с дефолтными настройками свопится память DE - неправильно :(
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

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

Сообщение Bizdelnick »

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