synch/mutex/innodb/fil_system_mutex - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

synch/mutex/innodb/fil_system_mutex

当会话等待访问表空间内存缓存时,会发生 synch/mutex/innodb/fil_system_mutex 事件。

支持的引擎版本

以下引擎版本支持此等待事件信息:

  • Aurora MySQL 版本 2,最高 2.09.2

  • Aurora MySQL 版本 1,最高 1.23.1

上下文

InnoDB 使用表空间来管理表和日志文件的存储区域。表空间内存缓存是一种全局内存结构,用于维护有关表空间的信息。MySQL 使用 synch/mutex/innodb/fil_system_mutex 等待控制对表空间内存缓存的并发访问。

事件 synch/mutex/innodb/fil_system_mutex 表示当前有多个操作需要检索和操作同一表空间的表空间内存缓存中的信息。

等待次数增加的可能原因

synch/mutex/innodb/fil_system_mutex 事件的发生率超过正常(可能表示性能问题)时,该情况通常会在以下所有条件均存在时发生:

  • 更新或删除同一表中的数据的并发数据操作语言 (DML) 操作增加。

  • 此表的表空间非常大,有很多数据页面。

  • 这些数据页面的填充系数很低。

操作

根据等待事件的原因,我们建议采取不同的操作。

确定导致事件的会话和查询

通常,具有中等到大量负载的数据库都会有等待事件。如果性能最佳,等待事件可能是可以接受的。如果性能不佳,请检查数据库花费最多时间的位置。查看导致最高负载的等待事件,并了解是否可以优化数据库和应用程序以减少这些事件。

查找负责高负载的 SQL 查询

  1. 登录Amazon Web Services Management Console并通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/rds/

  2. 在导航窗格中,选择 Performance Insights

  3. 选择一个数据库实例。该数据库实例的性能详情控制面板出现。

  4. Database load(数据库负载)图表中,选择 Slice by wait(按等待切片)。

  5. 在页面底部,选择 Top SQL(主要 SQL)。

    该图表列出了负责加载的 SQL 查询。排在列表前面的负载负有最大的责任。为了解决瓶颈,请关注这些语句。

有关使用性能详情进行故障排除的有用概览,请参阅博客文章利用性能详情分析 Amazon Aurora MySQL 工作负载

找出哪些查询导致了大量 synch/mutex/innodb/fil_system_mutex 等待的另一个方法是检查 performance_schema,如以下示例所示。

mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G *************************** 1. row *************************** THREAD_ID: 19 EVENT_ID: 195057 END_EVENT_ID: 195057 EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:6700 TIMER_START: 1010146190118400 TIMER_END: 1010146196524000 TIMER_WAIT: 6405600 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: NULL NESTING_EVENT_TYPE: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL *************************** 2. row *************************** THREAD_ID: 23 EVENT_ID: 5480 END_EVENT_ID: 5480 EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:5906 TIMER_START: 995269979908800 TIMER_END: 995269980159200 TIMER_WAIT: 250400 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: NULL NESTING_EVENT_TYPE: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL *************************** 3. row *************************** THREAD_ID: 55 EVENT_ID: 23233794 END_EVENT_ID: NULL EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:449 TIMER_START: 1010492125341600 TIMER_END: 1010494304900000 TIMER_WAIT: 2179558400 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: 23233786 NESTING_EVENT_TYPE: WAIT OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL

在非高峰时段重新组织大型表

重新组织您在生产时间之外的维护时段内识别为大量 synch/mutex/innodb/fil_system_mutex 等待事件的来源的大型表。这样做可以确保在快速访问表至关重要时不会进行内部表空间映射清理。有关重新组织表的信息,请参阅 MySQL 参考中的 OPTIMIZE TABLE 语句