Я выполняю dask over slurm через jobqueue и получаю три ошибки довольно последовательно ...
По сути, мой вопрос в том, что может быть причиной этих сбоев? На первый взгляд проблема в том, что слишком много рабочих пишут на диск одновременно, или мои работники переходят во многие другие процессы, но это довольно сложно отследить. Я могу подключиться к узлу через ssh, но я не вижу ненормального числа процессов, и каждый узел имеет 500 ГБ ssd, поэтому мне не следует писать слишком много.
Все, что ниже, это просто информация о моих конфигурациях и тому подобное
Моя установка выглядит следующим образом:
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)
Полагаю, я даже не уверен, следует ли устанавливать процессы = False.
Я запускаю этот стартовый скрипт через sbatch в условиях 4 ГБ памяти, 2 ядер (-c) (хотя я ожидаю, что потребуется только 1) и 1 задача (-n). И это запускает все мои работы через конфигурацию slurmcluster сверху. Я выгрузил свои скрипты для отправки сообщений в файлы, и они выглядят разумно.
Каждое задание не является сложным, это команда 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
EDIT:
Еще одна часть головоломки:
Похоже, dask_worker выполняет несколько вызовов multiprocessing.forkserver? это звучит разумно?
https://pastebin.com/r2pTQUS4