 |
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
following:
WSQUOTA 16384
WSEXTENT 16384
PGFLQUOTA 32768
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
documentation.
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.
|
|
|
|
|
