Недостатки запуска рабочего сервера AWS на 100% ЦП

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

В AWS избегайте экземпляров серии T, если вы используете 100% ЦП, поскольку они дают частичный ЦП. По сравнению с распределением ЦП дешевле получить виртуальную машину M (общего назначения) / C (интенсивные вычисления) / другую серию для выделенного ЦП, чем использовать «T2 / T3 без ограничений».

Чтобы ответить на комментарий, AWS (и я предполагаю, что другие ведущие облачные провайдеры) не имеют политики «добросовестного использования» для ЦП, которая, как правило, исходит от поставщиков низкого уровня или общих хостов. Если вы платите за ядро, вы можете использовать ядро ​​на 100%. Если ваши инстансы используются недостаточно, сервис AWS Trusted Advisor рекомендует меньшие инстансы, чтобы помочь вам сэкономить деньги.

Очевидно, что локально вы можете делать все, что захотите. Это обычный ответ, который применим к облаку, в частности к AWS.

Независимо от того, хорошо или нет, работает на 100% CPU означает, что вы не обрабатываете свои задания так быстро, как могли бы, если бы у вас было больше ЦП. Вся система действительно тормозит. Единственное, что делает для вас, это позволяет указать, какие процессы имеют более высокий или более низкий приоритет и должны иметь больше или меньше вашего и без того ограниченного ЦП.

Если ваши задания выполняются медленнее, чем вы ожидаете, Единственное, что будет иметь какое-либо существенное значение, - это дать им больше процессора. Если вы возьмете это с другой работы, то эта работа замедлится. Если вы обновите свой процессор, все будет работать быстрее. Конечно, поскольку это EC2, вы можете просто добавить больше экземпляров.

Да, работа со 100% ЦП - это нормально, здесь нет необходимости использовать nice , который только снижает приоритет процессов по сравнению с обычными процессами, которых у вас нет .

Если это только вычислительные процессы с определенным концом и никакой интерактивности не ожидается, я бы пошел еще дальше и использовал бы SCHED_BATCH , который увеличивает временные интервалы до более секунды и в более короткие сроки. Ситуация с памятью отдает приоритет достижению прогресса по сравнению со справедливостью в планировании, исходя из предположения, что процессы в конечном итоге завершаются и освобождают всю свою память, если вы даете им больше процессорного времени.

Зависит

Некоторые рабочие нагрузки, такие как машинное обучение, трехмерный рендеринг, транскодирование мультимедиа, майнинг криптовалюты, предназначены для работы со 100% ЦП (*). Эти типы рабочих нагрузок часто оптимизируются, чтобы разделить их задачи на блоки одинаковой формы и использовать 100% каждого конвейера команд каждого ЦП в коробке. Если в таких случаях вы будете говорить о 100% загрузке ЦП, ваши коллеги подумают, что вы идиот. В вашем вопросе не упоминается какая-либо из этих специализированных рабочих нагрузок, поэтому читайте дальше.

С другой стороны, для общих бизнес-нагрузок вы часто имеете дело с чрезмерно сложным и плохо написанным программным обеспечением, которое должно обрабатывать задачи в блоках неправильной формы прибытие с непредсказуемыми интервалами. Для этого типа рабочей нагрузки нехватка ЦП может привести к нестабильности системы и смертельной спирали из-за «сопутствующих заболеваний». Некоторые из этих «сопутствующих заболеваний» включают непредсказуемое использование памяти, соединения с базой данных, блокировку базы данных и конфигурации тайм-аута.

Пример: Предположим, у вас есть процесс, который занимает две минуты, когда у него есть 100% ЦП для сам по себе, но время увеличивается до 10 минут, когда ему приходится делить ЦП с четырьмя другими процессами. Теперь предположим, что каждый процесс поддерживает соединение с внешней базой данных все время, пока он запущен, а пул соединений повторно использует соединения старше 10 минут. А затем ...

BZZZZZ.

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

(*) Давайте проигнорируем GPU-связанных рабочих нагрузок на данный момент, это будет совершенно новый вопрос.

Нет проблем в 100% запуск ЦП.

Даже в том маловероятном случае, когда у вашего конкретного оборудования возникла проблема с охлаждением, приводящая к перегреву, поскольку это сервер AWS, это будет проблемой Amazon, а не вашей (будьте уверены, они взяли это учтено в их модели ценообразования)

Если бы он не выполнял эту работу, он бы сидел без дела, поэтому, если вам нужно выполнить $ job, лучше пусть он это сделает. Вы не хотите его искусственно ограничивать.

Основным недостатком будет использование ЦП постоянно на 100%, потребуется больше энергии. Но вы же хотели, чтобы эта задача была выполнена, верно? ¹

(¹ Обратите внимание, что в некоторых случаях, например, при майнинге биткойнов, стоимость электроэнергии выше, чем стоимость добытых биткойнов)

Во-вторых, если процессор системы полностью загружен используется на 100% для выполнения какой-то не слишком важной задачи (например, обработки пакетов SETI), может случиться так, что прибыло что-то более важное (например, интерактивный запрос владельца), но компьютер не обращает на это внимания очень быстро потому что он был занят обработкой этих пакетов. Это решается обращением внимания на менее важную задачу. Тогда система узнает, как расставить приоритеты, и вы избежите этой проблемы.

В некоторых местах вы можете увидеть, что плохо иметь сервер, работающий на 100%. Сервер с CPU на 100% показывает узкое место в процессе. Вы можете производить больше с большим количеством процессоров или более быстрыми, но пока вы достаточно довольны пропускной способностью, все в порядке. Вы можете думать об этом как о магазине, где все клерки всегда заняты. Это, вероятно, плохо, так как больше клиентов не могут делать там покупки, поскольку их невозможно обслужить.

Однако, если у нас есть склад с товарами для сортировки, без особых сроков и достаточным объемом работы на следующие 5 лет, вы хотите, чтобы все работали над этим полный рабочий день, а не заставляли кого-то бездельничать.

Если склад находится рядом с магазином, вы можете комбинировать вещи: у вас есть клерки, обслуживающие клиентов, а когда есть клиентов не осталось, они заранее сортируют склад, пока не прибудет следующий клиент.

Традиционно у вас есть определенное выделенное оборудование, и вы должны использовать его более или менее. Однако в такой модели, как AWS, у вас есть больше возможностей. (Примечание: я предполагаю, что ваша задача состоит из множества небольших, легко распараллеливаемых фрагментов)

• Используйте один экземпляр размера X столько, сколько необходимо
• Используйте более быстрый экземпляр размера X + n
• Используйте более медленный, но более дешевый экземпляр, требующий больше времени
• Использование нескольких экземпляров

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

Кроме того, затраты не фиксированы. Вероятно, вы получите выгоду, запустив дополнительные экземпляры в нерабочее время, когда они дешевле, но сократите их, когда это будет дороже. Предположим, вы смогли одолжить клерку в ближайшем магазине (по определенной переменной ставке). Круглосуточный магазин мог бы с радостью позволить вам, чтобы сотрудник, работающий в ночную смену, довольно дешево отсортировал некоторые из ваших складских товаров, поскольку мимо пройдет лишь горстка покупателей. Однако, если вам нужна дополнительная пара рук в Черную пятницу, это будет намного дороже. (на самом деле, лучше, чтобы в этот день никто не покидал сортировку склада)

AWS позволяет выполнять большую динамическую нагрузку, а когда вам не нужно отвечать в X-времени, вы можете заметно оптимизировать свои расходы. Однако у них «слишком много вариантов», и их сложно понять. Вам также необходимо хорошо понимать свою рабочую нагрузку, чтобы принимать правильные решения.