有几个与性能架构相关的状态变量:
mysql> SHOW STATUS LIKE 'perf%';+-----------------------------------------------+-------+ | Variable_name |值 | +-----------------------------------------------+-------+ | 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状态变量提供了关于由于内存限制而无法加载或创建的检测的信息。这些变量的名称有几种形式:
Performance_schema_
表示有多少类型的仪器xxx
_classes_lostxxx
无法加载。Performance_schema_
指示对象类型的实例数量xxx
_instances_lostxxx
无法创建。Performance_schema_
指示对象类型的实例数量xxx
_handles_lostxxx
无法打开。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个互斥锁工具。
服务器根据插件需要的数量和可用的数量为插件分配互斥工具,如下语句所示:
安装插件plugin_a
服务器现在有150+40 = 190个互斥设备。
卸载插件plugin_a;
服务器上还有190台仪器。插件代码生成的所有历史数据仍然可用,但不会收集仪器的新事件。
安装插件plugin_a;
服务器检测到这40个仪器已经定义,所以没有创建新的仪器,并且重用以前分配的内部内存缓冲区。服务器上还有190台仪器。
安装插件plugin_b;
服务器有200-190 = 10个仪器的空间(在本例中是互斥类),并且看到插件包含20个新仪器。10个仪器被装载,10个被丢弃或”丢失。”的Performance_schema_mutex_classes_lost
指示丢失的仪器(互斥锁类)的数量:
mysql> SHOW STATUS LIKE "perf%mutex_classes_lost";+---------------------------------------+-------+ | Variable_name |值 | +---------------------------------------+-------+ | Performance_schema_mutex_classes_lost | 10 | +---------------------------------------+-------+ 1行集(0.10秒)
仪器仍然工作并收集(部分)数据plugin_b
.
当服务器无法创建互斥工具时,会出现以下结果:
没有为仪器插入的行
setup_instruments
表格Performance_schema_mutex_instances_lost
不会改变。(当互斥锁工具没有被创建时,以后就不能用它来创建互斥锁实例了。)
刚才描述的模式适用于所有类型的工具,而不仅仅是互斥锁。
的值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
状态变量是表示某些事件由于未能创建仪器而在内部被删除的唯一可见标志。
如果仪器没有丢失,则Performance Schema会知道它,并在测试实例时使用它。例如,等待/同步/互斥锁/ sql / LOCK_delete
互斥锁工具的名称是否在setup_instruments
表格在代码中创建互斥锁时使用这个工具:: LOCK_delete
),但在服务器运行时需要多个互斥锁实例。在这种情况下,LOCK_delete
是每个连接的互斥锁(野
),所以如果一个服务器有1000个连接,就有1000个线程,1000个仪器化LOCK_delete
互斥对象实例(:: LOCK_delete
).
如果服务器没有空间容纳所有这1000个被检测的互斥锁(实例),则有些互斥锁是使用检测创建的,有些则不使用检测创建。如果服务器只能创建800个实例,则会丢失200个实例。服务器继续运行,但会增加Performance_schema_mutex_instances_lost
到200表示无法创建实例。
的值Performance_schema_mutex_instances_lost
当代码在运行时初始化的互斥锁多于分配的互斥锁时,会发生大于0的情况——performance_schema_max_mutex_instances =
.N
底线是如果显示状态如'perf%'
表示没有丢失任何东西(所有值都为零),Performance Schema数据是准确的,可以信赖。如果有数据丢失,则数据是不完整的,并且由于提供给它使用的内存量不足,Performance Schema不能记录所有数据。在这种情况下,具体的Performance_schema_
变量表示问题区域。xxx
_lost
在某些情况下,故意造成仪器饥饿可能是合适的。例如,如果不关心文件I/O的性能数据,可以在启动服务器时将与文件I/O相关的所有performance Schema参数设置为0。没有为文件相关的类、实例或句柄分配内存,并且所有文件事件都会丢失。
使用显示引擎performance_schema状态
检查Performance Schema代码的内部操作:
mysql>显示引擎性能模式状态*************************** 3所示。行 *************************** 类型:performance_schema名字:events_waits_history。size状态:76 *************************** 4.单击“确定”。行 *************************** 类型:performance_schema名字:events_waits_history。计数状态:10000 *************************** 5。行 *************************** 类型:performance_schema名字:events_waits_history。内存状态:760000…*************************** 57。行 *************************** 类型:performance_schema名字:performance_schema。内存状态:26459600…
此语句旨在帮助DBA理解不同的Performance Schema选项对内存需求的影响。有关字段含义的说明,请参见第13.7.5.15节,“SHOW ENGINE语句”.