LINUX.ORG.RU
решено ФорумAdmin

килять 100% cpu бинарники из баша

 , , , ,


1

1

есть ли какой-то стандартный способ
подход
как килять процесс который ест 100% cpu?

могу конечно навелосипедить на баше

★★★★★

Последнее исправление: smilessss (всего исправлений: 2)

Стандартного способа нет, так как поведение программы при котором она ест 100% проца и ее нужно килять — не является нормальным.

Если очень нужно то monit имеет такое. Если лень разбираться с ним — пиши скриптик на 10 строк.

iron ★★★★★
()

есть ли какой-то стандартный способ

Есть - отказаться от ущербного подхода к архитектуре. Перестать задалбывать вопросами по XY-проблемам и не слушать советы.

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

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)

Не знаю в тему ли, но у меня повешен на хоткей xkill. Когда приложение вдруг перестает реагировать на действия - жму хоткей, указатель мыши меняется на красивый ☠️, далее ЛКМ по зависшему окну.

Обычно проблема решается перезапуском приложения.

krasnh ★★★
()
Ответ на: комментарий от smilessss

что неужели никто не сделал тулзу как omm только для cpu

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

monkdt
()
Ответ на: комментарий от smilessss

И при этом не один не будет жрать 100% времени процессора, если только у вас там не 10000 cpu.

ИМХО, если уж килять, то те процессы, которые всё время в состоянии (R)unning.

mky ★★★★★
()
Ответ на: комментарий от smilessss

что неужели никто не сделал тулзу как omm только для cpu

Не сделали по причине «ненужно». Если что-то кушает 100% CPU значит оно ему нужно, и это нормально, однако это не значит, что все остальные процессы простаивают в это время.

anc ★★★★★
()
Ответ на: комментарий от alex1101

10 тысяч процессов свидетельствуют об архитектурной ошибке

Та пускай себе экспериментирует. Человек познает мир.

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

iron ★★★★★
()
Ответ на: комментарий от mky

они начинают есть 100 только если фризятся
я буду на баше велосипедить

top -b -n1 | grep binary_name | awk '{print $1,int($9)}' 


осталось нагуглить как сравнивать второй столбец с 90 и если если true то передавать в kill pid

smilessss ★★★★★
() автор топика
Ответ на: комментарий от monkdt
top -b -n1 | grep binary_name | awk '{print $1,int($9)}' 



осталось нагуглить как сравнивать второй столбец с 90 и если если true то передавать в kill pid

smilessss ★★★★★
() автор топика
Последнее исправление: smilessss (всего исправлений: 1)

Поддержу тех, кто говорит что это плохая идея.

Причиной беспокойства по CPU является

  1. большой load average - больше количества ядер
  2. большой steal rate - больше 5%, это если у тебя виртуальная машина

В остальных случаях нужно сначала смотреть на другие показатели. Например, свопирование, проблемы с дисковым IO, да и вообще с железом/драйверами, zombie-процессы (хотя ЕМНИП такие процессы CPU не потребляют, но индикацией проблемы являются) и т. п.

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

Kroz ★★★★★
()
Ответ на: комментарий от anc

как nice/renice может заставить бинарник не есть 100% cpu?

думаете 10000 процессов которые едят 100% cpu можно заставить не фризать систему изменением их приоритета?

smilessss ★★★★★
() автор топика
Ответ на: комментарий от smilessss

думаете 10000 процессов которые едят 100% cpu можно заставить не фризать систему изменением их приоритета?

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

anc ★★★★★
()