Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| es:centro:servizos:hpc [2017/10/06 10:34] – diego.cougil | es:centro:servizos:hpc [2024/10/08 09:56] (actual) – [CONDA] jorge.suarez | ||
|---|---|---|---|
| Línea 1: | Línea 1: | ||
| - | ====== Computación de Altas Prestaciones | + | ====== |
| + | [[ https:// | ||
| + | ===== Descripción | ||
| + | El clúster está compuesto en la parte de cómputo por: | ||
| + | * 9 servidores para cómputo general. | ||
| + | * 1 "fat node" para trabajos que requieran mucha memoria. | ||
| + | * 4 servidores para computo con GPU. | ||
| + | |||
| + | Los usuarios solo tienen acceso directo al nodo de login, de prestaciones más limitadas y que no debe usarse para computar. \\ | ||
| + | Todos los nodos están interconectados por una red a 10Gb. \\ | ||
| + | Hay un almacenamiento distribuido accesible desde todos los nodos con 220 TB de capacidad conectado mediante una doble red de fibra de 25Gb. \\ | ||
| + | \\ | ||
| + | ^ Nombre | ||
| + | | hpc-login2 | ||
| + | | hpc-node[1-2] | ||
| + | | hpc-node[3-9] | ||
| + | | hpc-fat1 | ||
| + | | hpc-gpu[1-2] | ||
| + | | hpc-gpu3 | ||
| + | | hpc-gpu4 | ||
| - | ===== Acceso | + | ===== Conexión |
| + | Para acceder al clúster, hay que solicitarlo previamente a través de [[https:// | ||
| - | El acceso se hace a través de una máquina que actúa como // | + | El acceso se realiza mediante |
| + | <code bash> | ||
| + | ssh < | ||
| + | </ | ||
| - | Antes de acceder por primera vez, lee atentamente | + | ===== Almacenamiento, |
| + | <note warning> No se hace copia de seguridad de ninguno de los sistemas de ficheros del cluster!!</ | ||
| + | El HOME de los usuarios en el cluster está en el sistema compartido de ficheros, por lo que es accesible desde todos los nodos del cluster. Ruta definida en la variable de entorno %%$HOME%%. \\ | ||
| + | Cada nodo tiene una partición local de 1 TB para scratch, que se borra al terminar cada trabajo. Se puede acceder | ||
| + | Para datos que deban ser compartidos | ||
| + | ^ Directorio | ||
| + | | Home | %%$HOME%% | ||
| + | | Scratch local | ||
| + | | Carpeta de grupo | %% $GRUPOS/< | ||
| + | %%* el almacenamiento es compartido%% | ||
| + | === AVISO IMPORTANTE === | ||
| + | El sistema | ||
| + | * Crear el fichero de imagen en tu home: | ||
| + | <code bash> | ||
| + | ## truncate image.name -s SIZE_IN_BYTES | ||
| + | truncate ejemplo.ext4 -s 20G | ||
| + | </ | ||
| + | * Crear un sistema de archivos en el fichero de imagen: | ||
| + | <code bash> | ||
| + | ## mkfs.ext4 -T small -m 0 image.name | ||
| + | ## -T small opciones optimizadas para archivos pequeños | ||
| + | ## -m 0 No reservar espacio para root | ||
| + | mkfs.ext4 -T small -m 0 ejemplo.ext4 | ||
| + | </ | ||
| + | * Montar la imagen (usando SUDO) con el script | ||
| + | <code bash> | ||
| + | ## Por defecto queda montada en / | ||
| + | sudo mount_image.py ejemplo.ext4 | ||
| + | </ | ||
| + | * Para desmontar la imagen usar el script // | ||
| - | ===== Introducción | + | El script de montaje tiene estas opciones: |
| + | < | ||
| + | --mount-point path < | ||
| + | --rw <-- (opcional)Por defecto se monta readonly, con esta opción se monta readwrite. | ||
| + | </ | ||
| + | El script de desmontaje tiene estas opciones: | ||
| + | < | ||
| + | --mount-point | ||
| + | </ | ||
| + | ===== | ||
| + | === SCP === | ||
| + | Desde tu máquina local al cluster: | ||
| + | <code bash> | ||
| + | scp filename < | ||
| + | </ | ||
| + | Desde el cluster a tu máquina local: | ||
| + | <code bash> | ||
| + | scp filename < | ||
| + | </ | ||
| + | [[https:// | ||
| + | === SFTP === | ||
| + | Para transferir múltiples archivos o para navegar por el sistema de archivos. | ||
| + | <code bash> | ||
| + | < | ||
| + | sftp> | ||
| + | sftp> ls | ||
| + | sftp> cd < | ||
| + | sftp> put < | ||
| + | sftp> get < | ||
| + | sftp> quit | ||
| + | </ | ||
| + | [[https:// | ||
| + | === RSYNC === | ||
| + | [[ https:// | ||
| + | === SSHFS === | ||
| + | Requiere la instalación del paquete sshfs.\\ | ||
| + | Permite por ejemplo montar el home del equipo del usuario en hpc-login2: | ||
| + | <code bash> | ||
| + | ## Montar | ||
| + | sshfs < | ||
| + | ## Desmontar | ||
| + | fusermount -u < | ||
| + | </ | ||
| + | [[https:// | ||
| - | ==== Funcionamiento básico de un clúster de computación | + | ===== Software disponible |
| + | Todos los nodos tienen el software básico que se instala por defecto con AlmaLinux 8.4, particularmente: | ||
| + | * GCC 8.5.0 | ||
| + | * Python 3.6.8 | ||
| + | * Perl 5.26.3 | ||
| + | En los nodos con GPU, además: | ||
| + | * nVidia Driver 510.47.03 | ||
| + | * CUDA 11.6 | ||
| + | * libcudnn 8.7 | ||
| - | El Cluster de Computación | + | 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 | ||
| + | - Usar un contenedor | ||
| + | - Usar Conda | ||
| + | Un módulo es la solución más sencilla para usar software sin modificaciones o dependencias difíciles de satisfacer.\\ | ||
| + | Un contenedor es ideal cuando las dependencias son complicadas y/o el software está muy personalizado. También es la mejor solución si lo que se busca es reproducibilidad, | ||
| + | Conda es la mejor solución si lo que se necesita es la última versión de una librería o programa o paquetes no disponibles | ||
| - | Un **cluster de computación** se compone de un conjunto de nodos interconectados mediante una red dedicada que puede actuar como un único elemento computacional. Esto proporciona una gran potencia, permitiendo la ejecución de trabajos paralelos muy grandes o muchas ejecuciones pequeñas de forma concurrente. | ||
| - | Un **sistema | + | ==== Uso de modules/Lmod ==== |
| + | [[ https://lmod.readthedocs.io/en/ | ||
| + | <code bash> | ||
| + | # Ver los módulos disponibles: | ||
| + | module avail | ||
| + | # Cargar un módulo: | ||
| + | module < | ||
| + | # Descargar un módulo: | ||
| + | module unload < | ||
| + | # Ver módulos cargados en tu entorno: | ||
| + | module list | ||
| + | # Puede usarse ml como abreviatura del comando module: | ||
| + | ml avail | ||
| + | # Para obtener información sobre un módulo: | ||
| + | ml spider < | ||
| + | </code> | ||
| - | La dinámica de funcionamiento de un sistema de este tipo es la siguiente: | ||
| - | - El usuario solicita la ejecución de una tarea((Normalmente un script de //bash//)) con unos recursos determinados. | ||
| - | - El sistema registra la solicitud en una de sus colas de entrada((Típicamente //batch//)) y, según la cantidad de recursos solicitados, | ||
| - | - En función de la prioridad de la cola de sistema (a menores recursos necesarios, mayor prioridad) y de la disponibilidad de los recursos en el sistema, la tarea se enviará a uno o varios de los nodos computacionales. Al terminar la ejecución, se devolverá la salida generada. | ||
| - | Lo habitual es que la ejecución tenga que **esperar en la cola** hasta que los recursos estén disponibles y preparados. Además, resulta imposible realizar así ejecuciones de manera interactiva((Sin embargo, existe una cola interactiva especial para ejecuciones interactivas, | ||
| - | ==== Descripción del hardware | + | ==== Ejecución de contenedores de software |
| - | El clúster **ctcomp2** es un clúster heterogéneo, | + | === uDocker ==== |
| + | [[ https://indigo-dc.gitbook.io/udocker/user_manual | Manual de uDocker]] \\ | ||
| + | udocker está instalado como un módulo, así que es necesario cargarlo en el entorno: | ||
| + | <code bash> | ||
| + | ml uDocker | ||
| + | </code> | ||
| - | ^ Nombre del nodo ^ Modelo | + | === Apptainer/Singularity === |
| - | | node1-7 | + | [[ https:// |
| - | | inode11-15 | Dell PowerEdge M910 - Procesadores Intel Xeon L | 64 (4, 4, 8, 1) | 64GB | + | Apptainer/ |
| - | | inode16-20 | + | |
| - | Internamente los nodos computacionales están conectados entre sí a través de varias redes 10 GbE dedicadas. La conexión desde el exterior es de 1Gb. | ||
| - | Casi todos los nodos, a excepción de //node1// e //inode20// se apagan cuando no se están utilizando durante un rato, lo que podría causar retrasos de varios minutos en la cola aunque el cluster aparentemente esté desocupado. | + | ==== CONDA ==== |
| + | [[ https://docs.conda.io/en/latest/ | ||
| + | Miniconda es la versíon mínima de Anaconda y solo incluye el gestor de entornos conda, Python y unos pocos paquetes necesarios. A partir de ahí cada usuario solo descarga | ||
| + | <code bash> | ||
| + | # Obtener miniconda | ||
| + | wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh | ||
| + | # Instalarlo | ||
| + | bash Miniconda3-latest-Linux-x86_64.sh | ||
| + | # Inicializar miniconda para el shell bash | ||
| + | ~/ | ||
| + | </ | ||
| - | [[ | + | ===== Uso de SLURM ===== |
| - | ==== Descripción del software | + | El gestor de colas en el cluster es [[ https:// |
| - | El sistema operativo es //Debian GNU/Linux 8.6 (jessie)//. | + | <note tip>El término CPU identifica a un core físico de un socket. El hyperthreading está desactivado, |
| + | == Recursos disponibles == | ||
| + | <code bash> | ||
| + | hpc-login2 ~]# ver_estado.sh | ||
| + | ============================================================================================================= | ||
| + | NODO | ||
| + | ============================================================================================================= | ||
| + | | ||
| + | | ||
| + | | ||
| + | hpc-gpu3 up | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | ============================================================================================================= | ||
| + | TOTALES: [Cores : 3/688] [Mem(MB): 270000/3598464] [GPU: 3/ 7] | ||
| - | El sistema de colas que gestiona los trabajos es PBS/Torque, apoyado por CLUES para mejorar la gestión de energía. | + | hpc-login2 ~]$ sinfo -e -o " |
| + | # Hay un alias para este comando: | ||
| + | hpc-login2 ~]$ ver_recursos | ||
| + | NODELIST | ||
| + | hpc-fat1 | ||
| + | hpc-gpu[1-2] | ||
| + | hpc-gpu3 | ||
| + | hpc-gpu4 | ||
| + | hpc-node[1-2] | ||
| + | hpc-node[3-9] | ||
| - | * [[http://docs.adaptivecomputing.com/maui/ | + | # Para ver el uso actual de los recursos: (CPUS (Allocated/Idle/Other/Total)) |
| - | | + | hpc-login2 ~]$ sinfo -N -r -O NodeList, |
| - | * [[http://www.grycap.upv.es/ | + | # Hay un alias para este comando: |
| + | hpc-login2 ~]$ ver_uso | ||
| + | NODELIST | ||
| + | hpc-fat1 | ||
| + | hpc-gpu3 | ||
| + | hpc-gpu4 | ||
| + | hpc-node1 | ||
| + | hpc-node2 | ||
| + | hpc-node3 | ||
| + | hpc-node4 36/12/ | ||
| + | hpc-node5 | ||
| + | hpc-node6 | ||
| + | hpc-node7 | ||
| + | hpc-node8 | ||
| + | hpc-node9 | ||
| + | </ | ||
| + | ==== 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 | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | </ | ||
| + | ==== 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* | ||
| + | # 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. | ||
| - | El sistema permite compilar | + | ==== Sistema de colas (QOS) ==== |
| - | ===== Sistema | + | La cola a la que se envíe cada trabajo define la prioridad, |
| + | <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 | ||
| + | ---------- | ||
| + | | ||
| + | interactive | ||
| + | urgent | ||
| + | long | ||
| + | | ||
| + | | ||
| + | | ||
| + | </code> | ||
| + | # Priority: es la prioridad relativa de cada cola. \\ | ||
| + | # DenyonLimit: | ||
| + | # UsageFactor: | ||
| + | # 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 | ||
| + | == Especificación de recursos == | ||
| + | Por defecto, si se envía un trabajo sin especificar nada el sistema lo envía a la QOS por defecto (regular) y le asigna un nodo, una CPU y 4GB de RAM. 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, | ||
| + | - %%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 )%% | ||
| - | El sistema de colas tiene cuatro **colas de entrada** y ocho **colas del sistema**. Un usuario | + | A mayores puede ser interesante añadir los siguientes parámetros: |
| + | | -J | ||
| + | | -q | ||
| + | | -o | ||
| + | | | ||
| + | | -C | ||
| + | | | %%--exclusive%% | ||
| + | | -w | %%--nodelist%% | ||
| - | Para enviar un trabajo al sistema de colas, | + | == Cómo se asignan los recursos == |
| + | Por defecto | ||
| - | ^ Cola ^ Número máximo | + | == Calculo |
| - | | '' | + | Cuando se envía un trabajo al sistema |
| - | | '' | + | Si hay recursos disponibles el trabajo se ejecuta directamente, |
| - | | '' | + | 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 | ||
| + | User RawShares | ||
| + | ---------- ---------- ----------- ----------- ----------- | ||
| + | 1.000000 | ||
| + | 1 | ||
| + | user_name | ||
| + | </ | ||
| + | # 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 | ||
| + | # NormUsage: Cantidad anterior normalizada al total de segundos/ | ||
| + | # FairShare: El factor FairShare entre 0 y 1. Cuanto mayor uso del cluster, más se aproximará a 0 y menor será la prioridad.\\ | ||
| - | Los recursos que se pueden solicitar y que determinarán la cola del sistema utilizada son: | + | == Envío de trabajos == |
| + | - sbatch | ||
| + | - salloc | ||
| + | - srun | ||
| - | * El número de nodos | ||
| - | * El número de núcleos por nodo | ||
| - | * El tiempo de ejecución | ||
| - | La memoria máxima asignada depende de la cola del sistema | + | 1. SBATCH \\ |
| + | Sirve para enviar un script al sistema | ||
| + | <code bash> | ||
| + | # Crear el script: | ||
| + | hpc-login2 ~]$ vim trabajo_ejemplo.sh | ||
| + | # | ||
| + | #SBATCH --job-name=prueba | ||
| + | #SBATCH --nodes=1 | ||
| + | #SBATCH --ntasks=1 | ||
| + | #SBATCH --cpus-per-task=1 | ||
| + | #SBATCH --mem=1gb | ||
| + | #SBATCH --time=00: | ||
| + | #SBATCH --qos=urgent | ||
| + | #SBATCH --output=prueba_%j.log # Standard output and error log | ||
| - | Los recursos pueden solicitarse de dos formas: como comentarios al inicio del script, o con el parámetro '' | + | echo "Hello World!" |
| - | Comprueba los límites existentes en las colas del sistema, | + | hpc-login2 ~]$ sbatch trabajo_ejemplo.sh |
| + | </ | ||
| + | 2. SALLOC \\ | ||
| + | Sirve para obtener de forma inmediata una asignación | ||
| + | <code bash> | ||
| + | # Obtener 5 nodos y lanzar un trabajo. | ||
| + | hpc-login2 ~]$ salloc -N5 myprogram | ||
| + | # Obtener acceso interactivo | ||
| + | hpc-login2 ~]$ salloc -N1 | ||
| + | # Obtener acceso interactivo a un nodo de forma EXCLUSIVA | ||
| + | hpc-login2 ~]$ salloc -N1 --exclusive | ||
| + | </ | ||
| + | 3. 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 | ||
| + | </ | ||
| - | ^ ^ Límites | ||
| - | ^ Cola ^ Núcleos((parámetro '' | ||
| - | | '' | ||
| - | | '' | ||
| - | | '' | ||
| - | | '' | ||
| - | | '' | ||
| - | | '' | ||
| - | | '' | ||
| - | | '' | ||
| - | Puedes leer más sobre [[es:centro:servizos:hpc:escribir_script |cómo preparar | + | ==== Uso de los nodos con GPU ==== |
| + | Para solicitar específicamente una asignación de GPUs para un trabajo hay que añadir a sbatch o srun las opciones: | ||
| + | | %%--gres%% | ||
| + | | %%--gpus o -G%% | Solicitud de gpus por JOB | %%--gpus=[type]:count, | ||
| + | También existen las opciones %% --gpus-per-socket, | ||
| + | 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: | ||
| + | </ | ||
| + | |||
| + | |||
| + | ==== Monitorización de los trabajos | ||
| + | <code bash> | ||
| + | ## Listado de todos los trabajos en la cola | ||
| + | hpc-login2 ~]$ squeue | ||
| + | ## Listado de los trabajos de un usuario | ||
| + | hpc-login2 ~]$ squeue -u < | ||
| + | ## Cancelar un trabajo: | ||
| + | hpc-login2 ~]$ scancel < | ||
| + | ## Lista de trabajos recientes | ||
| + | hpc-login2 ~]$ sacct -b | ||
| + | ## Información histórica detallada de un trabajo: | ||
| + | hpc-login2 ~]$ sacct -l -j < | ||
| + | ## Información de debug de un trabajo | ||
| + | hpc-login2 ~]$ scontrol show jobid -dd < | ||
| + | ## Ver el uso de recursos de un trabajo en ejecución: | ||
| + | hpc-login2 ~]$ sstat < | ||
| + | </ | ||
| + | ==== Controlar la salida de los trabajos ==== | ||
| + | == Códigos de salida == | ||
| + | Por defecto estos son los códigos de salida de los comandos: | ||
| + | ^ SLURM command | ||
| + | | salloc | ||
| + | | srun | El más alto de entre todas las tareas ejecutadas o 253 para un error out-of-mem | ||
| + | | sbatch | ||
| + | |||
| + | == 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=< | ||
| + | | %%-o, --output=< | ||
| + | | %%-e, --error=< | ||
| + | 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 pattern//: Igual que filename pero con un fichero definido por un [[ https:// | ||
| + | |||
| + | **SBATCH: | ||
| + | Por defecto "/ | ||
| + | | %%-i, --input=< | ||
| + | | %%-o, --output=< | ||
| + | | %%-e, --error=< | ||
| + | La referencia de filename_pattern está [[ https:// | ||
| + | |||
| + | ==== 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=< | ||
| + | | %%--mail-user=< | ||
| + | |||
| + | |||
| + | |||
| + | ==== Estados de los trabajos en el sistema de colas ==== | ||
| + | <code bash> | ||
| + | hpc-login2 ~]# squeue -l | ||
| + | JOBID PARTITION | ||
| + | 6547 defaultPa | ||
| + | |||
| + | ## Ver estado de uso de las colas del cluster: | ||
| + | hpc-login2 ~]$ estado_colas.sh | ||
| + | JOBS PER USER: | ||
| + | -------------- | ||
| + | | ||
| + | | ||
| + | |||
| + | JOBS PER QOS: | ||
| + | -------------- | ||
| + | | ||
| + | long: 1 | ||
| + | |||
| + | JOBS PER STATE: | ||
| + | -------------- | ||
| + | | ||
| + | | ||
| + | ========================================== | ||
| + | Total JOBS in cluster: | ||
| + | </ | ||
| + | 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:// | ||
| + | |||
| + | Si un trabajo no está en ejecución aparecerá | ||