The OpenNET Project / Index page

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



"Выпуск обработчика нехватки памяти earlyoom 1.4"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Выпуск обработчика нехватки памяти earlyoom 1.4" +/
Сообщение от пох. (?), 03-Мрт-20, 16:55 
> Не троянской программы, а ошибочной программы

ошибки обычно иначе выглядят - вот типичная ошибка (в днк разработчика):

  1960 mysql     20   0 5544180 1.873g  11088 S   6.0  9.6   1566:00 mysqld
в конце-концов она устанет от такой жизни, задумается о вечном и перестанет откликаться на раздражители (виснет только один из тредов, но об него локаются запросы и рецепт все равно один)
- после чего будет просто прибита и перезапущена.

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

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

Система - виртуалка с обычной убунтой, xeon e5, диски живут на промышленной СХД, но она об этом счастливо не в курсе, живут на ней репо прода и самой убунты, поэтому нагрузка в штатном режиме ровно ноль, никаких особо специальных настроек нет.

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

15:49:18 up 208 days, 23:28,  2 users,  load average: 3.95, 1.22, 0.42
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
user      pts/0    192.168.6.4      15:47    1:17   1:04  55.70s ./a.out
user      pts/1    192.168.6.4      15:48   11.00s  2.08s  0.50s w
linups:~> free
              total        used        free      shared  buff/cache   available
Mem:        8209956     8071716       46580          44       91660       46520
Swap:      10483708     7880952     2602756

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

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

Оглавление
Выпуск обработчика нехватки памяти earlyoom 1.4, opennews, 02-Мрт-20, 20:25  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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