Melhorando o Script de Submissão

Esta seção detalha a construção de scripts de submissão robustos e eficientes, incorporando as melhores práticas e todos os recursos disponíveis no GridUnesp.

Opções do SBATCH

O SLURM oferece dezenas de diretivas para controlar a execução dos jobs. Abaixo as mais importantes:

Principais diretivas SBATCH

Diretiva

Abrev.

Descrição

--time

-t

Tempo máximo de execução (formato: min, min:seg, horas:min:seg, dias-horas, dias-horas:min:seg)

--cpus-per-task

-c

Número de CPUs por processo (para threads/OpenMP)

--ntasks

-n

Número total de processos (para MPI)

--nodes

-N

Número mínimo de nós

--mem

Memória por nó (ex: 16G, 32768M)

--mem-per-cpu

Memória por CPU (ex: 4G)

--output

-o

Arquivo para saída padrão (stdout)

--error

-e

Arquivo para saída de erros (stderr)

--job-name

-J

Nome do job (aparece no squeue)

--partition

-p

Partição (short, medium, long, gpu)

--gres

Recursos genéricos, como GPUs (--gres=gpu:1)

--mail-type

Quando enviar e-mail (BEGIN, END, FAIL, ALL)

--mail-user

Endereço de e-mail para notificações

Exemplos:

#SBATCH -t 24:00:00 -c 4
#SBATCH --mem=16G
#SBATCH --output=job_%j.out
#SBATCH --mail-type=END,FAIL
#SBATCH --mail-user=joao@unesp.br

Dica

Use %j no nome do arquivo para incluir o Job ID automaticamente.

Script job-nanny

O job-nanny é um script essencial do GridUnesp que gerencia a transferência de dados entre o /home/ e as áreas de trabalho temporárias.

Por que usar job-nanny?

  1. Evita sobrecarga no /home/ - Acesso direto ao /home/ durante a execução degrada o desempenho

  2. Otimiza performance - Usa discos locais (/tmp/ ou /store/) que são muito mais rápidos

  3. Garante persistência - Copia resultados de volta ao final

  4. Checkpoints automáticos - Salva progresso periodicamente

Aviso

O script job-nanny é reconhecido ao carregar o módulo gridunesp.

Quando o usuário faz login no cluster, esse módulo é carregado automaticamente.

Caso tenha usado o comando module purge, é preciso fazer

module load gridunesp

para que o job-nanny esteja disponível.

Variáveis Obrigatórias

O job-nanny exige a definição de duas variáveis:

export INPUT="arquivo1.dat arquivo2.dat diretorio_entrada/"
export OUTPUT="resultado.dat saida/"

  • INPUT: Arquivos/diretórios que serão copiados para a área de trabalho temporária

  • OUTPUT: Arquivos/diretórios que serão copiados de volta ao /home/ ao final

Variáveis Opcionais

Variáveis do job-nanny

Variável

Padrão

Descrição

CHECKPOINT

$OUTPUT

Local para salvar checkpoints

WAIT_CHECKPOINT

10800 (3h)

Intervalo entre checkpoints (segundos)

VERBOSE

0

Ativa modo verboso (1) para debug

SHARED_FS

“false”

Se “false”, usa /tmp/; se “true”, força uso do /store/

LARGE_FILES

“false”

Se “true”, força uso do /store/ (para arquivos grandes)

Exemplos de Uso do job-nanny

Exemplo 1: Job serial simples

job_simples.sh
#!/bin/bash
#SBATCH -J teste
#SBATCH -n 1
#SBATCH -t 01:00:00

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

module load python/3.9
job-nanny python script.py entrada.dat > resultado.dat

Exemplo 2: Job com múltiplos arquivos

job_multiplo.sh
#!/bin/bash
#SBATCH -J simulacao
#SBATCH -c 4
#SBATCH -t 24:00:00

export INPUT="parametros.in dados/ biblioteca.so"
export OUTPUT="saida.dat logs/"

module load gcc/10.2.0
job-nanny ./programa -i parametros.in -o saida.dat

Exemplo 3: Job com arquivos grandes

job_grande.sh
#!/bin/bash
#SBATCH -J big_data
#SBATCH -n 1
#SBATCH -t 12:00:00

export INPUT="dataset_grande.bin"
export OUTPUT="resultados/"
export LARGE_FILES="true"      # Força uso do /store/

job-nanny ./processador dataset_grande.bin

Exemplo 4: Job com checkpoints frequentes

job_longo.sh
#!/bin/bash
#SBATCH -J long_job
#SBATCH -n 8
#SBATCH -t 20-00:00:00          # 20 dias

export INPUT="entrada.dat"
export OUTPUT="resultado_final.dat"
export CHECKPOINT="checkpoints/"
export WAIT_CHECKPOINT=3600      # Checkpoint a cada 1 hora

module load meu_software
job-nanny simular --restart checkpoints/

Escolha Entre /tmp/ e /store/

O job-nanny decide automaticamente onde executar:

Usa /tmp/ (rápido, local) quando:

  • Job usa apenas 1 nó (-N 1)

  • SHARED_FS não está definido ou é "false"

  • LARGE_FILES não está definido ou é "false"

Usa /store/ (compartilhado) quando:

  • Job usa múltiplos nós (-N > 1)

  • SHARED_FS="true"

  • LARGE_FILES="true"

Dica

Para jobs de 1 nó com arquivos muito grandes (>100 GB), use LARGE_FILES="true" para forçar o uso do /store/, que tem mais espaço disponível do que o /tmp/ do nó de processamento.

Sistema de Filas (Detalhado)

O tempo especificado determina automaticamente a partição:

Relação tempo x partição

Tempo solicitado

Partição

Prazo máximo de processamento

Até 24 horas

short

24 horas

Até 24 horas (especificando -p gpu)

gpu

24 horas (executado no servidor de GPU)

Entre 24h e 7 dias

medium

7 dias

Entre 7 e 30 dias

long

30 dias

Acima de 30 dias

(inválido)

Job não será aceito

Importante

Sempre especifique o tempo mais preciso possível. Jobs com tempo menor:

  • Têm prioridade maior na fila

  • Podem “encaixar” em janelas de recursos ociosos

  • Aumentam a eficiência do cluster para todos

Exemplos de Configuração de Tempo:

# 30 minutos
#SBATCH -t 30:00

# 12 horas e 30 minutos
#SBATCH -t 12:30:00

# 2 dias e 6 horas
#SBATCH -t 2-06:00:00

# 30 dias (máximo permitido)
#SBATCH -t 30-00:00:00

Informações sobre o Storage (Detalhado)

O GridUnesp possui três áreas principais de armazenamento, cada uma com características específicas:

Comparação das partições

Partição

Capacidade

Velocidade

Persistência

Uso recomendado

/home/

120 TB

Média

Permanente

Scripts, código, dados pequenos

/tmp/

~180 GB/nó

Muito rápida

Temporária (apenas durante o job)

I/O intensivo, arquivos temporários

/store/

7 TB

Média-baixa

Temporária

Arquivos grandes, dados compartilhados

Partição /tmp/

O /tmp/ é um diretório local em cada nó de processamento. Suas principais características:

  • Velocidade: Altíssima (disco local SSD/HD)

  • Espaço: Limitado (~180 GB por nó)

  • Escopo: Visível apenas no nó onde o job está executando

  • Persistência: TEMPORÁRIA - arquivos são removidos ao final do job

Quando usar /tmp/:

  • Jobs que fazem muita leitura/escrita em disco

  • Dados temporários que podem ser recriados

  • Processamento que cabe no espaço disponível

  • Jobs de um único nó (padrão)

Exemplo de uso explícito do /tmp/ (já é o padrão):

#!/bin/bash
#SBATCH -J tmp_job
#SBATCH -N 1
#SBATCH -n 28
#SBATCH -t 24:00:00

export INPUT="dados_entrada/"
export OUTPUT="resultados/"

# job-nanny usará /tmp/ automaticamente (1 nó, sem flags)
job-nanny ./programa

Partição /store/

O /store/ é um sistema de arquivos compartilhado entre todos os nós:

  • Velocidade: Média

  • Espaço: Grande (7 TB)

  • Escopo: Visível em todos os nós

  • Persistência: TEMPORÁRIA (dados apagados após o término do job)

Quando usar /store/:

  • Jobs com múltiplos nós (MPI)

  • Arquivos de entrada/saída muito grandes (>100 GB)

  • Dados que precisam ser acessados por vários nós simultaneamente

Exemplo de job multi-nó (usa /store/ automaticamente):

#!/bin/bash
#SBATCH -J mpi_job
#SBATCH -N 4
#SBATCH -n 112
#SBATCH -t 72:00:00

export INPUT="dados_grandes/"
export OUTPUT="resultados_mpi/"

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

Exemplo forçando uso do /store/ em job de 1 nó:

#!/bin/bash
#SBATCH -J big_job
#SBATCH -N 1
#SBATCH -n 28
#SBATCH -t 48:00:00

export INPUT="dataset_500GB/"
export OUTPUT="resultados/"
export LARGE_FILES="true"      # Força uso do /store/

job-nanny ./processador

Considerações Importantes

  1. Nunca processe jobs diretamente no servidor access

  2. Sempre defina INPUT e OUTPUT ao usar job-nanny

  3. Estime corretamente o tempo necessário (jobs mais curtos têm prioridade)

  4. Monitore seus jobs com squeue e scontrol

  5. Limpe arquivos temporários após a conclusão

Ver também