Tuned CPGs

[ailean]

Has anyone seen the HP whitepaper entitled "hp 3par storage and vmware vsphere 5 best practices"?

On page 19 it talks about 'default CPG' vs 'tuned CPG' performance however it seems to skip over just how you go about creating a 'tuned CPG'.

Basic difference seems to be in the LD distribution and size, rating larger/even sized LDs with wider distribution being better then the default variable size/distribution.

This is the first I've seen this talked about in detail in a HP/3PAR doc and the lack of command options to achieve this is irritating.

I'm guessing the distribution/RowSz is done with the "-rs" option, and from the 'showld -d' outputs they screenshooted I'm guessing "-rs 8" but not sure how to force the 'SizeMB' property to come out at 144GB, unless this is an effect of the forcing a non variable RowSz?

Anyone tried any of this before?

[scottm]

Working through this right now. I think if you set the proper Growth Increment it will automatically set the proper row size.

I'm double checking my math on it now hoping I made the calculations right.

[johnbecker31]

Has there been any further discussion as to the best practice on setting growth increment ( CPG Tuning ) I see that it is suggested in HP Best Practices for Implementing SQL Server with HP 3PAR StoreServ and VMware vSphere – August 2013, but does this concept hold true for other high write/high IOP/s configurations?
http://h20195.www2.hp.com/V2/GetPDF.aspx%2F4AA4-7945ENW.pdf

[nsnidanko]

CPG tunning to strip data across all disks

Formula:
( Total number of disks * data drives ) / total drives
For Example Raid 5_1 (Raid 5 with 5 data and one parity) on 108 disks:
( 108 * 5 ) / 6 = 90 GB

[johnbecker31]

I guess what I am looking for is: Has anyone had HP instruct them to use anything other than the default growth increment? Lets say I have a V400 and our current FC count is 528. We are going to add additional drives and will be close to maxed out, but we are still using the default growth increment of 64GB.

[apol]

The idea of striping everything above all disks sounds perfect, but: Doesn't it collide with the "availabillity"-settings in some manner? And as long as the chunks are 1GB, none of your data is really striped over more than a few of them - unless you have some really big files.

Further more, on bigger machines the formula mentioned above leads to (in my opinion) absurd numbers - I am NOT going to set the growth increment to (960 x 6) / 7 = 822GB!

Daily compactcpg, weekly tunesys, and the default settings for growth increment do a perfect job on our 10400.

As the Best practices Guide for InformOS 3.1.3 (4AA4-4524ENW, June 2014, Rev. 4) suggests:

Best practice: When creating CPGs, always accept defaults if possible.

[nsnidanko]

Big files are quite common with VMDK/VHD formats. I agree setting growth size to 800GBs sounds a bit crazy.

Here's the video describing concept:
https://www.youtube.com/watch?v=zgVXWjq3W_c

As per changes to Best Practice here's reply from the author:
"What HP is trying to get away from is random nonsensical changes to CPG growth, the wrong entry could really mess you up."