# PXC 8.4.6: LOCK\_ticket\_store\_ops mutex instances grow with cumulative connections **URL:** \ **Category:** MySQL & MariaDB\ **Tags:** pmm, mysql, percona\ **Created:** [August 24, 2026, 9:46pm UTC](https://forums.percona.com/t/pxc-8-4-6-lock-ticket-store-ops-mutex-instances-grow-with-cumulative-connections/41203 "2026-08-24T21:46:10Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Wu\_Nan\_Lin](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/wu_nan_lin/32/24193_2.png) [@Wu\_Nan\_Lin](https://forums.percona.com/u/Wu_Nan_Lin)\ **Post date:** [August 24, 2026, 9:46pm UTC](https://forums.percona.com/t/pxc-8-4-6-lock-ticket-store-ops-mutex-instances-grow-with-cumulative-connections/41203/1 "2026-08-24T21:46:11Z")
Hello Percona team, We are seeing continuous growth of this Performance Schema mutex instance on a three-node staging PXC cluster: ```plaintext wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops ``` ### Environment ```plaintext PXC: 8.4.6-6.1 Performance Schema: enabled performance_schema_max_mutex_instances: -1 (autoscaled, before mitigation) Monitoring: PMM / mysqld_exporter perf_schema.eventswaits collector ``` ### Related report This appears related to the following PXC 8.0.42-33.1 report: > [@The number of wait/synch/mutex/sql/MDL\_ticket\_store::LOCK\_ticket\_store\_ops in mutex\_instances is constantly growing](https://forums.percona.com/t/the-number-of-wait-synch-mutex-sql-mdl-ticket-store-lock-ticket-store-ops-in-mutex-instances-is-constantly-growing/39571): > > Hello! I have a Percona xtradb Cluster 8.0.42-33.1 cluster installed using percona-operator 1.18.0. I’ve noticed a steady increase in the number of rows in performance\_schema.mutex\_instances with NAME=wait/synch/mutex/sql/MDL\_ticket\_store::LOCK\_ticket\_store\_ops. It’s growing by 250K rows per day. There’s almost no load on the cluster. What could be causing this? In that thread, the growth was reproduced and correlated with repeated short-lived monitor/health-check connections. The reporter also observed the PMM wait-summary query becoming slow and used `performance_schema_max_mutex_instances=20000` as a workaround. However, the thread does not identify a public bug ID, confirmed root cause, or fixed version. ### Evidence from PXC 8.4.6 Before restarting one staging node: ```plaintext performance_schema.mutex_instances total: 1,048,716 LOCK_ticket_store_ops instances: 1,036,214 (98.8%) Performance_schema_mutex_instances_lost: 16,926,214 ``` After restart, the target count returned to approximately 200 and `Performance_schema_mutex_instances_lost` returned to 0. During a four-minute observation after restart: ```plaintext Connections: 131 -> 192 (+61) LOCK_ticket_store_ops: 210 -> 271 (+61) mutex_instances total: 2,811 -> 2,872 (+61) ``` The target instance count increased exactly with cumulative connections and did not return to the previous baseline after those short-lived sessions ended. The PMM monitoring user repeatedly issued: ```sql SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_waits_summary_global_by_event_name; ``` Example slow-log result: ```plaintext Query_time: 1.688297 Rows_sent: 473 Rows_examined: 473 Full_scan: Yes ``` We confirmed that this query is issued by the PMM/mysqld\_exporter `perf_schema.eventswaits` collector. We are reporting an observed correlation between the accumulated instances and query cost, not claiming that the global summary returns one row per mutex instance. The global summary contains one row per event name. ### Additional test We restarted a staging node with: ```ini performance-schema-instrument='wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops=OFF' ``` The instrument then reported `ENABLED=NO` and `TIMED=NO`, but its instance count still increased 1:1 with `Connections`. This disabled collection/timing but did not prevent instance registration. We also inspected the PXC `release-8.4.6`, `release-8.4.10-10`, and `8.4` branches. We found initialization of `m_LOCK_ticket_store_ops`, but did not find a corresponding `mysql_mutex_destroy()` in `sql/mdl.cc` or `sql/mdl.h`. This is an observation for confirmation, not a concluded root cause. ### Temporary mitigations - Disabling only `perf_schema.eventswaits` stopped the monitoring query but removed the related wait-event metrics. - Setting `performance_schema_max_mutex_instances=20000` bounded memory use, but it affects all mutex instruments. Once full, `Performance_schema_mutex_instances_lost` increases and mutex observability becomes incomplete. It is not FIFO. ### Questions 1. Is this a known PXC defect, and is there a public issue ID? 2. Is it fixed in PXC 8.4.7, 8.4.8, 8.4.10, or a later release? 3. Is the absence of a visible matching `mysql_mutex_destroy()` intentional, or is the mutex destroyed elsewhere? 4. What mitigation and `performance_schema_max_mutex_instances` sizing does Percona recommend while retaining observability? Thank you. ---
**Author:** ![anil.joshi](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/anil.joshi/32/13100_2.png) [@anil.joshi](https://forums.percona.com/u/anil.joshi)\ **Post date:** [August 25, 2026, 7:08am UTC](https://forums.percona.com/t/pxc-8-4-6-lock-ticket-store-ops-mutex-instances-grow-with-cumulative-connections/41203/2 "2026-08-25T07:08:34Z")
@Wu_Nan_Lin Yes, the similar issue was reproducible on this thread - [The number of wait/synch/mutex/sql/MDL\_ticket\_store::LOCK\_ticket\_store\_ops in mutex\_instances is constantly growing - #4 by anil.joshi](https://forums.percona.com/t/the-number-of-wait-synch-mutex-sql-mdl-ticket-store-lock-ticket-store-ops-in-mutex-instances-is-constantly-growing/39571/4) however that was simply observed with the **usual health check and operator monitoring process** where the session connects and monitor the cluster node without running any additional workload etc. E.g, ```auto mysql> show processlist; +------+----------------------+--------------------------------------------------------------------------+------+---------+------+--------------------------+------------------+---------+-----------+---------------+ | Id | User | Host | db | Command | Time | State | Info | Time_ms | Rows_sent | Rows_examined | +------+----------------------+--------------------------------------------------------------------------+------+---------+------+--------------------------+------------------+---------+-----------+---------------+ | 1 | system user | | NULL | Sleep | 1094 | wsrep: aborter idle | NULL | 1093398 | 0 | 0 | | 2 | system user | | NULL | Sleep | 1094 | innobase_commit_low (-1) | NULL | 1093398 | 0 | 0 | | 8 | event_scheduler | localhost | NULL | Daemon | 1094 | Waiting on empty queue | NULL | 1093148 | 0 | 0 | | 11 | system user | | NULL | Sleep | 1094 | wsrep: applier idle | NULL | 1093142 | 0 | 0 | | 480 | root | cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local:52740 | NULL | Query | 0 | init | show processlist | 0 | 0 | 0 | **| 2223 | unauthenticated user | cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local:46356 | NULL | Connect | 0 | login | NULL | 42 | 0 | 0 |** +------+----------------------+--------------------------------------------------------------------------+------+---------+------+--------------------------+------------------+---------+-----------+---------------+ 6 rows in set, 1 warning (0.00 sec) ``` ```auto |2025-11-14T12:52:34.467195Z| 4170 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on using SSL/TLS| |2025-11-14T12:52:34.612264Z| 4171 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on mysql using SSL/TLS| |2025-11-14T12:52:35.004880Z| 4174 Connect|monitor@cluster1-pxc-0.cluster1-pxc.pxc-operator.svc.cluster.local on using SSL/TLS| |2025-11-14T12:52:35.012697Z| 4175 Connect|monitor@cluster1-pxc-0.cluster1-pxc.pxc-operator.svc.cluster.local on using SSL/TLS| ``` Is your environment is also based on **PXC /K8s operator**? Is that spike you noticed just increasing from the PMM monitoring along without running any other operations on the cluster. What I mean is the cluster idle around that period ? Increasing **performance\_schema\_max\_mutex\_instances** doesn’t seems to be a solution rather a workaround for temporary mitigation. I’ll check this with the Dev or Internal team to get more clarity and then accordingly update you. ---
**Author:** ![Wu\_Nan\_Lin](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/wu_nan_lin/32/24193_2.png) [@Wu\_Nan\_Lin](https://forums.percona.com/u/Wu_Nan_Lin)\ **Post date:** [August 25, 2026, 8:22am UTC](https://forums.percona.com/t/pxc-8-4-6-lock-ticket-store-ops-mutex-instances-grow-with-cumulative-connections/41203/3 "2026-08-25T08:22:20Z")
Hi @anil.joshi Thanks for checking with the development team. Our environment is a three-node PXC cluster running on vSphere VMs, not Kubernetes or the PXC Operator. Each VM has 4 vCPUs and 16 GB RAM. The cluster was idle, with no application workload, DDL, or manual testing. Load appeared only when the PMM/mysqld\_exporter `perf_schema.eventswaits` collector ran: ![260824_1](https://media.wnlin.org/i/d5452ebc-2b47-41ab-ad62-09f5cad9a799) We agree that `performance_schema_max_mutex_instances=20000` is only a temporary mitigation. Thank you for checking whether this mutex lifecycle behavior is a known issue or fixed in a later PXC release. ---
**Author:** ![anil.joshi](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/anil.joshi/32/13100_2.png) [@anil.joshi](https://forums.percona.com/u/anil.joshi)\ **Post date:** [August 25, 2026, 1:41pm UTC](https://forums.percona.com/t/pxc-8-4-6-lock-ticket-store-ops-mutex-instances-grow-with-cumulative-connections/41203/4 "2026-08-25T13:41:56Z")
@Wu_Nan_Lin I tested with PXC **8.4.10-10.1** and can see gradual increases in mutex\_instances. These are directly related to regular client connections, background threads, and monitoring, etc. `mysql> select * from performance_schema.mutex_instances where name like '%LOCK_ticket_store_ops%';` ```auto | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140177129374368 | NULL | | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140176526040304 | NULL | | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140176526040304 | NULL | | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140176526040304 | NULL | | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140177129374368 | NULL | | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140177129374368 | NULL | | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140177129374368 | NULL | | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140177129374368 | NULL | | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140177129374368 | NULL | | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 140177129374368 | NULL | +--------------------------------------------------------------+-----------------------+---------------------+ 110 rows in set (0.01 sec) ``` Under **table: events\_waits\_summary\_global\_by\_event\_name** this similar information shows as an aggregated output. ```auto mysql> select \* from performance_schema.events_waits_summary_global_by_event_name where EVENT_NAME like '%LOCK_ticket_store_ops%'; +--------------------------------------------------------------+------------+----------------+----------------+----------------+----------------+ | EVENT_NAME | COUNT_STAR | SUM_TIMER_WAIT | MIN_TIMER_WAIT | AVG_TIMER_WAIT | MAX_TIMER_WAIT | +--------------------------------------------------------------+------------+----------------+----------------+----------------+----------------+ | wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 664 | 106355160 | 45600 | 160056 | 692208 | +--------------------------------------------------------------+------------+----------------+----------------+----------------+----------------+ 1 row in set (0.03 sec) ``` As this table aggregates as per event, it won’t increment that high. It will be limited to the captured **EVENT\_NAME** only. ```auto mysql> select count(\*) from performance_schema.events_waits_summary_global_by_event_name; +----------+ | count(\*) | +----------+ | 474 | +----------+ 1 row in set (0.02 sec) ``` Well, in PMM, you can also disable specific collectors in the exporter if you don’t need them. ` **--disable-collectors=perf_schema.eventswaits** ` This will avoid running the query at regular intervals and reduce stress on the database. ```auto SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_waits_summary_global_by_event_name ``` > **[Collectors - Percona Monitoring and Management - Manage inventory](https://docs.percona.com/percona-monitoring-and-management/3/use/commands/pmm-admin/inventory.html#collectors)** > > Use pmm-admin inventory from the command line to list registered services and agents, and modify agent configurations without removing and re-adding services. I have additionally raised a Jira - [https://perconadev.atlassian.net/browse/PXC-5310](https://perconadev.atlassian.net/browse/PXC-5310) regarding this issue. It’s most likely to be handled by the destroyer thread or released at some point rather than accumulating forever. You can track the Jira for any further updates on this. ---
**Author:** ![Wu\_Nan\_Lin](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/wu_nan_lin/32/24193_2.png) [@Wu\_Nan\_Lin](https://forums.percona.com/u/Wu_Nan_Lin)\ **Post date:** [August 25, 2026, 2:11pm UTC](https://forums.percona.com/t/pxc-8-4-6-lock-ticket-store-ops-mutex-instances-grow-with-cumulative-connections/41203/5 "2026-08-25T14:11:31Z")
Hi @anil.joshi, Thank you for reproducing this on PXC 8.4.10-10.1 and raising PXC-5310. We appreciate that the issue has entered the Jira investigation stage and will track it for further updates. With our current mysqld\_exporter version, we confirmed that `–no-collect.perf_schema.eventswaits` stops the periodic query and mitigates the observed database load, and we have already applied it. This is only a temporary mitigation, not a root-cause fix. Reference: [MySQL 可觀測性成本：PMM Collector、Performance Schema 與 Mutex 累積 — Wu-Nan Lin](https://ink.wnlin.org/posts/mysql-observability-performance-schema-cost/) Many thanks again, Anil, for your help and continued follow-up.