Using Analyzer there is no absolute way to detemine if the IO load is 100 %sequential.
You can look at the Average Seek Distance for the disks to see how small the distance in GB's is. The smaller the number the more sequential the IO (disk heads are traveling less distance).
If the IO is all Writes, you can look at Total Write Throughout and Full Stripe Writes (for the LUN) - the closer these two number are together the more sequential the IO. Same for Reads - if the IO is all Reads, look at Total Read IOPS and Read Cache Hits - 100% sequential reads should mean that Read Cache Hits are 100%.
Knowing your data is the most important part - the better you understand what the host is sending to the array, the better you can design LUNs and Raid Groups to handle the load.
The first question is, is it a Read or Write workload?
If its a Read or Read-heavy workload, (as Glen pointed out above) the read cache hit rate (RCHR) can tell you. RCHR is the percentage of read I/O requests found in the read cache. It is one of the metrics for determining if a read I/O workload is random or sequential.
If a workload’s read I/Os are purely random, the RCHR can be up to five percent. If it is higher, there is probably either a mix of random and sequential I/O, or a multi-threaded sequential workload being measured. There is also the chance the same addresses are being repeatedly accessed, or there is high locality in the I/O. The metadata on the first 64KB of a file system volume is an example of addresses which would receive repeated access.
For purely sequential I/O, the metric's value depends on the number of threads performing the I/O. With single-threaded sequential, the RCHR should be about 100 percent, but not less than 80 percent. Multiple-stream multi-threaded sequential access can reduce the effectiveness of the pre-fetch, which lowers the RCHR. Multiple-stream multi-threaded sequential I/O causes many read accesses to many different regions of a RAID group's drives. This slows the prefetch process lowering the RCHR.
The final possible reason for a low RCHR value is the workload is not truly sequential. The larger the random I/O component to the workload the lower the value of RCHR.
kelleg
4 Operator
•
4.5K Posts
0
January 11th, 2010 13:00
Using Analyzer there is no absolute way to detemine if the IO load is 100 %sequential.
You can look at the Average Seek Distance for the disks to see how small the distance in GB's is. The smaller the number the more sequential the IO (disk heads are traveling less distance).
If the IO is all Writes, you can look at Total Write Throughout and Full Stripe Writes (for the LUN) - the closer these two number are together the more sequential the IO. Same for Reads - if the IO is all Reads, look at Total Read IOPS and Read Cache Hits - 100% sequential reads should mean that Read Cache Hits are 100%.
Knowing your data is the most important part - the better you understand what the host is sending to the array, the better you can design LUNs and Raid Groups to handle the load.
glen
jps00
2 Intern
•
392 Posts
0
January 14th, 2010 10:00
The first question is, is it a Read or Write workload?
If its a Read or Read-heavy workload, (as Glen pointed out above) the read cache hit rate (RCHR) can tell you. RCHR is the percentage of read I/O requests found in the read cache. It is one of the metrics for determining if a read I/O workload is random or sequential.
If a workload’s read I/Os are purely random, the RCHR can be up to five percent. If it is higher, there is probably either a mix of random and sequential I/O, or a multi-threaded sequential workload being measured. There is also the chance the same addresses are being repeatedly accessed, or there is high locality in the I/O. The metadata on the first 64KB of a file system volume is an example of addresses which would receive repeated access.
For purely sequential I/O, the metric's value depends on the number of threads performing the I/O. With single-threaded sequential, the RCHR should be about 100 percent, but not less than 80 percent. Multiple-stream multi-threaded sequential access can reduce the effectiveness of the pre-fetch, which lowers the RCHR. Multiple-stream multi-threaded sequential I/O causes many read accesses to many different regions of a RAID group's drives. This slows the prefetch process lowering the RCHR.
The final possible reason for a low RCHR value is the workload is not truly sequential. The larger the random I/O component to the workload the lower the value of RCHR.