[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IDD #ZQD-728782]: [ldm-users] LDM tries to take Saturday off...
- Subject: [IDD #ZQD-728782]: [ldm-users] LDM tries to take Saturday off...
- Date: Tue, 14 Oct 2014 12:23:37 -0600
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