MySQL Profiling
MySQL Profiling
Database Profiling for MariaDB and Percona Server

Both MariaDB and Percona Server serve as MySQL replacements from an api compatibility, binary and command line perspective. Having an alternative is simply great as anything can happen in the future.

The Setup

Installing both MariaDB and Percona Server onto test instances is pretty simple. In this example, two Red Hat Enterprise Linux (RHEL) servers operate on Amazon Web Services (AWS).

When it comes to installing Percona and MariaDB Server, you need to create yum repository files (detailed here and here) and operate the yum installation commands. This gets the binaries installed. The remaining process is about starting and configuring the individual database servers.

The startup command for MariaDB and Percona Server is “/etc/init.d/mysql start”. This shows that both the products directly drop in adherence to MySQL. The below screen shows this example with MariaDB 10.0.3 and Percona Server 5.5.31-30.3.

Screen Shot 2013-07-01 at 2.21.48 PM Screen Shot 2013-07-01 at 2.23.30 PM

Each of the databases is connected to 1 instance of Drupal and 1 instance of WordPress in an almost “out of the box” configuration. Moreover, it adds a few new posts to each CMS to drive a small amount of load. This example doesn't set up a load testing tool and hence a huge disk I/O load on each server is brought on by operating the UNIX command “cat /dev/zero > /tmp/zerofile”. The Unix command swiftly puts the number 0 into that file that primarily crushes the disk. (to erase this command before you fill your disk, use Ctrl-C .)

The Profiling

The profiling set up is done very easily. Here a test instance of AppDynamics for Databases was used to remotely profile the Databases console and navigate to the agent manager. Click the button “add agent” , and fill the fields as given below (Here MySQL as the database type):

Screen Shot 2013-07-01 at 3.39.47 PM

The remote agent didn’t connect the first time even though the AWS firewall rules had been set up properly (facepalm)because in this example the iptables were not configured to let the connection through. Once the iptables are dealt with properly (just turned off since these were test instances), your database monitoring connections would come to life.

The Result

AppDynamics for Databases is 100% consistent with MariaDB and Percona Server. A look at the data shows that there are no errors and is everything that it should be.

Inducing disk I/O load by clicking all over the web interface of Drupal and WordPress shows that it brings slow response times. Here are a few screen shots for each database type for you to examine…

MariaDB Activity

Activity screen for the MariaDB database.

Percona Activity

Activity screen for the Percona database.

MariaDB Explain Statement

Explain statement for a particular statement in MariaDB.

Percona Explain Statement

Explain statement for a particular

statement in Percona.

MariaDB Statistics

A few statistics charts for MariaDB.

Percona Statistics

A couple of statistics charts for Percona.

If you’re running MySQL, you can see performance improvements by using MariaDB and Percona Server. This is because the storage engine for Percona and MariaDB is XtraDB and not InnoDB. Thus having choices in technology is truly helpful. If there is a unified monitoring platform for your MySQL, SQL Server, MariaDB, Sybase, Percona Server, IBM DB2, Oracle, and PostgreSQL database, it is even better.

Get started with AppDynamics for Databases free trial.