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


Estoy tratando de entender cuál es la diferencia entre la srun y sbatch órdenes. 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 documentación , srun es para enviar trabajos, y sbatch es para enviar trabajos para su posterior ejecución, pero el 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 en una fila, estará muy bien en la cola del quinto trabajo hasta que una CPU esté disponible, al igual que la ejecución de sbatch testjob.sh.

Para hacer la pregunta más concreta, creo que un buen punto de partida 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 a ambos los comandos son los mismos. Los que parecen los más relevantes son --ntasks, --nodes, --cpus-per-task, --ntasks-per-node. ¿Cómo se relacionan entre sí, y en qué difieren para srun vs sbatch?

Una diferencia particular es que srun causará un error si testjob.sh no tiene permiso ejecutable, 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 es comúnmente se usa dentro de los scripts sbatch. Esto lleva a la pregunta: ¿Cómo interactúan entre sí, 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?

Author: dkv, 2017-05-03

2 answers

La documentación dice

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

Mientras que

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 de bloqueo (obtiene el resultado en su terminal y no puede escribir otros comandos hasta que haya terminado), mientras que sbatch es procesamiento por lotes y no bloqueo (los resultados se escriben en un archivo y puede enviar otros comandos de inmediato).

Si usas srun en el fondo con el signo &, entonces elimine la función de' bloqueo ' de srun, que se vuelve interactiva pero no bloqueante. Sin embargo, sigue siendo 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 matarán si se reinicia la máquina a la que se conecta para enviar trabajos.

Si utiliza sbatch, envía su trabajo y es manejado por Slurm; puedes desconectar, matar tu terminal, etc. sin consecuencias. Su trabajo ya no está vinculado a un proceso en ejecución.

¿Cuáles son algunas cosas que 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 job arrrays. Como srun se puede usar dentro de un script sbatch, no hay nada que no pueda hacer con sbatch.

¿Cómo se relacionan estos con cada uno otros, y en qué difieren para srun vs sbatch?

Todos los parámetros --ntasks, --nodes, --cpus-per-task, --ntasks-per-node tienen el mismo significado en ambos comandos. Esto 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 empiece el trabajo. Puede comprobar esto modificando su script 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 sí, y cuál es el caso de uso "canónico" para cada uno de ellos?

Normalmente se usa sbatch para enviar un trabajo y srun en el script de envío para crear pasos de trabajo como los llama Slurm. srun se utiliza para iniciar los procesos. Si su programa es un programa MPI paralelo, srun se encarga de crear todos los procesos MPI. Si no, srun ejecutará su programa tantas veces como especifique la opción --ntasks. Hay muchos casos de uso dependiendo de si su programa está en paralelo o no, tiene un largo tiempo de ejecución o no, se compone 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 las cuales se ejecuta (desde aquí).

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

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

 45
Author: damienfrancois,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-08-07 08:06:56

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


De un hilo relacionado encontré con una pregunta similar:

En pocas palabras, sbatch y salloc asignan recursos al trabajo, mientras que srun lanza tareas paralelas entre esos recursos. Cuando se invoca dentro de una asignación de trabajo, srun iniciará tareas paralelas en algunos o todos los recursos asignados. En eso case, srun hereda por defecto las opciones pertinentes del sbatch o salloc bajo el que se ejecuta. A continuación, puede (generalmente) proporcionar srun diferentes opciones que anularán lo que recibe por defecto. 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 en esos recursos como un solo trabajo y paso del trabajo.

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

Doc/html/cpu_management.shtml


Información adicional de la página SLURM FAQ.

El comando srun tiene dos modos de operación diferentes. 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), entonces creará una asignación de trabajo y generará una aplicación. Si se ejecuta dentro 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 supervisando la salida. La salida de la aplicación es vista como salida del comando srun, típicamente en el terminal del usuario. El comando sbatch está diseñado para enviar un script para su posterior ejecución y su la 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 arreglos de trabajos, mientras que srun no lo hace. Otra diferencia significativa es la tolerancia a fallos. Los errores que involucran trabajos sbatch generalmente dan lugar a que el trabajo se vuelva a solicitar y ejecutar, mientras que los errores que involucran srun generalmente dan lugar a que se genere un mensaje de error con la expectativa de que el usuario responderá de una manera apropiada.

 4
Author: dkv,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-05 16:39:37