MySQL :: MySQL 8.3 Reference Manual :: 29.7 Performance Schema Status Monitoring

version 8.3

8.0 current
5.7

8.0 Japanese

MySQL 8.3 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 表示事件丢失或未记录的数量。

例如，如果服务器源代码中instrument了一个互斥锁，但是在运行时无法为仪器分配内存，它将增加 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 个被丢弃或 “lost.” 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 的部分数据。

当服务器无法创建互斥锁仪器时，结果如下：

没有行被插入到 setup_instruments 表中。
Performance_schema_mutex_classes_lost 增加 1。
Performance_schema_mutex_instances_lost 不变。（当互斥锁仪器不被创建时，它不能用于创建仪器互斥锁实例。）

上述模式适用于所有类型的仪器，不仅仅是互斥锁。

如果 Performance_schema_mutex_classes_lost 的值大于 0，可以在两个情况下发生：

为了节省一些内存，服务器可以使用 --performance_schema_max_mutex_classes=N 启动，其中 N 小于默认值。默认值是为了加载 MySQL 分发中的所有插件所选择的，但可以减少如果一些插件从不加载。例如，您可能选择不加载一些存储引擎。
您加载了一个第三方插件，该插件对性能模式进行了仪表，但是在启动服务器时没有考虑到插件的仪表内存要求。由于它来自第三方，因此该引擎的仪表内存消耗不在默认值中被考虑。

如果服务器没有足够的资源来满足插件的仪表需求，并且您没有使用 --performance_schema_max_mutex_classes=N 明确分配更多，那么加载插件将导致仪表饥饿。

如果为 performance_schema_max_mutex_classes 选择的值太小，不会在错误日志中报告错误，也不会在运行时失败。但是，性能模式数据库中的表格内容将缺少事件。Performance_schema_mutex_classes_lost 状态变量是唯一可见的迹象，表明一些事件由于无法创建仪表而被丢弃。

如果仪表没有丢失，它将被性能模式所知晓，并在实例化时使用。例如，wait/synch/mutex/sql/LOCK_delete 是 setup_instruments 表中的一个互斥锁仪表名称。这个单一仪表将在创建互斥锁时使用（在 THD::LOCK_delete 中），无论服务器运行时需要多少个互斥锁实例。在这种情况下，LOCK_delete 是一个每连接（THD）互斥锁，因此如果服务器有 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 了解不同的性能模式选项对内存要求的影响。有关字段含义的描述，请参阅第 15.7.7.16 节，“SHOW ENGINE 语句”。

PREV HOME UP NEXT