h1. Submissão Tradicional
*Atualmente recomendamos a submissão via GO para todos os usuários, inclusive os que compilam a própria apliação: [[SubmissaoSimplificada]]*
{{>toc}}
h2. Compilar
Você pode compilar seu códigos nessa máquina. Estão disponíveis:
* GCC (C, C++ e Fortran)
* Intel (C, C++ e Fortran)
Também está disponível o Intel MPI para compilações de programas paralelos utilizando MPI. Para isso utilize mpicc e suas variantes (mpigcc, mpiicc, mpif90...)
*ATENÇÃO: NÃO EXECUTE AS SIMULAÇÕES NESSA MÁQUINA. NÃO RODE PROGRAMAS MPI NESSA MÁQUINA. APENAS COMPILE.*
Sempre que possível use compilação estática ou ainda use a ferramenta condor_compile.
h2. Submeter para o grid
Para submeter jobs para o grid será necessário criar um arquivo de submissão informando qual programa executar, quais arquivos copiar na entrada e saída...
Abaixo estão dois exemplos, um para programas simples e outro para programas MPI.
Em qualquer caso é necessário autenticar o seu certificado antes de iniciar a submissão:
myproxy-logon
a chave valid permite especificar a duração da proxy, é importante definir esta variável
por um tempo *superior a duas vezes a duração dos processos submetidos*.
O padrão desse comando (sem a chave -t) é 12 horas. Para requisitar 72 horas:
myproxy-logon -t 72
Para submeter:
condor_submit arquivo.submit
h3. Exemplo de arquivo de submissão para programas simples:
universe=grid
grid_resource=gt2 ce.grid.unesp.br/jobmanager-pbs
executable = executavel
arguments = argumentos
transfer_input_files = arquivo_de_entrada
transfer_output_files = arquivo_de_saida
WhenToTransferOutput = ON_EXIT
log = test.log
output = test.out
error = test.error
queue
h3. Exemplo de arquivo de submissão para programas MPI:
universe=grid
grid_resource=gt2 ce.grid.unesp.br/jobmanager-pbs
# 16 é o número de processos MPI
globusrsl = (host_xcount=16)(jobType=mpi)
executable = programa_mpi
arguments = argumentos
log = test.log
output = test.out
error = test.error
transfer_input_files = arquivo_de_entrada
transfer_output_files = arquivo_de_saida
WhenToTransferOutput = ON_EXIT
queue
h2. Verificar o status
Para verificar a fila de processos:
condor_q
Ou para listar apenas os seus processo:
condor_q username
h2. Cancelar job
Para remover um job, é necessário saber o seu número (verifique no item anterior):
condor_rm numero_do_processo
Para remover todos os seus processos:
condor_rm username
h1. Parâmetros para a submissão
Aqui estão descritos os parâmetros que devem ser especificados no arquivo de submissão dos jobs.
h2. Como utilizar
Adicionar o parâmetro "globusrsl" no arquivo de submissão.
Exemplo:
globusrsl = (queue=long)
Exemplo utilizando MPI com multiplas opções:
globusrsl = (host_xcount=20)(jobType=mpi)(queue=long)
h2. Opções
h3. Tempo de execução
A opção *queue* limita o tempo máximo de execução de um processo.
Caso não seja especificado, será adotado o tempo padrão (24 horas).
Escolhendo a categoria de menor duração garante um início mais rápido dos jobs.
* *short*: execução limitada a 24 horas
* *long*: execução limitada a 30 dias
* *medium*: execução limitada a 7 dias
globusrsl = (queue=long)
h3. Programas multi-thread (SMP)
Essa opção requisita mais de um core em um mesmo servidor.
Ideal para programas paralelizados com memória compartilhada (SMP).
globusrsl = (xcount=4)(jobType=single)
h3. MPI
Permite a execução de programas paralelos que sejam MPI.
globusrsl = (host_xcount=20)(jobType=mpi)
h3. Paralelo, não MPI
Essa opção só deve ser utilizada por usuários avançados. Ela permite a execução de programas paralelos que não sejam MPI.
Cabe ao usuário fornecer um script para configurar o ambiente paralelo.
globusrsl = (host_xcount=30)(jobType=single)
h1. Ajustes de performance
h2. Escrita de arquivos no /tmp
Por padrão, os jobs enviados são executados de um diretório compartilhado por NFS. Esse diretório tem uma performance menor que o disco local dos nós (/tmp).
Configure o seu programa para escrever os arquivos temporários (scratch) no /tmp. Essa medida simples pode melhorar a execução do seu programa em algumas vezes, dependendo do padrão de escrita.
Observe o exemplo abaixo, em que o mesmo job foi disparado duas vezes e medidos os respectivos tempos de execução. Na primeira execução o job foi configurado para escrever no diretório /tmp, enquanto que na segunda o job não foi modificado, sendo disparado através das configurações padrões.
carlosm@treinamento01:~/jobs/produtor_consumidor/pthread$ cat error.tmp
real 0m38.973s
user 0m22.610s
sys 2m1.604s
carlosm@treinamento01:~/jobs/produtor_consumidor/pthread$ cat error.sem_tmp
real 1m8.418s
user 0m22.579s
sys 2m21.039s
Repare que o ganho, em tempo de execução, do job configurado para escrever no diretório /tmp, sobre o job com as configurações padrão, foi de aproximadamente 50%.
Caso o seu programa não aceite como parâmetro um diretório de execução temporário, pode-se utilizar um script que mova os dados para o local correto e traga de volta.
Segue um exemplo:
script *wrapper.sh*
#!/bin/bash
OLD_PWD=`pwd`
TMP_DIR="/tmp/$USER-$$"
mkdir $TMP_DIR
cp * $TMP_DIR
cd $TMP_DIR
chmod +x $1
$*
rsync -r . $OLD_PWD/
cd $OLD_PWD
rm -rf $TMP_DIR
Trecho do arquivo de submissão
(..)
executable = wrapper.sh
arguments = ./programa arg1 arg2
transfer_input_files = programa, outros_arquivos_de_entrada
(...)
Lembre de apagar qualquer arquivo temporário no fim da execução.
h2. Submissão de múltiplos jobs
Quando submeter diversos jobs ou jobs com várias tarefas, inclua sempre no arquivo de submissão:
stream_output = False
stream_error = False
Isso evita sobrecarregar o cluster.
h1. Depuração
Antes de começar é importante ressaltar que o ambiente de grid adiciona uma camada de complexidade ao seu problema. Apenas submeta programas que tenham sido testados em um ambiente padrão de desenvolvimento.
A ferramenta Condor:http://www.cs.wisc.edu/condor/ é uma ferramenta poderosa que usa de forma oportunística recursos computacionais, da mesma forma que a ave sobrevoa os altiplanos andinos a procura de algum animal morto para se alimentar. Ela é versátil e pode ser utilizada em ambientes, heterogêneos, e sujeitos a falhas. Mas uma vez disparado um job, o usuário não tem controle sobre ele com exceção da possibilidade de interromper a execução.
Para iniciar o processo de depuração descubra o número do seu job:
condor_q username
-- Submitter: access.grid.unesp.br : <200.145.46.37:59072> : access.grid.unesp.br
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
14762.0 lemke 4/9 13:51 0+00:25:11 R 0 2.4 mdrun_mpi -v -s fu
14764.3 lemke 4/9 13:57 0+00:00:00 I 0 0.0 geraforcas -l 30 -
2 jobs; 1 idle, 1 running, 0 held
O número do job é o ID de seu job. Nesse caso o usuário lemke possui dois jobs 14762.0 e 14764.3.
Observe o status (ST) de seu job:
* R significa que o seu job está em execução (RUNNING)
* I significa que o seu job está Idle (em espera)
* H significa que seu job não foi executado até o final (HALTED)
Outra possibilidade é usar a chave -globus
condor_q -globus lemke
-- Submitter: access.grid.unesp.br : <200.145.46.37:59072> : access.grid.unesp.br
ID OWNER STATUS MANAGER HOST EXECUTABLE
12131.0 ipgtt STAGE_OUT condor ce.grid.unesp.br /opt/condor-7.2.4/
12145.0 ipgtt STAGE_OUT condor ce.grid.unesp.br /opt/condor-7.2.4/
12717.0 morgon UNKNOWN condor ce.grid.unesp.br /home/morgon/bin/R
12718.0 morgon UNKNOWN condor ce.grid.unesp.br /home/morgon/bin/R
12720.0 morgon UNKNOWN condor ce.grid.unesp.br /home/morgon/bin/R
13948.0 jdreis STAGE_OUT condor ce.grid.unesp.br /home/jdreis/sempi
14486.0 trtomei STAGE_OUT condor ce.grid.unesp.br /home/trtomei/CMSS
14772.0 fabiofima STAGE_OUT condor ce.grid.unesp.br /opt/gromacs/bin/m
14773.0 grilo ACTIVE condor ce.grid.unesp.br /home/grilo/teste/
14774.0 lemke UNSUBMITTED condor ce.grid.unesp.br /home/lemke/surf/.
14774.1 lemke PENDING condor ce.grid.unesp.br /home/lemke/surf/.
14774.2 lemke PENDING condor ce.grid.unesp.br /home/lemke/surf/.
14774.3 lemke PENDING condor ce.grid.unesp.br /home/lemke/surf/.
14774.4 lemke STAGE_IN condor ce.grid.unesp.br /home/lemke/surf/.
O comando mais importante para depurar um programa é
condor_q -l numjob
Este comando indica uma série de variáveis que podem ser úteis para checar se o job submetido é adequado. Em particular verifique:
* os arquivos de entrada estão corretos?
* os arquivos de saída estão corretos?
* o executável existe?
* os parâmetros estão corretos?
Para simplificar o processo é conveniente utilizar um script para submeter um job. Isto facilita o processo de depuração. No script de submissão você pode realizar testes preliminares, compilar o programa se este for o caso, ou ainda realizar varias etapas do seu processo computacional em um único job.
#!/bin/bash
./configura
echo configurou
condor_compile g++ -o prog prog.cc -lm
echo compilou
./prog
echo rodou
Neste exemplo executamos um script de configuração, compilamos nosso programa e executamos.
O condor_compile é uma boa alternativa para compilar programas pois garante que o seu job esteja adequado ao ambiente Grid. A sintaxe é simples: anteceda o comando de compilação com o condor_compile. Além disso compilar o programa na máquina em que o programa irá rodar aumenta sua portabilidade e facilita a depuração de erros como falta de bibliotecas.
Você pode escrever mensagens usando o comando echo, o que pode facilitar a depuração em muitos casos.
Para ler as messagens de erro e de saída do seu job, acesse os arquivos de erro, log e saída indicados em seu arquivo de submissão. Nos casos em que for solicitar ajuda para outros usuários ou para a equipe de suporte do NCC, inclua estes arquivos em seu e-mail.
O ambiente de grid está sujeito a problemas que ocorrem em estações de trabalho, como quedas de energia, máquinas com problema de hardware, etc. Em alguns casos esta pode ser a explicação para o problema observado com seu job.
Além disso a complexidade e os recursos utilizados por um job ou pelo usuário, podem também ser responsáveis por problemas de execução. Uso excessivo de disco e memória podem causar problemas. Algumas considerações sobre stes limites:
* um único usuário só pode rodar simultaneamente 100 jobs, mas pode submeter um número muito maior de jobs,
* jobs com mais de 2 Gb de memória podem ocasionar problemas de execução e
* jobs mpi que usem muitos slots podem demorar para iniciar sua execução.
Uma importante diferença entre o Condor:http://www.cs.wisc.edu/condor/ e o Condor-G:http://www.cs.wisc.edu/condor/condorg/ utilizado no NCC, é que no segundo ambiente os arquivos de saída devem ser explicitados no arquivo de submissão.
A principal saída de erro é:
HoldReason = "Globus error 155: the job manager could not stage out a file"
Ela ocorre sempre que o arquivo de saída não for gerado. Isto pode ocorrer por diversos motivos:
* seu executável não conseguiu iniciar (neste caso a execução durou muito pouco tempo)
* seu executável iniciou mas não concluiu (a execução custou algum) e o arquivo de saída não foi gerado
* o nome do arquivo de saída está errado
Um exemplo de script para testar estas possbilidades
#!/bin/bash
ls -l
# testa se os arquivos foram transferidos
./configura
date
echo configurou
condor_compile g++ -o prog prog.cc -lm
date
echo compilou
./prog
date
ls -l
echo rodou