Что на самом деле делает memoryReservation в ECS с Fargate? - PullRequest
1 голос
/ 27 июня 2019

ECS 'Определения контейнеров позволяют вам указать memoryReservation для каждого контейнера:

Мягкий предел (в МиБ) памяти, который нужно зарезервировать для контейнера. Когда системная память находится в состоянии конфликта, Docker пытается сохранить память контейнера до этого мягкого предела ; однако ваш контейнер может потреблять больше памяти при необходимости, вплоть до жесткого предела, заданного параметром памяти (если применимо), или всей доступной памяти в экземпляре контейнера, в зависимости от того, что наступит раньше. Этот параметр сопоставляется с MemoryReservation в разделе «Создание контейнера» в Docker Remote API и параметром --memory -servation для запуска docker ... Если вы укажете memoryReservation, то это значение будет вычтено из доступных ресурсов памяти для экземпляр контейнера, на котором расположен контейнер ; в противном случае используется значение памяти. Например, если ваш контейнер обычно использует 128 мегабайт памяти, но время от времени переходит в 256 мегабайт памяти в течение коротких периодов времени, вы можете установить memoryReservation 128 мегабайт и жесткий предел памяти в 300 мегабайт. Эта конфигурация позволила бы контейнеру резервировать только 128 МБ памяти из оставшихся ресурсов на экземпляре контейнера, но также позволяла бы контейнеру потреблять больше ресурсов памяти при необходимости.

Я полагаю, что это реализовано с помощью "мягких пределов cgroups ."

Таким образом, это означает, что в ECS + EC2 цель этого параметра состоит в том, чтобы позволить вам запланировать группу задач для экземпляра, которая, если бы они все одновременно использовали свою максимальную память, превысила бы общую доступную память на экземпляр, но вы предсказываете, что они не будут этого делать.

А как насчет ECS + Fargate? У Fargate размер задачи и объединенные жесткие ограничения (опция "memory") контейнеров задачи не могут превышать объем памяти задачи . [Эта последняя часть была неправильной; см. мой уточняющий ответ.] Вы оплачиваете в зависимости от размера задачи независимо от установленных вами ограничений памяти. Так какую выгоду вы могли бы получить, установив memoryReservation ниже вашего жесткого лимита?

Единственные возможности, о которых я могу думать:

  1. memoryReservation поручает AWS упаковать ваши контейнеры на меньшее количество базовых виртуальных машин, рискуя проблемами с производительностью без какой-либо выгоды для вас (так как цена такая же).
  2. AWS просто игнорирует memoryReservation для Фаргейта.

Я что-то упустил? Если нет, Амазонка говорит, какой из двух это?

Ответы [ 2 ]

0 голосов
/ 02 июля 2019

Теперь я понимаю, что в моем вопросе была неверная предпосылка:

У Fargate есть размер задачи, и объединенные жесткие ограничения (опция «память») контейнеров задачи не могут превышать размер памяти задачи.

Фактически, объединенные мягкие ограничения (опция «memoryReservation») не могут превышать объем памяти задач. Могут комбинированные жесткие ограничения. Таким образом, в Fargate вы могли запланировать несколько «пакетных» контейнеров в одной задаче, и один контейнер мог использовать всю доступную память задачи, прежде чем был убит. Это в некоторой степени похоже на то, чего вы можете достичь на экземплярах EC2, используя задачи с одним контейнером и memoryReservation.

Вам не нужно использовать memoryReservation для выполнения этого в Fargate (вы просто не можете устанавливать какие-либо ограничения памяти или резервирования сверх размера задачи). Таким образом, остается вопрос: зачем использовать эту настройку в Fargate? Я думаю, что лучшим ответом, вероятно, является ответ, предоставленный MasterFowl: намекнуть ядру, чтобы не позволить одному из ваших контейнеров занимать слишком много памяти задачи.

0 голосов
/ 01 июля 2019

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

...