SDumont - FAQ de Utilização


  1. Diretrizes do uso de senhas

  2. Shell do script de submissão

  3. Informações sobre acesso

  4. Transferencia de dados

  5. Erro de Alocação de memória - Jobs utilizando IntelMPI

  6. Executando múltiplas tarefas seriais em um único job

  7. Warning: MXM WARN The 'ulimit -s'

  8. Envio de e-mail através do SLURM

  9. Executando jobs com DOCKER

  10. SCRATCH de Parceiros e ICTs da Petrobras

  11. Informações sobre Software Proprietário


1. Diretrizes do uso de senhas

As senhas são informações pessoais e intransferíveis. Os usuários dos serviços do ambiente tecnológico do LNCC, incluindo o SDumont, devem definir suas senhas de acordo com a política de senhas do LNCC. Clique aqui para maiores informações sobre as políticas e procedimentos do LNCC.

1.1. Boas práticas para criação de senhas fortes

Recomenda-se utilizar:

  • Quantidade mínima de caracteres numéricos: 1

    • Serão considerados caracteres numéricos: 0123456789

  • Quantidade mínima de caracteres especiais: 1

    • Serão considerados caracteres especiais (incluindo o espaço): ! #$%&*)(_+=-}{^`'~][/;?:><.,|"

  • Quantidade mínima de caracteres alfabéticos maiúsculos: 1

    • Serão considerados caracteres alfabéticos maiúsculos: ABCDEFGHIJKLMNOPQSTUVXYWZ

  • Quantidade mínima de caracteres alfabéticos minúsculos: 1

    • Serão considerados caracteres alfabéticos minúsculos: abcdefghijklmnopqrstuvxywz

  • Números aleatórios;

  • Substituir letras por números ou caracteres especiais;

  • Criar uma frase que auxilie na memorização da senha (ex: “Utilizar uma frase para memorizar a senha é mais seguro” pode gerar a senha “u1FpMaSe+s”;

  • Criar padrões para formação da senha (#ftg9@AwS, #ftg9@GmAiL e etc.).

Evitar a utilização de:

  • Repetição de sequências de caracteres conhecidos ou sequências de teclas do teclado como: 123456, abcdef, asdfgh, qwerty e etc;

  • Uso de nomes, sobrenomes, nomes de membros da família e demais dados pessoais;

  • Uso de placas de carros;

  • Uso de palavras do dicionário;

  • Uso de nomes de times de futebol, filmes, músicas, personagens e etc.;

  • Repetição de senhas anteriores;

  • Anotar a senha em papel ou no próprio computador;

  • Uso da mesma senha em mais de uma conta.

1.2. Tamanho da senha para conta de usuário

O comprimento da senha deve ter um mínimo de 8 caracteres.

1.3. Validade da senha

As senhas devem ter um período de validade inferior a 06 (seis) meses.

1.4. Tentativas incorretas

A conta será bloqueada após 5 tentativas incorretas. As solicitações de desbloqueio deverão ser encaminhadas ao Helpdesk-SDumont, que seguirá o procedimento de validação das informações do usuário para efetuar o desbloqueio.

1.5. Redefinição de senhas

Dentro do período de validade da senha, o usuário pode alterá-la a qualquer momento. Para isso, basta utilizar o comando passwd diretamente no terminal do nó de login do SDumont, conforme descrito abaixo:


[meu.usuario@sdumontXX ~]$ passwd
Changing password for user meu.usuario.
(current) LDAP Password: #--- ATENÇÃO: DIGITAR A SENHA ATUAL
New password:            #--- ATENÇÃO: DIGITAR A SUA NOVA SENHA
Retype new password:     #--- ATENÇÃO: REDIGITAR A SUA NOVA SENHA
passwd: all authentication tokens updated successfully.

Caso o usuário tenha esquecido a senha, as solicitações de redefinição (reset) devem ser realizadas pelo próprio usuário através da intranet ou, quando esta não estiver disponível, através do Helpdesk-SDumont, que seguirá o procedimento de validação de informações do usuário para disponibilizar uma senha temporária.

O portal para redefinição de senha está disponível no endereço: https://novasenhasdumont.lncc.br.

Acesse a interface, informe seu login de acesso ao SDumont, resolva o captcha e clique no botão Enviar.

Os usuários devem alterar suas senhas imediatamente ao se conectarem no SDumont após uma redefinição de senha pela equipe do Helpdesk-SDumont.

*Lembre-se: No próximo acesso após a redefinição, caso tenha salvado a senha anterior no cliente VPN, será necessário ajustar essa configuração com a nova senha redefinida ao acessar o SDumont.

1.6. Adequação à política

Essas diretrizes então em acordo com a Política de Segurança do LNCC. Para maiores informações.

Topo


2. Shell do script de submissão (ksh)

Se for necessário utilizar o ksh como shell do script de submissão, é necessário incluir a linha abaixo no script de submissão antes de carregar os módulos:

. /opt/modules/default/Modules/init/ksh

Topo


3. Erro de segmentação - segmentation fault

Caso ocorra erro parecido com o descrito abaixo:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
APP.............. 0000000001409B95 Unknown Unknown Unknown
APP.............. 00000000014077B7 Unknown Unknown Unknown
APP.............. 00000000013B8E74 Unknown Unknown Unknown
APP.............. 00000000013B8C86 Unknown Unknown Unknown
APP.............. 0000000001357E76 Unknown Unknown Unknown
APP.............. 000000000135DF30 Unknown Unknown Unknown
....


Adicionar as linhas abaixo no script de submissão, antes de iniciar a execução da aplicação:

ulimit -c unlimited
ulimit -s unlimited

Topo


4. Transferencia de dados

O sistema de VPN não suporta grandes taxas de transmissão de dados, prejudicando a transferência.

Estamos projetando a implementação de um servidor dedicado para poder realizar o upload/download dos dados de forma mais prática e eficiente, porém ainda sem data para entrar em produção.

A solução adotada por enquanto é a de realizar a cópia dos dados a partir do nó de login do SDumont para algum host acessível através da Internet, utiliza comandos como o scp (enviar e receber dados) ou wget (receber dados). Dessa forma, a comunicação de saída não passa pela VPN, possibilitando alcançar melhores taxas de transferência.

Topo


5. Erro de Alocação de memória - Jobs utilizando IntelMPI

Caso ocorra erro parecido com o descrito abaixo:

DAPL ERR reg_mr Cannot allocate memory

Adicionar a linha abaixo no script de submissão, antes de iniciar a execução da aplicação:

export I_MPI_FABRICS=shm:ofa

Essa variável de ambiente configura a fabric a ser utilizada na comunicação dos processos MPI ao utilizar o Intel MPI. A primeira (shm) define a comunicação internamente no nó e a segunda (ofa) entre os nós.

Dessa forma a configuração para os requisitos de alocação de memória é realizada automaticamente.

Maiores informações: Selecting Fabrics | Intel® MPI Library for Linux

Topo


6. Executando múltiplas tarefas seriais em um único job

Há algumas formas de realizar essa tarefa. As mais simples estão listadas abaixo.

6.1. Executando N vezes o mesmo binário (serial), sem passar parâmetros

Essa é a forma mais simples. Se a aplicação não necessita utilizar parâmetros de entrada e é executada diretamente, é necessário apenas configurar o ambiente do SLURM corretamente.

O exemplo abaixo executará 48 vezes a mesma aplicação, sendo 24 em cada nó.

Script de submissão exemplo_1_simples.srm

#!/bin/bash
#SBATCH --nodes=2            #Numero de Nós
#SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó
#SBATCH --ntasks=48          #Numero total de tarefas MPI
#SBATCH -p cpu_small         #Fila (partition) a ser utilizada
#SBATCH -J exemplo_1         #Nome job
#SBATCH --exclusive          #Utilização exclusiva dos nós durante a execução do job

#Exibe os nós alocados para o Job
echo $SLURM_JOB_NODELIST
nodeset -e $SLURM_JOB_NODELIST

cd $SLURM_SUBMIT_DIR

#Configura o executavel
EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x

#exibe informações sobre o executável
/usr/bin/ldd $EXEC

srun --resv-ports  --nodes 1 --ntasks=24  $EXEC > $PWD/log1.txt &
srun --resv-ports  --nodes 1 --ntasks=24  $EXEC > $PWD/log2.txt &
wait

Quando o “srun” é executado utilizando um binário serial, ele disparará a execução do número de vezes que foi definido pelo “--ntasks”.

No exemplo acima, executará 24 vezes o benchmark cg do NPB em cada um dos nós nós.


6.2. Executando N vezes o mesmo binário (serial) através de um script, sem passar parâmetros

No exemplo anterior o job colocará a saída das execuções em um arquivo para cada execução do srun, agregando assim a saída de 24 execuções em um único arquivo de log, o que pode ficar confuso.

Uma forma de contornar isso é utilizar um script intermediário.

No exemplo abaixo, a linha do srun executará um script, que por sua vez executará as 24 instâncias da aplicação, direcionando a saída para arquivos diferentes.

Script de submissão exemplo_2_simples_com_script.srm

#!/bin/bash
#SBATCH --nodes=2            #Numero de Nós
#SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó
#SBATCH --ntasks=48          #Numero total de tarefas MPI
#SBATCH -p cpu_small         #Fila (partition) a ser utilizada
#SBATCH -J exemplo_2         #Nome job
#SBATCH --exclusive          #Utilização exclusiva dos nós durante a execução do job

#Exibe os nós alocados para o Job
echo $SLURM_JOB_NODELIST
nodeset -e $SLURM_JOB_NODELIST

cd $SLURM_SUBMIT_DIR

#Configura o script intermediario
SCRIPT=${PWD}/script_intermediario_2.sh

srun --resv-ports  --nodes 1 --ntasks=1 -c 24 $SCRIPT log_run_node1 &
srun --resv-ports  --nodes 1 --ntasks=1 -c 24 $SCRIPT log_run_node2 &
wait


script_intermediario_2.sh - *DEVE SER EXECUTÁVEL

#!/bin/bash

#Configura o executavel
EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x

#Configura a variavel do log - passada por parametro pela execucao do srun
RUN_LOG=${1}

#Exibe informações sobre o executável
/usr/bin/ldd $EXEC

#Inicia as execucoes
$EXEC > ${PWD}/${RUN_LOG}_1_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_2_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_3_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_4_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_5_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_6_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_7_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_8_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_9_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_10_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_11_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_12_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_13_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_14_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_15_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_16_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_17_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_18_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_19_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_20_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_21_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_22_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_23_log.txt &
$EXEC > ${PWD}/${RUN_LOG}_24_log.txt &
wait

6.3. Executando N vezes o mesmo binário (serial) através de um script, passando parâmetros

A utilização de parâmetros por parte do executável vai depender de cada caso. Se ele lê um arquivo de entrada, é possível criar um arquivo para cada execução independente.

Script de submissão exemplo_3_com_parametros_em_arquivo.srm

#!/bin/bash
#SBATCH --nodes=2            #Numero de Nós
#SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó
#SBATCH --ntasks=48          #Numero total de tarefas MPI
#SBATCH -p cpu_small         #Fila (partition) a ser utilizada
#SBATCH -J exemplo_3         #Nome job
#SBATCH --exclusive          #Utilização exclusiva dos nós durante a execução do job

#Exibe os nós alocados para o Job
echo $SLURM_JOB_NODELIST
nodeset -e $SLURM_JOB_NODELIST

cd $SLURM_SUBMIT_DIR

#Configura o script intermediario
SCRIPT=${PWD}/script_intermediario_3.sh

srun --resv-ports  --nodes 1 --ntasks=1 -c 24 $SCRIPT run_node1 &
srun --resv-ports  --nodes 1 --ntasks=1 -c 24 $SCRIPT run_node2 &
wait


script_intermediario_3.sh - *DEVE SER EXECUTÁVEL

#!/bin/bash

#Configura o executavel
EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x

#Configura a variavel da execucao - passada por parametro pela execucao do srun
RUN=${1}

#Exibe informações sobre o executável
/usr/bin/ldd $EXEC

#Inicia as execucoes
$EXEC -f ${PWD}/${RUN}_1_entrada > ${PWD}/${RUN}_1_log.txt &
$EXEC -f ${PWD}/${RUN}_2_entrada > ${PWD}/${RUN}_2_log.txt &
$EXEC -f ${PWD}/${RUN}_3_entrada > ${PWD}/${RUN}_3_log.txt &
$EXEC -f ${PWD}/${RUN}_4_entrada > ${PWD}/${RUN}_4_log.txt &
$EXEC -f ${PWD}/${RUN}_5_entrada > ${PWD}/${RUN}_5_log.txt &
$EXEC -f ${PWD}/${RUN}_6_entrada > ${PWD}/${RUN}_6_log.txt &
$EXEC -f ${PWD}/${RUN}_7_entrada > ${PWD}/${RUN}_7_log.txt &
$EXEC -f ${PWD}/${RUN}_8_entrada > ${PWD}/${RUN}_8_log.txt &
$EXEC -f ${PWD}/${RUN}_9_entrada > ${PWD}/${RUN}_9_log.txt &
$EXEC -f ${PWD}/${RUN}_10_entrada > ${PWD}/${RUN}_10_log.txt &
$EXEC -f ${PWD}/${RUN}_11_entrada > ${PWD}/${RUN}_10_log.txt &
$EXEC -f ${PWD}/${RUN}_12_entrada > ${PWD}/${RUN}_11_log.txt &
$EXEC -f ${PWD}/${RUN}_13_entrada > ${PWD}/${RUN}_12_log.txt &
$EXEC -f ${PWD}/${RUN}_14_entrada > ${PWD}/${RUN}_13_log.txt &
$EXEC -f ${PWD}/${RUN}_15_entrada > ${PWD}/${RUN}_14_log.txt &
$EXEC -f ${PWD}/${RUN}_16_entrada > ${PWD}/${RUN}_15_log.txt &
$EXEC -f ${PWD}/${RUN}_17_entrada > ${PWD}/${RUN}_16_log.txt &
$EXEC -f ${PWD}/${RUN}_18_entrada > ${PWD}/${RUN}_17_log.txt &
$EXEC -f ${PWD}/${RUN}_19_entrada > ${PWD}/${RUN}_18_log.txt &
$EXEC -f ${PWD}/${RUN}_20_entrada > ${PWD}/${RUN}_19_log.txt &
$EXEC -f ${PWD}/${RUN}_21_entrada > ${PWD}/${RUN}_20_log.txt &
$EXEC -f ${PWD}/${RUN}_22_entrada > ${PWD}/${RUN}_21_log.txt &
$EXEC -f ${PWD}/${RUN}_23_entrada > ${PWD}/${RUN}_22_log.txt &
$EXEC -f ${PWD}/${RUN}_24_entrada > ${PWD}/${RUN}_23_log.txt &

wait


* Importante observar que nesse caso é necessário gerar previamente um arquivo de entrada diferente para cada execução.


6.3.1. Passando parâmetros diretamente

É possível também passar diferentes parâmetros diretamente para o script.

Script de submissão exemplo_3.1_com_parametros_direto.srm

#!/bin/bash
#SBATCH --nodes=2            #Numero de Nós
#SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó
#SBATCH --ntasks=48          #Numero total de tarefas MPI
#SBATCH -p cpu_small         #Fila (partition) a ser utilizada
#SBATCH -J exemplo_3.1       #Nome job
#SBATCH --exclusive          #Utilização exclusiva dos nós durante a execução do job

#Exibe os nós alocados para o Job
echo $SLURM_JOB_NODELIST
nodeset -e $SLURM_JOB_NODELIST

cd $SLURM_SUBMIT_DIR

#Configura o script intermediario
SCRIPT=${PWD}/script_intermediario_3.1.sh

srun --resv-ports  --nodes 1 --ntasks=1 -c 24 $SCRIPT parametro_1 parametro_2 parametro_3 parametro_4 parametro_5 parametro_6 parametro_7 parametro_8 parametro_9 parametro_10 parametro_11parametro_12 parametro_13 parametro_14 parametro_15 parametro_16 parametro_17 parametro_18 parametro_19 parametro_20 parametro_21 parametro_22 parametro_23 parametro_24 &
srun --resv-ports  --nodes 1 --ntasks=1 -c 24 $SCRIPT parametro_25 parametro_26 parametro_27 parametro_28 parametro_29 parametro_30 parametro_31 parametro_32 parametro_33 parametro_34 parametro_35 parametro_36 parametro_37 parametro_38 parametro_39 parametro_40 parametro_41 parametro_42 parametro_43 parametro_44 parametro_45 parametro_46 parametro_47 parametro_48 &
wait


script_intermediario_3.1.sh - *DEVE SER EXECUTÁVEL

#!/bin/bash

#Configura o executavel
EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x

#Exibe informações sobre o executável
/usr/bin/ldd $EXEC

#Inicia as execucoes
$EXEC ${1} &
$EXEC ${2} &
$EXEC ${3} &
$EXEC ${4} &
$EXEC ${5} &
$EXEC ${6} &
$EXEC ${7} &
$EXEC ${8} &
$EXEC ${9} &
$EXEC ${10} &
$EXEC ${11} &
$EXEC ${12} &
$EXEC ${13} &
$EXEC ${14} &
$EXEC ${15} &
$EXEC ${16} &
$EXEC ${17} &
$EXEC ${18} &
$EXEC ${19} &
$EXEC ${20} &
$EXEC ${21} &
$EXEC ${22} &
$EXEC ${23} &
$EXEC ${24} &

wait


* Nesse caso, a linha do srun passará 24 parâmetros diferentes para o script intermediário.
* O script intermediário pega os 24 diferentes parâmetros de entrada e os distribui para as 24 execuções.


6.4. Executando N vezes o mesmo binário (serial) através de um script completo

Uma outra forma seria criar diferentes scripts intermediários completos, cada um contando todos os parâmetros necessários, sem a necessidade de passar valores do script de submissão.

Script de submissão exemplo_4_com_scripts_completos.srm

#!/bin/bash
#SBATCH --nodes=2            #Numero de Nós
#SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó
#SBATCH --ntasks=48          #Numero total de tarefas MPI
#SBATCH -p cpu_small         #Fila (partition) a ser utilizada
#SBATCH -J exemplo_4         #Nome job
#SBATCH --exclusive          #Utilização exclusiva dos nós durante a execução do job

#Exibe os nós alocados para o Job
echo $SLURM_JOB_NODELIST
nodeset -e $SLURM_JOB_NODELIST

cd $SLURM_SUBMIT_DIR

srun --resv-ports  --nodes 1 --ntasks=1 -c 24 ${PWD}/script_intermediario_4_completo.1.sh  &
srun --resv-ports  --nodes 1 --ntasks=1 -c 24 ${PWD}/script_intermediario_4_completo.2.sh  &
wait


script_intermediario_4_completo.1.sh - *DEVE SER EXECUTÁVEL

#!/bin/bash

#Configura o executavel
EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x

#Exibe informações sobre o executável
/usr/bin/ldd $EXEC

#Inicia as execucoes
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
$EXEC parametro_1 parametro_2 .... parametro_N &
wait


script_intermediario_4_completo.2.sh - *DEVE SER EXECUTÁVEL

#!/bin/bash

#Configura o executavel
EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x

#Exibe informações sobre o executável
/usr/bin/ldd $EXEC

#Inicia as execucoes
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &
$EXEC parametro_A parametro_B .... parametro_XZY &

wait


* Nesse caso é necessário um script específico para cada linha do srun.
* Esse script intermediário deverá conter todos os parâmetros necessários para a execução da aplicação, representados por “parametro_X.Y

Topo


7. Warning: MXM WARN The 'ulimit -s'

Ao submeter um job utilizando o OpenMPI 2.0, algumas aplicações apresentam o seguinte aviso no arquivo de log:

mxm.c:196 MXM WARN The 'ulimit -s' on the system is set to 'unlimited'. This may have negative performance implications. Please set the stack size to the default value (10240)

Esse é um problema recorrente e até o momento não apresentou problemas de desempenho nos benchmarks realizados.

Topo


8. Envio de e-mail através do SLURM

É possível configurar o job para enviar uma notificação através do e-mail. Para utilizar essa funcionalidade, é necessário configurar as linhas abaixo no script de submissão:

#SBATCH --mail-type=TIPO
#SBATCH --mail-user=DESTINO

Onde TIPO é um dos possíveis valores:

  • NONE: Não envia notificação por e-mail.
  • BEGIN: Envia uma notificação por e-mail quando o job inicia.
  • END: Envia uma notificação por e-mail quando o job finaliza.
  • FAIL: Envia uma notificação por e-mail quando o job falha.
  • REQUEUE: Envia uma notificação por e-mail quando o job é reenfileirado.
  • ALL: Equivalente a BEGIN, END, FAIL e REQUEUE
  • TIME_LIMIT: Envia uma notificação por e-mail quando o job atinge seu limite de tempo.
  • TIME_LIMIT_90: Envia uma notificação por e-mail quando o job atinge 90% do seu limite de tempo.
  • TIME_LIMIT_80: Envia uma notificação por e-mail quando o job atinge 80% do seu limite de tempo.
  • TIME_LIMIT_50: Envia uma notificação por e-mail quando o job atinge 50% do seu limite de tempo.
  • ARRAY_TASKS: Envia uma notificação por e-mail para cada tarefa do JOB ARRAY.

DESTINO é o endereço de e-mail que receberá as notificações.
Múltiplos TIPOS podem ser especificados através de uma lista separada por vírgula.

Múltiplos DESTINOS também podem ser especificados através de uma lista separada por vírgula.

*ATENÇÃO: Ao configurar o envio de e-mail, verifique a caixa de Spam da sua conta se a notificação enviada pelo SLURM foi taxada como tal. Alguns servidores de E-Mail podem não identifcar a noticação como um e-mail válido.

Topo


9. Executando jobs com DOCKER

O docker está instalado no SDumont. Antes de utilizá-lo, é necessário verificar se o usuário está inserido no grupo do docker, utilizando o comando id:

$ id
uid=6XXXX(username) gid=61YYYY(projeto) grupos=61YYYY(projeto),50000(docker)

Caso grupo 50000(docker) não aparece na saída do comando id, entre em contato com o Helpdesk-SDumont e solicite a inclusão do usuário no Grupo.

Se o usuário já tiver acesso ao grupo do docker: para garantir que o docker seja executado com o grupo correto, é necessário executar o comando de submissão através do comando 'sg grupo -c "comando de submissão"', conforme o exemplo abaixo:

sg docker -c "srun -N 1 -n 1 -p cpu_dev docker run hello-world"
ou
sg docker -c "sbatch script.srm"

Para Jobs Interativos (salloc) - Exemmplo 2, ao acessar diretamente o nó de execução, não é necessário utilizar o comando sg para executar o docker.

Topo


10. SCRATCH de Parceiros e ICTs da Petrobras

O Path para o diretório de SCRATCH de Parceiros e ICTs da Petrobras sempre será /scratch/parceirosbr.

De acordo com o projeto que estiver trabalhado você deverá utilizar o subdiretório correspondente.

Se você participar de apenas um projeto de parceiros e ICTs poderá customizar sua variável SCRATCH nos arquivos de configuração da sua conta (~/.bashrc por exemplo).

Devido as particularidades da infraestrutura dos parceiros e ICTs da Petrobras, não é possível definir a variável $SCRATCH da mesma forma que é feito para os usuários do LNCC.

Topo


11. Informações sobre Software Proprietário

11.1 O SDumont possui licenças de softwares proprietários disponíveis?

Não. O SDumont não possui licença para softwares proprietários. Sendo assim, esse softwares devem ser adquiridos pelo usuário.

11.2 Os nós de processamento conseguem alcançar servidores de licenças externos?

Sim. Todos os nós tem acesso a internet.

11.3 Quem pode realizar a instalação do software?

Os usuários podem realizar a instalação de softwares em sua área de dados. Os softwares que serão utilizados nos nós de processamento devem ser instalados em um subdiretório do /scratch/projeto.
A equipe de suporte do SDumont também pode realizar a instalação dos softwares, mediante abertura de chamado.