calculating transfer size on vms disk

[Wim Van den Wyngaert]

But not per disk.

Wim

[Wim Van den Wyngaert]

And are the IO's bybassing the cache in it ?

[Keith Parris · Accepted solution]

Another way to calculate average transfer size is to look at it down at the controller level. If you have HSx controllers, VTDPY can give you, on a per-disk basis, the average data transfer rate and the I/O request rate. Dividing the average request rate into the average data transfer rate in kilobytes gives you the average I/O tramsfer size in kilobytes.

[Hein van den Heuvel]

Ok folks, enough chatting about block sizes and caches. Let's get back to be basic question which is NOT calculating the transfer size as the subject suggestm, but it is figuting out an optimal chuk size for a raid set.

None of the prior replies are going to help with that.

IMHO are stuck by picking a highish number like 255 or 256. High enough to avoid excessive splitting of IO, low enough to pread hotspots.

It is exceedingly unliky that you can actually pick a hardware stripe size to optimally match your average IO size.

The AVERAGE is completely irrelevant in this calculation IMnsHO.
Only the MODAL value counts (or whatever the name of the statistical term that means 'most often used' :-). This is because a lot of VMS IOs are 1 blocks. For those the chunk size does not matter at all, but they do influence the average!

This is one of the few times where you may want to take the DISK ALLOCATION CLUSTER SIZE into consideration. Why? because you know there is a good chance that IOs will start as a cluster boundary. After all, every single file starts at a cluster boundary.

So by selecting the chunk size to be a straight multiple of the cluster size you will make sure that the first IO from the beginning of a file will not be spilt over chunks.

The following IOs are dependend on the IO sizes. For sequential files IO that is OFTEN, but not always 32 blocks. (SHOW/SET RMS!)So to keep those from fragmenting you could consider
CLUSTERSIZE = N * 32
CHUNKSIZE = N * CLUSTERSIZE

An other popular IO access pattens is Indexed file IO. There the size is BUCKETSIZE, but the first datablock (by default) tend to start at block 3 or 4, and does NOT start on a multiple of cluster no bucket size. Note, blocks intentt will be alligned, and you can play fdl games to start out aligned.

I'd pick 256 if I had some hope to force allignment on 2**N boundaries. I'd pick 255 if i was afraid to 'fall out of sync' and cause a pattern of splits. With the chunk size being prime you'll distribute the pain evenly :-).

hope this helps,
Hein.

[Hein van den Heuvel]

[ 0 points for this reply ]

I'm glad you like my reply (judging by the 10p) despite the horrible spelling. Sorry 'bout that. I just started typing and never looked back.

One cute (imho) line I was going to put in there was "when is the last time you did an 'average' IO?". Just to put further focus on the 'modal' value selections, not median, not average.
4 IOs 1 block
3 IOs 4 blocks
2 IOs 8 blocks
8 IOs 16 blocks.

Total 17 IOs, 160 block, avg=9.4, med=8.5, mod=16. Pick 16 as the number for the sizing, not 9.5.

cheers,
Hein