Documentation Home
MySQL 8.4 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 39.8Mb
PDF (A4) - 39.9Mb
Man Pages (TGZ) - 257.9Kb
Man Pages (Zip) - 364.9Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 8.4 Reference Manual  /  MySQL Performance Schema  /  Performance Schema Status Monitoring

29.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_lost 表示无法加载 xxx 类型的仪表板数量。

  • Performance_schema_xxx_instances_lost 表示无法创建 xxx 对象类型的实例数量。

  • Performance_schema_xxx_handles_lost 表示无法打开 xxx 对象类型的实例数量。

  • Performance_schema_locker_lost 表示有多少事件是 "丢失”” 或未记录。

例如,如果服务器在运行时无法为某个互斥量分配内存来进行仪表板化,它将增加 Performance_schema_mutex_classes_lost。虽然互斥量仍然作为同步对象(即服务器继续正常运行),但对其的性能数据不被收集。如果仪表板可以分配,它可以用于初始化已仪表板化的互斥量实例。对于单例互斥量,如全局互斥量,只有一个实例。其他互斥量每个连接或缓存和数据缓冲区中的页面都有一个实例,因此实例数量随时间变化。如果服务器无法创建给定已仪表板化的互斥量实例,它将增加 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_lost 表示丢失的互斥量(类别)数量:

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数据库中的表内容会缺失事件。Performance_schema_mutex_classes_lost状态变量是唯一的可见迹象,表明由于无法创建仪器内部有事件被丢弃。

如果一个仪器没有丢失,它就知道性能方案,并在创建时使用它。例如,wait/synch/mutex/sql/LOCK_deletesetup_instruments表中的一个互斥量仪器。这一单个仪器在代码中创建互斥量时使用(例如,在THD::LOCK_delete中),但服务器运行时需要的互斥量实例数量无限。例如,如果服务器有1000个连接,那么就有1000个线程,并且有1000个被监控的LOCK_delete互斥量实例(即THD::LOCK_delete)。

如果服务器没有为所有这些1000个被监控的互斥量实例分配足够的内存,那么一些互斥量会以不带仪器的形式创建,而另一些则会以带有仪器的形式创建。如果服务器只能创建800个实例,200个实例就会丢失。服务器继续运行,但将Performance_schema_mutex_instances_lost增加200,以指示无法创建实例。

如果Performance_schema_mutex_instances_lost的值大于0,可能是因为代码在运行时初始化了更多互斥量实例,而这些实例没有为--performance_schema_max_mutex_instances=N分配的内存。

总结来说,如果SHOW STATUS LIKE 'perf%'说没有丢失(所有值都是零),那么性能方案数据是准确的,可以依赖它。如果有丢失,数据是不完整的,性能方案无法记录一切给定的内存不足的情况。在这种情况下,特定的Performance_schema_XXX_lost变量指出了问题区域。

在某些情况下,可能会有故意的仪器饥饿。例如,如果你不关心性能数据中的文件I/O,你可以使用所有与文件I/O相关的性能方案参数设置为0。没有为文件相关类、实例或句柄分配内存,因此所有文件事件都丢失了。

使用SHOW ENGINE PERFORMANCE_SCHEMA STATUS来检查性能方案代码的内部操作:

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理解不同性能方案选项对内存需求的影响。有关字段含义的描述,请参阅Section 15.7.7.16, “SHOW ENGINE Statement”