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

[LDM #EZP-106031]: ldm not working properly after OS updates

Hi Sen,

re:
> I have been bothered by this issue for some time.  We have the sever
> patched (titan.met.sjsu.edu). after that, some of the model data are coming
> anymore including all GFS suits.
> Any suggestions?

When we looked at how titan was configured previously, we developed
two conclusions which I though we had relayed to you:

1) first, titan seemed to be suitably equipped to be able to handle
   all of the IDD data that it had/has REQUESTs for

   We noted that the LDM queue size on titan needed to be made
   a lot larger to cut down on "second trip" receipts of data. The
   problem with increasing the LDM queue size as that titan did not
   have enough memory... I recall that titan had 20 GB of RAM, so
   I could only increase the LDM queue to 12 GB and still leave enough
   RAM for the various processing that it was doing.

   I seem to recall that we recommended increasing the memory to as
   much as possible (whatever the machine will accept), but this should
   be more than 64 GB so that the queue size can be increased to 
   at least 32 GB.

2) the last time I looked, it seemed like there was some issues with
   latencies for the feeds being REQUESTed

   A quick look at the real-time stats latencies titan is reporting
   shows that, for instance, the latency for CONDUIT is low - a
   good thing.

3) I believe that you used to be REQUESTing the GOES-16/17 GRB
   imagery and products in the SATELLITE feed (which is known as
   DIFAX in older LDM versions).  Since I don't see that feed
   being reported in real-time stats from titan, I'll assume that
   you removed the feed REQUEST

So, the questions are:

- has more memory been installed in titan?

  If yes, how much does it have now?

- is the LDM queue size the same as it was the last time we were
  logged in?

  At that time, it was 12 GB.

- does your LDM log file have indications that look like "processed oldest
  product"?

  These indicate that the products are not getting processed before they
  are at the end of the queue, and this, in turn, is a strong indication
  that products are being scoured out of the queue before they are
  acted on by LDM pattern-action file actions.

Is the access to your machine the same as it used to be?  If yes, and if
I can find the login information, I will try to logon and poke around.

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: EZP-106031
Department: Support LDM
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.