The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск обработчика нехватки памяти earlyoom 1.4, opennews (ok), 02-Мрт-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


183. "Выпуск обработчика нехватки памяти earlyoom 1.4"  +/
Сообщение от yaya (?), 04-Мрт-20, 20:25 
> тест не релевантен, нехватает sleep

Зачем sleep-то?

> как только он съедает память то сразу выходит

Вы не увидели там while (1)?

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

То, что я хочу проверить - я понимаю и написал такой маленький тест. Один человек уже его запустил, у него не возникло недоумений, как у вас. Он увидел, что его система начала притормаживать, но не критично. По ctrl-c он сумел срубить тест. Но он запустил его в виртуалке.

Если я запускаю на своей машине этот же тест, то у меня машина перестаёт откликаться - всё уходит в своп и не даёт ничего сделать.

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

Ответить | Правка | Наверх | Cообщить модератору

191. "Выпуск обработчика нехватки памяти earlyoom 1.4"  +/
Сообщение от ананчик (?), 04-Мрт-20, 23:44 
> Зачем sleep-то?

что бы не выжирал память за считанные секунды.
>Вы не увидели там while (1)?

Действительно он есть, что еще более странно что будет когда malloc будет возвращать ошибку
while(1){} одно ядро убили.

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

а вот посадить такую  membomb в cgroups я не пробовал, думаю сейчас это решило бы практически все проблемы

Учтите что соотношение размера оперативной памяти и размер свопа очень сильно влияет на ваши тормоза. Добавьте sleep где-то 1-5 секунд запустите vmstat/iotop или что то подобное и вам сразу станет понятно откуда тормоза.
вот вам маленькая шпаргалка https://www.oracle.com/technical-resources/articles/it-infra...

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

Ответить | Правка | Наверх | Cообщить модератору

197. "Выпуск обработчика нехватки памяти earlyoom 1.4"  +/
Сообщение от Аноним (-), 05-Мрт-20, 02:22 
> что бы не выжирал память за считанные секунды.

А в чем пойнт туповэйтить в разы дольше?

Ответить | Правка | Наверх | Cообщить модератору

203. "Выпуск обработчика нехватки памяти earlyoom 1.4"  +/
Сообщение от пох. (?), 05-Мрт-20, 07:47 
> Действительно он есть, что еще более странно что будет когда malloc будет
> возвращать ошибку

очевидно - будет крутиться в цикле, периодически спрашивая "а еще память есть? А если найду?"

и если найдет - сожрет.

> io. То что у вас  gui  просто встает колом
> тоже нормально это регулируется приоритетами процессов по io.

этот процесс не занимается io, думайте дальше.

> а вот посадить такую  membomb в cgroups я не пробовал, думаю
> сейчас это решило бы практически все проблемы

да-да. ручное управление памятью каждому /bin/ls решит все проблемы, безусловно.

Добро пожаловать в 1970й. В 72м это немного всем уже осточертело, и появился unix.

Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

209. "Выпуск обработчика нехватки памяти earlyoom 1.4"  +/
Сообщение от yaya (?), 05-Мрт-20, 15:48 
> что бы не выжирал память за считанные секунды.

В этом и есть тест. Не, конечно можно было бы открыть chrome, открыть кучу вкладок, открыть libreoffice книги "Война и мир", открыть видеоредактор, 3D-редактор, загрузить в них кучу файлов и надеятся нарваться на проблему "нехватки памяти", но это как-то долго и не факт, что получится проблема "нехватки памяти".

Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

213. "Выпуск обработчика нехватки памяти earlyoom 1.4"  +/
Сообщение от пох. (?), 05-Мрт-20, 22:32 
>> что бы не выжирал память за считанные секунды.
> В этом и есть тест. Не, конечно можно было бы открыть chrome,

не, это разные тесты. Тут весь поинт в том что память жрется быстрее, чем своппер успевает ее освобождать.

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

Плюс они обрабатывают ошибки выделения этой памяти (скорее всего assert("опачки, кончилась?");
но уж точно не навернуть еще десяток циклов в ожидании а вдруг появится).

> "нехватки памяти", но это как-то долго и не факт, что получится
> проблема "нехватки памяти".

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

Ответить | Правка | Наверх | Cообщить модератору

216. "Выпуск обработчика нехватки памяти earlyoom 1.4"  +/
Сообщение от yaya (?), 06-Мрт-20, 16:52 
> Тут весь поинт в том что память жрется быстрее, чем своппер успевает ее освобождать.
> получится, но она несколько иначе выглядит.

Даже если не жрать память быстрее, а просто один раз запросить памяти на размер ОЗУ*2 и активно потом этой выделенной памятью пользоваться, то мы получим непрерывную активность на диске (если своп достаточно большой).

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

Если усложнить эксперимент (возвести в абсолют) и сделать своп на дискетах, то считай всё, проще сделать аппаратный ребут, чем перебирать дискеты.

Никто не может заранее сказать, что запуская какую-то программу она не съест ОЗУ*2 памяти и не будет ею активно пользоваться, что аж все другие программы уйдут в своп.

На это тоже интересно было бы написать тест и посмотреть как поведёт себя система.

Впрочем, это не открытие америки. https://www.phoronix.com/scan.php?page=news_item&px=Linux-Do...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру