☰

手动执行与 Slurm srun/sbatch 的调度差异

tag-icon • tag-icon cpu scheduling nice slurm
手动执行与 Slurm srun/sbatch 的调度差异

太长了；博士仅当通过 Slurm sbatch/srun 启动时（而不是手动启动时），CPU 密集型工作负载才会忽略其他进程的好值。

我正在运行一个 systemd 服务，它定期收集硬件性能数据。该服务部署氮（核心数量）守护进程全部固定在分配给它们的一个核心上运行。为了确保它们在需要时或多或少地被调度1，服务（及其固有的所有线程/守护进程）都以 -20 的良好值启动。

当运行 CPU 密集型任务/基准测试时，例如

stress --cpu $(nproc) --timeout 60s

我服务的所有守护进程都能够在 <200 毫秒内执行其操作2（这很好）。

然而，当我通过 Slurm sbatch/srun 3提交相同的压力测试时，我的守护进程缺乏 CPU。守护进程（正如我假设的那样）没有被调度，并且需要几秒钟来执行其操作（开销增加了 10-20 倍），而不是花费 <200 毫秒。

守护进程不受任何其他因素（如 I/O、内存、共享资源）的限制，因为它们仅访问硬件寄存器。 cgroup 没有限制。此系统上禁用自动分组。

系统：2x AMD EPYC 7713 (64c)，256GB RAM； AlmaLinux8.4，内核为 4.18.0

问题：

手动启动压力测试和通过 Slurm 启动压力测试在安排方面有什么区别？为什么其中一个不会影响我的守护进程的调度，而另一个则让它们缺乏 CPU 资源？

1我知道这将是一个实时调度问题，但如果可能的话，我想避免更改为实时调度策略

2主要设置/读取硬件性能计数器

3请参阅以下脚本：

#!/bin/bash 
#SBATCH --ntasks=1
#SBATCH --partition=ALL 
#SBATCH --nodelist=myNode 
#SBATCH --time=00:05:00  
stress --cpu $(nproc) --timeout 60s

相关内容