Контекст
Я использую dask.distributed для распараллеливания вычислений на разных машинах. Поэтому у меня есть dask-worker, работающие на разных машинах, которые подключаются к dask-scheduler, на который я могу затем отправлять свои собственные графики вместе с необходимыми ключами.
Из-за ограничений сетевого монтирования мои входные данные (и выходное хранилище) доступны только для подмножества машин («хосты ввода-вывода»). Я пытался справиться с этим двумя способами:
- все задачи, задействованные в операциях ввода-вывода, ограничены хостами ввода-вывода (они могут выполняться только на рабочих процессах, которые работают на машинах, имеющих доступ к данным), а задачи, не связанные с вводом-выводом, ограничиваются узлами ввода-вывода.
- все задачи, участвующие в операциях ввода-вывода, привязаны к рабочим, предоставляющим ресурс 'io' (узлы ввода-вывода), а задачи, не связанные с вводом-выводом, привязаны к рабочим на узлах без ввода-вывода, которые обеспечивают вычисление ресурса '.
Идея, лежащая в основе запрета выполнения задач, не связанных с вводом-выводом, на узлах ввода-вывода состоит в том, чтобы убедиться, что их рабочие процессы доступны для задач ввода-вывода.
Проблема
Оба подхода работают так, как ожидалось, в том смысле, что они ограничивают задачи ввода-вывода правильными исполнителями. Однако я заметил, что при использовании любого из двух подходов лишь очень немногие рабочие накапливают много задач, в то время как большинство других рабочих остается бездействующими.
Прочитав о том, как задачи распределяются между рабочими, я обнаружил, что кража работы, похоже, намеренно отключена для ограниченных задач (http://distributed.readthedocs.io/en/latest/work-stealing.html). Похоже, это также применимо к структуре ресурсов.
Вопрос
Есть ли хороший способ совместить ограничения задач с кражей работы?
