AWS Пакетное задание застряло в рабочем состоянии - PullRequest
6 голосов
/ 30 мая 2020

Я пытаюсь запустить пакетное задание на 100 узлов AWS, когда я настраиваю свою вычислительную среду на использование только экземпляров m4.xlarge и m5.xlarge, все работает нормально, и моя работа подбирается и выполняется.

Однако, когда я начинаю включать в свою вычислительную среду другие типы экземпляров, такие как m5.2xlarge, задание застревает в состоянии runnable на неопределенный срок. Единственная переменная, которую я изменяю в этих обновлениях, - это типы экземпляров в вычислительной среде.

Я не уверен, почему это задание не выполняется, когда я включаю другие типы экземпляров в вычислительную среду. В документации для Параметры вычислительной среды единственное примечание:

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

JobDefinition является многоузловым:

  • Node 0
    • виртуальных ЦП: 1
    • Память: 15360 МБ
  • Узел 1:
    • виртуальных ЦП: 2
    • Память: 15360 МБ

Максимальное количество виртуальных ЦП в моей вычислительной среде установлено на 10,000, всегда находится в состоянии VALID и всегда ENABLED. Также мой предел виртуальных ЦП EC2 составляет 6,000. CloudWatch не предоставляет журналов, потому что задание еще не началось, я не знаю, что еще здесь попробовать. Я также не использую настройку optimal для типов экземпляров, потому что у меня возникли проблемы с получением достаточного количества экземпляров.

1 Ответ

4 голосов
/ 01 июня 2020

Я только что решил эту проблему, проблема связана со стратегией BEST_FIT в пакетном режиме. Задания, которые я отправляю, недостаточно близки к типу экземпляра, поэтому они никогда не подбираются.

Я понял это, изменив определение задания на использование 8 vCPU and 30GB памяти, и задание началось с m5.2xlarge экземпляров.

Я собираюсь посмотреть, решит ли эта проблема использование стратегии BEST_FIT_PROGRESSIVE и доложу об этом, хотя я сомневаюсь, что это так.

-

Обновление: я поговорил с AWS Службой поддержки и получил дополнительную информацию. Стратегия распределения BEST_FIT_PROGRESSIVE имеет встроенную защиту от чрезмерного масштабирования, чтобы клиенты случайно не запустили тысячи экземпляров. Хотя это имеет побочный эффект того, что я испытываю, что приводит к тому, что задания не запускаются.

Инженеры службы поддержки рекомендовали использовать один тип экземпляра в Compute Environment и стратегию распределения BEST_FIT. Поскольку у моих заданий разные требования к экземплярам, ​​я смог успешно создать три отдельных ComputeEnvironments, нацеленных на разные типы экземпляров (c5.large, c5.xlarge, m4.xlarge), отправить задания и запустить их в соответствующей Compute Environment.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...