Performance Troubleshooting: Response Time & Queue Lengths

Performance Troubleshooting: Response Time & Queue Lengths

RESOURCES & LINKS:
____________________________________________
Reliant Technology - https://www.Reliant-Technology.com
Linkedin: https://www.linkedin.com/company/reliant-technology/
Facebook: https://www.facebook.com/ReliantTechnology
Twitter: https://twitter.com/goreliant

1.877.227.0828

Another good indicator and these things tend to all come together, is queue length and response time on both the LUN and the storage processor, so all of these performance indicators we've been talking about, you can look at them at different levels.

You can either look at them at the LUN level. You can also look at them on the array level. I tend to start at the array level, meaning at the SP, and then once I've got an idea of where my problem might lie, I start digging down into individual LUNs to determine OK, which LUN is doing this and why is it doing this.

Response time is a good indicator to look at and this kind of ties in with some of the other things that we're looking at.

If you go and look at, and when you're pulling these graphs you can pull multiple different indicators up at the same time, so that way you're able to see some type of correlation between these different indicators to see OK, is my response time spiking up at the exact same time that my cache utilization is spiking up?

If that's the case then that is basically a clear indicator that OK, my environment is engaging in forced flushing right now because of the fact that my cache is through the roof and my response time just sky rocketed because now since the array is not able to use the cache, the amount of time that it takes to accept a request and send the response has now spiked. Right?

You'll generally, that KPI line up with increased utilization on the SP processor itself or on the cache. Right?

Another thing that you want to look out for is the queue length. Queue length is basically ... When you think of a queue you think of a line. Right? Where is my place in line?

Queue lengths generally tend to be best between a number of four and I would say no higher than 20, right? You start seeing that number start to spike. That can be an indicator of a performance issue.

The array is a multi-tenant system. It's got more than one server that's sitting on it accessing data. You can't have every server trying to access the data all at one time.

You have this queue that the array manages on when each system is going to be able to make a request and it's going to be able to handle that request.

You don't want that number to get higher than a certain number because basically, you'll have systems sitting there waiting for IO after it sent a request for an extended period of time.

Now, how to bring that number down comes back to or not necessarily how to bring that number down, but why that number tends to rise up can be for a number of reasons, but it also, they tend to all fall in line with the amount of stress and transactions that are being pushed onto the SPs at any given point in time.

You've got very high utilization, very high cache utilization. You'll see the queue length will start to climb up.

If the array is healthy then that queue length should be no more than 4 to 6 or maybe as high as 10 if even that, but you can see it climb up during times of high utilization.

#Performance_Troubleshooting #Response_Time #Queue_Lengths