cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 9

Host Max Disk Latency

Hello,

Can someone advise what an acceptable alert level is for Host Max Disk Latency?  We often have many alerts for this due to the default alert of 20ms. 

On the otherhand, the SQL read/write latencies rarely match up to the latencies for Host Max Disk Latency.  Can someone explain the relationship?

Sometimes SQL latencies are fine, HMDL is high, sometimes vice versa. 

Attached is an example screenshot.

Thanks!

0 Kudos
3 Replies
Level 14

We are approaching this from two different vantage points, so they can be very different.

Host Max Disk Latency = We're asking VMware for the high water mark for disk latency as it sees it - if high, this can cause more systemic issues for anything dependent on those datastores/storage.

SQL Latency = We ask SQL over the past 1 minute, what were the number of requests divided by the service time, so it's not a high water mark, but averaged over that 1 minute (don't want to get too granular as that puts more overhead on the system).

So think of the host metric as looking more holistically and SQL as very specific to what your database engine is experiencing.

Having said that, I'd recommend setting your thresholds to values that are important to you (in other words, when would you want to know about potential VMware disk latency that your system is dependent on?). Alerts or turning things red shouldn't just become noise...

HTH.

Thanks for the info! Very interesting. I'm fairly new to DPA, been installed for about 2 months now. That's exactly what I'm doing, trying to reduce the noise. Our disk alerts often go red for the HMDL. So from a SQL perspective, as long as we get good SQL latencies do I need to be concerned about Host Max Disk Latency?  Is there a normal range that people use for alerts or warnings? 

0 Kudos

"Normal" is likely subjective. 8 ) Let me take a step back.

DPA is primarily about the waits. The waits represent your end user or customer pain because something is delayed (waiting).

You could even be experiencing high SQL latency, but no additional waits that customers are observing because very little is being requested. And, you could be having great (low) SQL latency and huge waits because of volume or not enough memory or concurrency (blocking) or ...

My point is, start with the waits, it will always lead you to the right place for performance. As for the rest of it, they can be causes of the longer waits or indicators that things will head south in the future (think high SQL latency as a norm with the introduction of increased I/O requests/volume).

I like your thought process though in eliminating the noise - exactly the way I think. "If I get this alert, what action will I take as a result?" If I'm not sure, I should really think if that's the right alert or if I need to tweak it for something that I really need to see.

As in all things DBA, "It depends."