The release notes for HSZ70 HSOF software version 7.7 update the existing
documentation regarding choosing a chunk size. The new documentation
recommends specific chunk sizes, all prime numbers, and replaces the original
documentation, which recommended that the default chunk size of 256 blocks be
used.
I'd like to know if the recommended chunk sizes would also apply to the HSZ50
since it's in the same controller family. I'm trying to improve the
performance of a stripeset that is overloaded.
See below for the details.
(In a reply, please say whether or not you want your name, email address,
domain, or organization included in the credits in the summary.)
Joe Ledesma
Oracle DBA / SAP R/3 Basis / UNIX Admin
Sacramento, CA USA
===========================================
General recommendations for choosing a stripeset chunk size typically
recommend that a chunk size that is greater than the average request size be
used in order to increase the request rate and a chunk size that is smaller
than the average request size be used to increase the data transfer rate
(throughput) for sequential access.
The original documentation for the HSZ70 (and the HSZ50) recommended that the
default chunk size of 256 blocks (= 128 K) for a stripeset or RAIDset with 9
or less members be used and warned against using an improper chunk size.
The new documentation advises that the default chunk size should be used with
caution and recommends that in order to increase the request rate, a chunk
size of 10 to 20 times the average request size, "rounded" to the nearest
prime number, be used:
* If there is a lot of parallel I/O on a small area of data, use a chunk size
that is 10 times the average request size.
* If the areas being accessed are scattered, use a chunk size that is 20 times
the average request size.
* If you don't know, use a chunk size that is 15 times the average request
size.
Therefore, for an 8 KB request size, the documentation says to use a chunk
size of 157 for high locality, 239 for unknown locality, and 317 for low
locality access. (Chunk size is in disk blocks = 512 bytes.)
To increase the data transfer rate, the updated documentation says that a
chunk size of 17 generally works well for sequential access on stripesets.
I have already used the chunk size of 317 blocks on a 6 member striped
mirrorset (i.e. 3 member stripeset) on an HSZ70 with no ill effects that I can
tell. (The unit is used for Oracle datafiles for an OLTP application.)
* My question is, would these recommendations also apply to the HSZ50?
The Compaq hardware phone support person I asked one evening in March thought
so since both controllers are in the same family. I suppose that these
recommended chunk sizes would also apply to the HSZ50 since I suspect that the
HSOF software for the HSZ70 uses algorithms for striping that are similar to
or the same as those used in the HSOF (5.4) for the HSZ50?
I'm considering using the chunk size of 17 on an HSZ50 for a sequentially
accessed unit. Otherwise I'll stick with the default of 256 for all HSZ50
stripesets.
If you want to read the documentation I'm referring to, you can't unless you
have the HSOF 7.7 kit (I'm running 7.3; we received version 7.7 (Feb 2000) as
part of our support--part QB-5SBAB-RA.) since the release notes for the new
version aren't on the web page for "Array Controller Documentation":
http://www.compaq.com/support/storage/open_vendor/support/document.html
* Is anyone from StorageWorks out there that can get this page updated? The
versions listed stop at 5.2 and 7.0.
The server storage configuration is:
SCSI buses 3 and 4: two pairs of dual-redundant HSZ70s (7.3) with mirrored
writeback cache connected via two KZPBA-CBs
--hold the Oracle database datafiles on striped mirrorsets and the Oracle
online redo logs on mirrorsets
SCSI bus 2: one dual-redundant pair of HSZ50s (5.4 ) connected via a
KZPSA-BB
--has the system disk and holds the Oracle archived redo logs and other
non-database file systems
The drives are mostly DS-RZ1DF-VW 9.1 GB 7,200 rpm disks.
The server is an AlphaServer 4100 (4 x 600 MHZ) running Tru64 4.0D patch 4.
All file systems are AdvFS.
The unit in question on the HSZ50, for the Oracle archived redo logs, is a 4
member striped mirrorset with the default chunk size of 256 blocks. During
peak processing, Oracle writes to this file system a 100 MB archived redo log
file as often as every 2-4 minutes. The NetWorker client is also reading this
file system hourly to back it up over the network. This backup takes 10-20
minutes during peak hours. (Presumably it's reading one file at a time.)
This weekend I plan to migrate the domain to a 6 member striped mirrorset and
will also be changing all the other storagesets to be preferred (using the
controller load balancing) to one controller so that this unit for the
archived redo logs is handled by its own controller in the pair. I'll also
make sure that none of the other mirrorsets have a primary member in the same
device-side channel as any of the primary members of the mirrorsets in the
striped mirrorset for the archived redo logs. This is the stripeset that I'm
considering using the chunk size of 17 for.
I've also observed that using the writeback cache for this unit with the large
sequential writes doesn't help--I expected this. (Each HSZ50 has 128 MB
cache.)
The basic issue is that the online redo logs are being written very quickly on
faster storage, the HSZ70s, and are being archived to older slower storage;
but I don't have another HSZ70 for this purpose.
**For Oracle users**
One solution at the Oracle level is to use larger online redo logs so that log
switches occur less often and use more log groups. I'm already using 8 log
groups and I don't want to use a size greater than 100 MB in case Oracle has
to do an instance recovery after a crash, which would take longer with a
larger online log?
I'm using these Oracle parameter values:
log_archive_buffers = 4 (OS-dependent default)
log_archive_buffer_size = 31 (OS-dependent default)
--the units here are redo log blocks--OS-blocks--whatever Oracle considers
that to be for Tru64 ?
log_buffer = 1048576 (bytes)
Assuming the 'log_archive_buffer_size' parameter is in 1 K blocks, this value
means that Oracle is writing the archived redo logs 31 K at a time.
I've already reduced redo latch contention by adding more copy latches.
Thanks,
Joe Ledesma
____________________________________________________________________
Get free email and a permanent address at
http://www.netaddress.com/?N=1
Received on Fri Apr 07 2000 - 22:56:23 NZST