Статус рабочего узла в кластере Ray EC2: ошибка обновления

Теперь у меня есть кластер Ray, работающий на EC2 (Ubuntu 16.04) с главным узлом c4.8xlarge и одним идентичным рабочим. Я хотел проверить, используется ли многопоточность, поэтому я провел тесты, чтобы время увеличения числа (n) одной и той же 9-секундной задачи. Поскольку в инстансе 18 ЦП, я ожидал увидеть, что задание займет около 9 секунд до n ‹= 35 (при условии, что один ЦП для управления кластером), а затем либо сбой, либо увеличение примерно до 18 секунд при переключении на 36 виртуальных ЦП. на узел.

Вместо этого кластер обрабатывал только 14 задач параллельно, а затем время выполнения подскочило до 40 секунд и продолжило увеличиваться с увеличением n. Когда я попробовал мастер c4xlarge (4 процессора), время было прямо пропорционально n, то есть они работали последовательно. Поэтому я предполагаю, что мастеру на самом деле требуется 4 процессора для системы, а рабочий узел вообще не используется. Однако, если я добавлю второго рабочего, время для n> 14 будет примерно на 40 секунд меньше, чем без него. Я также пробовал значение target_utilization_factor меньше 1.0, но это не имело никакого значения.

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

луч-временная шкала


amazon-ec2 cluster-computing parallel-processing ray
person Nick Mint    schedule 13.05.2019    source источник
comment
Чтобы увидеть, планируется ли что-то параллельно, я бы посоветовал взглянуть на временную шкалу Рэя. Запустите ray timeline в командной строке (на одном из узлов), а затем загрузите полученный файл JSON в chrome: // tracing в веб-браузере Chrome.   -  person Robert Nishihara    schedule 13.05.2019
comment
Какой удобный инструмент трассировки! На снимке экрана показан результат выполнения n = [8,18,28,38]. Всего 36 рабочих, поэтому у каждого должен быть один реальный ЦП - я не могу сказать, какой из них принадлежит мастеру, а какой - рабочему. Однако только первый тест запускается на ~ 9 секундах для всех рабочих. Считаете ли вы, что это проблема с ресурсами: возможно, задача очень голодна по ОЗУ, и, если каждый работник конкурирует за общую память, это может вызвать узкое место? Я предполагал, что у экземпляра, оптимизированного для вычислений, будет более чем достаточно оперативной памяти для каждого рабочего.   -  person Nick Mint    schedule 14.05.2019
comment
Я увеличил размер тома EBS до 100 ГБ, что улучшило ситуацию, но по-прежнему не позволяло всем задачам выполняться параллельно. Затем я увеличил число рабочих узлов до 3 и запустил n = [18,36,54,72], получив времена ~ [11, 22, 27, 36]; однако трассировка показала, что это все еще использовало только 36 процессоров! Я удалил с помощью tmp.TemporaryDirectory () as path: block (см. Код в stackoverflow.com/questions/55912710/), но это не имело значения. Еще попробовал увеличить EBS до 200Гб: опять же, без особой разницы.   -  person Nick Mint    schedule 15.05.2019

Ответы (1)


arrow_upward
0
arrow_downward

Похоже, что кластер не использует рабочих, поэтому трассировка показывает только 18 фактических процессоров, работающих с задачей. Монитор (ray exec ray_conf.yaml 'tail -n 100 -f / tmp / ray / session_ / logs / monitor') определил, что «ошибка обновления» значительна в том, что команды настройки, вызываемые ray updater.py, не работали на рабочих узлах. В частности, это была попытка установить на них пакет компилятора C, необходимый для сборки, который, по-видимому, превысил выделение рабочей памяти. Я делал это только для того, чтобы подавить предупреждение об установке "setproctitle", которое, как я теперь понимаю, в любом случае можно безопасно проигнорировать.

person Nick Mint    schedule 27.05.2019