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

Ответ 1

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

Аппаратное обеспечение Case 1 - 6 узлов и каждый node 16 ядер, 64 ГБ оперативной памяти

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

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

Начните с того, как выбрать количество ядер:

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 Node, 32 ядра, 64 ГБ

5 одинаково для хорошего concurrency

Число исполнителей для каждого node= 32/5 ~ 6

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

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

Конечные числа - исполнители - 35, ядро ​​5, память исполнителя - 9 ГБ

Случай 3

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

Теперь для первого случая, если мы думаем, что нам не нужны 19 ГБ, и достаточно всего 10 ГБ, то следуют числа:

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

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

Итак, вычисляем снова,

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

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

Конечные номера - 29 исполнителей, 3 ядра, память исполнителей - 11 ГБ.

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

Примечание. Верхняя граница числа исполнителей, если включено динамическое распределение. Таким образом, это говорит о том, что искровое приложение может съесть все ресурсы, если это необходимо. Итак, в  кластер, в котором работают другие приложения, и для запуска задач также требуются ядра, убедитесь, что вы делаете это на уровне кластера. Я имею в виду, что вы можете выделить  определенное количество ядер для 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

Ответ 2

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

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

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

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

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

Вы читаете данные из HDFS или из HTTP?

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