[LDM #OGU-667706]: vetQueueSize()

Hi Clint,

Would you please send me the output of the following command, executed by the 
LDM user:

    grep -i '^request' /home/ldm/etc/pqact.conf

Are you logging metrics as outlined at 
<http://www.unidata.ucar.edu/software/ldm/ldm-current/basics/monitoring.html#metrics>?
 If so, would you please send me screenshots from the following command, 
executed by the LDM user:

    ldmadmin plotmetrics -b 20151001

Alternatively, add the entries in the attached file to the LDM user's 
"~/.ssh/authorized_keys" file and I'll look at your setup myself:

> Hi Steve (probably),
> 
> I just installed LDM (6.12.14) on a new server and am getting a message that 
> I have never seen before.
> vetQueueSize(): The maximum acceptable latency (registry parameter
> "/server/max-latency": 3600 seconds) is greater than the observed minimum
> virtual residence time of data-products in the queue (247 seconds).
> This will hinder detection of duplicate data-products.
> vetQueueSize(): The queue should be 83308854029 bytes in size with
> 2301904 slots or the maximum-latency parameter should be decreased to
> 247 seconds. You should set registry-parameter "/reconciliation-mode"
> to "increase queue" or "decrease maximum latency" or manually adjust
> the relevant registry parameters and recreate the queue.
> 
> So, I checked the support archives and found a year-old reply from you about 
> this with regard to duplicate products.  I haven't checked to see if we're 
> actually getting duplicate products (it's only been running since yesterday), 
> but I'm wondering how to tune this (or whther to ignore it), since two 
> parameters seem to be involved.  Here are the current (mostly default) 
> registry settings:
> [ldm@squall ~]$ regutil
> /delete-info-files : 0
> /hostname : squall.unl.edu
> /insertion-check-interval : 300
> /reconciliation-mode : do nothing
> /check-time/enabled : 1
> /check-time/limit : 10
> /check-time/warn-if-disabled : 1
> /check-time/ntpdate/command : /usr/sbin/ntpdate
> /check-time/ntpdate/servers : ntp.ucsd.edu ntp1.cs.wisc.edu ntppub.tamu.edu 
> otc1.psu.edu timeserver.unidata.ucar.edu
> /check-time/ntpdate/timeout : 5
> /metrics/count : 4
> /metrics/file : /mnt/ssd0/var/logs/metrics.txt
> /metrics/files : /mnt/ssd0/var/logs/metrics.txt*
> /metrics/netstat-command : /bin/netstat -A inet -t -n
> /metrics/top-command : /usr/bin/top -b -n 1
> /log/count : 7
> /log/file : /mnt/ssd0/var/logs/ldmd.log
> /log/rotate : 1
> /pqsurf/config-path : /home/ldm/etc/pqsurf.conf
> /pqsurf/datadir-path : /mnt/ssd0/var/data
> /scour/config-path : /home/ldm/etc/scour.conf
> /surf-queue/path : /mnt/ssd0/var/queues/pqsurf.pq
> /surf-queue/size : 2M
> /server/config-path : /home/ldm/etc/ldmd.conf
> /server/enable-anti-DOS : TRUE
> /server/ip-addr : 0.0.0.0
> /server/max-clients : 256
> /server/max-latency : 3600
> /server/port : 388
> /server/time-offset : 3600
> /queue/path : /mnt/ssd0/var/queues/ldm.pq
> /queue/size : 8G
> /queue/slots : default
> /pqact/config-path : /home/ldm/etc/pqact.conf
> /pqact/datadir-path : /mnt/ssd0/var
> [ldm@squall ~]$
> 
> This machine is not relaying to any downstream sites (although it might in 
> the future) and is, as you can see, using an SSD for both the product queue 
> and the ingested data.  Increasing the queue size to over 80Gb seems 
> excessive, but reducing the max latency to about 4 minutes seems pretty 
> short.  Any suggestions?
> 
> Thanks,
> Clint
> 
> ====================================================================
> Clinton M. Rowe
> Professor and Graduate Chair                     phone:(402)472-1946
> Earth & Atmospheric Sciences                       fax:(402)472-4917
> University of Nebraska- Lincoln                       
> address@hidden<mailto:address@hidden>


Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: OGU-667706
Department: Support LDM
Priority: Normal
Status: Closed

Attachment: authorized_keys
Description: Binary data