在SLURM中绑定比cpus错误更多的进程
在SLURM中绑定比cpus错误更多的进程
提问于 2022-04-27 19:32:15
我正在尝试运行一个作业，该作业使用SLURM上节点之间传递的显式消息(即不只是运行并行作业)，但正在收到一个反复出现的错误，即“请求绑定到它将导致绑定比资源上的cpus更多的进程”。简单地说，我的代码需要在128个节点上发送一个参数数组，计算这些参数的可能性，并将这些可能性值的总和收集回根节点。在使用以下sbatch文件执行代码时，我得到了错误：
#!/bin/bash
#SBATCH --job-name=linesearch
#SBATCH --output=ls_%j.txt
#SBATCH --nodes=16
#SBATCH --ntasks-per-node=16
#SBATCH --partition=broadwl
#SBATCH --mem-per-cpu=2000
#SBATCH --time=18:00:00
# Load the default OpenMPI module.
module load openmpi
mpiexec -N 8 ./linesearch我认为使用-N 8会显式地将每个节点8个进程分配给16个--ntasks-per-node。我认为，使用这种方法(这是对计算机处理空间的低效使用)将减少对不同溢出线程的响应之后的错误，但它没有解决这个问题。
如果有用的话，完整的错误消息如下：
A request was made to bind to that would result in binding more
processes than cpus on a resource:
Bind to: NONE:IF-SUPPORTED
Node: XXXXXX
#processes: 4
#cpus: 3
You can override this protection by adding the "overload-allowed"
option to your binding directive.我正在执行的进程可能是内存密集型的，因此我不希望在作业耗尽分配后终止作业的风险中使用重载覆盖。
回答 1
Stack Overflow用户
回答已采纳
发布于 2022-04-28 18:30:02
请注意，我正在加载模块openmpi v2.0.1退休。但是，将s批处理文件更改为仅使用-np 128任务绑定到套接字解决了此问题。
批处理文件：
#!/bin/bash
#SBATCH --job-name=linesearch
#SBATCH --output=ls_%j.txt
#SBATCH --nodes=16
#SBATCH --ntasks=128
#SBATCH --partition=broadwl
#SBATCH --mem-per-cpu=2000
#SBATCH --time=18:00:00
# Load the default OpenMPI module.
module load openmpi
mpiexec -np 128 ./execs/linesearch $1 $2另一种解决方案是在--bind-to core --map-by core语句中使用mpiexec将每个进程绑定到核心。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/72034343
复制相关文章
相似问题
腾讯云开发者
