Что представляет собой «незанятый» процессор при расчете кредита Ц2?

9

Документация для EC2 T2 "burstable" типов гласит:

Базовая производительность и способность к взлому определяются процессором. Каждый экземпляр T2 непрерывно получает кредиты ЦП с установленной скоростью, в зависимости от размера экземпляра. Экземпляры T2 накапливают кредиты ЦП, когда они простаивают , и используют кредиты ЦП, когда они активны. Кредит ЦП обеспечивает производительность полного ядра ЦП за одну минуту.

То, что я не понимаю, что означает бездействие ? Все экземпляры используют некоторый ЦП> 0%, поэтому есть ли показатель использования ЦП, при котором экземпляр считается «бездействующим»?

Удивительно, но учитывая либеральное использование этого термина, я нигде не могу найти определение «бездействия».

amazon-ec2

— Дэн Гравелл
источник

7

Хороший вопрос, документация по Amazon EC2 для кредитов ЦП в экземплярах T2 здесь может быть более точной - вступительное сообщение в блоге Новые недорогие экземпляры EC2 с быстродействующей производительностью дает лучшее объяснение, см. Таблицу в середине:

Столбец, помеченный как «Базовая производительность», указывает процент производительности одного ядра базового физического ЦП, выделенного для экземпляра. Например, экземпляр t2.small имеет доступ к 20% одноядерного процессора Intel Xeon, работающего на частоте 2,5 ГГц (до 3,3 ГГц в турбо-режиме). T2.medium имеет доступ к 40% производительности одного ядра, которое вы (или, если быть более точным, ваша операционная система) можете использовать на одном или обоих ядрах в зависимости от спроса.

Столбец, помеченный как «Credits / Hour CPU», показывает частоту кредитов CPU, которые экземпляр T2 получает каждый час. Кредиты ЦП накапливаются, когда экземпляр не использует базовое распределение ЦП, и расходуются, когда экземпляр активен . Неиспользованные кредиты ЦП хранятся до 24 часов. [Акцент мой]

— Штеффен Опель
источник

4

Отлично, так, например, в случае T2.small, базовый уровень которого составляет 20% ЦП, когда он ниже 20%, мы зарабатываем с фиксированной ставкой, когда он выше, мы тратим с переменной ставкой согласно документам. aws.amazon.com/AWSEC2/latest/UserGuide/…

— Дэн

1

Точно - этот прозрачный подход (включая соответствующие метрики CloudWatch ) является довольно значительным и конкурентным улучшением по сравнению с предыдущей моделью регулирования для соответственно печально известных t1.microслучаев.

— Штеффен Опель

@DanGravell, вы зарабатываете с переменной скоростью "Например, если бы у экземпляра t2.small загрузка ЦП составляла 5% в час, он бы использовал 3 кредита ЦП (5% от 60 минут), но он бы заработал 12 кредитов ЦП в течение часа, поэтому разница в 9 кредитов ЦП будет добавлена к кредитному балансу ЦП "

— Пол Дрейпер

2

Общеизвестно, что «простоя» вообще сложно определить для серверов Linux. На общем уровне простоя должно быть любое время, не затрачиваемое на пользовательский режим, системный режим, режим с низким приоритетом, ожидание ввода-вывода или прерывания - со специальным условием, обеспечивающим правильный тип рабочей нагрузки, время ожидания ввода-вывода может быть преобразовано во время пользовательского режима (для другого процесса).

Тем не менее, в вопросе простоя AWS t2 это не имеет места. Это также не относится к t1 (из-за «украденного» времени), но даже это не объясняет поведение t2. Я сталкивался со сценариями, в которых время простоя (как сообщают и топ Linux, и AWS CloudWatch) намного выше задокументированных пороговых уровней, но в данном случае экземпляр теряет кредиты ЦП, а не получает их. Я считаю, что это ошибка бухгалтерского учета на стороне Amazon, и пока она не будет исправлена, слишком усердно пытаться понять, как определяются загрузка процессора и время простоя, будет пустая трата времени.

Я разместил несколько иллюстративных диаграмм на форумах поддержки AWS, где, надеюсь, они ответят. https://forums.aws.amazon.com/thread.jspa?messageID=568026#568026

— осма
источник

У нас может быть та же проблема со средним экземпляром для обработки почты. Кредиты накапливались линейно, без использования вообще, и теперь развернуты, наблюдается постепенное снижение даже при максимальном использовании в 5-минутных сегментах менее 1%. Может случиться так, что порог простоя составляет небольшую долю в 1%, но это не сделает полезными экземпляры. Ответы от Amazon на ваш тикет и другие предполагают, что расчет кредитов работает не так, как задумано.

— Ник

Персонал Amazon опубликовал объяснение системы, которое представляется более сложным, чем можно предположить из документации: не только существует максимальный баланс кредитов для каждого типа экземпляра T2, но и кредиты, заработанные 24 часа назад, истекают из баланса. Таким образом, t2.small будет зарабатывать 12 кредитов в час, поддерживая максимальный баланс в 288 кредитов, но ТАКЖЕ любые кредиты, которые он заработал 24 часа назад, будут вычтены из баланса. Это означает, что экземпляры старше 24 часов потеряют кредиты быстрее, чем вы ожидаете, и долгосрочный баланс, вероятно, будет ближе к первоначальному, чем к максимальному значению.

— Osma

@osama спасибо за добавление этого. Из графиков я подозреваю, что есть еще кое- что, но это работает для нас на данный момент, что имеет значение :) Мы увеличили среднюю нагрузку на среду с пятницы и смотрим, что происходит сейчас.

— Ник

0

Это что-то вроде ниже

Если вы используете микроэкземпляр, который работает на одном ядре максимум 10%. Предположим, что настало время, когда ваш сервер потребляет 5% от одного ядра, поэтому он считает оставшиеся 5% вычислительной мощности простаивающими. Эти 5% продолжают накапливаться вне курса только в течение 24 часов. Теперь, если у вас есть это накопление и имеется ввиду, когда ваш сервер испытывает потребность в вычислительной мощности, он может заимствовать эту накопленную вычислительную мощность. Для этой вычислительной мощности они использовали причудливое слово под названием CPU Credits.

Я погуглил и нашел хорошее объяснение в каком-то блоге http://themindtracks.com/amazon-launches-new-low-cost-ec2-instances-burstable-performance/

— Ачал Сарайя
источник