25.7 性能架构状态监视

与性能模式关联的状态变量有几个:

mysql> SHOW STATUS LIKE 'perf%';
+-----------------------------------------------+-------+
| Variable_name                                 | Value |
+-----------------------------------------------+-------+
| Performance_schema_accounts_lost              | 0     |
| Performance_schema_cond_classes_lost          | 0     |
| Performance_schema_cond_instances_lost        | 0     |
| Performance_schema_digest_lost                | 0     |
| Performance_schema_file_classes_lost          | 0     |
| Performance_schema_file_handles_lost          | 0     |
| Performance_schema_file_instances_lost        | 0     |
| Performance_schema_hosts_lost                 | 0     |
| Performance_schema_locker_lost                | 0     |
| Performance_schema_memory_classes_lost        | 0     |
| Performance_schema_metadata_lock_lost         | 0     |
| Performance_schema_mutex_classes_lost         | 0     |
| Performance_schema_mutex_instances_lost       | 0     |
| Performance_schema_nested_statement_lost      | 0     |
| Performance_schema_program_lost               | 0     |
| Performance_schema_rwlock_classes_lost        | 0     |
| Performance_schema_rwlock_instances_lost      | 0     |
| Performance_schema_session_connect_attrs_lost | 0     |
| Performance_schema_socket_classes_lost        | 0     |
| Performance_schema_socket_instances_lost      | 0     |
| Performance_schema_stage_classes_lost         | 0     |
| Performance_schema_statement_classes_lost     | 0     |
| Performance_schema_table_handles_lost         | 0     |
| Performance_schema_table_instances_lost       | 0     |
| Performance_schema_thread_classes_lost        | 0     |
| Performance_schema_thread_instances_lost      | 0     |
| Performance_schema_users_lost                 | 0     |
+-----------------------------------------------+-------+

性能架构状态变量提供有关由于内存限制而无法加载或创建的检测的信息。这些变量的名称具有几种形式:

  • Performance_schema_xxx_classes_losttable 示无法加载* xxx *类型的仪器。

  • Performance_schema_xxx_instances_losttable 示无法创建多少个对象类型* xxx *实例。

  • Performance_schema_xxx_handles_losttable 示无法打开多少个对象类型* xxx *实例。

  • Performance_schema_locker_lost指示“丢失”或未记录多少事件。

例如,如果在服务器源中插入了互斥锁,但服务器在运行时无法为该分配分配内存,则它将递增Performance_schema_mutex_classes_lost。互斥锁仍充当同步对象(即服务器 continue 正常运行),但是不会收集其性能数据。如果可以分配工具,则可以将其用于初始化已检测的互斥实例。对于单例互斥锁(例如全局互斥锁),将只有一个实例。其他互斥锁在每个连接或每个页面在各种缓存和数据缓冲区中都有一个实例,因此实例的数量随时间而变化。增加最大连接数或某些缓冲区的最大大小将增加可能一次分配的最大实例数。如果服务器无法创建给定的检测 Mutex 实例,则它将递增Performance_schema_mutex_instances_lost

假设满足以下条件:

  • 该服务器以--performance_schema_max_mutex_classes=200选项启动,因此可以容纳 200 个互斥乐器。

  • 150 互斥乐器已经加载。

  • 名为plugin_a的插件包含 40 个互斥乐器。

  • 名为plugin_b的插件包含 20 种互斥乐器。

服务器根据需要的插件数量和可用的插件数量为插件分配互斥工具,如以下语句序列所示:

INSTALL PLUGIN plugin_a

服务器现在有 150 40 = 190 个互斥工具。

UNINSTALL PLUGIN plugin_a;

服务器仍然有 190 台仪器。插件代码生成的所有历史数据仍然可用,但未收集仪器的新事件。

INSTALL PLUGIN plugin_a;

服务器检测到已经定义了 40 种工具,因此没有创建新工具,并且先前分配的内部存储器缓冲区被重用。服务器仍然有 190 台仪器。

INSTALL PLUGIN plugin_b;

服务器有 200-190 = 10 种乐器的空间(在本例中为互斥类),并且该插件包含 20 种新乐器。装入了 10 个仪器,有 10 个被丢弃或“丢失”。 Performance_schema_mutex_classes_losttable 示丢失的乐器(互斥类)数量:

mysql> SHOW STATUS LIKE "perf%mutex_classes_lost";
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| Performance_schema_mutex_classes_lost | 10    |
+---------------------------------------+-------+
1 row in set (0.10 sec)

该工具仍然有效,并收集plugin_b的(部分)数据。

当服务器无法创建互斥量工具时,将出现以下结果:

刚刚描述的模式适用于所有类型的乐器,而不仅仅是互斥。

在两种情况下,可能会发生Performance_schema_mutex_classes_lost大于 0 的值:

  • 要节省一些字节的内存,请使用--performance_schema_max_mutex_classes=N启动服务器,其中* N *小于默认值。选择默认值足以加载 MySQL 发行版中提供的所有插件,但是如果从不加载某些插件,则可以降低默认值。例如,您可能选择不加载分发中的某些存储引擎。

  • 您加载了为性能模式进行检测的第三方插件,但是在启动服务器时不允许该插件的检测内存要求。由于它来自第三方,因此未在为performance_schema_max_mutex_classes选择的默认值中考虑此引擎的仪器内存消耗。

如果服务器没有足够的资源来使用插件的工具,而您没有使用--performance_schema_max_mutex_classes=N显式分配更多资源,则加载插件会导致工具短缺。

如果为performance_schema_max_mutex_classes选择的值太小,则错误日志中不会报告错误,并且在运行时也不会失败。但是,performance_schema数据库中 table 的内容将丢失事件。状态变量Performance_schema_mutex_classes_lost是唯一可见的迹象,table 明某些事件由于无法创建工具而在内部被丢弃。

如果没有丢失一种工具,则性能架构将知道该工具,并在检测实例时使用它。例如,wait/synch/mutex/sql/LOCK_deletesetup_instrumentstable 中互斥工具的名称。在代码中(THD::LOCK_delete中)创建互斥锁时会使用该工具,但是在服务器运行时需要许多互斥锁实例。在这种情况下,LOCK_delete是每个连接(THD)的互斥锁,因此,如果服务器有 1000 个连接,则有 1000 个线程和 1000 个检测的LOCK_delete互斥锁实例(THD::LOCK_delete)。

如果服务器没有足够的空间容纳所有这 1000 个已检测到的互斥锁(实例),则某些互斥锁是通过检测创建的,而有些互斥锁是在没有检测的情况下创建的。如果服务器只能创建 800 个实例,则会丢失 200 个实例。服务器 continue 运行,但是将Performance_schema_mutex_instances_lost增加 200 以指示无法创建实例。

当代码在运行时初始化的互斥量比为--performance_schema_max_mutex_instances=N分配的互斥量大时,Performance_schema_mutex_instances_lost的值可能大于 0.

最重要的是,如果显示状态,例如“ perf%”说什么也没丢失(所有值均为零),则性能模式数据是准确的并且可以依赖。如果丢失了某些内容,则数据将不完整,并且由于分配给它的内存不足,因此性能架构无法记录所有内容。在这种情况下,特定的Performance_schema_xxx_lost变量指示问题区域。

在某些情况下,可能会导致故意的仪器饥饿。例如,如果您不关心文件 I/O 的性能数据,则可以在将与文件 I/O 相关的所有性能模式参数设置为 0 的情况下启动服务器。不会为与文件相关的类,实例,或句柄,所有文件事件都将丢失。

使用显示引擎 PERFORMANCE_SCHEMA 状态检查性能模式代码的内部操作:

mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G
...
*************************** 3. row ***************************
  Type: performance_schema
  Name: events_waits_history.size
Status: 76
*************************** 4. row ***************************
  Type: performance_schema
  Name: events_waits_history.count
Status: 10000
*************************** 5. row ***************************
  Type: performance_schema
  Name: events_waits_history.memory
Status: 760000
...
*************************** 57. row ***************************
  Type: performance_schema
  Name: performance_schema.memory
Status: 26459600
...

该语句旨在帮助 DBA 了解不同的“性能模式”选项对内存要求的影响。有关字段含义的描述,请参见第 13.7.5.15 节“ SHOW ENGINE 语句”