Informações sobre filas de BATCH via PBS nos servidores Linux 64 bits do CCIFUSP.

Transcrição

1 Informações sobre filas de BATCH via PBS nos servidores Linux 64 bits do CCIFUSP. Introdução Philippe Gouffon, 29 de maio 1996 Adaptado por João Leonel, 14 de abril 2009 Revisado por João Leonel, 19 de outubro 2017 Um sistema de filas de bath foi instalado no servidor entral e em alguns servidores departamentais (fep, fap, fig, ite e fmt(romeo)). Várias filas om arateristias distintas, desritas abaixo, foram riadas. Com este sistema disponível, o uso interativo de programas em bakground aima de erto limite de tempo de pu ser ımpedido nos servidores departamentais. O uso de filas de bath permite que a máquina, om reursos limitados de memória, possa ter um desempenho satisfatório também para o uso interativo. Esta nota desreve brevemente o sistema PBS e as filas definidas no momento. Os parâmetros destas podem variar de aordo om a resposta do sistema e de seus usuários. As filas No servidor entral foram riadas quatro lasses de exeução, para arquitetura de proessador amd64, ada uma alimentada pelas filas. Nos servidores departamentais, as lasses A, B e C foram riadas e estão disponíveis. Jobs podem ser submetidos a partir dos servidores departamentais sem que haja neessidade de se logar no servidor entral. As lasses são Classe Memoria Tempo de CPU Fila de Aesso 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ória, o programa deve rodar, pode-se rodá-lo interativamente e utilizar o omando top para ver o quanto gasta de memória (oluna SIZE). As filas de aesso short, medium, long e huge existem nos servidores departamentais e podem ser utilizadas para rodar um job no servidor entral ou em qualquer servidor departamental. O job é enaminhado ao servidor entral que loaliza um servidor om disponibilidade. Este serviço distribuido está sendo ofereido a título de experiênia graças à boa vontade dos responsáveis. Isto permite um uso melhor dos reursos e um tempo de resposta bem melhor em média. Claro que este proedimento, vantajoso para todos, somente poderá ontinuar se for usado de forma adequada, seguindo as regras abaixo desritas. 1

2 As filas que omeçam om o prefixo i64 (i64short, i64medium, i64long, i64huge são filas para exeutáveis da arquitetura Intel-64bits. Todo job submetido a uma destas filas será exeutado num proessador de uma máquina rodando Sistema Operaional Linux-64 bits. Os servidores possuem 2 ompiladores fortran: gfortran e intel-fortran(ifort). Doumentação A doumentação sobre PBS existe no estado de páginas de man, por exemplo, man qsub. Alguns omandos que atuam no PBS são Exemplo Comando função qat lista os arquivos de entrada e saida do job. qdel Apaga ou aborta job qmgr Gereniador de filas. Permite obter informações sobre filas. qrls Libera um job que estava em estado de hold qstat Devolve o status dos jobs exeutando ou submetidos qsub Submete um job para fila. O arquivo a ser submetido ao NQS é um shell sript que pode ser interpretado por qualquer shell disponível, omo o sh, sh, tsh, bash e perl. Na situação mais simples, imagine um arquivo que ontenha apenas os omandos que seriam exeutados interativamente. O exemplo abaixo, um pouo omplexo, mostra omo ompilar um programa Fortran uja fonte está no próprio job. Quando o arquivo fonte já existe em diso ele pode ser ompilado diretamente sem toda esta ginástia. Se o exeutável já existe, melhor ainda pois ele pode ser exeutado diretamente. O problema maior é a entrada de valores via terminal. O mais simples é fazer um programa que leia dados de um arquivo om nome fixo ou que não leia valores. O exemplo mostra omo passar valores que seriam lidos normalmente do terminal. Na primeira exeução, apenas um valor é passado e usa-se o omando eho para fazer isto. Na segunda, uma série de valores são passados, que poderiam vir de um arquivo (seria um omando tipo at arquivo test.exe). No aso, os valores estão no próprio sript, o que é o mais perto que se pode hegar de simular uma leitura do terminal. O arquivo abaixo é hamado de test.sh.!/bin/sh Vai para o diretorio de trabalho. Por exemplo, servidor FEP d /fep/home/$user/jobs Cria o arquivo test.f que ontem o programa fonte a ser ompilado 2

3 at << /EOC > test.f Programa que alula o valor de PI por Monte Carlo real*8 dentro,total,x,y integer iseed dentro = 0 total = 0 iseed= x=rand(iseed) 1 write(6,1000) 1000 format(/,$) read(5,1010,end=2,err=2) nev 1010 format(i10) loop de simulaao. Gera um par (x,y) e verifia se o ponto ai no primeiro quadrante do irulo. Conta numero de suessos. 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 alula valor de pi e imprime resultado. pi = 4.*dentro/total write(6,2000) pi,nev 2000 format(/ Pi vale,f7.5, om,i10, sorteios ) go to 1 2 stop end /EOC arquivo riado. Agora ompila e linka, ria um exeutavel test.exe eho ">>>>>> ompilando test.f" ifort -o test.exe test.f 3

4 mostra que foi riado o exeutavel eho ">>>>>> ompilado. diretory do exeutavel" ls -l test.exe exuta programa om eventos eho ">>>>>> exeuta programa na maquina" hostname eho test.exe eho ">>>>>> terminado em" date exeuta programa om 8 diferentes numeros de eventos at << /EOC test.exe /EOC eho ">>>>>> terminado em" date fim de job exit EOF Para exutá-lo usamos o omando qsub, por exemplo: >qsub -q i64short test.sh 532.mestre.if.usp.br Pode-se aompanhar a evolução do job om qstat: >qstat -na mestre.if.usp.br: Req d Req d Elap Job ID Username Queue Jobname SessID NDS TSK Memory Time S Time mestre.if.usp joaoleo i64short meu.sh :30 R -- servo O job número 532, submetido por joaoleo, hegou ao gerente de filas mestre.if.usp.br (532.mestre) e está rodando na fila de exeução A (lasse A) i64short no servidor servo. 4

5 Quando o job terminar, vão apareer dois arquivos no diretório de onde foi submetido o job, tendo omo nome o nome do sript om.onnn e.ennn onde nnn é o número do job: >ls -l test.sh* -rw-r--r-- 1 ifusp ifusp -rw-r--r-- 1 ifusp ifusp -rw-r--r-- 1 ifusp ifusp 960 May 29 16:36 test.sh 34 May 29 16:43 test.sh.e May 29 16:43 test.sh.o532 No aso, om arquivo test.sh.e532 ontém 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ão, os arquivos ontem: >at test.sh.e532 stty: tgetattr: Not a typewriter um erro indiando que durante a iniialização algum ontrole foi tentado sobre as araterístias do terminal. Isto pode ser ignorado. O outro arquivo, o que interessa, ontem: >at test.sh.o532 Warning: no aess to tty (Bad file number). Thus no job ontrol in this shell. >>>>>> ompilando test.f >>>>>> ompilado. diretory do exeutavel -rwxr-xr-x 1 ifusp ifusp May 29 16:37 test.exe >>>>>> exeuta programa na maquina mestre.if.usp.br Pi vale om sorteios >>>>>> terminado em Wed May 29 16:37:46 EST 1996 Pi vale om Pi vale om Pi vale om Pi vale om Pi vale om Pi vale om 10 sorteios 100 sorteios 1000 sorteios sorteios sorteios sorteios 5

6 Pi vale om sorteios Pi vale om sorteios >>>>>> terminado em Wed May 29 16:43:29 EST 1996 Claro, o programa pode gerar arquivo em diso. Deve-se tomar um erto uidado no aso de ambiente distribuido, para que o diso desejado seja aessível para esrita. Problemas Varios problemas podem aonteer neste sistema. Os mais omuns estão relaionados a variáveis de ambiente e aesso a arquivos. Quando o job é exeutado, um shell é aberto para o usuário que fez a submissão. Para que isto oorra, o usuário deve estar autorizado a utilizar a fila e estar registrado na máquina onde o job será exeutado. Não preisa ter aesso interativo. O shell a ser exeutado é o que está definido no sript (a linha!/bin/sh do exemplo aima) ou na ausênia deste o que está definido omo default para o usuário ou o que foi dado no omando qsub om a opção -s. Este shell, por não ser interativo, não exuta os omandos que estão no arquivo.login automatiamente (no aso de sh ou tsh), o que pode levar a variáveis não definidas. Como se trata de um novo proesso, o job omeça na área definida omo home do usuário, não no diretório de onde foi disparado. Caso o job tenha que ser exeutado lá, o omando d deve ser exeutado (no exemplo, há um d job que leva ao diretório ~/job. Tudo omo se estivesse trabalhando interativamente. Finalmente, quando o job não pode ser exeutado por alguma razão grave, uma mensagem é mandada para o usuário na máquina de origem, expliitando a ausa. Regras Como qualquer sistema usado por várias pessoas, o bom senso deve prevaleer para evitar que outros sejam prejudiados. No aso do bath, uma das regras de onduta mais importante e mais violada é a de submeter dezenas ou entenas de jobs de uma vez na fila e ir embora. Como normalmente a ordem de exeução é a ordem de hegada, quem submeter um job depois vai fiar esperando todos os anteriores terminarem.para evitar problemas, a tabela abaixo seta limites reomendados de submissão para as filas distribuidas. Qualquer abuso notado ou notifiado terá omo onsequênia a imediata proibição de uso das filas distribuidas. 6

7 Fila Condições de submissão i64short Máximo de 5 jobs exeutando por usuario e 8 no total. i64medium Idem. i64large Idem. i64huge Máximo de 3 jobs exeutando por usuario e 3 no total. 7