Spark не использует все доступные процессоры

Я выполняю запрос с использованием Hive on Spark, который демонстрирует странное поведение. Я запускал его несколько раз и наблюдал такое же поведение. Запрос:

  • читает из большой внешней таблицы Hive
  • Spark создает около 990 000 задач.
  • выполняется в очереди YARN с доступными ЦП > 2900
  • использует 700 исполнителей с 4 ЦП на исполнителя

Все хорошо в начале работы. После примерно 1,5 часов запуска 2800 процессоров задание завершено примерно на 80% (задачи 800 000/990 000). С этого момента все начинает падать: Spark перестает использовать все доступные ему процессоры для работы над задачами. При выполнении ~190 тыс. задач Spark постепенно уменьшится с использования 2800 ЦП до двузначного числа (обычно общее количество ЦП составляет около 20). Из-за этого последние 190 000 задач выполняются значительно дольше, чем предыдущие 800 000.

По мере того, как работа была очень близка к завершению, я мог видеть, что Spark не сможет распараллелить небольшое количество оставшихся задач на большом количестве процессоров. Но с учетом того, что осталось запустить 190 000 задач, для этого слишком рано.

Что я проверил:

  • Ни одно другое задание не использует свои ресурсы в YARN. (Кроме того, если бы это было так, я бы ожидал, что задание будет случайным образом терять / восстанавливать ресурсы, а не предсказуемо терять пар на отметке 80%).
  • Это происходит независимо от того, включено или отключено динамическое размещение. Если этот параметр отключен, Spark имеет все 2800 ЦП, доступных на все время выполнения задания, — просто не использует их. Если этот параметр включен, Spark отключает исполнителей, поскольку решает, что они ему больше не нужны.
  • Если бы проблема заключалась в перекосе данных, я бы увидел, что некоторые задачи занимают больше времени, чем другие. Но это не объясняет, почему Spark не будет использовать простаивающие процессоры для запуска невыполненных задач.

Есть ли у кого-нибудь совет?

Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
0
662
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Для потомков этот ответ от Трэвиса Хегнера содержал ответ.

Настройка spark.locality.wait=0s устраняет эту проблему. Я также не уверен, почему 3-секундное ожидание вызывает такое нагромождение способности Spark планировать задачи, но установка на 0 делает работу очень хорошей.

Другие вопросы по теме