После долгих поисков и прочтения связанных вопросов и статей мы обнаружили свойство maxAMShare для планировщика заданий YARN (мы используем Fair Scheduler).
Что это значит?
Процент памяти и ресурсов из общего ресурса очереди пользователя, который может быть выделен мастерам приложений.Значение по умолчанию: 0,5 (50%). Источник
Как это вызвало тупик?
Когда мы будем запускать несколько заданий oozie параллельно, каждое задание oozie и разветвленные действия требуют парыконтейнеров ApplicationMaster, которые должны быть выделены в первую очередь для пусковых установок oozie, которые затем запускают другие контейнеры для выполнения фактической задачи действия.
В нашем случае мы фактически начинали около 20-30 параллельных заданий, каждое с почти 20 разветвленными действиями.И для каждого действия, требующего 2 ApplicationMasters, около 800 контейнеров блокировались только Oozie ApplicationMasters.
Из-за этого мы достигли 50% -ного предела maxAMShare по умолчанию для нашей пользовательской очереди.И YARN не позволял создавать новые ApplicationMasters для выполнения фактического задания.
Решение?
Одним мгновенным предложением может быть отключение проверкиустановив это свойство в -1.0.Но это не рекомендуется.Вы можете снова распределить все или большую часть ресурсов для AM, и реальная работа, которая будет выполнена, будет намного меньше.
Другой вариант (с которым мы пошли дальше) - этоукажите отдельную очередь для AM в конфигурации oozie, а затем установите для свойства maxAMShare значение 1.0.Таким образом, вы можете контролировать, сколько ресурсов может быть выделено для AM, не влияя на другие задания. Ссылка
<global>
<configuration>
<property>
<name>oozie.launcher.mapred.job.queue.name</name>
<value>root.users.oozie_am_queue</value>
</property>
</configuration>
</global>
Надеюсь, что это будет основным временемзаставка для людей, сталкивающихся с той же проблемой.Там может быть много других причин тупика, которые уже обсуждались в других вопросах по SO.