[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000804: LDM problems at stc

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20000804: LDM problems at stc
  • Date: Mon, 07 Aug 2000 11:42:06 -0600
>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 200008041916.e74JG1T26054 LDM disk usage

Alan,

>Have a problem on our ldm - data ingest machine (waldo).  I was out of town
>late last week until this past Wed.  When I checked waldo on Wed., the disk
>was full and (7.9 GB).  It normally runs about half full, and that was how 
>it was when I left the previous week.  
>
>I stopped the ldm and restarted it.  The disk space used immediately dropped
>to about 40 %.

It would be a good idea to try and see if you could find one or more files
that was using up your disk space.

For reference, what version of the LDM are you running, and is it a binary
distribution, or one you built there?

>Everything seemed to be working ok, the ldm logs showed 
>nothing unusual so I let it go.

OK, but given that this happened again (comments below), we need to find
out what is using the disk space.

>Today, I again found the disk full.  Again I stopped the ldm, and noticed that
>the disk use again dropped way back.  Restarted ldm and again logs ok.

What about today (Monday, August 7)?

>Today, 
>our feedsite at sunset.meteor.wisc.edu is apparently down, but that is just
>a temporary issue on their side.
>
>I looked in our data directory, /var/data/mcidas, and file sizes seem ok.
>Largest are a couple of files  DD002160.XCD  and DD002150.XCD at about 250 MB.

The .XCD files are pretty big anymore.  Here are some representative numbers
for ones on a system we control:

/data/ldm/mcidas% dir *.XCD
    641107 -rw-rw-r--   1 ustaff   219249360 Aug  4 13:55 DD002170.XCD
    640984 -rw-rw-r--   1 ustaff   268909760 Aug  3 17:59 DD002160.XCD
    640920 -rw-rw-r--   1 ustaff   270230800 Aug  2 17:59 DD002150.XCD
    641430 -rw-rw-r--   1 ustaff   273390160 Aug  1 17:59 DD002140.XCD
    640978 -rw-rw-r--   1 ustaff   268478240 Jul 31 17:59 DD002130.XCD
    640821 -rw-rw-r--   1 ustaff   291589600 Jul 30 17:59 DD002120.XCD

So, you can see that 250 MB is in the right ballpark.

>I know we need to upgrade our ldm to allow for the new imagery compression, 

You need to upgrade ldm-mcidas decoders, not (necessarily) your LDM.

>but did not expect this to have caused our disk problem.

It shouldn't have.  For reference, can you clip out and send in the
ldmd.conf request line(s) for MCIDAS (actually, send all you have) and
the pqact.conf entry for LWTOA3 decoding of images?  Thanks

>Have left the
>ldm stopped for now as I will be gone over the weekend.  
>Be back in office on Tuesday.

OK, so not until tomorrow.  If I can remember the 'ldm' login to waldo
I will get on and try some troubleshooting.

>Any ideas as to why our disk should fill up,

Nope, sorry.

>and what seems more puzzling to 
>me is why the use drops way down when I stop the ldm.  I did not delete any
>files.

I have to believe that the problem somehow lies in system logging and/or
something related to the LDM queue.

>The machine is waldo, who you have met before.  

Yes, but I have to see if I can remember the login.

Tom