Wikicima - Contribuciones del usuario [es]

WRF4L

2019-03-13T18:12:51Z

Pzaninelli:

There is a far more powerful tool to manage work-flow of [http://www.meteo.unican.es/software/wrf4g/ WRF4G].

Lluís developed a less powerful one which is here described

WRF work-flow management is done via 5 scripts (these are the specifics for hydra [CIMA cluster]):
* <code>EXPERIMENTparameters.txt</code>: General ASCII file which configures the experiment and chain of simulations (chunks). This is the unique file to modify
* <code>run_experiment.pbs</code>: PBS-queue job which prepares the experiment of the environment
* <code>run_WPS.pbs</code>: PBS-queue job which launch the WPS section of the model: <code>ungrib.exe</code>, <code>metgrid.exe</code>, <code>real.exe</code>
* <code>run_WRF.pbs</code>: PBS-queue job which launch the <code>wrf.exe</code>
* <code>launch_pbs.bash</code>: Necessary shell script to launch jobs which use more than one node in CIMA's <code>hydra</code> cluster
* There is a folder called <code>components</code> with shell and python scripts necessary for the work-flow management

An experiment which contains a period of simulation is divided by '''chunks''' small pieces of times which are manageable by the model. The work-flow follows these steps using <code>run_experiments.pbs</code>:
# Copy and link all the required files for a given '''chunk''' of the whole period of simulation following the content of <code>EXPERIMENTparameters.txt</code>
# Launches <code>run_WPS.pbs</code> which will produce the necessary files for the period of the given '''chunk'''
# Launches <code>run_WRF.pbs</code> which will simulated the period of the given '''chunk''' (which waits until the end of <code>run_WPS.pbs</code>)
# Launches the next <code>run_experiments.pbs</code> (which waits until the end of <code>run_WRF.pbs</code>)

All the scripts are located in <code>hydra</code> at:
<pre>
/share/tools/work-flows/WRF4L/hydra
</pre>

== How to simulate ==
# Creation of a new folder from where launch the experiment [ExperimentName] (g.e. somewhere at $HOME)
<pre>
$ mkdir [ExperimentName]
cd [ExperimentName]
</pre>
# copy the WRF4L files to this folder
<pre>
$ cp /share/tools/work-flows/WRF4L/hydra/EXPERIMENTparameters.txt ./
$ cp /share/tools/work-flows/WRF4L/hydra/run_experiment.pbs ./
$ cp /share/tools/work-flows/WRF4L/hydra/run_WPS.pbs ./
$ cp /share/tools/work-flows/WRF4L/hydra/run_WRF.pbs ./
$ cp /share/WRF/launch_pbs.bash ./
</pre>
# Edit the configuration/set-up of the simulation of the experiment
<pre>
$ vim EXPERIMENTparameters.txt
</pre>
# Launch the simulation of the experiment
<pre>
$ qsub run_experiment.pbs
</pre>
When it is running one would have (runnig ORCHIDEE job <code>or_[SimName]</code> `R', and <code>exp_[SimName]</code> in hold `H'):
<pre>
$ qstat -u $USER

hydra:
Req'd Req'd Elap
Job ID Username Queue Jobname SessID NDS TSK Memory Time S Time
-------------------- -------- -------- ---------------- ------ ----- --- ------ ----- - -----
397.hydra lluis.fi larga wps_ 27567 1 16 20gb 168:0 R --
398.hydra lluis.fi larga wrf_ -- 1 1 20gb 168:0 H --
399.hydra lluis.fi larga exp_ -- 1 1 2gb 168:0 H --
</pre>

In case of crash of the simulation, after fixing the issue, go to <code>[runHOME]/[ExpName]/[SimName]</code> and re-launch the experiment (after the first run the <code>scratch</code> is switched automatically to `false')
<pre>
$ qsub run_experiment.pbs
</pre>

== Checking the experiment ==
Once the experiment runs, one needs to look on (following name of the variables from <code>EXPERIMENTparameters.txt</code>
* <code>[runHOME]/[ExpName]/[SimName]</code>: Will content the copies of the templates <code>namelist.wps</code>, <code>namelist.input</code> and a file <code>chunk_attemps.inf</code> which counts how many times a '''chunk''' has been attempted to be run (if it reached 4 times, the <code>WRF4L</code> is stopped)
* <code>[runHOME]/[ExpName]/[SimName]/run</code>: actual folder where the computing nodes run the model. In a folder called <code>wrfout</code> there is a folder for each '''chunk''' with the standard output of the model
* <code>[runHOME]/[ExpName]/[SimName]/run/wrfout/[YYYYi][MMi][DDi][HHi][MIi][SSi]-[YYYYf][MMf][DDf][HHf][MIf][SSf]</code>: folder with the standard output and all the required files to run a given '''chunk'''. The content of all this folder is compressed and kept in <code>[storageHOME]/[ExpName]/[SimName]/config_[YYYYi][MMi][DDi][HHi][MIi][SSi]-[YYYYf][MMf][DDf][HHf][MIf][SSf].tar.gz</code>
* <code>[storageHOME]/[ExpName]/[SimName]</code> (in [storageHOST]): output of the already ran '''chunks''' as <code>[YYYYi][MMi][DDi][HHi][MIi][SSi]-[YYYYf][MMf][DDf][HHf][MIf][SSf]</code> for a chunk from <code>[YYYYi]/[MMi]/[DDi] [HHi]:[MIi]:[SSi]</code> to <code>[YYYYf]/[MMf]/[DDf] [HHf]:[MIf]:[SSf]</code>

=== When something went wrong ===
If there has been any problem check the last chunk (in wrfout/[PERIODchunk]) to try to understand what happens and where the problem comes from:
* <code>rsl.[error/out].[nnnn]</code>: These are the files which content the standard output while running the model. One file for each process. If the problem was something related to model execution and it has been prepared for the error, a correct message must appear. (look first for the largest files...
<pre>
$ ls -lrS rsl.error.*
</pre>
* <code>run_wrf.log</code>: These are the files which content the standard output of the model. Search for `segmentation faults' in form of (it might differ):
<pre>forrtl: error (63): output conversion error, unit -5, file Internal Formatted Write
Image PC Routine Line Source
orchidee_ol 00000000032B736A Unknown Unknown Unknown
orchidee_ol 00000000032B5EE5 Unknown Unknown Unknown
orchidee_ol 0000000003265966 Unknown Unknown Unknown
orchidee_ol 0000000003226EB5 Unknown Unknown Unknown
orchidee_ol 0000000003226671 Unknown Unknown Unknown
orchidee_ol 000000000324BC3C Unknown Unknown Unknown
orchidee_ol 0000000003249C94 Unknown Unknown Unknown
orchidee_ol 00000000004184DC Unknown Unknown Unknown
libc.so.6 000000319021ECDD Unknown Unknown Unknown
orchidee_ol 00000000004183D9 Unknown Unknown Unknown
</pre>
* on <code>[runHOME]/[ExpName]/[SimName]</code>, check the output of the PBS jobs. Which are called:
** <code>exp-[SimName].o[nnnn]</code>: output of the <code>run_experiment.pbs</code>
** <code>wps-[SimName].o[nnnn]</code>: output of the <code>run_WPS.pbs</code>
** <code>wrf-[SimName].o[nnnn]</code>: output of the <code>run_WRF.pbs</code>
* Check <code>[runHOME]/[ExpName]/[SimName]/run/namelist.output</code> which holds all the parameters (even the default ones) used in the simulation

== EXPERIMENTSparameters.txt ==
This ASCII file configures all the simulation. It assumes:
* Required files, forcings, storage, compiled version of the code might be at different machines.
* There is a folder with a given template version of the <code>namelist.input</code> which will be used and changed accordingly to the requirement of the experiments

Name of the experiment
<pre>
# Experiment name
ExpName = WRFsensSFC
</pre>

Name of the simulation. Here is understood that a given experiment could have the model configured with different set-ups (here identified with a different name of simulation)
<pre>
# Simulation name
SimName = control
</pre>

Which binary of <code>python</code> 2.x to be used
<pre>
# python binary
pyBIN=/home/lluis.fita/bin/anaconda2/bin/python2.7
</pre>

Should this simulation be run from the beginning or not. If it is set to `true', it will remove all the pre-existing content of the folder [ExpName]/[SimName] in the running and in the storage spaces. '''Be careful'''. In case of `false' simulation will continue from the last successful ran '''chunk''' (checking the restart files).
<pre>
# Start from the beginning (keeping folder structure)
scratch = false
</pre>

Period of the simulation of the simulation (In this example from 1958 Jan 1st to 2015 Dec 31)
<pre>
# Experiment starting date
exp_start_date = 19790101000000
# Experiment ending date
exp_end_date = 20150101000000
</pre>

Length of the chunks (do not make chunks larger than 1-month!!)
<pre>
# Chunk Length [N]@[unit]
# [unit]=[year, month, week, day, hour, minute, second]
chunk_length = 1@month
</pre>

Selection of the machines and users to each machine where the different requirement files are located and the output should be placed.
* '''NOTE:''' this will only work if one set-up the <code>.ssh</code> public/private keys in each involved USER/HOST.
* '''NOTE 2:''' All the forcings, compiled code, ... are already at <code>hydra</code> at the common space called <code>share</code>
* '''NOTE 3:''' From the computing nodes, one can not access to the <code>/share</code> folder and to any of the CIMA's storage machines: skogul, freyja, ... For that reason, one need to use these system of <code>[USER]@[HOST]</code> accounts. <code>*.pbs</code> scripts uses a series of wrappers of the standard functions: <code>cp, ln, ls, mv, ....</code> which manage them `from' and `to' different pairs of <code>[USER]@[HOST]</code>. '''NOTE:''' This will only work if the public/private ssh key pairs have been set-up (see more details at [[llaves_ssh]])
<pre>
# Hosts
# list of different hosts and specific user
# [USER]@[HOST]
# NOTE: this will only work if public keys have been set-up
##
# Host with compiled code, namelist templates
codeHOST=lluis.fita@hydra
# forcing Host with forcings (atmospherics and morphologicals)
forcingHOST=lluis.fita@hydra
# output Host with storage of output (including restarts)
outHOST=lluis.fita@hydra
</pre>

Templates of the configuration of WRF: <code>namelist.wps</code>, <code>namelist.input</code> files. '''NOTE:''' they will be changed according to the content of <code>EXPERIMENTparameters.txt</code> like period of the '''chunk''', atmospheric forcing, differences of the set-up, ... (located in the <code>[codeHOST]</code>
<pre>
# Folder with the `namelist.wps', `namelist.input' and `geo_em.d[nn].nc' of the experiment
domainHOME = /home/lluis.fita/salidas/estudios/dominmios/SA50k
</pre>

Folder where the WRF model will run in the computing nodes (on top of that there will be two more folders [ExpName]/[SimName]). WRF will run at the folder [ExpName]/[SimName]/run
<pre>
# Running folder
runHOME = /home/lluis.fita/estudios/WRFsensSFC/sims
</pre>

Folder with the compiled version of the WPS (located at <code>[codeHOST]</code>)
<pre>
# Folder with the compiled source of WPS
wpsHOME = /share/WRF/WRFV3.9.1/ifort/dmpar/WPS
</pre>

Folder with the compiled version of the WRF (located at <code>[codeHOST]</code>)
<pre>
# Folder with the compiled source of WRF
wrfHOME = /share/WRF/WRFV3.9.1/ifort/dmpar/WRFV3
</pre>

Folder to storage all the output of the model (history files, restarts and compressed file with content of the configuration and the standard output of the given run). The content of the folder will be organized by chunks (located at <code>[storageHOST]</code>)
<pre>
# Storage folder of the output
storageHOME = /home/lluis.fita/salidas/estudios/WRFsensSFC/sims/output
</pre>

Wether modules should be load (not used for <code>hydra</code>)
<pre>
# Modules to load ('None' for any)
modulesLOAD = None
</pre>

Names of the files used to check that the '''chunk''' has properly ran
<pre>
# Model reference output names (to be used as checking file names)
nameLISTfile = namelist.input # namelist
nameRSTfile = wrfrst_d01_ # restart file
nameOUTfile = wfrout_d01_ # output file
</pre>

Extensions of the files with the configuration of WRF (to be retrieved from <code>codeHOST</code> and <code>domainHOME</code>)
<pre>
# Extensions of the files with the configuration of the model
configEXTS = wps:input
</pre>

To continue from a previous '''chunk''' one needs to use the `restart' files. But they need to be renamed, because otherwise they will be re-written. Here one specifies the original name of the file <code>[origFile]</code> and the name to be used to avoid the re-writting <code>[destFile]</code>. It uses a complex bash script which even can deal with the change of dates according to the period of the '''chunk''' (':' list of <code>[origFile]@[destFile]</code>). They will located at the <code>[storageHOST]</code>
<pre>
# restart file names
# ':' list of [tmplrstfilen|[NNNNN1]?[val1]#[...[NNNNNn]?[valn]]@[tmpllinkname]|[NNNNN1]?[val1]#[...[NNNNNn]?[valn]]
# [tmplrstfilen]: template name of the restart file (if necessary with [NNNNN] variables to be substituted)
# [NNNNN]: section of the file name to be automatically substituted
# `[YYYY]': year in 4 digits
# `[YY]': year in 2 digits
# `[MM]': month in 2 digits
# `[DD]': day in 2 digits
# `[HH]': hour in 2 digits
# `[SS]': second in 2 digits
# `[JJJ]': julian day in 3 digits
# [val]: value to use (which is systematically defined in `run_OR.pbs')
# `%Y%': year in 4 digits
# `%y%': year in 2 digits
# `%m%': month in 2 digits
# `%d%': day in 2 digits
# `%h%': hour in 2 digits
# `%s%': second in 2 digits
# `%j%': julian day in 3 digits
# [tmpllinkname]: template name of the link of the restart file (if necessary with [NNNNN] variables to be substituted)
rstFILES=wrfrst_d01_[YYYY]-[MM]-[DD]_[HH]:[MI]:[SS]|YYYY?%Y#MM?%m#DD?%d#HH?%H#MI?%M#SS?%S@wrfrst_d01_[YYYY]-[MM]-[DD]_[HH]:[MI]:[SS]|YYYY?%Y#MM?%m#DD?%d#HH?%H#MI?%M#SS?%S
</pre>

Folder with the input data (located at <code>[forcingHOST]</code>).
<pre>
# Folder with the input morphological forcing data
indataHOME = /share/DATA/re-analysis/ERA-Interim
</pre>

Format of the input data and name of files
<pre>
# Data format (grib, nc)
indataFMT= grib
# For `grib' format
# Head and tail of indata files names.
# Assuming ${indataFheader}*[YYYY][MM]*${indataFtail}.[grib/nc]
indataFheader=ERAI_
indataFtail=
</pre>

In case of netCDF input data, there is a bash script which transforms the data to grib, to be used later by <code>ungrib</code>

Variable table to use in <code>ungrib</code>
<pre>
# Type of Vtable for ungrib as Vtable.[VtableType]
VtableType=ERA-interim.pl
</pre>

Folder with the atmospheric forcing data (located at <code>[forcingHOST]</code>).
<pre>
# For `nc' format
# Folder which contents the atmospheric data to generate the initial state
iniatmosHOME = ./
# Type of atmospheric data to generate the initial state
# `ECMWFstd': ECMWF 'standard' way ERAI_[pl/sfc][YYYY][MM]_[var1]-[var2].grib
# `ERAI-IPSL': ECMWF ERA-INTERIM stored in the common IPSL way (.../4xdaily/[AN\_PL/AN\_SF])
iniatmosTYPE = 'ECMWFstd'
</pre>

Here on can change values on the template <code>namelist.input</code>. It will change the values of the provided parameters with a new value. If the given parameter is not in the template of the <code>namelist.input</code> it will be automatically added.
<pre>
## Namelist changes
nlparameters = ra_sw_physics;4,ra_lw_physics;4,time_step;180
</pre>

Name of WRF's executable (to be localized at <code>[orHOME]</code> folder from <code>[codeHOST]</code>)
<pre>
# Name of the exectuable
nameEXEC=wrf.exe
</pre>

':' separated list of netCDF file names from WRF's output which do not need to be kept
<pre>
# netCDF Files which will not be kept anywhere
NokeptfileNAMES=''
</pre>

':' separated list of headers of netCDF file names from WRF's output which need to be kept
<pre>
# Headers of netCDF files need to be kept
HkeptfileNAMES=wrfout_d:wrfxtrm_d:wrfpress_d
</pre>

':' separated list of headers of restarts netCDF file names from WRF's output which need to be kept
<pre>
# Headers of netCDF restart files need to be kept
HrstfileNAMES=wrfrst_d
</pre>

Parallel configuration of the run.
<pre>
# WRF parallel run configuration
## Number of nodes
Nnodes = 1
## Number of mpi procs
Nmpiprocs = 16
## Number of shared memory threads ('None' for no openMP threads)
Nopenthreads = None
## Memory size of shared memory threads
SIZEopenthreads = 200M
## Memory for PBS jobs
MEMjobs = 30gb
</pre>

Generic definitions
<pre>
## Generic
errormsg=ERROR -- error -- ERROR -- error
warnmsg=WARNING -- warning -- WARNING -- warning
</pre>

procesos zombies

2018-12-07T18:19:44Z

Pzaninelli: /* script general */

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 <code>'home'</code> 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.

== script general ==
Hay una script the bash con la cuál se muestran los procesos <CODE>`wrf.exe'</CODE> de un usuario que están corriendo en todos los nodos del clúster
<PRE>
/share/tools/work-flows/components/bats/check_hydra.bash [user]
</PRE>
En donde <CODE>[user]</CODE> es el código numérico del usuarie (ej.: lluis.fita --> 1624)

{| class="wikitable"
! nombre
! número
|-
| lluis.fita
| 1624
|-
| pablo.zaninelli
| 1561

|}

= Caso1: Pasos a seguir =
# Itendificar los procesos de la cola del sistema del usuario (ej. lluis.fita)
<pre>
$ 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
</pre>

# El proceso <code>4426</code> es una simulación de WRF.
<pre>
$ qstat -f 4426
Job Id: 4426.hydra
Job_Name = wrf_control
Job_Owner = lluis.fita@node48
resources_used.cput = 1700:00:37
resources_used.mem = 6264020kb
resources_used.vmem = 15322976kb
resources_used.walltime = 72:40:26
job_state = R
queue = larga
server = hydra
Checkpoint = u
ctime = Sat Apr 7 10:47:06 2018
depend = beforeany:4427.hydra@hydra
Error_Path = node48:/home/lluis.fita/estudios/WRFsensSFC/simulations/contr
ol/wrf_control.e4426
exec_host = node48/23+node48/22+node48/21+node48/20+node48/19+node48/18+no
de48/17+node48/16+node48/15+node48/14+node48/13+node48/12+node48/11+no
de48/10+node48/9+node48/8+node48/7+node48/6+node48/5+node48/4+node48/3
+node48/2+node48/1+node48/0+node51/23+node51/22+node51/21+node51/20+no
de51/19+node51/18+node51/17+node51/16+node51/15+node51/14+node51/13+no
de51/12+node51/11+node51/10+node51/9+node51/8+node51/7+node51/6+node51
/5+node51/4+node51/3+node51/2+node51/1+node51/0
exec_port = 15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15
003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+
15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+1500
3+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15
003+15003+15003
Hold_Types = n
Join_Path = oe
Keep_Files = n
Mail_Points = ae
Mail_Users = lluis.fita@cima.fcen.uba.ar
mtime = Sat Apr 7 10:48:06 2018
Output_Path = node48:/home/lluis.fita/estudios/WRFsensSFC/simulations/cont
rol/wrf_control.o4426
Priority = 0
qtime = Sat Apr 7 10:47:06 2018
Rerunable = True
Resource_List.mem = 30gb
Resource_List.nodect = 2
Resource_List.nodes = 2:ppn=24
Resource_List.vmem = 30gb
Resource_List.walltime = 168:00:00
session_id = 19561
Variable_List = PBS_O_QUEUE=larga,PBS_O_HOST=node48,
PBS_O_HOME=/home/lluis.fita,PBS_O_LANG=en_US.UTF-8,
PBS_O_LOGNAME=lluis.fita,
PBS_O_PATH=/usr/local/bin:/opt/intel/composerxe-2011.3.174/bin/intel6
4:/usr/lib64/qt-3.3/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:
/usr/local/maui/bin:/usr/local/maui/sbin:/usr/local/bin:/opt/intel/com
poserxe/bin:/usr/local/maui/bin:/usr/local/maui/sbin:/home/lluis.fita/
bin:/opt/intel/composerxe-2011.3.174/mpirt/bin/intel64:/usr/local/maui
/bin:/usr/local/maui/sbin,PBS_O_MAIL=/var/spool/mail/lluis.fita,
PBS_O_SHELL=/bin/bash,PBS_SERVER=hydra,
PBS_O_WORKDIR=/home/lluis.fita/estudios/WRFsensSFC/simulations/contro
l
etime = Sat Apr 7 10:47:14 2018
submit_args = -W depend=afterany:4425 /home/lluis.fita/estudios/WRFsensSFC
/simulations/control/run_WRF.pbs
start_time = Sat Apr 7 10:47:14 2018
Walltime.Remaining = 343110
start_count = 1
fault_tolerant = False
submit_host = node48
init_work_dir = /home/lluis.fita/estudios/WRFsensSFC/simulations/control
</pre>
# La variable <code>PBS_O_WORKDIR</code> 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
<pre>
$ 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
</pre>
# 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 <CODE>exec_host</CODE>) node48 y node51.
<pre>
[lluis.fita@hydra ~]$ ssh node48
[lluis.fita@node48 ~]$ top
top - 11:35:40 up 5 days, 47 min, 0 users, load average: 23.00, 22.99, 23.03
Tasks: 246 total, 24 running, 198 sleeping, 0 stopped, 24 zombie
Cpu(s): 87.4%us, 8.4%sy, 0.0%ni, 4.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32942908k total, 18055956k used, 14886952k free, 3972k buffers
Swap: 0k total, 0k used, 0k free, 12102316k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21531 lluis.fi 20 0 508m 256m 28m R 100.0 0.8 4360:00 wrf.exe
21532 lluis.fi 20 0 503m 248m 23m R 100.0 0.8 4358:44 wrf.exe
21537 lluis.fi 20 0 503m 247m 23m R 100.0 0.8 4359:53 wrf.exe
21540 lluis.fi 20 0 507m 252m 23m R 100.0 0.8 4359:52 wrf.exe
21545 lluis.fi 20 0 503m 249m 24m R 100.0 0.8 4359:35 wrf.exe
21546 lluis.fi 20 0 503m 247m 22m R 100.0 0.8 4359:51 wrf.exe
21547 lluis.fi 20 0 507m 253m 23m R 100.0 0.8 4360:04 wrf.exe
21548 lluis.fi 20 0 507m 254m 24m R 100.0 0.8 4359:52 wrf.exe
21549 lluis.fi 20 0 495m 241m 23m R 100.0 0.7 4359:44 wrf.exe
21550 lluis.fi 20 0 507m 251m 23m R 100.0 0.8 4359:47 wrf.exe
21552 lluis.fi 20 0 501m 249m 27m R 100.0 0.8 4359:49 wrf.exe
21529 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:42 wrf.exe
21530 lluis.fi 20 0 500m 246m 25m R 99.7 0.8 4360:05 wrf.exe
21533 lluis.fi 20 0 507m 253m 23m R 99.7 0.8 4359:55 wrf.exe
21534 lluis.fi 20 0 507m 254m 24m R 99.7 0.8 4360:04 wrf.exe
21535 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:40 wrf.exe
21536 lluis.fi 20 0 503m 250m 24m R 99.7 0.8 4359:37 wrf.exe
21539 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:01 wrf.exe
21541 lluis.fi 20 0 503m 248m 23m R 99.7 0.8 4360:07 wrf.exe
21542 lluis.fi 20 0 500m 250m 27m R 99.7 0.8 4359:49 wrf.exe
21543 lluis.fi 20 0 500m 244m 23m R 99.7 0.8 4359:43 wrf.exe
21544 lluis.fi 20 0 507m 251m 23m R 99.7 0.8 4359:34 wrf.exe
21551 lluis.fi 20 0 507m 257m 27m R 99.7 0.8 4360:02 wrf.exe
[lluis.fita@node48 ~]$ killall wrf.exe
[lluis.fita@node48 ~]$ top
top - 11:37:32 up 5 days, 49 min, 0 users, load average: 19.46, 22.23, 22.79
Tasks: 199 total, 1 running, 197 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32942908k total, 12665572k used, 20277336k free, 3972k buffers
Swap: 0k total, 0k used, 0k free, 12048020k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10 root 20 0 0 0 0 S 0.3 0.0 39:27.92 kworker/0:1
262 root 20 0 0 0 0 S 0.3 0.0 0:18.40 kpktgend_13
272 root 20 0 0 0 0 S 0.3 0.0 0:18.47 kpktgend_23
27134 lluis.fi 20 0 15280 1256 888 R 0.3 0.0 0:00.01 top
1 root 20 0 25660 1736 1428 S 0.0 0.0 0:05.71 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:01.17 ksoftirqd/0
[lluis.fita@node48 ~]$ exit
</pre>
# Se repite el procedimiento en tantos nodos cómo ocupe el job (en este caso también <code>node51</code>)
<pre>
[lluis.fita@hydra ~]$ ssh node51
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ killall wrf.exe
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ exit
</pre>
# El job re-aparece cómo <code>cancelled</code> (letra <code>C</code>)
<pre>
[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
</pre>
# Si el job no fuera cancelado, se hace encesaria la cancelación manual
<pre>
$ qdel 4426
</pre>
# Otros jobs que estabn en la cola PBS, ahora ya se están ejecutándose al liberarse los nodos! Se observa en el [[http://scad.cima.fcen.uba.ar/ganglia/ ganglia]] del sistema cómo los nodos 48 y 51, se descargan de carga de cálculo

[[File:Ganglia_afterZombie.png|frame|50px|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 <CODE>pzaninelli</CODE>

# Mirar procesos corriendo
<pre>
[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
</pre>
# Determinar nodos y ruta de ejecución de todos los jobs del usuari.x.
<pre>
[pzaninelli@hydra ~]$ qstat -f 4432
Job Id: 4432.hydra
Job_Name = wrf_control50k
(...)
exec_host = node46/23+node46/22+node46/21+node46/20+node46/19+node46/18+no
de46/17+node46/16+node46/15+node46/14+node46/13+node46/12+node46/11+no
de46/10+node46/9+node46/8+node46/7+node46/6+node46/5+node46/4+node46/3
+node46/2+node46/1+node46/0+node47/23+node47/22+node47/21+node47/20+no
de47/19+node47/18+node47/17+node47/16+node47/15+node47/14+node47/13+no
de47/12+node47/11+node47/10+node47/9+node47/8+node47/7+node47/6+node47
/5+node47/4+node47/3+node47/2+node47/1+node47/0
(...)
PBS_O_WORKDIR=/home/pzaninelli/workdir/SENSHeatWave03/sims/control50k
(...)
[pzaninelli@hydra ~]$ qstat -f 4438
Job Id: 4438.hydra
(...)
exec_host = node49/23+node49/22+node49/21+node49/20+node49/19+node49/18+no
de49/17+node49/16+node49/15+node49/14+node49/13+node49/12+node49/11+no
de49/10+node49/9+node49/8+node49/7+node49/6+node49/5+node49/4+node49/3
+node49/2+node49/1+node49/0+node50/23+node50/22+node50/21+node50/20+no
de50/19+node50/18+node50/17+node50/16+node50/15+node50/14+node50/13+no
de50/12+node50/11+node50/10+node50/9+node50/8+node50/7+node50/6+node50
/5+node50/4+node50/3+node50/2+node50/1+node50/0
(...)
PBS_O_WORKDIR=/home/pzaninelli/workdir/SENSHeatWave03/sims/phy1
</pre>
# Se obtiene que:
* 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
<pre>
$ ssh [nombreNodo]
</pre>
## Chequear los procesos
### Si no se sabe el nombre de la aplicación que podría estar zombie
<pre>
ps -ef | grep $USER
</pre>
### Si se sabe el nombre de la aplicación (en el caso de ejemplo el modelo <code>WRF</Code>)
<pre>
ps -ef | grep [aplicación]
</pre>
### Parar esos procesos que no correspondan (huérfanos de job PBS)
<pre>
kill -9 [procesoID]
</pre>
### Salir del nodo y empezar con el siguiente
<pre>
exit
</pre>
# Después de mirar en los nodos del 40 al 46, entrando en el nodo 47
<pre>
[pzaninelli@hhydra ~]$ ssh node47
[pzaninelli@node47 ~]$ ps -ef | grep wrf.exe
1561 17995 1 74 Apr07 ? 3-00:53:43 ./wrf.exe
1561 17996 1 74 Apr07 ? 3-00:53:36 ./wrf.exe
1561 17997 1 74 Apr07 ? 3-00:49:04 ./wrf.exe
1561 17998 1 74 Apr07 ? 3-00:53:03 ./wrf.exe
1561 17999 1 74 Apr07 ? 3-00:57:12 ./wrf.exe
1561 18000 1 74 Apr07 ? 3-00:47:14 ./wrf.exe
1561 18001 1 74 Apr07 ? 3-00:50:55 ./wrf.exe
1561 18002 1 74 Apr07 ? 3-00:51:08 ./wrf.exe
1561 18003 1 74 Apr07 ? 3-00:53:33 ./wrf.exe
1561 18005 1 74 Apr07 ? 3-00:56:54 ./wrf.exe
1561 18006 1 74 Apr07 ? 3-00:49:51 ./wrf.exe
1561 18007 1 74 Apr07 ? 3-00:51:28 ./wrf.exe
1561 18008 1 74 Apr07 ? 3-00:53:13 ./wrf.exe
1561 18009 1 74 Apr07 ? 3-00:49:40 ./wrf.exe
1561 18010 1 74 Apr07 ? 3-00:52:07 ./wrf.exe
1561 18011 1 74 Apr07 ? 3-00:52:12 ./wrf.exe
1561 18012 1 74 Apr07 ? 3-00:54:05 ./wrf.exe
1561 18013 1 74 Apr07 ? 3-00:52:44 ./wrf.exe
1561 18014 1 74 Apr07 ? 3-00:49:45 ./wrf.exe
1561 18015 1 74 Apr07 ? 3-00:48:31 ./wrf.exe
1561 23401 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23402 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23403 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23404 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23405 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23406 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23407 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23408 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23409 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23410 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23411 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23412 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23413 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23414 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23415 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23416 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23417 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23418 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23419 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23420 23401 56 Apr09 ? 1-05:16:12 ./wrf.exe
1561 23421 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23422 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23423 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23424 23402 55 Apr09 ? 1-05:07:45 ./wrf.exe
1561 23425 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23426 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23427 23404 55 Apr09 ? 1-04:50:56 ./wrf.exe
1561 23428 23405 55 Apr09 ? 1-05:07:46 ./wrf.exe
1561 23429 23406 56 Apr09 ? 1-05:33:20 ./wrf.exe
1561 23430 23417 56 Apr09 ? 1-05:35:49 ./wrf.exe
1561 23431 23407 56 Apr09 ? 1-05:26:10 ./wrf.exe
1561 23432 23421 56 Apr09 ? 1-05:15:46 ./wrf.exe
1561 23433 23415 55 Apr09 ? 1-05:05:37 ./wrf.exe
1561 23434 23403 55 Apr09 ? 1-04:50:07 ./wrf.exe
1561 23435 23426 55 Apr09 ? 1-04:57:29 ./wrf.exe
1561 23436 23419 55 Apr09 ? 1-05:08:26 ./wrf.exe
1561 23437 23414 56 Apr09 ? 1-05:17:23 ./wrf.exe
1561 23438 23409 55 Apr09 ? 1-04:57:51 ./wrf.exe
1561 23439 23411 55 Apr09 ? 1-04:59:43 ./wrf.exe
1561 23440 23408 55 Apr09 ? 1-05:00:49 ./wrf.exe
1561 23441 23410 55 Apr09 ? 1-04:55:14 ./wrf.exe
1561 23442 23423 56 Apr09 ? 1-05:21:52 ./wrf.exe
1561 23443 23422 56 Apr09 ? 1-05:28:01 ./wrf.exe
1561 23444 23413 56 Apr09 ? 1-05:36:03 ./wrf.exe
1561 23445 23425 55 Apr09 ? 1-05:12:05 ./wrf.exe
1561 23446 23412 56 Apr09 ? 1-05:35:22 ./wrf.exe
1561 23447 23418 57 Apr09 ? 1-05:46:58 ./wrf.exe
1561 23448 23416 56 Apr09 ? 1-05:16:21 ./wrf.exe
1561 27514 27474 0 12:30 pts/0 00:00:00 grep wrf.exe
</pre>
# 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
<PRE>
[pzaninelli@node47 ~]$ pwdx 17995
17995: /home/pzaninelli/workdir/SENSHeatWave03/sims/phy1/run

[pzaninelli@node47 ~]$ pwdx 23427
23427: /home/pzaninelli/workdir/SENSHeatWave03/sims/control50k/run
</PRE>
# Del análisi anterior el nodo 47 sólo hospeda el job PBS <code>4432</code> que se ejecuta en <code>/home/pzaninelli/workdir/SENSHeatWave03/sims/control50k</code>. Así que los procesos del grupo (Ids de 17995 a 18015) que se ejecutan en <code>/home/pzaninelli/workdir/SENSHeatWave03/sims/phy1/run</code> son zombies. Así que ya se pueden eliminar
<PRE>
[pzaninelli@node47 ~]$ kill -9 $(seq 17995 18015)
</PRE>
# Ahora al buscar los procesos aprecen sólo los procesos dependiendo del job PBS
<PRE>
[pzaninelli@node47 ~]$ ps -ef | grep wrf.exe
1561 23401 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23402 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23403 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23404 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23405 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23406 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23407 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23408 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23409 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23410 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23411 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23412 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23413 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23414 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23415 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23416 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23417 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23418 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23419 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23420 23401 56 Apr09 ? 1-05:20:01 ./wrf.exe
1561 23421 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23422 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23423 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23424 23402 55 Apr09 ? 1-05:11:40 ./wrf.exe
1561 23425 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23426 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23427 23404 55 Apr09 ? 1-04:54:40 ./wrf.exe
1561 23428 23405 55 Apr09 ? 1-05:11:37 ./wrf.exe
1561 23429 23406 56 Apr09 ? 1-05:37:15 ./wrf.exe
1561 23430 23417 56 Apr09 ? 1-05:40:07 ./wrf.exe
1561 23431 23407 56 Apr09 ? 1-05:30:09 ./wrf.exe
1561 23432 23421 56 Apr09 ? 1-05:19:26 ./wrf.exe
1561 23433 23415 55 Apr09 ? 1-05:09:19 ./wrf.exe
1561 23434 23403 55 Apr09 ? 1-04:54:05 ./wrf.exe
1561 23435 23426 55 Apr09 ? 1-05:01:22 ./wrf.exe
1561 23436 23419 55 Apr09 ? 1-05:12:17 ./wrf.exe
1561 23437 23414 56 Apr09 ? 1-05:21:10 ./wrf.exe
1561 23438 23409 55 Apr09 ? 1-05:01:46 ./wrf.exe
1561 23439 23411 55 Apr09 ? 1-05:03:41 ./wrf.exe
1561 23440 23408 55 Apr09 ? 1-05:04:38 ./wrf.exe
1561 23441 23410 55 Apr09 ? 1-04:58:56 ./wrf.exe
1561 23442 23423 56 Apr09 ? 1-05:25:47 ./wrf.exe
1561 23443 23422 56 Apr09 ? 1-05:31:58 ./wrf.exe
1561 23444 23413 56 Apr09 ? 1-05:40:00 ./wrf.exe
1561 23445 23425 55 Apr09 ? 1-05:16:06 ./wrf.exe
1561 23446 23412 56 Apr09 ? 1-05:39:17 ./wrf.exe
1561 23447 23418 57 Apr09 ? 1-05:50:49 ./wrf.exe
1561 23448 23416 56 Apr09 ? 1-05:20:11 ./wrf.exe
1561 27524 27474 0 12:37 pts/0 00:00:00 grep wrf.exe
</PRE>
# Se repite el proceso en el resto de los nodos y se observa cómo los nodos reducen su carga de trabajo

[[File:GangliaAfterZombie.png|frame|50px|Ejemplo de descarga de los nodos 47, 50 y 53 después de matar un proceso 'zombie']]

procesos zombies

2018-12-07T18:19:03Z

Pzaninelli: /* script general */

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 <code>'home'</code> 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.

== script general ==
Hay una script the bash con la cuál se muestran los procesos <CODE>`wrf.exe'</CODE> de un usuario que están corriendo en todos los nodos del clúster
<PRE>
/share/tools/work-flows/components/bats/check_hydra.bash [user]
</PRE>
En donde <CODE>[user]</CODE> es el código numérico del usuarie (ej.: lluis.fita --> 1624)

{|
! nombre
! úumero
|-
| pablo.zaninelli
| 1561
|}

= Caso1: Pasos a seguir =
# Itendificar los procesos de la cola del sistema del usuario (ej. lluis.fita)
<pre>
$ 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
</pre>

# El proceso <code>4426</code> es una simulación de WRF.
<pre>
$ qstat -f 4426
Job Id: 4426.hydra
Job_Name = wrf_control
Job_Owner = lluis.fita@node48
resources_used.cput = 1700:00:37
resources_used.mem = 6264020kb
resources_used.vmem = 15322976kb
resources_used.walltime = 72:40:26
job_state = R
queue = larga
server = hydra
Checkpoint = u
ctime = Sat Apr 7 10:47:06 2018
depend = beforeany:4427.hydra@hydra
Error_Path = node48:/home/lluis.fita/estudios/WRFsensSFC/simulations/contr
ol/wrf_control.e4426
exec_host = node48/23+node48/22+node48/21+node48/20+node48/19+node48/18+no
de48/17+node48/16+node48/15+node48/14+node48/13+node48/12+node48/11+no
de48/10+node48/9+node48/8+node48/7+node48/6+node48/5+node48/4+node48/3
+node48/2+node48/1+node48/0+node51/23+node51/22+node51/21+node51/20+no
de51/19+node51/18+node51/17+node51/16+node51/15+node51/14+node51/13+no
de51/12+node51/11+node51/10+node51/9+node51/8+node51/7+node51/6+node51
/5+node51/4+node51/3+node51/2+node51/1+node51/0
exec_port = 15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15
003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+
15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+1500
3+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15
003+15003+15003
Hold_Types = n
Join_Path = oe
Keep_Files = n
Mail_Points = ae
Mail_Users = lluis.fita@cima.fcen.uba.ar
mtime = Sat Apr 7 10:48:06 2018
Output_Path = node48:/home/lluis.fita/estudios/WRFsensSFC/simulations/cont
rol/wrf_control.o4426
Priority = 0
qtime = Sat Apr 7 10:47:06 2018
Rerunable = True
Resource_List.mem = 30gb
Resource_List.nodect = 2
Resource_List.nodes = 2:ppn=24
Resource_List.vmem = 30gb
Resource_List.walltime = 168:00:00
session_id = 19561
Variable_List = PBS_O_QUEUE=larga,PBS_O_HOST=node48,
PBS_O_HOME=/home/lluis.fita,PBS_O_LANG=en_US.UTF-8,
PBS_O_LOGNAME=lluis.fita,
PBS_O_PATH=/usr/local/bin:/opt/intel/composerxe-2011.3.174/bin/intel6
4:/usr/lib64/qt-3.3/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:
/usr/local/maui/bin:/usr/local/maui/sbin:/usr/local/bin:/opt/intel/com
poserxe/bin:/usr/local/maui/bin:/usr/local/maui/sbin:/home/lluis.fita/
bin:/opt/intel/composerxe-2011.3.174/mpirt/bin/intel64:/usr/local/maui
/bin:/usr/local/maui/sbin,PBS_O_MAIL=/var/spool/mail/lluis.fita,
PBS_O_SHELL=/bin/bash,PBS_SERVER=hydra,
PBS_O_WORKDIR=/home/lluis.fita/estudios/WRFsensSFC/simulations/contro
l
etime = Sat Apr 7 10:47:14 2018
submit_args = -W depend=afterany:4425 /home/lluis.fita/estudios/WRFsensSFC
/simulations/control/run_WRF.pbs
start_time = Sat Apr 7 10:47:14 2018
Walltime.Remaining = 343110
start_count = 1
fault_tolerant = False
submit_host = node48
init_work_dir = /home/lluis.fita/estudios/WRFsensSFC/simulations/control
</pre>
# La variable <code>PBS_O_WORKDIR</code> 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
<pre>
$ 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
</pre>
# 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 <CODE>exec_host</CODE>) node48 y node51.
<pre>
[lluis.fita@hydra ~]$ ssh node48
[lluis.fita@node48 ~]$ top
top - 11:35:40 up 5 days, 47 min, 0 users, load average: 23.00, 22.99, 23.03
Tasks: 246 total, 24 running, 198 sleeping, 0 stopped, 24 zombie
Cpu(s): 87.4%us, 8.4%sy, 0.0%ni, 4.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32942908k total, 18055956k used, 14886952k free, 3972k buffers
Swap: 0k total, 0k used, 0k free, 12102316k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21531 lluis.fi 20 0 508m 256m 28m R 100.0 0.8 4360:00 wrf.exe
21532 lluis.fi 20 0 503m 248m 23m R 100.0 0.8 4358:44 wrf.exe
21537 lluis.fi 20 0 503m 247m 23m R 100.0 0.8 4359:53 wrf.exe
21540 lluis.fi 20 0 507m 252m 23m R 100.0 0.8 4359:52 wrf.exe
21545 lluis.fi 20 0 503m 249m 24m R 100.0 0.8 4359:35 wrf.exe
21546 lluis.fi 20 0 503m 247m 22m R 100.0 0.8 4359:51 wrf.exe
21547 lluis.fi 20 0 507m 253m 23m R 100.0 0.8 4360:04 wrf.exe
21548 lluis.fi 20 0 507m 254m 24m R 100.0 0.8 4359:52 wrf.exe
21549 lluis.fi 20 0 495m 241m 23m R 100.0 0.7 4359:44 wrf.exe
21550 lluis.fi 20 0 507m 251m 23m R 100.0 0.8 4359:47 wrf.exe
21552 lluis.fi 20 0 501m 249m 27m R 100.0 0.8 4359:49 wrf.exe
21529 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:42 wrf.exe
21530 lluis.fi 20 0 500m 246m 25m R 99.7 0.8 4360:05 wrf.exe
21533 lluis.fi 20 0 507m 253m 23m R 99.7 0.8 4359:55 wrf.exe
21534 lluis.fi 20 0 507m 254m 24m R 99.7 0.8 4360:04 wrf.exe
21535 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:40 wrf.exe
21536 lluis.fi 20 0 503m 250m 24m R 99.7 0.8 4359:37 wrf.exe
21539 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:01 wrf.exe
21541 lluis.fi 20 0 503m 248m 23m R 99.7 0.8 4360:07 wrf.exe
21542 lluis.fi 20 0 500m 250m 27m R 99.7 0.8 4359:49 wrf.exe
21543 lluis.fi 20 0 500m 244m 23m R 99.7 0.8 4359:43 wrf.exe
21544 lluis.fi 20 0 507m 251m 23m R 99.7 0.8 4359:34 wrf.exe
21551 lluis.fi 20 0 507m 257m 27m R 99.7 0.8 4360:02 wrf.exe
[lluis.fita@node48 ~]$ killall wrf.exe
[lluis.fita@node48 ~]$ top
top - 11:37:32 up 5 days, 49 min, 0 users, load average: 19.46, 22.23, 22.79
Tasks: 199 total, 1 running, 197 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32942908k total, 12665572k used, 20277336k free, 3972k buffers
Swap: 0k total, 0k used, 0k free, 12048020k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10 root 20 0 0 0 0 S 0.3 0.0 39:27.92 kworker/0:1
262 root 20 0 0 0 0 S 0.3 0.0 0:18.40 kpktgend_13
272 root 20 0 0 0 0 S 0.3 0.0 0:18.47 kpktgend_23
27134 lluis.fi 20 0 15280 1256 888 R 0.3 0.0 0:00.01 top
1 root 20 0 25660 1736 1428 S 0.0 0.0 0:05.71 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:01.17 ksoftirqd/0
[lluis.fita@node48 ~]$ exit
</pre>
# Se repite el procedimiento en tantos nodos cómo ocupe el job (en este caso también <code>node51</code>)
<pre>
[lluis.fita@hydra ~]$ ssh node51
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ killall wrf.exe
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ exit
</pre>
# El job re-aparece cómo <code>cancelled</code> (letra <code>C</code>)
<pre>
[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
</pre>
# Si el job no fuera cancelado, se hace encesaria la cancelación manual
<pre>
$ qdel 4426
</pre>
# Otros jobs que estabn en la cola PBS, ahora ya se están ejecutándose al liberarse los nodos! Se observa en el [[http://scad.cima.fcen.uba.ar/ganglia/ ganglia]] del sistema cómo los nodos 48 y 51, se descargan de carga de cálculo

[[File:Ganglia_afterZombie.png|frame|50px|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 <CODE>pzaninelli</CODE>

# Mirar procesos corriendo
<pre>
[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
</pre>
# Determinar nodos y ruta de ejecución de todos los jobs del usuari.x.
<pre>
[pzaninelli@hydra ~]$ qstat -f 4432
Job Id: 4432.hydra
Job_Name = wrf_control50k
(...)
exec_host = node46/23+node46/22+node46/21+node46/20+node46/19+node46/18+no
de46/17+node46/16+node46/15+node46/14+node46/13+node46/12+node46/11+no
de46/10+node46/9+node46/8+node46/7+node46/6+node46/5+node46/4+node46/3
+node46/2+node46/1+node46/0+node47/23+node47/22+node47/21+node47/20+no
de47/19+node47/18+node47/17+node47/16+node47/15+node47/14+node47/13+no
de47/12+node47/11+node47/10+node47/9+node47/8+node47/7+node47/6+node47
/5+node47/4+node47/3+node47/2+node47/1+node47/0
(...)
PBS_O_WORKDIR=/home/pzaninelli/workdir/SENSHeatWave03/sims/control50k
(...)
[pzaninelli@hydra ~]$ qstat -f 4438
Job Id: 4438.hydra
(...)
exec_host = node49/23+node49/22+node49/21+node49/20+node49/19+node49/18+no
de49/17+node49/16+node49/15+node49/14+node49/13+node49/12+node49/11+no
de49/10+node49/9+node49/8+node49/7+node49/6+node49/5+node49/4+node49/3
+node49/2+node49/1+node49/0+node50/23+node50/22+node50/21+node50/20+no
de50/19+node50/18+node50/17+node50/16+node50/15+node50/14+node50/13+no
de50/12+node50/11+node50/10+node50/9+node50/8+node50/7+node50/6+node50
/5+node50/4+node50/3+node50/2+node50/1+node50/0
(...)
PBS_O_WORKDIR=/home/pzaninelli/workdir/SENSHeatWave03/sims/phy1
</pre>
# Se obtiene que:
* 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
<pre>
$ ssh [nombreNodo]
</pre>
## Chequear los procesos
### Si no se sabe el nombre de la aplicación que podría estar zombie
<pre>
ps -ef | grep $USER
</pre>
### Si se sabe el nombre de la aplicación (en el caso de ejemplo el modelo <code>WRF</Code>)
<pre>
ps -ef | grep [aplicación]
</pre>
### Parar esos procesos que no correspondan (huérfanos de job PBS)
<pre>
kill -9 [procesoID]
</pre>
### Salir del nodo y empezar con el siguiente
<pre>
exit
</pre>
# Después de mirar en los nodos del 40 al 46, entrando en el nodo 47
<pre>
[pzaninelli@hhydra ~]$ ssh node47
[pzaninelli@node47 ~]$ ps -ef | grep wrf.exe
1561 17995 1 74 Apr07 ? 3-00:53:43 ./wrf.exe
1561 17996 1 74 Apr07 ? 3-00:53:36 ./wrf.exe
1561 17997 1 74 Apr07 ? 3-00:49:04 ./wrf.exe
1561 17998 1 74 Apr07 ? 3-00:53:03 ./wrf.exe
1561 17999 1 74 Apr07 ? 3-00:57:12 ./wrf.exe
1561 18000 1 74 Apr07 ? 3-00:47:14 ./wrf.exe
1561 18001 1 74 Apr07 ? 3-00:50:55 ./wrf.exe
1561 18002 1 74 Apr07 ? 3-00:51:08 ./wrf.exe
1561 18003 1 74 Apr07 ? 3-00:53:33 ./wrf.exe
1561 18005 1 74 Apr07 ? 3-00:56:54 ./wrf.exe
1561 18006 1 74 Apr07 ? 3-00:49:51 ./wrf.exe
1561 18007 1 74 Apr07 ? 3-00:51:28 ./wrf.exe
1561 18008 1 74 Apr07 ? 3-00:53:13 ./wrf.exe
1561 18009 1 74 Apr07 ? 3-00:49:40 ./wrf.exe
1561 18010 1 74 Apr07 ? 3-00:52:07 ./wrf.exe
1561 18011 1 74 Apr07 ? 3-00:52:12 ./wrf.exe
1561 18012 1 74 Apr07 ? 3-00:54:05 ./wrf.exe
1561 18013 1 74 Apr07 ? 3-00:52:44 ./wrf.exe
1561 18014 1 74 Apr07 ? 3-00:49:45 ./wrf.exe
1561 18015 1 74 Apr07 ? 3-00:48:31 ./wrf.exe
1561 23401 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23402 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23403 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23404 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23405 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23406 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23407 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23408 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23409 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23410 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23411 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23412 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23413 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23414 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23415 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23416 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23417 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23418 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23419 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23420 23401 56 Apr09 ? 1-05:16:12 ./wrf.exe
1561 23421 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23422 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23423 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23424 23402 55 Apr09 ? 1-05:07:45 ./wrf.exe
1561 23425 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23426 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23427 23404 55 Apr09 ? 1-04:50:56 ./wrf.exe
1561 23428 23405 55 Apr09 ? 1-05:07:46 ./wrf.exe
1561 23429 23406 56 Apr09 ? 1-05:33:20 ./wrf.exe
1561 23430 23417 56 Apr09 ? 1-05:35:49 ./wrf.exe
1561 23431 23407 56 Apr09 ? 1-05:26:10 ./wrf.exe
1561 23432 23421 56 Apr09 ? 1-05:15:46 ./wrf.exe
1561 23433 23415 55 Apr09 ? 1-05:05:37 ./wrf.exe
1561 23434 23403 55 Apr09 ? 1-04:50:07 ./wrf.exe
1561 23435 23426 55 Apr09 ? 1-04:57:29 ./wrf.exe
1561 23436 23419 55 Apr09 ? 1-05:08:26 ./wrf.exe
1561 23437 23414 56 Apr09 ? 1-05:17:23 ./wrf.exe
1561 23438 23409 55 Apr09 ? 1-04:57:51 ./wrf.exe
1561 23439 23411 55 Apr09 ? 1-04:59:43 ./wrf.exe
1561 23440 23408 55 Apr09 ? 1-05:00:49 ./wrf.exe
1561 23441 23410 55 Apr09 ? 1-04:55:14 ./wrf.exe
1561 23442 23423 56 Apr09 ? 1-05:21:52 ./wrf.exe
1561 23443 23422 56 Apr09 ? 1-05:28:01 ./wrf.exe
1561 23444 23413 56 Apr09 ? 1-05:36:03 ./wrf.exe
1561 23445 23425 55 Apr09 ? 1-05:12:05 ./wrf.exe
1561 23446 23412 56 Apr09 ? 1-05:35:22 ./wrf.exe
1561 23447 23418 57 Apr09 ? 1-05:46:58 ./wrf.exe
1561 23448 23416 56 Apr09 ? 1-05:16:21 ./wrf.exe
1561 27514 27474 0 12:30 pts/0 00:00:00 grep wrf.exe
</pre>
# 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
<PRE>
[pzaninelli@node47 ~]$ pwdx 17995
17995: /home/pzaninelli/workdir/SENSHeatWave03/sims/phy1/run

[pzaninelli@node47 ~]$ pwdx 23427
23427: /home/pzaninelli/workdir/SENSHeatWave03/sims/control50k/run
</PRE>
# Del análisi anterior el nodo 47 sólo hospeda el job PBS <code>4432</code> que se ejecuta en <code>/home/pzaninelli/workdir/SENSHeatWave03/sims/control50k</code>. Así que los procesos del grupo (Ids de 17995 a 18015) que se ejecutan en <code>/home/pzaninelli/workdir/SENSHeatWave03/sims/phy1/run</code> son zombies. Así que ya se pueden eliminar
<PRE>
[pzaninelli@node47 ~]$ kill -9 $(seq 17995 18015)
</PRE>
# Ahora al buscar los procesos aprecen sólo los procesos dependiendo del job PBS
<PRE>
[pzaninelli@node47 ~]$ ps -ef | grep wrf.exe
1561 23401 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23402 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23403 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23404 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23405 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23406 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23407 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23408 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23409 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23410 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23411 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23412 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23413 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23414 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23415 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23416 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23417 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23418 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23419 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23420 23401 56 Apr09 ? 1-05:20:01 ./wrf.exe
1561 23421 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23422 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23423 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23424 23402 55 Apr09 ? 1-05:11:40 ./wrf.exe
1561 23425 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23426 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23427 23404 55 Apr09 ? 1-04:54:40 ./wrf.exe
1561 23428 23405 55 Apr09 ? 1-05:11:37 ./wrf.exe
1561 23429 23406 56 Apr09 ? 1-05:37:15 ./wrf.exe
1561 23430 23417 56 Apr09 ? 1-05:40:07 ./wrf.exe
1561 23431 23407 56 Apr09 ? 1-05:30:09 ./wrf.exe
1561 23432 23421 56 Apr09 ? 1-05:19:26 ./wrf.exe
1561 23433 23415 55 Apr09 ? 1-05:09:19 ./wrf.exe
1561 23434 23403 55 Apr09 ? 1-04:54:05 ./wrf.exe
1561 23435 23426 55 Apr09 ? 1-05:01:22 ./wrf.exe
1561 23436 23419 55 Apr09 ? 1-05:12:17 ./wrf.exe
1561 23437 23414 56 Apr09 ? 1-05:21:10 ./wrf.exe
1561 23438 23409 55 Apr09 ? 1-05:01:46 ./wrf.exe
1561 23439 23411 55 Apr09 ? 1-05:03:41 ./wrf.exe
1561 23440 23408 55 Apr09 ? 1-05:04:38 ./wrf.exe
1561 23441 23410 55 Apr09 ? 1-04:58:56 ./wrf.exe
1561 23442 23423 56 Apr09 ? 1-05:25:47 ./wrf.exe
1561 23443 23422 56 Apr09 ? 1-05:31:58 ./wrf.exe
1561 23444 23413 56 Apr09 ? 1-05:40:00 ./wrf.exe
1561 23445 23425 55 Apr09 ? 1-05:16:06 ./wrf.exe
1561 23446 23412 56 Apr09 ? 1-05:39:17 ./wrf.exe
1561 23447 23418 57 Apr09 ? 1-05:50:49 ./wrf.exe
1561 23448 23416 56 Apr09 ? 1-05:20:11 ./wrf.exe
1561 27524 27474 0 12:37 pts/0 00:00:00 grep wrf.exe
</PRE>
# Se repite el proceso en el resto de los nodos y se observa cómo los nodos reducen su carga de trabajo

[[File:GangliaAfterZombie.png|frame|50px|Ejemplo de descarga de los nodos 47, 50 y 53 después de matar un proceso 'zombie']]

procesos zombies

2018-12-07T18:18:16Z

Pzaninelli: /* script general */

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 <code>'home'</code> 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.

== script general ==
Hay una script the bash con la cuál se muestran los procesos <CODE>`wrf.exe'</CODE> de un usuario que están corriendo en todos los nodos del clúster
<PRE>
/share/tools/work-flows/components/bats/check_hydra.bash [user]
</PRE>
En donde <CODE>[user]</CODE> es el código numérico del usuarie (ej.: lluis.fita --> 1624)

{|
| nombre
| numero
-
| pablo.zaninelli
| 1561
-
|}

= Caso1: Pasos a seguir =
# Itendificar los procesos de la cola del sistema del usuario (ej. lluis.fita)
<pre>
$ 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
</pre>

# El proceso <code>4426</code> es una simulación de WRF.
<pre>
$ qstat -f 4426
Job Id: 4426.hydra
Job_Name = wrf_control
Job_Owner = lluis.fita@node48
resources_used.cput = 1700:00:37
resources_used.mem = 6264020kb
resources_used.vmem = 15322976kb
resources_used.walltime = 72:40:26
job_state = R
queue = larga
server = hydra
Checkpoint = u
ctime = Sat Apr 7 10:47:06 2018
depend = beforeany:4427.hydra@hydra
Error_Path = node48:/home/lluis.fita/estudios/WRFsensSFC/simulations/contr
ol/wrf_control.e4426
exec_host = node48/23+node48/22+node48/21+node48/20+node48/19+node48/18+no
de48/17+node48/16+node48/15+node48/14+node48/13+node48/12+node48/11+no
de48/10+node48/9+node48/8+node48/7+node48/6+node48/5+node48/4+node48/3
+node48/2+node48/1+node48/0+node51/23+node51/22+node51/21+node51/20+no
de51/19+node51/18+node51/17+node51/16+node51/15+node51/14+node51/13+no
de51/12+node51/11+node51/10+node51/9+node51/8+node51/7+node51/6+node51
/5+node51/4+node51/3+node51/2+node51/1+node51/0
exec_port = 15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15
003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+
15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+1500
3+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15
003+15003+15003
Hold_Types = n
Join_Path = oe
Keep_Files = n
Mail_Points = ae
Mail_Users = lluis.fita@cima.fcen.uba.ar
mtime = Sat Apr 7 10:48:06 2018
Output_Path = node48:/home/lluis.fita/estudios/WRFsensSFC/simulations/cont
rol/wrf_control.o4426
Priority = 0
qtime = Sat Apr 7 10:47:06 2018
Rerunable = True
Resource_List.mem = 30gb
Resource_List.nodect = 2
Resource_List.nodes = 2:ppn=24
Resource_List.vmem = 30gb
Resource_List.walltime = 168:00:00
session_id = 19561
Variable_List = PBS_O_QUEUE=larga,PBS_O_HOST=node48,
PBS_O_HOME=/home/lluis.fita,PBS_O_LANG=en_US.UTF-8,
PBS_O_LOGNAME=lluis.fita,
PBS_O_PATH=/usr/local/bin:/opt/intel/composerxe-2011.3.174/bin/intel6
4:/usr/lib64/qt-3.3/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:
/usr/local/maui/bin:/usr/local/maui/sbin:/usr/local/bin:/opt/intel/com
poserxe/bin:/usr/local/maui/bin:/usr/local/maui/sbin:/home/lluis.fita/
bin:/opt/intel/composerxe-2011.3.174/mpirt/bin/intel64:/usr/local/maui
/bin:/usr/local/maui/sbin,PBS_O_MAIL=/var/spool/mail/lluis.fita,
PBS_O_SHELL=/bin/bash,PBS_SERVER=hydra,
PBS_O_WORKDIR=/home/lluis.fita/estudios/WRFsensSFC/simulations/contro
l
etime = Sat Apr 7 10:47:14 2018
submit_args = -W depend=afterany:4425 /home/lluis.fita/estudios/WRFsensSFC
/simulations/control/run_WRF.pbs
start_time = Sat Apr 7 10:47:14 2018
Walltime.Remaining = 343110
start_count = 1
fault_tolerant = False
submit_host = node48
init_work_dir = /home/lluis.fita/estudios/WRFsensSFC/simulations/control
</pre>
# La variable <code>PBS_O_WORKDIR</code> 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
<pre>
$ 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
</pre>
# 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 <CODE>exec_host</CODE>) node48 y node51.
<pre>
[lluis.fita@hydra ~]$ ssh node48
[lluis.fita@node48 ~]$ top
top - 11:35:40 up 5 days, 47 min, 0 users, load average: 23.00, 22.99, 23.03
Tasks: 246 total, 24 running, 198 sleeping, 0 stopped, 24 zombie
Cpu(s): 87.4%us, 8.4%sy, 0.0%ni, 4.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32942908k total, 18055956k used, 14886952k free, 3972k buffers
Swap: 0k total, 0k used, 0k free, 12102316k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21531 lluis.fi 20 0 508m 256m 28m R 100.0 0.8 4360:00 wrf.exe
21532 lluis.fi 20 0 503m 248m 23m R 100.0 0.8 4358:44 wrf.exe
21537 lluis.fi 20 0 503m 247m 23m R 100.0 0.8 4359:53 wrf.exe
21540 lluis.fi 20 0 507m 252m 23m R 100.0 0.8 4359:52 wrf.exe
21545 lluis.fi 20 0 503m 249m 24m R 100.0 0.8 4359:35 wrf.exe
21546 lluis.fi 20 0 503m 247m 22m R 100.0 0.8 4359:51 wrf.exe
21547 lluis.fi 20 0 507m 253m 23m R 100.0 0.8 4360:04 wrf.exe
21548 lluis.fi 20 0 507m 254m 24m R 100.0 0.8 4359:52 wrf.exe
21549 lluis.fi 20 0 495m 241m 23m R 100.0 0.7 4359:44 wrf.exe
21550 lluis.fi 20 0 507m 251m 23m R 100.0 0.8 4359:47 wrf.exe
21552 lluis.fi 20 0 501m 249m 27m R 100.0 0.8 4359:49 wrf.exe
21529 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:42 wrf.exe
21530 lluis.fi 20 0 500m 246m 25m R 99.7 0.8 4360:05 wrf.exe
21533 lluis.fi 20 0 507m 253m 23m R 99.7 0.8 4359:55 wrf.exe
21534 lluis.fi 20 0 507m 254m 24m R 99.7 0.8 4360:04 wrf.exe
21535 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:40 wrf.exe
21536 lluis.fi 20 0 503m 250m 24m R 99.7 0.8 4359:37 wrf.exe
21539 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:01 wrf.exe
21541 lluis.fi 20 0 503m 248m 23m R 99.7 0.8 4360:07 wrf.exe
21542 lluis.fi 20 0 500m 250m 27m R 99.7 0.8 4359:49 wrf.exe
21543 lluis.fi 20 0 500m 244m 23m R 99.7 0.8 4359:43 wrf.exe
21544 lluis.fi 20 0 507m 251m 23m R 99.7 0.8 4359:34 wrf.exe
21551 lluis.fi 20 0 507m 257m 27m R 99.7 0.8 4360:02 wrf.exe
[lluis.fita@node48 ~]$ killall wrf.exe
[lluis.fita@node48 ~]$ top
top - 11:37:32 up 5 days, 49 min, 0 users, load average: 19.46, 22.23, 22.79
Tasks: 199 total, 1 running, 197 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32942908k total, 12665572k used, 20277336k free, 3972k buffers
Swap: 0k total, 0k used, 0k free, 12048020k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10 root 20 0 0 0 0 S 0.3 0.0 39:27.92 kworker/0:1
262 root 20 0 0 0 0 S 0.3 0.0 0:18.40 kpktgend_13
272 root 20 0 0 0 0 S 0.3 0.0 0:18.47 kpktgend_23
27134 lluis.fi 20 0 15280 1256 888 R 0.3 0.0 0:00.01 top
1 root 20 0 25660 1736 1428 S 0.0 0.0 0:05.71 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:01.17 ksoftirqd/0
[lluis.fita@node48 ~]$ exit
</pre>
# Se repite el procedimiento en tantos nodos cómo ocupe el job (en este caso también <code>node51</code>)
<pre>
[lluis.fita@hydra ~]$ ssh node51
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ killall wrf.exe
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ exit
</pre>
# El job re-aparece cómo <code>cancelled</code> (letra <code>C</code>)
<pre>
[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
</pre>
# Si el job no fuera cancelado, se hace encesaria la cancelación manual
<pre>
$ qdel 4426
</pre>
# Otros jobs que estabn en la cola PBS, ahora ya se están ejecutándose al liberarse los nodos! Se observa en el [[http://scad.cima.fcen.uba.ar/ganglia/ ganglia]] del sistema cómo los nodos 48 y 51, se descargan de carga de cálculo

[[File:Ganglia_afterZombie.png|frame|50px|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 <CODE>pzaninelli</CODE>

# Mirar procesos corriendo
<pre>
[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
</pre>
# Determinar nodos y ruta de ejecución de todos los jobs del usuari.x.
<pre>
[pzaninelli@hydra ~]$ qstat -f 4432
Job Id: 4432.hydra
Job_Name = wrf_control50k
(...)
exec_host = node46/23+node46/22+node46/21+node46/20+node46/19+node46/18+no
de46/17+node46/16+node46/15+node46/14+node46/13+node46/12+node46/11+no
de46/10+node46/9+node46/8+node46/7+node46/6+node46/5+node46/4+node46/3
+node46/2+node46/1+node46/0+node47/23+node47/22+node47/21+node47/20+no
de47/19+node47/18+node47/17+node47/16+node47/15+node47/14+node47/13+no
de47/12+node47/11+node47/10+node47/9+node47/8+node47/7+node47/6+node47
/5+node47/4+node47/3+node47/2+node47/1+node47/0
(...)
PBS_O_WORKDIR=/home/pzaninelli/workdir/SENSHeatWave03/sims/control50k
(...)
[pzaninelli@hydra ~]$ qstat -f 4438
Job Id: 4438.hydra
(...)
exec_host = node49/23+node49/22+node49/21+node49/20+node49/19+node49/18+no
de49/17+node49/16+node49/15+node49/14+node49/13+node49/12+node49/11+no
de49/10+node49/9+node49/8+node49/7+node49/6+node49/5+node49/4+node49/3
+node49/2+node49/1+node49/0+node50/23+node50/22+node50/21+node50/20+no
de50/19+node50/18+node50/17+node50/16+node50/15+node50/14+node50/13+no
de50/12+node50/11+node50/10+node50/9+node50/8+node50/7+node50/6+node50
/5+node50/4+node50/3+node50/2+node50/1+node50/0
(...)
PBS_O_WORKDIR=/home/pzaninelli/workdir/SENSHeatWave03/sims/phy1
</pre>
# Se obtiene que:
* 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
<pre>
$ ssh [nombreNodo]
</pre>
## Chequear los procesos
### Si no se sabe el nombre de la aplicación que podría estar zombie
<pre>
ps -ef | grep $USER
</pre>
### Si se sabe el nombre de la aplicación (en el caso de ejemplo el modelo <code>WRF</Code>)
<pre>
ps -ef | grep [aplicación]
</pre>
### Parar esos procesos que no correspondan (huérfanos de job PBS)
<pre>
kill -9 [procesoID]
</pre>
### Salir del nodo y empezar con el siguiente
<pre>
exit
</pre>
# Después de mirar en los nodos del 40 al 46, entrando en el nodo 47
<pre>
[pzaninelli@hhydra ~]$ ssh node47
[pzaninelli@node47 ~]$ ps -ef | grep wrf.exe
1561 17995 1 74 Apr07 ? 3-00:53:43 ./wrf.exe
1561 17996 1 74 Apr07 ? 3-00:53:36 ./wrf.exe
1561 17997 1 74 Apr07 ? 3-00:49:04 ./wrf.exe
1561 17998 1 74 Apr07 ? 3-00:53:03 ./wrf.exe
1561 17999 1 74 Apr07 ? 3-00:57:12 ./wrf.exe
1561 18000 1 74 Apr07 ? 3-00:47:14 ./wrf.exe
1561 18001 1 74 Apr07 ? 3-00:50:55 ./wrf.exe
1561 18002 1 74 Apr07 ? 3-00:51:08 ./wrf.exe
1561 18003 1 74 Apr07 ? 3-00:53:33 ./wrf.exe
1561 18005 1 74 Apr07 ? 3-00:56:54 ./wrf.exe
1561 18006 1 74 Apr07 ? 3-00:49:51 ./wrf.exe
1561 18007 1 74 Apr07 ? 3-00:51:28 ./wrf.exe
1561 18008 1 74 Apr07 ? 3-00:53:13 ./wrf.exe
1561 18009 1 74 Apr07 ? 3-00:49:40 ./wrf.exe
1561 18010 1 74 Apr07 ? 3-00:52:07 ./wrf.exe
1561 18011 1 74 Apr07 ? 3-00:52:12 ./wrf.exe
1561 18012 1 74 Apr07 ? 3-00:54:05 ./wrf.exe
1561 18013 1 74 Apr07 ? 3-00:52:44 ./wrf.exe
1561 18014 1 74 Apr07 ? 3-00:49:45 ./wrf.exe
1561 18015 1 74 Apr07 ? 3-00:48:31 ./wrf.exe
1561 23401 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23402 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23403 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23404 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23405 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23406 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23407 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23408 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23409 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23410 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23411 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23412 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23413 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23414 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23415 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23416 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23417 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23418 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23419 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23420 23401 56 Apr09 ? 1-05:16:12 ./wrf.exe
1561 23421 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23422 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23423 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23424 23402 55 Apr09 ? 1-05:07:45 ./wrf.exe
1561 23425 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23426 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23427 23404 55 Apr09 ? 1-04:50:56 ./wrf.exe
1561 23428 23405 55 Apr09 ? 1-05:07:46 ./wrf.exe
1561 23429 23406 56 Apr09 ? 1-05:33:20 ./wrf.exe
1561 23430 23417 56 Apr09 ? 1-05:35:49 ./wrf.exe
1561 23431 23407 56 Apr09 ? 1-05:26:10 ./wrf.exe
1561 23432 23421 56 Apr09 ? 1-05:15:46 ./wrf.exe
1561 23433 23415 55 Apr09 ? 1-05:05:37 ./wrf.exe
1561 23434 23403 55 Apr09 ? 1-04:50:07 ./wrf.exe
1561 23435 23426 55 Apr09 ? 1-04:57:29 ./wrf.exe
1561 23436 23419 55 Apr09 ? 1-05:08:26 ./wrf.exe
1561 23437 23414 56 Apr09 ? 1-05:17:23 ./wrf.exe
1561 23438 23409 55 Apr09 ? 1-04:57:51 ./wrf.exe
1561 23439 23411 55 Apr09 ? 1-04:59:43 ./wrf.exe
1561 23440 23408 55 Apr09 ? 1-05:00:49 ./wrf.exe
1561 23441 23410 55 Apr09 ? 1-04:55:14 ./wrf.exe
1561 23442 23423 56 Apr09 ? 1-05:21:52 ./wrf.exe
1561 23443 23422 56 Apr09 ? 1-05:28:01 ./wrf.exe
1561 23444 23413 56 Apr09 ? 1-05:36:03 ./wrf.exe
1561 23445 23425 55 Apr09 ? 1-05:12:05 ./wrf.exe
1561 23446 23412 56 Apr09 ? 1-05:35:22 ./wrf.exe
1561 23447 23418 57 Apr09 ? 1-05:46:58 ./wrf.exe
1561 23448 23416 56 Apr09 ? 1-05:16:21 ./wrf.exe
1561 27514 27474 0 12:30 pts/0 00:00:00 grep wrf.exe
</pre>
# 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
<PRE>
[pzaninelli@node47 ~]$ pwdx 17995
17995: /home/pzaninelli/workdir/SENSHeatWave03/sims/phy1/run

[pzaninelli@node47 ~]$ pwdx 23427
23427: /home/pzaninelli/workdir/SENSHeatWave03/sims/control50k/run
</PRE>
# Del análisi anterior el nodo 47 sólo hospeda el job PBS <code>4432</code> que se ejecuta en <code>/home/pzaninelli/workdir/SENSHeatWave03/sims/control50k</code>. Así que los procesos del grupo (Ids de 17995 a 18015) que se ejecutan en <code>/home/pzaninelli/workdir/SENSHeatWave03/sims/phy1/run</code> son zombies. Así que ya se pueden eliminar
<PRE>
[pzaninelli@node47 ~]$ kill -9 $(seq 17995 18015)
</PRE>
# Ahora al buscar los procesos aprecen sólo los procesos dependiendo del job PBS
<PRE>
[pzaninelli@node47 ~]$ ps -ef | grep wrf.exe
1561 23401 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23402 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23403 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23404 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23405 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23406 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23407 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23408 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23409 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23410 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23411 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23412 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23413 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23414 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23415 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23416 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23417 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23418 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23419 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23420 23401 56 Apr09 ? 1-05:20:01 ./wrf.exe
1561 23421 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23422 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23423 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23424 23402 55 Apr09 ? 1-05:11:40 ./wrf.exe
1561 23425 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23426 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23427 23404 55 Apr09 ? 1-04:54:40 ./wrf.exe
1561 23428 23405 55 Apr09 ? 1-05:11:37 ./wrf.exe
1561 23429 23406 56 Apr09 ? 1-05:37:15 ./wrf.exe
1561 23430 23417 56 Apr09 ? 1-05:40:07 ./wrf.exe
1561 23431 23407 56 Apr09 ? 1-05:30:09 ./wrf.exe
1561 23432 23421 56 Apr09 ? 1-05:19:26 ./wrf.exe
1561 23433 23415 55 Apr09 ? 1-05:09:19 ./wrf.exe
1561 23434 23403 55 Apr09 ? 1-04:54:05 ./wrf.exe
1561 23435 23426 55 Apr09 ? 1-05:01:22 ./wrf.exe
1561 23436 23419 55 Apr09 ? 1-05:12:17 ./wrf.exe
1561 23437 23414 56 Apr09 ? 1-05:21:10 ./wrf.exe
1561 23438 23409 55 Apr09 ? 1-05:01:46 ./wrf.exe
1561 23439 23411 55 Apr09 ? 1-05:03:41 ./wrf.exe
1561 23440 23408 55 Apr09 ? 1-05:04:38 ./wrf.exe
1561 23441 23410 55 Apr09 ? 1-04:58:56 ./wrf.exe
1561 23442 23423 56 Apr09 ? 1-05:25:47 ./wrf.exe
1561 23443 23422 56 Apr09 ? 1-05:31:58 ./wrf.exe
1561 23444 23413 56 Apr09 ? 1-05:40:00 ./wrf.exe
1561 23445 23425 55 Apr09 ? 1-05:16:06 ./wrf.exe
1561 23446 23412 56 Apr09 ? 1-05:39:17 ./wrf.exe
1561 23447 23418 57 Apr09 ? 1-05:50:49 ./wrf.exe
1561 23448 23416 56 Apr09 ? 1-05:20:11 ./wrf.exe
1561 27524 27474 0 12:37 pts/0 00:00:00 grep wrf.exe
</PRE>
# Se repite el proceso en el resto de los nodos y se observa cómo los nodos reducen su carga de trabajo

[[File:GangliaAfterZombie.png|frame|50px|Ejemplo de descarga de los nodos 47, 50 y 53 después de matar un proceso 'zombie']]

procesos zombies

2018-12-07T18:16:44Z

Pzaninelli: /* script general */

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 <code>'home'</code> 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.

== script general ==
Hay una script the bash con la cuál se muestran los procesos <CODE>`wrf.exe'</CODE> de un usuario que están corriendo en todos los nodos del clúster
<PRE>
/share/tools/work-flows/components/bats/check_hydra.bash [user]
</PRE>
En donde <CODE>[user]</CODE> es el código numérico del usuarie (ej.: lluis.fita --> 1624)

{-
nombre |
numero -
pablo.zaninelli |
1561
-}

= Caso1: Pasos a seguir =
# Itendificar los procesos de la cola del sistema del usuario (ej. lluis.fita)
<pre>
$ 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
</pre>

# El proceso <code>4426</code> es una simulación de WRF.
<pre>
$ qstat -f 4426
Job Id: 4426.hydra
Job_Name = wrf_control
Job_Owner = lluis.fita@node48
resources_used.cput = 1700:00:37
resources_used.mem = 6264020kb
resources_used.vmem = 15322976kb
resources_used.walltime = 72:40:26
job_state = R
queue = larga
server = hydra
Checkpoint = u
ctime = Sat Apr 7 10:47:06 2018
depend = beforeany:4427.hydra@hydra
Error_Path = node48:/home/lluis.fita/estudios/WRFsensSFC/simulations/contr
ol/wrf_control.e4426
exec_host = node48/23+node48/22+node48/21+node48/20+node48/19+node48/18+no
de48/17+node48/16+node48/15+node48/14+node48/13+node48/12+node48/11+no
de48/10+node48/9+node48/8+node48/7+node48/6+node48/5+node48/4+node48/3
+node48/2+node48/1+node48/0+node51/23+node51/22+node51/21+node51/20+no
de51/19+node51/18+node51/17+node51/16+node51/15+node51/14+node51/13+no
de51/12+node51/11+node51/10+node51/9+node51/8+node51/7+node51/6+node51
/5+node51/4+node51/3+node51/2+node51/1+node51/0
exec_port = 15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15
003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+
15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+1500
3+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15003+15
003+15003+15003
Hold_Types = n
Join_Path = oe
Keep_Files = n
Mail_Points = ae
Mail_Users = lluis.fita@cima.fcen.uba.ar
mtime = Sat Apr 7 10:48:06 2018
Output_Path = node48:/home/lluis.fita/estudios/WRFsensSFC/simulations/cont
rol/wrf_control.o4426
Priority = 0
qtime = Sat Apr 7 10:47:06 2018
Rerunable = True
Resource_List.mem = 30gb
Resource_List.nodect = 2
Resource_List.nodes = 2:ppn=24
Resource_List.vmem = 30gb
Resource_List.walltime = 168:00:00
session_id = 19561
Variable_List = PBS_O_QUEUE=larga,PBS_O_HOST=node48,
PBS_O_HOME=/home/lluis.fita,PBS_O_LANG=en_US.UTF-8,
PBS_O_LOGNAME=lluis.fita,
PBS_O_PATH=/usr/local/bin:/opt/intel/composerxe-2011.3.174/bin/intel6
4:/usr/lib64/qt-3.3/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:
/usr/local/maui/bin:/usr/local/maui/sbin:/usr/local/bin:/opt/intel/com
poserxe/bin:/usr/local/maui/bin:/usr/local/maui/sbin:/home/lluis.fita/
bin:/opt/intel/composerxe-2011.3.174/mpirt/bin/intel64:/usr/local/maui
/bin:/usr/local/maui/sbin,PBS_O_MAIL=/var/spool/mail/lluis.fita,
PBS_O_SHELL=/bin/bash,PBS_SERVER=hydra,
PBS_O_WORKDIR=/home/lluis.fita/estudios/WRFsensSFC/simulations/contro
l
etime = Sat Apr 7 10:47:14 2018
submit_args = -W depend=afterany:4425 /home/lluis.fita/estudios/WRFsensSFC
/simulations/control/run_WRF.pbs
start_time = Sat Apr 7 10:47:14 2018
Walltime.Remaining = 343110
start_count = 1
fault_tolerant = False
submit_host = node48
init_work_dir = /home/lluis.fita/estudios/WRFsensSFC/simulations/control
</pre>
# La variable <code>PBS_O_WORKDIR</code> 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
<pre>
$ 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
</pre>
# 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 <CODE>exec_host</CODE>) node48 y node51.
<pre>
[lluis.fita@hydra ~]$ ssh node48
[lluis.fita@node48 ~]$ top
top - 11:35:40 up 5 days, 47 min, 0 users, load average: 23.00, 22.99, 23.03
Tasks: 246 total, 24 running, 198 sleeping, 0 stopped, 24 zombie
Cpu(s): 87.4%us, 8.4%sy, 0.0%ni, 4.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32942908k total, 18055956k used, 14886952k free, 3972k buffers
Swap: 0k total, 0k used, 0k free, 12102316k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21531 lluis.fi 20 0 508m 256m 28m R 100.0 0.8 4360:00 wrf.exe
21532 lluis.fi 20 0 503m 248m 23m R 100.0 0.8 4358:44 wrf.exe
21537 lluis.fi 20 0 503m 247m 23m R 100.0 0.8 4359:53 wrf.exe
21540 lluis.fi 20 0 507m 252m 23m R 100.0 0.8 4359:52 wrf.exe
21545 lluis.fi 20 0 503m 249m 24m R 100.0 0.8 4359:35 wrf.exe
21546 lluis.fi 20 0 503m 247m 22m R 100.0 0.8 4359:51 wrf.exe
21547 lluis.fi 20 0 507m 253m 23m R 100.0 0.8 4360:04 wrf.exe
21548 lluis.fi 20 0 507m 254m 24m R 100.0 0.8 4359:52 wrf.exe
21549 lluis.fi 20 0 495m 241m 23m R 100.0 0.7 4359:44 wrf.exe
21550 lluis.fi 20 0 507m 251m 23m R 100.0 0.8 4359:47 wrf.exe
21552 lluis.fi 20 0 501m 249m 27m R 100.0 0.8 4359:49 wrf.exe
21529 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:42 wrf.exe
21530 lluis.fi 20 0 500m 246m 25m R 99.7 0.8 4360:05 wrf.exe
21533 lluis.fi 20 0 507m 253m 23m R 99.7 0.8 4359:55 wrf.exe
21534 lluis.fi 20 0 507m 254m 24m R 99.7 0.8 4360:04 wrf.exe
21535 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:40 wrf.exe
21536 lluis.fi 20 0 503m 250m 24m R 99.7 0.8 4359:37 wrf.exe
21539 lluis.fi 20 0 507m 252m 24m R 99.7 0.8 4359:01 wrf.exe
21541 lluis.fi 20 0 503m 248m 23m R 99.7 0.8 4360:07 wrf.exe
21542 lluis.fi 20 0 500m 250m 27m R 99.7 0.8 4359:49 wrf.exe
21543 lluis.fi 20 0 500m 244m 23m R 99.7 0.8 4359:43 wrf.exe
21544 lluis.fi 20 0 507m 251m 23m R 99.7 0.8 4359:34 wrf.exe
21551 lluis.fi 20 0 507m 257m 27m R 99.7 0.8 4360:02 wrf.exe
[lluis.fita@node48 ~]$ killall wrf.exe
[lluis.fita@node48 ~]$ top
top - 11:37:32 up 5 days, 49 min, 0 users, load average: 19.46, 22.23, 22.79
Tasks: 199 total, 1 running, 197 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32942908k total, 12665572k used, 20277336k free, 3972k buffers
Swap: 0k total, 0k used, 0k free, 12048020k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10 root 20 0 0 0 0 S 0.3 0.0 39:27.92 kworker/0:1
262 root 20 0 0 0 0 S 0.3 0.0 0:18.40 kpktgend_13
272 root 20 0 0 0 0 S 0.3 0.0 0:18.47 kpktgend_23
27134 lluis.fi 20 0 15280 1256 888 R 0.3 0.0 0:00.01 top
1 root 20 0 25660 1736 1428 S 0.0 0.0 0:05.71 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:01.17 ksoftirqd/0
[lluis.fita@node48 ~]$ exit
</pre>
# Se repite el procedimiento en tantos nodos cómo ocupe el job (en este caso también <code>node51</code>)
<pre>
[lluis.fita@hydra ~]$ ssh node51
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ killall wrf.exe
[lluis.fita@node51 ~]$ top
[lluis.fita@node51 ~]$ exit
</pre>
# El job re-aparece cómo <code>cancelled</code> (letra <code>C</code>)
<pre>
[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
</pre>
# Si el job no fuera cancelado, se hace encesaria la cancelación manual
<pre>
$ qdel 4426
</pre>
# Otros jobs que estabn en la cola PBS, ahora ya se están ejecutándose al liberarse los nodos! Se observa en el [[http://scad.cima.fcen.uba.ar/ganglia/ ganglia]] del sistema cómo los nodos 48 y 51, se descargan de carga de cálculo

[[File:Ganglia_afterZombie.png|frame|50px|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 <CODE>pzaninelli</CODE>

# Mirar procesos corriendo
<pre>
[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
</pre>
# Determinar nodos y ruta de ejecución de todos los jobs del usuari.x.
<pre>
[pzaninelli@hydra ~]$ qstat -f 4432
Job Id: 4432.hydra
Job_Name = wrf_control50k
(...)
exec_host = node46/23+node46/22+node46/21+node46/20+node46/19+node46/18+no
de46/17+node46/16+node46/15+node46/14+node46/13+node46/12+node46/11+no
de46/10+node46/9+node46/8+node46/7+node46/6+node46/5+node46/4+node46/3
+node46/2+node46/1+node46/0+node47/23+node47/22+node47/21+node47/20+no
de47/19+node47/18+node47/17+node47/16+node47/15+node47/14+node47/13+no
de47/12+node47/11+node47/10+node47/9+node47/8+node47/7+node47/6+node47
/5+node47/4+node47/3+node47/2+node47/1+node47/0
(...)
PBS_O_WORKDIR=/home/pzaninelli/workdir/SENSHeatWave03/sims/control50k
(...)
[pzaninelli@hydra ~]$ qstat -f 4438
Job Id: 4438.hydra
(...)
exec_host = node49/23+node49/22+node49/21+node49/20+node49/19+node49/18+no
de49/17+node49/16+node49/15+node49/14+node49/13+node49/12+node49/11+no
de49/10+node49/9+node49/8+node49/7+node49/6+node49/5+node49/4+node49/3
+node49/2+node49/1+node49/0+node50/23+node50/22+node50/21+node50/20+no
de50/19+node50/18+node50/17+node50/16+node50/15+node50/14+node50/13+no
de50/12+node50/11+node50/10+node50/9+node50/8+node50/7+node50/6+node50
/5+node50/4+node50/3+node50/2+node50/1+node50/0
(...)
PBS_O_WORKDIR=/home/pzaninelli/workdir/SENSHeatWave03/sims/phy1
</pre>
# Se obtiene que:
* 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
<pre>
$ ssh [nombreNodo]
</pre>
## Chequear los procesos
### Si no se sabe el nombre de la aplicación que podría estar zombie
<pre>
ps -ef | grep $USER
</pre>
### Si se sabe el nombre de la aplicación (en el caso de ejemplo el modelo <code>WRF</Code>)
<pre>
ps -ef | grep [aplicación]
</pre>
### Parar esos procesos que no correspondan (huérfanos de job PBS)
<pre>
kill -9 [procesoID]
</pre>
### Salir del nodo y empezar con el siguiente
<pre>
exit
</pre>
# Después de mirar en los nodos del 40 al 46, entrando en el nodo 47
<pre>
[pzaninelli@hhydra ~]$ ssh node47
[pzaninelli@node47 ~]$ ps -ef | grep wrf.exe
1561 17995 1 74 Apr07 ? 3-00:53:43 ./wrf.exe
1561 17996 1 74 Apr07 ? 3-00:53:36 ./wrf.exe
1561 17997 1 74 Apr07 ? 3-00:49:04 ./wrf.exe
1561 17998 1 74 Apr07 ? 3-00:53:03 ./wrf.exe
1561 17999 1 74 Apr07 ? 3-00:57:12 ./wrf.exe
1561 18000 1 74 Apr07 ? 3-00:47:14 ./wrf.exe
1561 18001 1 74 Apr07 ? 3-00:50:55 ./wrf.exe
1561 18002 1 74 Apr07 ? 3-00:51:08 ./wrf.exe
1561 18003 1 74 Apr07 ? 3-00:53:33 ./wrf.exe
1561 18005 1 74 Apr07 ? 3-00:56:54 ./wrf.exe
1561 18006 1 74 Apr07 ? 3-00:49:51 ./wrf.exe
1561 18007 1 74 Apr07 ? 3-00:51:28 ./wrf.exe
1561 18008 1 74 Apr07 ? 3-00:53:13 ./wrf.exe
1561 18009 1 74 Apr07 ? 3-00:49:40 ./wrf.exe
1561 18010 1 74 Apr07 ? 3-00:52:07 ./wrf.exe
1561 18011 1 74 Apr07 ? 3-00:52:12 ./wrf.exe
1561 18012 1 74 Apr07 ? 3-00:54:05 ./wrf.exe
1561 18013 1 74 Apr07 ? 3-00:52:44 ./wrf.exe
1561 18014 1 74 Apr07 ? 3-00:49:45 ./wrf.exe
1561 18015 1 74 Apr07 ? 3-00:48:31 ./wrf.exe
1561 23401 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23402 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23403 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23404 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23405 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23406 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23407 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23408 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23409 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23410 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23411 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23412 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23413 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23414 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23415 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23416 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23417 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23418 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23419 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23420 23401 56 Apr09 ? 1-05:16:12 ./wrf.exe
1561 23421 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23422 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23423 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23424 23402 55 Apr09 ? 1-05:07:45 ./wrf.exe
1561 23425 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23426 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23427 23404 55 Apr09 ? 1-04:50:56 ./wrf.exe
1561 23428 23405 55 Apr09 ? 1-05:07:46 ./wrf.exe
1561 23429 23406 56 Apr09 ? 1-05:33:20 ./wrf.exe
1561 23430 23417 56 Apr09 ? 1-05:35:49 ./wrf.exe
1561 23431 23407 56 Apr09 ? 1-05:26:10 ./wrf.exe
1561 23432 23421 56 Apr09 ? 1-05:15:46 ./wrf.exe
1561 23433 23415 55 Apr09 ? 1-05:05:37 ./wrf.exe
1561 23434 23403 55 Apr09 ? 1-04:50:07 ./wrf.exe
1561 23435 23426 55 Apr09 ? 1-04:57:29 ./wrf.exe
1561 23436 23419 55 Apr09 ? 1-05:08:26 ./wrf.exe
1561 23437 23414 56 Apr09 ? 1-05:17:23 ./wrf.exe
1561 23438 23409 55 Apr09 ? 1-04:57:51 ./wrf.exe
1561 23439 23411 55 Apr09 ? 1-04:59:43 ./wrf.exe
1561 23440 23408 55 Apr09 ? 1-05:00:49 ./wrf.exe
1561 23441 23410 55 Apr09 ? 1-04:55:14 ./wrf.exe
1561 23442 23423 56 Apr09 ? 1-05:21:52 ./wrf.exe
1561 23443 23422 56 Apr09 ? 1-05:28:01 ./wrf.exe
1561 23444 23413 56 Apr09 ? 1-05:36:03 ./wrf.exe
1561 23445 23425 55 Apr09 ? 1-05:12:05 ./wrf.exe
1561 23446 23412 56 Apr09 ? 1-05:35:22 ./wrf.exe
1561 23447 23418 57 Apr09 ? 1-05:46:58 ./wrf.exe
1561 23448 23416 56 Apr09 ? 1-05:16:21 ./wrf.exe
1561 27514 27474 0 12:30 pts/0 00:00:00 grep wrf.exe
</pre>
# 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
<PRE>
[pzaninelli@node47 ~]$ pwdx 17995
17995: /home/pzaninelli/workdir/SENSHeatWave03/sims/phy1/run

[pzaninelli@node47 ~]$ pwdx 23427
23427: /home/pzaninelli/workdir/SENSHeatWave03/sims/control50k/run
</PRE>
# Del análisi anterior el nodo 47 sólo hospeda el job PBS <code>4432</code> que se ejecuta en <code>/home/pzaninelli/workdir/SENSHeatWave03/sims/control50k</code>. Así que los procesos del grupo (Ids de 17995 a 18015) que se ejecutan en <code>/home/pzaninelli/workdir/SENSHeatWave03/sims/phy1/run</code> son zombies. Así que ya se pueden eliminar
<PRE>
[pzaninelli@node47 ~]$ kill -9 $(seq 17995 18015)
</PRE>
# Ahora al buscar los procesos aprecen sólo los procesos dependiendo del job PBS
<PRE>
[pzaninelli@node47 ~]$ ps -ef | grep wrf.exe
1561 23401 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23402 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23403 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23404 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23405 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23406 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23407 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23408 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23409 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23410 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23411 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23412 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23413 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23414 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23415 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23416 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23417 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23418 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23419 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23420 23401 56 Apr09 ? 1-05:20:01 ./wrf.exe
1561 23421 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23422 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23423 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23424 23402 55 Apr09 ? 1-05:11:40 ./wrf.exe
1561 23425 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23426 23390 0 Apr09 ? 00:00:00 /bin/bash ./launch_pbs.bash ./wrf.exe
1561 23427 23404 55 Apr09 ? 1-04:54:40 ./wrf.exe
1561 23428 23405 55 Apr09 ? 1-05:11:37 ./wrf.exe
1561 23429 23406 56 Apr09 ? 1-05:37:15 ./wrf.exe
1561 23430 23417 56 Apr09 ? 1-05:40:07 ./wrf.exe
1561 23431 23407 56 Apr09 ? 1-05:30:09 ./wrf.exe
1561 23432 23421 56 Apr09 ? 1-05:19:26 ./wrf.exe
1561 23433 23415 55 Apr09 ? 1-05:09:19 ./wrf.exe
1561 23434 23403 55 Apr09 ? 1-04:54:05 ./wrf.exe
1561 23435 23426 55 Apr09 ? 1-05:01:22 ./wrf.exe
1561 23436 23419 55 Apr09 ? 1-05:12:17 ./wrf.exe
1561 23437 23414 56 Apr09 ? 1-05:21:10 ./wrf.exe
1561 23438 23409 55 Apr09 ? 1-05:01:46 ./wrf.exe
1561 23439 23411 55 Apr09 ? 1-05:03:41 ./wrf.exe
1561 23440 23408 55 Apr09 ? 1-05:04:38 ./wrf.exe
1561 23441 23410 55 Apr09 ? 1-04:58:56 ./wrf.exe
1561 23442 23423 56 Apr09 ? 1-05:25:47 ./wrf.exe
1561 23443 23422 56 Apr09 ? 1-05:31:58 ./wrf.exe
1561 23444 23413 56 Apr09 ? 1-05:40:00 ./wrf.exe
1561 23445 23425 55 Apr09 ? 1-05:16:06 ./wrf.exe
1561 23446 23412 56 Apr09 ? 1-05:39:17 ./wrf.exe
1561 23447 23418 57 Apr09 ? 1-05:50:49 ./wrf.exe
1561 23448 23416 56 Apr09 ? 1-05:20:11 ./wrf.exe
1561 27524 27474 0 12:37 pts/0 00:00:00 grep wrf.exe
</PRE>
# Se repite el proceso en el resto de los nodos y se observa cómo los nodos reducen su carga de trabajo

[[File:GangliaAfterZombie.png|frame|50px|Ejemplo de descarga de los nodos 47, 50 y 53 después de matar un proceso 'zombie']]