srun - Online en la nube

PROGRAMA:

NOMBRE

srun - Ejecutar trabajos paralelos

SINOPSIS

correr [OPCIONES...] ejecutable [args...]

DESCRIPCIÓN

Ejecute un trabajo paralelo en un clúster administrado por Slurm. Si es necesario, srun primero creará un
asignación de recursos para ejecutar el trabajo paralelo.

El siguiente documento describe la influencia de varias opciones en la asignación de
cpus a trabajos y tareas.
http://slurm.schedmd.com/cpu_management.html

OPCIONES

--accel-bind=<opciones>
Controle cómo las tareas están vinculadas a los recursos genéricos de tipo gpu, mic y nic.
Se pueden especificar varias opciones. Las opciones admitidas son las siguientes:

g Vincula cada tarea a las GPU más cercanas a las CPU asignadas.

m Vincule cada tarea a los MIC que estén más cerca de las CPU asignadas.

n Vincule cada tarea a las NIC más cercanas a las CPU asignadas.

v Modo detallado. Registre cómo las tareas están vinculadas a los dispositivos GPU y NIC.

-A, --cuenta=<.>
Cargue los recursos utilizados por este trabajo a la cuenta especificada. los . es un
cadena arbitraria. El nombre de la cuenta puede cambiarse después del envío del trabajo usando el
control mando.

--acctg-freq
Defina la contabilidad del trabajo y los intervalos de muestreo de perfiles. Esto se puede utilizar para
anular el JobAcctGatherFrecuencia parámetro en el archivo de configuración de Slurm,
slurm.conf. El formato admitido es el siguiente:

--acctg-freq ==
donde = especifica el intervalo de muestreo de la tarea para
el complemento jobacct_gather o un intervalo de muestreo para un tipo de perfil
por el complemento acct_gather_profile. Múltiples, separados por comas
= se pueden especificar intervalos. Tipos de datos admitidos
son los siguientes:

tarea =
donde es el intervalo de muestreo de la tarea en segundos para
los complementos jobacct_gather y para la creación de perfiles de tareas por parte del
complemento acct_gather_profile. NOTA: Esta frecuencia se utiliza para
monitorear el uso de la memoria. Si se aplican los límites de memoria, los más altos
La frecuencia que un usuario puede solicitar es la configurada en el
archivo slurm.conf. Tampoco pueden apagarlo (= 0).

energía =
donde es el intervalo de muestreo en segundos para energía
creación de perfiles utilizando el complemento acct_gather_energy

red =
donde es el intervalo de muestreo en segundos para
Perfiles infiniband utilizando el complemento acct_gather_infiniband.

sistema de archivos =
donde es el intervalo de muestreo en segundos para
creación de perfiles del sistema de archivos mediante el complemento acct_gather_filesystem.

El valor predeterminado para el intervalo de muestreo de la tarea
es 30. El valor predeterminado para todos los demás intervalos es 0. Un intervalo de 0 desactiva
muestreo del tipo especificado. Si el intervalo de muestreo de la tarea es 0, la contabilidad
La información se recopila solo al finalizar el trabajo (lo que reduce la interferencia de Slurm con
el trabajo).
Los valores más pequeños (distintos de cero) tienen un mayor impacto en el desempeño laboral, pero un valor
de 30 segundos no es probable que se note para aplicaciones que tienen menos de
10,000 tareas.

-B --información-extra-nodo=<tomas[:núcleos[:hilos]]>
Solicite una asignación específica de recursos con detalles en cuanto al número y tipo
de recursos computacionales dentro de un clúster: número de sockets (o
procesadores) por nodo, núcleos por socket y subprocesos por núcleo. La cantidad total de
Los recursos solicitados son el producto de todos los términos. Cada valor especificado
se considera un mínimo. Se puede utilizar un asterisco (*) como marcador de posición que indica
que se utilizarán todos los recursos disponibles de ese tipo. Al igual que con los nodos, el
Los niveles individuales también se pueden especificar en opciones separadas si se desea:
--sockets-por-nodo=<tomas>
- núcleos por socket=<núcleos>
- hilos por núcleo=<hilos>
Si el complemento de tarea / afinidad está habilitado, especificar una asignación de esta manera
también establece un valor predeterminado --cpu_bind opción de hilos si el -B opción especifica una
recuento de hilos, de lo contrario una opción de núcleos si se especifica un recuento de núcleos, de lo contrario
una opción de tomas. Si SelectType está configurado para seleccionar / cons_res, debe tener
un parámetro de CR_Core, CR_Core_Memory, CR_Socket o CR_Socket_Memory para esto
opción de ser honrado. Esta opción no es compatible con los sistemas BlueGene.
(el complemento select / bluegene está configurado). Si no se especifica, el scontrol show job
mostrará 'ReqS: C: T = *: *: *'.

--cama y desayuno=<especulación>
Especificación de búfer de ráfagas. La forma de la especificación depende del sistema.
Ver también --bbf.

--bbf=<file_name>
Ruta del archivo que contiene la especificación del búfer de ráfagas. La forma de la especificación
depende del sistema. Ver también --cama y desayuno.

--bcast[=ruta_destino>]
Copie el archivo ejecutable en los nodos de cálculo asignados. Si se especifica un nombre de archivo, copie
el ejecutable a la ruta del archivo de destino especificado. Si no se especifica ninguna ruta,
copie el archivo a un archivo llamado "slurm_bcast_ . " en la corriente
laboral. Por ejemplo, "srun --bcast = / tmp / mine -N3 a.out" copiará el archivo
"a.out" de su directorio actual al archivo "/ tmp / mine" en cada uno de los tres
asignados nodos de cálculo y ejecutar ese archivo.

--empezar=<time>
Aplazar el inicio de este trabajo hasta la hora especificada. Acepta tiempos del
formulario HH: MM: SS para ejecutar un trabajo a una hora específica del día (los segundos son opcionales). (Si
que el tiempo ya ha pasado, se asume el día siguiente.) También puede especificar
medianoche, mediodía, fika (3 p. M.) O la hora del té (4 p. M.) Y puede tener una hora del día
con el sufijo AM or PM para correr por la mañana o por la noche. También puede decir
qué día se ejecutará el trabajo, especificando una fecha del formulario MMDDAA or MM / DD / AA
AAAA-MM-DD. Combinar fecha y hora usando el siguiente formato
AAAA-MM-DD [THH: MM [: SS]]. También puedes dar momentos como ahora + contar unidades de tiempo, donde el
las unidades de tiempo pueden ser segundos (Predeterminado), minutos, horas, díaso semanas. y se puede
dígale a Slurm que ejecute el trabajo hoy con la palabra clave hoy y hacer el trabajo mañana
con la palabra clave mañana. El valor se puede cambiar después del envío del trabajo usando el
control mando. Por ejemplo:
- comienzo = 16:00
--comienzo = ahora + 1 hora
--begin = ahora + 60 (segundos por defecto)
--begin=2010-01-20T12:34:00

Notas sobre las especificaciones de fecha / hora:
- Aunque el campo 'segundos' de la especificación de tiempo HH: MM: SS está permitido por
el código, tenga en cuenta que el tiempo de sondeo del programador Slurm no es lo suficientemente preciso para
Garantizar el envío del trabajo en el segundo exacto. El trabajo será elegible para
comenzar en la siguiente encuesta después de la hora especificada. El intervalo exacto de la encuesta
depende del programador Slurm (por ejemplo, 60 segundos con el programa predeterminado / incorporado).
- Si no se especifica ninguna hora (HH: MM: SS), el valor predeterminado es (00:00:00).
- Si se especifica una fecha sin un año (por ejemplo, MM / DD), el año actual es
asumido, a menos que la combinación de MM / DD y HH: MM: SS ya haya pasado para ese
año, en cuyo caso se utiliza el año siguiente.

--control=<time>
Especifica el intervalo entre la creación de puntos de control del paso del trabajo. Por defecto,
el paso de trabajo no tendrá puntos de control creados. Los formatos de hora aceptables incluyen
"minutos", "minutos: segundos", "horas: minutos: segundos", "días-horas",
"días-horas: minutos" y "días-horas: minutos: segundos".

--punto de control-dir=<directorio>
Especifica el directorio en el que se debe ubicar el trabajo o el punto de control del paso del trabajo.
escrito (utilizado solo por los complementos checkpoint / blcr y checkpoint / xlch). El
El valor predeterminado es el directorio de trabajo actual. Los archivos de punto de control serán de
formulario " .ckpt "para trabajos y" . .ckpt "para ver los pasos del trabajo.

--comentario=<cadena>
Un comentario arbitrario.

-C, --restricción=<lista>
Los nodos pueden tener Características asignado por el administrador de Slurm. Los usuarios pueden
especificar cuál de estos Características son requeridos por su trabajo usando la restricción
opción. Solo los nodos que tengan características que coincidan con las restricciones del trabajo se utilizarán para
satisfacer la solicitud. Se pueden especificar múltiples restricciones con AND, OR, matching
O, recuentos de recursos, etc. Las opciones de restricción admitidas incluyen:

Individual Nombre
Solo se utilizarán los nodos que tengan la característica especificada. Por ejemplo,
--constraint = "intel"

Nodo Contar
Una solicitud puede especificar la cantidad de nodos necesarios con alguna característica por
agregar un asterisco y contar después del nombre de la función. Por ejemplo
"--nodos = 16 --constraint = graphics * 4 ... " indica que el trabajo requiere 16
nodos y que al menos cuatro de esos nodos deben tener la característica
"gráficos."

Y Si solo se utilizarán nodos con todas las características especificadas. El ampersand es
utilizado para un operador AND. Por ejemplo, --constraint = "intel y gpu"

OR Si solo se utilizarán nodos con al menos una de las características especificadas. los
La barra vertical se utiliza para un operador OR. Por ejemplo,
--constraint = "intel | amd"

Emparejar OR
Si solo se debe usar una de un conjunto de opciones posibles para todos los
nodos, luego use el operador OR y encierre las opciones dentro del cuadrado
soportes. Por ejemplo: "--constraint = [rack1 | rack2 | rack3 | rack4] " puede ser
se utiliza para especificar que todos los nodos deben asignarse en un solo bastidor del
clúster, pero se puede utilizar cualquiera de esos cuatro bastidores.

Múltiple Cuenta
Los recuentos específicos de varios recursos se pueden especificar mediante el uso de AND
operador y encerrando las opciones entre corchetes. Por ejemplo:
"--constraint = [rack1 * 2 y rack2 * 4] " podría usarse para especificar que dos nodos
deben asignarse desde nodos con la característica de "rack1" y cuatro nodos deben
ser asignados desde nodos con la característica "rack2".

ADVERTENCIA: Cuando srun se ejecuta desde dentro de salloc o sbatch,
el valor de restricción solo puede contener un único nombre de característica. Ninguno de los otros
Los operadores actualmente son compatibles con los pasos del trabajo.

--contiguo
Si se establece, los nodos asignados deben formar un conjunto contiguo. No honrado con el
topología / árbol or topología / 3d_torus complementos, los cuales pueden modificar el nodo
ordenar. No honrado por la asignación de un paso de trabajo.

- núcleos por socket=<núcleos>
Restringir la selección de nodos a nodos con al menos el número especificado de núcleos por
enchufe. Ver información adicional en -B opción anterior cuando el complemento de tarea / afinidad
está habilitado.

--cpu_bind= [{tranquilo, detallado},]tipo
Vincular tareas a las CPU. Se usa solo cuando el complemento de tarea / afinidad o tarea / cgroup está
activado. El parámetro de configuración TaskPluginParam puede anular estas opciones.
Por ejemplo, si TaskPluginParam está configurado para unirse a núcleos, su trabajo no
ser capaz de vincular tareas a sockets. NOTA: Para que Slurm informe siempre sobre el
enlace de CPU seleccionado para todos los comandos ejecutados en un shell, puede habilitar verbose
modo estableciendo el valor de la variable de entorno SLURM_CPU_BIND en "verbose".

Las siguientes variables de entorno informativas se establecen cuando --cpu_bind será en
utilizar:
SLURM_CPU_BIND_VERBOSE
SLURM_CPU_BIND_TYPE
SLURM_CPU_BIND_LIST

Consulte las MEDIO AMBIENTE VARIABLES sección para una descripción más detallada de la
variables SLURM_CPU_BIND individuales. Estas variables están disponibles solo si el
El complemento de tarea / afinidad está configurado.

Cuando usas --cpus-por-tarea para ejecutar tareas multiproceso, tenga en cuenta que el enlace de la CPU es
heredado del padre del proceso. Esto significa que la tarea multiproceso
debe especificar o borrar el enlace de la CPU para evitar tener todos los subprocesos
de la tarea multiproceso utiliza la misma máscara / CPU que la principal. Alternativamente, grasa
máscaras (máscaras que especifican más de una CPU permitida) podrían usarse para las tareas
con el fin de proporcionar varias CPU para las tareas multiproceso.

De forma predeterminada, un paso de trabajo tiene acceso a cada CPU asignada al trabajo. Para asegurar
que se asignan distintas CPU a cada paso del trabajo, utilice el --exclusivo .

Tenga en cuenta que a un paso de trabajo se le pueden asignar diferentes números de CPU en cada nodo o
CPU asignadas que no comienzan en la ubicación cero. Por tanto, una de las opciones que
Se recomienda generar automáticamente el enlace de tareas. Máscaras explícitamente especificadas
o las vinculaciones solo se respetan cuando el paso de trabajo se ha asignado a todos los disponibles
CPU en el nodo.

Vincular una tarea a un dominio de localidad NUMA significa vincular la tarea al conjunto de CPU
que pertenecen al dominio de localidad NUMA o "nodo NUMA". Si dominio de localidad NUMA
las opciones se utilizan en sistemas sin soporte NUMA, entonces cada socket se considera un
dominio de localidad.

Auto Encuadernación
Se aplica solo cuando la tarea / afinidad está habilitada. Si la asignación del paso del trabajo
incluye una asignación con un número de sockets, núcleos o subprocesos igual a
el número de tareas multiplicado por cpus-por-tarea, entonces las tareas serán por defecto
enlazado a los recursos apropiados (enlace automático). Desactive este modo de
operación estableciendo explícitamente "--cpu_bind = none". Usar
TaskPluginParam = autobind = [hilos | núcleos | sockets] para establecer una CPU predeterminada
vinculante en caso de que la "vinculación automática" no encuentre una coincidencia.

Las opciones admitidas incluyen:

tranquilo]
Enlazar silenciosamente antes de que se ejecute la tarea (predeterminado)

verboso]
Informe detallado de la vinculación antes de que se ejecute la tarea

ninguno] No vincule tareas a CPU (predeterminado a menos que se aplique el enlace automático)

clasificar Enlazar automáticamente por rango de tarea. La tarea con el número más bajo en cada
el nodo está vinculado a socket (o núcleo o subproceso) cero, etc. No compatible
a menos que todo el nodo esté asignado al trabajo.

map_cpu:
Enlazar mediante la asignación de ID de CPU a tareas como se especifica donde es
, ... . El mapeo se especifica para un nodo
y se aplica un mapeo idéntico a las tareas en cada nodo (es decir, el
El ID de tarea más bajo en cada nodo se asigna al primer ID de CPU especificado
en la lista, etc.). Los ID de CPU se interpretan como valores decimales a menos que
van precedidos de '0x', en cuyo caso se interpretan como
valores hexadecimales. No es compatible a menos que todo el nodo esté
asignado al trabajo.

mask_cpu:
Enlazar estableciendo máscaras de CPU en tareas como se especifica donde es
, ... . El mapeo se especifica para un nodo y
Se aplica un mapeo idéntico a las tareas en cada nodo (es decir, el
El ID de tarea más bajo en cada nodo se asigna a la primera máscara especificada en
la lista, etc.). Las máscaras de CPU son always interpretado como hexadecimal
valores, pero puede ir precedido de un '0x' opcional. No soportado
a menos que todo el nodo esté asignado al trabajo.

rango_ldom
Vincularse a un dominio de localidad NUMA por rango. No es compatible a menos que el
todo el nodo está asignado al trabajo.

map_ldom:
Vincular mediante la asignación de ID de dominio de localidad NUMA a tareas como se especifica donde
es , ... . Los ID de dominio de localidad son
interpretados como valores decimales a menos que estén precedidos por '0x' en
cuyo caso se interpretan como valores hexadecimales. No soportado
a menos que todo el nodo esté asignado al trabajo.

mask_ldom:
Enlazar mediante la configuración de máscaras de dominio de localidad NUMA en las tareas según lo especificado
donde es , ... . Dominio de localidad NUMA
las mascaras son always interpretado como valores hexadecimales pero puede ser
precedido de un '0x' opcional. No se admite a menos que todo el nodo
se asigna al trabajo.

tomas
Genere automáticamente máscaras vinculando tareas a sockets. Solo las CPU
en el socket que se ha asignado al trabajo. Si
el número de tareas difiere del número de sockets asignados este
puede resultar en una unión subóptima.

núcleos Genere automáticamente máscaras vinculando tareas a núcleos. Si el numero
de tareas difiere del número de núcleos asignados, esto puede resultar
en unión subóptima.

hilos
Genere automáticamente máscaras vinculando tareas a subprocesos. Si el numero
de tareas difiere del número de subprocesos asignados, esto puede resultar
en unión subóptima.

ldoms Genere automáticamente tareas vinculantes de máscaras a dominios de localidad NUMA.
Si el número de tareas difiere del número de localidad asignada
dominios, esto puede resultar en una unión subóptima.

tablas Genere automáticamente máscaras vinculando tareas a tableros. Si el numero
de tareas difiere del número de tableros asignados, esto puede resultar
en unión subóptima. Esta opción es compatible con task / cgroup
solo complemento.

ayuda Mostrar mensaje de ayuda para cpu_bind

--cpu-frecuencia =<p1[-p2[:p3]]>

Solicite que el paso de trabajo iniciado por este comando srun se ejecute en algunos casos solicitados
frecuencia, si es posible, en las CPU seleccionadas para el paso en los nodos de cálculo.

p1 puede ser [#### | bajo | medio | alto | highm1] que establecerá la frecuencia
scaling_speed al valor correspondiente, y establezca la frecuencia scaling_governor en
UserSpace. Consulte a continuación la definición de los valores.

p1 puede ser [conservador | OnDemand | Rendimiento | PowerSave] que establecerá el
scaling_governor al valor correspondiente. El gobernador tiene que estar en la lista establecida
mediante la opción slurm.conf CpuFreqGovernors.

Cuándo p2 está presente, p1 será la frecuencia mínima de escalado y p2 será el
frecuencia máxima de escalado.

p2 puede ser [#### | medio | alto | highm1] p2 debe ser mayor que p1.

p3 puede ser [conservador | OnDemand | Rendimiento | PowerSave | UserSpace] que
establecerá el gobernador en el valor correspondiente.

If p3 es UserSpace, la frecuencia scaling_speed será establecida por una potencia o energía
estrategia de programación consciente a un valor entre p1 y p2 que permite que el trabajo se ejecute dentro
el objetivo de poder del sitio. El trabajo puede retrasarse si p1 es mayor que una frecuencia que
permite que el trabajo se ejecute dentro de la meta.

Si la frecuencia actual es <min, se establecerá en min. Asimismo, si la corriente
la frecuencia es> máx., se establecerá en máx.

Los valores aceptables en la actualidad incluyen:

#### frecuencia en kilohercios

Baja la frecuencia más baja disponible

Alta la frecuencia más alta disponible

AltoM1 (alto menos uno) seleccionará la siguiente frecuencia más alta disponible

Mediana intenta establecer una frecuencia en el medio del rango disponible

Conservador intenta usar el gobernador de CPU conservador

Bajo demanda intenta utilizar el regulador de CPU OnDemand (el valor predeterminado)

Desempeno intenta utilizar el regulador de CPU de rendimiento

Ahorro de energía intenta utilizar el regulador de CPU PowerSave

Espacio de usuario intenta utilizar el regulador de CPU UserSpace

La siguiente variable de entorno informativa se establece en el trabajo
paso cuando --cpu-frecuencia se solicita la opción.
SLURM_CPU_FREQ_REQ

Esta variable de entorno también se puede utilizar para proporcionar el valor de la CPU.
solicitud de frecuencia si se establece cuando se emite el comando 'srun'. los --cpu-frecuencia
en la línea de comando anulará el valor de la variable de entorno. El formulario en el
La variable de entorno es la misma que la línea de comando. Ver el MEDIO AMBIENTE
VARIABLES sección para obtener una descripción de la variable SLURM_CPU_FREQ_REQ.

NOTA: Este parámetro se trata como una solicitud, no como un requisito. Si el paso del trabajo es
El nodo no admite la configuración de la frecuencia de la CPU o el valor solicitado está fuera
los límites de las frecuencias legales, se registra un error, pero el paso del trabajo es
Permitido continuar.

NOTA: Establecer la frecuencia solo para las CPU del paso de trabajo implica que el
las tareas se limitan a esas CPU. Si el confinamiento de tareas (es decir,
TaskPlugin = tarea / afinidad o TaskPlugin = tarea / cgroup con los "ConstrainCores"
opción) no está configurado, este parámetro se ignora.

NOTA: Cuando se completa el paso, la frecuencia y el regulador de cada CPU seleccionada se
restablecer a lo configurado CPUFreqDef valor con un valor predeterminado de la CPU OnDemand
gobernador.

NOTA: Al enviar trabajos con el --cpu-frecuencia opción con linuxproc como
ProctrackType puede hacer que los trabajos se ejecuten demasiado rápido antes de que Contabilidad pueda sondear
para obtener información sobre el trabajo. Como resultado, no estará presente toda la información contable.

-c, --cpus-por-tarea=<ncpus>
Solicita eso ncpus ser asignado per . Esto puede resultar útil si el trabajo está
multiproceso y requiere más de una CPU por tarea para un rendimiento óptimo. El
el valor predeterminado es una CPU por proceso. Si -c se especifica sin -n, ya que muchas tareas
ser asignado por nodo como sea posible mientras se satisface el -c restricción. Por ejemplo
en un clúster con 8 CPU por nodo, una solicitud de trabajo para 4 nodos y 3 CPU por tarea
Se pueden asignar 3 o 6 CPU por nodo (1 o 2 tareas por nodo) dependiendo de
consumo de recursos por otros trabajos. Es posible que un trabajo de este tipo no pueda ejecutar más de un
total de 4 tareas. Esta opción también puede ser útil para generar tareas sin asignar
recursos al paso del trabajo desde la asignación del trabajo cuando se ejecutan varios pasos del trabajo
con el --exclusivo .

ADVERTENCIA: Hay configuraciones y opciones que se interpretan de manera diferente por trabajo y
solicitudes de pasos de trabajo que pueden resultar en inconsistencias para esta opción. Por ejemplo
correr -c2 - hilos por núcleo = 1 prog puede asignar dos núcleos para el trabajo, pero si cada uno
de esos núcleos contiene dos subprocesos, la asignación de trabajo incluirá cuatro CPU. El
La asignación de pasos de trabajo lanzará dos subprocesos por CPU para un total de dos tareas.

ADVERTENCIA: Cuando srun se ejecuta desde dentro de salloc o sbatch, hay
configuraciones y opciones que pueden resultar en asignaciones inconsistentes cuando -c tiene
un valor mayor que -c en salloc o sbatch.

-d, --dependencia=<lista_dependencias>
Aplazar el inicio de este trabajo hasta que se hayan satisfecho las dependencias especificadas
terminado. Esta opción no se aplica a los pasos del trabajo (ejecuciones de srun dentro de un
asignación de salloc o sbatch existente) solo para asignaciones de trabajo.lista_dependencias>
es de la formatipo: job_id [: job_id] [, tipo: job_id [: job_id]]> o
<tipo: job_id [: job_id] [? tipo: job_id [: job_id]]>. Todas las dependencias deben satisfacerse
si se utiliza el separador ",". Cualquier dependencia puede satisfacerse si el "?" separador
se utiliza. Muchos trabajos pueden compartir la misma dependencia y estos trabajos pueden incluso pertenecer a
diferentes usuarios. El valor puede cambiarse después del envío del trabajo usando el scontrol
mando. Una vez que una dependencia laboral falla debido al estado de terminación de un
trabajo, el trabajo dependiente nunca se ejecutará, incluso si el trabajo anterior está en cola y
tiene un estado de terminación diferente en una ejecución posterior.

after: job_id [: jobid ...]
Este trabajo puede comenzar a ejecutarse después de que los trabajos especificados hayan comenzado a ejecutarse.

afterany: job_id [: jobid ...]
Este trabajo puede comenzar a ejecutarse después de que hayan terminado los trabajos especificados.

afternotok: job_id [: jobid ...]
Este trabajo puede comenzar a ejecutarse después de que los trabajos especificados hayan terminado en
algún estado fallido (código de salida distinto de cero, fallo del nodo, tiempo de espera agotado, etc.).

afterok: job_id [: jobid ...]
Este trabajo puede comenzar a ejecutarse después de que los trabajos especificados se hayan realizado correctamente.
ejecutado (se ejecutó hasta completarse con un código de salida de cero).

expandir: job_id
Los recursos asignados a este trabajo deben usarse para expandir el trabajo especificado.
El trabajo a expandir debe compartir la misma QOS (Quality of Service) y
dividir. La programación grupal de recursos en la partición tampoco es
soportado.

Singleton
Este trabajo puede comenzar a ejecutarse después de cualquier trabajo iniciado previamente que comparta el
mismo nombre de trabajo y usuario han terminado.

-D, --chdir=<camino>
Haga que los procesos remotos hagan un chdir para camino antes de comenzar la ejecución. El
por defecto es chdir al directorio de trabajo actual del correr proceso. El camino
se puede especificar como ruta completa o ruta relativa al directorio donde el comando
es ejecutado.

-e, --error=<modo>
Especifique cómo se redirigirá stderr. Por defecto en modo interactivo, correr
redirige stderr al mismo archivo que stdout, si se especifica uno. El --error
Se proporciona la opción para permitir que stdout y stderr sean redirigidos a diferentes
ubicaciones. Ver IO Redirección a continuación para ver más opciones. Si el archivo especificado
ya existe, se sobrescribirá.

-E, --preservar-env
Pasar los valores actuales de las variables de entorno SLURM_NNODES y SLURM_NTASKS
a través de la ejecutable, en lugar de calcularlos a partir de parámetros de la línea de comandos.

--epílogo=<ejecutable>
correr correrá ejecutable justo después de que se completa el paso del trabajo. La linea de comando
argumentos para ejecutable será el comando y los argumentos del paso del trabajo. Si
ejecutable es "none", entonces no se ejecutará ningún epílogo srun. Este parámetro anula el
Parámetro SrunEpilog en slurm.conf. Este parámetro es completamente independiente de
el parámetro Epilog en slurm.conf.

--exclusive [= usuario]
Esta opción tiene dos significados ligeramente diferentes para las asignaciones de trabajos y pasos de trabajo.
Cuando se utiliza para iniciar un trabajo, la asignación de trabajo no puede compartir nodos con otros
trabajos en ejecución (o simplemente otros usuarios con la opción "= usuario"). El valor por defecto
El comportamiento compartido / exclusivo depende de la configuración del sistema y de la partición.
Compartido La opción tiene prioridad sobre la opción del trabajo.

Esta opción también se puede utilizar al iniciar más de un paso de trabajo dentro de un
asignación de recursos existente, donde desea que se dediquen procesadores separados a
cada paso del trabajo. Si no hay suficientes procesadores disponibles para iniciar el paso del trabajo,
será diferido. Puede pensarse que esto proporciona un mecanismo para
gestión al trabajo dentro de su asignación.

La asignación exclusiva de CPU solo se aplica a los pasos de trabajo invocados explícitamente con
los --exclusivo opción. Por ejemplo, a un trabajo se le puede asignar un nodo con cuatro
CPU y un shell remoto invocados en el nodo asignado. Si ese caparazón no se invoca
con el --exclusivo opción, entonces puede crear un paso de trabajo con cuatro tareas usando
los --exclusivo opción y no entrar en conflicto con el recurso del shell remoto
asignación. Utilizar el --exclusivo opción para invocar cada paso del trabajo para asegurar distintos
recursos para cada paso.

Tenga en cuenta que todas las CPU asignadas a un trabajo están disponibles para cada paso del trabajo a menos que
--exclusivo se utiliza la opción más se configura la afinidad de tareas. Desde recurso
la gestión es proporcionada por el procesador, el --tareas se debe especificar la opción, pero la
NO se deben especificar las siguientes opciones --relativo, --distribución=arbitrario.
See EJEMPLO abajo.

--exportar=<entorno las variables | NINGUNO>
Identifique qué variables de entorno se propagan a la aplicación iniciada.
Los nombres de variables de entorno múltiples deben estar separados por comas. Ambiente
Los nombres de las variables se pueden especificar para propagar el valor actual de esas variables.
(por ejemplo, "--export = EDITOR") o se pueden exportar valores específicos para las variables
(por ejemplo, "--export = EDITOR = / bin / vi") además de las variables de entorno que
de lo contrario se establecería. De forma predeterminada, se propagan todas las variables de entorno.

--gid=<grupo de XNUMX>
If correr se ejecuta como root, y el --gid se utiliza la opción, envíe el trabajo con grupo de XNUMX's
permisos de acceso de grupo. grupo de XNUMX puede ser el nombre del grupo o el ID numérico del grupo.

--gres=<lista>
Especifica una lista delimitada por comas de recursos consumibles genéricos. El formato de
cada entrada de la lista es "nombre [[: tipo]: recuento]". El nombre es el del
recurso consumible. El recuento es el número de esos recursos con un valor predeterminado
valor de 1. Los recursos especificados se asignarán al trabajo en cada nodo.
Los recursos consumibles genéricos disponibles son configurables por el sistema
administrador. Se imprimirá una lista de los recursos consumibles genéricos disponibles.
y el comando saldrá si el argumento de la opción es "ayuda". Ejemplos de uso
incluyen "--gres = gpu: 2, mic = 1", "--gres = gpu: kepler: 2" y "--gres = ayuda". NOTA: Por
Por defecto, a un paso de trabajo se le asignan todos los recursos genéricos que se han asignado
al trabajo. Para cambiar el comportamiento de modo que a cada paso del trabajo no se le asigne ningún
recursos, establezca explícitamente el valor de --gres para especificar cero recuentos para cada
recurso genérico O establecer "--gres = none" O establecer el entorno SLURM_STEP_GRES
variable a "ninguna".

-H, --sostener
Especifique que el trabajo se enviará en estado retenido (prioridad cero). Un trabajo retenido
ahora se puede liberar usando scontrol para restablecer su prioridad (por ejemplo, "control ,
").

-h, --ayuda
Mostrar información de ayuda y salir.

--insinuación=<tipo>
Vincular tareas de acuerdo con las sugerencias de la aplicación.

computar_enlazado
Seleccione la configuración para aplicaciones vinculadas a la computación: use todos los núcleos en cada
zócalo, un hilo por núcleo.

enlazado a la memoria
Seleccione la configuración para las aplicaciones limitadas a la memoria: use solo un núcleo en cada
zócalo, un hilo por núcleo.

[no] multihilo
[no] use subprocesos adicionales con subprocesos múltiples en el núcleo que pueden beneficiar
aplicaciones de comunicación intensiva. Solo se admite con la tarea / afinidad
.

ayuda muestra este mensaje de ayuda

-I, --inmediato[=segundos>]
Salga si los recursos no están disponibles dentro del período de tiempo especificado. Si no
se da el argumento, los recursos deben estar disponibles inmediatamente para que la solicitud
triunfar. Por defecto, --inmediato está apagado, y el comando se bloqueará hasta que
los recursos están disponibles. Dado que el argumento de esta opción es opcional, para
El análisis de la opción de una sola letra debe ir seguido inmediatamente con el valor y
No incluir un espacio entre ellos. Por ejemplo, "-I60" y no "-I 60".

-i, --aporte=<modo>
Especifique cómo se redirigirá stdin. Por defecto, correr redirige stdin desde el
terminal todas las tareas. Ver IO Redirección a continuación para ver más opciones. Para OS X, el
La función poll () no admite stdin, por lo que la entrada desde una terminal no es posible.

-J, --nombre del trabajo=<nombre de trabajo>
Especifique un nombre para el trabajo. El nombre especificado aparecerá junto con la identificación del trabajo.
número al consultar trabajos en ejecución en el sistema. El predeterminado es el suministrado
ejecutable nombre del programa. NOTA: Esta información puede escribirse en el
archivo slurm_jobacct.log. Este archivo está delimitado por espacios, por lo que si se utiliza un espacio en el
nombre de trabajo nombre, causará problemas para mostrar correctamente el contenido del
slurm_jobacct.log cuando el sacar Se utiliza el comando.

--Identificación del trabajo=<Identificación del trabajo>
Iniciar un paso de trabajo debajo de un trabajo ya asignado con ID de trabajo id. Usando esto
la opción causará correr comportarse exactamente como si el entorno SLURM_JOB_ID
se estableció la variable.

-K, --matar-en-mala-salida[= 0 | 1]
Controla si finalizar o no un trabajo si alguna tarea sale con una salida distinta de cero
código. Si no se especifica esta opción, la acción predeterminada se basará en la
Parámetro de configuración Slurm de KillOnBadSalir. Si se especifica esta opción,
tendrá prioridad sobre KillOnBadSalir. Un argumento de opción de cero no
terminar el trabajo. Un argumento distinto de cero o ningún argumento terminará el trabajo.
Nota: esta opción tiene prioridad sobre la -W, --Espere opción para terminar el trabajo
inmediatamente si una tarea sale con un código de salida distinto de cero. Dado que esta opción
El argumento es opcional, para un análisis adecuado se debe seguir la opción de una sola letra
inmediatamente con el valor y no incluir un espacio entre ellos. Por ejemplo, "-K1"
y no "-K 1".

-k, --no matar
No finalice automáticamente un trabajo si uno de los nodos se le ha asignado
falla. Esta opción solo se reconoce en una asignación de trabajo, no para el envío
de los pasos del trabajo individual. El trabajo asumirá todas las responsabilidades de
Tolerancia a fallos. Las tareas que se inicien con esta opción no se considerarán finalizadas.
(p.ej -K, --matar-en-mala-salida y -W, --Espere opciones no tendrán ningún efecto sobre el
paso de trabajo). El paso de trabajo activo (trabajo MPI) probablemente sufrirá un error fatal, pero
Se pueden ejecutar los pasos de trabajo posteriores si se especifica esta opción. La acción predeterminada es
para terminar el trabajo en caso de falla del nodo.

--lanzamiento-cmd
Imprima el comando de inicio externo en lugar de ejecutar el trabajo normalmente a través de Slurm. Esta
La opción solo es válida si se usa algo que no sea el lanzamiento / slurm .

--lanzador-opciones=<opciones>
Opciones para el lanzador externo si usa algo diferente al lanzamiento / slurm
.

-l, --etiqueta
Anteponga el número de tarea a las líneas de stdout / err. El --etiqueta la opción antepondrá líneas
de salida con la identificación de la tarea remota.

-L, --licencias=<licencia>
Especificación de licencias (u otros recursos disponibles en todos los nodos del
cluster) que debe asignarse a este trabajo. Los nombres de las licencias pueden ir seguidos de un
dos puntos y recuento (el recuento predeterminado es uno). Múltiples nombres de licencia deben ser comas.
separados (por ejemplo, "--licenses = foo: 4, bar").

-m, --distribución=
*|bloquear|cíclico|arbitrario|plano = [:*|bloquear|cíclico|cíclico[:*|bloquear|
cíclico|cíclico]] [,.|Sin Paquete]

Especifique métodos de distribución alternativos para procesos remotos. Esta opción controla
la distribución de tareas a los nodos en los que se han asignado recursos, y
la distribución de esos recursos a las tareas para la vinculación (afinidad de tareas). La primera
El método de distribución (antes del primer ":") controla la distribución de tareas a
nodos. El segundo método de distribución (después del primer ":") controla el
distribución de CPU asignadas a través de sockets para enlazar a tareas. El tercero
El método de distribución (después del segundo ":") controla la distribución de los
CPU en los núcleos para vincularlas a tareas. Se aplican las distribuciones segunda y tercera.
solo si la afinidad de tareas está habilitada. La tercera distribución es compatible solo si el
El complemento task / cgroup está configurado. El valor predeterminado para cada tipo de distribución es
especificado por *.

Tenga en cuenta que con select / cons_res, el número de CPU asignadas en cada socket y
El nodo puede ser diferente. Referirse a http://slurm.schedmd.com/mc_support.html
información sobre la asignación de recursos, la distribución de tareas a los nodos y la vinculación de
tareas a las CPU.
Primer método de distribución (distribución de tareas entre nodos):

* Utilice el método predeterminado para distribuir tareas a los nodos (bloque).

bloquear El método de distribución de bloques distribuirá las tareas a un nodo de manera que
las tareas consecutivas comparten un nodo. Por ejemplo, considere una asignación de tres
nodos cada uno con dos cpus. Una solicitud de distribución de bloques de cuatro tareas
distribuya esas tareas a los nodos con las tareas uno y dos en la primera
nodo, tarea tres en el segundo nodo y tarea cuatro en el tercer nodo. Cuadra
La distribución es el comportamiento predeterminado si el número de tareas excede el
número de nodos asignados.

cíclico El método de distribución cíclica distribuirá las tareas a un nodo de manera que
las tareas consecutivas se distribuyen en nodos consecutivos (en un round-robin
Moda). Por ejemplo, considere una asignación de tres nodos cada uno con dos
cpus. Una solicitud de distribución cíclica de cuatro tareas distribuirá esas tareas a
los nodos con las tareas uno y cuatro en el primer nodo, la tarea dos en el segundo
nodo y la tarea tres en el tercer nodo. Tenga en cuenta que cuando SelectType es
select / cons_res, es posible que no se asigne el mismo número de CPU en cada nodo.
La distribución de tareas será por turnos entre todos los nodos con CPU aún por
ser asignado a tareas. La distribución cíclica es el comportamiento predeterminado si el
El número de tareas no es mayor que el número de nodos asignados.

avión Las tareas se distribuyen en bloques de un tamaño específico. Las opciones
incluir un número que represente el tamaño del bloque de tareas. Esto es seguido
mediante una especificación opcional del esquema de distribución de tareas dentro de un bloque
de tareas y entre los bloques de tareas. El número de tareas distribuidas
a cada nodo es el mismo que para la distribución cíclica, pero los taskids
asignados a cada nodo dependen del tamaño del plano. Para obtener más detalles (incluido
ejemplos y diagramas), consulte
http://slurm.schedmd.com/mc_support.html
y
http://slurm.schedmd.com/dist_plane.html

arbitrario
El método arbitrario de distribución asignará los procesos en orden como
enumerados en el archivo designado por la variable de entorno SLURM_HOSTFILE. Si
esta variable aparece en la lista y anulará cualquier otro método especificado. Si
no establecido, el método se bloqueará por defecto. Dentro del archivo host debe contener
como mínimo el número de hosts solicitados y ser uno por línea o coma
apartado. Si especifica un recuento de tareas (-n, --tareas=<número>), tus tareas
se distribuirá en los nodos en el orden del archivo.
NOTA: La opción de distribución arbitraria en una asignación de trabajo solo controla
los nodos que se asignarán al trabajo y no la asignación de CPU en esos
nodos. Esta opción está destinada principalmente a controlar el diseño de la tarea de un paso de trabajo en
una asignación de trabajo existente para el comando srun.

Segundo método de distribución (distribución de CPU a través de sockets para enlace):

* Utilice el método predeterminado para distribuir CPU entre sockets (cíclico).

bloquear El método de distribución de bloques distribuirá las CPU asignadas consecutivamente
desde el mismo socket para enlazar a las tareas, antes de usar el siguiente
enchufe.

cíclico El método de distribución cíclica distribuirá las CPU asignadas para enlazar a
una tarea dada consecutivamente desde el mismo zócalo, y desde el siguiente
socket consecutivo para la siguiente tarea, en forma de turnos a través de
enchufes

cíclico
El método de distribución cíclica distribuirá las CPU asignadas para la vinculación
a tareas de sockets consecutivos en forma de turnos en todo el
enchufes

Tercer método de distribución (distribución de CPU a través de núcleos para enlace):

* Utilice el método predeterminado para distribuir CPU entre núcleos (heredado de
segundo método de distribución).

bloquear El método de distribución de bloques distribuirá las CPU asignadas consecutivamente
desde el mismo núcleo para enlazar a las tareas, antes de usar la siguiente consecutiva
núcleo.

cíclico El método de distribución cíclica distribuirá las CPU asignadas para enlazar a
una tarea determinada consecutivamente desde el mismo núcleo, y desde el siguiente consecutivo
core para la siguiente tarea, de forma rotatoria en todos los núcleos.

cíclico
El método de distribución cíclica distribuirá las CPU asignadas para la vinculación
a tareas de núcleos consecutivos de forma rotatoria en todos los núcleos.

Control opcional para la distribución de tareas en los nodos:

. En lugar de distribuir uniformemente las tareas de un paso del trabajo de manera uniforme en
nodos asignados, empaquételos lo más apretadamente posible en los nodos.

Sin Paquete En lugar de empaquetar las tareas de un paso de trabajo de la manera más ajustada posible en los nodos,
distribuirlos uniformemente. Esta opción de usuario sustituirá a la
Parámetro de configuración SelectTypeParameters CR_Pack_Nodes.

- tipo de correo=<tipo>
Notifique al usuario por correo electrónico cuando se produzcan determinados tipos de eventos. Válido tipo los valores son NINGUNO,
BEGIN, END, FAIL, REQUEUE, ALL (equivalente a BEGIN, END, FAIL, REQUEUE y
STAGE_OUT), STAGE_OUT (salida de la etapa de búfer de ráfaga completada), TIME_LIMIT, TIME_LIMIT_90
(alcanzó el 90 por ciento del límite de tiempo), TIME_LIMIT_80 (alcanzó el 80 por ciento del tiempo
límite) y TIME_LIMIT_50 (alcanzado el 50 por ciento del límite de tiempo). Múltiple tipo valores
se puede especificar en una lista separada por comas. Se indica el usuario a notificar
con --usuario de correo.

--usuario de correo=<usuario>
El usuario recibirá una notificación por correo electrónico de los cambios de estado según lo definido por - tipo de correo.
el valor predeterminado es el usuario remitente.

--mem=<MB>
Especifique la memoria real requerida por nodo en MegaBytes. El valor predeterminado es
DefMemPerNodo y el valor máximo es MaxMemPorNodo. Si está configurado, ambos
los parámetros se pueden ver usando el control show config mando. Este parámetro
generalmente se usaría si se asignan nodos completos a trabajos
(SelectType = seleccionar / lineal). Especificar un límite de memoria de cero para un paso de trabajo
Restringir el paso del trabajo a la cantidad de memoria asignada al trabajo, pero no eliminarlo.
cualquiera de la asignación de memoria del trabajo esté disponible para otros pasos del trabajo. también
ver --mem-por-cpu. --mem y --mem-por-cpu son mutuamente excluyentes. NOTA: una memoria
La especificación de tamaño se trata como un caso especial y otorga acceso al trabajo a todos los
la memoria en cada nodo. NOTA: La aplicación de los límites de memoria depende actualmente de
el complemento task / cgroup o la habilitación de contabilidad, que muestra el uso de memoria en un
de forma periódica (no es necesario almacenar los datos, solo recopilarlos). En ambos casos uso de memoria
se basa en el tamaño del conjunto de residentes (RSS) del trabajo. Una tarea puede exceder el límite de memoria.
hasta la siguiente muestra contable periódica.

--mem-por-cpu=<MB>
Memoria mínima requerida por CPU asignada en MegaBytes. El valor predeterminado es
DefMemPerCPU y el valor máximo es MáxMemPorCPU (ver la excepción a continuación). Si
configurados, ambos parámetros se pueden ver usando el control show config mando.
Tenga en cuenta que si el trabajo es --mem-por-cpu el valor excede el configurado MáxMemPorCPU,
entonces el límite del usuario se tratará como un límite de memoria por tarea; --mem-por-cpu
se reducirá a un valor no mayor que MáxMemPorCPU; --cpus-por-tarea se establecerá
y el valor de --cpus-por-tarea multiplicado por el nuevo --mem-por-cpu el valor será
igual al original --mem-por-cpu valor especificado por el usuario. Este parámetro sería
generalmente se usa si se asignan procesadores individuales a trabajos
(SelectType = seleccionar / cons_res). Si los recursos son asignados por el núcleo, socket o
nodos completos; la cantidad de CPU asignadas a un trabajo puede ser mayor que la tarea
contar y el valor de --mem-por-cpu debe ajustarse en consecuencia. Especificando un
El límite de memoria de cero para un paso de trabajo restringirá el paso de trabajo a la cantidad de
memoria asignada al trabajo, pero sin eliminar ninguna de la asignación de memoria del trabajo de
estar disponible para otros pasos del trabajo. Ver también --mem. --mem y --mem-por-cpu están
mutuamente excluyentes.

--mem_bind= [{tranquilo, detallado},]tipo
Vincula las tareas a la memoria. Se usa solo cuando el complemento de tarea / afinidad está habilitado y el
Las funciones de memoria NUMA están disponibles. Nota que los resolución of CPU y memoria
uniéndose pueden diferir de on some arquitecturas Por ejemplo, se puede realizar el enlace de la CPU
al nivel de los núcleos dentro de un procesador mientras se realiza el enlace de memoria
a nivel de nodos, donde la definición de "nodos" puede diferir de un sistema a otro
. Los use of any tipo other than "ninguna" or "local" is no recomendado. If
desea un mayor control, intente ejecutar un código de prueba simple con las opciones
"--cpu_bind = verbose, none --mem_bind = verbose, none" para determinar el
configuración.

NOTA: Para que Slurm informe siempre sobre el enlace de memoria seleccionado para todos los comandos
ejecutado en un shell, puede habilitar el modo detallado configurando SLURM_MEM_BIND
valor de la variable de entorno a "detallado".

Las siguientes variables de entorno informativas se establecen cuando --mem_bind será en
utilizar:

SLURM_MEM_BIND_VERBOSE
SLURM_MEM_BIND_TYPE
SLURM_MEM_BIND_LIST

Consulte las MEDIO AMBIENTE VARIABLES sección para una descripción más detallada de la
Variables SLURM_MEM_BIND * individuales.

Las opciones admitidas incluyen:

tranquilo]
enlazar silenciosamente antes de que se ejecute la tarea (predeterminado)

verboso]
informar detalladamente la vinculación antes de que se ejecute la tarea

ninguno] no vincular tareas a la memoria (predeterminado)

clasificar enlazar por rango de tarea (no recomendado)

local Usar memoria local para el procesador en uso

map_mem:
enlazar mapeando la memoria de un nodo a las tareas como se especifica donde es
, ... . Los ID de CPU se interpretan como valores decimales
a menos que estén precedidos por '0x', en cuyo caso se interpretan como
valores hexadecimales (no recomendado)

mask_mem:
enlazar estableciendo máscaras de memoria en tareas como se especifica donde es
, ... . las máscaras de memoria son always interpretado como
valores hexadecimales. Tenga en cuenta que las máscaras deben ir precedidas de un '0x' si
no comience con [0-9], por lo que srun los ve como valores numéricos.

ayuda muestra este mensaje de ayuda

--mincpus=<n>
Especifique un número mínimo de procesadores / procesadores lógicos por nodo.

--msg-tiempo de espera=<segundos>
Modifique el tiempo de espera del mensaje de inicio del trabajo. El valor predeterminado es Tiempo de espera del mensaje en la categoría Industrial.
Archivo de configuración de Slurm slurm.conf. Los cambios a esto generalmente no son
recomendado, pero podría ser útil para diagnosticar problemas.

--mpi=<tipo_mpi>
Identifique el tipo de MPI que se utilizará. Puede resultar en procedimientos de iniciación únicos.

lista Enumera los tipos de MPI disponibles para elegir.

lam Inicia un proceso 'lamd' por nodo y establece el entorno necesario
variables para LAM / MPI.

mpich1_shmem
Inicia un proceso por nodo y establece el entorno necesario
variables para el modelo de memoria compartida mpich1. Esto también funciona para mvapich built
para memoria compartida.

mpichgm
Para usar con Myrinet.

mvapich
Para usar con Infiniband.

openmpi
Para usar con OpenMPI.

pmi2 Para habilitar el soporte de PMI2. El soporte de PMI2 en Slurm solo funciona si el MPI
la implementación lo admite, es decir, si el MPI tiene la interfaz PMI2
implementado. --Mpi = pmi2 cargará la biblioteca lib / slurm / mpi_pmi2.so
que proporciona la funcionalidad del lado del servidor, pero el lado del cliente debe
implementar PMI2_Init () y las otras llamadas de interfaz.

ninguna Sin procesamiento especial de MPI. Este es el valor predeterminado y funciona con muchos otros
versiones de MPI.

--multiprog
Ejecute un trabajo con diferentes programas y diferentes argumentos para cada tarea. En esto
caso, el programa ejecutable especificado es en realidad un archivo de configuración que especifica
el ejecutable y los argumentos de cada tarea. Ver MÚLTIPLE PROGRAMA CONFIGURACIÓN
a continuación para obtener detalles sobre el contenido del archivo de configuración.

-N, --nodos=<minnodos[-maxnodos]>
Solicite que un mínimo de minnodos nodos asignados a este trabajo. Un nodo máximo
El recuento también se puede especificar con maxnodos. Si solo se especifica un número, este
se utiliza como recuento mínimo y máximo de nodos. Los límites del nodo de la partición
reemplazar a los del trabajo. Si los límites de los nodos de un trabajo están fuera del rango
permitido para su partición asociada, el trabajo se dejará en estado PENDIENTE.
Esto permite una posible ejecución en un momento posterior, cuando el límite de partición es
cambió. Si el límite de un nodo de trabajo excede el número de nodos configurados en el
partición, el trabajo será rechazado. Tenga en cuenta que la variable de entorno
SLURM_JOB_NUM_NODES (y SLURM_NNODES para compatibilidad con versiones anteriores) se establecerá en
el recuento de nodos realmente asignados al trabajo. Ver el MEDIO AMBIENTE VARIABLES
sección para obtener más información. Si -N no se especifica, el comportamiento predeterminado es
asignar suficientes nodos para satisfacer los requisitos de la -n y -c opciones. los
El trabajo se asignará a tantos nodos como sea posible dentro del rango especificado y
sin retrasar el inicio del trabajo. La especificación del recuento de nodos puede
incluir un valor numérico seguido de un sufijo de "k" (multiplica el valor numérico por
1,024) o "m" (multiplica el valor numérico por 1,048,576).

-n, --tareas=<número>
Especifique el número de tareas a ejecutar. Solicita eso correr asignar recursos para ntareas
Tareas. El valor predeterminado es una tarea por nodo, pero tenga en cuenta que el --cpus-por-tarea opción
cambiará este valor predeterminado.

--la red=<tipo>
Especifique la información relacionada con el conmutador o la red. La interpretación de
tipo depende del sistema. Esta opción es compatible cuando se ejecuta Slurm en un Cray
de forma nativa. Se utiliza para solicitar utilizando contadores de rendimiento de red. Solo un valor
por solicitud es válida. Todas las opciones distinguen entre mayúsculas y minúsculas. En esta configuración
los valores admitidos incluyen:

te
Utilice los contadores de rendimiento de la red de todo el sistema. Solo los nodos solicitados
estar marcado en uso para la asignación de trabajo. Si el trabajo no llena el
todo el sistema, el resto de los nodos no pueden ser utilizados por otros trabajos
usando NPC, si está inactivo, su estado aparecerá como PerfCnts. Estos nodos son
todavía disponible para otros trabajos que no usan NPC.

espada Utilice los contadores de rendimiento de la red blade. Solo los nodos solicitados serán
marcado en uso para la asignación de trabajo. Si el trabajo no llena todo
hoja (s) asignada al trabajo, esas hojas no pueden ser utilizadas por otros
trabajos que usan NPC, si están inactivos, su estado aparecerá como PerfCnts. Estos nodos son
todavía disponible para otros trabajos que no usan NPC.

En todos los casos, la solicitud de asignación de trabajo o paso deben especificar los
- opción exclusiva. De lo contrario, se rechazará la solicitud.

Además, con cualquiera de estas opciones, los pasos no pueden compartir blades, por lo que los recursos
permanecería inactivo dentro de una asignación si el paso que se ejecuta en una hoja no toma
todos los nodos de la hoja.

Los del sistema, La opción también es compatible con sistemas con IBM Parallel Environment
(EDUCACIÓN FÍSICA). Consulte la documentación de palabras clave del mandato de trabajo LoadLeveler de IBM sobre la palabra clave
"red" para obtener más información. Se pueden especificar varios valores en una coma
lista separada. Todas las opciones distinguen entre mayúsculas y minúsculas. Los valores admitidos incluyen:

BULK_XFER[=recursos>]
Habilite la transferencia masiva de datos mediante el acceso remoto directo a memoria (RDMA).
La opción recursos La especificación es un valor numérico que puede tener
un sufijo de "k", "K", "m", "M", "g" o "G" para kilobytes, megabytes o
gigabytes. Nota la recursos La especificación no es compatible con el
infraestructura de IBM subyacente a partir de Parallel Environment versión 2.2
y no se debe especificar ningún valor en este momento. Los dispositivos asignados
a un trabajo deben ser todos del mismo tipo. El valor predeterminado depende de
depende del hardware disponible y del orden de preferencias
IPONLY (que no se considera en el modo de espacio de usuario), HFI, IB, HPCE y
KMUX.

CAE=<contar> Número de Unidades de Aceleración Colectiva (CAU) necesarias. Solo se aplica
a los procesadores IBM Power7-IH. El valor predeterminado es cero. CAU independiente
serán asignados para cada interfaz de programación (MPI, LAPI, etc.)

NOMBREDEV=<nombre >
Especifique el nombre del dispositivo que se utilizará para las comunicaciones (por ejemplo, "eth0" o
"mlx4_0").

TIPO DE DISPOSITIVO=<tipo>
Especifique el tipo de dispositivo que se utilizará para las comunicaciones. El apoyado
valores de tipo son: "IB" (InfiniBand), "HFI" (P7 Host Fabric
Interfaz), "IPONLY" (interfaces solo IP), "HPCE" (HPC Ethernet) y
"KMUX" (Emulación de núcleo de HPCE). Los dispositivos asignados a un trabajo deben
todos sean del mismo tipo. El valor predeterminado depende de depende de
qué hardware está disponible y en orden de preferencias es SÓLO IP (que
no se considera en el modo Espacio de usuario), HFI, IB, HPCE y KMUX.

INMEDIADO =<contar>
Se requiere el número de ranuras de envío inmediato por ventana. Se aplica solo a
Procesadores IBM Power7-IH. El valor predeterminado es cero.

INSTANCIAS =<contar>
Especifique el número de conexiones de red para cada tarea en cada red
conexión. El recuento de instancias predeterminado es 1.

IPV4 Utilice comunicaciones de Protocolo de Internet (IP) versión 4 (predeterminado).

IPV6 Utilice las comunicaciones de la versión 6 del Protocolo de Internet (IP).

LAPI Utilice la interfaz de programación LAPI.

MPI Utilice la interfaz de programación MPI. MPI es la interfaz predeterminada.

PAMI Utilice la interfaz de programación PAMI.

SHMÉM Utilice la interfaz de programación OpenSHMEM.

SN_TODOS Utilice todas las redes de conmutadores disponibles (predeterminado).

SN_SINGLE Utilice una red de conmutadores disponible.

UPC Utilice la interfaz de programación UPC.

US Utilice las comunicaciones de User Space.

Algunos ejemplos de especificaciones de red:

Instancias = 2, EE. UU., MPI, SN_ALL
Cree dos conexiones de espacio de usuario para comunicaciones MPI en cada
cambiar de red para cada tarea.

EE. UU., MPI, instancias = 3, Devtype = IB
Cree tres conexiones de espacio de usuario para comunicaciones MPI en cada
Red InfiniBand para cada tarea.

IPV4, LAPI, SN_Single
Cree una conexión IP versión 4 para comunicaciones LAPI en un conmutador
red para cada tarea.

Instancias = 2, EE. UU., LAPI, MPI
Cree dos conexiones de espacio de usuario cada una para comunicaciones LAPI y MPI
en cada red de conmutadores para cada tarea. Tenga en cuenta que SN_ALL es el predeterminado
opción para que se utilice cada red de conmutadores. También tenga en cuenta que Instances = 2
especifica que se establecen dos conexiones para cada protocolo (LAPI
y MPI) y cada tarea. Si hay dos redes y cuatro tareas en
el nodo, entonces se establecen un total de 32 conexiones (2 instancias x
2 protocolos x 2 redes x 4 tareas).

--bonito[=ajuste]
Ejecute el trabajo con una prioridad de programación ajustada dentro de Slurm. Sin ajuste
valor, la prioridad de programación se reduce en 100. El rango de ajuste es de
-10000 (prioridad más alta) a 10000 (prioridad más baja). Solo los usuarios privilegiados pueden
especificar un ajuste negativo. NOTA: Esta opción se ignora actualmente si
SchedulerType = programado / wiki or SchedulerType = sched / wiki2.

--ntasks-por-núcleo=<ntareas>
Solicita el máximo ntareas invocarse en cada núcleo. Esta opción se aplica al trabajo
asignación, pero no escalonar asignaciones. Destinado a ser utilizado con el --tareas
opción. Relacionado con --ntasks-por-nodo excepto en el nivel central en lugar del nodo
nivel. Las máscaras se generarán automáticamente para vincular las tareas a un núcleo específico
a menos que --cpu_bind = ninguno está especificado. NOTA: Esta opción no es compatible a menos que
SelectTypeParameters = CR_Core or SelectTypeParameters = CR_Core_Memory está configurado

--ntasks-por-nodo=<ntareas>
Solicita eso ntareas ser invocado en cada nodo. Si se usa con el --tareas opción, la
--tareas la opción tendrá prioridad y la --ntasks-por-nodo será tratado como un
máximas recuento de tareas por nodo. Destinado a ser utilizado con el --nodos opción. Esta
está relacionado con --cpus-por-tarea=ncpus, pero no requiere el conocimiento de la realidad
número de cpus en cada nodo. En algunos casos, es más conveniente poder
Solicite que no se invoque más de un número específico de tareas en cada nodo.
Ejemplos de esto incluyen enviar una aplicación híbrida MPI / OpenMP donde solo un MPI
Se debe asignar una "tarea / rango" a cada nodo mientras se permite que la parte de OpenMP
utilizar todo el paralelismo presente en el nodo, o enviar un solo
trabajo de configuración / limpieza / supervisión en cada nodo de una asignación preexistente como un paso
en un guión de trabajo más grande.

--ntasks-por-socket=<ntareas>
Solicita el máximo ntareas ser invocado en cada socket. Esta opción se aplica a
asignación de trabajo, pero no escalonar asignaciones. Destinado a ser utilizado con el --tareas
opción. Relacionado con --ntasks-por-nodo excepto en el nivel del zócalo en lugar del
nivel de nodo. Las máscaras se generarán automáticamente para vincular las tareas a tareas específicas.
enchufes a menos que --cpu_bind = ninguno está especificado. NOTA: esta opción no es compatible
a menos que SelectTypeParameters = CR_Socket or SelectTypeParameters = CR_Socket_Memory is
configurado.

-O, - comprometerse en exceso
Comprometer recursos en exceso. Cuando se aplica a la asignación de trabajos, solo se asigna una CPU a
el trabajo por nodo y las opciones utilizadas para especificar el número de tareas por nodo, socket,
core, etc. se ignoran. Cuando se aplica a asignaciones de pasos de trabajo (el correr comando
cuando se ejecuta dentro de una asignación de trabajo existente), esta opción se puede utilizar para iniciar
más de una tarea por CPU. Normalmente, correr no asignará más de un proceso
por CPU. Especificando - comprometerse en exceso estás permitiendo explícitamente más de una
proceso por CPU. Sin embargo, no más de MAX_TAREAS_POR_NODO las tareas están permitidas para
ejecutar por nodo. NOTA: MAX_TAREAS_POR_NODO está definido en el archivo slurm.h y es
no es una variable, se establece en el tiempo de construcción de Slurm.

-o, --producción=<modo>
Especifique el modo para la redirección de stdout. Por defecto en modo interactivo, correr
recopila stdout de todas las tareas y envía esta salida a través de TCP / IP al adjunto
Terminal. Con --producción stdout puede ser redirigido a un archivo, a un archivo por tarea,
o hacia / dev / null. Mira la sección IO Redirección a continuación para las diversas formas de modo.
Si el archivo especificado ya existe, se sobrescribirá.

If --error tampoco se especifica en la línea de comando, tanto stdout como stderr
dirigido al archivo especificado por --producción.

--modo abierto=<añadir | truncar>
Abra los archivos de salida y de error utilizando el modo adjuntar o truncar según lo especificado. El
El valor predeterminado lo especifica el parámetro de configuración del sistema. Agregar archivo de trabajo.

-p, --dividir=<nombres_de_partición>
Solicite una partición específica para la asignación de recursos. Si no se especifica, el
El comportamiento predeterminado es permitir que el controlador slurm seleccione la partición predeterminada
según lo designado por el administrador del sistema. Si el trabajo puede utilizar más de una
partición, especifique sus nombres en una lista separada por comas y la que ofrece
se utilizará la iniciación más temprana sin tener en cuenta el nombre de la partición
ordenar (aunque las particiones de mayor prioridad se considerarán primero). Cuando el
se inicia el trabajo, el nombre de la partición utilizada se colocará primero en el trabajo
grabar la cadena de partición.

--poder=<banderas>
Lista separada por comas de opciones de complementos de administración de energía. Banderas disponibles actualmente
incluir: nivel (todos los nodos asignados al trabajo deben tener límites de energía idénticos,
puede desactivarse mediante la opción de configuración Slurm PowerParameters = job_no_level).

--prioridad=
Solicite una prioridad de trabajo específica. Puede estar sujeto a configuraciones específicas
limitaciones. Solo los operadores y administradores de Slurm pueden establecer la prioridad de un
trabajo.

--perfil=
permite la recopilación de datos detallada mediante el complemento acct_gather_profile. Datos detallados
suelen ser series de tiempo que se almacenan en un archivo HDF5 para el trabajo.

Todo Se recopilan todos los tipos de datos. (No se puede combinar con otros valores).

Ninguna No se recopilan tipos de datos. Este es el predeterminado.
(No se puede combinar con otros valores).

Energía Se recopilan datos energéticos.

Tarea Se recopilan datos de tareas (E / S, memoria, ...).

Sistema de archivos
Se recopilan datos del sistema de archivos.

Nuestra red Se recopilan datos de la red (InfiniBand).

--prólogo=<ejecutable>
correr correrá ejecutable justo antes de iniciar el paso del trabajo. La linea de comando
argumentos para ejecutable será el comando y los argumentos del paso del trabajo. Si
ejecutable es "none", entonces no se ejecutará ningún prólogo srun. Este parámetro anula el
Parámetro SrunProlog en slurm.conf. Este parámetro es completamente independiente de
el parámetro Prolog en slurm.conf.

--propagar[=límites]
Permite a los usuarios especificar cuál de los límites de recursos modificables (suaves) propagar
a los nodos de cálculo y aplicarlos a sus trabajos. Si límites no se especifica, entonces
Se propagarán todos los límites de recursos. Se admiten los siguientes nombres de límites
por Slurm (aunque es posible que algunas opciones no sean compatibles con algunos sistemas):

TODO INCLUIDO Todos los límites enumerados a continuación

AS El espacio máximo de direcciones para un proceso

NÚCLEO El tamaño máximo del archivo principal

CPU La cantidad máxima de tiempo de CPU

DATOS El tamaño máximo del segmento de datos de un proceso.

TAMAÑO El tamaño máximo de los archivos creados. Tenga en cuenta que si el usuario establece FSIZE en
menor que el tamaño actual de slurmd.log, los inicios de trabajos fallarán con
un error de "Límite de tamaño de archivo excedido".

MEMLOCK El tamaño máximo que se puede bloquear en la memoria

NINGÚN ARCHIVO El número máximo de archivos abiertos

NPROC El número máximo de procesos disponibles

RSS El tamaño máximo del conjunto residente

APILAR El tamaño máximo de pila

--pty Ejecute la tarea cero en modo pseudo terminal. Establece implícitamente - sin búfer.
Establece implícitamente --error y --producción a / dev / null para todas las tareas excepto la tarea cero,
lo que puede hacer que esas tareas se cierren inmediatamente (por ejemplo, los shells normalmente saldrán
inmediatamente en esa situación). Actualmente no es compatible con plataformas AIX.

-Q, --tranquilo
Suprime los mensajes informativos de srun. Los errores seguirán apareciendo.

-q, --salir al interrumpir
Salga inmediatamente con un solo SIGINT (Ctrl-C). El uso de esta opción deshabilita el estado
característica normalmente disponible cuando correr recibe un solo Ctrl-C y causa correr a
en su lugar, finalice inmediatamente el trabajo en ejecución.

--qos=<qos>
Solicite una calidad de servicio para el trabajo. Los valores de QOS se pueden definir para cada
asociación de usuario / clúster / cuenta en la base de datos de Slurm. Los usuarios estarán limitados a
el conjunto definido de qos de su asociación cuando el parámetro de configuración Slurm,
AccountingStorageEnforce, incluye "qos" en su definición.

-r, --relativo=<n>
Ejecutar un paso de trabajo relativo al nodo n de la asignación actual. Esta opción puede ser
se utiliza para distribuir varios pasos de trabajo entre los nodos del trabajo actual. Si -r is
utilizado, el paso de trabajo actual comenzará en el nodo n de la lista de nodos asignada, donde
el primer nodo se considera nodo 0. El -r la opción no está permitida con -w or -x
opción y dará como resultado un error fatal cuando no se ejecute dentro de una asignación anterior
(es decir, cuando SLURM_JOB_ID no está configurado). El predeterminado para n es 0. Si el valor de
--nodos excede el número de nodos identificados con el --relativo opción, una
Se imprimirá un mensaje de advertencia y --relativo la opción tendrá prioridad.

--reiniciar
Forzar el reinicio de los nodos asignados antes de iniciar el trabajo. Esto es sólo
compatible con algunas configuraciones del sistema y, de lo contrario, se ignorará en silencio.

--resv-puertos
Reserve puertos de comunicación para este trabajo. Los usuarios pueden especificar el número de puerto que
quiere reservar. El parámetro MpiParams = ports = 12000-12999 debe especificarse en
slurm.conf. Si no se especifica, el número de reserva predeterminado de puertos es igual al
número de tareas. Si el número de puertos reservados es cero, no se reserva ningún puerto.
Utilizado para OpenMPI.

--reserva=<nombre >
Asignar recursos para el trabajo desde la reserva nombrada.

--reiniciar-dir=<directorio>
Especifica el directorio desde el cual se debe leer el trabajo o el punto de control del paso del trabajo.
(utilizado solo por los complementos checkpoint / blcrm y checkpoint / xlch).

-s, --Cuota
La asignación de trabajos puede compartir recursos con otros trabajos en ejecución. Los recursos para
ser compartidos pueden ser nodos, sockets, núcleos o hyperthreads dependiendo de
configuración. El comportamiento compartido predeterminado depende de la configuración del sistema y la
partición Compartido La opción tiene prioridad sobre la opción del trabajo. Esta opción puede
dar lugar a que la asignación se conceda antes que si la opción --compartir no fuera
establecer y permitir una mayor utilización del sistema, pero es probable que el rendimiento de la aplicación
sufren debido a la competencia por los recursos. Consulte también la opción --exclusive.

-S, --núcleo-spec=<número>
Recuento de núcleos especializados por nodo reservados por el trabajo para operaciones del sistema y
no utilizado por la aplicación. La aplicación no utilizará estos núcleos, pero será
cobrado por su asignación. El valor predeterminado depende de la
valor configurado de CoreSpecCount. Si se designa un valor de cero y el Slurm
La opción de configuración AllowSpecResourcesUsage está habilitada, se permitirá que el trabajo
anule CoreSpecCount y utilice los recursos especializados en los nodos asignados.
Esta opción no se puede utilizar con el --especificación de hilo .

--sicp Identifique un trabajo como uno del que pueden depender los trabajos enviados a otros clústeres.

--señal=<sign_num> [@señal_time>]
Cuando un trabajo esta dentro señal_time segundos de su hora de finalización, envíale la señal sign_num.
Debido a la resolución del manejo de eventos por Slurm, la señal puede enviarse hasta 60
segundos antes de lo especificado. sign_num puede ser un número de señal o un nombre
(por ejemplo, "10" o "USR1"). señal_time debe tener un valor entero entre 0 y 65535.
De forma predeterminada, no se envía ninguna señal antes de la hora de finalización del trabajo. Si un sign_num está especificado
sin ninguna señal_time, el tiempo predeterminado será de 60 segundos.

--slurmd-depuración=<nivel>
Especifique un nivel de depuración para arrastrado(8). los nivel se puede especificar como un número entero
valor entre 0 [silencioso, solo se muestran errores] y 4 [operación detallada] o el
SlurmdDebug las etiquetas.

tranquilo No registrar nada

fatal Registra solo errores fatales

error Registrar solo errores

info Registrar errores y mensajes informativos generales

verboso Registrar errores y mensajes informativos detallados

La información de depuración de slurmd se copia en el stderr de
el trabajo. De forma predeterminada, solo se muestran los errores.

--sockets-por-nodo=<tomas>
Restrinja la selección de nodos a nodos con al menos el número especificado de sockets.
Ver información adicional en -B opción anterior cuando el complemento de tarea / afinidad está
habilitado

- interruptores=<contar> [@tiempo máximo>]
Cuando se utiliza una topología de árbol, esto define el recuento máximo de conmutadores deseados
para la asignación de trabajo y, opcionalmente, el tiempo máximo de espera para ese número de
interruptores. Si Slurm encuentra una asignación que contiene más cambios que el recuento
especificado, el trabajo permanece pendiente hasta que encuentre una asignación con la deseada
interruptor de conteo o el límite de tiempo expira. Si no hay límite de recuento de interruptores,
No hay demora en comenzar el trabajo. Los formatos de hora aceptables incluyen "minutos",
"minutos: segundos", "horas: minutos: segundos", "días-horas", "días-horas: minutos" y
"días-horas: minutos: segundos". La demora máxima del trabajo puede estar limitada por la
administrador del sistema utilizando el Parámetros del programador parámetro de configuración con el
max_switch_wait opción de parámetro. El tiempo máximo predeterminado es max_switch_wait
Parámetros del programador.

-T, --hilos=<n hilos>
Permite limitar la cantidad de subprocesos simultáneos utilizados para enviar la solicitud de trabajo desde
el proceso srun a los procesos slurmd en los nodos asignados. El valor predeterminado es usar
un subproceso por nodo asignado hasta un máximo de 60 subprocesos simultáneos. Especificando
esta opción limita el número de subprocesos simultáneos a n hilos (menor o igual
a 60). Esto solo debe usarse para establecer un recuento bajo de subprocesos para probar en muy
Pequeños ordenadores de memoria.

-t, --tiempo=<time>
Establezca un límite en el tiempo total de ejecución de la asignación de trabajos. Si la hora solicitada
límite excede el límite de tiempo de la partición, el trabajo se dejará en estado PENDIENTE
(posiblemente indefinidamente). El límite de tiempo predeterminado es el tiempo predeterminado de la partición.
límite. Cuando se alcanza el límite de tiempo, cada tarea en cada paso del trabajo se envía SIGTERM
seguido de SIGKILL. El intervalo entre señales lo especifica el Slurm
parámetro de configuración mataresperar. límite de tiempo excedido el parámetro de configuración puede
permitir que el trabajo se ejecute más de lo programado. La resolución de tiempo es de un minuto y
los segundos valores se redondean al minuto siguiente.

Un límite de tiempo de cero solicitudes de que no se imponga ningún límite de tiempo. Tiempo aceptable
los formatos incluyen "minutos", "minutos: segundos", "horas: minutos: segundos",
"días-horas", "días-horas: minutos" y "días-horas: minutos: segundos".

--tarea-epílogo=<ejecutable>
Los paso lento el demonio se ejecutará ejecutable justo después de que termina cada tarea. Esta
se ejecutará antes de que se ejecute cualquier parámetro TaskEpilog en slurm.conf. Esto es
destinado a ser un programa de muy corta duración. Si no termina en unos pocos
segundos, se eliminará junto con cualquier proceso descendiente.

--tarea-prólogo=<ejecutable>
Los paso lento el demonio se ejecutará ejecutable justo antes de iniciar cada tarea. Esta
se ejecutará después de que se ejecute cualquier parámetro TaskProlog en slurm.conf. además
las variables de entorno normales, esto tiene SLURM_TASK_PID disponible para identificar el
ID de proceso de la tarea que se está iniciando. Salida estándar de este programa del
El formulario "export NAME = value" se utilizará para establecer variables de entorno para la tarea.
siendo engendrado.

- solo prueba
Devuelve una estimación de cuándo se programaría la ejecución de un trabajo dado el trabajo actual
cola y todo lo demás correr argumentos que especifican el trabajo. Esto limita srun's
comportamiento para simplemente devolver información; no se envía ningún trabajo. EXCEPCIÓN: Activado
Los sistemas Bluegene / Q se encienden cuando se ejecutan dentro de una asignación de trabajo existente, esto deshabilita
el uso de "runjob" para iniciar tareas. El programa será ejecutado directamente por el
demonio slurmd.

--especificación de hilo=<número>
Recuento de subprocesos especializados por nodo reservados por el trabajo para operaciones del sistema y
no utilizado por la aplicación. La aplicación no utilizará estos subprocesos, pero
cobrar por su asignación. Esta opción no se puede utilizar con el --núcleo-spec
.

- hilos por núcleo=<hilos>
Restringir la selección de nodos a nodos con al menos el número especificado de subprocesos por
centro. NOTA: "Subprocesos" se refiere al número de unidades de procesamiento en cada núcleo en lugar de
que el número de tareas de la aplicación que se iniciarán por núcleo. Ver adicionales
información debajo -B opción anterior cuando el complemento de tarea / afinidad está habilitado.

--tiempo-min=<time>
Establezca un límite de tiempo mínimo en la asignación de trabajos. Si se especifica, el trabajo puede tener
es --tiempo límite reducido a un valor no inferior a --tiempo-min si hacerlo lo permite
el trabajo debe comenzar la ejecución antes de lo que sea posible. El límite de tiempo del trabajo
no se cambiará después de que se asignen recursos al trabajo. Esto es realizado por un
algoritmo de programación de reabastecimiento para asignar recursos que de otro modo se reservarían para mayores
trabajos prioritarios. Los formatos de hora aceptables incluyen "minutos", "minutos: segundos",
"horas: minutos: segundos", "días-horas", "días-horas: minutos" y
"días-horas: minutos: segundos".

--tmp=<MB>
Especifique una cantidad mínima de espacio en disco temporal.

-u, - sin búfer
De forma predeterminada, la conexión entre slurmstepd y la aplicación iniciada por el usuario es
sobre una tubería. La salida stdio escrita por la aplicación es almacenada en búfer por glibc
hasta que se vacíe o la salida se establezca como sin búfer. Ver setbuf(3). Si esto
se especifica la opción las tareas se ejecutan con un pseudo terminal para que el
la salida de la aplicación no tiene búfer.

--uso
Muestre un breve mensaje de ayuda y salga.

--uido=<usuario>
Intente enviar y / o ejecutar un trabajo como usuario en lugar del ID de usuario que invoca. los
La invocación de las credenciales del usuario se utilizará para verificar los permisos de acceso para el objetivo.
dividir. El usuario root puede usar esta opción para ejecutar trabajos como un usuario normal en un RootOnly
partición, por ejemplo. Si se ejecuta como root, correr dejará caer sus permisos al uid
especificado después de que la asignación de nodos sea exitosa. usuario puede ser el nombre de usuario o
ID de usuario numérico.

-V, --versión
Muestra la información de la versión y sale.

-v, --verboso
Aumenta la verbosidad de los mensajes informativos de srun. Múltiple -vvoluntad
aumentar aún más la verbosidad de srun. De forma predeterminada, solo se mostrarán los errores.

-W, --Espere=<segundos>
Especifique cuánto tiempo esperar después de que termine la primera tarea antes de terminar todas
tareas restantes. Un valor de 0 indica una espera ilimitada (se emitirá una advertencia
después de 60 segundos). El valor predeterminado lo establece el parámetro WaitTime en el slurm
archivo de configuración (ver slurm.conf(5)). Esta opción puede ser útil para asegurar que un
el trabajo se termina de manera oportuna en caso de que una o más tareas terminen
prematuramente. Nota la -K, --matar-en-mala-salida la opción tiene prioridad sobre -W,
--Espere para terminar el trabajo inmediatamente si una tarea sale con un código de salida distinto de cero.

-w, --lista de nodos=<host1, host2, ... or nombre de archivo>
Solicite una lista específica de hosts. El trabajo contendrá all de estos anfitriones y
posiblemente hosts adicionales según sea necesario para satisfacer los requisitos de recursos. La lista puede
especificarse como una lista de hosts separados por comas, un rango de hosts (host [1-5,7, ...]
por ejemplo) o un nombre de archivo. Se asumirá que la lista de hosts es un nombre de archivo si
contiene un carácter "/". Si especifica un número mínimo de nodos o procesadores mayor
que puede ser satisfecho por la lista de hosts proporcionada, los recursos adicionales serán
asignados en otros nodos según sea necesario. En lugar de repetir varios nombres de host
veces, se puede agregar un asterisco y un recuento de repeticiones al nombre de host. Para
ejemplo, "host1, host1" y "host1 * 2" son equivalentes.

- hockey=<wckey>
Especifique el wckey que se utilizará con el trabajo. Si TrackWCKey = no (predeterminado) en slurm.conf
este valor se ignora.

-X, --disable-estado
Desactiva la visualización del estado de la tarea cuando srun recibe un solo SIGINT (Ctrl-C).
En su lugar, reenvíe inmediatamente el SIGINT al trabajo en ejecución. Sin esta opción un
Se requiere un segundo Ctrl-C en un segundo para terminar el trabajo a la fuerza y correr will
salir inmediatamente. También se puede configurar a través de la variable de entorno
SLURM_DISABLE_STATUS.

-x, --excluir=<host1, host2, ... or nombre de archivo>
Solicite que no se incluya una lista específica de hosts en los recursos asignados a
este trabajo. Se asumirá que la lista de hosts es un nombre de archivo si contiene un
"/"personaje.

-Z, --no asignar
Ejecute las tareas especificadas en un conjunto de nodos sin crear un "trabajo" Slurm en el
Estructura de cola Slurm, sin pasar por el paso normal de asignación de recursos. La lista de
los nodos deben especificarse con el -w, --lista de nodos opción. Este es un privilegiado
opción solo disponible para los usuarios "SlurmUser" y "root".

Las siguientes opciones son compatibles con los sistemas Blue Gene, pero pueden ser aplicables a otros sistemas como
bien.

--blrts-imagen=<camino>
Ruta a la imagen blrts para el bloque bluegene. Solo BGL. Predeterminado de blugene.conf if
no establecido.

--cnload-imagen=<camino>
Ruta para calcular la imagen del nodo para el bloque bluegene. Solo BGP. Predeterminado de
blugene.conf si no está configurado.

- tipo de conexión=<tipo>
Requiere que el tipo de conexión del bloque sea de un tipo determinado. En Blue Gene el
aceptable de tipo son MESH, TORUS y NAV. Si NAV, o si no está configurado, Slurm
intente ajustar lo que el DefaultConnType está configurado en el bluegene.conf si eso no es
establecer el valor predeterminado es TORUS. Normalmente no debería configurar esta opción. Si está corriendo
un sistema BGP y desea ejecutar en modo HTC (solo para 1 plano medio y menos). usted
puede usar HTC_S para SMP, HTC_D para Dual, HTC_V para modo de nodo virtual y HTC_L para
Modo Linux. Para sistemas que permiten un tipo de conexión diferente por dimensión,
puede proporcionar una lista separada por comas de tipos de conexión se puede especificar, uno para
cada dimensión (es decir, M, T, T, T le dará una conexión toroidal son todas las dimensiones
esperar el primero).

-g, --geometría=<XxYxZ> |AxXxYxZ>
Especifique los requisitos de geometría para el trabajo. En los sistemas BlueGene / L y BlueGene / P
hay tres números que dan dimensiones en las direcciones X, Y y Z, mientras que en
En los sistemas BlueGene / Q hay cuatro números que dan dimensiones en A, X, Y y Z
direcciones y no se puede utilizar para asignar sub-bloques. Por ejemplo
"--geometry = 1x2x3x4", especifica un bloque de nodos que tiene 1 x 2 x 3 x 4 = 24 nodos
(en realidad planos medios en BlueGene).

--ioload-imagen=<camino>
Ruta a la imagen de io para el bloque bluegene. Solo BGP. Predeterminado de blugene.conf si no
conjunto.

--linux-imagen=<camino>
Ruta a la imagen de Linux para el bloque bluegene. Solo BGL. Predeterminado de blugene.conf if
no establecido.

--mloader-imagen=<camino>
Ruta a la imagen de mloader para el bloque bluegene. Predeterminado de blugene.conf si no está configurado.

-R, --no rotar
Desactiva la rotación de la geometría solicitada del trabajo para que se ajuste a un
cuadra. Por defecto, la geometría especificada puede rotar en tres dimensiones.

--imagen de disco RAM=<camino>
Ruta a la imagen de disco RAM para el bloque bluegene. Solo BGL. Predeterminado de blugene.conf if
no establecido.

correr enviará la solicitud de trabajo al controlador de trabajo slurm, luego iniciará todos los procesos
en los nodos remotos. Si la solicitud no se puede atender de inmediato, correr bloqueará hasta que el
Los recursos son gratuitos para ejecutar el trabajo. Si el -I (--inmediato) se especifica la opción correr will
terminar si los recursos no están disponibles de inmediato.

Al iniciar procesos remotos correr propagará el directorio de trabajo actual, a menos que
--chdir=<camino> se especifica, en cuyo caso camino se convertirá en el directorio de trabajo de la
procesos remotos.

Los -norte, -cy -N Las opciones controlan cómo se asignarán las CPU y los nodos al trabajo. Cuándo
especificando solo el número de procesos a ejecutar con -n, un valor predeterminado de una CPU por proceso
está asignado. Especificando el número de CPU necesarias por tarea (-c), más de una CPU
puede asignarse por proceso. Si el número de nodos se especifica con -N, correr will
intentar asignar at menos el número de nodos especificado.

Se pueden utilizar combinaciones de las tres opciones anteriores para cambiar la forma en que se ejecutan los procesos.
distribuidos entre nodos y cpus. Por ejemplo, especificando tanto el número de
procesos y el número de nodos en los que ejecutar, el número de procesos por nodo es
implícito. Sin embargo, si el número de CPU por proceso es más importante, entonces el número de
procesos (-n) y el número de CPU por proceso (-c) debe especificarse.

correr se negará a asignar más de un proceso por CPU a menos que - comprometerse en exceso (-O) es
también especificado.

correr intentará cumplir con las especificaciones anteriores "como mínimo". Es decir, si 16 nodos
se solicitan para 32 procesos, y algunos nodos no tienen 2 CPU, la asignación de nodos
aumentará para satisfacer la demanda de CPU. En otras palabras, un mínimo de 16
se solicitan nodos. Sin embargo, si se solicitan 16 nodos para 15 procesos, correr will
considere esto como un error, ya que 15 procesos no pueden ejecutarse en 16 nodos.

IO Redirección

De forma predeterminada, stdout y stderr serán redirigidos desde todas las tareas a stdout y stderr
of correr, y stdin será redirigido desde la entrada estándar de correr a todas las tareas remotas.
Si stdin solo debe ser leído por un subconjunto de las tareas generadas, especificando un archivo para leer
en lugar de reenviar stdin desde el correr El comando puede ser preferible ya que evita
mover y almacenar datos que nunca se leerán.

Para OS X, la función poll () no es compatible con stdin, por lo que la entrada desde un terminal no es
posible.

Para BGQ srun solo admite stdin para 1 tarea que se ejecuta en el sistema. Por defecto es taskid
0 pero se puede cambiar con -i como se describe a continuación, o
--launcher-opts = "- stdinrank = ".

Este comportamiento se puede cambiar con el --producción, --errory --aporte (-o, -e, -i) opciones.
Las especificaciones de formato válidas para estas opciones son

all stdout stderr se redirige de todas las tareas a srun. stdin se transmite a todos
Tareas remotas. (Este es el comportamiento predeterminado)

ninguna stdout y stderr no se reciben de ninguna tarea. stdin no se envía a ninguna tarea
(stdin está cerrado).

idtarea stdout y / o stderr se redirigen solo desde la tarea con una identificación relativa igual a
idtarea, donde 0 <= idtarea <= ntareas, donde el ntareas es el número total de tareas
en el paso de trabajo actual. stdin se redirige desde el stdin de correr a este
misma tarea. Este archivo se escribirá en el nodo que ejecuta la tarea.

nombre de archivo correr redirigirá stdout y / o stderr al archivo nombrado desde todas las tareas. stdin
será redirigido desde el archivo nombrado y transmitido a todas las tareas del trabajo.
nombre de archivo se refiere a una ruta en el host que se ejecuta correr. Dependiendo de
diseño del sistema de archivos del clúster, esto puede resultar en que la salida aparezca en
diferentes lugares dependiendo de si el trabajo se ejecuta en modo por lotes.

formato cadena
correr permite utilizar una cadena de formato para generar el archivo IO con nombre
descrito arriba. La siguiente lista de especificadores de formato se puede utilizar en la
cadena de formato para generar un nombre de archivo que será único para un ID de trabajo determinado,
stepid, nodo o tarea. En cada caso, se abre el número apropiado de archivos
y asociado a las tareas correspondientes. Tenga en cuenta que cualquier cadena de formato
que contenga% t,% n y / o% N se escribirán en el nodo que ejecuta la tarea
en lugar del nodo donde correr ejecuta, estos especificadores de formato no son
compatible con un sistema BGQ.

%A Número de asignación de trabajo principal de la matriz de trabajos.

%a Número de ID de matriz de trabajo (índice).

% J jobid.stepid del trabajo en ejecución. (por ejemplo, "128.0")

% j id de trabajo del trabajo en ejecución.

% s stepid del trabajo en ejecución.

% N nombre de host corto. Esto creará un archivo IO separado por nodo.

% n Identificador de nodo relativo al trabajo actual (por ejemplo, "0" es el primer nodo de
el trabajo en ejecución) Esto creará un archivo IO separado por nodo.

% t identificador de tarea (rango) relativo al trabajo actual. Esto creará un
archivo IO separado por tarea.

% u Nombre de usuario.

Se puede usar un número colocado entre el carácter de porcentaje y el especificador de formato.
para rellenar con ceros el resultado en el nombre del archivo IO. Este número se ignora si el formato
el especificador corresponde a datos no numéricos (% N, por ejemplo).

Algunos ejemplos de cómo se puede usar la cadena de formato para un paso de trabajo de 4 tareas con un
La identificación de trabajo de 128 y la identificación de paso de 0 se incluyen a continuación:

trabajo% J.out job128.0.out

trabajo% 4j.out job0128.out

trabajo% j-% 2t.out job128-00.out, job128-01.out, ...

ENTRADA MEDIO AMBIENTE VARIABLES

Algunas opciones de srun se pueden configurar mediante variables de entorno. Estas variables de entorno,
junto con sus opciones correspondientes, se enumeran a continuación. Nota: las opciones de la línea de comandos
anule siempre estos ajustes.

PMI_FANOUT Esto se usa exclusivamente con PMI (MPICH2 y MVAPICH2) y controles
el abanico de comunicaciones de datos. El comando srun envía mensajes
a los programas de aplicación (a través de la biblioteca PMI) y esas aplicaciones
puede ser llamado a reenviar esos datos hasta este número de
tareas adicionales. Los valores más altos descargan el trabajo del comando srun
a las aplicaciones y probablemente aumente la vulnerabilidad a
fracasos. El valor predeterminado es 32.

PMI_FANOUT_OFF_HOST Esto se usa exclusivamente con PMI (MPICH2 y MVAPICH2) y controles
el abanico de comunicaciones de datos. El comando srun envía mensajes
a los programas de aplicación (a través de la biblioteca PMI) y esas aplicaciones
se le puede solicitar que reenvíe esos datos a tareas adicionales. Por
predeterminado, srun envía un mensaje por host y una tarea en ese host
reenvía los datos a otras tareas en ese host hasta PMI_FANOUT. Si
PMI_FANOUT_OFF_HOST está definida, la tarea del usuario puede ser necesaria para
reenviar los datos a tareas en otros hosts. Ajuste
PMI_FANOUT_OFF_HOST puede aumentar el rendimiento. Dado que más trabajo es
realizado por la biblioteca PMI cargada por la aplicación de usuario,
Las fallas también pueden ser más comunes y más difíciles de diagnosticar.

PMI_TIEMPO Esto se usa exclusivamente con PMI (MPICH2 y MVAPICH2) y controles
cuánto se difunden las comunicaciones de las tareas al srun
a tiempo para evitar abrumar el comando srun con
trabajo. El valor predeterminado es 500 (microsegundos) por tarea. Sobre
Procesadores relativamente lentos o sistemas con un procesador muy grande.
recuentos (y grandes conjuntos de datos de PMI), es posible que se requieran valores más altos.

Slurm_conf La ubicación del archivo de configuración de Slurm.

SLURM_ACCOUNT Igual que -UN, --cuenta

SLURM_ACCTG_FREQ Igual que --acctg-freq

SLURM_BCAST Igual que --bcast

SLURM_BLRTS_IMAGE Igual que --blrts-imagen

SLURM_BURST_BUFFER Igual que --cama y desayuno

SLURM_PUNTO DE CONTROL Igual que --control

SLURM_CHECKPOINT_DIR Igual que --punto de control-dir

SLURM_CNLOAD_IMAGE Igual que --cnload-imagen

SLURM_CONN_TYPE Igual que - tipo de conexión

SLURM_CORE_SPEC Igual que --núcleo-spec

SLURM_CPU_BIND Igual que --cpu_bind

SLURM_CPU_FREQ_REQ Igual que --cpu-frecuencia.

SLURM_CPUS_PER_TASK Igual que -C, --cpus-por-tarea

SLURM_DEBUG Igual que -v, --verboso

SlurmD_DEBUG Igual que -D, --slurmd-depuración

SLURM_DEPENDENCIA -PAG, --dependencia=<Identificación del trabajo>

SLURM_DISABLE_STATUS Igual que -X, --disable-estado

SLURM_DIST_PLANESIZE Igual que -m avión

SLURM_DISTRIBUCIÓN Igual que -metro, --distribución

SLURM_EPILOG Igual que --epílogo

SLURM_EXCLUSIVO Igual que --exclusivo

SLURM_EXIT_ERROR Especifica el código de salida generado cuando se produce un error Slurm (p. Ej.
opciones inválidas). Esto puede ser utilizado por un script para distinguir
códigos de salida de la aplicación de varias condiciones de error Slurm. También
ver SLURM_EXIT_IMMEDIATE.

SLURM_EXIT_IMMEDIATE Especifica el código de salida generado cuando el --inmediato opción es
utilizado y los recursos no están disponibles actualmente. Esto puede ser utilizado por
un script para distinguir los códigos de salida de la aplicación de varios Slurm
condiciones de error. Ver también SLURM_EXIT_ERROR.

SLURM_GEOMETRÍA Igual que -gramo, --geometría

SLURM_SUGERENCIA Igual que --insinuación

SLURM_GRES Igual que --gres. Ver también SLURM_STEP_GRES

SLURM_IMMEDIATE Igual que -YO, --inmediato

SLURM_IOLOAD_IMAGE Igual que --ioload-imagen

SLURM_JOB_ID (y SLURM_JOBID para compatibilidad con versiones anteriores)
Igual que --Identificación del trabajo

SLURM_JOB_NOMBRE Igual que -J, --nombre del trabajo excepto dentro de una asignación existente, en
cuyo caso se ignora para evitar usar el nombre del trabajo por lotes como el
nombre de cada paso del trabajo.

SLURM_JOB_NUM_NODES (y SLURM_NNODES para compatibilidad con versiones anteriores)
Número total de nodos en la asignación de recursos del trabajo.

SLURM_KILL_BAD_SALIR Igual que -K, --matar-en-mala-salida

SLURM_LABELIO Igual que -yo, --etiqueta

SLURM_LINUX_IMAGE Igual que --linux-imagen

SLURM_MEM_BIND Igual que --mem_bind

SLURM_MEM_PER_CPU Igual que --mem-por-cpu

SLURM_MEM_PER_NODE Igual que --mem

SLURM_MLOOADER_IMAGE Igual que --mloader-imagen

SLURM_MPI_TYPE Igual que --mpi

SLURM_RED Igual que --la red

SLURM_NNODES Igual que -NORTE, --nodos

SLURM_NO_ROTAR Igual que -R, --no rotar

SLURM_NTASKS (y SLURM_NPROCS para compatibilidad con versiones anteriores)
Igual que -norte, --tareas

SLURM_NTASKS_PER_CORE Igual que --ntasks-por-núcleo

SLURM_NTASKS_PER_NODE Igual que --ntasks-por-nodo

SLURM_NTASKS_PER_SOCKET
Igual que --ntasks-por-socket

SLURM_OPEN_MODE Igual que --modo abierto

SLURM_OVERCOMMIT Igual que -Oh, - comprometerse en exceso

SLURM_PARTICIÓN Igual que -pag, --dividir

SLURM_PMI_KVS_NO_DUP_KEYS
Si se establece, los pares de claves de PMI no contendrán claves duplicadas. MPI puede
utilice esta variable para informar a la biblioteca de PMI que no utilizará
llaves duplicadas para que PMI pueda omitir la verificación de llaves duplicadas. Esta
es el caso de MPICH2 y reduce los gastos generales en las pruebas de
duplicados para un mejor rendimiento

SLURM_POWER Igual que --poder

PERFIL_SLURM Igual que --perfil

SLURM_PROLOG Igual que --prólogo

SLURM_QOS Igual que --qos

SLURM_RAMDISK_IMAGE Igual que --imagen de disco RAM

SLURM_REMOTE_CWD Igual que -RE, --chdir =

SLURM_REQ_SWITCH Cuando se utiliza una topología de árbol, esto define el recuento máximo de
interruptores deseados para la asignación de trabajo y, opcionalmente, el máximo
tiempo para esperar esa cantidad de interruptores. Ver - interruptores

SLURM_RESERVACIÓN Igual que --reserva

SLURM_RESTART_DIR Igual que --reiniciar-dir

SLURM_RESV_PORTS Igual que --resv-puertos

SLURM_SICP Igual que --sicp

SLURM_SIGNAL Igual que --señal

SLURM_STDERRMODE Igual que -mi, --error

SLURM_STDINMODE Igual que -I, --aporte

SLURM_SRUN_REDUCE_TASK_EXIT_MSG
si se establece y no es cero, mensajes de salida de tarea sucesivos con el mismo
El código de salida se imprimirá solo una vez.

SLURM_STEP_GRES Igual que --gres (solo se aplica a los pasos del trabajo, no a las asignaciones de trabajo).
Ver también SLURM_GRES

SLURM_STEP_KILLED_MSG_NODE_ID= ID
Si se establece, solo el nodo especificado se registrará cuando el trabajo o el paso sean
asesinado por una señal.

SLURM_STDOUTMODE Igual que -Oh, --producción

SLURM_TASK_EPILOG Igual que --tarea-epílogo

SLURM_TASK_PROLOG Igual que --tarea-prólogo

SLURM_TEST_EXEC si está definido, verifique la existencia del programa ejecutable en el
equipo local antes de intentar ejecutarlo en los nodos de cómputo.

SLURM_THREAD_SPEC Igual que --especificación de hilo

SLURM_HILOS Igual que -T, --hilos

SLURM_TIMELIMIT Igual que -t, --tiempo

SLURM_UNBUFFEREDIO Igual que -tu, - sin búfer

SLURM_ESPERA Igual que -W, --Espere

SLURM_WAIT4SWITCH Tiempo máximo de espera de los conmutadores solicitados. Ver - interruptores

SLURM_WCKEY Igual que -W, - hockey

SLURM_WORKING_DIR -RE, --chdir

SALIDA MEDIO AMBIENTE VARIABLES

srun establecerá algunas variables de entorno en el entorno de las tareas en ejecución en el
nodos informáticos remotos. Estas variables de entorno son:

SLURM_CHECKPOINT_IMAGE_DIR
Directorio en el que se deben escribir las imágenes de puntos de control si
especificado en la línea de ejecución.

SLURM_CLUSTER_NOMBRE Nombre del clúster en el que se está ejecutando el trabajo.

SLURM_CPU_BIND_VERBOSE
--cpu_bind verbosity (silencioso, detallado).

SLURM_CPU_BIND_TYPE --cpu_bind type (ninguno, rango, map_cpu:, mask_cpu :).

SLURM_CPU_BIND_LIST --cpu_bind mapa o lista de máscaras (lista de ID de CPU Slurm o máscaras para esto
nodo, CPU_ID = Board_ID x subprocesos_per_board + Socket_ID x
threads_per_socket + Core_ID x threads_per_core + Thread_ID).

SLURM_CPU_FREQ_REQ Contiene el valor solicitado para la frecuencia de la CPU en el comando srun
como una frecuencia numérica en kilohercios, o un valor codificado para un
petición de low, mediano ,altom1 or high para la frecuencia. Ver el
descripción del --cpu-frecuencia opción o el SLURM_CPU_FREQ_REQ Las opciones de entrada
Variable ambiental.

SLURM_CPUS_ON_NODE Recuento de procesadores disponibles para el trabajo en este nodo. Nota la
El complemento select / linear asigna nodos completos a trabajos, por lo que el valor
indica el recuento total de CPU en el nodo. Para el
plugin select / cons_res, este número indica el número de núcleos en
este nodo asignado al trabajo.

SLURM_CPUS_PER_TASK Número de cpus solicitados por tarea. Solo se establece si el --cpus-por-tarea
Se especifica la opción.

SLURM_DISTRIBUCIÓN Tipo de distribución de los trabajos asignados. Establecer la distribución con
-m, - distribución.

SLURM_GTIDS ID de tareas globales que se ejecutan en este nodo. Origen cero y coma
apartado.

SLURM_JOB_CPUS_PER_NODE
Número de CPUS por nodo.

SLURM_JOB_DEPENDENCY Establezca el valor de la opción --dependency.

SLURM_JOB_ID (y SLURM_JOBID para compatibilidad con versiones anteriores)
Id. De trabajo del trabajo en ejecución.

SLURM_JOB_NOMBRE Establezca el valor de la opción --job-name o el nombre del comando cuando
srun se utiliza para crear una nueva asignación de trabajo. No establecido cuando srun es
se utiliza solo para crear un paso de trabajo (es decir, dentro de un trabajo existente
asignación).

SLURM_JOB_PARTITION Nombre de la partición en la que se está ejecutando el trabajo.

SLURM_LAUNCH_NODE_IPADDR
Dirección IP del nodo desde el que se inició el lanzamiento de la tarea
(de donde se ejecutó el comando srun).

SLURM_LOCALID ID de tarea local de nodo para el proceso dentro de un trabajo.

SLURM_MEM_BIND_VERBOSE
--mem_bind verbosity (silencioso, detallado).

SLURM_MEM_BIND_TYPE --mem_bind tipo (ninguno, rango, map_mem:, mask_mem :).

SLURM_MEM_BIND_LIST --mem_bind mapa o lista de máscaras ( ).

SLURM_NNODES Número total de nodos en la asignación de recursos del trabajo.

SLURM_NODE_ALIASES Conjuntos de nombre de nodo, dirección de comunicación y nombre de host para nodos
asignado al trabajo desde la nube. Cada elemento del conjunto si
separados por dos puntos y cada conjunto está separado por comas. Por ejemplo:
SLURM_NODE_ALIASES = ec0: 1.2.3.4: foo, ec1: 1.2.3.5: bar

SLURM_NODEID El ID de nodo relativo del nodo actual.

SLURM_NODELIST Lista de nodos asignados al trabajo.

SLURM_NTASKS (y SLURM_NPROCS para compatibilidad con versiones anteriores)
Número total de procesos en el trabajo actual.

SLURM_PRIO_PROCESO La prioridad de programación (buen valor) en el momento del envío del trabajo.
Este valor se propaga a los procesos generados.

SLURM_PROCID El rango de MPI (o ID de proceso relativo) del proceso actual.

SLURM_SRUN_COMM_HOST Dirección IP del host de comunicación srun.

SLURM_SRUN_COMM_PORT puerto de comunicación srun.

SLURM_STEP_LAUNCHER_PORT
Puerto del lanzador de pasos.

SLURM_STEP_NODELIST Lista de nodos asignados al paso.

SLURM_STEP_NUM_NODES Número de nodos asignados al paso.

SLURM_STEP_NUM_TASKS Número de procesos en el paso.

SLURM_STEP_TASKS_PER_NODE
Número de procesos por nodo dentro del paso.

SLURM_STEP_ID (y SLURM_STEPID para compatibilidad con versiones anteriores)
El ID de paso del trabajo actual.

SLURM_SUBMIT_DIR El directorio desde el que correr fue invocado.

SLURM_SUBMIT_HOST El nombre de host de la computadora desde la que Salloc fue invocado.

SLURM_TASK_PID El ID de proceso de la tarea que se está iniciando.

SLURM_TASKS_PER_NODE Número de tareas a iniciar en cada nodo. Los valores son comas
separados y en el mismo orden que SLURM_NODELIST. Si dos o mas
los nodos consecutivos deben tener el mismo recuento de tareas, ese recuento es
seguido de "(x #)" donde "#" es el recuento de repeticiones. Por ejemplo,
"SLURM_TASKS_PER_NODE = 2 (x3), 1" indica que los primeros tres nodos
cada uno ejecutará tres tareas y el cuarto nodo ejecutará una
tarea.

SLURM_TOPOLOGY_ADDR Esto se establece solo si el sistema tiene el complemento de topología / árbol
configurado. El valor se establecerá en los nombres de los conmutadores de red.
que puede estar involucrado en las comunicaciones del trabajo desde el sistema
interruptor de nivel superior hasta el interruptor de hoja y termina con el nombre del nodo.
Se utiliza un punto para separar cada nombre de componente de hardware.

SLURM_TOPOLOGY_ADDR_PATTERN
Esto se establece solo si el sistema tiene el complemento de topología / árbol
configurado. El valor se establecerá en los tipos de componentes enumerados en
SLURM_TOPOLOGY_ADDR. Cada componente se identificará como
"interruptor" o "nodo". Se utiliza un punto para separar cada hardware.
tipo de componente.

SRUN_DEBUG Establecer en el nivel de registro del correr mando. El valor predeterminado es 3
(nivel de información). El valor aumenta o disminuye según
las opciones --verbose y --quiet.

MPIRUN_NOALLOCATE No asigne un bloque solo a los sistemas Blue Gene.

MPIRUN_NOFREE No libere un bloque solo en los sistemas Blue Gene.

MPIRUN_PARTITION El nombre del bloque solo en los sistemas Blue Gene.

SEÑALES Y ESCAPE SECUENCIAS

Señales enviadas al correr El comando se reenvía automáticamente a las tareas que está
controlando con algunas excepciones. La secuencia de escape informará al estado
de todas las tareas asociadas con el correr mando. Si se ingresa dos veces dentro de una
En segundo lugar, la señal SIGINT asociada se enviará a todas las tareas y una terminación.
Se ingresará la secuencia enviando SIGCONT, SIGTERM y SIGKILL a todas las tareas generadas. Si un
third se recibe, el programa srun se terminará sin esperar
tareas remotas para salir o su E / S para completar.

La secuencia de escape actualmente se ignora. Nuestra intención es que esto ponga el correr
comando en un modo en el que se pueden invocar varias acciones especiales.

MPI SOPORTE

El uso de MPI depende del tipo de MPI que se utilice. Hay tres fundamentalmente diferentes
modos de funcionamiento utilizados por estas diversas implementaciones MPI.

1. Slurm lanza directamente las tareas y realiza la inicialización de las comunicaciones.
(Quadrics MPI, MPICH2, MPICH-GM, MVAPICH, MVAPICH2 y algunos modos MPICH1). Por ejemplo:
"srun -n16 a.out".

2. Slurm crea una asignación de recursos para el trabajo y luego mpirun lanza tareas usando
Infraestructura de Slurm (OpenMPI, LAM / MPI, HP-MPI y algunos modos MPICH1).

3. Slurm crea una asignación de recursos para el trabajo y luego mpirun lanza tareas usando
algún mecanismo que no sea Slurm, como SSH o RSH (BlueGene MPI y algunos modos MPICH1).
Estas tareas se iniciaron fuera del control o la supervisión de Slurm. El epílogo de Slurm debería ser
configurado para depurar estas tareas cuando se abandona la asignación del trabajo.

See http://slurm.schedmd.com/mpi_guide.html para obtener más información sobre el uso de estos diversos
Implementación de MPI con Slurm.

MÚLTIPLE PROGRAMA CONFIGURACIÓN

Los comentarios en el archivo de configuración deben tener un "#" en la columna uno. El archivo de configuración
contiene los siguientes campos separados por espacios en blanco:

Rango de tarea
Uno o más rangos de tareas para usar esta configuración. Varios valores pueden ser comas
apartado. Los rangos pueden indicarse con dos números separados por un '-' con el
primero un número más pequeño (por ejemplo, "0-4" y no "4-0"). Para indicar todas las tareas no
de lo contrario, especifique un rango de '*' como la última línea del archivo. Si una
Si se intenta iniciar una tarea para la que no se ha definido ningún programa ejecutable,
Se producirá el siguiente mensaje de error "No se ha especificado ningún programa ejecutable para este
tarea".

Ejecutable
El nombre del programa a ejecutar. Puede ser un nombre de ruta completo si se desea.

Argumentos
Argumentos del programa. La expresión "% t" se reemplazará con el número de la tarea.
La expresión "% o" se reemplazará con el desplazamiento de la tarea dentro de este rango (p. Ej.
un valor de rango de tarea configurado de "1-5" tendría valores de compensación de "0-4"). Único
Se pueden usar comillas para evitar que se interpreten los valores adjuntos. Este campo es
Opcional. Se agregarán todos los argumentos para el programa ingresados ​​en la línea de comando
a los argumentos especificados en el archivo de configuración.

Por ejemplo:
############################################################################################################################################################################################################################################################################################ #################
# srun archivo de configuración de varios programas
#
# srun -n8 -l --multi-prog tonto.conf
############################################################################################################################################################################################################################################################################################ #################
4-6 nombre de host
1,7 tarea de eco:% t
0,2-3 compensación de eco:% o

> srun -n8 -l --multi-prog tonto.conf
0: desplazamiento: 0
1: tarea: 1
2: desplazamiento: 1
3: desplazamiento: 2
4: linux15.llnl.gov
5: linux16.llnl.gov
6: linux17.llnl.gov
7: tarea: 7

EJEMPLOS

Este sencillo ejemplo demuestra la ejecución del comando hostname en ocho tareas. En
Se asignarán al menos ocho procesadores al trabajo (lo mismo que el recuento de tareas) en
sin embargo, se requieren muchos nodos para satisfacer la solicitud. El resultado de cada tarea será
procedió con su número de tarea. (La máquina "dev" en el ejemplo siguiente tiene un total de
dos CPU por nodo)

> srun -n8 -l nombre de host
0: dev0
1: dev0
2: dev1
3: dev1
4: dev2
5: dev2
6: dev3
7: dev3

El srun -r La opción se usa dentro de un script de trabajo para ejecutar dos pasos de trabajo en nodos separados en
el siguiente ejemplo. El script se ejecuta usando el modo de asignación en lugar de como un trabajo por lotes en
este caso.

> cat test.sh
#!/ Bin / sh
echo $ SLURM_NODELIST
srun -lN2 -r2 nombre de host
srun -lN2 nombre de host

> salloc -N4 test.sh
dev [7-10]
0: dev9
1: dev10
0: dev7
1: dev8

La siguiente secuencia de comandos ejecuta dos pasos de trabajo en paralelo dentro de un conjunto de nodos asignado.

> cat test.sh
#!/ bin / bash
srun -lN2 -n4 -r 2 dormir 60 &
srun -lN2 -r 0 dormir 60 &
sueño 1
chillar
apretar -s
esperar

> salloc -N4 test.sh
NOMBRE DE PARTICIÓN DE TRABAJO NODOS DE TIEMPO DE USUARIO ST NODELIST
65641 lote test.sh grondo R 0:01 4 dev [7-10]

NODELISTA DE TIEMPO DE USUARIO DE PARTICIÓN PASO A PASO
65641.0 lote grondo 0:01 dev [7-8]
65641.1 lote grondo 0:01 dev [9-10]

Este ejemplo demuestra cómo se ejecuta un trabajo MPICH simple. Usamos correr para construir un
lista de máquinas (nodos) que utilizará mpirún en su formato requerido. Un comando de muestra
sigue la línea y el script que se ejecutará.

> cat test.sh
#!/ Bin / sh
MACHINEFILE = "nodos. $ SLURM_JOB_ID"

# Genere Machinefile para mpich de manera que los hosts estén en el mismo
# orden como si se ejecutara a través de srun
#
srun-l / bin / nombre de host | sort -n | awk '{print $ 2}'> $ MACHINEFILE

# Ejecutar usando el archivo de máquina generado:
mpirun -np $ SLURM_NTASKS -machinefile $ MACHINEFILE mpi-aplicación

rm $ MACHINEFILE

> salloc -N2 -n4 test.sh

Este simple ejemplo demuestra la ejecución de diferentes trabajos en diferentes nodos en el
mismo srun. Puede hacer esto para cualquier número de nodos o trabajos. El
Los ejecutables se colocan en los nodos ubicados por SLURM_NODEID env var. Comenzando en 0 y
yendo al número especificado en la línea de comando srun.

> cat test.sh
caso $ SLURM_NODEID en
0) echo "Estoy corriendo"
nombre de host ;;
1) nombre de host
echo "es donde estoy corriendo" ;;
esac

> srun -N2 test.sh
dev0
es donde estoy corriendo
Estoy corriendo en
dev1

Este ejemplo demuestra el uso de opciones de varios núcleos para controlar el diseño de las tareas. Nosotros
Solicite que cuatro sockets por nodo y dos núcleos por socket se dediquen al trabajo.

> srun -N2 -B 4-4: 2-2 a.out

Este ejemplo muestra un script en el que Slurm se usa para proporcionar administración de recursos para un
trabajo ejecutando los diversos pasos del trabajo a medida que los procesadores estén disponibles para sus
utilizar.

> gato my.script
#!/ bin / bash
srun --exclusive -n4 prog1 &
srun --exclusive -n3 prog2 &
srun --exclusive -n1 prog3 &
srun --exclusive -n1 prog4 &
esperar

COPIA

Copyright (C) 2006-2007 The Regents de la Universidad de California. Producido en Lawrence
Laboratorio Nacional de Livermore (cf, DESCARGO DE RESPONSABILIDAD).
Copyright (C) 2008-2010 Lawrence Livermore Seguridad Nacional.
Derechos de autor (C) 2010-2015 SchedMD LLC.

Este archivo es parte de Slurm, un programa de gestión de recursos. Para obtener más detalles, consulte
<http://slurm.schedmd.com/>.

Slurm es un software gratuito; puedes redistribuirlo y / o modificarlo bajo los términos de la
Licencia pública general GNU publicada por la Free Software Foundation; ya sea la versión 2
de la Licencia, o (a su elección) cualquier versión posterior.

Slurm se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA; sin
incluso la garantía implícita de COMERCIABILIDAD o APTITUD PARA UN PROPÓSITO PARTICULAR. Ver el
Licencia pública general de GNU para más detalles.

Use srun en línea usando los servicios de onworks.net