centro:servizos:hpc

Diferenzas

Isto amosa as diferenzas entre a revisión seleccionada e a versión actual da páxina.

Enlazar a esta vista de comparación

Both sides previous revision Previous revision
Next revision		 Previous revision
Next revisionBoth sides next revision
centro:servizos:hpc [2022/03/07 14:12] – [CONDA] fernando.guillencentro:servizos:hpc [2022/04/11 09:13] – fernando.guillen
Liña 1: Liña 1:
-====== Cluster de Computación de Altas Prestacións (HPC) ======+====== Cluster de Computación de Altas Prestacións (HPC) ctcomp3  ====== 
 +[[ https://web.microsoftstream.com/video/f5eba154-b597-4440-9307-3befd7597d78 | Video de la presentación del servicio (7/3/22) ]]
 ===== Descripción ===== ===== Descripción =====
  
Liña 11: Liña 12:
 Hay un almacenamiento distribuido accesible desde todos los nodos con 220 TB de capacidad conectado mediante una doble red de fibra de 25Gb. \\ Hay un almacenamiento distribuido accesible desde todos los nodos con 220 TB de capacidad conectado mediante una doble red de fibra de 25Gb. \\
 \\ \\
-^  Nombre           ^  Modelo      ^  Procesador   ^  Memoria  ^  GPU  ^ +^  Nombre                    ^  Modelo      ^  Procesador                                     ^  Memoria  ^  GPU                         ^ 
-|    hpc-login2     |  Dell R440    |  1 x Intel Xeon Silver 4208 CPU @ 2.10GHz (8c)  |  16 GB  |  -  | +|  hpc-login2                |  Dell R440   |  1 x Intel Xeon Silver 4208 CPU @ 2.10GHz (8c)  |  16 GB    |  -                           | 
-|    hpc-node[1-2]  |  Dell R740    |  2 x Intel Xeon Gold 5220 @2,2 GHz (18c)  |  192 GB      |   -  | +|  hpc-node[1-2]             |  Dell R740   |  2 x Intel Xeon Gold 5220 @2,2 GHz (18c)        |  192 GB   |  -                           | 
-|    hpc-node[3-9]  |  Dell R740    |  2 x Intel Xeon Gold 5220R @2,2 GHz (24c)                  |      192 GB       |  -  | +|  hpc-node[3-9]             |  Dell R740   |  2 x Intel Xeon Gold 5220R @2,2 GHz (24c)       |  192 GB   |  -                           | 
-|    hpc-fat1       |  Dell R840    |  4 x Xeon Gold 6248 @ 2.50GHz (20c)                 |    1 TB       |  -   | +|  hpc-fat1                  |  Dell R840   |  4 x Xeon Gold 6248 @ 2.50GHz (20c)             |  1 TB     |  -                           | 
-|    hpc-gpu[1-2]   |  Dell R740    |  2 x Intel Xeon Gold 5220 CPU @ 2.20GHz (18c)       |      192 GB      |   2x Nvidia Tesla V100S  | +|  <del>hpc-gpu[1-2]</del>*  |  Dell R740   |  2 x Intel Xeon Gold 5220 CPU @ 2.20GHz (18c)   |  192 GB   |  2x Nvidia Tesla V100S       | 
-|    hpc-gpu3       |  Dell R7525   |  2 x AMD EPYC 7543 @2,80 GHz (32c)   |     256 GB       |  2x Nvidia Ampere A100 40GB   | +|  hpc-gpu3                  |  Dell R7525  |  2 x AMD EPYC 7543 @2,80 GHz (32c)              |  256 GB   |  2x Nvidia Ampere A100 40GB  | 
-|    hpc-gpu4       |  Dell R7525   |  2 x AMD EPYC 7543 @2,80 GHz (32c)    |     256 GB       |  1x Nvidia Ampere A100 80GB   | +|  hpc-gpu4                  |  Dell R7525  |  2 x AMD EPYC 7543 @2,80 GHz (32c)              |  256 GB   |  1x Nvidia Ampere A100 80GB  | 
 +* Son ctgpgpu7 y 8. Se integrarán próximamente en cluster.
 ===== Conexión al sistema ===== ===== Conexión al sistema =====
 Para acceder al clúster, hay que solicitarlo previamente a través de [[https://citius.usc.es/uxitic/incidencias/add|formulario de incidencias]]. Los usuarios que no tengan permiso de acceso recibirán un mensaje de "contraseñal incorrecta". Para acceder al clúster, hay que solicitarlo previamente a través de [[https://citius.usc.es/uxitic/incidencias/add|formulario de incidencias]]. Los usuarios que no tengan permiso de acceso recibirán un mensaje de "contraseñal incorrecta".
Liña 33: Liña 34:
 Cada nodo tiene una partición local de 1 TB para scratch, que se borra al terminar cada trabajo. Se puede acceder mediante la variable de entorno %%$LOCAL_SCRATCH%% en los scripts. \\ Cada nodo tiene una partición local de 1 TB para scratch, que se borra al terminar cada trabajo. Se puede acceder mediante la variable de entorno %%$LOCAL_SCRATCH%% en los scripts. \\
 Para datos que deban ser compartidos por grupos de usuarios, hay que solicitar la creación de una carpeta en el almacenamiento compartido que solo será accesible por los miembros del grupo.\\ Para datos que deban ser compartidos por grupos de usuarios, hay que solicitar la creación de una carpeta en el almacenamiento compartido que solo será accesible por los miembros del grupo.\\
-^  Directorio   ^  Variable   ^  Punto de montaje  ^   Capacidad  ^ +^  Directorio        ^  Variable               ^  Punto de montaje             ^  Capacidad  ^ 
-|  Home     |   %%$HOME%%     |  /mnt/beegfs/home/<username>  |     220 TB*         | +|  Home              |  %%$HOME%%              |  /mnt/beegfs/home/<username>  |  220 TB*    | 
-|  Scratch local  |  %%$LOCAL_SCRATCH%%   |       varía             |     1 TB         | +|  Scratch local     |  %%$LOCAL_SCRATCH%%     |  varía                        |  1 TB       | 
-|  Carpeta de grupo         |     a definir        |  /mnt/beegfs/groups/<nombre>    |   220 TB*    |+|  Carpeta de grupo  |  %% $GRUPOS/<nombre>%%  |  /mnt/beegfs/groups/<nombre>  |  220 TB*    |
 %%* el almacenamiento es compartido%% %%* el almacenamiento es compartido%%
 === AVISO IMPORTANTE === === AVISO IMPORTANTE ===
Liña 112: Liña 113:
 Para usar cualquier otro software no instalado en el sistema u otra versión del mismo hay tres opciones: Para usar cualquier otro software no instalado en el sistema u otra versión del mismo hay tres opciones:
   - Usar Modules con los módulos que ya están instalados (o solicitar la instalación de un nuevo módulo si no está disponible)   - Usar Modules con los módulos que ya están instalados (o solicitar la instalación de un nuevo módulo si no está disponible)
-  - Usar un contenedor (uDocker o Singularity)+  - Usar un contenedor (uDocker o Apptainer/Singularity)
   - Usar Conda   - Usar Conda
 Un módulo es la solución más sencilla para usar software sin modificaciones o dependencias difíciles de satisfacer.\\ Un módulo es la solución más sencilla para usar software sin modificaciones o dependencias difíciles de satisfacer.\\
Liña 146: Liña 147:
 </code> </code>
  
-=== Singularity === +=== Apptainer/Singularity === 
-[[ https://sylabs.io/guides/3.8/user-guide/ | Documentacion de Singularity ]] \\ +[[ https://sylabs.io/guides/3.8/user-guide/ | Documentacion de Apptainer/Singularity ]] \\ 
-Singularity está instalado en el sistema de cada nodo, por lo que no es necesario hacer nada para usarlo.+Apptainer/Singularity está instalado en el sistema de cada nodo, por lo que no es necesario hacer nada para usarlo.
  
  
Liña 162: Liña 163:
  
 ===== Uso de SLURM ===== ===== Uso de SLURM =====
 +El gestor de colas en el cluster es [[ https://slurm.schedmd.com/documentation.html | SLURM ]]. \\
 +<note tip>El término CPU identifica a un core físico de un socket. El hyperthreading está desactivado, por lo que cada nodo tiene disponibles tantas CPU como (nº sockets) * (nº cores físico por socket) tenga.</note>
 +== Recursos disponibles ==
 +<code bash>
 +hpc-login2 ~]$ sinfo -e -o "%30N  %20c  %20m  %20f  %30G " --sort=N
 +# Hay un alias para este comando:
 +hpc-login2 ~]$ ver_recursos
 +NODELIST                        CPUS                  MEMORY                AVAIL_FEATURES        GRES                           
 +hpc-fat1                        80                    1027273               cpu_intel             (null)                         
 +hpc-gpu[1-2]                    36                    187911                cpu_intel             gpu:V100S:2                    
 +hpc-gpu3                        64                    253282                cpu_amd               gpu:A100_40:2                  
 +hpc-gpu4                        64                    253282                cpu_amd               gpu:A100_80:1(S:0)             
 +hpc-node[1-2]                   36                    187645                cpu_intel             (null)                         
 +hpc-node[3-9]                   48                    187645                cpu_intel             (null)
 +</code>
 +==== Nodos ====
 +Un nodo es la unidad de computación de SLURM, y se corresponde con un servidor físico.
 +<code bash>
 +# Mostrar la información de un nodo:
 +hpc-login2 ~]$ scontrol show node hpc-node1
 +NodeName=hpc-node1 Arch=x86_64 CoresPerSocket=18 
 +   CPUAlloc=0 CPUTot=36 CPULoad=0.00
 +   AvailableFeatures=cpu_intel
 +   ActiveFeatures=cpu_intel
 +   Gres=(null)
 +   NodeAddr=hpc-node1 NodeHostName=hpc-node1 Version=21.08.6
 +   OS=Linux 4.18.0-305.el8.x86_64 #1 SMP Wed May 19 18:55:28 EDT 2021 
 +   RealMemory=187645 AllocMem=0 FreeMem=166801 Sockets=2 Boards=1
 +   State=IDLE ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A
 +   Partitions=defaultPartition 
 +   BootTime=2022-03-01T13:13:56 SlurmdStartTime=2022-03-01T15:36:48
 +   LastBusyTime=2022-03-07T14:34:12
 +   CfgTRES=cpu=36,mem=187645M,billing=36
 +   AllocTRES=
 +   CapWatts=n/a
 +   CurrentWatts=0 AveWatts=0
 +   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
 +</code>
 ==== Particiones ==== ==== Particiones ====
 +Las particiones en SLURM son grupos lógicos de nodos. En el cluster hay una única partición a la que pertenecen todos los nodos, por lo que no es necesario especificarla a la hora de enviar trabajos.
 +<code bash>
 +# Mostrar la información de las particiones:
 +hpc-login2 ~]$ sinfo
 +defaultPartition*    up   infinite     11   idle hpc-fat1,hpc-gpu[3-4],hpc-node[1-9]
 +# Cuando se incorporen al cluster ctgpgpu7 y 8 apareceran como los nodos hpc-gpu1 y 2 respectivamente.
 +</code>
 +==== Trabajos ====
 +Los trabajos en SLURM son asignaciones de recursos a un usuario durante un tiempo determinado. Los trabajos se identifican por un número correlativo o JOBID. \\
 +Un trabajo (JOB) consiste en uno o más pasos (STEPS), cada uno consistente en una o más tareas (TASKS) que usan una o más CPU. Hay un STEP por cada programa que se ejecute de forma secuencial en un JOB y hay un TASK por cada programa que se ejecute en paralelo. Por lo tanto en el caso más simple como por ejemplo lanzar un trabajo consistente en ejecutar el comando hostname el JOB tiene un único STEP y una única TASK.
 +
 +==== Sistema de colas (QOS) ====
 +La cola a la que se envíe cada trabajo define la prioridad,los límites y también el "coste" relativo para el usuario.
 +<code bash>
 +# Mostrar las colas
 +hpc-login2 ~]$ sacctmgr show qos
 +# Hay un alias que muestra solo la información más relevante:
 +hpc-login2 ~]$ ver_colas
 +      Name   Priority           Flags UsageFactor                     MaxTRES     MaxWall     MaxTRESPU MaxJobsPU MaxSubmitPU 
 +---------- ---------- --------------- ----------- --------------------------- ----------- ------------- --------- ----------- 
 +   regular        100     DenyOnLimit    1.000000   cpu=200,gres/gpu=1,node=4  4-04:00:00                      10          50 
 +interactive       200     DenyOnLimit    1.000000                      node=1    04:00:00        node=1         1           1 
 +    urgent        300     DenyOnLimit    2.000000           gres/gpu=1,node=1    04:00:00        cpu=36         5          15 
 +      long        100     DenyOnLimit    1.000000           gres/gpu=1,node=4  8-08:00:00                                     
 +     large        100     DenyOnLimit    1.000000          cpu=200,gres/gpu=2  4-04:00:00                      10          25 
 +     admin        500                    0.000000 
 +</code>
 +# Priority: es la prioridad relativa de cada cola. \\
 +# DenyonLimit: el trabajo no se ejecuta si no cumple los límites de la cola \\
 +# UsageFactor: el coste relativo para el usuario de ejecutar un trabajo en esa cola \\
 +# MaxTRES: límites por cada trabajo \\
 +# MaxWall: tiempo máximo que puede estar el trabajo en ejecución \\
 +# MaxTRESPU: límites globales por usuario \\
 +# MaxJobsPU: Número máximo de trabajos que un usuario puede tener en ejecución. \\
 +# MaxSubmitPU: Número máximo de trabajos que un usuario puede tener en total encolados y en ejecucuón.\\
 + 
 +==== Envío de un trabajo al sistema de colas ====
 +== Especificación de recursos ==
 +Por defecto, si se envía un trabajo sin especificar nada el sistema lo envia a la QOS por defecto (regular) y le asigna un nodo, una CPU y toda la memoria disponible. El límite de tiempo para la ejecución del trabajo es el de la cola (4 días y 4 horas). 
 +Esto es muy ineficiente, lo ideal es especificar en la medida de lo posible al menos tres parámetros a la hora de enviar los trabajos:
 +  -  %%El número de nodos (-N o --nodes), tareas (-n o --ntasks) y/o CPU por tarea (-c o --cpus-per-task).%%
 +  -  %%La memoria (--mem) por nodo o la memoria por cpu (--mem-per-cpu).%%
 +  -  %%El tiempo estimado de ejecución del trabajo ( --time )%%
 +
 +A mayores puede ser interesante añadir los siguientes parámetros:
 +|  -J   |  %%--job-name%%  |Nombre para el trabajo. Por defecto: nombre del ejecutable  |
 +|  -q   |  %%--qos%%       |Nombre de la cola a la que se envía el trabajo. Por defecto: regular  |
 +|  -o   |  %%--output%%    |Fichero o patrón de fichero al que se redirige toda la salida estandar y de error.  |
 +|       |  %%--gres%%      |Tipo y/o número de GPUs que se solicitan para el trabajo.  |
 +|  -C   |  %%--constraint%%  |Para especificar que se quieren nodos con procesadores Intel o AMD (cpu_intel o cpu_amd)  |
 +|    |  %%--exclusive%%  |Para solicitar que el trabajo no comparta nodos con otros trabajos.  |
 +|  -w  |  %%--nodelist%%   |Lista de nodos en los que ejecutar el trabajo  |
 +
 +== Cómo se asignan los recursos ==
 +Por defecto el método de asignación entre nodos es la asignación en bloque ( se asignan todos los cores disponibles en un nodo antes de usar otro). El método de asignación por defecto dentro de cada nodo es la asignación cíclica  (se van repartiendo por igual los cores requeridos entre los sockests disponibles en el nodo). 
 +
 +== Calculo de la prioridad ==
 +Cuando se envía un trabajo al sistema de colas, lo primero que ocurre es que se comprueba si los recursos solicitados entran dentro de los límites fijados en la cola correspondiente. Si supera alguno se cancela el envío. \\
 +Si hay recursos disponibles el trabajo se ejecuta directamente, pero si no es así se encola. Cada trabajo tiene asignada una prioridad que determina el orden en que se ejecutan los trabajos de la cola cuando quedan recursos disponibles. Para determinar la prioridad de cada trabajo se ponderan 3 factores: el tiempo que lleva esperando en la cola (25%), la prioridad fija que tiene la cola(25%) y el fairshare del usuario (50%). \\
 +El fairshare es un cálculo dinámico que hace SLURM para cada usuario y es la diferencia entre los recursos asignados y los recursos consumidos a lo largo de los últimos 14 días. 
 +<code bash>
 +hpc-login2 ~]$ sshare -l 
 +      User  RawShares  NormShares    RawUsage   NormUsage   FairShare 
 +---------- ---------- ----------- ----------- -----------  ---------- 
 +                         1.000000     2872400                0.500000 
 +                    1    0.500000     2872400    1.000000    0.250000 
 +user_name         100    0.071429        4833    0.001726    0.246436
 +</code>
 +# RawShares: es la cantidad de recursos en términos absolutos asignada al usuario. Es igual para todos los usuarios.\\
 +# NormShares: Es la cantidad anterior normalizada a los recursos asignados en total.\\
 +# RawUsage: Es la cantidad de segundos/cpu consumida por todos los trabajos del usuario.\\
 +# NormUsage: Cantidad anterior normalizada al total de segundos/cpu consumidos en el cluster.\\
 +# FairShare: El factor FairShare entre 0 y 1. Cuanto mayor uso del cluster, más se aproximará a 0 y menor será la prioridad.\\
 +
 +== Envío de trabajos ==
 +  - salloc
 +  - srun
 +  - sbatch
 +
 +1. SALLOC \\
 +Sirve para obtener de forma inmediata una asignación de recursos (nodos). En cuanto se obtiene se ejecuta el comando especificado o una shell en su defecto. 
 +<code bash>
 +# Obtener 5 nodos y lanzar un trabajo.
 +hpc-login2 ~]$ salloc -N5 myprogram
 +# Obtener acceso interactivo a un nodo (Pulsar Ctrl+D para terminar el acceso):
 +hpc-login2 ~]$ salloc -N1 
 +</code>
 +2. SRUN \\
 +Sirve para lanzar un trabajo paralelo ( es preferible a usar mpirun ). Es interactivo y bloqueante.
 +<code bash>
 +# Lanzar un hostname en 2 nodos
 +hpc-login2 ~]$ srun -N2 hostname
 +hpc-node1
 +hpc-node2
 +</code>
 +3. SBATCH \\
 +Sirve para enviar un script al sistema de colas. Es de procesamiento por lotes y no bloqueante.
 +<code bash>
 +# Crear el script:
 +hpc-login2 ~]$ vim trabajo_ejemplo.sh
 +    #!/bin/bash
 +    #SBATCH --job-name=prueba            # Job name
 +    #SBATCH --nodes=1                    # -N Run all processes on a single node   
 +    #SBATCH --ntasks=1                   # -n Run a single task   
 +    #SBATCH --cpus-per-task=1            # -c Run 1 processor per task       
 +    #SBATCH --mem=1gb                    # Job memory request
 +    #SBATCH --time=00:05:00              # Time limit hrs:min:sec
 +    #SBATCH --qos=urgent                 # Cola
 +    #SBATCH --output=prueba_%j.log       # Standard output and error log
 +
 +    echo "Hello World!"
 +
 +hpc-login2 ~]$ sbatch trabajo_ejemplo.sh 
 +</code>
 +
 ==== Uso de los nodos con GPU ==== ==== Uso de los nodos con GPU ====
-==== Límites del sistema de colas (QOS) ==== +Para solicitar específicamente una asignación de GPUs para un trabajo hay que añadir a sbatch o srun las opciones:  
-==== Ejemplos de envío de un trabajo al sistema de colas ====+|  %%--gres%%  |  Solicitud de gpus por NODE  |  %%--gres=gpu[[:type]:count],...%%  | 
 +|  %%--gpus o -G%%  |  Solicitud de gpus por JOB  |  %%--gpus=[type]:count,...%%  | 
 +También existen las opciones %% --gpus-per-socket,--gpus-per-node y --gpus-per-task%%,\\ 
 +Ejemplos: 
 +<code bash> 
 +## Ver la lista de nodos y gpus: 
 +hpc-login2 ~]$ ver_recursos 
 +## Solicitar 2 GPU cualesquiera para un JOB, añadir: 
 +--gpus=2 
 +## Solicitar una A100 de 40G en un nodo y una A100 de 80G en otro, añadir: 
 +--gres=gpu:A100_40:1,gpu:A100_80:1  
 +</code> 
 + 
 ==== Monitorización de los trabajos ==== ==== Monitorización de los trabajos ====
-==== Salida estándar y de errores ====+<code bash> 
 +## Listado de todos los trabajos en la cola 
 +hpc-login2 ~]$ squeue 
 +## Listado de los trabajos de un usuario             
 +hpc-login2 ~]$ squeue -u <login> 
 +## Cancelar un trabajo: 
 +hpc-login2 ~]$ scancel <JOBID> 
 +## Lista de trabajos recientes 
 +hpc-login2 ~]$ sacct -b 
 +## Información histórica detallada de un trabajo: 
 +hpc-login2 ~]$ sacct -l -j <JOBID> 
 +## Información de debug de un trabajo para troubleshooting: 
 +hpc-login2 ~]$ scontrol show jobid -dd <JOBID> 
 +## Ver el uso de recursos de un trabajo en ejecución: 
 +hpc-login2 ~]$ sstat <JOBID> 
 +</code> 
 +==== Controlar la salida de los trabajos ==== 
 +== Códigos de salida == 
 +Por defecto estos son los códigos de salida de los comandos: 
 +^  SLURM command  ^  Exit code  ^ 
 +|  salloc  |  0 en caso de éxito, 1 si no se puedo ejecutar el comando del usuario  | 
 +|  srun  |  El más alto de entre todas las tareas ejecutadas o 253 para un error out-of-mem  | 
 +|  sbatch  |  0 en caso de éxito, si no, el código de salida correspondiente del proceso que falló  | 
 + 
 +== STDIN, STDOUT y STDERR == 
 +**SRUN:**\\ 
 +Por defecto stdout y stderr se redirigen de todos los TASKS a el stdout y stderr de srun, y stdin se redirecciona desde el stdin de srun a todas las TASKS. Esto se puede cambiar con: 
 +|  %%-i, --input=<opcion>%%    |  
 +|  %%-o, --output=<opcion>%%   | 
 +|  %%-e, --error=<opcion>%%   | 
 +Y las opciones son: 
 +  * //all//: opción por defecto. 
 +  * //none//: No se redirecciona nada. 
 +  * //taskid//: Solo se redirecciona desde y/o al TASK id especificado. 
 +  * //filename//: Se redirecciona todo desde y/o al fichero especificado. 
 +  * //filename pattern//: Igual que filename pero con un fichero definido por un [[ https://slurm.schedmd.com/srun.html#OPT_filename-pattern | patrón ]] 
 + 
 +**SBATCH:**\\ 
 +Por defecto "/dev/null" está abierto en el stdin del script y stdout y stderror se redirigen a un fichero de nombre "slurm-%j.out". Esto se puede cambiar con: 
 +|  %%-i, --input=<filename_pattern>%%  | 
 +|  %%-o, --output=<filename_pattern>%%  | 
 +|  %%-e, --error=<filename_pattern>%%  | 
 +La referencia de filename_pattern está [[ https://slurm.schedmd.com/sbatch.html#SECTION_%3CB%3Efilename-pattern%3C/B%3E | aquí ]]. 
 + 
 +==== Envío de correos ==== 
 +Se pueden configurar los JOBS para que envíen correos en determinadas circunstancias usando estos dos parámetros (**SON NECESARIOS AMBOS**): 
 +|  %%--mail-type=<type>%%  |  Opciones: BEGIN, END, FAIL, REQUEUE, ALL, TIME_LIMIT, TIME_LIMIT_90, TIME_LIMIT_50.  | 
 +|  %%--mail-user=<user>%%  |  La dirección de correo de destino.  | 
 + 
 + 
 ==== Estados de los trabajos en el sistema de colas ==== ==== Estados de los trabajos en el sistema de colas ====
 +<code bash>
 +hpc-login2 ~]# squeue -l
 +JOBID PARTITION     NAME     USER      STATE       TIME  NODES NODELIST(REASON)
 +6547  defaultPa  example <username>  RUNNING   22:54:55      1 hpc-fat1
 +</code>
 +Estados (STATE) más comunes de un trabajo:
 +  * R RUNNING Job currently has an allocation.
 +  * CD COMPLETED Job has terminated all processes on all nodes with an exit code of zero. 
 +  * F FAILED Job terminated with non-zero exit code or other failure condition.
 +  * PD PENDING Job is awaiting resource allocation.
 + 
 +[[ https://slurm.schedmd.com/squeue.html#SECTION_JOB-STATE-CODES | Lista completa de posibles estados de un trabajo ]].\\
 +
 +Si un trabajo no está en ejecución aparecerá una razón debajo de REASON:[[ https://slurm.schedmd.com/squeue.html#SECTION_JOB-REASON-CODES | Lista de las razones ]] por las que un trabajo puede estar esperando su ejecución.
 +
 +
 +
  
  
  • centro/servizos/hpc.txt
  • Última modificación: 2023/03/27 10:39
  • por fernando.guillen