PMM supports all commonly used variants of MySQL, including Percona Server, MariaDB, and Amazon RDS. To prevent data loss and performance issues, PMM does not automatically change MySQL configuration. However, there are certain recommended settings that help maximize monitoring efficiency. These recommendations depend on the variant and version of MySQL you are using, and mostly apply to very high loads.
PMM can collect query data either from the slow query log or from Performance Schema. The slow query log provides maximum details, but can impact performance on heavily loaded systems. On Percona Server the query sampling feature may reduce the performance impact.
Performance Schema is generally better for recent versions of other MySQL variants. For older MySQL variants, which have neither sampling, nor Performance Schema, configure logging only slow queries.
MySQL with too many tables can lead to PMM Server overload due to the streaming of too much time series data. It can also lead to too many queries from
mysqld_exporter causing extra load on MySQL. Therefore PMM Server disables most consuming
mysqld_exporter collectors automatically if there are more than 1000 tables.
You can add configuration examples provided below to
restart the server or change variables dynamically using the following syntax:
SET GLOBAL <var_name>=<var_value>
The following sample configurations can be used depending on the variant and version of MySQL:
- If you are running Percona Server (or XtraDB Cluster), configure the slow query log to capture all queries and enable sampling. This will provide the most amount of information with the lowest overhead.
log_output=file slow_query_log=ON long_query_time=0 log_slow_rate_limit=100 log_slow_rate_type=query log_slow_verbosity=full log_slow_admin_statements=ON log_slow_slave_statements=ON slow_query_log_always_write_time=1 slow_query_log_use_global_control=all innodb_monitor_enable=all userstat=1
- If you are running MySQL 5.6+ or MariaDB 10.0+, see Performance Schema.
- If you are running MySQL 5.5 or MariaDB 5.5, configure logging only slow queries to avoid high performance overhead.
log_output=file slow_query_log=ON long_query_time=0 log_slow_admin_statements=ON log_slow_slave_statements=ON
This may affect the quality of monitoring data gathered by Query Analytics.
When adding a MySQL instance to monitoring, you can specify the MySQL server superuser account credentials. However, monitoring with the superuser account is not advised. It’s better to create a user with only the necessary privileges for collecting data.
As an example, the user
pmm can be created manually with the necessary
privileges and pass its credentials when adding the instance.
To enable complete MySQL instance monitoring, a command similar to the following is recommended:
sudo pmm-admin add mysql --username pmm --password <password>
Of course this user should have necessary privileges for collecting data. If
pmm user already exists, you can grant the required privileges as
CREATE USER 'pmm'@'localhost' IDENTIFIED BY 'pass' WITH MAX_USER_CONNECTIONS 10; GRANT SELECT, PROCESS, SUPER, REPLICATION CLIENT, RELOAD ON *.* TO 'pmm'@'localhost';
The default source of query data for PMM is the slow query log. It is available in MySQL 5.1 and later versions. Starting from MySQL 5.6 (including Percona Server 5.6 and later), you can choose to parse query data from the Performance Schema instead of slow query log. Starting from MySQL 5.6.6, Performance Schema is enabled by default.
Performance Schema is not as data-rich as the slow query log, but it has all the critical data and is generally faster to parse. If you are not running Percona Server (which supports sampling for the slow query log), then Performance Schema is a better alternative.
Use of the performance schema is off by default in MariaDB 10.x.
To use Performance Schema, set the
performance_schema variable to
SHOW VARIABLES LIKE 'performance_schema';
+--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | performance_schema | ON | +--------------------+-------+
If this variable is not set to ON, add the the following lines to the
MySQL configuration file
my.cnf and restart MySQL:
If you are running a custom Performance Schema configuration, make sure that the
statements_digest consumer is enabled:
select * from setup_consumers;
+----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | events_stages_current | NO | | events_stages_history | NO | | events_stages_history_long | NO | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | events_transactions_current | NO | | events_transactions_history | NO | | events_transactions_history_long | NO | | events_waits_current | NO | | events_waits_history | NO | | events_waits_history_long | NO | | global_instrumentation | YES | | thread_instrumentation | YES | | statements_digest | YES | +----------------------------------+---------+ 15 rows in set (0.00 sec)
Performance Schema instrumentation is enabled by default in MySQL 5.6.6 and later versions. It is not available at all in MySQL versions prior to 5.6.
If certain instruments are not enabled, you will not see the corresponding graphs in the MySQL Performance Schema dashboard. To enable full instrumentation, set the option
'%=on' when starting the MySQL server.
This option can cause additional overhead and should be used with care.
If the instance is already running, configure the QAN agent to collect data from Performance Schema:
Open the PMM Query Analytics dashboard.
Click the Settings button.
Open the Settings section.
Performance Schemain the Collect from drop-down list.
Click Apply to save changes.
If you are adding a new monitoring instance with the
pmm-admin tool, use the
--query-source perfschema option:
Run this command as root or by using the
pmm-admin add mysql --username=pmm --password=pmmpassword --query-source='perfschema' ps-mysql 127.0.0.1:3306
For more information, run
pmm-admin add mysql --help.
You add MySQL services (Metrics and Query Analytics) with the following command:
pmm-admin add mysql --query-source=slowlog --username=pmm --password=pmm
where username and password are credentials for the monitored MySQL access, which will be used locally on the database host. Additionally, two positional arguments can be appended to the command line flags: a service name to be used by PMM, and a service address. If not specified, they are substituted automatically as
The command line and the output of this command may look as follows:
pmm-admin add mysql --query-source=slowlog --username=pmm --password=pmm sl-mysql 127.0.0.1:3306
MySQL Service added. Service ID : /service_id/a89191d4-7d75-44a9-b37f-a528e2c4550f Service name: sl-mysql
--query-source option can be used to specify it, either as
slowlog (it is also used by default if nothing specified) or as
pmm-admin add mysql --username=pmm --password=pmm --query-source=perfschema ps-mysql 127.0.0.1:3306
Beside positional arguments shown above you can specify service name and service address with the following flags:
--host (the hostname or IP address of the service), and
--port (the port number of the service). If both flag and positional argument are present, flag gains higher priority. Here is the previous example modified to use these flags:
pmm-admin add mysql --username=pmm --password=pmm --service-name=ps-mysql --host=127.0.0.1 --port=3306
It is also possible to add MySQL instance using UNIX socket with use of a special
--socket flag followed with the path to a socket without username, password and network type:
pmm-admin add mysql --socket=/var/path/to/mysql/socket
After adding the service you can view MySQL metrics or examine the added node on the new PMM Inventory Dashboard.
Collecting metrics and statistics for graphs increases overhead. You can keep collecting and graphing low-overhead metrics all the time, and enable high-overhead metrics only when troubleshooting problems.
InnoDB metrics provide detailed insight about InnoDB operation. Although you
can select to capture only specific counters, their overhead is low even when
they all are enabled all the time. To enable all InnoDB metrics, set the
SET GLOBAL innodb_monitor_enable=all
If you are running Percona Server for MySQL, a properly configured slow query log will provide the most amount of information with the lowest overhead. In other cases, use Performance Schema if it is supported.
The first and obvious variable to enable is
slow_query_log which controls the global Slow Query on/off status.
Secondly, verify that the log is sent to a FILE instead of a TABLE. This is controlled with the
By definition, the slow query log is supposed to capture only slow queries. These are the queries the execution time of which is above a certain threshold. The threshold is defined by the
In heavily-loaded applications, frequent fast queries can actually have a much bigger impact on performance than rare slow queries. To ensure comprehensive analysis of your query traffic, set the
long_query_time to 0 so that all queries are captured.
Depending on the amount of traffic, logging could become aggressive and resource consuming. However, Percona Server for MySQL provides a way to throttle the level of intensity of the data capture without compromising information. The most important variable is
log_slow_rate_limit, which controls the query sampling in Percona Server for MySQL. Details on that variable can be found here.
A possible problem with query sampling is that rare slow queries might not get captured at all. To avoid this, use the
slow_query_log_always_write_time variable to specify which queries should ignore sampling. That is, queries with longer execution time will always be captured by the slow query log.
PMM will take care of rotating and removing old slow log files, only if you set the
--size-slow-logs variable via pmm-admin.
When the limit is reached, PMM will remove the previous old slow log file, rename the current file with the suffix
.old, and execute the MySQL command
FLUSH LOGS. It will only keep one old file. Older files will be deleted on the next iteration.
MySQL 8 (in version 8.0.4) changes the way clients are authenticated by
default_authentication_plugin parameter is set to
caching_sha2_password. This change of the default value implies that MySQL
drivers must support the SHA-256 authentication. Also, the communication channel
with MySQL 8 must be encrypted when using
The MySQL driver used with PMM does not yet support the SHA-256 authentication.
With currently supported versions of MySQL, PMM requires that a dedicated MySQL
user be set up. This MySQL user should be authenticated using the
mysql_native_password plugin. Although MySQL is configured to support SSL
clients, connections to MySQL Server are not encrypted.
There are two workarounds to be able to add MySQL Server version 8.0.4 or higher as a monitoring service to PMM:
Alter the MySQL user that you plan to use with PMM
Change the global MySQL configuration
Altering the MySQL User
Provided you have already created the MySQL user that you plan to use with PMM, alter this user as follows:
ALTER USER pmm@'localhost' IDENTIFIED WITH mysql_native_password BY '$eCR8Tp@s$w*rD';
Then, pass this user to
pmm-admin add as the value of the
This is a preferred approach as it only weakens the security of one user.
Changing the global MySQL Configuration
A less secure approach is to set
to the value mysql_native_password before adding it as a
monitoring service. Then, restart your MySQL Server to apply this
- Page updated 2021-01-13