Optimum cluster size for EVA ?

[Guinaudeau]

here the three files,

one at 16:30,

two one hour later 17:30 to compare.

louis

[Guinaudeau]

file # 1

[Guinaudeau]

file # 2

[Hein van den Heuvel]

If you toss that XFC out at EXCEL.
Add a READ-IO column as READ - HIT
Sort By Descending READ-IO
Add a READ-% column as READ-IO/SUM(READ-IO)
Take a top-5
For day-time hour(s) and overall.
The you get the full picture below (probably heavily istorted.

Reduced to just block-size and read-percent:

Overall (64% of all read IOs)
Size % reads
1 19%
127 16%
2 15%
64 11%
32 3%

One-hour (87% of all read IOs)
Size % reads
1 39%
2 37%
64 5%
127 3%
47 3%

Reminder: IF the files are pre-allocated, THEN the cluster size matters absolutely ZERO, as far as OpenVMS IO performance is concerned. That is, as long as those IO have no (artifical)cluster alignment as suggested in the topic.

Now looking at the data, it seems that during the day, it matters even less than nothing, if that was possible.
The bulk of the IOs (almost 80%) is for a size where nothing matters: 1 or 2 blocks. There is no way to optimize those other than to make them go away: MORE XFC cache?

Looking overall there are those 127 block IOs to deal with. Probably not VMS Backup, as they seem to be cached. Possibly COPY or just application code using 32-bit RMS $READ with its maximum buffers size of 127.

That's an odd, prime value. No cluster size, other than a multiple of 127 will ever line up with that. That 127 will not line up with anything in the EVA, so the cluster size choice for that large component of all IO does not matter at all.

Finally there is a significant component of 16/32/64 block IOs. Possible simple miscelaneous stuff like LOG FILES. (SHOW RMS ... default set to 64?) Possibly not happening on the disks we are concerned with. Possible on files with fragmentation. Since nothing else matters, you might as well humor those and create a cluster size as a large multiple (127? :-) of 16.
Hence the 1024 I suggested in the first place.

Hope this helps some more,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

Size Read Hits Read IO Writes % reads
Total 411,167,290 405,510,091 5,657,199 17,023,438
1 135,516,967 134,427,979 1,088,988 3,242,916 19%
127 24,062,592 23,175,571 887,021 1,289,772 16%
2 119,641,504 118,808,372 833,132 893,298 15%
64 4,764,132 4,116,111 648,021 3,626,524 11%
32 1,567,160 1,385,615 181,545 875,731 3%

Size: Read Hits Read IO Writes IO % reads
Total 1,846,576 1,794,231 52,345 70,074
1 649147 628664 20483 13185 39%
2 582528 562910 19618 6728 37%
64 16986 14448 2538 14599 5%
127 77837 76366 1471 3020 3%
47 19162 17744 1418 3621 3%

[Robert Brooks_1]

Looking overall there are those 127 block IOs to deal with. Probably not VMS Backup, as they seem to be cached. Possibly COPY or just application code using 32-bit RMS $READ with its maximum buffers size of 127.

That's an odd, prime value. No cluster size, other than a multiple of 127 will ever line up with that. That 127 will not line up with anything in the EVA, so the cluster size choice for that large component of all IO does not matter at all.

--

Host-based volume shadowing used to do its copy and merge I/O's in 127-block increments.

I'm pretty sure the default was changed once the EVA alignment issue was discovered, but I'm not positive.

-- Rob

[Guinaudeau]

hi,

thanks a lot for your assistance in interpreting the XFC cache data

i thought now (a bit late)i could have used SDA extension if it helps, but it sounds sufficient with DCL command to do it. or ?

especially thanks to hein and rob for the last two very detailed replies based on attached XFC output.

i am thinking about your replies with my colleagues and will probably soon close this thread because i should conclude : we will not win anything thru a change of cluster size.

we had (possibly) thru the upgrade (application should be upgraded too, not only HW) to change that cluster size, and that was the reason of my thread.

we have (possibly) another customer with SCSI-3 drives in shadow-set where the same app upgrade should occure (no HW upgrade in that case). i will redo the same steps as you did to check what will be when we change cluster size there.

rob, i confirm : the application is an old $QIO based with the limit of "64K" IOs, where it looks like the actual limit is 127 blocks. i dont understand something here, 127 and not 128. should i read the code with attention to understand some subtilities, or can someone say immediately something about this point ? most IOs are either large upto that limit of "64K" or smal 1 or 2 blocks

anyway, thanks thanks and thanks again.

louis

[Hein van den Heuvel · Accepted solution]

>> the application is an old $QIO based with the limit of "64K" IOs,

There is no 64 limit for QIOs in OpenVMS in general. There is for RMS $READ/$WRITE, and there was a time when the SCSI driver would split up IOs in 127 blocks chunks... but my memory is scetchy on that. Would have to research exact versions and stuff. will not.

>> i dont understand something here, 127 and not 128.

That't because there is 1 bit too few.

The limitation (in some placed, like RMS, but not in QIO) is not 64K but 16 bits to specify the size. Since 0 is in use, you can only count to 65535, so there is 1 byte too few to express a full 64K = 65536.
0xffff versus 0x10000 --> 16 bits versus 17

Compare with 1 digit, which can have 10 values (0 .. 9), but you can only count to 9!

Considering disk IO must have even byte counts, and really only make sense on 512 byte boundaries, 'they' should have 'given' you a free byte, making -1 = 64 k huh!?

They could have made QIOs to a block device take 512 byte blocks as arguments, but they kept they kept the interface consisten. Sizes are in bytes. Everywhere.
Offsets are in blocks though (VBN)!


Hein.

[Robert Brooks_1]

There is no 64 limit for QIOs in OpenVMS in general. There is for RMS $READ/$WRITE, and there was a time when the SCSI driver would split up IOs in 127 blocks chunks... but my memory is scetchy on that. Would have to research exact versions and stuff.

--

$ write sys$output f$getdvi( "$1$dka0", "device_max_io_size" )
131072

That item code returns the value in ucb$l_maxbcnt. A decimal value of 131072 is equal to %X20000 and is the upper limit of the SCSI disk driver. RMS and XFC may impose a lower maximum.

I think that item code was added for V8.2 and perhaps backported to V7.3-2

-- Rob

[Guinaudeau]

hi,

colleague confirms :

the application restriction is 64K for old reasons in the development, and i assume you quoted the correct one : 16 bits to specify the size, so "64K-1" bytes.

hein,

i am surprised when you wrote that this restriction does not apply to QIOs, since we are using QIO, not RMS => are you sure that it does not apply to old QIO (before fast IO) ???

we will not change this old legacy now, we cannot afford it (test such a change would not worth). and anyway, a cluster size looks not to bring something.

louis

[Guinaudeau]

many thanks for your help

louis