Personal blog of Yzmir Ramirez

In Percona Monitoring and Management (PMM) 1.13 we have adopted Prometheus 2, and with this comes a dramatic improvement in resource usage, along with performance improvements!

What does it mean for you? This means you can have a significantly larger number of servers and database instances monitored by the same PMM installation. Or you can reduce the instance size you use to monitor your environment and save some money.

Let’s look at some stats!

CPU Usage

We can see an approximate 5x and 8x reduction of CPU usage on these two PMM Servers. Depending on the workload, we see CPU usage reductions to range between 3x and 10x.

Disk Writes

There is also less disk write bandwidth required:

On this instance, the bandwidth reduction is “just” 1.5x times. Note this is disk IO for the entire PMM system, which includes more than only the Prometheus component. Prometheus 2 itself promises much more significant IO bandwidth reduction according to official benchmarks

According to the same benchmark, you should expect disk space usage reduction by 33-50% for Prometheus 2 vs Prometheus 1.8. The numbers will be less for Percona Monitoring and Management, as it also stores Query Statistics outside of Prometheus.

Resource usage on the monitored hosts

Also, resource usage on the monitored hosts is significantly reduced:

Why does CPU usage go down on a monitored host with a Prometheus 2 upgrade? This is because PMM uses TLS for the Prometheus to monitored host communication. Before Prometheus 2, a full handshake was performed for every scrape, taking a lot of CPU time. This was optimized with Prometheus 2, resulting in a dramatic CPU usage decrease.

Query performance is also a lot better with Prometheus 2, meaning dashboards visually load a lot faster, though we did not do any specific benchmarks here to share the hard numbers. Note though this improvement only applies when you’re querying the data which is stored in Prometheus 2.

If you’re querying data that was originally stored in Prometheus 1.8, it will be queried through the much slower and less efficient “Remote Read” interface, being quite a bit slower and using a lot more CPU and memory resources.

If you love better efficiency and Performance, consider upgrading to PMM 1.13!

The post Resource Usage Improvements in Percona Monitoring and Management 1.13 appeared first on Percona Database Performance Blog.

Please join Percona’s Principal Support Escalation Specialist Sveta Smirnova as she presents Troubleshooting Best Practices: Monitoring the Production Database Without Killing Performance on Wednesday, June 27th at 11:00 AM PDT (UTC-7) / 2:00 PM EDT (UTC-4).

During the MySQL Troubleshooting webinar series, I covered many monitoring and logging tools such as:

• General, slow, audit, binary, error log files
• Performance Schema
• Information Schema
• System variables
• Linux utilities
• InnoDB monitors
• PMM

However, I did not spend much time on the impact these instruments have on overall MySQL performance. And they do have an impact.

And this is the conflict many people face. MySQL Server users try exploring these monitoring instruments, see that they slow down their installations, and turn them off. This is unfortunate. If the instrument that can help you resolve a problem is OFF, you won’t have good and necessary information to help understand when, how and why the issue occurred. In the best case, you’ll re-enable instrumentation and wait for the next disaster occurrence. In the worst case, you try various fix options without any real knowledge if they solve the problem or not.

This is why it is important to understand the impact monitoring tools have on your database, and therefore how to minimize it.

Understanding and controlling the impact of MySQL monitoring tools

In this webinar, I cover why certain monitoring tools affect performance, and how to minimize the impact without turning the instrument off. You will learn how to monitor safely and effectively.

Register Now

Sveta Smirnova

Principal Support Escalation Specialist

Sveta joined Percona in 2015. Her main professional interests are problem-solving, working with tricky issues, bugs, finding patterns that can quickly solve typical issues and teaching others how to deal with MySQL issues, bugs and gotchas effectively. Before joining Percona, Sveta worked as Support Engineer in MySQL Bugs Analysis Support Group in MySQL AB-Sun-Oracle. She is the author of book “MySQL Troubleshooting” and JSON UDF functions for MySQL.

The post Webinar 6/27: MySQL Troubleshooting Best Practices: Monitoring the Production Database Without Killing Performance appeared first on Percona Database Performance Blog.

First, I would like to invite you to my webinar, “Monitoring All (Yes, All!) MySQL Metrics with Percona Cloud Tools,” on Wednesday, June 25 at 10 a.m. Pacific Daylight Time, where I will talk on the
new features in Percona Cloud Tools, including monitoring capabilities.

In this post I’d like to show the cool and interesting things we’ve implemented in Percona Cloud Tools, including the recently released agent that Daniel also talks about here in this post.

Basically our agent allows users to collect ALL MySQL metrics plus important environment’s metrics, like CPU, memory, IO stats.

And when I talk all MySQL it is:

• Metrics from SHOW GLOBAL STATUS (I counted 571 entries on my Percona Server 5.6 with TokuDB)
• Metrics from INFORMATION_SCHEMA.INNODB_METRICS ( 214 entries)
• Data from SHOW GLOBAL VARIABLES ( 522 entries).

So you see we collect more than 1000 points. We collect data every second, aggregate per minute and it becomes available with a 1-minute resolution, but with descriptive stats like min, max, avg, median, 5%-percentile, 95%-percentile of collected data. We found this represents data better than 1-sec points, which can be a quite noisy.

So for example this is how a chart with MySQL command counters looks like:

If you do not have MySQL, in fact, you can just monitor your OS without MySQL if you need to.
For example CPU stats

Please note you can see a value at any point in the past. We even can go to week range and see values several days ago

You can choose a custom timerange back to hours, days, weeks, etc with zoom-in capabilities.

Why do we need avg, min, max stats? Let see Peter’s graph from a server with periodical stalls.

Averaging metric smooths the line, and really hides the problem, while with min we are able to see that throughput drops to zero, that means that during some seconds the server did not execute any queries (which is essentially stalls)

More about the agent.

Our percona-agent is open source. This is our way of sharing our Go knowledge, and also you can check that we do not do anything insane on your server (like bitcoin mining or black magic regression modeling math).

You can see source code here https://github.com/percona/percona-agent:
and pre-compiled binaries are available from our website:

What is also interesting about our technology is that we use a permanent connection (based on WebSockets technology, so it looks like a connection to web browser) between an agent and our servers. This way
we support a bi-directional real-time communication between https://cloud.percona.com/ and an agent.

That means you can manage an agent and receive data updates at the same time. Pretty cool, yeah?

Our agent comes with “minimal efforts” in mind.

• 1. There is minimal efforts to install agent. Basically it takes 3-minutes
  to download binaries, install them, and start seeing real-time updates of charts with MySQL metrics.
• 2. Agent comes with self-update capabilities (not activated at this moment). Later you will need
  to worry if there is new version of agent is available, it will updated itself. We thought if Android Apps can do that, why can’t we?
• 3. Minimal efforts for a maintenance: you do not need to install a dedicated server, configure and maintain database, care about its backups and availability. Basically no more hassle with Cacti configuration and managing a storage for it.

The goal of Percona Cloud Tools is to provide you with FULL visibility on what’s going on inside your system right now or at some point in the past, and to gain additional insights on your database server.

Our tools are useful not only if you have hundreds of database servers to manage, but pretty much for single installations, too. Well, of course, we always can run mysql -e "SHOW GLOBAL STATUS" , vmstat 10 ; iostat -dxm 10 manually when we need to troubleshoot something, but is it not useful to collect all this data automatically and be able to go to any point in the past?

You can register for the Beta right now. No invitation is needed, but it may take sometime for us to activate your account, we see a quite a demand right now and we need to prime our servers.

And what’s important, eventually our tools will require a payment, but we will always provide a free level, which will be useful enough for small accounts (this is not a bait-and-switch 30-days trial approach).

The post From zero to full visibility of MySQL in 3 minutes with Percona Cloud Tools appeared first on MySQL Performance Blog.