HP OpenVMS Systems

ask the wizard
Content starts here

Performance Tuning, BACKUP, and DECnet?

» close window

The Question is:

It seems we are getting a number of decnet event 4.18 Adjacency down when we
 begin certain backups.  These are at a time when the system is not busy (VAX
 4106 64megs RAM, TZ87 DLT IV SCSI tape drive.)  Backup account has the
WSQUOTA  16384
FILLM  128
DIOLM  4096
ASTLM  4096
BIOLM  128
BYTLM  65536
ENQLM  256
The system and network are fine and dandy all through the day but almost the
 instant we begin one of our nightly backups we begin to get a flury of decnet
 events.  We have multiple HSD10s with SCSI Bus Adapters, the 4106 is part of a
 two node cluster with
 a Vax4505 and the above mentioned DLT drive is hanging off the Scsi port on
 the VAX 4106.  The decnet events do not always occur.  The question is simply
 where else can we look for the cause of this after having insured network
 connectivity is not the is
sue?  Is the DLT IV dirve perhaps ging VMS backup issues?  We have noticed
 errors on devices on the VAX not causing the decnetevents after they occur.
Error Count
PAB0:                                    2
PAA0:                                    3
PEA0:                                    2
Is this a matter of some sysgen paramaters?
Hoping this isn't to vauge.
Thank you

The Answer is :

  The recommended BACKUP process quotas are listed in the current OpenVMS
  This could be a process quota error, or (more likely) this is a network
  congestion or system parameter error.
  As a first step, the OpenVMS Wizard would clean out MODPARAMS.DAT of
  any absolete settings (when ADD_ or MIN_ or MAX_ variants are
  available), and the OpenVMS Wizard would also remove any entries
  for products or versions no longer relevent), and AUTOGEN the system
  with FEEDBACK.
  Of central interest would be the DECnet counters -- see the OpenVMS
  FAQ for how to zero these values on recent OpenVMS versions.  You
  will probably find retransmission and back-off (retransmission) errors
  reported by the DECnet counters.  Assuming DECnet Phase IV, you can use
  the NCP command SHOW KNOWN LINE COUNTERS to see the current values of
  the DECnet communications lines.  Also assuming DECnet Phase IV, the
  NCP command ZERO KNOWN LINE COUNTERS will clear the counters.
  You may also find that the particular device(s) targeted by the
  BACKUP are central to OpenVMS system or DECnet operations, and that
  the BACKUP is saturating the I/O capabilities of these devices.
  MONITOR DISK/ITEM=QUEUE_LENGTH can be used to determine I/O rates,
  and any values above 0.5 effectively indicate I/O saturation; that
  half of all I/O operations to the disk are waiting.  This can point
  to I/O loading, or to insufficient physical memory for I/O caching,
  or severely fragmented disks, poorly-tuned or internally-fragmented
  RMS (indexed) files, or other related I/O problems.
  You might also find that there is bus contention -- your VAX
  systems are comparatively old, and your I/O buses correspondingly
  slow.  Newer DLT tapes are particularly good at driving the SCSI
  bus quickly, and you might be encountering bus-level contention
  on other devices sharing the same SCSI.  The obvious approach
  here involves additional or (better) additional faster) buses.
  Please see the Performance manual in the OpenVMS documentation set.
  This manual has information on a systematic performance investigation.
  Also potentially of interest will be disk defragmentation and RMS
  indexed file conversion (and/or RMS file tuning).  Also potentially
  the addition of physical memory.  The performance manual should help
  you identify the system bottleneck(s) you are encountering here.

answer written or last revised on ( 24-FEB-2003 )

» close window