Ошибка работника dask jobqueue при запуске "Ресурс временно недоступен"

Я запускаю dask через slurm через очередь заданий, и я довольно часто получаю 3 ошибки ...

В основном мой вопрос в том, что могло вызвать эти сбои? На первый взгляд проблема в том, что слишком много воркеров одновременно записывают на диск или мои воркеры задействованы во многих других процессах, но отследить это довольно сложно. Я могу подключиться к узлу по ssh, но я не вижу ненормального количества процессов, и каждый узел имеет ssd на 500 ГБ, поэтому мне не следует писать слишком много.

Все, что ниже, это просто информация о моих конфигурациях и подобных
Моя установка выглядит следующим образом:

cluster = SLURMCluster(cores=1, memory=f"{args.gbmem}GB", queue='fast_q', name=args.name,
                           env_extra=["source ~/.zshrc"])
cluster.adapt(minimum=1, maximum=200)

client = await Client(cluster, processes=False, asynchronous=True)

Полагаю, я даже не уверен, нужно ли установить process = False.

Я запускаю этот стартовый сценарий через sbatch при условиях 4 ГБ памяти, 2 ядер (-c) (хотя я ожидаю, что мне понадобится только 1) и 1 задача (-n). И это запускает все мои задания через конфигурацию slurmcluster сверху. Я сбросил свои сценарии отправки slurm в файлы, и они выглядят разумно.

Каждое задание несложно, это subprocess.call( команда для скомпилированного исполняемого файла, которая занимает 1 ядро ​​и 2–4 ГБ памяти. Я требую, чтобы вызов клиента и последующие вызовы были асинхронными, потому что у меня много условных вычислений. Таким образом, каждый загруженный рабочий процесс должен состоять из 1 процесса Python, 1 исполняемого файла и 1 оболочки. Наложенный планировщиком мы имеем

>> ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-m: resident set size (kbytes)      unlimited
-u: processes                       512
-n: file descriptors                1024
-l: locked-in-memory size (kbytes)  64
-v: address space (kbytes)          unlimited
-x: file locks                      unlimited
-i: pending signals                 1031203
-q: bytes in POSIX msg queues       819200
-e: max nice                        0
-r: max rt priority                 0
-N 15:                              unlimited

И каждый узел имеет 64 ядра. так что я действительно не думаю, что достигаю каких-либо ограничений.

Я использую файл jobqueue.yaml, который выглядит так:

slurm:
  name: dask-worker
  cores: 1                 # Total number of cores per job
  memory: 2                # Total amount of memory per job
  processes: 1                # Number of Python processes per job
  local-directory: /scratch       # Location of fast local storage like /scratch or $TMPDIR
  queue: fast_q
  walltime: '24:00:00'
  log-directory: /home/dbun/slurm_logs

Буду признателен за любой совет! Полный журнал ниже.

FORK BLOCKING IO ERROR


distributed.nanny - INFO -         Start Nanny at: 'tcp://172.16.131.82:13687'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/dbun/.local/share/pyenv/versions/3.7.0/lib/python3.7/multiprocessing/forkserver.py", line 250, in main
    pid = os.fork()
BlockingIOError: [Errno 11] Resource temporarily unavailable
distributed.dask_worker - INFO - End worker

Aborted!

CANT START NEW THREAD ERROR

https://pastebin.com/ibYUNcqD

BLOCKING IO ERROR

https://pastebin.com/FGfxqZEk

РЕДАКТИРОВАТЬ: Еще одна часть головоломки: похоже, что dask_worker выполняет несколько вызовов multiprocessing.forkserver? это звучит разумно?

https://pastebin.com/r2pTQUS4