Documentation Home

27.4.2 性能模式事件过滤

事件以生产者/消费者的方式处理:

  • 插桩代码是事件的来源并生成要收集的事件。该 setup_instruments表列出了可以为其收集事件的仪器,它们是否已启用,以及(对于已启用的仪器)是否收集计时信息:

    mysql> SELECT NAME, ENABLED, TIMED
           FROM performance_schema.setup_instruments;
    +---------------------------------------------------+---------+-------+
    | NAME                                              | ENABLED | TIMED |
    +---------------------------------------------------+---------+-------+
    ...
    | wait/synch/mutex/sql/LOCK_global_read_lock        | YES     | YES   |
    | wait/synch/mutex/sql/LOCK_global_system_variables | YES     | YES   |
    | wait/synch/mutex/sql/LOCK_lock_db                 | YES     | YES   |
    | wait/synch/mutex/sql/LOCK_manager                 | YES     | YES   |
    ...

    setup_instruments表提供了对事件生成的最基本控制形式。为了根据正在监视的对象或线程的类型进一步细化事件生成,可以使用其他表,如 第 27.4.3 节,“事件预过滤”中所述。

  • Performance Schema 表是事件和消费事件的目的地。该 setup_consumers表列出了事件信息可以发送到的消费者类型以及它们是否已启用:

    mysql> SELECT * FROM performance_schema.setup_consumers;
    +----------------------------------+---------+
    | NAME                             | ENABLED |
    +----------------------------------+---------+
    | events_stages_current            | NO      |
    | events_stages_history            | NO      |
    | events_stages_history_long       | NO      |
    | events_statements_cpu            | NO      |
    | events_statements_current        | YES     |
    | events_statements_history        | YES     |
    | events_statements_history_long   | NO      |
    | events_transactions_current      | YES     |
    | events_transactions_history      | YES     |
    | events_transactions_history_long | NO      |
    | events_waits_current             | NO      |
    | events_waits_history             | NO      |
    | events_waits_history_long        | NO      |
    | global_instrumentation           | YES     |
    | thread_instrumentation           | YES     |
    | statements_digest                | YES     |
    +----------------------------------+---------+

过滤可以在性能监控的不同阶段进行:

  • 预过滤。  这是通过修改 Performance Schema 配置来完成的,以便仅从生产者收集某些类型的事件,并且收集的事件仅更新某些消费者。为此,启用或禁用仪器或消费者。预过滤由性能模式完成,具有适用于所有用户的全局效果。

    使用预过滤的原因:

    • 以减少开销。即使启用了所有工具,性能模式开销也应该是最小的,但也许你想进一步减少它。或者您不关心时序事件并希望禁用时序代码以消除时序开销。

    • 避免用您不感兴趣的事件填充当前事件或历史表。预过滤在这些表中为启用的仪器类型的行实例留下更多空间” 。如果您仅启用带有预过滤的文件工具,则不会为非文件工具收集任何行。通过后过滤,收集非文件事件,为文件事件留下更少的行。

    • 避免维护某些类型的事件表。如果禁用消费者,则服务器不会花时间维护该消费者的目的地。例如,如果您不关心事件历史记录,则可以禁用历史表消费者以提高性能。

  • 过滤后。  这涉及在WHERE从性能模式表中选择信息的查询中使用子句,以指定您想要查看哪些可用事件。后过滤是在每个用户的基础上执行的,因为各个用户选择感兴趣的可用事件。

    使用后置过滤的原因:

    • 避免为单个用户做出有关哪些事件信息感兴趣的决定。

    • 当事先不知道使用预过滤施加的限制时,使用性能模式来调查性能问题。

以下部分提供了有关预过滤的更多详细信息,并提供了在过滤操作中命名工具或消费者的指南。有关编写查询以检索信息(后过滤)的信息,请参阅 第 27.5 节,“性能模式查询”