[IDD #ZQD-728782]: [ldm-users] LDM tries to take Saturday off...

Hi Phil,

re:
> Thank you - I still haven’t yet had a chance to really dig into the issue, 
> but I’m
> attaching a link to a tarball of our ldmd.conf and our log files (if you’d 
> prefer that I
> attach it, just let me know).

I didn't see anything that jumped out as me as being problematic in the various
files included in the compressed tarball you provided.  I did note, however,
that the pattern-action files referenced in the /home/ldm/etc/ldmd.conf file
were not included in the compressed tarball:

#EXEC   "pqact"
exec    "pqact -f ANY-NNEXRAD-CRAFT-NIMAGE etc/pqact.gempak_decoders"
exec    "pqact -f WMO etc/pqact.gempak_nwx" 
exec    "pqact -f MCIDAS|NIMAGE etc/pqact.gempak_images"
exec    "pqact -f NNEXRAD|WSI|FNEXRAD|EXP etc/pqact.gempak_nexrad"
exec    "pqact -f CRAFT etc/pqact.gempak_craft"

Can you provide these files?

re:
> I’m still convinced that something is eating system
> resources on Saturday morning, but I haven’t been able to track it down of 
> yet.

A couple of things would be useful:

- the LDM registry file:

  ~ldm/etc/registry.xml

- listing of all processes running in 'ldm's cron

  This may tell us if 'ldm'-initiated processes are part of the problem
  you are experiencing.

- the output from 'ldmadmin config'

- some information on the machine you are using:

  - output of 'uname -a'

  - output of 'cat /proc/cpuinfo' and 'cat /proc/meminfo'

  - output of 'df -h'

  - output of 'mount'

- a long list of your GEMPAK log file directory

  The typical setups for GEMPAK output are either:

  ~ldm/data/gempak

  OR

  ~ldm/var/data/gempak

  Exactly where your GEMPAK output directory can be found is a function
  of how your LDM is setup in the ~ldm/etc/registry.xml file and how
  the actions are defined in the GEMPAK pattern-action files.  Again,
  your tarball did not include any of these files.

  What I am really looking for is a long list of the GEMPAK logs directory.
  Please see below for further comment...

re:
> ldmd.log.1 was Sunday
> ldmd.log.2-6 were from Saturday,
> ldmd.log.7 was Friday
> 
> http://twister.sbs.ohio-state.edu/unidata/ldmd-2014-10-13-1252.tar.gz

I did not see anything untoward in your LDM log files.

re:
> I’ll try to take a closer look at everything this afternoon and implement 
> some of the
> suggestions that others provided to see if I can resolve the issue.

One thing I have found on numerous user systems is the failure to rotate GEMPAK
decoder log files.  The net result of this especially on 64-bit systems is HUGE
decoder log files.  Cleaning them up (i.e., properly rotating them) has solved
performance problems on more than one users's machines.

re:
> Thanks again!

No worries.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: ZQD-728782
Department: Support IDD
Priority: Normal
Status: Closed