Informa¸c˜
oes sobre filas de BATCH via PBS
nos servidores Linux 64 bits do CCIFUSP.
Philippe Gouffon, 29 de maio 1996
Adaptado por Jo˜ao Leonel, 14 de abril 2009
Revisado por Jo˜ao Leonel, 19 de outubro 2017
Introdu¸c˜
ao
Um sistema de filas de batch foi instalado no servidor central e em alguns servidores departamentais (fep, fap, fig, itec e fmt(romeo)). V´arias filas com carateristicas distintas, descritas abaixo, foram criadas. Com este sistema dispon´ıvel, o uso interativo de progra-mas em background acima de certo limite de tempo de cpu ser’ımpedido nos servidores departamentais. O uso de filas de batch permite que a m´aquina, com recursos limitados de mem´oria, possa ter um desempenho satisfat´orio tamb´em para o uso interativo.
Esta nota descreve brevemente o sistema PBS e as filas definidas no momento. Os parˆametros destas podem variar de acordo com a resposta do sistema e de seus usu´arios.
As filas
No servidor central foram criadas quatro classes de execu¸c˜ao, para arquitetura de processador amd64, cada uma alimentada pelas filas. Nos servidores departamentais, as classes A, B e C foram criadas e est˜ao dispon´ıveis. Jobs podem ser submetidos a partir dos servidores departamentais sem que haja necessidade de se logar no servidor central. As classes s˜ao
Classe Memoria Tempo de CPU Fila de Acesso distribuida A 3 GB 0h30 short B 6 GB 6h00 medium C 10 GB 72h00 long D 21 GB 120h00 huge
Para saber em que fila, em termos de mem´oria, o programa deve rodar, pode-se rod´a-lo interativamente e utilizar o comando ”top” para ver o quanto gasta de mem´oria (coluna SIZE).
As filas de acesso short, medium, long e huge existem nos servidores departamentais e podem ser utilizadas para rodar um job no servidor central ou em qualquer servidor departamental. O job ´e encaminhado ao servidor central que localiza um servidor com disponibilidade. Este servi¸co distribuido est´a sendo oferecido a t´ıtulo de experiˆencia gra¸cas `a boa vontade dos respons´aveis. Isto permite um uso melhor dos recursos e um tempo de resposta bem melhor em m´edia. Claro que este procedimento, vantajoso para todos, somente poder´a continuar se for usado de forma adequada, seguindo as regras abaixo descritas.
As filas que come¸cam com o prefixo i64 (i64short, i64medium, i64long, i64huge s˜ao filas para execut´aveis da arquitetura Intel-64bits. Todo job submetido a uma destas filas ser´a executado num processador de uma m´aquina rodando Sistema Operacional Linux-64 bits.
Os servidores possuem 2 compiladores fortran: gfortran e intel-fortran(ifort).
Documenta¸c˜
ao
A documenta¸c˜ao sobre PBS existe no estado de p´aginas de man, por exemplo, man qsub. Alguns comandos que atuam no PBS s˜ao
Comando fun¸c˜ao
qcat lista os arquivos de entrada e saida do job. qdel Apaga ou aborta job
qmgr Gerenciador de filas. Permite obter informa¸c˜oes sobre filas. qrls Libera um job que estava em estado de ”hold”
qstat Devolve o status dos jobs executando ou submetidos qsub Submete um job para fila.
Exemplo
O arquivo a ser submetido ao NQS ´e um shell script que pode ser interpretado por qualquer shell dispon´ıvel, como o sh, csh, tcsh, bash e perl. Na situa¸c˜ao mais simples, imagine um arquivo que contenha apenas os comandos que seriam executados interativa-mente.
O exemplo abaixo, um pouco complexo, mostra como compilar um programa Fortran cuja fonte est´a no pr´oprio job. Quando o arquivo fonte j´a existe em disco ele pode ser compilado diretamente sem toda esta gin´astica. Se o execut´avel j´a existe, melhor ainda pois ele pode ser executado diretamente.
O problema maior ´e a entrada de valores via ”terminal”. O mais simples ´e fazer um programa que leia dados de um arquivo com nome fixo ou que n˜ao leia valores. O exemplo mostra como passar valores que seriam lidos normalmente do terminal. Na primeira execu¸c˜ao, apenas um valor ´e passado e usa-se o comando echo para fazer isto. Na segunda, uma s´erie de valores s˜ao passados, que poderiam vir de um arquivo (seria um comando tipo cat arquivo | test.exe). No caso, os valores est˜ao no pr´oprio script, o que ´e o mais perto que se pode chegar de simular uma leitura do terminal. O arquivo abaixo ´e chamado de test.sh.
#!/bin/sh #
# Vai para o diretorio de trabalho. Por exemplo, servidor FEP #
cd /fep/home/$USER/jobs #
# Cria o arquivo test.f que contem o programa fonte a ser compilado
#
cat << /EOC > test.f c
c Programa que calcula o valor de PI por Monte Carlo c real*8 dentro,total,x,y integer iseed dentro = 0 total = 0 iseed=1234567 x=rand(iseed) 1 write(6,1000)
1000 format(/’ Numero de eventos: ’,$) read(5,1010,end=2,err=2) nev 1010 format(i10)
c
c loop de simulacao. Gera um par (x,y) e verifica se o ponto cai no c primeiro quadrante do circulo. Conta numero de sucessos.
c
iseed=0
do i=1,nev x=ran(iseed) y=ran(iseed)
if(x*x+y*y .le. 1.) then dentro = dentro +1.d0 endif
total=total+1.d0 enddo
c
c calcula valor de pi e imprime resultado. c
pi = 4.*dentro/total
write(6,2000) pi,nev
2000 format(/’ Pi vale ’,f7.5,’ com ’,i10,’ sorteios’) go to 1
2 stop end /EOC
#
# arquivo criado. Agora compila e linka, cria um executavel test.exe #
echo ">>>>>> compilando test.f" ifort -o test.exe test.f
#
# mostra que foi criado o executavel #
echo ">>>>>> compilado. directory do executavel" ls -l test.exe
#
# excuta programa com 1000000 eventos #
echo ">>>>>> executa programa na maquina" ‘hostname‘ echo 1000000 | test.exe
echo ">>>>>> terminado em" ‘date‘ #
# executa programa com 8 diferentes numeros de eventos #
cat << /EOC | test.exe 10 100 1000 10000 100000 1000000 10000000 100000000 /EOC
echo ">>>>>> terminado em" ‘date‘ #
# fim de job #
exit #EOF
Para excut´a-lo usamos o comando qsub, por exemplo:
>qsub -q i64short test.sh 532.mestre.if.usp.br
Pode-se acompanhar a evolu¸c˜ao do job com qstat:
>qstat -na
mestre.if.usp.br:
Req’d Req’d Elap Job ID Username Queue Jobname SessID NDS TSK Memory Time S Time --- --- - --- --- - - ---532.mestre.if.usp joaoleo i64short meu.sh 583 -- -- -- 00:30 R
--servo
O job n´umero 532, submetido por joaoleo, chegou ao gerente de filas mestre.if.usp.br (532.mestre) e est´a rodando na fila de execu¸c˜ao A (classe A) i64short no servidor servo.
Quando o job terminar, v˜ao aparecer dois arquivos no diret´orio de onde foi submetido o job, tendo como nome o nome do script com .onnn e .ennn onde nnn ´e o n´umero do job:
>ls -l test.sh*
-rw-r--r-- 1 ccifusp ccifusp 960 May 29 16:36 test.sh -rw-r--r-- 1 ccifusp ccifusp 34 May 29 16:43 test.sh.e532 -rw-r--r-- 1 ccifusp ccifusp 969 May 29 16:43 test.sh.o532
No caso, om arquivo test.sh.e532 cont´em as mensagens que iriam para o dispositivo de erro (stderr) e o arquivo test.sh.o532 tudo que iria para a tela (stdout). Para o exemplo em quest˜ao, os arquivos contem:
>cat test.sh.e532
stty: tcgetattr: Not a typewriter
um erro indicando que durante a inicializa¸c˜ao algum controle foi tentado sobre as carac-ter´ısticas do terminal. Isto pode ser ignorado. O outro arquivo, o que interessa, contem:
>cat test.sh.o532
Warning: no access to tty (Bad file number). Thus no job control in this shell.
>>>>>> compilando test.f
>>>>>> compilado. directory do executavel
-rwxr-xr-x 1 ccifusp ccifusp 32768 May 29 16:37 test.exe >>>>>> executa programa na maquina mestre.if.usp.br
Numero de eventos:
Pi vale 3.14258 com 1000000 sorteios
Numero de eventos: >>>>>> terminado em Wed May 29 16:37:46 EST 1996
Numero de eventos:
Pi vale 3.20000 com 10 sorteios
Numero de eventos:
Pi vale 3.20000 com 100 sorteios
Numero de eventos:
Pi vale 3.11712 com 1000 sorteios
Numero de eventos:
Pi vale 3.11575 com 10000 sorteios
Numero de eventos:
Pi vale 3.13603 com 100000 sorteios
Numero de eventos:
Pi vale 3.14268 com 1000000 sorteios
Numero de eventos:
Pi vale 3.14153 com 10000000 sorteios
Numero de eventos:
Pi vale 3.14139 com 100000000 sorteios
Numero de eventos: >>>>>> terminado em Wed May 29 16:43:29 EST 1996
Claro, o programa pode gerar arquivo em disco. Deve-se tomar um certo cuidado no caso de ambiente distribuido, para que o disco desejado seja acess´ıvel para escrita.
Problemas
Varios problemas podem acontecer neste sistema. Os mais comuns est˜ao relacionados a vari´aveis de ambiente e acesso a arquivos.
Quando o job ´e executado, um shell ´e aberto para o usu´ario que fez a submiss˜ao. Para que isto ocorra, o usu´ario deve estar autorizado a utilizar a fila e estar registrado na m´aquina onde o job ser´a executado. N˜ao precisa ter acesso interativo. O shell a ser executado ´e o que est´a definido no script (a linha #!/bin/sh do exemplo acima) ou na ausˆencia deste o que est´a definido como default para o usu´ario ou o que foi dado no comando qsub com a op¸c˜ao -s.
Este shell, por n˜ao ser interativo, n˜ao excuta os comandos que est˜ao no arquivo .login automaticamente (no caso de csh ou tcsh), o que pode levar a vari´aveis n˜ao definidas.
Como se trata de um novo processo, o job come¸ca na ´area definida como home do usu´ario, n˜ao no diret´orio de onde foi disparado. Caso o job tenha que ser executado l´a, o comando cd deve ser executado (no exemplo, h´a um cd job que leva ao diret´orio ~/job. Tudo como se estivesse trabalhando interativamente.
Finalmente, quando o job n˜ao pode ser executado por alguma raz˜ao grave, uma men-sagem ´e mandada para o usu´ario na m´aquina de origem, explicitando a causa.
Regras
Como qualquer sistema usado por v´arias pessoas, o bom senso deve prevalecer para evitar que outros sejam prejudicados. No caso do batch, uma das regras de conduta mais importante e mais violada ´e a de submeter dezenas ou centenas de jobs de uma vez na fila e ir embora. Como normalmente a ordem de execu¸c˜ao ´e a ordem de chegada, quem submeter um job depois vai ficar esperando todos os anteriores terminarem.Para evitar problemas, a tabela abaixo seta limites recomendados de submiss˜ao para as filas distribuidas. Qualquer abuso notado ou notificado ter´a como consequˆencia a imediata proibi¸c˜ao de uso das filas distribuidas.
Fila Condi¸c˜oes de submiss˜ao
i64short M´aximo de 5 jobs executando por usuario e 8 no total. i64medium Idem.
i64large Idem.
i64huge M´aximo de 3 jobs executando por usuario e 3 no total.
