
在slurm集群中,通过bash脚本提交python脚本,再由python脚本调用`srun`来启动大规模并行计算任务,这种嵌套调用方式在启动阶段会引入极小的、几乎可以忽略的开销。只要python脚本的主要作用是任务编排且在并行任务启动后不进行大量计算,它对整个hpc工作负载的运行时性能不会产生负面影响。
在高性能计算(HPC)环境中,通过Slurm调度系统提交任务是一种标准实践。当需要在一个更复杂的任务流中启动并行计算时,常见的工作流可能涉及多层脚本调用。本文将探讨一种具体场景:通过sbatch提交一个Bash脚本,该Bash脚本随后执行一个Python脚本,而这个Python脚本又通过subprocess模块调用srun来启动实际的大规模并行工作负载。其典型的执行链如下:
sbatch 命令 -> Bash Script -> Python Script -> srun 命令 -> HPC Workload
在这种工作流中,sbatch负责向Slurm提交整个作业,Bash Script作为入口点,Python Script则扮演着灵活的编排者角色,例如处理输入参数、配置环境或执行预处理步骤。最终,Python Script通过调用srun来启动由Slurm管理的实际并行计算任务。
用户普遍关心的问题是,这种多层嵌套的调用方式,特别是Python脚本作为中间层,是否会引入显著的性能开销,从而影响最终HPC工作负载的效率。
立即学习“Python免费学习笔记(深入)”;
当sbatch提交作业后,Slurm会分配资源并启动Bash脚本。Bash脚本随后启动Python解释器来执行Python脚本。Python解释器的启动和Python脚本的执行会消耗一定的CPU时间和内存。然而,对于大多数HPC任务而言,这部分开销是:
因此,这种启动开销对于整个作业的性能影响微乎其微。
一旦Python脚本通过subprocess模块成功调用了srun,srun命令会接管控制权,并按照其参数启动并行程序。此时:
结论: 只要Python脚本的主要职责是编排和启动任务,而不是执行大量的计算密集型或I/O密集型操作,那么它对整个HPC工作负载的运行时性能不会造成负面影响。
为了更好地理解这种工作流,以下提供一个简单的示例:
#!/bin/bash #SBATCH --job-name=python_srun_test #SBATCH --nodes=2 #SBATCH --ntasks-per-node=4 #SBATCH --time=00:05:00 #SBATCH --output=slurm-%j.out echo "Starting myscript.sh on $(hostname)" echo "Slurm job ID: $SLURM_JOB_ID" # 激活conda环境或设置Python环境(如果需要) # source /path/to/your/conda/etc/profile.d/conda.sh # conda activate my_hpc_env # 执行Python脚本,Python脚本将调用srun python running.py "Hello HPC!" echo "myscript.sh finished."
import subprocess
import sys
import os
def run_hpc_workload(message):
"""
通过srun调用一个简单的并行HPC程序。
这里以一个简单的MPI程序为例,实际可以是任何并行应用。
"""
# 假设你有一个名为 'my_mpi_program' 的MPI可执行文件
# 并且它位于PATH中或者指定了完整路径
hpc_program = "./my_mpi_program" # 假设my_mpi_program在当前目录
# 构建srun命令。注意:srun会继承sbatch分配的资源。
# 这里我们只传递了程序名和参数。
# 如果需要更精细的srun控制,可以在这里添加更多srun参数,
# 但通常sbatch的参数已经足够。
srun_command = [
"srun",
hpc_program,
message # 传递给HPC程序的参数
]
print(f"Python script is about to call srun: {' '.join(srun_command)}")
try:
# 使用subprocess.check_call执行srun命令
# check_call会在命令返回非零退出码时抛出CalledProcessError
subprocess.check_call(srun_command)
print("srun command executed successfully.")
except subprocess.CalledProcessError as e:
print(f"Error calling srun: {e}", file=sys.stderr)
sys.exit(e.returncode)
except FileNotFoundError:
print(f"Error: '{hpc_program}' not found. Make sure it's compiled and in the correct path.", file=sys.stderr)
sys.exit(1)
if __name__ == "__main__":
# 获取从bash脚本传递的参数
if len(sys.argv) > 1:
param = sys.argv[1]
else:
param = "Default Message"
print(f"Python script running on host: {os.uname().nodename}")
print(f"Received parameter: {param}")
run_hpc_workload(param)
print("Python script finished its orchestration role.")#include <mpi.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv) {
MPI_Init(&argc, &argv);
int world_size;
MPI_Comm_size(MPI_COMM_WORLD, &world_size);
int world_rank;
MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
char processor_name[MPI_MAX_PROCESSOR_NAME];
int name_len;
MPI_Get_processor_name(processor_name, &name_len);
char message[256];
if (argc > 1) {
strncpy(message, argv[1], sizeof(message) - 1);
message[sizeof(message) - 1] = '\0';
} else {
strcpy(message, "No message provided.");
}
printf("Hello from processor %s, rank %d out of %d processes. Message: %s\n",
processor_name, world_rank, world_size, message);
MPI_Finalize();
return 0;
}mpicc my_mpi_program.c -o my_mpi_program
sbatch myscript.sh
在Slurm中通过Bash脚本提交Python脚本,再由Python脚本调用srun来启动大规模并行计算任务,是一种完全可行且常见的模式。这种方法在启动阶段引入的开销可以忽略不计,并且对主HPC工作负载的运行时性能没有实质性影响。关键在于将Python脚本作为高效的任务编排工具,而不是计算密集型任务的执行者。通过遵循上述最佳实践,可以确保这种嵌套调用方式既能提供灵活性,又能保持HPC任务的高效执行。
以上就是在Slurm中通过Python脚本调用srun的性能考量与最佳实践的详细内容,更多请关注php中文网其它相关文章!
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号