Identify performance risks in SVC or Storwize
mipi 270004DGB0 Visits (2566)
We actually run a program that we call the HKC Analysis or more simple health check.
You need: (please see checklist for details)
It takes us only 20 seconds after the launch of BVQ to find the first answers for performance issues. The CPU usage of the SVC or Storwize is low with only 3% to 6%, the global R/W cache is on standard values but the global write cache fullness is much too high. A reason for this can be a slow storage backend or some SAN issues. The result of these peaks is normally what a server admin would describe as a slow SAN storage.
You have the knowledge and the tool – this allows you to go deep into the SVC and figure out what in detail happens in the cache partitions of the SVC. Each managed disk group is a cache partition and we have been alarmed by the global cache that there might be an issue. There is a quick way to find out which managed disk group is in trouble. From there we can go on into the analysis of the volumes.
It is only some mouse clicks away to see what is going on with the SVC Node ports. This analysis shows that the data rates on the ports are not an issue. Typical SAN errors are also not visible but the yellow line tells us about a SAN blockage. The SVC had to wait up to 40% of its working time for SAN Buffers. This might be a wrong parameter in the SAN switch or a slow draining device in the SAN.