[LDM #MDC-227212]: LDM Compile Error

Hi,

re:
> I misspoke.  Our legacy VM has about the same number processes; same physical 
> host
> and same resource allocation on the new server but running RHEL7 instead of 
> RHEL5.

It is not surprising that the overhead in RHEL7 is significantly greater
than it is in RHEL5.  The efficiency of the LDM has not changed, at least,
measurably, so the change in the underlying OS is likely the cause of the
performance difference that you have noted.

re:
> When we start LDM on the new server it is only successful after rebooting the 
> system
> and started manually.  We do not yet have LDM starting at boot time so all LDM
> related processes are gone when performing an initial "ldmadmin start".  
> After that
> executes, "ldmadmin watch" works (for example) but if we try to "ldmadmin 
> stop" it
> hangs and the processes persist.  They can be killed one at a time but 
> killing the
> parent process nor deleting the lock files cascades to all the child 
> processes.

If the characteristics of the VM can not be changed (meaning more vCPUs,
more RAM, etc.), then reorganization of the 66 REQUESTs in your LDM
configuration file, ~ldm/etc/ldmd.conf, is the next thing to try.

Since we note that you redacted the names/ip addresses of the upstream
server(s) that you are REQUESTing feeds from, the following will need to
be general in nature...

If multiple of what looks like the same kind of product are being REQUESTed
from the same upstream host, you can/should combine them into smaller numbers
of REQUESTs.  For instance:

a) assume that the following REQUESTs are all being made to the same
   upstream:

request EXP     "LRL_SHEF"      x.x.x.x
request EXP     "LRH_SHEF"      x.x.x.x
request EXP     "LRN_SHEF"      x.x.x.x
request EXP     "LRP_SHEF"      x.x.x.x
request EXP     "LRB_SHEF"      x.x.x.x
request EXP     "LRD_SHEF"      x.x.x.x
request EXP     "LRD_SHEF"      x.x.x.x
request EXP     "MVP_SHEF"      x.x.x.x

  In this case, these 8 REQUESTs could be simplified into a
  single REQUEST:

REQUEST EXP "(LR[BDHLNP]|MVP)_SHEF"   x.x.x.x

  Aside: one of the REQUESTs in this list is a duplicate of
  another:

request EXP     "LRD_SHEF"      x.x.x.x
request EXP     "LRD_SHEF"      x.x.x.x

b) the same kind of thing as in a) can be done for most of the
   REQUEST lines in your LDM configuration file if, of course,
   the name/IP address of the upstream the REQUEST is being made
   to is the same

Again, without knowing the specifics of the upstream machine(s) the
REQUESTs are being made to, it is impossible for us to give you
specifics on how the REQUESTs can be reorganized to a fewer number.
If you redacted the names/ip addresses to have identifiable names/ip
addresses, we could give you a better guidance on what we think
needs to be done.  What I mean by this is: replace 'x.x.x.x' with
abc.def.ghi.jkl for upstream machine 1, bcd.efg.hij.klm for
machine 2, etc.

Also, we can _not_ make our ongoing exchanges public if you
would like.  This way, the actual names/ip addresses of the
machines you are REQUESTing from would stay private in our
inquiry tracking system.

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: MDC-227212
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.