* 4432: utiliza nodos 46 y 47 y se ejecuta en /home/pzaninelli/workdir/SENSHeatWave03/sims/control50k
* 4432: utiliza nodos 46 y 47 y se ejecuta en /home/pzaninelli/workdir/SENSHeatWave03/sims/control50k
Línea 420:
Línea 420:
# Los pasos a seguir para cada nodo son los siguientes. Se tiene que entrar en todos los nodos, puesto que no hay otra manera de conocer los procesos que se ejectuan en ellos
# Los pasos a seguir para cada nodo son los siguientes. Se tiene que entrar en todos los nodos, puesto que no hay otra manera de conocer los procesos que se ejectuan en ellos
## Entrar en el nodo
## Entrar en el nodo
<PRE>
<pre>
$ ssh [nombreNodo]
$ ssh [nombreNodo]
</PRE>
</pre>
## Chequear los procesos
## Chequear los procesos
### Si no se sabe el nombre de la aplicación que podría estar zombie
### Si no se sabe el nombre de la aplicación que podría estar zombie
<PRE>
<pre>
ps -ef | grep $USER
ps -ef | grep $USER
</PRE>
</pre>
### Si se sabe el nombre de la aplicación (en el caso de ejemplo el modelo <code>WRF</Code>)
### Si se sabe el nombre de la aplicación (en el caso de ejemplo el modelo <code>WRF</Code>)
<PRE>
<pre>
ps -ef | grep [aplicación]
ps -ef | grep [aplicación]
</PRE>
</pre>
### Parar esos procesos que no correspondan (huérfanos de job PBS)
### Parar esos procesos que no correspondan (huérfanos de job PBS)
<PRE>
<pre>
kill -9 [procesoID]
kill -9 [procesoID]
</PRE>
</pre>
### Salir del nodo y empezar con el siguiente
### Salir del nodo y empezar con el siguiente
<PRE>
<pre>
exit
exit
</PRE>
</pre>
# Después de mirar en los nodos del 40 al 46, entrando en el nodo 47
# Después de mirar en los nodos del 40 al 46, entrando en el nodo 47
# Si hay algún proceso 'zombie' tendrá un tiempo de ejecución muy largo. Se observa que hay dos grupos distintos de procesos: <code>3-00:53:43 ./wrf.exe</code> (3 días y 53 minutos) y <code>1-04:50:56 ./wrf.exe</code> (1 días 4 horas y 50 minutos)
# Si hay algún proceso 'zombie' tendrá un tiempo de ejecución muy largo. Se observa que hay dos grupos distintos de procesos: <code>3-00:53:43 ./wrf.exe</code> (3 días y 53 minutos) y <code>1-04:50:56 ./wrf.exe</code> (1 días 4 horas y 50 minutos)
# Analizar donde está ejecutándose cada proceso
# Analizar donde está ejecutándose cada proceso
Revisión del 18:53 11 abr 2018
Un proceso zombie se entiende cómo ese proceso que fue lanzado dentro de la cola PBS de gestión de trabajos, que ocupa espacio en el sistema del clúster, pero que actualmente no está en curso.
Esta situación suele ocurrir cuando el clúster se apaga de una manera no controloda, el espacio en el 'home' del clúster se llena.
Es importante que se paren estos procesos, puesto que suponen un sobre esfuerzo para los nodos en los cuáles estos procesos zombies están ejecutándose.
NOTA: este es el único caso en el cuál está permitido entrar en los nodos de cálculo del clúster.
Pasos a seguir
Itendificar los procesos de la cola del sistema del usuario (ej. lluis.fita)
$ qstat
Job id Name User Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
4426.hydra wrf_control lluis.fita 1699:08: R larga
4427.hydra ...nsSFC-control lluis.fita 0 H larga
4432.hydra wrf_control50k pzaninelli 649:09:3 R larga
4433.hydra run_experiment pzaninelli 0 H larga
4438.hydra wrf_phy1 pzaninelli 645:40:5 R larga
4439.hydra run_experiment pzaninelli 0 H larga
4440.hydra WRF17O victoria.gallig 603:42:2 R larga
4441.hydra WRF17O victoria.gallig 600:18:4 R larga
4443.hydra WRF17O lluis.fita 0 Q larga
La variable PBS_O_WORKDIR contiene el path de ejecución del job. Se tiene que cercionar que el proceso (simulación WRF en este caso), está ejecutándose (en este caso si los rsl.out/error.[nnnn] se están actualizando). En este caso la ejecución del WRF se halla en $PBS_O_WORKDIR/run
$ ls -l /home/lluis.fita/estudios/WRFsensSFC/simulations/control/run/rsl.error.0000
rw-r--r-- 1 lluis.fita cima 1204224 Apr 8 19:07 /home/lluis.fita/estudios/WRFsensSFC/simulations/control/run/rsl.error.0000
$ date
Tue Apr 10 11:32:35 ART 2018
Está claro que el WRF no está ejecutándose adecuadamente. Así que se tendrá que entrar en el nodo en dónde se está ejecutando y parar el job, ya que el sistema de colas PBS no controla este proceso. El WRF se ejecuta en el nodo (valores de exec_host) node48 y node51.
Se repite el procedimiento en tantos nodos cómo ocupe el job (en este caso también node51)
[lluis.fita@hydra ~]$ ssh node51
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ killall wrf.exe
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ exit
El job re-aparece cómo cancelled (letra C)
[lluis.fita@hydra ~]$ qstat
Job id Name User Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
4426.hydra wrf_control lluis.fita 1703:44: C larga
4427.hydra ...nsSFC-control lluis.fita 0 R larga
4432.hydra wrf_control50k pzaninelli 654:14:4 R larga
4433.hydra run_experiment pzaninelli 0 H larga
4438.hydra wrf_phy1 pzaninelli 650:46:2 R larga
4439.hydra run_experiment pzaninelli 0 H larga
4440.hydra WRF17O victoria.gallig 608:46:5 R larga
4441.hydra WRF17O victoria.gallig 605:22:5 R larga
4443.hydra WRF17O lluis.fita 0 R larga
Si el job no fuera cancelado, se hace encesaria la cancelación manual
$ qdel 4426
Otros jobs que estabn en la cola PBS, ahora ya se están ejecutándose al liberarse los nodos! Se observa en el [ganglia] del sistema cómo los nodos 48 y 51, se descargan de carga de cálculo
Ejemplo de descarga de los nodos 48 y 51 después de matar un proceso 'zombie'
Un proceso zombie se entiende cómo ese proceso que fue lanzado dentro de la cola PBS de gestión de trabajos, que ocupa espacio en el sistema del clúster, pero que actualmente no está en curso.
Esta situación suele ocurrir cuando el clúster se apaga de una manera no controloda, el espacio en el 'home' del clúster se llena.
Es importante que se paren estos procesos, puesto que suponen un sobre esfuerzo para los nodos en los cuáles estos procesos zombies están ejecutándose.
NOTA: este es el único caso en el cuál está permitido entrar en los nodos de cálculo del clúster.
Pasos a seguir
Itendificar los procesos de la cola del sistema del usuario (ej. lluis.fita)
$ qstat
Job id Name User Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
4426.hydra wrf_control lluis.fita 1699:08: R larga
4427.hydra ...nsSFC-control lluis.fita 0 H larga
4432.hydra wrf_control50k pzaninelli 649:09:3 R larga
4433.hydra run_experiment pzaninelli 0 H larga
4438.hydra wrf_phy1 pzaninelli 645:40:5 R larga
4439.hydra run_experiment pzaninelli 0 H larga
4440.hydra WRF17O victoria.gallig 603:42:2 R larga
4441.hydra WRF17O victoria.gallig 600:18:4 R larga
4443.hydra WRF17O lluis.fita 0 Q larga
La variable PBS_O_WORKDIR contiene el path de ejecución del job. Se tiene que cercionar que el proceso (simulación WRF en este caso), está ejecutándose (en este caso si los rsl.out/error.[nnnn] se están actualizando). En este caso la ejecución del WRF se halla en $PBS_O_WORKDIR/run
$ ls -l /home/lluis.fita/estudios/WRFsensSFC/simulations/control/run/rsl.error.0000
rw-r--r-- 1 lluis.fita cima 1204224 Apr 8 19:07 /home/lluis.fita/estudios/WRFsensSFC/simulations/control/run/rsl.error.0000
$ date
Tue Apr 10 11:32:35 ART 2018
Está claro que el WRF no está ejecutándose adecuadamente. Así que se tendrá que entrar en el nodo en dónde se está ejecutando y parar el job, ya que el sistema de colas PBS no controla este proceso. El WRF se ejecuta en el nodo (valores de exec_host) node48 y node51.
Se repite el procedimiento en tantos nodos cómo ocupe el job (en este caso también node51)
[lluis.fita@hydra ~]$ ssh node51
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ killall wrf.exe
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ exit
El job re-aparece cómo cancelled (letra C)
[lluis.fita@hydra ~]$ qstat
Job id Name User Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
4426.hydra wrf_control lluis.fita 1703:44: C larga
4427.hydra ...nsSFC-control lluis.fita 0 R larga
4432.hydra wrf_control50k pzaninelli 654:14:4 R larga
4433.hydra run_experiment pzaninelli 0 H larga
4438.hydra wrf_phy1 pzaninelli 650:46:2 R larga
4439.hydra run_experiment pzaninelli 0 H larga
4440.hydra WRF17O victoria.gallig 608:46:5 R larga
4441.hydra WRF17O victoria.gallig 605:22:5 R larga
4443.hydra WRF17O lluis.fita 0 R larga
Si el job no fuera cancelado, se hace encesaria la cancelación manual
$ qdel 4426
Otros jobs que estabn en la cola PBS, ahora ya se están ejecutándose al liberarse los nodos! Se observa en el [ganglia] del sistema cómo los nodos 48 y 51, se descargan de carga de cálculo
Ejemplo de descarga de los nodos 48 y 51 después de matar un proceso 'zombie'
procesos sin PBS: Pasos a seguir II
Puede darse el caso, que el proceso esté ocupando el nodo y no se muestre cómo trabajo de la cola. En este caso el nodo estará ejecutando un proceso, pero para el sistema de colas PBS, no estaría ocupando recursos con lo que el nodo estaría sobre trabjando.
En este caso, al consultar el Ganglia del clúster, se ve que el nodo está en rojo y que está todo gris (en el ejemplo de Ganglia anterior los nodos 47,50 y 53). Para estar seguros será necesario entrar en todos los nodos del clúster uno a uno y asegurarse que no tenga ningún proceso sin job dependiente.
Ejemplo con el usuario pzaninelli
Mirar procesos corriendo
[pzaninelli@hydra ~]$ qstat
Job id Name User Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
4432.hydra wrf_control50k pzaninelli 1248:26: R larga
4433.hydra run_experiment pzaninelli 0 H larga
4438.hydra wrf_phy1 pzaninelli 1244:57: R larga
4439.hydra run_experiment pzaninelli 0 H larga
4440.hydra WRF17O victoria.gallig 1201:37: R larga
4441.hydra WRF17O victoria.gallig 1197:29: R larga
4445.hydra wrf_control lluis.fita 593:41:0 R larga
4446.hydra ...nsSFC-control lluis.fita 0 H larga
Determinar nodos y ruta de ejecución de todos los jobs del usuari.x.
4432: utiliza nodos 46 y 47 y se ejecuta en /home/pzaninelli/workdir/SENSHeatWave03/sims/control50k
4438: utiliza nodos 49 y 50 y se ejecuta en /home/pzaninelli/workdir/SENSHeatWave03/sims/phy1
Los pasos a seguir para cada nodo son los siguientes. Se tiene que entrar en todos los nodos, puesto que no hay otra manera de conocer los procesos que se ejectuan en ellos
Entrar en el nodo
$ ssh [nombreNodo]
Chequear los procesos
Si no se sabe el nombre de la aplicación que podría estar zombie
ps -ef | grep $USER
Si se sabe el nombre de la aplicación (en el caso de ejemplo el modelo WRF)
ps -ef | grep [aplicación]
Parar esos procesos que no correspondan (huérfanos de job PBS)
kill -9 [procesoID]
Salir del nodo y empezar con el siguiente
exit
Después de mirar en los nodos del 40 al 46, entrando en el nodo 47
Si hay algún proceso 'zombie' tendrá un tiempo de ejecución muy largo. Se observa que hay dos grupos distintos de procesos: 3-00:53:43 ./wrf.exe (3 días y 53 minutos) y 1-04:50:56 ./wrf.exe (1 días 4 horas y 50 minutos)
Del análisi anterior el nodo 47 sólo hospeda el job PBS 4432 que se ejecuta en /home/pzaninelli/workdir/SENSHeatWave03/sims/control50k. Así que los procesos del grupo (Ids de 17995 a 18015) que se ejecutan en /home/pzaninelli/workdir/SENSHeatWave03/sims/phy1/run son zombies. Así que ya se pueden eliminar
[pzaninelli@node47 ~]$ kill -9 $(seq 17995 18015)
Ahora al buscar los procesos aprecen sólo los procesos dependiendo del job PBS
