Я использую distributed.Client для локальных вычислений. Я также хочу создать гринлет gevent из основного потока, чтобы провести несвязанный мониторинг. Использование метода patch_all() gevent превратит нативные потоки в гринлеты. Учитывая, что большая часть работы, выполняемой планировщиком, выполняется pandas/numpy, и поэтому я подозреваю, что большая часть из них выпускает GIL, нативные потоки были бы полезны. Я обеспокоен тем, что их исправление gevent будет совершенно неоптимальным. Однако отсутствие исправления собственных потоков доставляет мне другие головные боли (в частности, выдает ошибки, когда локальный планировщик пытается разветвить сервер Bokeh. Это известное ограничение). Есть ли рекомендации по использованию gevent и dask/distributed, или их следует избегать?
локальный планировщик dask и gevent
Ответы (1)
Dask.distributed использует Tornado для параллелизма, в то время как вычисления происходят в других потоках. И вычисления, и коммуникация пересекаются в одном и том же процессе. Если вы перестанете использовать правильные потоки, связь будет заблокирована до тех пор, пока не закончатся длительные вычисления. Это может привести к тому, что ваши рабочие потоки перестанут отвечать на запросы, поскольку им придется ждать длительных вычислений, прежде чем они смогут обрабатывать запросы на связь с другими рабочими процессами. Тот факт, что вычисления numpy/pandas освобождают GIL, полезен только в том случае, если вы действительно используете потоки.
Если разветвление боке-сервера является проблемой, вы также можете просто не использовать боке-веб-сервер с флагом --no-bokeh.
dask-scheduler --no-bokeh
Или, короче говоря, dask.distributed не тестировался с gevent и не планирует его поддерживать.
