Optimum cluster size for EVA ?

[Guinaudeau]

hi,

we will upgrade soon one VMS customer to use EVA (4100) with ES45. that customer runs V8.3.

our application has a large proprietary database, where

-> files are GB large and pre-allocated, no extension

-> files are ever opened, IOs are $QIOW aligned or not ; some IOs may be 512 bytes large, larger IOs are 64K (the old limit) ; files will be aligned, IOs not ever.

IO load is a great thing by this customer, so we are trying to look for optimal perfs.

i red about cluster size and we would like to optimize the cluster size for the new drives located on EVA.

=> advice was modulo 4 ? is it ever correct ? or is it better with modulo 16 ? i remember the presentation at bootcamp by steve hoffmann and his remark for mod 16.

=> i assume DISKPERF would be helpfull if we can judge a ~ real load

=> i assume, since app runs today using MSA, that we can use MSA fib-channel extension to have statistics, at least about IO size, possibly about alignment ?

any idea about analyse ?

i assume the issues are :

-> HW chain between drives / controlers / ...

-> XFC caching size

and what else ?

thanks for any remark / comment / etc ... in advance

louis

[Jan van den Ende]

Louis,

I think I was at that same session by Hoff :-)
Not only his, but also various performance sessions, and also answers here in ITRC, by specialists as Hein, Guy Peleg, Bruce Ellis, and several more point in the same direction.
All stress the 8 Kbyte, 16 block (or multiple) as transfer unit for SAN.
Do not forget to alse make that the value for the various RMS blocks. Limit here is 127, so biggest multiple of 16 is 112. And of course, also the disk cluster size should be a muliple of the transfer.

You did not specify WHICH database, but those usually also allow/require such settings. Make sure those harmonise with OS settings.

hth

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

Summary... I don't think it is going to matter much at all, given all conditions you wrote (Thanks for a refreshingly well documented note!)

The modulo-4 was due to an EVA RAID-5 issue.
It could affect write speed.

Obviously, since the customer cares about performance RAID-5 will not be used right?

http://www.baarf.com/ - "Battle Against Any Raid Five" http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt

Does the application avoid the XFC cache? (QIO no-cache attribute ?)

If it uses XFC than SHOW MEM/CACHE/FULL will give a nice IO histogram.

If the system has been up for a while, then you may want to SET CACHE/RESET to clear those counters (not the data) and look again after an hour or a day.

If it uses XFC than you should opt for modulo 16 as it deals with 16 block cache lines.

Now XFC deals with VBNs, not LBNs so the cluster size only plays a role if the application aligns or blocks, based on the cluster size. RMS Indexed files are sensitive to this. Your application might not. Still... it wouldn't hurt. You might as well stack the deck.
Clustersize defines first-block-in-file LBN alignement. No more, no less.

Since you mention large (and therefor few) pre-allocated file I would encourage a large cluster size to make it easier for all components.
A nice 'round' number like 1024 or 2048 perhaps?

maye more later,

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

[Guinaudeau]

hi jan,

the DB is not RMS working, purely QIO.

It is an internal product in our company, very specialized for our SCADA system needs, with fast access (read or write) to different cyclic data for example. several blocks are written every 10 seconds, and the DB should be red fast too for display of timeline data on several minutes / hours / ...

I recollect from your replay and other threads (at least using MSA, which has also been used by some of our customers) the 127 (or 112) size for the cluster.

louis

[Jan van den Ende]

Louis,

SCADA?
May or may not be like what I have been dealing with (15 years ago, so things change, and memory fades :-( )
but THAT SCADA was operating a mainly in-memory DB, with on-disk data only as backing store.
_REAL_ fast, also in VAX days, but the active part of the DB HAD to fit in available memory.
_IF_ that applies here also, the disk-access speed and volume is still interesting, but being able to tailer the important parts for permanent residence is the REAL issue,
Nowadays memory is rather cheap, and VMS v8,x has extensive means to exploit that.

But... does that apply for your environment?

fwiw

Proost.

Buvez un de moi.

jpe

[Guinaudeau]

precision : the DB layed on RAID-0 and RAID-1 volumes (additionally, these are shadow members, but that is pretty clear with VMS ;-)

[Guinaudeau]

SCADA :

you are right, the in-memory is important for performances. the DB had some in-mem caching, but currently, the best caching (since it is larger than original caching SW allowed) is the XFC to read blocks (write caching is for sure neglected, sorry for that, but our SW would need much work to ensure this)

=> we obtain already 80-90% hit rate for the read in the large files i quoted, and that is great for performances, we use 1GB and more of main memory

louis

**************

nota : my reply in that system are very slow, several minutes each time => is it on my side something slow, or the forum machine itself => curious to read your reactions

[Hein van den Heuvel]

May we assume you already googled around and found documents like: http://h71028.www7.hp.com/ERC/downloads/5982-9140EN.pdf
"Virtual Array 3000 and 5000 configuration best practices"

>> but currently, the best caching (since it is larger than original caching SW allowed) is the XFC to read blocks

So maybe share a representative SHOW MEM/CACH/FULL output in an attachment at some point? Preferably not over days, but after being reset just before a typical production window, and displayed afterwards?

SET CACHE/RESET may sound scary, but don;t worry, it just resets the top level counters, not the file details, and certainly does not affect the cache contents.

=> we obtain already 80-90% hit rate for the read in the large files i quoted, and that is great for performances, we use 1GB and more of main memory

That's typical, maybe even on the low side.

I have a (perl) script to take the SHOW MEMO/CACH=(TOPQIO=x,VOLUME=y) into a CSV sorted hot-file list fro excel. Nice way to see trends/problems... imho.

>> nota : my reply in that system are very slow, several minutes each time =>

Are you refering to the ITRC?
The replies often SEEM slow, but it is really the confirmation that's slow. Be sure to use a second window and 'see' whether the reply is there already. Or jsut ^A, ^C to be sure to safe all reply text, and then hit the topic hotlink on top (here the underlined "Optimum cluster size for EVA ?") to check that the reply made it in.

hth,
Hein.

[Guinaudeau]

hein,

1) do you prefer / think better a

$ SHOW MEM/CACH/FULL

or a

$ SHOW MEM/CACH=(TOPQIO=x,VOLUME=y)

i did first command then reset and will in one hour redo it.

2) your perl script will be of interest, for sure. do you attach in the thread ?

yours

louis

***************

thanks for the tip with slow ITRC command. that is what i meant, slow ITRC reaction.

[Hein van den Heuvel]

>> 1) do you prefer / think better a
$ SHOW MEM/CACH/FULL

That will be good enough to satisfy the curiosity of readers like myself, and perhaps generate some good suggestions.

>> $ SHOW MEM/CACH=(TOPQIO=x,VOLUME=y)

That generates a lot more data and needs more context to interpret it correctly.
It is very interesting, but it soon turns into 'work' to interpret. Sure, attach it as well. Maybe someone 'sees' something! I mentioned it more as a hint for yourself to look at it.

>> 2) your perl script will be of interest, for sure. do you attach in the thread ?

The script is not 'rocket science' but still represents some major work to get it reasonably robust. It is work (art?! ;-) in progress. I'll attach a basic version.

I expect to present a 1 hour session on describing how to obtain, format and interpret the SHOW MEM/CACHE data during the 2008 OpenVMS Boot Camp.
See you there?
http://h71000.www7.hp.com/symposium/index.html?jumpid=symposium

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