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.