Este es el comando sbatch que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.
PROGRAMA:
NOMBRE
sbatch: envíe un script por lotes a Slurm.
SINOPSIS
muestra [opciones] guión [args...]
DESCRIPCIÓN
sbatch envía un script por lotes a Slurm. La secuencia de comandos por lotes se puede dar para pasar a través de un
nombre de archivo en la línea de comando, o si no se especifica ningún nombre de archivo, sbatch leerá en un
secuencia de comandos de la entrada estándar. El script por lotes puede contener opciones precedidas por "#SBATCH"
antes de cualquier comando ejecutable en el script.
sbatch sale inmediatamente después de que el script se transfiere con éxito al Slurm
controlador y se le asignó un ID de trabajo Slurm. El script por lotes no se concede necesariamente
recursos inmediatamente, puede permanecer en la cola de trabajos pendientes durante algún tiempo antes de su
los recursos necesarios están disponibles.
De forma predeterminada, tanto la salida estándar como el error estándar se dirigen a un archivo con el nombre
"slurm-% j.out", donde "% j" se reemplaza con el número de asignación de trabajo. El archivo
generarse en el primer nodo de la asignación de trabajo. Aparte del propio script por lotes,
Slurm no mueve archivos de usuario.
Cuando finalmente se otorga la asignación de trabajo para el script por lotes, Slurm ejecuta una sola copia
del script por lotes en el primer nodo del conjunto de nodos asignados.
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
CAMPUS
-a, --formación=<índices>
Envíe una matriz de trabajos, varios trabajos para ejecutar con parámetros idénticos. El
índices La especificación identifica qué valores de índice de matriz deben usarse. Múltiple
Los valores se pueden especificar usando una lista separada por comas y / o un rango de valores con
un separador "-". Por ejemplo, "--array = 0-15" o "--array = 0,6,16-32". Un paso
La función también se puede especificar con un sufijo que contenga dos puntos y un número. Para
ejemplo, "--array = 0-15: 4" es equivalente a "--array = 0,4,8,12". Un número máximo de
las tareas que se ejecutan simultáneamente desde la matriz de trabajos se pueden especificar mediante un "%"
separador. Por ejemplo, "--array = 0-15% 4" limitará el número de
ejecutar tareas desde esta matriz de trabajos a 4. El valor de índice mínimo es 0. el máximo
El valor es uno menos que el parámetro de configuración MaxArraySize.
-A, --cuenta=<cuenta>
Cargue los recursos utilizados por este trabajo a la cuenta especificada. los cuenta 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 segundos.
El valor predeterminado para todos los demás intervalos es 0. Un intervalo de 0 desactiva el muestreo.
del tipo especificado. Si el intervalo de muestreo de la tarea es 0, la información contable
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 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 que esta opción sea
honrado. Esta opción no es compatible con los sistemas BlueGene (seleccione el complemento / bluegene
está configurado). Si no se especifica, se mostrará el trabajo de scontrol show
'Requerimientos: C: T = *: *: *'.
--cama y desayuno=<especulación>
Especificación de búfer de ráfagas. La forma de la especificación depende del sistema.
--empezar=<time>
Envíe el script por lotes al controlador Slurm inmediatamente, como de costumbre, pero dígale
el controlador para aplazar la asignación del trabajo hasta el momento especificado.
El tiempo puede ser de la forma HH: MM: SS ejecutar un trabajo a una hora específica del día (segundos
son opcionales). (Si ese tiempo ya pasó, se supone que será el día siguiente).
también especificar medianoche, mediodía, fika (3 p. M.) O la hora del té (4 p. M.) Y puedes tener un
hora del día con el sufijo AM or PM para correr por la mañana o por la noche. usted
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 now + 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 / blcrm 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 entre comillas dobles si se utilizan espacios o alguna
personajes.
-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"
Coincidencia de 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".
--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
ordenando
- 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-frecuencia =<p1[-p2[:p3]]>
Solicite que se ejecuten los pasos del trabajo iniciados por los comandos srun dentro de este script sbatch
a alguna frecuencia solicitada si es posible, en las CPU seleccionadas para el paso en el
calcular nodo (s).
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)
Rendimiento 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>
Avise al controlador Slurm que los siguientes pasos del trabajo requerirán ncpus número de
procesadores por tarea. Sin esta opción, el controlador simplemente intentará asignar
un procesador por tarea.
Por ejemplo, considere una aplicación que tiene 4 tareas, cada una requiere 3
procesadores. Si nuestro clúster está compuesto por nodos de cuatro procesadores y simplemente preguntamos
para 12 procesadores, el controlador puede darnos solo 3 nodos. Sin embargo, al usar
las --cpus-per-task = 3 opciones, el controlador sabe que cada tarea requiere 3
procesadores en el mismo nodo, y el controlador otorgará una asignación de 4
nodos, uno para cada una de las 4 tareas.
-d, --dependencia=<lista_dependencias>
Aplazar el inicio de este trabajo hasta que se hayan satisfecho las dependencias especificadas
terminado.lista_dependencias> tiene la forma
<tipo: 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, --dirección de trabajo=<directorio>
Establezca el directorio de trabajo del script por lotes en directorio antes de que se ejecute.
La ruta se puede especificar como ruta completa o ruta relativa al directorio donde
se ejecuta el comando.
-e, --error=<nombre de archivo patrón>
Indique a Slurm que conecte el error estándar del script por lotes directamente al archivo
nombre especificado en el "nombre de archivo patrón". De forma predeterminada, tanto la salida estándar como
los errores estándar se dirigen al mismo archivo. Para matrices de trabajos, el archivo predeterminado
el nombre es "slurm-% A_% a.out", "% A" se reemplaza por el ID del trabajo y "% a" por la matriz
índice. Para otros trabajos, el nombre de archivo predeterminado es "slurm-% j.out", donde "% j" es
reemplazado por el ID del trabajo. Ver el --aporte opción para las opciones de especificación de nombre de archivo.
--exclusive [= usuario]
La asignación de trabajos no puede compartir nodos con otros trabajos en ejecución (o simplemente con otros usuarios
con la opción "= usuario"). El comportamiento compartido / exclusivo predeterminado depende del sistema
configuración y la partición Compartido La opción tiene prioridad sobre la del trabajo.
.
--exportar=<entorno las variables | TODOS | NINGUNO>
Identifique qué variables de entorno se propagan al trabajo por lotes. Múltiple
Los nombres de las variables de entorno deben estar separados por comas. Nombres de variables de entorno
puede especificarse para propagar el valor actual de esas variables (p. ej.
"--export = EDITOR") o se pueden exportar valores específicos para las variables (p. ej.
"--export = EDITOR = / bin / vi") además de las variables de entorno que
de lo contrario, se configurará. Esta opción es particularmente importante para los trabajos que se envían
en un clúster y ejecutar en un clúster diferente (por ejemplo, con diferentes rutas). Por
por defecto, se propagan todas las variables de entorno. Si el argumento es NINGUNO or
nombres de variables de entorno específicos, luego el --get-usuario-entorno la opción será implícitamente
configurarse para cargar otras variables de entorno en función de la configuración del usuario en
el clúster que ejecuta el trabajo.
--exportar archivo=<nombre de archivo | fd>
Si se especifica un número entre 3 y OPEN_MAX como argumento para esta opción,
Se asumirá un descriptor de archivo legible (STDIN y STDOUT no son compatibles como
argumentos válidos). De lo contrario, se asume un nombre de archivo. Exportar variables de entorno
definido ennombre de archivo> o leer defd> al entorno de ejecución del trabajo. El
El contenido es una o más definiciones de variables de entorno de la forma NOMBRE = valor,
cada uno separado por un carácter nulo. Esto permite el uso de caracteres especiales en
definiciones ambientales.
-F, --nodefile=<nodo presentar>
Al igual que --nodelist, pero la lista está contenida en un archivo de nombre nodo presentar.
Los nombres de nodo de la lista también pueden abarcar varias líneas en el archivo. Nodo duplicado
se ignorarán los nombres del archivo. El orden de los nombres de los nodos en la lista no es
importante; los nombres de los nodos se ordenarán por Slurm.
--get-usuario-entorno[=tiempo de espera][modo]
Esta opción le dirá a sbatch que recupere las variables de entorno de inicio de sesión para el
usuario especificado en el --uido opción. Las variables de entorno son recuperadas por
ejecutando algo de este tipo "su - -C / usr / bin / env"y analizando el
producción. Tenga en cuenta que las variables de entorno ya configuradas en sbatch
El entorno tendrá prioridad sobre cualquier variable de entorno en el inicio de sesión del usuario.
ambiente. Borre las variables de entorno antes de llamar a sbatch que no tenga
desea propagar al programa generado. El opcional tiempo de espera el valor está en segundos.
El valor predeterminado es 8 segundos. El opcional modo value controla las opciones "su".
Con una modo valor de "S", "su" se ejecuta sin la opción "-". Con un modo
el valor de "L", "su" se ejecuta con la opción "-", replicando el inicio de sesión
medio ambiente. Si modo no especificado, el modo establecido en el tiempo de construcción de Slurm es
usado. Los ejemplos de uso incluyen "--get-user-env", "--get-user-env = 10"
"--get-user-env = 10L" y "--get-user-env = S". Esta opción fue creada originalmente
para uso de Moab.
--gid=<grupo de XNUMX>
If muestra 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".
-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
El script por lotes solo se enviará al controlador si los recursos
necesarios para otorgar su asignación de trabajo están disponibles de inmediato. Si el trabajo
La asignación tendrá que esperar en una cola de trabajos pendientes, el script por lotes no
ser enviado. NOTA: Hay soporte limitado para esta opción con trabajos por lotes.
--ignorar-pbs
Ignore las opciones "#PBS" especificadas en el script por lotes.
-i, --aporte=<nombre de archivo patrón>
Indique a Slurm que conecte la entrada estándar del script por lotes directamente al archivo
nombre especificado en el "nombre de archivo patrón".
De forma predeterminada, "/ dev / null" está abierto en la entrada estándar del script por lotes y tanto
la salida estándar y el error estándar se dirigen a un archivo con el nombre
"slurm-% j.out", donde "% j" se reemplaza con el número de asignación de trabajo, como
se describe a continuación.
El patrón de nombre de archivo puede contener uno o más símbolos de reemplazo, que son un
signo de porcentaje "%" seguido de una letra (por ejemplo,% j).
Los símbolos de reemplazo admitidos son:
%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 Número de asignación de trabajo.
%N Nombre del nodo. Solo se crea un archivo, por lo que% N será reemplazado por el nombre de
el primer nodo del trabajo, que es el que ejecuta el script.
%u Nombre de usuario.
-J, --nombre del trabajo=<nombre de trabajo>
Especifique un nombre para la asignación de trabajo. El nombre especificado aparecerá junto con
el número de identificación del trabajo al consultar trabajos en ejecución en el sistema. El predeterminado es el nombre
del script por lotes, o simplemente "sbatch" si el script se lee en el estándar de sbatch
entrada.
--Identificación del trabajo=<Identificación del trabajo>
Asignar recursos como el ID de trabajo especificado. NOTA: Solo válido para usuario root.
-k, --no matar
No finalice automáticamente un trabajo si uno de los nodos se le ha asignado
falla. El usuario asumirá las responsabilidades de tolerancia a fallos si un nodo
fallar. Cuando hay una falla en el nodo, cualquier paso de trabajo activo (generalmente trabajos MPI) en
ese nodo casi con certeza sufrirá un error fatal, pero con --no-kill, el trabajo
La asignación no se revocará, por lo que el usuario puede iniciar nuevos pasos de trabajo en el
nodos restantes en su asignación.
Por defecto, Slurm finaliza toda la asignación de trabajo si algún nodo falla en su
rango de nodos asignados.
--kill-on-invalid-dep=<si | no>
Si un trabajo tiene una dependencia no válida y nunca se puede ejecutar, este parámetro le dice a Slurm
terminarlo o no. Un estado de trabajo terminado será JOB_CANCELLED. Si esto
La opción no está especificada, se aplica el comportamiento de todo el sistema. Por defecto, el trabajo permanece
pendiente con motivo DependencyNeverSatisfied o si kill_invalid_depend es
especificado en slurm.conf, el trabajo finaliza.
-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"). Para enviar trabajos usando licencias remotas,
aquellos atendidos por slurmdbd, especifique el nombre del servidor que proporciona el
Licencias. Por ejemplo, "--license = nastran @ slurmdb: 12".
-M, - racimos=<cadena>
Clústeres para emitir comandos. Varios nombres de clústeres pueden estar separados por comas. El
el trabajo se enviará al grupo que proporciona el trabajo esperado más temprano
hora de iniciación. El valor predeterminado es el clúster actual. Un valor de 'all' voluntad
consulta para que se ejecute en todos los clústeres. Nota la --exportar opción para controlar el medio ambiente
variables exportadas entre clústeres.
-m, --distribución=
arbitrario|<bloquear|cíclico|plano =[:bloquear|cíclico|cíclico]>
Especifique métodos de distribución alternativos para procesos remotos. En sbatch, esto solo
establece variables de entorno que serán utilizadas por solicitudes srun posteriores. Esta
La opción controla la asignación de tareas a los nodos en los que se han
asignados, y la distribución de esos recursos a las tareas para la vinculación (tarea
afinidad). El primer método de distribución (antes de ":") controla la distribución
de recursos en los nodos. El segundo método de distribución opcional (después de ":")
controla la distribución de recursos a través de sockets dentro de un nodo. Tenga en cuenta que
con select / cons_res, el número de cpus asignados en cada socket y nodo puede ser
diferente. Referirse a http://slurm.schedmd.com/mc_support.html para obtener más información.
sobre la asignación de recursos, la asignación de tareas a los nodos y la vinculación de tareas a las CPU.
Primer método de distribución:
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
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, anulará cualquier otro método especificado. Que no
establecer el método predeterminado para bloquear. Dentro del archivo host debe contener en
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:
bloquear El método de distribución de bloques distribuirá las tareas a los sockets de manera que
las tareas consecutivas comparten un enchufe.
cíclico El método de distribución cíclica distribuirá las tareas a los enchufes de manera que
las tareas consecutivas se distribuyen en sockets consecutivos (en un round-robin
Moda). Las tareas que requieren más de una CPU tendrán todas esas CPU
asignado en un solo socket si es posible.
cíclico
El método de distribución cíclica distribuirá las tareas a los sockets de manera que
las tareas consecutivas se distribuyen en sockets consecutivos (en un round-robin
Moda). Las tareas que requieren más de una CPU tendrán cada CPU asignada
de forma cíclica a través de enchufes.
- 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. Las notificaciones por correo sobre el trabajo BEGIN, END y FAIL se aplican a un trabajo
matriz como un todo en lugar de generar mensajes de correo electrónico individuales para cada tarea en
la matriz de trabajos.
--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) Ver también --mem-por-cpu. --mem --mem-por-cpu están
mutuamente excluyentes. NOTA: La especificación del tamaño de la memoria se trata como un caso especial.
y otorga al trabajo acceso a toda la memoria en cada nodo. NOTA: Cumplimiento de
Los límites de memoria actualmente se basan en el complemento task / cgroup o en la habilitación de
contabilidad, que muestra el uso de memoria de forma periódica (no es necesario almacenar datos,
recién recogido). En ambos casos, el uso de la memoria se basa en el tamaño del conjunto residente del trabajo.
(RSS). Una tarea puede exceder el límite de memoria hasta la próxima contabilidad periódica.
muestra.
--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. Ver también
--mem. --mem --mem-por-cpu son 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. Note en la de la forma más resolución of CPU 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
. El proyecto 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
"--mem_bind = verbose, none" para determinar la configuración específica.
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.
-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_NNODES se establecerá en el recuento de nodos realmente asignados al trabajo. Ver
de la forma más MEDIO AMBIENTE VARIABLES sección para obtener más información. Si -N no está especificado,
El comportamiento predeterminado es asignar suficientes nodos para satisfacer los requisitos de la
-n -c opciones. El trabajo se asignará a tantos nodos como sea posible dentro del
rango especificado y sin retrasar el inicio del trabajo. El recuento de nodos
La especificación puede incluir un valor numérico seguido de un sufijo de "k" (multiplica
valor numérico por 1,024) o "m" (multiplica el valor numérico por 1,048,576).
-n, --tareas=<número>
sbatch no lanza tareas, solicita una asignación de recursos y envía una
secuencia de comandos por lotes. Esta opción advierte al controlador Slurm que los pasos del trabajo se ejecutan dentro
la asignación lanzará un máximo de número tareas y proporcionar suficientes
recursos. El valor predeterminado es una tarea por nodo, pero tenga en cuenta que el --cpus-por-tarea
La 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 deben especificar de la forma más
- 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.
El proyecto 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.
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.
--sin cola
Especifica que el trabajo por lotes nunca se debe poner en cola bajo ninguna circunstancia.
Establecer esta opción evitará que los administradores del sistema puedan reiniciar
el trabajo (por ejemplo, después de un tiempo de inactividad programado), recuperarse de una falla de nodo, o
ser puesto en cola al ser reemplazado por un trabajo de mayor prioridad. Cuando un trabajo se pone en cola,
La secuencia de comandos por lotes se inicia desde el principio. También vea el --requear opción. La
TrabajoRequeue El parámetro de configuración controla el comportamiento predeterminado en el clúster.
--ntasks-por-núcleo=<ntareas>
Solicita el máximo ntareas invocarse en cada núcleo. Destinado a ser utilizado con el
--tareas opción. Relacionado con --ntasks-por-nodo excepto en el nivel central en lugar de
el nivel de nodo. NOTA: Esta opción no es compatible a menos que
SelectTypeParameters = CR_Core or SelectTypeParameters = CR_Core_Memory está configurado
--ntasks-por-socket=<ntareas>
Solicita el máximo ntareas ser invocado en cada socket. Destinado a ser utilizado con el
--tareas opción. Relacionado con --ntasks-por-nodo excepto en el nivel del zócalo en su lugar
del nivel de nodo. NOTA: Esta opción no es compatible a menos que
SelectTypeParameters = CR_Socket or SelectTypeParameters = CR_Socket_Memory is
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.
-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=<nombre de archivo patrón>
Indique a Slurm que conecte la salida estándar del script por lotes directamente al archivo
nombre especificado en el "nombre de archivo patrón". De forma predeterminada, tanto la salida estándar como
los errores estándar se dirigen al mismo archivo. Para matrices de trabajos, el archivo predeterminado
el nombre es "slurm-% A_% a.out", "% A" se reemplaza por el ID del trabajo y "% a" por la matriz
índice. Para otros trabajos, el nombre de archivo predeterminado es "slurm-% j.out", donde "% j" es
reemplazado por el ID del trabajo. Ver el --aporte opción para las opciones de especificación de nombre de archivo.
--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.
- analizable
Muestra solo el número de identificación del trabajo y el nombre del clúster, si está presente. Los valores son
separados por un punto y coma. Los errores seguirán apareciendo.
-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, ...).
lustre Se recopilan datos de brillo.
Nuestra red Se recopilan datos de la red (InfiniBand).
--propagar[=límitefR]
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):
TODOS 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
-Q, --tranquilo
Suprime los mensajes informativos de sbatch. Los errores seguirán apareciendo.
--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.
--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.
--requear
Especifica que el trabajo por lotes debe ser apto para ser puesto en cola. El trabajo puede ser
puesto en cola explícitamente por un administrador del sistema, después de la falla del nodo, o en caso de
apropiación por un trabajo de mayor prioridad. Cuando un trabajo se pone en cola, el script por lotes se
iniciado desde su inicio. También vea el --sin cola opción. La TrabajoRequeue
El parámetro de configuración controla el comportamiento predeterminado en el clúster.
--reserva=<nombre >
Asignar recursos para el trabajo desde la reserva nombrada.
-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= [B:]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. Utilice la opción "B:" para
señalizar solo el shell del lote, no se señalizará ninguno de los otros procesos. Por
por defecto, se señalarán todos los pasos del trabajo, pero no el shell del lote en sí.
--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, --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".
--tareas por nodo=<n>
Especifique la cantidad de tareas que se ejecutarán por nodo. Equivalente a
--ntasks-por-nodo.
- solo prueba
Valide el script por lotes y devuelva una estimación de cuándo se programaría un trabajo
para ejecutar dada la cola de trabajos actual y todos los demás argumentos que especifican el trabajo
requisitos. En realidad, no se envía ningún trabajo.
--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, --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, muestra 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
Aumente la verbosidad de los mensajes informativos de sbatch. Múltiple -vvoluntad
aumentar aún más la verbosidad de sbatch. De forma predeterminada, solo se mostrarán los errores.
-w, --lista de nodos=<nodo nombre lista>
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. Los nombres de nodos duplicados en la lista serán
ignorado. El orden de los nombres de los nodos en la lista no es importante; los nombres de los nodos
serán ordenados por Slurm.
--esperar-a-todos-los-nodos=<propuesta de>
Controla cuando comienza la ejecución del comando. Por defecto, el trabajo comenzará
ejecución tan pronto como se realice la asignación.
0 Inicie la ejecución tan pronto como se pueda realizar la asignación. No espere por todos los nodos
estar listo para usar (es decir, arrancado).
1 No comience la ejecución hasta que todos los nodos estén listos para su uso.
- hockey=<wckey>
Especifique el wckey que se utilizará con el trabajo. Si TrackWCKey = no (predeterminado) en slurm.conf
este valor se ignora.
--envoltura=<comando cadena>
Sbatch envolverá la cadena de comando especificada en un simple script de shell "sh", y
envíe ese script al controlador slurm. Cuando se usa --wrap, un nombre de secuencia de comandos y
los argumentos no se pueden especificar en la línea de comando; en su lugar, el sbatch generado
Se utiliza la secuencia de comandos de envoltura.
-x, --excluir=<nodo nombre lista>
Excluya explícitamente ciertos nodos de los recursos otorgados al trabajo.
Las siguientes opciones son compatibles con los sistemas Blue Gene, pero pueden ser aplicables a otros sistemas como
bien.
--blrts-imagen=<camino>
Ruta a Blue GeneL Run Time Supervisor, o blrts, imagen para el bloque bluegene. BGL
solo. Predeterminado de blugene.conf si no está configurado.
--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.
ENTRADA MEDIO AMBIENTE VARIABLES
Al iniciarse, sbatch leerá y manejará las opciones configuradas en el siguiente entorno
variables. Tenga en cuenta que las variables de entorno anularán cualquier opción establecida en un lote
script, y las opciones de la línea de comandos anularán cualquier variable de entorno.
SBATCH_CUENTA Igual que -UN, --cuenta
SBATCH_ACCTG_FREQ Igual que --acctg-freq
SBATCH_ARRAY_INX Igual que -a --formación
SBATCH_BLRTS_IMAGE Igual que --blrts-imagen
SBATCH_BURST_BUFFER Igual que --cama y desayuno
SBATCH_PUNTO DE CONTROL Igual que --control
SBATCH_CHECKPOINT_DIR Igual que --punto de control-dir
SBATCH_CLUSTERS or SLURM_CLUSTERS
Igual que - racimos
SBATCH_CNLOAD_IMAGE Igual que --cnload-imagen
SBATCH_CONN_TYPE Igual que - tipo de conexión
SBATCH_CORE_SPEC Igual que --núcleo-spec
SBATCH_DEBUG Igual que -v, --verboso
SBATCH_DISTRIBUCIÓN Igual que -metro, --distribución
SBATCH_EXCLUSIVO Igual que --exclusivo
SBATCH_EXPORTAR Igual que --exportar
SBATCH_GEOMETRÍA Igual que -gramo, --geometría
SBATCH_GET_USER_ENV Igual que --get-usuario-entorno
SBATCH_SUGERENCIA or SLURM_SUGERENCIA
Igual que --insinuación
SBATCH_IGNORE_PBS Igual que --ignorar-pbs
SBATCH_IMMEDIATE Igual que -YO, --inmediato
SBATCH_IOLOAD_IMAGE Igual que --ioload-imagen
SBATCH_JOBID Igual que --Identificación del trabajo
SBATCH_JOB_NOMBRE Igual que -J, --nombre del trabajo
SBATCH_LINUX_IMAGE Igual que --linux-imagen
SBATCH_MEM_BIND Igual que --mem_bind
SBATCH_MLOOADER_IMAGE Igual que --mloader-imagen
SBATCH_RED Igual que --la red
SBATCH_NO_REQUEUE Igual que --sin cola
SBATCH_NO_ROTATE Igual que -R, --no rotar
SBATCH_OPEN_MODE Igual que --modo abierto
SBATCH_OVERCOMMIT Igual que -Oh, - comprometerse en exceso
SBATCH_PARTICIÓN Igual que -pag, --dividir
SBATCH_POWER Igual que --poder
PERFIL_SBATCH Igual que --perfil
SBATCH_QOS Igual que --qos
SBATCH_RAMDISK_IMAGE Igual que --imagen de disco RAM
SBATCH_RESERVACIÓN Igual que --reserva
SBATCH_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
SBATCH_REQUEUE Igual que --requear
SBATCH_SICP Igual que --sicp
SBATCH_SIGNAL Igual que --señal
SBATCH_THREAD_SPEC Igual que --especificación de hilo
SBATCH_TIMELIMIT Igual que -t, --tiempo
SBATCH_WAIT_ALL_NODES Igual que --esperar-a-todos-los-nodos
SBATCH_WAIT4SWITCH Tiempo máximo de espera de los conmutadores solicitados. Ver - interruptores
SBATCH_WCKEY Igual que - hockey
Slurm_conf La ubicación del archivo de configuración de Slurm.
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.
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.
SALIDA MEDIO AMBIENTE VARIABLES
El controlador Slurm establecerá las siguientes variables en el entorno del lote
guión.
BASIL_RESERVATION_ID
El ID de reserva en los sistemas Cray que ejecutan ALPS / BASIL únicamente.
MPIRUN_NOALLOCATE
No asigne un bloque en sistemas Blue Gene L / P únicamente.
MPIRUN_NOFREE
No libere un bloque solo en los sistemas Blue Gene L / P.
MPIRUN_PARTITION
El nombre del bloque solo en los sistemas Blue Gene.
SBATCH_CPU_BIND
Establezca el valor de la opción --cpu_bind.
SBATCH_CPU_BIND_VERBOSE
Establézcalo en "verbose" si la opción --cpu_bind incluye la opción verbose. Ajustado a
"tranquilo" de lo contrario.
SBATCH_CPU_BIND_TYPE
Establezca el tipo de enlace de CPU especificado con la opción --cpu_bind. Valores posibles
dos posibles cadenas separadas por comas. La primera cadena posible identifica el
entidad a la que se vinculará: "hilos", "núcleos", "sockets", "ldoms" y "tableros". El
La segunda cadena identifica la forma en que se enlazan las tareas: "ninguna", "rango",
"map_cpu", "mask_cpu", "rank_ldom", "map_ldom" o "mask_ldom".
SBATCH_CPU_BIND_LIST
Establezca la máscara de bits utilizada para el enlace de la CPU.
SBATCH_MEM_BIND
Establezca el valor de la opción --mem_bind.
SBATCH_MEM_BIND_VERBOSE
Establézcalo en "verbose" si la opción --mem_bind incluye la opción verbose. Ajustado a
"tranquilo" de lo contrario.
SBATCH_MEM_BIND_TYPE
Establezca el tipo de enlace de memoria especificado con la opción --mem_bind. Posible
los valores son "none", "rank", "map_map", "mask_mem" y "local".
SBATCH_MEM_BIND_LIST
Establezca la máscara de bits utilizada para el enlace de memoria.
SLURM_ARRAY_TASK_ID
Número de ID de matriz de trabajo (índice).
SLURM_ARRAY_TASK_MAX
Número máximo de ID (índice) de la matriz de trabajos.
SLURM_ARRAY_TASK_MIN
Número mínimo de ID (índice) de la matriz de trabajos.
SLURM_ARRAY_TASK_STEP
Tamaño del paso del índice de la matriz de trabajos.
SLURM_ARRAY_JOB_ID
Número de identificación del trabajo maestro de la matriz de trabajos.
SLURM_CHECKPOINT_IMAGE_DIR
Directorio en el que se deben escribir las imágenes de puntos de control si se especifica en el
ejecutar línea.
SLURM_CLUSTER_NOMBRE
Nombre del clúster en el que se está ejecutando el trabajo.
SLURM_CPUS_ON_NODE
Número de CPUS en el nodo asignado.
SLURM_CPUS_PER_TASK
Número de cpus solicitados por tarea. Solo se establece si el --cpus-por-tarea opción es
especificado.
SLURM_DISTRIBUCIÓN
Igual que -metro, --distribución
SLURM_GTIDS
ID de tareas globales que se ejecutan en este nodo. Origen cero y separados por comas.
SLURM_JOB_ID (y SLURM_JOBID para compatibilidad con versiones anteriores)
El ID de la asignación de trabajo.
SLURM_JOB_CPUS_PER_NODE
Recuento de procesadores disponibles para el trabajo en este nodo. Tenga en cuenta el select / linear
El complemento asigna nodos completos a trabajos, por lo que el valor indica el recuento total de
CPU en el nodo. El complemento select / cons_res asigna procesadores individuales a
trabajos, por lo que este número indica el número de procesadores en este nodo asignados a
el trabajo.
SLURM_JOB_DEPENDENCY
Establezca el valor de la opción --dependency.
SLURM_JOB_NOMBRE
Nombre del trabajo.
SLURM_JOB_NODELIST (y SLURM_NODELIST para compatibilidad con versiones anteriores)
Lista de nodos asignados al 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_JOB_PARTITION
Nombre de la partición en la que se está ejecutando el trabajo.
SLURM_LOCALID
ID de tarea local de nodo para el proceso dentro de un trabajo.
SLURM_NODE_ALIASES
Conjuntos de nombre de nodo, dirección de comunicación y nombre de host para los nodos asignados al
trabajo desde la nube. Cada elemento del conjunto está separado por dos puntos y cada conjunto es
separado por comas. Por ejemplo: SLURM_NODE_ALIASES = ec0: 1.2.3.4: foo, ec1: 1.2.3.5: bar
SLURM_NODEID
ID de los nodos asignados.
SLURMD_NODENAME
Nombres de todos los nodos asignados.
SLURM_NTASKS (y SLURM_NPROCS para compatibilidad con versiones anteriores)
Igual que -norte, --tareas
SLURM_NTASKS_PER_CORE
Número de tareas solicitadas por núcleo. Solo se establece si el --ntasks-por-núcleo opción es
especificado.
SLURM_NTASKS_PER_NODE
Número de tareas solicitadas por nodo. Solo se establece si el --ntasks-por-nodo opción es
especificado.
SLURM_NTASKS_PER_SOCKET
Número de tareas solicitadas por socket. Solo se establece si el --ntasks-por-socket opción
está especificado.
SLURM_PRIO_PROCESO
La prioridad de programación (buen valor) en el momento del envío del trabajo. Este valor es
propagado a los procesos engendrados.
SLURM_PROCID
El rango de MPI (o ID de proceso relativo) del proceso actual
PERFIL_SLURM
Igual que --perfil
SLURM_RESTART_COUNT
Si el trabajo se ha reiniciado debido a una falla del sistema o ha sido explícitamente
en cola, esto se enviará a la cantidad de veces que se haya reiniciado el trabajo.
SLURM_SUBMIT_DIR
El directorio desde el que muestra fue invocado.
SLURM_SUBMIT_HOST
El nombre de host de la computadora desde la que muestra fue invocado.
SLURM_TASKS_PER_NODE
Número de tareas a iniciar en cada nodo. Los valores están separados por comas y en el
mismo orden que SLURM_NODELIST. Si dos o más nodos consecutivos van a tener la
mismo recuento de tareas, ese recuento va seguido de "(x #)" donde "#" es la repetición
contar. Por ejemplo, "SLURM_TASKS_PER_NODE = 2 (x3), 1" indica que los tres primeros
cada uno de los nodos ejecutará tres tareas y el cuarto nodo ejecutará una tarea.
SLURM_TASK_PID
El ID de proceso de la tarea que se está iniciando.
SLURM_TOPOLOGY_ADDR
Esto se establece solo si el sistema tiene configurado el complemento de topología / árbol. El
El valor se establecerá en los nombres de los conmutadores de red que pueden estar involucrados en el
comunicaciones del trabajo desde el interruptor de nivel superior del sistema hasta el interruptor de hoja
y termina con el nombre del nodo. Se utiliza un punto para separar cada componente de hardware.
nombre.
SLURM_TOPOLOGY_ADDR_PATTERN
Esto se establece solo si el sistema tiene configurado el complemento de topología / árbol. El
El valor se establecerá en los tipos de componentes enumerados en SLURM_TOPOLOGY_ADDR. Cada
El componente se identificará como "conmutador" o "nodo". Se usa un punto para
separe cada tipo de componente de hardware.
EJEMPLOS
Especifique un script por lotes por nombre de archivo en la línea de comando. El script por lotes especifica un 1
límite de tiempo de un minuto para el trabajo.
$ gato myscript
#!/ Bin / sh
#SBATCH --time = 1
srun nombre de host | ordenar
$ muestra -N4 myscript
salloc: asignación de trabajo concedida 65537
$ gato slurm-65537.out
host1
host2
host3
host4
Pase un script por lotes a sbatch en la entrada estándar:
$ sbatch -N4 <
> #!/ Bin / sh
> srun nombre de host | ordenar
> EOF
sbatch: trabajo por lotes enviado 65541
$ gato slurm-65541.out
host1
host2
host3
host4
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 sbatch en línea usando los servicios de onworks.net
