appsphere 15 - is the database affecting your critical business transactions?

Is the database affecting your critical business transactions? Ian McGuinness Product Manager

A quick history of databases

•  Relational databases have been around since the 70’s –  Oracle released it’s first database in 1978

•  Client/Server Applications evolve –  SQL and Stored Procedure driven

•  Application Complexity increases –  Object Relational Mappings help map relational to OO coded applications

•  Monolithic architecture à Clustered Database e.g. Oracle RAC •  2015

–  “Structured data” still dominated by relational databases e.g. Oracle, SQL Server, MySQL etc. –  NoSQL databases building market share fast e.g. MongoDB, Hadoop

Copyright © 2015 AppDynamics. All rights reserved. 2

Database problems over the years

•  Database problems today aren’t that different to they were 15 years a go!


Bad query performance e.g. Poorly indexed queries

Conflict between users/queries e.g. Batch activities causing lock contention for online users

Capacity Issues e.g. Slow disk not enough IOPS for the needs of the app

Inefficient database configuration parameters e.g. Buffer cache too small

Databases are not static

•  Data is exploding! •  Data production will be 44x greater in 2020 versus 2009* •  App users are generating data all the time

–  Companies are using that data for analytics to drive further sales

•  Biggest growth in unstructured data


* http://www.csc.com/insights/flxwd/78931-big_data_universe_beginning_to_explode

Usage patterns are unregulated

•  Most consumer applications have a loose usage pattern •  Spikes in concurrency may occur any time day or night •  Databases are a shared resource – contention on one part

can affect the whole


INTRODUCING APPDYNAMICS DATABASE MONITORING

DB Agent

SaaS or On-Premise On-Premise

Controller HTTP(S)

AppDynamics Integrated DB Monitoring

Key Features §  Low overhead – Production Safe §  Rapid Installation – Agentless §  Detailed & comprehensive analysis §  Current & historical granular data §  Consolidate web based GUI §  Support for almost all versions of DB2

LUW, MS-SQL, Oracle, Sybase ASE, Sybase IQ, PostgreSQL, MySQL and MongoDB

§  Server Monitoring for Windows, Linux, AIX and Solaris

USE CASE EXAMPLES #1 Long running SQL Queries

Slow Running Application SQL


•  APM can track query response time, but DBMon will tell the user why the query is bad

•  Sometimes business critical queries will fall outside the top few that are actively monitored by the DBA

Slow BT with high query response time

91.3% of time spent in

Oracle call

Detailed Query information in DBMon

Coming to 4.2! – Snapshot Correlation

•  Available for Java à Oracle •  Java BCI tags Oracle sessions with BT ID and GUID •  Allows drilldown from Snapshot Flowmap to specific

queries within DBMon


USE CASE EXAMPLES #2 Poorly configured database

Poorly sized buffer pool (MySQL)

Number of Physical I/O’s to populate cache

Before and After - Buffer Pool Re-size

•  5 minute load tests were run •  Before recommendations we can see 5 mins 34 secs spent in MySQL •  After recommendations we can see just 27 secs of MySQL time •  92% reduction in DB Time!

Coming to 4.2! – Improved Health Rules


•  Create a single health rule which applies to: –  all databases –  all databases of a certain type e.g. MySQL, SQL Server etc.

•  Use Health Rules in Custom Dashboards

DBMon Health Rules

Coming to 4.2! – Custom Dashboards

•  Custom dashboards now available for any DBMon metric


DBMon Custom Dashboard

USE CASE EXAMPLES #3 Capacity & Conflict

I/O Issues

•  Detailed time-series metrics clearly show contention •  Time Spent in DB very high •  Wait State analysis shows PAGEIOLATCH_EX wait •  Host monitoring clearly shows increase in Read IOPS

Locking

34 seconds of Lock Wait Time!

88.8% of all activity time spent in Lock Wait!

USE CASE EXAMPLES #4 NoSQL Performance Issues

Key Concepts of the Solution

•  Collection of metrics is agentless and read-only i.e. No running code on Monitored DB

•  Metrics are collected without the need to install/modify additional components on monitored DB e.g. Modules/Objects etc.

•  Provide historical time-series information on Time spent within DB supplemented by DB specific Metrics

•  Gather information about all DB activity - not just activity resulting from a monitored (with AppD APM) application

Auto-Detection of the Cluster

•  If mongoS then all ReplicaSets in the cluster will be discovered. •  If single ReplicaSet then Primary/Secondaries etc. will be monitored. •  Otherwise standalone mongod

Detailed Time-Series Metrics

Drilldown to problematic Queries

Conclusions

•  Database performance issues will always be around! •  Proactive performance management is what’s needed

–  Use a low overhead 24/7 monitoring solution to gain visibility –  Capture the right type of data to allow rapid root cause analysis and

to prioritize tuning efforts


Thank You

appsphere 15 - is the database affecting your critical business transactions?

Documents