parallel-processing - pause - srun slurm

SLURM `srun` vs` sbatch` y sus parámetros

Question

Estoy tratando de entender cuál es la diferencia entre los comandos srun y sbatch SLURM. Estaré contento con una explicación general, en lugar de respuestas específicas a las siguientes preguntas, pero aquí hay algunos puntos específicos de confusión que pueden ser un punto de partida y dar una idea de lo que estoy buscando.

Según la documentation , srun es para enviar trabajos, y sbatch es para enviar trabajos para su posterior ejecución, pero la diferencia práctica no está clara para mí, y su comportamiento parece ser el mismo. Por ejemplo, tengo un clúster con 2 nodos, cada uno con 2 CPU. Si ejecuto srun testjob.sh & 5x seguidos, se pondrá en cola el quinto trabajo hasta que una CPU esté disponible, al igual que ejecutar sbatch testjob.sh .

Para hacer la pregunta más concreta, creo que un buen lugar para comenzar podría ser: ¿Cuáles son algunas cosas que puedo hacer con una que no puedo hacer con la otra y por qué?

Muchos de los argumentos de ambos comandos son iguales. Los que parecen más relevantes son --ntasks , --nodes , --cpus-per-task , --ntasks-per-node . ¿Cómo se relacionan entre sí y cómo difieren entre srun y sbatch ?

Una diferencia particular es que srun causará un error si testjob.sh no tiene permiso de ejecución, es decir, chmod +x testjob.sh mientras que sbatch lo ejecutará felizmente. ¿Qué está sucediendo "bajo el capó" que hace que este sea el caso?

La documentación también menciona que srun se usa comúnmente dentro de los scripts de sbatch . Esto lleva a la pregunta: ¿Cómo interactúan entre ellos y cuál es el caso de uso "canónico" para cada uno de ellos? Específicamente, ¿alguna vez usaría srun por sí mismo?

Answer 1

En realidad, esto no responde completamente la pregunta, pero aquí hay más información que encontré que puede ser útil para alguien en el futuro:

De un here con una pregunta similar:

En pocas palabras, sbatch y salloc asignan recursos al trabajo, mientras que srun lanza tareas paralelas a través de esos recursos. Cuando se invoca dentro de una asignación de trabajo, srun iniciará tareas paralelas en algunos o todos los recursos asignados. En ese caso, srun hereda por defecto las opciones pertinentes del sbatch o salloc con el que se ejecuta. Luego, puede (por lo general) proporcionar diferentes opciones de ejecución que anularán lo que recibe de forma predeterminada. Cada invocación de srun dentro de un trabajo se conoce como un paso de trabajo.

srun también se puede invocar fuera de una asignación de trabajo. En ese caso, srun solicita recursos, y cuando se otorgan esos recursos, inicia tareas a través de esos recursos como un solo trabajo y paso de trabajo.

Hay una página web relativamente nueva que entra en más detalles sobre las opciones -B y --exclusivas.

doc / html / cpu_management.shtml

Información adicional de la página de preguntas frecuentes de SLURM .

El comando srun tiene dos modos diferentes de operación. Primero, si no se ejecuta dentro de un trabajo existente (es decir, no dentro de una asignación de trabajo Slurm creada por salloc o sbatch), creará una asignación de trabajo y generará una aplicación. Si se ejecuta dentro de una asignación existente, el comando srun solo genera la aplicación. Para esta pregunta, solo abordaremos el primer modo de operación y compararemos la creación de una asignación de trabajo utilizando los comandos sbatch y srun.

El comando srun está diseñado para uso interactivo, con alguien monitoreando la salida. La salida de la aplicación se ve como salida del comando srun, típicamente en la terminal del usuario. El comando sbatch está diseñado para enviar un script para su posterior ejecución y su salida se escribe en un archivo. Las opciones de comando utilizadas en la asignación de trabajos son casi idénticas. La diferencia más notable en las opciones es que el comando sbatch admite el concepto de matrices de trabajos, mientras que srun no. Otra diferencia significativa está en la tolerancia a fallas. Las fallas que involucran trabajos sbatch generalmente dan como resultado que el trabajo sea solicitado y ejecutado nuevamente, mientras que las fallas que involucran srun generalmente generan un mensaje de error con la expectativa de que el usuario responderá de manera apropiada.

Answer 2

La documentación dice

srun is used to submit a job for execution in real time

mientras

sbatch is used to submit a job script for later execution.

Ambos aceptan prácticamente el mismo conjunto de parámetros. La principal diferencia es que srun es interactivo y bloqueador (obtienes el resultado en tu terminal y no puedes escribir otros comandos hasta que esté terminado), mientras que sbatch es procesamiento por lotes y no bloqueo (los resultados se escriben en un archivo y puedes enviar otros comandos de inmediato).

Si usa srun en segundo plano con el signo & , entonces elimina la función de ''bloqueo'' de srun , que se vuelve interactiva pero sin bloqueo. Sin embargo, todavía es interactivo, lo que significa que la salida desordenará su terminal y los procesos srun están vinculados a su terminal. Si se desconecta, perderá el control sobre ellos, o podrían ser asesinados (dependiendo de si usan stdout o no básicamente). Y se eliminarán si se reinicia la máquina a la que se conecta para enviar trabajos.

Si usa sbatch , envía su trabajo y Slurm lo maneja; puede desconectarse, matar su terminal, etc. sin consecuencias. Su trabajo ya no está vinculado a un proceso en ejecución.

¿Qué cosas puedo hacer con una que no puedo hacer con la otra y por qué?

Una característica que está disponible para sbatch y no para srun es la llegada de trabajos . Como srun puede usarse dentro de un script sbatch , no hay nada que no pueda hacer con sbatch .

¿Cómo se relacionan entre sí y cómo difieren entre srun y sbatch?

Todos los parámetros --ntasks , --nodes , --cpus-per-task , --ntasks-per-node tienen el mismo significado en ambos comandos. Eso es cierto para casi todos los parámetros, con la notable excepción de --exclusive .

¿Qué está sucediendo "bajo el capó" que hace que este sea el caso?

srun ejecuta inmediatamente el script en el host remoto, mientras que sbatch copia el script en un almacenamiento interno y luego lo carga en el nodo de cómputo cuando comienza el trabajo. Puede verificar esto modificando su secuencia de comandos de envío después de que se haya enviado; los cambios no se tendrán en cuenta (ver this ).

¿Cómo interactúan entre ellos y cuál es el caso de uso "canónico" para cada uno de ellos?

Por lo general, usa sbatch para enviar un trabajo y srun en el script de envío para crear pasos de trabajo como Slurm los llama. srun se usa para iniciar los procesos. Si su programa es un programa paralelo de MPI, srun se encarga de crear todos los procesos de MPI. De lo contrario, srun ejecutará su programa tantas veces como lo especifique la opción --ntasks . Hay muchos casos de uso dependiendo de si su programa es paralelo o no, tiene un largo tiempo de ejecución o no, está compuesto de un solo ejecutable o no, etc. A menos que se especifique lo contrario, srun hereda por defecto las opciones pertinentes de sbatch o salloc bajo el cual corre (desde here ).

Específicamente, ¿alguna vez usaría srun por sí mismo?

Aparte de las pruebas pequeñas, no. Un uso común es srun --pty bash para obtener un shell en un trabajo de cómputo.