Slurm 作业导致执行时间异常

Question

我有这样的工作脚本，

#!/bin/bash 
#SBATCH -p cs
#SBATCH -e %j.err
#SBATCH --time=40:00
#SBATCH --output=slurm-%j.out
#SBATCH --cpus-per-task=2
#SBATCH --nodes=1
#SBATCH --ntasks=1

# executable
for I in $(seq 32)
do
    export OMP_NUM_THREADS=2 &&
    srun --nodes=1 --ntasks=1 --cpus-per-task=2  bash -c "./debug > ./logs/112500/exp$I/log-2.txt" 
done

我对不同数量的 omp 线程有相同的作业脚本，我只更改了 --cpus-per-task = openmp 线程数 的标头信息，以及 srun 命令中的那个。

奇怪的是，在同一个作业做的32个实验中，虽然在执行时间上有一个通用模式，但有些运行故障的执行时间是通用模式执行时间的20倍或350倍。调试程序测量挂钟时间，因为程序是并行的。它测量一个嵌套的 for 循环，它不会被任何其他方法中断。

我连续手动运行脚本，每当一个脚本完成时，我会提交另一个具有更多线程的脚本。

我有下面列表中包含的所有测量值，

知道为什么会发生这种情况吗？如何修复它并获得大致相同的执行时间？

Answer 1

根据 Slurm 集群的配置方式，您的作业可能会因其他作业而受到干扰，尤其是在涉及磁盘或网络的情况下，或者内存被其他作业过度使用并且 Slurm 未配置为包含它的情况下。

你能做的是

• 使用

  --exclusive

  确保你的工作是节点上唯一的工作
• 将所有输入数据/输出结果复制到本地磁盘，以避免网络负载干扰。

Answer 2

好吧，刚刚也解决了这个案子。显然我的 openmp pragma 中有一个小错误，我假设变量被声明为私有的，但是，当没有指定默认子句时，它是共享的。因此，我计算了每个线程在 N^2 次迭代中的共享变量，这在某些实验中造成了瓶颈。由于存在此错误，我原以为运行时会比当前的少数异常值增加更多的运行时间。无论如何，将声明模式固定为私有稳定了 32 个实验中的所有时间测量。