08 ‐ Verificando status e utilização - arcarneiro/teste-doc-sdumont GitHub Wiki

Table of Contents

Informações gerais

Os principais comandos do SLURM para verificação e acompanhamento são:

  • squeue [parametros]: Exibe informações sobre os jobs e o escalonamento
  • squeue --start: Exibe o tempo esperado de quando um job entrará em execução (coluna START_TIME)
  • sinfo [parametros]: Exibe informações sobre as filas/partições e os nós.
  • scontrol show jobid #NUMERO-DO-JOB -dd: Exibe informações detalhadas sobre um job.
Para informações detalhadas de cada um, utilizar o man COMANDO

Início


Status/Reason do job

Ao executar o comando squeue ou sacct, o job pode estar em um dos seguintes estados (coluna "ST"):

  • CA - CANCELLED: O job foi explicitamente cancelado pelo usuário ou pelo administrador.
  • CD - COMPLETED: O job foi terminou normalmente, finalizando todos os seus processos em todos os nós.
  • CG - COMPLETING: O job está no processo de finalização. Alguns dos processos ainda podem estar em execução em um dos nós.
  • F - FAILED: O job terminou com um código de saída diferente de zero, indicando falha na execução/finalização.
  • NF - NODE_FAIL: O job terminou devido a uma falha em um ou mais nós.
  • PD - PENDING: O job está aguardando em fila pela alocação/liberação de recursos.
  • R - RUNNING: O job em execução.
  • TO - TIMEOUT: O job foi terminado por ter alcançado o seu limite de tempo.
Ao executar o comando squeue, a coluna REASON (Razão) explica porque um job está aguardando na fila, com o status PD - PENDING. As razões mais comuns são:
  • AssociationJobLimit: Foi atingido o limite máximo do número de jobs.
  • PartitionNodeLimit: O número de nós solicitado pelo job está fora do limite da Fila.
  • AssocMaxNodesPerJobLimit: O job solicitou um número de nós acima do permitido.
  • AssocMaxJobsLimit: Geralmente ocorre quando excedeu o número de jobs em execução da fila.
  • AssocMaxWallDurationPerJobLimit: O job solicitou um tempo de execução maior do que o permitido pela fila
  • BeginTime: O job possui um horário determinado para iniciar, que ainda não foi atingido.
  • Dependency: O job está aguardando a finalização de uma dependência para poder iniciar.
  • JobHeldAdmin: O job foi suspenso pelo administrador.
  • JobHeldUser: O job foi suspenso pelo usuário.
  • NodeDown: Um ou mais nós necessários para o job está "Down".
  • PartitionDown: A fila (partição) solicitada pelo job está "Down".
  • PartitionInactive: A fila (partição) solicitada pelo job está Inativa.
  • Priority: Um ou mais jobs de maior prioridade estão à frente na fila, aguardando a execução.
  • ReqNodeNotAvail: Um ou mais nós solicitados pelo job não estão disponíveis.
  • Resources: O job está aguardando os recursos solicitados ficarem disponíveis, geralmente relacionado ao número de nós.
Início

Visualizando o consumo dos recursos compartilhados

É possível utilizar o comando sinfo para exibir uma visualização personalizada das informações das filas.

Visualizando os recursos (CPUS) da fila:

$ sinfo -p sequana_cpu -o "%P %.5a %.10l %.6D %C"
PARTITION AVAIL TIMELIMIT NODES CPUS(A/I/O/T)
sequana_cpu up infinite 80 12/3828/0/3840

No exemplo acima visualizamos que temos 12 cores ocupados (A), 3828 disponíveis (I), nenhum nó offline (O) e um total de 3840 cores disponíveis (T) na fila.

Visualizando os recursos de cada nó da fila:

Para visualizar o consumo dos cores de cada nó, devemos acrescentar o parâmentro -N e adicionar o cabeçalho %N ao comando:

$ sinfo -N -p sequana_cpu -o "%N %.5a %.10l %.6D %C"
NODELIST AVAIL TIMELIMIT NODES CPUS(A/I/O/T)
sdumont6085 up infinite 1 12/36/0/48
sdumont6086 up infinite 1 0/48/0/48
sdumont6087 up infinite 1 0/48/0/48
sdumont6088 up infinite 1 0/48/0/48
sdumont6089 up infinite 1 0/48/0/48
...

O resultado apresenta que todos os 12 cores foram alocados no nó sdumont6085. Os demais nós da fila estão totalmente livres.

Início


Remover jobs da fila ou em execução

 scancel [parametros] #NUMERO-DO-JOB

Início


Informações sobre a Utilização

Para obter informações sobre a utilização dos recursos do SDumont por um projeto, é possível utilizar um dos comandos abaixo:

  • sacct -lj #NUMERO-DO-JOB: Exibe informações de accounting do job.
  • sacct -S AAAA-MM-DD -E AAAA-MM-DD -X -A PROJETO: Exibe a lista dos jobs que foram executados pelo projeto em um determinado período.
  • sreport -t hours job SizesByAccount start=AAAA-MM-DD end=AAAA-MM-DD Users=USUARIO FlatView Grouping=12001: Exibe o total (em horas) utilizado durante o período, delimitado pelos parâmetros start e end.
  • sreport -t hours cluster AccountUtilizationByUser start=AAAA-MM-DD end=AAAA-MM-DD Accounts=PROJETO: Exibe a quantidade de horas utilizada pelo projeto durante um período, delimitado pelos parâmetros start e end.
  • sacctmgr list user $USER -s format=partition%20,MaxJobs,MaxSubmit,MaxNodes,MaxCPUs,MaxWall: Exibe as filas que você possui acesso, listando o nome das filas (partition), o número máximo de jobs em execução simultânea (MaxJobs), o número máximo de jobs que podem ser submetidos (MaxSubmit), o número máximo de nós e de cores (MaxNodes e MaxCPUs) e o tempo limite de execução (MaxWall). Lembramos que os direitos de acesso às filas são atribuídos conforme o programa de alocação do seu projeto.
    • OBS: a variável de ambiente "$USER" contém o seu login, logo, o comando da forma como está vai listar as informações para o seu usuário.
Essa informação sobre a utilização também está disponível na intranet do SDumont, acessível apenas para o coordenador de cada projeto.

Início


Variáveis de ambiente do Slurm

O Slurm configura as seguintes variáveis no ambiente do Job (acessíveis dentro do script de submissão):

  • SLURM_ARRAY_TASK_ID
    • Job array ID (index) number.
  • SLURM_ARRAY_JOB_ID
    • Job array's master job ID number.
  • SLURM_CHECKPOINT_IMAGE_DIR
    • Directory into which checkpoint images should be written if specified on the execute line.
  • SLURM_CLUSTER_NAME
    • Name of the cluster on which the job is executing.
  • SLURM_CPUS_ON_NODE
    • Number of CPUS on the allocated node.
  • SLURM_CPUS_PER_TASK
    • Number of cpus requested per task. Only set if the --cpus-per-task option is specified.
  • SLURM_DISTRIBUTION
    • Same as -m, --distribution
  • SLURM_GTIDS
    • Global task IDs running on this node. Zero origin and comma separated.
  • SLURM_JOB_ID (and SLURM_JOBID for backwards compatibility)
    • The ID of the job allocation.
  • SLURM_JOB_CPUS_PER_NODE
    • Count of processors available to the job on this node. Note the select/linear plugin allocates entire nodes to jobs, so the value indicates the total count of CPUs on the node. The select/cons_res plugin allocates individual processors to jobs, so this number indicates the number of processors on this node allocated to the job.
  • SLURM_JOB_DEPENDENCY
    • Set to value of the --dependency option.
  • SLURM_JOB_NAME
    • Name of the job.
  • SLURM_JOB_NODELIST (and SLURM_NODELIST for backwards compatibility)
    • List of nodes allocated to the job.
  • SLURM_JOB_NUM_NODES (and SLURM_NNODES for backwards compatibility)
    • Total number of nodes in the job's resource allocation.
  • SLURM_JOB_PARTITION
    • Name of the partition in which the job is running.
  • SLURM_LOCALID
    • Node local task ID for the process within a job.
  • SLURM_MEM_BIND
    • Set to value of the --mem_bind option.
  • SLURM_NODE_ALIASES
    • Sets of node name, communication address and hostname for nodes allocated to the job from the cloud. Each element in the set if colon separated and each set is comma sepa rated. For example: SLURM_NODE_ALIASES=ec0:1.2.3.4:foo,ec1:1.2.3.5:bar
  • SLURM_NODEID
    • ID of the nodes allocated.
  • SLURMD_NODENAME
    • Names of all the allocated nodes.
  • SLURM_NTASKS (and SLURM_NPROCS for backwards compatibility)
    • Same as -n, --ntasks
  • SLURM_NTASKS_PER_CORE
    • Number of tasks requested per core. Only set if the --ntasks-per-core option is specified.
  • SLURM_NTASKS_PER_NODE
    • Number of tasks requested per node. Only set if the --ntasks-per-node option is specified.
  • SLURM_NTASKS_PER_SOCKET
    • Number of tasks requested per socket. Only set if the --ntasks-per-socket option is specified.
  • SLURM_PRIO_PROCESS
    • The scheduling priority (nice value) at the time of job submission. This value is propagated to the spawned processes.
  • SLURM_PROCID
    • The MPI rank (or relative process ID) of the current process
  • SLURM_PROFILE
    • Same as --profile
  • SLURM_RESTART_COUNT
    • If the job has been restarted due to system failure or has been explicitly requeued, this will be sent to the number of times the job has been restarted.
  • SLURM_SUBMIT_DIR
    • The directory from which sbatch was invoked.
  • SLURM_SUBMIT_HOST
    • The hostname of the computer from which sbatch was invoked.
  • SLURM_TASKS_PER_NODE
    • Number of tasks to be initiated on each node. Values are comma separated and in the same order as SLURM_NODELIST. If two or more consecutive nodes are to have the same task count, that count is followed by "(x#)" where "#" is the repetition count. For example, "SLURM_TASKS_PER_NODE=2(x3),1" indicates that the first three nodes will each execute three tasks and the fourth node will execute one task.
  • SLURM_TASK_PID
    • The process ID of the task being started.
  • SLURM_TOPOLOGY_ADDR
    • This is set only if the system has the topology/tree plugin configured. The value will be set to the names network switches which may be involved in the job's communications from the system's top level switch down to the leaf switch and ending with node name. A period is used to separate each hardware component name.
  • SLURM_TOPOLOGY_ADDR_PATTERN
    • This is set only if the system has the topology/tree plugin configured. The value will be set component types listed in SLURM_TOPOLOGY_ADDR. Each component will be identified as either "switch" or "node". A period is used to separate each hardware component type.
Início
⚠️ **GitHub.com Fallback** ⚠️