Nut upsuser - Feb 2006 - UPSD slow in responding

Hi,

We are having a performance issue with UPSD.  

OUR ENVIRONMENT
--------------------------
We are using a custom script on a SUN V240 server running Solaris 8.  The script
employs UPSC to interrogate UPSD.  UPSD is configured (using upsdrvctl)  to talk
to two MGE Galaxy 3000 UPS's via the MGE-SNMP ups driver.

Our problem is this.  When the server runs the backup processes it becomes
loaded.  During this time UPSC takes up to 30 seconds to return with an answer
from UPSD regarding the status of each UPS.  Since we have two UPS's the
combined interrogation time can blow out to 75 seconds.

Is there any way we can speed up this interrogation time or, at least, determine
where the performance issue lies (i.e. with UPSD or UPSC)?

Thanks for your assistance 


Damon Pullen
DIER - Tasmania

On 2/7/06, Damon Pullen <Damon.Pullen@dier.tas.gov.au>
wrote:
> Our problem is this.  When the server runs the backup processes it becomes
loaded.
Is this a network backup, or local (to a tape drive, or something similar)?
>  During this time UPSC takes up to 30 seconds to return with an answer from
UPSD regarding the status of each UPS.  Since we have two UPS's the combined
interrogation time can blow out to 75 seconds.
>
> Is there any way we can speed up this interrogation time or, at least,
determine where the performance issue lies (i.e. with UPSD or UPSC)?
You could use tcpdump (or the Solaris equivalent; I seem to remember
using another program for packet capture) along with strace or truss
to pinpoint the problem. Together, these tools will let you see when
the packets are sent from upsc to upsd.

You will probably want to use a capture filter with tcpdump (monitor
TCP port 3493 and UDP port 161), and use the '-t' option of strace to
get the time of each system call.

One possibility is that your network transmit queues are too deep, and
the packets are sitting in a buffer for a while as the backup traffic
is sent. Or, if it is local disk I/O, you may have to lower the
priority of the backup process (since most OSes, by default, do not
schedule disk I/O with priorities that account for the system-specific
delay in waiting for disk reads and writes).

--
- Charles Lepple