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

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 /scratch/OSG, 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.

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.

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.