This post is more than 5 years old
48 Posts
0
1422
unisphere analyzer pool vs raidgroup stats
What happend to the SP Cache stats for luns that are build on pools.
A customer is using pools, no fast cache license yet, but we can't find any SP Cache stats for the individual luns.
If we look at the classic raidgroup luns, the SP Cache stats can be found so we can check for any write cache misses etc etc.
Regards,
John
kelleg
4.5K Posts
0
January 6th, 2011 14:00
Because Pools do not allow you to change the cache settings, you can not see any data about them - the cache is handled by the Pool drivers and not the individual LUNs within the pools.
glen
jjgrinwis
48 Posts
0
January 7th, 2011 00:00
ok, so if we really want details stats from a lun we still need to build it on the "classic" raidgroups.
Beside cache stat's I'm also not seeing any stats about disk-crossings and I can't imagine that with a misaligned FS on a pool we will never suffer from disk-crossings.Would be nice to see some more stats from pool luns.
John
kelleg
4.5K Posts
0
January 7th, 2011 10:00
Remember that disk-crossing are not a problem with file-system alignment, that's stripe-crossings. Besides, it's always considered best practice to align the file system (except on Wondows 2008).
glen
jjgrinwis
48 Posts
0
January 7th, 2011 12:00
We where able to solve a misalligned fs on a lun used for mssql by looking at the crossings a couple of months ago.
Thing is that would have taken us some more time to solve, if this had been build on a pool lun, because of the missings stats.
John
SKT2
1.3K Posts
0
January 17th, 2011 17:00
what you meant by "We where able to solve a misalligned fs on a lun used for mssql by looking at the crossings a couple of months ago".. as Mentioned earlier disk crossings and stripe crossings are 2 different things.. Can you explain your theory a little more so we know what may have happened in your case.
jjgrinwis
48 Posts
0
January 18th, 2011 01:00
Below two screenshots from analyzer showing the diskcrossings:
Disk crossings% before changing block size:
Disk crossings% after changing block size
disk crossings dropped to a max of 32%, causing a lot less read IOP/s.
My problem is with the pools, how can we ever generate stats like this to troubleshoot performance issue's when using pools.
SKT2
1.3K Posts
0
January 31st, 2011 10:00
Thanks for posting this buddy. What was the block size(default) earlier? And what is the new block size?
But the NTFS allocation size(block size) is different than the partition offset. They are two different things.
Can you also check what is your parition offset
jjgrinwis
48 Posts
0
February 2nd, 2011 02:00
SQL was runing on 2008, disk was aligned.
For some reason they used 48K block size, we've changed that to 64K, the recommended value which solved the above problem.