06 ‐ Gerenciador de filas - lncc-sered/manual-sdumont2nd GitHub Wiki
Não é permitido a execução de aplicações nos nós de login (sdumont[4-7]). Os processos em execução contínua, nesses nós, possuem um tempo limite de 30 minutos.
O gerenciador de filas utilizado é o Slurm v24.05.3 (Customizado pela ATOS/EVIDEN). Todos os jobs devem ser submetidos através do Slurm.
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 limite de jobs em execução é feito através da quantidade total de recursos que um usuário pode ter em execução. O limite wallclock máximo dos jobs foi reduzido visando reduzir o tempo de espera em fila. Recomendamos que todos os usuários implementem mecanismos de checkpoint/restart em seus jobs para evitar a perda de dados caso o job seja finalizado antes do previsto.
Recomendamos também que as demandas de trabalho que exijam um tempo superior ao wallclock máximo da fila sejam organizadas em multiplos jobs com dependencia através do parâmetro --dependency do SLURM. Exemplo de submissão de jobs com dependência
Nós GPU H100 e GPU GH200
Total de recursos alocáveis: recursos relativos à 2 nós inteiros
Ex: um usuário pode, contanto que haja recursos disponíveis, ter até 8 jobs em execução (cada utilizando 1 GPU, que pode ser em 8 nós diferentes), 2 jobs (cada utilizando 4 GPUs) ou 1 job (utilizando as 8 gpus de dois nós). OBS: o mesmo é válido para a quantidade de CPUs (cores).
Nós MI300A
Total de recursos alocáveis: recursos relativos à 1 nó inteiro.
Ex: um usuário pode, contanto que haja recursos disponíveis, ter até 2 jobs em execução (cada utilizando 1 GPU, que pode ser em 2 nós diferentes), 1 job (utilizando as 2 gpus do nó). OBS: o mesmo é válido para a quantidade de CPUs (cores).
Nós ARM
Total de recursos alocáveis: 1 job e 1 nó.
Dessa forma, o limite máximo de jobs em execução fica restrito à quantidade de recursos que um usuário pode utilizar. Após alocar estes recursos (ter jobs em execução), os outros jobs submetidos, solicitando para utilizar recursos além do limite permitido, ficarão presos na fila com o motivo indicando QOS (QOSMaxCpuPerNode, QOSMaxGRESPerUser, etc).
Abaixo um cenário para exemplificar a alocação de recursos e as possibilidades existentes, usando cmo base a arquitetura H100.
Levando em consideração que é permitido o uso em execução de recursos equivalentes a 2 nós inteiros, no total, um usuário de um projeto premium (SINAPAD/LNCC) teria direito a utilizar, como limite global:
- 2 nós
- 8 gpus
- 192 cpus(cores)
- 2048GB mem
- 1 job usando 2 nós, executando na fila exclusiva e alocando todos os recursos.
- 1 job usando 1 nó, executando na fila exclusiva (utilizando 4 GPUs), e 2 jobs (podendo ser em 2 nós diferentes), executando na fila compartilhada - cada job utilizando 2 GPUs
- 4 jobs executando na fila compartilhada, sendo que cada um estaria utilizando 2 GPUs.
- 8 jobs executando na fila compartilhada, sendo que cada um estaria utilizando 1 GPU.
Não há restrições de alocação de recursos computacionais, apenas a restrição de número de jobs submetidos.
| Fila | Wall-clock máximo (HH:MM:SS)3 | Recursos em execução | Limite de Recursos por nó | Jobs Submetidos | Arquitetura |
|---|---|---|---|---|---|
| lncc-cpu_amd | 24:00:00 | N/D | N/D | 30 | CPU AMD Genoa-X 9684X |
| lncc-h1001 | 24:00:00 | Equivalente a 2 nós | Sem restrição | 30 | Intel Xeon SHR + Nvidia HGX H100 |
| lncc-h100_shared2 | 24:00:00 | Equivalente a 2 nós | Metade do nó | 30 | Intel Xeon SHR + Nvidia HGX H100 |
| lncc-gh2001 | 24:00:00 | Equivalente a 2 nós | Sem restrição | 30 | Nvidia SuperChip Grace-Hopper GH200 |
| lncc-gh200_shared2 | 24:00:00 | Equivalente a 2 nós | Metade do nó | 30 | Nvidia SuperChip Grace-Hopper GH200 |
| lncc-mi300a1 | 24:00:00 | Equivalente a 1 nós | Sem restrição | 30 | APU AMD MI300A |
| lncc-mi300a_shared2 | 24:00:00 | Equivalente a 1 nó | Metade do nó | 30 | APU AMD MI300A |
| lncc-grace | 24:00:00 | Equivalente a 1 nó | Sem restrição | 1 | ARM Nvidia Grace-Grace C2 Super-Chip |
O conjunto de hardware da fila lncc-cpu_amd está em validação, diante disso a fila está temporariamente desabilitada para os usuários.
É 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)
Filas que possuem alocação exclusiva dos recursos. Nessa fila, o job aloca o nó inteiro e não permite o compartilhamento. Devem ser utilizadas apenas para aplicações que conseguem tirar o máximo de desmpenho utilizando todos os recuros (GPUs) ou por jobs configurados para utilizar 4 execuções simultâneas dentro de um único script, conforme descrito aqui e aqui.
OBS: Essas filas não possuem o GRES configurado. Dessa forma, não devem utilizar os parâmetros --gpus, --gpus-per-node, --gpus-per-socket, --gpus-per-task.
Filas implementadas para permitir o compartilhamento dos recursos computacionais. É possível alocar um subconjunto dos recursos computacionais do nó (CPU, Memória e Aceleradores) e compartilhar o nó de processamento com jobs de outros usuários.
Para alocar uma ou mais GPUs, é obrigatório especificar a quantidade de aceleradores (parâmetros --gpus, --gpus-per-node, --gpus-per-socket, --gpus-per-task). Caso não seja informada a quantidade de GPU's, o job não entrará em execução e ficará pendente em fila com a REASON QOSMinGRES.
Essas filas são configuradas para permitir alocar, no máximo, a metade do recurso do nó por job. Nessas filas, não é permitido o uso do parâmetro --exclusive. Caso esse parâmetro seja utilizado ou tente alocar mais recursos que o permitido, o job ficará preso com o estado QOSMaxGRESPerUser.
Mais detalhes sobre a alocação de recursos compartilhados estão em Submeter Jobs.
Uma das fases de liberação do SDumont2nd foi o período chamado de "Early Access", onde alguns projetos selecioados pelo Comitê Gestor do SDumont utilizaram o ambiente em carater preliminar, analisando questões como desempenho e usabilidade.
O tempo máximo de execução (Wallclock) de 24 horas, adotado para fase operacional do SDumont levou em consideração as análises obtidas durante o "Early Access" e também foi baseada em levantamentos feitos junto a centros europeus de propósito e capacidade semelhante ao SDumont (em particular, no que concerne àqueles intensamente apoiados em GPUs).
Para balancear o tempo de 24 horas, mais curto em relação ao SDumont1, a quantidade de jobs que podem ser submetidos aumentou para 30. É fortemente recomendado o uso de checkpoint como forma de viabilizar simulações e treinamentos que necessitem de tempos de execução mais longos.
| Fila | Wall-clock máximo (DD-HH:MM:SS)1 | Recursos em execução | Jobs Submetidos | Arquitetura |
|---|---|---|---|---|
| cpu_amd | 5-00:00:00 | Equivalente a 10 nós | 100 | CPU AMD Genoa-X 9684X |
| ict-h100 | 24:00:00 | Equivalente a 2 nós | 200 | Intel Xeon SHR + Nvidia HGX H100 |
| ict-gh200 | 24:00:00 | Equivalente a 2 nós | 200 | Nvidia SuperChip Grace-Hopper GH200 |
| ict-mi300a | 24:00:00 | Equivalente a 1 nó | 200 | APU AMD MI300A |
| petrobr-h100 | 7-00:00:00 | Sem limite | 200 | Intel Xeon SHR + Nvidia HGX H100 |
| petrobr-gh200 | 7-00:00:00 | Sem limite | 200 | Nvidia SuperChip Grace-Hopper GH200 |
| petrobr-mi300a | 7-00:00:00 | Sem limite | 200 | APU AMD MI300A |
| lncc-grace | 24:00:00 | Equivalente a 1 nó | 200 | ARM Nvidia Grace-Grace C2 Super-Chip |
Os projetos PETROBRAS e Parceiros/ICTs utilizarão a mesma fila para a arquitetura CPU AMD GENOA (cpu_amd e cpu_amd_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)
É obrigatório informar o account (sigla do projeto) na hora da submissão dos jobs. Essa configuração é feita através do parâmetro --account=sigla-do-projeto. Caso o parâmetro --account não seja informado, ocorrerá o erro: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)
Para obter a lista de filas e projetos (accounts) que tem acesso:
sacctmgr list user $USER -s format=partition%20,account,MaxJobs,MaxSubmit,MaxWall
Todas as filas apresentadas acima permitem o compartilhamento dos recursos (nós) por dois ou mais jobs.
Para alocar uma ou mais GPUs, é obrigatório especificar a quantidade de aceleradores (parâmetros --gpus, --gpus-per-node, --gpus-per-socket, --gpus-per-task). Caso não seja informada a quantidade de GPU's, o job não entrará em execução e ficará pendente em fila com a REASON QOSMinGRES.
Mais detalhes sobre a alocação de recursos compartilhados estão em Submeter Jobs.
Uma das fases de liberação do SDumont2nd foi o período chamado de "Early Access", onde alguns projetos selecioados pelo Comitê Gestor do SDumont utilizaram o ambiente em carater preliminar, analisando questões como desempenho e usabilidade.
O tempo máximo de execução (Wallclock) de 24 horas, adotado para fase operacional do SDumont levou em consideração as análises obtidas durante o "Early Access" e também foi baseada em levantamentos feitos junto a centros europeus de propósito e capacidade semelhante ao SDumont (em particular, no que concerne àqueles intensamente apoiados em GPUs).
Para balancear o tempo de 24 horas, mais curto em relação ao SDumont1, a quantidade de jobs que podem ser submetidos aumentou para 30. É fortemente recomendado o uso de checkpoint como forma de viabilizar simulações e treinamentos que necessitem de tempos de execução mais longos.
| Fila | Wall-clock máximo (HH:MM:SS) | Jobs Submetidos | Projetos |
|---|---|---|---|
| cpu_amd_dev | 00:20:00 | 1 | PETROBRAS e Parceiros/ICTs |
| h100_dev | 00:20:00 | 1 | PETROBRAS e Parceiros/ICTs |
| gh200_dev | 00:20:00 | 1 | PETROBRAS e Parceiros/ICTs |
| mi300a_dev | 00:20:00 | 1 | PETROBRAS e Parceiros/ICTs |
| lncc-cpu_amd_dev | 00:20:00 | 1 | SINAPAD/LNCC |
| lncc-h100_dev | 00:20:00 | 1 | SINAPAD/LNCC |
| lncc-gh200_dev | 00:20:00 | 1 | SINAPAD/LNCC |
| lncc-mi300a_dev | 00:20:00 | 1 | SINAPAD/LNCC |
| grace_dev | 00:20:00 | 1 | Todos os tipos de projetos |
As filas de desenvolvimento e teste possuem 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.
Essas filas só permitem alocar, no máximo, a metade do recurso do nó por job. Nessas filas, não é permitido o uso do parâmetro --exclusive. Caso esse parâmetro seja utilizado ou tente alocar mais recursos que o permitido, o job ficará preso com o estado QOSMaxGRESPerUser.
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
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.
O comando squeue -O JobID,Partition,StartTime -t PD -u $USER exibe o tempo esperado de quando um job pendente (PD = PENDING) entrará em execução (coluna START_TIME). A data prevista informada é alterada levando em conta os fatores de prioridade que são constantemente recalculados. 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.