Apache Spark executor использует более одного ядра, несмотря на spark.executor.cores = 1

1

Когда я запускаю приложение Apache Spark 1.2.1 на CentOS 6.5, я получаю более 100% нагрузки для исполнителей в соответствии с "верхним" выходом, а средняя загрузка значительна больше, чем количество ядер.

В результате у меня большая нагрузка на сборщик мусора.

  • Попробовали ограничить ядра на каждого исполнителя с помощью spark.executor.cores=1.
  • Попробовали spark.cores. Никакого эффекта.
  • Аппаратное обеспечение - 2 x Intel (R) Xeon (R) CPU E5-2620 v2 @2.10GHz, 6 физических ядер, каждый из которых имеет 12 ядер процессора на узел.
  • Модель развертывания - клиент YARN.

Аналогичная установка Ubuntu 14.04 с 4 физическими ядрами (Intel i5) не имеет проблем, 1 ядро на каждого исполнителя.

Любая идея, как это исправить?

Подача заявки выполняется из кода со всеми необходимыми свойствами, установленными через System.setProperty а затем создаются конфигурация и контекст Spark. Это делается точно так же, единственной возможной разницей может быть набор свойств конфигурации Spark, который является для каждого кластера, но нет ничего особенного. В Ubuntu с 4 ядрами i5 это приводит к правильной нагрузке не более чем с 1 ядром, используемой каждым исполнителем. В CentOS 6.5 с 2x6 ядрами E5 я вижу более одного ядра, используемого для каждого исполнителя. Более того, я попытался применить 4-ядерную конфигурацию i5 к E5 и не имел успеха.

содержимое файла spark-defaults.conf (до замены заменой искры, которая в настоящее время является 1.2.1):

spark.master=yarn-client
spark.eventLog.enabled=true
spark.eventLog.dir=hdfs:///user/spark/applicationHistory
spark.yarn.historyServer.address=X.X.X.X:18088
spark.executor.memory=1650M
spark.executor.cores=1
spark.cores.max=4
spark.executor.instances=15
spark.shuffle.memoryFraction=0.2
spark.storage.memoryFraction=0.02
spark.yarn.jar=hdfs:///user/spark/share/lib/${spark.version}/spark-assembly.jar

Основная проблема здесь: я вижу, что 2 x 6 ядер E5 имеют более низкую производительность, чем линейные 1 i5 x 4 ядра. Да, E5 несколько старше, но в любом случае он должен быть более мощным. И все же проанализировал пользовательский интерфейс сервера истории Spark при одинаковой нагрузке на оба кластера, я вижу заметное больше времени, потраченного на GC на кластере E5. Сумасшедшее состояние.

  • 0
    Как вы отправляете?
  • 1
    Я бы не посмотрел на среднюю нагрузку. Это длина работоспособной очереди. Вы больше заинтересованы в использовании процессора процессом executor. Я бы рекомендовал смотреть на это с помощью VisualVM. Он также расскажет вам, как он использует процессор.
Показать ещё 2 комментария
Теги:
performance
apache-spark
yarn
parallel-processing

2 ответа

1
Лучший ответ

Хорошо, в конце я нашел:

  1. На самом деле у меня было просто неправильное понимание "загрузки процессора". Более 100% означает только длину очереди выполнения.
  2. Распределение ядер процессора было правильным. 1 ядро было выделено для каждого исполнителя, которого требовали.
  3. Основываясь на профилировании GC, включенном для исполнителей Spark, а затем просмотре кода работы, было обнаружено, что причиной является просто неоптимальное копирование некоторых объектов. Код был скорректирован, чтобы быть более скудным с точки зрения управления памятью.

Таким образом, резолюция была:

Когда вы видите более 100% нагрузки на ядро процессора под исполнителем Spark, вы должны сначала проверить свои журналы регистрации GC для неэффективных операций с интенсивной памятью или, по крайней мере, сократить время жизни некоторых объектов за счет более агрессивного выпуска ресурсов.

Поделиться
0

Вы запрашиваете больше исполнителей, чем у вас есть ядра процессора, которые, если вы думаете об этом, должны быть невозможны. Однако модель YARN по умолчанию должна рассматривать только ОЗУ как ограничивающий фактор (с использованием DefaultResourceCalculator), и он с радостью будет делиться ядрами процессора между несколькими исполнителями "1 ядро", что фактически приводит к загрузке, превосходящей 1 на ядрах ЦП. Вы можете использовать DominantresourceCalculator, чтобы избежать этого :)

Поделиться
  • 0
    Нет. Этот кластер содержал 4 узла, каждый с 4 ядрами. 1 ядро ушло в мастер приложений, так что все было правильно.
  • 0
    Да, но пряжа будет по-прежнему распределять узел на узел, пока память каждого узла не заполнится. Если вы можете перепроверить, есть вероятность, что некоторые узлы были использованы недостаточно, а другие переполнены.
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню