VMSSupport,
All I'm saying is that I don't believe the issues with the cited Cerner site lies with HBVS. I believe their problem is with their HSG80s, VMS I/O tuning and the ability of VMS to overrun the HSG80's I/O request queue.
I recieved a copy of the following from our FE earlier this year. You should also read the release notes for HSG80 ACS v8.8-2 and the sited VMS 8.2 documentaion below that also applies to VMS 7.3-n.
Greetings,
Recent testing with both EVA and XP arrays indicates OpenVMS must be
tuned to optimize both the host and array performance. In particular,
OpenVMS hosts should reduce the number of asynchronous, concurrent I/Os
per process when accessing SAN storage arrays with an intelligent cache.
This applies to both EVA storage arrays and XP disk arrays.
This recommendation opposes recommendations OpenVMS engineering
previously provided. OpenVMS engineering suggested setting DIOLM to
4,096 or higher for the backup account. For OpenVMS VAX systems, this
helped reduce processing overhead.
With the advent of AlphaServer and Itanium based systems, the CPU
architecture minimizes this overhead. In fact, these high DIOLM values
adversely impact performance of SAN storage arrays with cache
subsystems, which predicts I/O activity. This is especially true during
large sequential read streams, where the array attempts to prefetch data
to satisfy the large read stream.
Even with CI based storage arrays, larger AlphaServer systems with large
DIOLM values cause problems with normal SCS communications. Dropping
DIOLM reduces errors in CI environments as well as with SAN storage.
Here are the symptoms of high DIOLM values:
* on HSJs high DIOLM values cause virtual circuit timeouts to the
controllers
* on HSGs high DIOLM values cause the HSG80 to hang / crash
* on EVAs high DIOLM values causes very high Read Hit rates to
VDisks
* on XPs high DIOLM values causes very poor I/O throughput
On both the EVA and XP arrays, a high DIOLM value causes the cache
management firmware to 'thrash'. That is, the firmware can not
effectively utilize cache for what should be a few large sequential
reads. Decreasing DIOLM allows these arrays to more effectively
prefetch data for these large sequential reads. Dropping DIOLM
dramatically improves array performance.
To address this issue, OpenVMS engineering changed the documented
recommendations for DIOLM and Working Set Sizes in the V8.2
documentation set. The documentation now recommends setting DIOLM to
100. When accessing XP disk arrays, experience shows DIOLM at 4 to 8
provides ideal performance. Some testing may be required to determine
the best value. However, with XP disk arrays use 100 as the top value
for DIOLM. Also note that WSQUOTA and WSEXTENT contribute heavily to
the performance of OpenVMS BACKUP.
PQL_MDIOLM must also be decreased, since it sets a system wide minimum
value for DIOLM. Systems that use DECwindows and/or Motif may need to
dynamically change PQL_MDIOLM during backup operations.
New tuning values for OpenVMS BACKUP can now be found at:
http://h71000.www7.hp.com/doc/82FINAL/aa-pv5mj-tk/00/01/117-con.htmlThis URL points to section 11.7, titled "Setting Software Parameters for
Efficient Backups". This is in the "HP OpenVMS System Manager's
Manual, Volume 1: Essentials" manual.
While this email focuses on OpenVMS BACKUP, recent experiences
demonstrate this may be an issue with other products, such as the HP
Disk File Optimizer for OpenVMS.
Regards,
=jbf=
John B. Fisher
OpenVMS/Storage Complex Problem Manager
Global Complex Solutions Management, GSE
Hewlett-Packard Company
Bill Hall
