Как настроить номер исполнителя искры, ядра и память исполнителей?

Question

С чего вы начинаете настраивать вышеупомянутые параметры. Мы начинаем с памяти исполнителя и получаем количество исполнителей, или начинаем с ядер и получаем номер исполнителя. Я последовал за link. Однако получил идею высокого уровня, но все еще не уверен, как и где начать и прийти к окончательному выводу.

Answer 1

Следующий ответ охватывает 3 основных аспекта, упомянутых в заголовке - количество исполнителей, память исполнителя и количество ядер. Могут быть и другие параметры, такие как память драйвера и другие, которые я не рассматривал как ответ, но хотел бы добавить в ближайшем будущем.

Случай 1 Оборудование - 6 узлов, а каждый узел 16 ядер, 64 ГБ ОЗУ

Каждый исполнитель является экземпляром виртуальной машины Java. Таким образом, мы можем иметь несколько исполнителей в одном узле

Первые 1 ядро ​​и 1 Гб необходима для операционной системы и Hadoop Демонов, поэтому доступно 15 ядер, 63 ГБ оперативной памяти для каждого узла

Start с тем, как выбрать количество ядер:

Number of cores = Concurrent tasks as executor can run 

So we might think, more concurrent tasks for each executor will give better performance. But research shows that 
any application with more than 5 concurrent tasks, would lead to bad show. So stick this to 5. 

This number came from the ability of executor and not from how many cores a system has. So the number 5 stays same 
even if you have double(32) cores in the CPU. 

Количество исполнителей:

Coming back to next step, with 5 as cores per executor, and 15 as total available cores in one Node(CPU) - we come to 
3 executors per node. 

So with 6 nodes, and 3 executors per node - we get 18 executors. Out of 18 we need 1 executor (java process) for AM in YARN we get 17 executors 

This 17 is the number we give to spark using --num-executors while running from spark-submit shell command 

памяти для каждого исполнителя:

From above step, we have 3 executors per node. And available RAM is 63 GB 

So memory for each executor is 63/3 = 21GB. 

However small overhead memory is also needed to determine the full memory request to YARN for each executor. 
Formula for that over head is max(384, .07 * spark.executor.memory) 

Calculating that overhead - .07 * 21 (Here 21 is calculated as above 63/3) 
          = 1.47 

Since 1.47 GB > 384 MB, the over head is 1.47. 
Take the above from each 21 above => 21 - 1.47 ~ 19 GB 

So executor memory - 19 GB 

Окончательные цифры - Исполнителями - 17, сердечники 5, исполнитель памяти - 19 ГБ

---

Случай 2 Оборудование: То же 6 Узел, 32 Сердечники, 64 GB

5 одинакова для хорошего параллельности

Количество execu ТЗ для каждого узла = 32/5 ~ 6

Так всего исполнители = 6 * 6 = 36. Узлы Тогда окончательное число 36 - 1 для AM = 35

Исполнитель память: 6 исполнителей для каждого узла. 63/6 ~ 10. Над головой .07 * 10 = 700 МБ. Так округлением до 1 Гб, как над головой, мы получим 10-1 = 9 GB

Окончательные цифры - ИСПОЛНИТЕЛЕЙ - 35, сердечники 5, Палач памяти - 9 GB

---

Case 3

Вышеупомянутые сценарии начинаются с принятия количества ядер как фиксированных и перехода к # исполнителей и памяти.

Теперь первом случае, если мы думаем, что нам не нужно 19 ГБ, и только 10 Гб достаточно, то следующие цифры:

сердечники 5 # исполнителей для каждого узла = 3

На этом этапе это приведет к 21, а затем 19 в соответствии с нашим первым вычислением. Но так как мы думали, что 10 в порядке (предположим немного накладных расходов), то мы не можем переключить # исполнителей на узел до 6 (например, 63/10). Станьте с 6 исполнителями на каждый узел и 5 ядер, до 30 ядер на узел, когда у нас всего 16 ядер. Поэтому нам также необходимо изменить количество ядер для каждого исполнителя.

Так вычисления снова,

Магическое число 5 доходит до 3 (любое число меньше или равно 5). Таким образом, с 3 ядрами и 15 доступными ядрами - мы получаем 5 исполнителей на узел. Таким образом, (5 * 6 -1) = 29 исполнители

Так память 63/5 ~ 12. Над головкой 12 * .07 = 0,84 Так исполнитель память 12 - 1 Гб = 11 Гб

Заключительные числа 29 исполнителей, 3 ядра, исполнитель памяти 11 ГБ

---

Динамическое распределение:

Примечание: Верхняя граница для числа EXE если динамическое распределение включено. Таким образом, это говорит о том, что искровое приложение может съесть все ресурсы, если это необходимо. Таким образом, в кластер, в котором у вас есть другие приложения, запущен, а также для запуска задач требуются ядра, убедитесь, что вы делаете это на уровне кластера. Я имею в виду, что вы можете выделить определенное количество ядер для YARN на основе доступа пользователя. Таким образом, вы можете создавать spark_user, а затем давать ядра (мин/макс) для этого пользователя. Эти ограничения предназначены для совместного использования между искрами и другими приложениями, которые работают на YARN.

spark.dynamicAllocation.enabled - Если для этого параметра установлено значение true - нам не нужно упоминать исполнителей. Причина ниже:

Статический номер параметра, который мы даем при искра-submit, предназначен для всей продолжительности работы. Однако, если динамическое размещение изображения, будут разные этапы, как

С чего начать:

Начальное число исполнителей (spark.dynamicAllocation.initialExecutors), чтобы начать с

Сколько:

Тогда в зависимости от нагрузки (задачи ждут) сколько потребуется. В конечном итоге это будет число, которое мы даем при искрообразовании - ставим статически. Итак, как только начальные номера исполнителей установлены, мы переходим к min (spark.dynamicAllocation.minExecutors) и max (spark.dynamicAllocation.maxExecutors) номеров.

Когда спросить или дать:

Когда мы просим новых исполнителей (spark.dynamicAllocation.schedulerBacklogTimeout) - Там были отложенные задания для этого много продолжительности. поэтому просьба. количество запросов, запрошенных в каждом раунде, экспоненциально возрастает по сравнению с предыдущим раундом. Например, приложение добавит 1 исполнителя в первом раунде, а затем 2, 4, 8 и т. Д. Исполнителей в последующих раундах. В определенной точке, выше макс входит в картину

когда мы отдать исполнитель (spark.dynamicAllocation.executorIdleTimeout) -

Пожалуйста, поправьте меня, если я пропустил что-нибудь. Выше было мое понимание, основанное на блоге, который я обсуждал, и некоторых онлайн-ресурсах. Спасибо.

Ссылки:

• http://site.clairvoyantsoft.com/understanding-resource-allocation-configurations-spark-application/
• http://spark.apache.org/docs/latest/configuration.html#dynamic-allocation
• http://spark.apache.org/docs/latest/job-scheduling.html#resource-allocation-policy

Answer 2

Кроме того, это зависит от вашего случая использования, является важным параметром конфигурации является:

spark.memory.fraction (Фракция (площадь кучи - 300 МБ), используемая для выполнения и хранения) от http://spark.apache.org/docs/latest/configuration.html#memory-management.

Если вы не используете кеш/persist, установите его в 0.1, чтобы у вас была вся память для вашей программы.

Если вы используете кэш/упорствовать, вы можете проверить память, занятую:

sc.getExecutorMemoryStatus.map(a => (a._2._1 - a._2._2)/(1024.0*1024*1024)).sum 

Вы можете читать данные из HDFS или HTTP?

Опять же, настройка зависит от вашего варианта использования.