Лучшие практики по определению количества рабочих - PullRequest
0 голосов
/ 29 июня 2018

Меня немного смущают различные термины, используемые в dask и dask.distributed при настройке рабочих в кластере.

Термины, с которыми я столкнулся: поток, процесс, процессор, узел, работник, планировщик.

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

  • 1 рабочий на узел с n процессами для n ядер на узле
  • темы и процессы - это одно и то же понятие? В dask-mpi я должен установить nthreads, но они отображаются как процессы в клиенте

Любые другие предложения?

1 Ответ

0 голосов
/ 29 июня 2018

Под "узлами" люди обычно подразумевают физическую или виртуальную машину. Этот узел может запускать несколько программ или процессов одновременно (так же, как мой компьютер может одновременно запускать веб-браузер и текстовый редактор). Каждый процесс может распараллеливать внутри себя множество потоков. Процессы имеют изолированную среду памяти, что означает, что обмен данными внутри процесса является бесплатным, а обмен данными между процессами стоит дорого.

Обычно все работает лучше на больших узлах (например, на 36 ядрах), если вы разбиваете их на несколько процессов, каждый из которых имеет несколько потоков. Вы хотите, чтобы число процессов, умноженное на количество потоков, равнялось количеству ядер. Например, для 36-ядерного компьютера вы можете сделать что-то вроде следующего:

  • Четыре процесса с девятью потоками в каждом
  • Двенадцать процессов с тремя потоками в каждом
  • Один процесс с тридцатью шестью нитями

Обычно каждый выбирает между этими вариантами в зависимости от рабочей нагрузки. Различие здесь связано с глобальной блокировкой интерпретатора Python, которая ограничивает параллелизм для некоторых видов данных. Если вы работаете в основном с Numpy, Pandas, Scikit-Learn или другими библиотеками числового программирования в Python, вам не нужно беспокоиться о GIL, и вы, вероятно, хотите отдать предпочтение нескольким процессам с большим количеством потоков в каждом. Это помогает, потому что позволяет данным свободно перемещаться между вашими ядрами, потому что все они живут в одном и том же процессе. Однако, если вы занимаетесь в основном программированием на чистом Python, например, работаете с текстовыми данными, словарями / списками / наборами и выполняете большую часть вычислений в тесном цикле Python для циклов, тогда вы предпочтете иметь много процессов с несколькими потоками в каждом. Это влечет за собой дополнительные расходы на связь, но позволяет обойти GIL.

Короче говоря, если вы используете в основном данные типа numpy / pandas, попробуйте получить как минимум восемь потоков или около того в процессе. В противном случае, возможно, в процессе будут использоваться только два потока.

...