|
HP OpenVMS Systemsask the wizard |
|
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.
|