Just a quick update - I doubled checked with engineering about the raid group statistic and they come from the disks not the LUNs. So the stats on the LUNs (due to caching) can be different than what you see at the RG.
There are a number (lots) of possible reasons - raid group numbers are not an exact 1 to 1 for the LUNs - it can be affected by the cache re-hit rate for Writes, sequential vs random, IO size, hit rates for Reads and more.
For example, say the IO is 100% Writes, but all at the same locations - you'd get very little disk IO but very hit LUN IO - all the Writes are operating out of cache at that point - that would skew the raid group numbers. Personally I look at the disks first to see if there is any overloading, then at the LUN level. I view the disks as the starting point as ultimately it is the disks that have a hard limit.
The basic LUN statistics are what is coming from/going to the server
The Disk/RAID group Statistics are what you see going to the disk.
In a simple world without write caching/prefetching you'd see.
RAID-5 LUN
1 Read from the LUN.
1 read from the RAID Group (maybe more on the individual disks)
1 Write to the LUN
2 Reads/2 Writes to the RAID Group.
With Write caching/Prefetching the numbers are going to be a lot different between the physical pieces (RG, disk) and the Logical pieces (LUN)
The fact that the numbers are different it usually good. It means your array is doing what it's designed to do - Minimize the physical I/O to the disks by gathering as much as it can into larger chunks before it hits the disks.
kelleg
4 Operator
•
4.5K Posts
0
November 8th, 2010 12:00
Just a quick update - I doubled checked with engineering about the raid group statistic and they come from the disks not the LUNs. So the stats on the LUNs (due to caching) can be different than what you see at the RG.
glen
kelleg
4 Operator
•
4.5K Posts
0
November 8th, 2010 10:00
There are a number (lots) of possible reasons - raid group numbers are not an exact 1 to 1 for the LUNs - it can be affected by the cache re-hit rate for Writes, sequential vs random, IO size, hit rates for Reads and more.
For example, say the IO is 100% Writes, but all at the same locations - you'd get very little disk IO but very hit LUN IO - all the Writes are operating out of cache at that point - that would skew the raid group numbers. Personally I look at the disks first to see if there is any overloading, then at the LUN level. I view the disks as the starting point as ultimately it is the disks that have a hard limit.
glen
driskollt1
131 Posts
1
November 8th, 2010 12:00
Think of it like this:
The basic LUN statistics are what is coming from/going to the server
The Disk/RAID group Statistics are what you see going to the disk.
In a simple world without write caching/prefetching you'd see.
RAID-5 LUN
1 Read from the LUN.
1 read from the RAID Group (maybe more on the individual disks)
1 Write to the LUN
2 Reads/2 Writes to the RAID Group.
With Write caching/Prefetching the numbers are going to be a lot different between the physical pieces (RG, disk) and the Logical pieces (LUN)
The fact that the numbers are different it usually good. It means your array is doing what it's designed to do - Minimize the physical I/O to the disks by gathering as much as it can into larger chunks before it hits the disks.