Partições e Limites de Recursos

O GridUnesp organiza os recursos computacionais em partições (filas) para gerenciar a execução dos jobs de forma eficiente e justa.

Conceitos Básicos

  • Partição: Conjunto de nós com características e políticas semelhantes

  • Limite de tempo: Tempo máximo que um job pode executar

  • Limite de recursos: Número máximo de núcleos, memória, GPUs por job

  • Política de prioridade: Regras que determinam a ordem de execução

Partições Disponíveis

Partições do GridUnesp

Partição

Nós

Tempo máximo

Uso recomendado

short

Todos os nós CPU

24 horas

Testes, jobs rápidos

medium

Todos os nós CPU

7 dias

Simulações de média duração

long

Todos os nós CPU

30 dias

Simulações longas

gpu

gpunode001

24 horas

Jobs que utilizam GPU

Nota

As partições short, medium e long são determinadas automaticamente pelo tempo solicitado. Não é necessário especificá-las explicitamente.

Consultando Partições

Comando sinfo

# Listar todas as partições
sinfo

# Formato detalhado
sinfo -o "%20P %5a %10l %6D %6t %N"

Exemplo de saída:

PARTITION            AVAIL TIMELIMIT  NODES  STATE  NODELIST
short*               up    1-00:00:00 56     mix    node[001-056]
medium               up    7-00:00:00 56     mix    node[001-056]
long                 up    30-00:00:0 56     mix    node[001-056]
gpu                  up    1-00:00:00 1      mix    gpunode001

Comando scontrol

# Detalhes de uma partição específica
scontrol show partition short

# Listar todos os nós
scontrol show nodes

Especificando Recursos no Script

Partição

# Para jobs GPU
#SBATCH --partition=gpu

Nota

Para as partições baseadas em tempo (short/medium/long), não é necessário especificar. O SLURM seleciona automaticamente baseado no valor de --time.

Tempo de Execução

# Formato: minutos
#SBATCH -t 30              # 30 minutos (partição short)

# Formato: horas:minutos:segundos
#SBATCH -t 12:00:00        # 12 horas (partição short)

# Formato: dias-horas
#SBATCH -t 2-12:00:00      # 2 dias e 12 horas (partição medium)
#SBATCH -t 7-00:00:00      # 7 dias (partição medium)
#SBATCH -t 30-00:00:00     # 30 dias (partição long)

Importante

  • Tempo até 24h → partição short

  • Tempo entre 24h e 7 dias → partição medium

  • Tempo entre 7 e 30 dias → partição long

  • Tempo > 30 dias → inválido (job não será aceito)

Nós e Processos

# Número de nós
#SBATCH --nodes=2

# Processos totais
#SBATCH --ntasks=52

# Processos por nó
#SBATCH --ntasks-per-node=28

# CPUs por processo (para threads)
#SBATCH --cpus-per-task=4

Memória

# Memória por nó
#SBATCH --mem=64G

# Memória por CPU
#SBATCH --mem-per-cpu=4G

Aviso

Não use --mem e --mem-per-cpu juntos. Escolha um.

GPUs

# Número de GPUs
#SBATCH --gres=gpu:1
#SBATCH --gres=gpu:2

# GPU específica (se houver mais de um tipo)
#SBATCH --gres=gpu:l40s:1

Exemplos Práticos

Exemplo 1: Job Serial

serial.sh
#!/bin/bash
#SBATCH -J serial
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --time=04:00:00
#SBATCH --mem=4G

export INPUT="entrada.dat"
export OUTPUT="saida.dat"

job-nanny ./meu_programa

Exemplo 2: Job Paralelo OpenMP

openmp.sh
#!/bin/bash
#SBATCH -J openmp
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=28
#SBATCH --time=12:00:00
#SBATCH --mem=64G

export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
export INPUT="dados.dat"
export OUTPUT="resultados/"

.job-nanny ./programa_omp

Exemplo 3: Job MPI

mpi.sh
#!/bin/bash
#SBATCH -J mpi
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=28
#SBATCH --time=48:00:00
#SBATCH --mem-per-cpu=2G

export INPUT="dados_mpi/"
export OUTPUT="resultados_mpi/"

module load openmpi/4.1.5
job-nanny mpirun -np 112 ./programa_mpi

Exemplo 4: Job GPU

gpu.sh
#!/bin/bash
#SBATCH -J gpu
#SBATCH --partition=gpu
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --gres=gpu:2
#SBATCH --cpus-per-task=16
#SBATCH --time=12:00:00
#SBATCH --mem=64G

export INPUT="dados_gpu/"
export OUTPUT="resultados_gpu/"

module load cuda/12.0
job-nanny ./programa_cuda

Exemplo 5: Job Array com Limite de Simultâneos

array.sh
#!/bin/bash
#SBATCH -J array
#SBATCH --array=1-1000%50
#SBATCH --ntasks=1
#SBATCH --time=01:00:00
#SBATCH --mem=2G

export INPUT="dados_${SLURM_ARRAY_TASK_ID}.dat"
export OUTPUT="resultado_${SLURM_ARRAY_TASK_ID}.dat"

job-nanny ./processa

Verificando Limites e Uso

Jobs em Execução

# Seus jobs
squeue -u $USER

# Todos os jobs
squeue

# Apenas jobs em execução
squeue -t RUNNING

# Apenas jobs pendentes
squeue -t PENDING

Recursos em Uso

# Resumo de uso do cluster
sinfo

# Uso detalhado por nó
sinfo -N -o "%16N %8c %8m %8d %6t"

# Nós disponíveis
sinfo -t idle

Por Que Meu Job Não Começa?

Razões comuns para jobs permanecerem em estado PENDING:

  1. Falta de recursos

    • Todos os nós estão ocupados

    • Solução: Aguarde ou solicite menos recursos

  2. Prioridade baixa

    • Segundo a Política de Prioridade, seu Fair Share está baixo

    • Solução: Reduza o uso ou aguarde o reset de prioridade

  3. Recursos solicitados inviáveis

    • Pediu mais que o disponível (ex: 100 nós)

    • Solução: Revise as requisições

  4. Tempo solicitado inválido

    • Mais de 30 dias

    • Solução: Reduza para ≤ 30 dias

Verificando a razão:

squeue -u $USER -o "%.18i %.9P %.8j %.8u %.2t %.10M %.6D %R"

A coluna %R mostra a razão (ex: “Resources”, “Priority”).

Otimizando o Uso de Recursos

  1. Peça apenas o necessário

    • Estime corretamente tempo e memória

    • Use sacct para ver o uso real após o job

  2. Jobs menores têm prioridade

    • Prefira vários jobs pequenos a um gigante

    • Use job arrays para HTC

  3. Evite picos de submissão

    • Espalhe a submissão ao longo do tempo

    • Use --array=1-1000%50 para limitar simultâneos

  4. Monitore seu Fair Share

    sshare -U $USER

Ver também