| Title: | HSZ40 Product Conference |
| Moderator: | SSDEVO::EDMONDS |
| Created: | Mon Apr 11 1994 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 902 |
| Total number of notes: | 3319 |
I'm working a hot performance issue with a customer. They're running progress on a 4100, DU4.0b, and an HSZ50 hanging off of a KZPSA. They're trying to do a database create and it's taking them twice as long as the original benchmarks did. At first I thought it might be an advfs issue, but the results of advfsstat showed that advfs wasn't even breaking a sweat. I then went out to the HSZ50, took one of the disks out of theur spareset, created a jbod and made the device files for it on the system. To check the performance, I used 'diskx -p' with both variable length and fixed length records. here are the results I got for the variable length test: Performance test results: Part- Transfer Count of Read Write Transfer ition Size Transfers Rate Rate Errors ------------------------------------------------------------------------------ - a 2.0 KB 32768 453.82 KB/sec 342.31 KB/sec 0 a 8.0 KB 8192 881.08 KB/sec 569.72 KB/sec 0 a 14.0 KB 4681 1.27 MB/sec 694.28 KB/sec 0 a 20.0 KB 3276 1.52 MB/sec 889.13 KB/sec 0 a 26.0 KB 2520 1.68 MB/sec 810.71 KB/sec 0 a 32.0 KB 2048 1.82 MB/sec 931.76 KB/sec 0 a 38.0 KB 1724 1.94 MB/sec 1.03 MB/sec 0 a 44.0 KB 1489 1.99 MB/sec 979.28 KB/sec 0 a 50.0 KB 1310 2.08 MB/sec 1.01 MB/sec 0 a 56.0 KB 1170 2.10 MB/sec 1.09 MB/sec 0 a 64.0 KB 1024 2.14 MB/sec 1.12 MB/sec 0 b 2.0 KB 65536 287.79 KB/sec 331.94 KB/sec 0 The maximum observed read rate is 2.14 MB/sec. The maximum observed write rate is 1.12 MB/sec. Does anyone have any idea as to why the observed rate are so low? Thanx. John McDonald Atlanta CSC [Posted by WWW Notes gateway]
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 852.1 | p.s. | NNTPD::"mcdonald@decatl.alf.dec.com" | John McDonald | Wed Apr 23 1997 16:02 | 7 |
p.s. The writeback cache is enabled and the battery is good. John [Posted by WWW Notes gateway] | |||||
| 852.2 | SSDEVO::T_GONZALES | Mon Apr 28 1997 17:42 | 3 | ||
What are the facts of the comparison, what was the original
configuration that was used as a comparison?
| |||||
| 852.3 | Check Note SMURF::ASE 1996.6 ... | GUIDUK::SOMER | Turgan Somer - SEO06 - DTN 548-6439 | Tue Apr 29 1997 15:05 | 3 |
I have the same issue at another customer site. Please check
SMURF::ASE Note 1996.6 and on....
| |||||
| 852.4 | MAXIMUM_CACHE_TRANSFER_SIZE ? | STOWKS::SLUIS | Hans van Sluis - StorageWorks Engineering Support Europe- DTN 889 9526 | Fri May 30 1997 09:34 | 11 |
OK, It's rather late. But do you happen to know what the MAXIMUM_CACHE_TRANSFER_SIZE of the units was set to. If it was still set to the default (32 blocks = 16K), then that may justify your performance problem. If it was set to its maximum value (as where it should be during write intensive applications, being 1024) the controller would have used his writeback cache. That's my guess | |||||
| 852.5 | MSE1::PCOTE | press one now for personal name | Fri May 30 1997 12:40 | 8 | |
Are there any hard and fast rules wrt to MAXIMUM_CACHE_TRANSFER_SIZE? Any documentation available which explains how to maximize hsz performance given various cache sizes, raidsets, policies, etc. thanks, | |||||
| 852.6 | VTDPY is the tool to use... | KERNEL::LOANE | Comfortably numb!! | Fri May 30 1997 13:24 | 4 |
Not so much hard and fast, more rule of thumb!! I use the VTDPY
tool to work out rough'n'ready details for Average I/O size. Then,
on a unit by unit basis, I set the Cache Xfer Size parameter to
make best use of the Read (or WriteBack) cache.
| |||||
| 852.7 | KITCHE::schott | Eric R. Schott USG Product Management | Sun Jun 01 1997 14:47 | 5 | |
Hi On Digital UNIX, I suggest always setting it to 256 (128KB) or larger. | |||||