HP P2000 Controller Test

A value close to 100 is a cause of concern.

Comparing the value of this measure across controllers will enable you to accurately identify the controller whose CPU resources are consumed excessively. If the value of this measure remains high for that controller, it is an indication that the processor is getting choked and may require more processing power. This would also indicate an I/O overload. In this case, you may want to tweak the load-balancing algorithm of the storage system to reduce the load on a single controller and to optimize CPU usage.

This is a good indicator of the load on the controller. You can compare the value of this measure across controllers to figure out whether the load has been distributed uniformly across all controllers or a few controllers are overloaded. In case of the latter, you may have to fine-tune the load-balancing algorithm used.

This measure serves as a good indicator of the I/O processing ability of the controller. A consistent drop in this value is hence a cause for concern, as it indicates a processing slowdown.

Ideally, the value of this measure should be high. A steady dip in this measure value could indicate a potential reading bottleneck. Under such circumstances, you may want to check the value of the Read cache hits and Read cache misses measure to figure out whether under-utilization of the cache is the cause for the reading delay. 

Ideally, the value of the Read cache hits measure should be high, and the value of the Read cache misses measure should be low. A consistent drop in cache hits and a steady increase in cache misses during the same time frame is indicative of ineffective read cache usage, which can lead to a slowness in read request servicing. To improve read cache usage, you may want to consider turning on read-ahead caching. You can optimize a volume for sequential reads or streaming data by changing its read-ahead cache settings. Read ahead is triggered by two back-to-back accesses to consecutive LBA ranges, whether forward (increasing LBAs) or reverse (decreasing LBAs).

You can change the amount of data read in advance after two back-to-back reads are made. Increasing the read-ahead cache size can greatly improve performance for multiple sequential read streams; however, increasing read-ahead size will likely decrease random read performance.

• The Default option works well for most applications: it sets one chunk for the first access in a sequential read and one stripe for all subsequent accesses. The size of the chunk is based on the chunk size used when you created the vdisk (the default is 64 KB). Non-RAID and RAID-1 vdisks are considered to have a stripe size of 64 KB.
• Specific size options let you select an amount of data for all accesses.
• The Maximum option lets the controller dynamically calculate the maximum read-ahead cache size for the volume. For example, if a single volume exists, this setting enables the controller to use nearly half the memory for read-ahead cache. Only use Maximum when disk latencies must be absorbed by cache. For example, for read-intensive applications, you will want data that is most often read to be in cache so that the response to the read request is very fast; otherwise, the controller has to locate which disks the data is on, move it up to cache, and then send it to the host.

Ideally, the value of this measure should be high. A steady dip in this measure value could indicate a potential writing bottleneck. Under such circumstances, you may want to check the value of the Write cache hits and Write cache misses measures to figure out whether under-utilization of the cache is the cause for the writing delay. 

Ideally, the value of the Write cache hits measure should be high, and the value of the Write cache misses measure should be low. A consistent drop in cache hits and a steady increase in cache misses during the same time frame is indicative of ineffective read cache usage, which can lead to a slowness in write request servicing. To improve write cache usage, you may want to consider changing that volume’s write-back cache setting. Write-back is a cache-writing strategy in which the controller receives the data to be written to disks, stores it in the memory buffer, and immediately sends the host operating system a signal that the write operation is complete, without waiting until the data is actually written to the disk. Write-back cache mirrors all of the data from one controller module cache to the other. Write-back cache improves the performance of write operations and the throughput of the controller.

Comparing the value of these measures across the controllers will clearly indicate which controller is the busiest in terms of the rate at which data is read and written - it could also shed light on irregularities in load balancing across the controllers.