Pmm Mysql agent

[Yunus]

@stofa.kenida

Query_time: 3.061418  Lock_time: 0.000001  Rows_sent: 478  Rows_examined: 478  Rows_affected: 0  Bytes_sent: 24971
Tmp_tables: 0  Tmp_disk_tables: 0  Tmp_table_sizes: 0
Full_scan: Yes  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
Filesort: No  Filesort_on_disk: No  Merge_passes: 0
No InnoDB statistics available for this query
Log_slow_rate_type: query  Log_slow_rate_limit: 100
SET timestamp=1790138862;
SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT
FROM performance_schema.events_waits_summary_global_by_event_name;

Looking at your slow query log, the query examines only 478 rows. Even though it performs a full table scan, 3 seconds seems unusually high for such a small result set. We should investigate what is causing the delay.

You can try Kedar’s suggestion as well.

On top of that,

SELECT COUNT(*) AS total_mutex_instances FROM performance_schema.mutex_instances;

SELECT NAME, COUNT(*) AS instances FROM performance_schema.mutex_instances GROUP BY NAME ORDER BY instances DESC LIMIT 20;

A related Percona discussion reports growth in LOCK_ticket_store_ops mutex instances. We can try to determine whether the same pattern exists on PXC 8.0.39. MySQL documents mutex_instances as the table listing mutexes observed by Performance Schema.

The number of wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops in mutex_instances is constantly growing

@anil.joshi Sorry for the long response. Yes, the growing number of records in performance_schema.mutex_instances leads to serious problems, as each record in the performance_schema.mutex_instances table also creates a corresponding record in the performance_schema.events_waits_summary_global_by_event_name table. With PMM installed and the recommended settings, PMM makes a high-frequency query to the performance_schema.events_waits_summary_global_by_event_name table, which looks like this: SE…

There was bug reported for that

https://perconadev.atlassian.net/browse/PXC-5310

Also check this

SHOW GLOBAL STATUS LIKE 'Performance_schema_mutex_instances_lost';

SHOW GLOBAL VARIABLES LIKE 'performance_schema_max_mutex_instances';

This is to try to check whether the slow query is related to mutex-instance growth or whether another factor is responsible. Since you’re running PXC 8.0.39, the issue was reported for v8.0.42.

Also if you have any other instance (replica), does this query takes same amount of time on that instance as well?

Is there any possibility to restart the mysql in maintenance window and see if the query behaves same?