Dataproc устанавливает количество vcores на контейнер исполнителя - PullRequest
0 голосов
/ 21 сентября 2018

Я создаю приложение spark, которое будет работать на Dataproc.Я планирую использовать эфемерные кластеры и раскручивать новые для каждого выполнения приложения.Поэтому я хочу, чтобы моя работа поглощала как можно больше ресурсов кластера, и у меня есть очень хорошее представление о требованиях.

Я играл с отключением динамического распределения и настройкойисполнитель экземпляров и ядра сам.В настоящее время я использую 6 экземпляров и 30 ядер.

Возможно, это скорее вопрос пряжи, но я нахожу, что связь между контейнером vCores и моими ядрами искрового исполнителя немного сбивает с толку.В пользовательском интерфейсе менеджера приложений YARN я вижу, что создаются 7 контейнеров (1 драйвер и 6 исполнителей), и каждый из них использует 1 vCore.Однако в рамках spark я вижу, что сами исполнители используют указанные 30 ядер.

Поэтому мне любопытно, пытаются ли исполнители выполнять 30 задач параллельно на том, что по сути представляет собой одноядерный блок.Или, может быть, vCore, отображаемый в графическом интерфейсе AM, ошибочен?

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

1 Ответ

0 голосов
/ 09 октября 2018

vCore, отображаемое в графическом интерфейсе YARN, является ошибочным;это не очень хорошо документированная, но известная проблема с capacity-scheduler, которая используется по умолчанию в Dataproc.Примечательно, что при настройках по умолчанию в Dataproc YARN выполняет только упаковку бина ресурсов на основе памяти, а не процессоров;Преимущество состоит в том, что это более универсально для переподписки процессоров в различной степени в зависимости от желаемой нагрузки на рабочую нагрузку, особенно если что-то связано с вводом-выводом, но недостатком является то, что YARN не будет отвечать за фиксированное использование процессора.

См. https://stackoverflow.com/a/43302303/3777211 для некоторого обсуждения изменения на fair-scheduler, чтобы увидеть распределение vcores, точно представленное в YARN.Тем не менее, в вашем случае, вероятно, нет никакой пользы от этого;Заставить YARN выполнять бинарную упаковку в обоих измерениях - это скорее проблема «общего многопользовательского кластера», и она только усложняет задачу планирования.

В вашем случае лучший способ настроить ваше приложение - просто игнорировать то, чтоЯрн говорит о vcores;если вам нужен только один исполнитель на рабочий узел, то установите максимальный размер памяти для исполнителя, который будет соответствовать YARN на узел, и сделайте количество ядер на исполнителя равным общему количеству ядер на узел.

...