Жесткие и мягкие ограничения памяти задач AWS ECS
Меня смущает цель наличия как жестких, так и мягких ограничений памяти для определений задач ECS.
IIRC мягкий предел - это то, сколько памяти планировщик резервирует на экземпляре для выполнения задачи, а жесткий предел-это то, сколько памяти может использовать контейнер, прежде чем он будет уничтожен.
Моя проблема заключается в том, что если планировщик ECS распределяет задачи по экземплярам на основе мягкого предела, может возникнуть ситуация, когда задача, использующая память выше мягкого предела, но ниже жесткий предел может привести к тому, что экземпляр превысит свой максимальный объем памяти (при условии, что все другие задачи используют память немного ниже или равную их мягкому пределу).
Правильно ли это?
Спасибо
1 ответ:
Если вы рассчитываете выполнить вычислительную нагрузку, которая в основном связана с памятью, а не с ЦП, то следует использовать только жесткий предел, а не мягкий предел. Из документов:
В определениях контейнеров необходимо указать ненулевое целое число для одного или обоих элементов memory или memoryReservation. Если вы зададите оба параметра, объем памяти должен быть больше, чем объем памяти, сохраняемой в памяти. Если указать memoryReservation, то это значение вычитается из доступных ресурсов памяти для экземпляра контейнера на который помещается контейнер; в противном случае используется значение памяти.
Http://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html
Указывая только жесткий лимит памяти для ваших задач, вы избегаете исчерпания памяти, потому что ECS перестает размещать задачи на экземпляре, а docker убивает любые контейнеры, которые пытаются превысить жесткий лимит.
Функция ограничения мягкой памяти предназначена для приложений, связанных с процессором, где вы требуется зарезервировать небольшой минимум памяти (мягкий предел), но разрешить случайные пакеты вплоть до жесткого предела. В этом типе загруженности ЦП вы действительно не заботитесь о конкретном значении использования памяти для контейнеров, потому что контейнеры будут работать из ЦП задолго до того, как они достигнут исчерпания памяти экземпляра, поэтому вы можете размещать задачи, основанные на резервировании ЦП и ограничении мягкой памяти. В этой установке жесткий предел является просто безотказным в случае, если что-то выходит из-под контроля или произошла утечка памяти.
Таким образом, вы должны оценить свою рабочую нагрузку с помощью нагрузочных тестов и посмотреть, имеет ли она тенденцию заканчиваться из процессора в первую очередь или из памяти в первую очередь. Если вы привязаны к процессору, то вы можете использовать ограничение мягкой памяти с дополнительным жестким ограничением просто как отказоустойчивый. Если вы привязаны к памяти, то вам нужно будет использовать только жесткий предел без мягкого предела.