When an application runs without any glitches, no one says a thing. However, as soon as the application gets slower in returning results, everyone in the organization wants to know the reasons and resolution. DBAs must have real-time insights into their server. They want to know what is going well and want to know what potentially can go wrong so they can take preventive actions.
If you ask me about the frequency of the performance monitoring, it should be real-time and constant. Constant monitoring of the system may sound impossible, but it is possible. Let us explore a few critical aspects of monitoring.
Server Metrics
Here’s an exciting scenario I have observed at my client’s workplace. The client’s typical complaint was that the server was running slow during the pick business hours. They observed various available resources for the system and identified that the CPU is running very high. They asked their developers to tune the queries to use less CPU. After a few days, they realized that their CPU was not running high, but their system was still slow. A quick look into the system informed me that this is because someone had changed the variable for Max Connection in the config file. It was earlier set to 151 and was changed to 51 recently.
After a while, we checked various picks and valleys in the performance chart. We realized that whenever there was any change in the setting or workload, it directly impacted the other metrics and the performance of the query.
There are many different variables and metrics one should monitor in real-time to get a complete idea of the server. On top of the variables, one should also watch important error metrics to understand if there is any misconfiguration preventing the system performance.
MySQL Alert
(For Events of Interest)
While some metrics are easy to measure, others are difficult to measure and interpret. Any DBA needs to know how many events of interest happened on the server and their potential impact. Another challenge which DBA face is a timely alert of the events. In a large organization, there can be many different platforms and servers. It is humanly impossible for DBA to sit in front of uneventful servers and watch the various metrics. It makes sense to get notified of any event of interest instead of just staring at the computer screen.
There are hundreds of configuration parameters and many queries; it often gets difficult for DBA to keep an eye on the event of interest.
MySQL Performance Schema
The MySQL Performance Schema is a feature for monitoring MySQL Server execution at a low level, and it also inspects the internal execution of the server at runtime. In recent years, I have used performance schema extensively to understand the server’s behaviour and queries. There are many different tables in the performance schema which contain helpful information. I always start my investigation of the server with the help of events_statements_summary_by_digest table, which surfaces many vital metrics for queries and indexes.
Solution:
SQL Diagnostic Manager for MySQLA constant and robust real-time monitoring is required for any database application to run efficiently. DBAs should keep on various metrics and take preventive actions if any negative trend is spotted in the server. I prefer to use SQLDM for MySQL to real-time monitor my database. With the help of various monitoring charts and alert mechanisms, I take action before any potential performance problem arises. SQLDM for MySQL has over 600 monitors and advisors, making DBA life easy and efficient.
