Spark: не влияет количество ядер на исполнителей на время выполнения приложения

Я тестирую влияние различного количества ядер на исполнителей (--executor-cores) на время выполнения SVD на Spark. При фиксированном --executor-cores количество разделов RDD основных данных изменяется. Однако, похоже, не происходит значительного изменения времени вычислений SVD для разных --executor-cores для заданного количества разделов RDD. Это немного сбивает с толку.

Моя среда:

  • Кластер Spark с 3 узлами (32 ядра и 32 ГБ памяти на узел). На каждом узле работает 1 рабочий.
  • spark.max.cores = 96
  • Менеджер кластера = Standalone
  • режим развертывания = client

Я нанес на график результаты для --executor-cores = [4, 16], и, как можно видеть, для данного размера раздела нет большой разницы между временем вычисления при увеличении размера раздела. Итак, мои вопросы:

  • Каков эффект от установки количества ядер на исполнителя?
  • Количество ядер на исполнителя оказывает значительное влияние на время выполнения, но только для небольших размеров разделов, а не для больших, почему?
  • Это как-то влияет на параллелизм (я не уверен)?

введите здесь описание изображения


apache-spark parallel-processing apache-spark-mllib svd
person user3557405    schedule 03.12.2015    source источник
comment
каков размер ваших данных?   -  person eliasah    schedule 03.12.2015
comment
Это 560 МБ с ~ 20 миллионами записей. Каждая запись соответствует элементу матрицы, и SVD вычисляется для этой очень разреженной матрицы (234934 x 140214).   -  person user3557405    schedule 03.12.2015
comment
1. Это не так уж много данных для обработки, поэтому тест бесполезен. 2. Количество разделов огромно по сравнению с входными данными, лучше сосредоточьтесь на размере раздела.   -  person eliasah    schedule 03.12.2015
comment
Добавьте к этому ответ Денниса, который на самом деле очень хорош!   -  person eliasah    schedule 03.12.2015
comment
Как упоминалось в ответе Деннису, я попробую с большим набором данных.   -  person user3557405    schedule 04.12.2015

Ответы (1)


arrow_upward
5
arrow_downward

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

  1. Вывоз мусора; задачи в одном и том же пространстве процесса теперь больше влияют друг на друга во время выделения памяти / сборки мусора как узкое место общего конфликта.
  2. Общие клиенты, такие как клиент HDFS, могут иметь проблемы с конкуренцией при использовании большого количества потоков.
  3. Общие пулы, такие как потоки akka, могут быть превышены по подписке из-за слишком большого количества параллельных задач в процессе.
  4. Любые совместно используемые структуры данных, требующие синхронизации, означают, что больше рабочего времени тратится на переключение контекста потока и ожидание блокировок; сюда входят такие вещи, как отчеты по показателям

С другой стороны, преимущества добавления большего количества ядер на исполнителя включают:

  1. Снижение накладных расходов памяти на каждого исполнителя; Если вам нужен определенный объем памяти для каждой задачи, теоретически вы можете упаковать больше параллельных задач на машину с помощью одного очень большого исполнителя по сравнению с множеством мелких исполнителей.
  2. Совместное пространство памяти становится большим преимуществом для таких вещей, как широковещательные переменные / данные.

Многие из этих компромиссов и конкретных цифр, особенно в отношении недостатков слишком больших исполнителей, объясняются в это сообщение в блоге Cloudera.

В случае небольшого количества разделов, теоретически с меньшим количеством разделов, чем количество исполнителей, производительность должна быть лучше или равной с более крупными исполнителями, если задачи распределены между разными исполнителями одинаково хорошо в каждом кейс. Однако если упаковка задач перекладывает их все на одного исполнителя, то это просто зависит от загруженности; Материал с тяжелым перемешиванием может выиграть от того факта, что все обрабатывается локально, но материал с тяжелым вводом-выводом HDFS будет страдать от конкуренции.

person Dennis Huo    schedule 03.12.2015
comment
Спасибо за подробный ответ. Я буду работать над этим больше и доложу о результатах. - person user3557405; 04.12.2015
comment
@ user3557405 Если этот ответ отвечает на ваш вопрос, вы должны принять его. В противном случае некоторые отзывы могут быть полезны. - person zero323; 25.04.2016
comment
Большие исполнители (больше ядер) также имеют преимущество, заключающееся в том, что задачи могут совместно использовать пространство памяти, поэтому это не только преимущество для широковещательных переменных. Каждый раз, когда вы пересекаете границу JVM, вы вводите накладные расходы на процесс связи, потенциально также пересекая границу физического узла. - person YoYo; 11.10.2017
comment
Всякий раз, когда я читаю MySQL таблицу, используя метод spark.read.jdbc(..numPartitions..) с dynamicAllocation=false, я обнаруживаю, что общее количество ядер (ядер на executor X количество executors) и количество запросов, сделанных к MySQL в данный момент равны. Итак, с 15 executor по 3 ядра в каждой, 45 запросов одновременно попадают в мою MySQL базу данных; что заставляет меня думать, что каждое ядро ​​обрабатывает один раздел. Однако с dynamicAllocation=true некоторые из исполнителей выполнили 4 запроса, что тогда кажется странным. - person y2k-shubham; 16.04.2018