Suporte (GridUNESP)

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:

<pre>
myproxy-logon
</pre>

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:

<pre>
myproxy-logon -t 72
</pre>

Para submeter:
<pre>
condor_submit arquivo.submit
</pre>

h3. Exemplo de arquivo de submissão para programas simples:

<pre>
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

</pre>

h3. Exemplo de arquivo de submissão para programas MPI:

<pre>
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

</pre>

h2. Verificar o status

Para verificar a fila de processos:

<pre>
condor_q
</pre>

Ou para listar apenas os seus processo:

<pre>
condor_q username
</pre>

h2. Cancelar job

Para remover um job, é necessário saber o seu número (verifique no item anterior):

<pre>
condor_rm numero_do_processo
</pre>

Para remover todos os seus processos:

<pre>
condor_rm username
</pre>

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:
<pre>
globusrsl = (queue=long)
</pre>

Exemplo utilizando MPI com multiplas opções:
<pre>
globusrsl = (host_xcount=20)(jobType=mpi)(queue=long)
</pre>

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 3 horas
* *long*: execução limitada a 30 dias sem limite de tempo
* _outro ou nenhum valor_: execução limitada a 24 horas

<pre>
globusrsl = (queue=long)
</pre>

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).

<pre>
globusrsl = (xcount=4)(jobType=single)
</pre>

h3. MPI

Permite a execução de programas paralelos que sejam MPI.

<pre>
globusrsl = (host_xcount=20)(jobType=mpi)
</pre>

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.

<pre>
globusrsl = (host_xcount=30)(jobType=single)
</pre>

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.

<pre>
carlosm@treinamento01:~/jobs/produtor_consumidor/pthread$ cat error.tmp

real 0m38.973s
user 0m22.610s
sys 2m1.604s
</pre>

<pre>
carlosm@treinamento01:~/jobs/produtor_consumidor/pthread$ cat error.sem_tmp

real 1m8.418s
user 0m22.579s
sys 2m21.039s
</pre>

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*
<pre>
#!/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
</pre>

Trecho do arquivo de submissão
<pre>
(..)

executable = wrapper.sh
arguments = ./programa arg1 arg2

transfer_input_files = programa, outros_arquivos_de_entrada

(...)
</pre>

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:

<pre>
stream_output = False
stream_error = False
</pre>

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:

<pre>
condor_q username
</pre>

<pre>
-- 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

</pre>
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

<pre>

condor_q -globus lemke
</pre>

<pre>
-- 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/.
</pre>

O comando mais importante para depurar um programa é

<pre>
condor_q -l numjob
</pre>

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.

<pre>
#!/bin/bash
./configura
echo configurou
condor_compile g++ -o prog prog.cc -lm
echo compilou
./prog
echo rodou
</pre>

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 é:
<pre>
HoldReason = "Globus error 155: the job manager could not stage out a file"
</pre>

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
<pre>
#!/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
</pre>