06 ‐ Gerenciador de filas - arcarneiro/teste-doc-sdumont GitHub Wiki
Não é permitido a execução de aplicações nos nós de login (sdumont[15-18]). Os processos em execução contínua, nesses nós, possuem um tempo limite de 30 minutos.
O gerenciador de filas utilizado é o Slurm v23.11.1 (Customizado pela ATOS/EVIDEN). Todos os jobs devem ser submetidos através do Slurm.
As filas de execução do Slurm são:
| Fila | Wall-clock máximo (em horas) | Número mínimo de nós (núcleos+ dispositivos) | Número máximo de nós (núcleos+ dispositivos) | Número máximo de tarefas em execução por usuário | Número máximo de tarefas em fila por usuário | Custo em Unidade de Alocação (UA) |
|---|---|---|---|---|---|---|
| sequana_cpu | 96 | 1 (48) | 50 (2400) | 4 | 24 | 1,0 |
| sequana_cpu_dev1 | 0:20 | 1 (48) | 4 (192) | 1 | 1 | 1,0 |
| sequana_cpu_long2 | 744 (31 dias) | 1 (48) | 10 (480) | 3 | 18 | 1,0 |
| sequana_cpu_bigmem3 | 96 | 1 (48) | 18 (864) | 4 | 24 | 1,0 |
| sequana_cpu_bigmem_long3 | 744 (31 dias) | 1 (48) | 5 (240) | 3 | 18 | 1,0 |
| sequana_gpu | 96 | 1 (48+4) | 21 (1008+84) | 4 | 24 | 1,5 |
| sequana_gpu_dev1 | 0:20 | 1 (48+4) | 4 (192+16) | 1 | 1 | 1,5 |
| sequana_gpu_long2 | 744 (31 dias) | 1 (48+4) | 10 (480+40) | 3 | 18 | 1,5 |
| gdl4 (Nós Sequana IA) | 48 | 1 (40+8) | 1 (40+8) | 1 | 6 | 2,0 |
- 1: Filas de desenvolvimento e teste, com limites reduzidos. Essas filas devem ser utilizadas para testar o script de submissão e a correta execução da aplicação, além de possibilitar execuções rápidas, como a preparação de arquivos de entrada. A prioridade dessas filas é maior, para que os testes possam entrar em execução mais rapidamente.
- 2: Filas especiais para jobs que necessitam de longa duração.
- 3: As filas sequana_cpu_bigmem* estão configuradas com nós que possuem 768 GB de memória RAM. O acesso a essas filas é exclusivo para projetos Premium.
- 4: A fila gdl é destinada a utilizar o nó Bull Sequana focado em Machine Learning/Deep Learning.
- OBS.1: Além dos limites das filas para cada usuário, ainda há um limite global por projeto, que é compartilhado por todos os usuários do mesmo. Cada projeto está limitado em 100 jobs (executando [RUNNING] ou em espera [PENDING]) por vez em todo o cluster. Ao ultrapassar esse limite, os jobs submetidos ficaram com o status PENDING e o motivo (REASON) AssociationJobLimit ou AssociationResourceLimit.
- OBS.2: As filas sequana_cpu e sequana_cpu_long permitem o uso compartilhado do nó de execução. O parâmetro --exclusive NÃO DEVE SER UTILIZADO. Quando o usuário não informar a quantidade de cores (parâmetros -n, --ntasks, --ntasks-per-node, --ntasks-per-socket, --tasks-per-node) desejados, o SLURM reservará um core por nó solicitado. Quando o usuário não especificar a quantidade de memória a ser utilizada (parâmetros --mem ou --mem-per-cpu), o SLURM reservará 8GB por core solicitado, não sendo elegíveis para iniciar a execução.
- OBS.3: As filas sequana_gpu* permitem o uso compartilhado do nó de execução. O parâmetro --exclusive NÃO DEVE SER UTILIZADO. Quando o usuário não informar a quantidade de cores (parâmetros -n, --ntasks, --ntasks-per-node, --ntasks-per-socket, --tasks-per-node) desejados, o SLURM reservará um core por nó solicitado. Quando o usuário não especificar a quantidade de memória a ser utilizada (parâmetros --mem ou --mem-per-cpu), o SLURM reservará 8GB por core solicitado. Mais informações sobre a submissão/utilização das filas GPU aqui.
- OBS.4: Com exceção das filas *dev, é obrigatório informar o tempo estimado de execução dos jobs. Essa configuração é feita através do parâmetro --time=HH:MM:SS. Caso o parâmetro --time não seja informado, ocorrerá o erro: error: Job submit/allocate failed: Requested time limit is invalid (missing or exceeds some limit)
- OBS.5: Os projetos dos programas de alocação Educacional e Embaixadores possuem limites e acessos reduzidos.
- Para verificar qual é o seu projeto e o tipo (programa de alocação) dele, executar o comando: sacctmgr list account $GROUPNAME format=account,descr -P
- Para consultar quais filas você possui acesso (e seus respectivos limites), basta executar o comando: sacctmgr list user $USER -s format=partition%20,MaxJobs,MaxSubmit,MaxNodes,MaxCPUs,MaxWall
O SLURM utiliza um mecanismo de "backfill" para realizar a alocação dos jobs e iniciar sua execução. Esse mecanismo leva em consideração o tempo de duração (WallCLock) de todos os jobs e, com base nisso, calcula o tempo esperado de quando um job iniciará (entrará em execução).
Normalmente, o SLURM vai reservando os recursos computacionais conforme os jobs são enfileirados, com base na prioridade destes. O mecanismo de backfill iniciará um job de menor prioridade se houver recurso coomputacional suficiente (que estava sendo "segurado") e se o seu tempo de duração não for atrapalhar o início de um job de maior prioridade. Mais informações sobre o mecanismo de backfill aqui e aqui.
Dessa forma, quanto menor for o tempo de duração (Wallclock) de um job, maior será a sua chance de entrar em execução. Porém, deve-se ter o cuidado para ajustar corretamente o tempo de duração do job de acordo com as necessidades. Caso seja ajustado (através do parâmetro --time) para um limte menor do que o necessário para a execução da aplicação, o job será cancelado por ultrapassar o limite definido, gerando a mensagem abaixo no arquivo de log do job:
*** JOB #ID ON sdumont1468 <b>CANCELLED</b> AT YYY-MM-DDTHH:MM:SS <b>DUE TO TIME LIMIT</b> ***
Por padrão, quando não especificado, o SLURM configura o WallCLock do job como a metade do limite da fila. Caso o limite seja definido (através do parâmetro --time) para um valor maior do que o permitido pela fila, o job ficará "preso", com status PENDING e com a REASON abaixo:
PartitionTimeLimit
Há alguns fatores que determinam o tempo de espera na fila e o início da execução dos jobs:
Os fatores de prioridade do SLURM são descritos aqui.
Resumindo, os principais fatores utilizados no SDumont para a composição da prioridade do job são:
Job_priority = Age + Fairshare + Partition + QOS
Cada um dos fatores acima possuem um peso que é multiplicado por um fator normalizado.
- Age: Representa o tempo que um job está aguardando na fila e elegível para execução. Esse valor vai aumentando a medida que um job fica pendente na fila.
- Fairshare: O componente de Fairshare para a prioridade de um job influencia a ordem em que os jobs na fila de um usuário são agendados para execução com base na parte dos recursos de computação que foram alocados e nos recursos que seus jobs já consumiram.
- Partition: Cada fila possui um valor de prioridade específico. Quanto maior o número, maior será a prioridade do job nessa fila.
- QOS: Cada QOS possui um valor de prioridade específico. Quanto maior o número, maior será a prioridade do job com essa QOS.
Para ter uma lista dos jobs em relação à prioridade (e seus fatores), é possível usar um dos comandos abaixo:
sprio -l" ou "sprio -l -p fila1,fila2
ou
squeue -O jobid,username:20,partition:20,PriorityLong" ou "squeue -O jobid,username:20,partition:20,PriorityLong -p fila1,fila2
Caso um projeto já tenham utilizado todas as UA's solicitadas, ele não é impedido de utilizar o SDumont, porém a prioridade de seus jobs é reduzida. Através do SLURM é possível saber se um projeto já consumiu todas as UA's utilizando um dos seguintes comandos:
- Listando a QOS associada às filas: sacctmgr list user $USER -s format=partition%20,qos
- Listando a QOS associada aos jobs em fila (pendentes ou em execução): squeue --me -O jobid,partition:20,qos
Cada fila possui uma prioridade específica, sendo que as de desenvolvimento (*_dev) possuem uma prioridade maior do que outras, já que são de curta duração e com o intuito de testar jobs pequenos.
Muitas das filas compartilham os nós de computação, o que aumenta o tempo de espera. Por exemplo, a fila sequana_cpu e sequana_cpu_long compartilham os mesmos nós. Dessa forma, alguns nós podem ficar alocados na fila sequana_cpu_long por até 30 dias, aumentando o tempo de espera na fila sequana_cpu. Importante ressaltar que quando um nó está alocado em uma fila, ele não fica disponível para as outras, mesmo que nele esteja sendo utilizado apenas 1 core.
Um fator importante e que influencia no aumento do tempo de espera na fila é o constante crescimento do número de usuários utilizando o SDumont.
O comando --mem-per-cpu exibe o tempo esperado de quando um job pendente (PENDING) entrará em execução (coluna START_TIME). A data prevista informada pelo parâmetro --start é constantemente alterada levando em conta os fatores mencionados acima. Dependendo dos recursos solicitados (tempo de execução, número de nós/cores), alguns jobs acabam aguardando na fila por um tempo maior que o previsto.