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.

Topic revision: r4 - 2008-02-07 - MarcoAndreFerreiraDias
 

This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback

antalya escort bursa escort eskisehir escort istanbul escort izmir escort