You can run into a situation very quickly where you are experiencing performance problems and these performance problems may be revealing themselves in an environment that may or may not actually have anything to do with the environment that is actually causing the performance problems. Sounds confusing, right? So how can you figure out what is the underlying cause of your performance problems and solve the issues at hand?

So, say that you have found yourself in a situation in which your cache on your array is being hammered by one of the environments in your system. What do you do now? The first thing you should do is to use the performance monitoring tools for your system. These performance graphs can show you which environment is using the highest amount of IOPS and cache. You’ll know when you have found the right LUN by seeing that response times and cache utilization have been spiking up at the same time as when this LUN increases its IOPS. This will indicate that you have found the server that is hosting the data that is causing your cache utilization to go through the roof.

What Next?

Your next step is to look at the LUN that is causing the problem. What kind of data is on the LUN? On what kind of drives does the LUN reside? Is it, for example, an Oracle database sitting on SATA drives? If that is the case, your fix is very easy – move it to a faster disk.

In most tier two type array, you will have the ability to migrate disks a lot. So, if you have a database LUN that is sitting on a RAID group or a storage pool that has SATA disks underlying it, and if you have the capacity available, you can go and create anew LUN on a SAS or Fibre Channel RAID group or storage pool and migrate that LUN over to the new pool. By doing this, you will decrease the response time for that device because the underlying device to which the cache is writing data is able to keep up with requests a lot faster than the original SATA disk.If your environment is strictly built on RAID groups, you create a new LUN that is in a faster spindle RAID group like SAS or SSD and you can then migrate that LUN over.

However, the best way avoid these issues is to plan your architecture properly when you deploy systems to the storage array.