Hadoop Fairschduler не использует все слоты для карт

Question

Запуск 12-узлового кластера hadoop с общим количеством доступных 48 слотов карт. Отправляю кучу заданий, но никогда не вижу всех используемых слотов карт. Максимальное количество занятых слотов колеблется около 30-35, но никогда не близко к 48. Почему?

Вот конфигурация fairscheduler.

<?xml version="1.0"?>
<allocations>
  <pool name="big">
    <minMaps>10</minMaps>
    <minReduces>10</minReduces>
    <maxRunningJobs>3</maxRunningJobs>
  </pool>
  <pool name="medium">
    <minMaps>10</minMaps>
    <minReduces>10</minReduces>
    <maxRunningJobs>3</maxRunningJobs>
    <weight>3.0</weight>
  </pool>
  <pool name="small">
    <minMaps>20</minMaps>
    <minReduces>20</minReduces>
    <maxRunningJobs>20</maxRunningJobs>
    <weight>100.0</weight>
  </pool>
</allocations>

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

Answer 1

Я думаю, что проблема может быть вызвана тем, что опция maxRunningJobs не учитывается при вычислении общих ресурсов для заданий.Я думаю, что этот параметр обрабатывается после того, как слоты (от превышения задания) уже были назначены для треккинга задач.Это происходит каждые n секунд из метода UpdateThread.update () -> update Runability () из класса FairScheduler.Я полагаю, что в вашем случае через некоторое время задания из «среднего» и «большого» пулов получают больший дефицит, чем задания из «малого» пула, это означает, что следующая задача будет запланирована из задания в среднем или большом пуле.Когда задача запланирована, имеет место ограничение maxRunningJobs и переводит превышающие задания в нерабочее состояние.То же самое появляется в следующем обновлении.

Это только мое предположение после того, как я позаботился о каком-то источнике fscheduler.Если вы можете, я, вероятно, попытался бы удалить maxRunningJobs из конфигурации и посмотреть, как планировщик ведет себя без этого ограничения и если он занимает все ваши слоты ..

Кажется, что вес для пулов в моем мнении слишком высок,Вес 100 означает, что этот пул должен получить в 100 раз больше слотов, чем пул по умолчанию.Я бы попытался уменьшить это число несколькими факторами, если вы хотите иметь справедливое распределение между вашими пулами.В противном случае задания из других пулов будут запущены только тогда, когда они встретят свой дефицит (он рассчитывается на основе запущенных задач и minShare)

Другой вариант, почему задания голодают, может быть из-за планирования задержки, которое включено в fschedс целью улучшения вычислительной местности?Вероятно, это можно улучшить, увеличив коэффициент репликации, но я не думаю, что это ваш случай ..

некоторые документы по Fairscheduler ..

Answer 2

Вероятно, голодание происходит из-за того, что приоритет малого пула действительно очень высок (2 ^ 100 больше, чем большой, 2 ^ 97 больше, чем средний).Когда все задания упорядочены по приоритету, и у вас есть ожидающие задания в небольшом пуле.Следующее задание в этом пуле требует 20 слотов и имеет более высокий приоритет, чем что-либо еще, поэтому открытые слоты просто ждут там, пока текущее задание не освободит их.нет «ненужных интервалов», которые можно разделить на другие приоритеты

см. основные моменты из примечаний к реализации справедливого графика :

"Справедливые доли рассчитанына деление емкости кластера между работающими заданиями в соответствии с «весом» для каждого задания. По умолчанию вес основан на приоритете, при этом каждый уровень приоритета имеет в 2 раза больший вес, чем следующий (например, VERY_HIGH имеет в 4 раза больше веса NORMAL). Однако веса также могут быть основаны на размерах и возрасте заданий, как описано в разделе Настройка. Для заданий, находящихся в пуле, справедливые доли также учитываютминимальная гарантия для этого пула. Эта емкость делится между заданиями в этом пуле в соответствии с их весами. "

Наконец, когда ограничения для запущенных заданий пользователя или запущенных заданий пула установлены, мы выбираемкакие задания можно запустить, отсортировав все задания в порядке приоритета, а затем отправив время, как в стандартной схеме Hadoopduler. Любые задания, которые выпадают после ограничения пользователя / пула в этом порядке, ставятся в очередь и ждут простоя, пока их можно будет запустить.В течение этого времени они игнорируются в расчетах справедливого распределения и не получают или не теряют дефицит (их справедливая доля установлена ​​на ноль).