Исходное сообщение
"Выпуск обработчика нехватки памяти 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 ядер там больше и нету, все что есть - съело. В целом - не вижу на этом вырожденном случае какого-то особо неправильного поведения системы.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Не троянской программы, а ошибочной программы > ошибки обычно иначе выглядят - вот типичная ошибка (в днк разработчика): > 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 > ядер там больше и нету, все что есть - съело. В целом > - не вижу на этом вырожденном случае какого-то особо неправильного поведения > системы.
	Введите код, изображенный на картинке: