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

synch/mutex/innodb/buf_pool_mutex

当线程在 InnoDB 缓冲池上获取锁定以访问内存中的页面时,将发生 synch/mutex/innodb/buf_pool_mutex 事件。

相关引擎版本

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

  • Aurora MySQL 版本 2.x,最高 2.09.2

  • Aurora MySQL 版本 1.x,最高 1.23.1

Context

buf_pool 互斥锁是保护缓冲池的控制数据结构的单个互斥锁。

有关更多信息,请参阅 MySQL 文档中的使用性能架构监控 InnoDB 互斥锁等待

等待次数增加的可能原因

这是特定于工作负载的等待事件。synch/mutex/innodb/buf_pool_mutex 显示在主要等待事件中的常见原因包括以下各项:

  • 缓冲池不够大,无法容纳工作数据集。

  • 工作负载更加特定于数据库中特定表中的某些页面,从而导致缓冲池中发生争用。

Actions

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

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

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

在 Amazon 管理控制台中查看主要的 SQL 图表

  1. 通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/rds/

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

  3. 选择一个数据库实例。将为该数据库实例显示性能详情控制面板。

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

  5. Database load(数据库加载)图表下,选择 Top SQL(主要 SQL)。

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

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

使用性能详情

此事件与工作负载有关。您可以使用性能详情执行以下操作:

  • 确定等待事件的开始时间,以及在那段时间内,应用程序日志或相关来源的工作负载是否有任何变化。

  • 识别应对此等待事件负责的 SQL 语句。检查查询的执行计划,以确保这些查询经过优化并且在使用适当的索引。

    如果负责等待事件的主要查询与同一数据库对象或表相关,则考虑对该对象或表进行分区。

创建 Aurora 副本

您可以创建 Aurora 副本以提供只读流量。您还可以使用 Aurora Auto Scaling 来处理读取流量的激增。确保在 Aurora 副本上运行计划的只读任务和逻辑备份。

有关更多信息,请参阅 使用 Amazon Aurora Auto Scaling 扩展 Aurora 副本

检查缓冲池大小

通过查看指标 innodb_buffer_pool_wait_free 来检查缓冲池大小是否足以应付工作负载。如果此指标的值很高且持续增加,则表明缓冲池的大小不足以处理工作负载。如果 innodb_buffer_pool_size 设置正确,innodb_buffer_pool_wait_free 的值应该很小。有关更多信息,请参阅 MySQL 文档中的 Innodb_buffer_pool_wait_free

如果数据库实例有足够的内存用于会话缓冲区和操作系统任务,则增加缓冲池大小。如果没有,请将数据库实例更改为较大的数据库实例类,以获取可分配给缓冲池的额外内存。

注意

Aurora MySQL 基于配置的 innodb_buffer_pool_size 自动调整 innodb_buffer_pool_instances 的值。

监控全局状态历史记录

通过监控状态变量的更改率,您可以检测数据库实例的锁定或内存问题。如果尚未开启“全局状态历史记录”(GoSH),请将其打开。有关 GoSH 的更多信息,请参阅管理全局状态历史记录

您还可以创建自定义 Amazon CloudWatch 指标以监控状态变量。有关更多信息,请参阅发布自定义指标