Workers com Load alto
Description
Um caminho da investigacao seria, por exemplo, o seguinte:
1. Identificar nodes com load1 > numero de cores + 1, para dar uma margem de processamento do sistema.
2. Verificar com condor_q -run | grep node# quais sao os jobs que estao rodando nesse node e há quanto tempo estao rodando. Jobs com mais de um dia de processamento são suspeitos.
[root@spgrid ~]# . /OSG/setup.sh;
[root@spgrid ~]# condor_q -run | grep node80
342301.0 uscms01 12/5 17:29 1+18:44:29 vm3@node80.grid <--Repare que ele esta rodando a 1 dia, 18h44min e 29s, na vm3
344370.0 uscms01 12/6 12:01 1+00:11:50 vm1@node80.grid
345292.0 uscms01 12/6 19:19 0+16:53:49 vm2@node80.grid
345337.0 uscms01 12/6 21:14 0+14:58:41 vm4@node80.grid
3. Investigar o conteudo desses jobs com condor_q -l
e ver há quanto tempo seu output não é atualizado, e dar uma lida no output para ver se há algo estranho.
[root@spgrid ~]# condor_q -l 342301.0
Out = "/home/uscms01/.globus/job/spgrid.if.usp.br/25960.1196882934/stdout"
[root@spgrid ~]# ls -lu /home/uscms01/.globus/job/spgrid.if.usp.br/25960.1196882934/stdout <-hora do ultimo acesso
-rw------- 1 uscms01 uscms01 0 Dec 5 17:29 /home/uscms01/.globus/job/spgrid.if.usp.br/25960.1196882934/stdout
[mdias@spgrid ~]$ condor_q -l 388998.0|grep Iwd
Iwd = "/home/uscms01/gram_scratch_uYVrq8VwcU"
[mdias@spgrid ~]$ condor_q -run |grep 388998.0
388998.0 uscms01 1/30 16:46 5+23:27:37 vm1@node52.grid
4. Ir no node em questao e ver quantos jobs estao rodando com o ps faux, olhando quantas arvores de processos estao abertas. Verificar se existem processos associados a eles em estado "D" que ficam assim por varios minutos.
[root@spgrid ~]#ssh node80
[root@node80 ~]# ps -faux
condor 23477 0.0 0.0 9364 3512 ? Ss Dec05 2:06 | \_ condor_starter -f -a vm3 spg00.grid <---na vm3
uscms01 23553 0.0 0.0 2608 356 ? DN Dec05 0:00 | | | \_ /usr/bin/tee /tmp//BossTeePipe
5. Ir no node, identificar o diretorio onde esses jobs estao rodando, entrar nos diretorios e ver a evolucao desses jobs para ver se estao de fato parados, se a comunicacao com o servico esta caida, ou o que.
[root@node06:OSG]# tail -f /home/uscms01/.globus/job/spgrid.if.usp.br/25960.1196882934/stdstderr
/home/uscms01/.globus/.gass_cache/local/md5/46/78f139cfef6de1d2170f18b3699599/md5/69/c61230666e11a5c6d5bd045f5e09e3/data: line 228: /opt/edg/bin/edg-wl-logev: No such file or directory
usando a parte do Iwd, tem outro stdout e outro stderr. Nesses da para ver a data do ultimo output
[root@node52 mdias]# tail -f /home/uscms01/gram_scratch_uYVrq8VwcU/WMS_node52_03708_https_3a_2f_2frb124.cern.ch_3a9000_2fsB177yE0gIOb6CgsUc2zbg/CMSSW_000364.stdout
>>> info for dashboard:
***** Cat /raid0/gridhome/uscms01/gram_scratch_uYVrq8VwcU/WMS_node52_03708_https_3a_2f_2frb124.cern.ch_3a9000_2fsB177yE0gIOb6CgsUc2zbg/jobreport.txt *****
MonitorJobID=364_https://rb124.cern.ch:9000/sB177yE0gIOb6CgsUc2zbg
MonitorID=groselli_cls2_080130_113019
ExeStart=cmsRun
***** End Cat jobreport *****
Parameters sent to Dashboard.
MonitorJobID=364_https://rb124.cern.ch:9000/sB177yE0gIOb6CgsUc2zbg
MonitorID=groselli_cls2_080130_113019
>>> cmsRun started at Fri Feb 1 09:52:22 BRST 2008
6. Anotar o que esta causando a falha no job para ver se é um problema a ser resolvida no ambito da SPRACE ou se não pertence a nós. Tem que analisar qual a causa da parada, o que as vezes como nao tem output nao da para investigar.
7. Se for causado pela gente, inicia-se uma nova investigacao para ver como consertar isso.
8. Se não for problema nosso, anotar o que está acontecendo e escrever um email para a lista do uscms relatando o ocorrido e apresentar o problema na reunião do USCMS para que o submetidor do job possa saber que o job esta quebrando na farm e que alguma acao possa ser adotada.
9. Depois de identificar o que pode estar causando o problema, se for o caso cancelar o job removendo-o da fila do condor com condor_rm . O condor se encarrega de derrubar tudo. Os jobs entram eventualmente em estado "X" no condor, quando a comunicacao com o job esta irremediavelmente comprometida. Nesse caso ele tem que ser removido com a diretiva "-forcex".
É importante notar que apenas matar o job não ajuda, pois a partir do momento que ele esta cancelado perdemos as informacoes sobre ele, com grandes chances do problema voltar a se repetir.