• 首页
  • css3教程
  • html5教程
  • jQuery手册
  • vue手册
  • php手册
  • MySQL手册
  • apache手册
  • redis手册
  • 使用性能模式诊断问题

    Performance Schema是一种工具,它通过进行实际测量而不是“疯狂的猜测”来帮助DBA进行性能调整。”这一节演示了为此目的使用性能模式的一些方法。这里的讨论依赖于事件过滤的使用,“性能模式事件过滤”中对此进行了描述。

    以下示例提供了一种可用于分析可重复问题的方法,例如调查性能瓶颈。首先,您应该有一个可重复的用例,其中性能被认为“太慢”并且需要优化,并且应该启用所有检测(根本不进行预过滤)。

    1. 运行用例。
    2. 使用性能架构表,分析性能问题的根本原因。该分析将严重依赖于后过滤。
    3. 对于排除的问题区域,请禁用相应的仪器。例如,如果分析表明问题与特定存储引擎中的文件I / O不相关,请禁用该引擎的文件I / O工具。然后截断历史记录和摘要表以删除以前收集的事件。
    4. 重复步骤1的过程。

      在每次迭代中,“性能模式”输出(尤其是events_waits_history_long表)将包含越来越少的由不重要的仪器引起的“噪声”,并且鉴于此表具有固定的大小,因此将包含与问题分析相关的越来越多的数据。手。

      在每次迭代中,随着“信噪比”的提高,调查应越来越接近问题的根本原因,从而使分析更加容易。

    5. 一旦确定了性能瓶颈的根本原因,请采取适当的纠正措施,例如:

      • 调整服务器参数(高速缓存大小,内存等)。
      • 通过不同的方式调整查询,
      • 调整数据库模式(表,索引等)。
      • 调整代码(仅适用于存储引擎或服务器开发人员)。
    6. 从步骤1重新开始,以参见更改对性能的影响。

    mutex_instances.LOCKED_BY_THREAD_IDrwlock_instances.WRITE_LOCKED_BY_THREAD_ID列调查性能瓶颈或死锁非常重要的。可以通过Performance Schema工具来实现此目的,如下所示:

    1. 假设线程1处于等待互斥的状态。
    2. 您可以确定线程正在等待什么:

      SELECT * FROM performance_schema.events_waits_current
      WHERE THREAD_ID = thread_1;
      

      假设查询结果标识该线程正在等待互斥体A(在中找到)events_waits_current.OBJECT_INSTANCE_BEGIN

    3. 您可以确定哪个线程持有互斥量A:

      SELECT * FROM performance_schema.mutex_instances
      WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
      

      假设查询结果表明它是持有互斥锁A的线程2,如中所找到mutex_instances.LOCKED_BY_THREAD_ID

    4. 您可以看到线程2在做什么:

      SELECT * FROM performance_schema.events_waits_current
      WHERE THREAD_ID = thread_2;