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

[LDM #BLL-845073]: ldm questions

Paul,

> I am working on the LDM for RAL at NCAR.  We have several questions that we 
> hope
> you can help with.
> 
> 1) We were trying to capture the results of 'ldmadmin watch' and make it
> available on our internal webserver, so that our downstream clients can
> see exactly what we is passing through our 'gateway' ldm.  We are using
> 'pqutil -r -w /home/ldm/data/ldm.pq' to do this, but notice that it
> often shows 90%+ cput utilization (via top).  Do you have any recommendations
> for a more efficient way to capture this information?

The pqutil(1) utility is, actually, an interactive program: it's designed
to expect user-supplied input; consequently, it can consume a lot of CPU
when used in a non-interactive setting.

I suggest using the notifyme(1) utility, instead.

> 2)  We have noticed that sometimes we end up with log files owned by root,
> and also some log files that are zipped, or have a .0 extension.  As far as
> I know we always run the ldm under the ldm user (although we are using
> a script /etc/init.d/ldm to automatically start the ldm when the machines
> boot up).  Do you have any suggestions for how root is becoming the owner
> of these logs?

I would check the boot-time start-up script for the LDM to ensure that
the root user is becoming the LDM user before executing the "ldmadmin
start" command.

  For security reasons which I don't understand, our system
> admins, do not like to have hupsyslog in ~ldm/bin.  Instead hupsyslog in
> ~ldm/bin is a symbolic link to /opt/bin/hupsyslog.  The link is owned
> by ldm, but /opt/bin/hupsyslog is owned by root with an ldm group.
> Could this be the problem?

The hupsyslog(1) utlity only sends a SIGHUP to the syslog(8) daemon: it
doesn't do anything with the LDM log files; consequently, it can't be
responsible for root owning those files.

> 2b) We've noticed that pqact & pqsurf logs don't seem to rotate correctly.
> When we run ldmadmin newlog a new log is created, and the numbers rotate,
> but the now the .1 file is being written to.  The new log file just stays
> at zero size.  Is this just the manner in which pqact/pqsurf work (i.e.
> not releasing their file handle each time they write), or is there something
> we are doing wrong?

The pqact(1) and pqsurf(1) programs are started by EXEC entries in the
LDM configuration-file.  I suspect that those entries are explicitly
specifying what log file to use -- via the "-l" option -- instead of 
using the default (logging to the LDM log file).  If so, then just
remove the use of that option from the EXEC entries.

> 3)  Did you do any load testing on your LDM cluster?  We would like to
> do some testing before we make ours available to the rest of RAL.  We 
> remembered
> the Unidata classroom, and were wondering if it would be possible to configure
> those machines to all try to request everything from our LDM cluster, to
> see what our load looks like under those conditions.

Intriguing idea!  I'll let you know.

> Thanks,
> Paul & Gary

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: BLL-845073
Department: Support LDM
Priority: Normal
Status: Closed