LDAP: couldn't connect to LDAP server
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
en:centro:servizos:hpc [2016/05/23 12:42] – fernando.guillen | en:centro:servizos:hpc [2022/06/30 10:58] – fernando.guillen | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
+ | [[ https:// | ||
+ | ===== Descripción | ||
- | ===== Quick usage instructions ===== | + | El clúster está compuesto en la parte de cómputo por: |
- | ---------------- | + | |
- | A summary of the steps necessary to get a job done: | + | * 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 | Dell R840 | ||
+ | | < | ||
+ | | hpc-gpu2 | Dell R740 | ||
+ | | hpc-gpu3 | Dell R7525 | 2 x AMD EPYC 7543 @2,80 GHz (32c) | 256 GB | ||
+ | | hpc-gpu4 | Dell R7525 | 2 x AMD EPYC 7543 @2,80 GHz (32c) | 256 GB | ||
+ | * Es ctgpgpu8. Se integrará próximamente en cluster. | ||
+ | ===== Conexión al sistema ===== | ||
+ | Para acceder al clúster, hay que solicitarlo previamente | ||
- | - [[ es: | + | El acceso se realiza mediante una conexión SSH al nodo de login: |
- | - [[ es: | + | <code bash> |
- | - [[ es: | + | ssh < |
+ | </ | ||
+ | ===== 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 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.\\ | ||
+ | ^ Directorio | ||
+ | | Home | %%$HOME%% | ||
+ | | Scratch local | ||
+ | | Carpeta de grupo | %% $GRUPOS/< | ||
+ | %%* el almacenamiento es compartido%% | ||
+ | === AVISO IMPORTANTE === | ||
+ | El sistema compartido de archivos tiene un mal rendimiento cuando trabaja con muchos archivos de tamaño pequeño. Para mejorar el rendimiento en ese tipo de escenarios hay que crear un sistema de archivos en un fichero de imagen y montarlo para trabajar directamente sobre él. El procedimiento es el siguiente: | ||
+ | * 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 // | ||
+ | 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 | ||
+ | </ | ||
+ | ===== Transferencia de ficheros y datos ===== | ||
+ | === 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:// | ||
- | ===== Introduction | + | ===== Software disponible |
- | ------------- | + | Todos los nodos tienen el software básico que se instala por defecto con AlmaLinux 8.4, particularmente: |
- | High Performance Computing (HPC from now on) infrastructures offer CITIUS researchers a platform to resolve problems with high computational requirements. A computational cluster is an set of nodes interconnected by a dedicated network that can act as a single computational element. This offers a huge computational power (allowing the execution of a big parallel job or several concurrent small executions) in a shared infrastructure. | + | * GCC 8.5.0 |
+ | * Python 3.6.8 | ||
+ | * Perl 5.26.3 | ||
- | A queue management system is a program that plans how and when jobs will execute using the available computational resources. | + | 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 un contenedor (uDocker o Apptainer/ | ||
+ | - 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 de otra forma.\\ | ||
- | The way these systems work is: | ||
- | - The user requests some resources to the queue manager for a computational task. This task is a set of instructions written in a script. | ||
- | - The queue manager assigns the request to one of its queues. | ||
- | - When the requested resources are available and depending on the priorities established by the system, the queue manager executes the task and stores the output. | ||
- | It is important to note that the request and the execution of a given task are independent actions that are not resolved atomically. In fact it is usual that the execution of the task has to wait in one of the queues until the requested resources are available. Also, interactive use is impossible. | + | ==== Uso de modules/ |
+ | [[ https:// | ||
+ | <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 < | ||
+ | </ | ||
- | ==== Hardware description ==== | ||
- | Ctcomp2 is a heterogeneous cluster, composed of 8 HP Proliant BL685c G7, 5 Dell PowerEdge M910 and 5 Dell PowerEdge M620 nodes. | ||
- | * Each HP Proliant node has 4 AMD Opteron 6262 HE (16 cores) processors and 256 GB RAM(except node1 and the master with 128GB). | ||
- | * Each Dell PowerEdge M910 node has 2 Intel Xeon L7555 (8 cores, 16 threads) processors and 64 GB RAM. | ||
- | * Each Dell PowerEdge M620 node has 2 Intel Xeon E5-2650L (8 cores, 16 threads) processors and 64 GB RAM. | ||
- | * Connection with the cluster is made at 1Gb but nodes are connected between them by several 10 GbE networks. | ||
+ | ==== Ejecución de contenedores de software ==== | ||
+ | === uDocker ==== | ||
+ | [[ https:// | ||
+ | uDocker está instalado como un módulo, así que es necesario cargarlo en el entorno: | ||
+ | <code bash> | ||
+ | ml uDocker | ||
+ | </ | ||
- | ==== Software description ==== | + | === Apptainer/ |
- | The job management is done by the queue manager PBS/TORQUE. To improve energetic efficiency an on demand power on and off system called CLUES has been implemented. | + | [[ https://sylabs.io/ |
+ | Apptainer/ | ||
- | * [[http:// | ||
- | * [[http:// | ||
- | * [[http:// | ||
- | ===== User queues ===== | + | ==== CONDA ==== |
- | ------------- | + | [[ https:// |
+ | 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 e instala los paquetes que necesita. | ||
+ | <code bash> | ||
+ | # Obtener miniconda | ||
+ | wget https:// | ||
+ | # Instalarlo | ||
+ | sh Miniconda3-py39_4.11.0-Linux-x86_64.sh | ||
+ | </ | ||
- | There are four user and eight system queues. The user queues are //routing// queues that set, depending on the number of computational numbers requested, the system queue in which each job is going to be executed. Users can't send their jobs directly to the system queues, jobs have to be submitted to the user queues. | + | ===== 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.</ | ||
+ | == Recursos disponibles == | ||
+ | <code bash> | ||
+ | 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] | ||
- | Independently of the type of queue used for job submissions, an user can only specify the following parameters: **node number**, **process number per node** and ** execution time**. Size of memory assigned and maximum execution time of a job are determined by the system queue in which the job gets routed. Jobs that exceed those limits during execution will be canceled. | + | # Para ver el uso actual de los recursos: (CPUS (Allocated/ |
- | Therefore for jobs in which both memory and execution time are critical it is recommended to modify the number of process requested | + | hpc-login2 ~]$ sinfo -N -r -O NodeList,CPUsState, |
- | __To execute jobs that don't adjust to queue parameters get in touch with the IT department.__ | + | # 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 | ||
+ | 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. | ||
+ | </ | ||
+ | ==== Trabajos ==== | ||
+ | Los trabajos en SLURM son asignaciones de recursos | ||
+ | Un trabajo | ||
- | User queues are '' | + | ==== Sistema de colas (QOS) ==== |
- | | + | La cola a la que se envíe cada trabajo define la prioridad,los límites y también el " |
- | | + | <code bash> |
- | < | + | # Mostrar las colas |
- | ct$ qsub -q short script.sh | + | hpc-login2 ~]$ sacctmgr show qos |
+ | # Hay un alias que muestra solo la información más relevante: | ||
+ | hpc-login2 ~]$ ver_colas | ||
+ | Name | ||
+ | ---------- ---------- --------------- ----------- --------------------------- ----------- ------------- --------- ----------- | ||
+ | | ||
+ | interactive | ||
+ | urgent | ||
+ | long 100 | ||
+ | large 100 | ||
+ | | ||
</ | </ | ||
- | * '' | + | # Priority: es la prioridad relativa de cada cola. \\ |
- | < | + | # DenyonLimit: |
- | ct$ qsub -q bigmem script.sh | + | # 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: | ||
+ | |||
+ | ==== 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, | ||
+ | | ||
+ | - %%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 | ||
+ | | | ||
+ | | -o | ||
+ | | | ||
+ | | -C | ||
+ | | | %%--exclusive%% | ||
+ | | -w | %%--nodelist%% | ||
+ | |||
+ | == 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 | ||
+ | |||
+ | == 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, | ||
+ | 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. | ||
+ | < | ||
+ | hpc-login2 ~]$ sshare | ||
+ | User RawShares | ||
+ | ---------- ---------- ----------- ----------- ----------- | ||
+ | | ||
+ | 1 0.500000 | ||
+ | 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 |
- | ct$ qsub -q interactive | + | # 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 == | ||
+ | | ||
+ | - 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. | ||
+ | < | ||
+ | # Obtener 5 nodos y lanzar un trabajo. | ||
+ | hpc-login2 ~]$ salloc | ||
+ | # Obtener acceso interactivo a un nodo (Pulsar Ctrl+D para terminar el acceso): | ||
+ | hpc-login2 ~]$ salloc | ||
</ | </ | ||
+ | 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 | ||
+ | </ | ||
+ | 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 | ||
+ | #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 | ||
- | The system queues are '' | + | echo "Hello World!" |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | The following table summarizes the characteristics of the user and system queues; | + | hpc-login2 ~]$ sbatch trabajo_ejemplo.sh |
+ | </ | ||
- | ^ Queue ^ Limits | + | ==== Uso de los nodos con GPU ==== |
- | | ::: ^ Processes | + | Para solicitar específicamente una asignación de GPUs para un trabajo hay que añadir a sbatch o srun las opciones: |
- | | '' | + | | |
- | | '' | + | | %%--gpus o -G%% |
- | | '' | + | 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 para troubleshooting: | ||
+ | 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 | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | == 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**): | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |||
+ | ==== Estados de los trabajos en el sistema de colas ==== | ||
+ | <code bash> | ||
+ | hpc-login2 ~]# squeue -l | ||
+ | JOBID PARTITION | ||
+ | 6547 defaultPa | ||
+ | </ | ||
+ | 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á una razón debajo de REASON:[[ https:// | ||
- | * Processes: Maximum number of processes by job in this queue. | ||
- | * Nodes: Maximum numbers of nodes in which the job will be executed. | ||
- | * Memory: Maximum virtual memory concurrently used by all the job processes. | ||
- | * Jobs/user: Maximum number of jobs per user regardless of their state. | ||
- | * Maximum time (hours): Maximum real time during which the job can be in the execution state. | ||
- | * Priority: Priority of the execution queue related to the other queues. A higher value means more priority. Please note that lacking other criteria, any job sent with qsub will by default be executed in np1 using its limits. |