LINUX.ORG.RU

Что будет при очень высоком cpu load? [вопрос про load average]

 ,


0

1

Что будет, если в очереди на обработку процессором накопятся много задач? Допустим, CPU Load (load average) на одно ядро увеличится до 30-50. ОС начнёт зависать, подключиться к ней по ssh станет невозможным.

А что дальше? Есть ли какой-то механизм очистки очереди в составе ОС? Или система так и будет умирать, и единственное спасение — ребут?

★★★

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

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

leave ★★★★★
()

load average и CPU Load - разные штуки. Вроде бы, вопрос про load average поставлен более-менее правильно, но вставка про CPU Load совершенно неуместна - да хоть все ядра по 100%, LA может быть, при этом, вполне нормальным, а система - отзывчивой.

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

Да, вопрос именно про load average, поправил заголовок.

Просто из-за Nagios возникла у меня такая путаница. В Nagios есть разделение на CPU Load (под этим там подразумевается load average, очередь) и CPU utilization (именно нагрузка, от 0 до 100%).

iljuase ★★★
() автор топика

load average 30-50

Ничего. Капец приходит от i/o, процессор нужно загрузить форк-бомбой и подождать, чтобы что-то начало происходить.

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

Ну да, и от нехватки памяти.

anonymous
()

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

Механизма, подобного OOM Killer'у, для случая большого LA нет, насколько я знаю. Что делать - ну, например, через SysRq прибить всё, дальше по ситуации.

tiandrey ★★★★★
()

Допустим, CPU Load (load average) на одно ядро увеличится до 30-50

В зависимости от архитектуры, но в общем случае c одним CPU, ядром с таким la, скорей всего все будет очень медленно. Хотя я заходил на atom (два ядра) c la 110 по ssh как-то (заняло 30 минут, чтобы зайти). Для этого и нужен мониторинг и своевременные оповещения, чтобы ты просто не довел до такой ситуации.
Впрочем, если что если ты точно знаешь что убить, то можно из такой ситуации вывести в реальном времени вручную, вполне. Алсо, для многопроцессорных систем, и в зависимости от проекта, la 30 может быть и вполне повседневным. И да если ты уже до такого довел, то с 2FA будет намного трудней подключиться по ssh, ну и в зависимости от настройки failban/sshguard, тебя может вполне заблокировать.

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

Это если заранее обо всём подумать и cgroups настроить. Но энивей в ситуации с большой очередью на I/O (особенно со свопом) жить будет очень печально. Если проблем с I/O нет, то это вполне себе решение, да.

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

Я больше о ситуации, когда не сможет запуститься шелл, хотя и тогда остается ssh -T.

Как поможет опция -T, если закончилась память и не может запуститься шелл?

bigbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.