Статус рабочего узла в кластере Ray EC2: обновление не выполнено - PullRequest
0 голосов
/ 13 мая 2019

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

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

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

ray-timeline

1 Ответ

0 голосов
/ 27 мая 2019

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

...