Monitoring Central

2 Posts authored by: mandevil Employee

Looking back through previous content, I came across this post by Jerry Eshbaugh.

 

SQL Server Two Ways - SAM AppInsight for SQL and Database Performance Analyzer

 

I read through it again and realized it still resonates in a big way. I’d like to add this foreword and bring it up to speed given some recent changes. SolarWinds® Database Performance Analyzer (DPA) wait-time statistics and resource metrics were recently added to the Performance Analysis view (lovingly known as PerfStack) in the Orion® Platform. I believe this addition gives IT professionals the end-to-end visibility they want. I know we all tend to exist in silos, but that doesn’t mean we don’t want greater upstream and downstream performance metrics.

 

Now you can easily see if your database performance is impacting application response time, and if storage latency is causing longer I/O related database activities. Also, you can view existing dependencies and what relates to what. These customizable dashboards are way cool!

 

If you haven’t had a chance to check it out, you have a couple of ways to do so:

  • If you own just DPA (without any Orion products), you can now download a standalone DPA Integration Module (DPAIM) from your customer portal as part of your existing license. That’s right! It’s free. You will be limited to DPA data only, as there are no other modules running to collect application, server, storage, and network data, etc.
  • If you already have another Orion product and are on the latest release, DPAIM may be installed (it comes with Server and Application Monitor for example), or you can install the DPAIM module from your customer portal on your Orion Platform.
  • If you aren’t ready to commit to a download, you can check out oriondemo.solarwinds.com and try out the Performance Analysis view. This might be a good start to play around with, but remember, it is demo data. Things may not line up exactly. Some of the data might be invented. The best way to get the most out of the PerfStack dashboard would be to look at your own data with it, which is infinitely more interesting!

 

Let us know what you think about it!

Jogging is my exercise. I use it to tune out noise, focus on a problem at hand, avoid interruptions, and stay healthy. Recently, I was cruising at a comfortable nine-minute pace when four elite runners passed me, and it felt like I was standing still. It got me thinking about the relationship between health and performance. I came to the conclusion that they are related, but more like distant cousins than siblings.

 

I can provide you data that indicates health status: blood pressure, resting heart rate, BMI, body fat percentage, current illnesses, etc. Given all that, tell me: can I run a four-minute mile? That question can’t be answered solely with the data I provided. That’s because I’m now talking about performance versus health.

 

We can also look at health metrics with databases: CPU utilization, I/O stats, memory pressure, etc. However, those also can’t answer the question of how your databases and queries are performing. I’d argue that both health AND performance monitoring and analysis are important. They can impact each other but answer different questions.

 

“What gets measured gets done.” I love this saying and believe that to be true. The tricky part is making sure we’re measuring the right thing to ensure we’re driving the behavior we want.

 

Health is a very mature topic and pretty much all database monitoring solutions offer visibility into it. Performance is another story. I love this definition of performance from Craig Mullins as it relates to databases: “the optimization of resource use to increase throughput and minimize contention, enabling the largest possible workload to be processed.”

 

Interestingly, I believe this definition would be widely accepted, yet approaches to achieving this with monitoring tools varies widely. While I agree with this definition, I’d add “in the shortest possible time” to the end of it. If you agree that you need to consider a time component in regards to database performance, now we’re talking about wait-time analysis. Here’s a white paper that goes into much more detail on this approach and why it is the correct way to think about database performance.

 

We can only get to the right answer regarding root cause if we’re collecting (measuring) the right data in the first place. Below is a chart with some thoughts on data collection requirements. Adapt as needed, but I hope it provides a workable framework.

 

Remember: don’t stop with asking “What can we do?” Take it to the next level and instead ask, “What should we do?”

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.