概述
简介
performance_schema
是一种处于low level的监控手段，有如下特性
1，ps主要关注于数据库的性能数据，而information_schema 主要关注metadata信息
2，ps 主要监控服务器的events，这里的event跟二进制日志里的event 是不同的概念，，event指的是任何的在mysql-server运行使用过程中花费时间，并且被仪表化的，能被收集到的信息。
3，ps中的表写入操作不会记录binlog，不会同步到从机。
4，收集信息的方法通过在源代码中打点的方式……………………….
5，ps的setup tables 可以动态的修改，并且立即生效
6，performance_schema 是一个数据库名称，同时也是一个存储引擎类型，performance_schema库中的表都是此类型的。
6，ps意在提供一种让我们获取有关数据库运行的一些有用信息的方法，并且 对数据库性能很小，这个实现遵守了如下的设计目标
- 1，不影响任何数据库的行为，不影响线程调用的顺序，不影响sql的执行计划
- 2，语法分析器不受影响，没有任何新增的关键字，和语句
sys_schema
由于直接操作performance_schema和information_schema比较麻烦，于是提供了一种操作，访问performance_schema数据库的接口，方便dba使用。
1，sys的设计是依赖与performance_schema的，提供了大量的基于performance表的查询试图
2，5.7版本中使用mysqld –initialize or –initialize-insecure 去初始化数据库，这个时候会默认安装sys数据库，如果是用mysql_install_db 初始化数据库，可以使用参数跳过次数据库的安装–skip-sys-schema，通过mysqld初始化的时候是没有跳过选项的，但是可以在初始化数据库后，直接删除此db
3，从5.6 升级到5.7的过程使用mysql_upgrade，默认会生成sys数据库，也可以使用参数–skip-sys-shema 跳过生成。如果之前数据库实例中已经有用户手动建立的sys数据库，则会报错，需要移除后升级。
4，5.6版本的mysql也是可以使用sys库的 大部分功能的，只要导入sys库即可。
performance与sys各组成部分
performance_schema各成员
perforance_schema包含了87张base table，这些表可以分为如下几类
setup tables
这类表主要是配置生产消费过滤，计时器的选择。
- setup_actors
- setup_consumers
- setup_instruments
- setup_objects
- setup_timers
Instance Tables
此类表作用在于解释说明监控事件的含义。
- cond_instances
- file_instances
- mutex_instances
- rwlock_instances
- socket_instances
Wait Event Tables
记录线程等待的事件
- events_waits_current
- events_waits_history
- events_waits_history_long
Stage Event Tables
每个线程的执行过程统计。
- events_stages_current
- events_stages_history
- events_stages_history_long
Statement Event Tables
执行过的sql统计相关
- events_statements_current
- events_statements_history
- events_statements_history_long
- prepared_statements_instances
Transaction Tables
事务相关的事件统计
- events_transactions_current
- events_transactions_history
- events_transactions_history_long
Connection Tables
- accounts
- hosts
- users
Connection Attribute Tables
会话级别的参数
- session_account_connect_attrs
- session_connect_attrs
replication tables
复制相关的配置，监控
- replication_connection_configuration
- replication_connection_status
- replication_applier_configuration
- replication_applier_status
- replication_applier_status_by_coordinator
- replication_applier_status_by_worker
- replication_group_members:
- replication_group_member_stats
lock tables
锁相关
- metadata_locks
- table_handles
System Variable Tables
会话级别的参数设置
- global_variables
- session_variables
- variables_by_thread
Status Variable Tables
状态值信息
- global_status
- session_status
- status_by_thread
Summary Tables
Wait Event Summaries
* events_waits_summary_by_account_by_event_name
* events_waits_summary_by_host_by_event_name
* events_waits_summary_by_instance
* events_waits_summary_by_thread_by_event_name
* events_waits_summary_by_user_by_event_name
* events_waits_summary_global_by_event_name
Stage Summaries
* events_stages_summary_by_account_by_event_name
* events_stages_summary_by_host_by_event_name
* events_stages_summary_by_thread_by_event_name
* events_stages_summary_by_user_by_event_name
* events_stages_summary_global_by_event_name
Statement Summaries
* events_statements_summary_by_account_by_event_name
* events_statements_summary_by_digest
* events_statements_summary_by_host_by_event_name
* events_statements_summary_by_program
* events_statements_summary_by_thread_by_event_name
* events_statements_summary_by_user_by_event_name
* events_statements_summary_global_by_event_name
* prepared_statements_instances
Transaction Summaries
* events_transactions_summary_by_account_by_event_name
* events_transactions_summary_by_host_by_event_name
* events_transactions_summary_by_thread_by_event_name
* events_transactions_summary_by_user_by_event_name
* events_transactions_summary_global_by_event_name
Object Wait Summaries:
* objects_summary_global_by_type
File I/O Summaries
* file_summary_by_event_name
* file_summary_by_instance
sys_schema成员
sys_schema 由很多类型的object组成
tables
- sys_config
triggers
- sys_config_insert_set_user
- sys_config_update_set_user
sys Schema Views
共有50对应的视图，详见mybase文件sys Schema Stored Procedures
共有26个存储过程
- create_synonym_db()
- diagnostics()
- execute_prepared_stmt()
- …….
sys Schema Stored Functions
很扯淡的函数，有几个比较有用。
- extract_schema_from_file_name()
- extract_table_from_file_name()
- *
performance_schema配置与内存分配
配置
mysql> show global variables like '%performance%';
+----------------------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------------------+-------+
| performance_schema | ON |
| performance_schema_accounts_size | -1 |
| performance_schema_digests_size | 10000 |
| performance_schema_events_stages_history_long_size | 10000 |
| performance_schema_events_stages_history_size | 10 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size | 10 |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size | 10 |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_hosts_size | -1 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | -1 |
| performance_schema_max_digest_length | 1024 |
| performance_schema_max_file_classes | 80 |
| performance_schema_max_file_handles | 32768 |
| performance_schema_max_file_instances | -1 |
| performance_schema_max_index_stat | -1 |
| performance_schema_max_memory_classes | 320 |
| performance_schema_max_metadata_locks | -1 |
| performance_schema_max_mutex_classes | 200 |
| performance_schema_max_mutex_instances | -1 |
| performance_schema_max_prepared_statements_instances | -1 |
| performance_schema_max_program_instances | -1 |
| performance_schema_max_rwlock_classes | 40 |
| performance_schema_max_rwlock_instances | -1 |
| performance_schema_max_socket_classes | 10 |
| performance_schema_max_socket_instances | -1 |
| performance_schema_max_sql_text_length | 1024 |
| performance_schema_max_stage_classes | 150 |
| performance_schema_max_statement_classes | 193 |
| performance_schema_max_statement_stack | 10 |
| performance_schema_max_table_handles | -1 |
| performance_schema_max_table_instances | -1 |
| performance_schema_max_table_lock_stat | -1 |
| performance_schema_max_thread_classes | 50 |
| performance_schema_max_thread_instances | -1 |
| performance_schema_session_connect_attrs_size | 512 |
| performance_schema_setup_actors_size | -1 |
| performance_schema_setup_objects_size | -1 |
| performance_schema_users_size | -1 |
+----------------------------------------------------------+-------+编译 configuration
编译选择ps库
cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1
编译过滤某些功能
cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1 -DDISABLE_PSI_STAGE=1 -DDISABLE_PSI_STATEMENT=1启动选项，配置文件。
[mysqld]
performance_schema=ON
......参数说明示例
performance_schema_events_waits_history_size=10
performance_schema_events_waits_history_long_size 这两个参数是分别控制events_waits_history，events_waits_history_long 这两张表中存放每个线程的等待事件的个数，超过设置的阀值侯，采取先进先出的队列模式。
Performance Schema状态监控
以下是与performance_schema相关的状态值
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_index_stat_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_prepared_statements_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_table_lock_stat_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
| Performance_schema_users_lost | 0 |
+-----------------------------------------------+-------+
30 rows in set (0.00 sec)这些状态信息显示了一些由于内存限制导致不能被收集的events，可以分为如下几类：
- Performance_schema_xxx_classes_lost 表示有多少XXX类型的instruments不能收集
- Performance_schema_xxx_instances_lost 表示有多少XXX类型的instance不能被创建
- Performance_schema_xxx_handles_lost 表示多少XXX类型的instance不能被打开
- Performance_schema_locker_lost 有多少events ‘丢失’，或者是没有被记录
performance_schema的内存分配模型
Before MySQL 5.7.6, the Performance Schema used this memory allocation model:
• Allocate all the memory needed at server startup
• Never allocate memory during server operation
• Never free memory during server operation
• Free all memory used at shutdown
With that model, the Performance Schema potentially allocates a large amount of memory unless
explicit configuration is used to minimize particular types of instrumentation.
As of MySQL 5.7.6, the memory model allocates less memory by default under most circumstances:
• May allocate memory at server startup
• May allocate additional memory during server operation
• Never free memory during server operation (although it might be recycled)
• Free all memory used at shutdown举个栗子吧
- 1，查看某个连接的session variables
mysql> show processlist;
+----+------+-----------+--------------------+---------+------+----------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+--------------------+---------+------+----------+------------------+
| 6 | ashe | localhost | performance_schema | Query | 0 | starting | show processlist |
| 8 | ashe | localhost | NULL | Sleep | 338 | | NULL |
+----+------+-----------+--------------------+---------+------+----------+------------------+
2 rows in set (0.00 sec)
mysql> select * from variables_by_thread where VARIABLE_NAME='sql_log_bin' and THREAD_ID=sys.ps_thread_id(8);
+-----------+---------------+----------------+
| THREAD_ID | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+---------------+----------------+
| 58 | sql_log_bin | OFF |
+-----------+---------------+----------------+
1 row in set (0.00 sec)
- 2，查看数据库中的表哪些索引重复建立了。
mysql> select * from schema_redundant_indexes limit 2G
*************************** 1. row ***************************
table_schema: ermasdb
table_name: ermas_address_book
redundant_index_name: idx_address_book
redundant_index_columns: CUST_NO
redundant_index_non_unique: 1
dominant_index_name: custNoPhoneNbr
dominant_index_columns: CUST_NO,PHONE_NBR
dominant_index_non_unique: 1
subpart_exists: 0
sql_drop_index: ALTER TABLE `ermasdb`.`ermas_address_book` DROP INDEX `idx_address_book`
*************************** 2. row ***************************
table_schema: ermasdb
table_name: ermas_address_book_access_rec
redundant_index_name: ID
redundant_index_columns: ID
redundant_index_non_unique: 0
dominant_index_name: PRIMARY
dominant_index_columns: ID
dominant_index_non_unique: 0
subpart_exists: 0
sql_drop_index: ALTER TABLE `ermasdb`.`ermas_address_book_access_rec` DROP INDEX `ID`
2 rows in set (12.09 sec)
- 3，查看哪些存在的索引从来没有被使用过
mysql> select * from schema_unused_indexes limit 10;
+---------------+-------------------------+--------------------------------------+
| object_schema | object_name | index_name |
+---------------+-------------------------+--------------------------------------+
| crm_im | im_session_record | index_im_session_record_fromUserId |
| crm_im | im_session_record | index_session_record_count_endDate |
| crm_im | im_session_record | index_im_session_record_toUserId |
| crm_im | im_session_record | uk_im_session_record_sessionId |
| crm_im | im_session_record_count | index_session_record_count_sessionId |
| crs | forbidden_user | idx_user_uuid |
| crs | forbidden_user | uni_topic_user_uuid |
| crs | forbidden_user | idx_type |
| crs | reply_detail_0 | uni_reply_uuid |
| crs | reply_detail_1 | uni_reply_uuid |
+---------------+-------------------------+--------------------------------------+
10 rows in set (0.52 sec)
- 4，查看当前server都是从哪些服务器器（ip），使用的哪些用户所访问过,可以作为归档，审计的一部分
mysql> select * from accounts;
+--------------+----------------+---------------------+-------------------+
| USER | HOST | CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |
+--------------+----------------+---------------------+-------------------+
| NULL | NULL | 49 | 222 |
| root | localhost | 24 | 129914 |
| analyze_r | 10.127.53.12 | 0 | 1 |
| analyze | 100.109.90.126 | 0 | 68 |
| analyze | 100.107.12.11 | 0 | 23817 |
| analyze | 100.106.31.1 | 0 | 2318 |
| analyze | 100.106.30.23 | 0 | 134 |
| analyze | 100.106.30.25 | 0 | 148 |
| analyze | 100.106.30.49 | 0 | 168 |
| analyze | 100.106.30.2 | 0 | 150 |
| analyze | 100.106.30.32 | 0 | 125 |
| analyze | 100.106.30.27 | 0 | 18 |
| analyze | 100.106.30.45 | 0 | 120 |
| analyze | 100.106.30.39 | 0 | 169 |
| analyze | 100.106.30.21 | 0 | 117 |
| analyze | 100.106.30.37 | 0 | 140 |
| analyze | 100.107.12.9 | 0 | 142 |
| xuxu | 100.106.15.8 | 0 | 10 |
| analyze | 100.106.35.5 | 0 | 3311 |
| analyze | 100.106.35.15 | 1 | 301 |
| analyze | 100.106.36.22 | 0 | 278 |
| analyze | 100.106.41.15 | 0 | 270 |
| analyze | 100.106.39.13 | 0 | 297 |
| analyze | 100.106.36.4 | 1 | 274 |
| analyze | 100.106.40.12 | 0 | 303 |
- 5，progress reporting
主要针对于长事务的状态报告，比如说一个增加字段操作。
mysql> select * from processlist where thd_id=54G
*************************** 1. row ***************************
thd_id: 54
conn_id: 5
user: root@localhost
db: ashe
command: Query
state: alter table (read PK and internal sort)
time: 3
current_statement: alter table sbtest1 add column na4 varchar(100) not null
statement_latency: 3.40 s
progress: 5.35
lock_latency: 564.00 us
rows_examined: 0
rows_sent: 0
rows_affected: 0
tmp_tables: 0
tmp_disk_tables: 0
full_scan: NO
last_statement: NULL
last_statement_latency: NULL
current_memory: 0 bytes
last_wait: wait/synch/mutex/innodb/log_sys_mutex
last_wait_latency: 35.42 ns
source: mtr0mtr.cc:833
trx_latency: NULL
trx_state: NULL
trx_autocommit: NULL
pid: 149824
program_name: mysql
1 row in set (0.09 sec)
mysql> select * from processlist where thd_id=54G
*************************** 1. row ***************************
thd_id: 54
conn_id: 5
user: root@localhost
db: ashe
command: Query
state: alter table (insert)
time: 40
current_statement: alter table sbtest1 add column na4 varchar(100) not null
statement_latency: 39.49 s
progress: 86.98
lock_latency: 564.00 us
rows_examined: 0
rows_sent: 0
rows_affected: 0
tmp_tables: 0
tmp_disk_tables: 0
full_scan: NO
last_statement: NULL
last_statement_latency: NULL
current_memory: 0 bytes
last_wait: wait/synch/mutex/innodb/flush_list_mutex
last_wait_latency: 29.64 ns
source: buf0flu.cc:429
trx_latency: NULL
trx_state: NULL
trx_autocommit: NULL
pid: 149824
program_name: mysql
1 row in set (0.09 sec)
mysql> select * from processlist where thd_id=54G
*************************** 1. row ***************************
thd_id: 54
conn_id: 5
user: root@localhost
db: ashe
command: Query
state: alter table (flush)
time: 46
current_statement: alter table sbtest1 add column na4 varchar(100) not null
statement_latency: 45.78 s
progress: 94.95
lock_latency: 564.00 us
rows_examined: 0
rows_sent: 0
rows_affected: 0
tmp_tables: 0
tmp_disk_tables: 0
full_scan: NO
last_statement: NULL
last_statement_latency: NULL
current_memory: 0 bytes
last_wait: wait/synch/mutex/innodb/buf_dblwr_mutex
last_wait_latency: 74.31 ns
source: buf0dblwr.cc:1207
trx_latency: NULL
trx_state: NULL
trx_autocommit: NULL
pid: 149824
program_name: mysql
1 row in set (0.09 sec)
mysql> select * from processlist where thd_id=54G
*************************** 1. row ***************************
thd_id: 54
conn_id: 5
user: root@localhost
db: ashe
command: Query
state: alter table (log apply table)
time: 58
current_statement: alter table sbtest1 add column na4 varchar(100) not null
statement_latency: 58.40 s
progress: 100.00
lock_latency: 564.00 us
rows_examined: 0
rows_sent: 0
rows_affected: 0
tmp_tables: 0
tmp_disk_tables: 0
full_scan: NO
last_statement: NULL
last_statement_latency: NULL
current_memory: 0 bytes
last_wait: wait/synch/sxlock/innodb/hash_table_locks
last_wait_latency: 54.67 ns
source: buf0buf.cc:4094
trx_latency: NULL
trx_state: NULL
trx_autocommit: NULL
pid: 149824
program_name: mysql
1 row in set (0.11 sec)
- slave status监控
mysql> execute show_slave_status;
+--------------+-------------------+------------------+
| channel_name | sql_thread_status | io_thread_status |
+--------------+-------------------+------------------+
| voip_133 | ON | ON |
| datagent_161 | ON | ON |
| repay_164 | ON | ON |
| cuishou_217 | ON | ON |
| lawsuit_215 | ON | ON |
| crm_im_221 | ON | ON |
| product | ON | ON |
| opui_181 | ON | ON |
| crs | ON | ON |
| lawagent_218 | ON | ON |
| finance | ON | ON |
+--------------+-------------------+------------------+
11 rows in set (0.00 sec)
- 使用performance_schema 进行查询分析
The following example demonstrates how to use Performance Schema statement events and stage events to retrieve data comparable to profiling information provided by SHOW PROFILES and SHOW PROFILE statements.
As of MySQL 5.7.8, the setup_actors table can be used to limit the collection of historical events by host, user, or account to reduce runtime overhead and the amount of data collected in history tables. The first step of the example shows how to limit collection of historical events to a specific user.
Performance Schema displays event timer information in picoseconds (trillionths of a second) to normalize timing data to a standard unit. In the following example, TIMER_WAIT values are divided by 1000000000000 to show data in units of seconds. Values are also truncated to 6 decimal places to
display data in the same format as SHOW PROFILES and SHOW PROFILE statements.
如上是官方的简介，操作起来也不复杂。对于可以收集到的语句，可以从performance_schema.events_statements_history_long 表中查询到语句的event_id,此id对应performance_schema.events_stages_history_long 表中的NESTING_EVENT_ID。就就可以查询到sql在执行过程中每个阶段花费的时间
mysql> SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration
-> FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=380;
+--------------------------------+----------+
| Stage | Duration |
+--------------------------------+----------+
| stage/sql/starting | 0.000051 |
| stage/sql/checking permissions | 0.000002 |
| stage/sql/Opening tables | 0.000009 |
| stage/sql/init | 0.000018 |
| stage/sql/System lock | 0.000006 |
| stage/sql/optimizing | 0.000006 |
| stage/sql/statistics | 0.000059 |
| stage/sql/preparing | 0.000004 |
| stage/sql/executing | 0.000000 |
| stage/sql/Sending data | 0.000006 |
| stage/sql/end | 0.000000 |
| stage/sql/query end | 0.000004 |
| stage/sql/closing tables | 0.000004 |
| stage/sql/freeing items | 0.000009 |
| stage/sql/cleaning up | 0.000000 |
+--------------------------------+----------+关于开启performance_schema对数据库性能影响的测试
准备实验表数据
./sysbench --mysql-host=127.0.0.1 --mysql-port=13308 --mysql-user=test --mysql-db=ashe --oltp-tables-count=100 --oltp-table-size=1000000 --num-threads=50 --max-requests=1000000 --report-interval=1 --test=./db/oltp.lua prepareperformance_schema监控状态为default情况下
CALL sys.ps_setup_reset_to_default(TRUE);
[ 434s] threads: 64, tps: 13587.99, reads/s: 190348.81, writes/s: 54398.95, response time: 5.84ms (95%)
[ 435s] threads: 64, tps: 13606.03, reads/s: 190711.44, writes/s: 54458.13, response time: 5.80ms (95%)
[ 436s] threads: 64, tps: 13534.98, reads/s: 189646.65, writes/s: 54086.90, response time: 5.88ms (95%)
[ 437s] threads: 64, tps: 13639.66, reads/s: 190991.20, writes/s: 54625.63, response time: 5.75ms (95%)
[ 438s] threads: 64, tps: 13656.33, reads/s: 191414.57, writes/s: 54663.30, response time: 5.69ms (95%)
[ 439s] threads: 64, tps: 13692.02, reads/s: 191721.33, writes/s: 54722.09, response time: 5.71ms (95%)
[ 440s] threads: 64, tps: 13642.00, reads/s: 191046.03, writes/s: 54572.01, response time: 5.80ms (95%)
[ 441s] threads: 64, tps: 13743.98, reads/s: 192539.73, writes/s: 54990.92, response time: 5.66ms (95%)
[ 442s] threads: 64, tps: 13662.00, reads/s: 191367.01, writes/s: 54668.00, response time: 5.75ms (95%)
[ 443s] threads: 64, tps: 13651.66, reads/s: 191395.23, writes/s: 54683.64, response time: 5.76ms (95%)
[ 444s] threads: 64, tps: 13657.35, reads/s: 191199.92, writes/s: 54577.40, response time: 5.77ms (95%)
[ 445s] threads: 64, tps: 13616.98, reads/s: 190888.79, writes/s: 54597.94, response time: 5.81ms (95%)
[ 446s] threads: 64, tps: 13623.01, reads/s: 190759.14, writes/s: 54429.04, response time: 5.79ms (95%)
[ 447s] threads: 64, tps: 13629.04, reads/s: 190887.60, writes/s: 54514.17, response time: 5.77ms (95%)
[ 448s] threads: 64, tps: 13592.82, reads/s: 190526.45, writes/s: 54415.27, response time: 5.76ms (95%)
performance_schema完全打开状态
CALL sys.ps_setup_enable_instrument('wait');
CALL sys.ps_setup_enable_instrument('stage');
CALL sys.ps_setup_enable_instrument('statement');
CALL sys.ps_setup_enable_consumer('current');
CALL sys.ps_setup_enable_consumer('history_long');
---------------------------------------------------
[ 86s] threads: 64, tps: 11452.97, reads/s: 160212.51, writes/s: 45790.86, response time: 6.75ms (95%)
[ 87s] threads: 64, tps: 11428.02, reads/s: 160240.34, writes/s: 45742.10, response time: 6.72ms (95%)
[ 88s] threads: 64, tps: 11432.01, reads/s: 160228.12, writes/s: 45790.03, response time: 6.77ms (95%)
[ 89s] threads: 64, tps: 11417.97, reads/s: 159896.64, writes/s: 45627.90, response time: 6.79ms (95%)
performance_schema,sys_schema各组成部分简介
setup_tables
setup_tables 共有五张表，如下：
- setup_actors
- setup_consumers
- setup_instruments
- setup_objects
- setup_timers
—->myabse
这五张表对应sys_schema中的设置相关的一系列存储过程，如下：
- ps_setup_enable_instrument
- ps_setup_enable_consumer
- ……->>>>>>>seafile
for example,open the all instruments and consumers
CALL sys.ps_setup_enable_instrument('wait');
CALL sys.ps_setup_enable_instrument('stage');
CALL sys.ps_setup_enable_instrument('statement');
CALL sys.ps_setup_enable_consumer('current');
CALL sys.ps_setup_enable_consumer('history_long');
mysql> use sys;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> CALL sys.ps_setup_enable_instrument('wait');
+-------------------------+
| summary |
+-------------------------+
| Enabled 308 instruments |
+-------------------------+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
mysql> CALL sys.ps_setup_enable_instrument('stage');
+------------------------+
| summary |
+------------------------+
| Enabled 87 instruments |
+------------------------+
1 row in set (0.01 sec)
Query OK, 0 rows affected (0.01 sec)
mysql> CALL sys.ps_setup_enable_instrument('statement');
+------------------------+
| summary |
+------------------------+
| Enabled 22 instruments |
+------------------------+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
mysql> CALL sys.ps_setup_enable_consumer('current');
+---------------------+
| summary |
+---------------------+
| Enabled 3 consumers |
+---------------------+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
mysql> CALL sys.ps_setup_enable_consumer('history_long');
+---------------------+
| summary |
+---------------------+
| Enabled 4 consumers |
+---------------------+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
mysql> 更多详细的介绍，可以参照文档，以后会有更多使用案例的介绍。
使用pfs与sys案例
- 1，用户登陆状态监控
#使用performance_schema最多的一个场景，通过查询accounts表进行用户登陆信息监控，不管长链接还是短链接，都可以捕获到，并且默认状态下的pfs库就支持。最近在做服务器资源回收，通过使用脚本监控此表，即可知道谁还在访问此实例。
mysql> select * from accounts;
+-------------+---------------+---------------------+-------------------+
| USER | HOST | CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |
+-------------+---------------+---------------------+-------------------+
| NULL | NULL | 26 | 29 |
| ha_op | 127.0.0.1 | 2 | 2 |
| repl | 100.107.21.12 | 1 | 1 |
| dba_manager | 127.0.0.1 | 3 | 6 |
| action | 10.127.33.79 | 0 | 6 |
+-------------+---------------+---------------------+-------------------+
5 rows in set (0.00 sec)锁相关
目前mysql版本（5.7.17）中，performance_schema跟锁相关的表有两个，分别是metadata_locks和 table_handles。mysql还没有把所有跟锁相关的信息全部放在performance_schema 中去展示，information_schema依然发挥余热，以后会慢慢把锁相关的信息放在pfs中。
statements使用示例
- 1，找到未提交事务的sql
session 1
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from ashe;
+---+---+----+
| a | b | c |
+---+---+----+
| 1 | 2 | 10 |
| 1 | 2 | 19 |
| 1 | 2 | 20 |
+---+---+----+
mysql> delete from ashe where a=1 and b=2 and c=23;
Query OK, 0 rows affected (0.00 sec)
session 2
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into ashe(a,b,c) values(2,3,100)
-> ;
waiting........session 3
mysql> select * from INNODB_LOCKS;
+-------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+------------------------+
| lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
+-------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+------------------------+
| 3601:32:3:1 | 3601 | X | RECORD | `ashe`.`ashe` | PRIMARY | 32 | 3 | 1 | supremum pseudo-record |
| 3600:32:3:1 | 3600 | X | RECORD | `ashe`.`ashe` | PRIMARY | 32 | 3 | 1 | supremum pseudo-record |
+-------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+------------------------+
2 rows in set, 1 warning (0.00 sec)
mysql> select * from INNODB_LOCK_WAITS;
+-------------------+-------------------+-----------------+------------------+
| requesting_trx_id | requested_lock_id | blocking_trx_id | blocking_lock_id |
+-------------------+-------------------+-----------------+------------------+
| 3601 | 3601:32:3:1 | 3600 | 3600:32:3:1 |
+-------------------+-------------------+-----------------+------------------+
1 row in set, 1 warning (0.00 sec)
session 4
先查到是哪个未提交的线程造成阻塞的。
mysql> select * from innodb_lock_waitsG
*************************** 1. row ***************************
wait_started: 2017-03-24 15:15:59
wait_age: 00:07:33
wait_age_secs: 453
locked_table: `ashe`.`ashe`
locked_index: PRIMARY
locked_type: RECORD
waiting_trx_id: 3604
waiting_trx_started: 2017-03-24 15:15:59
waiting_trx_age: 00:07:33
waiting_trx_rows_locked: 1
waiting_trx_rows_modified: 0
waiting_pid: 5
waiting_query: insert into ashe(a,b,c) values(2,3,100)
waiting_lock_id: 3604:32:3:1
waiting_lock_mode: X
blocking_trx_id: 3603
blocking_pid: 3
blocking_query: NULL
blocking_lock_id: 3603:32:3:1
blocking_lock_mode: X
blocking_trx_started: 2017-03-24 15:15:52
blocking_trx_age: 00:07:40
blocking_trx_rows_locked: 1
blocking_trx_rows_modified: 0
sql_kill_blocking_query: KILL QUERY 3
sql_kill_blocking_connection: KILL 3 ####线程id为3的线程造成了线程5的等待
1 row in set, 3 warnings (0.02 sec)但此时已经无法通过show processlist查看到线程3执行的sql，或者说线程3事务中的哪条sql造成的。
此时可以通过查看performance schema中的statement相关表来查看。
events_statements_current ##当前所有线程最后执行的sql。
events_statements_history ##保存线程最近performance_schema_events_statements_history_size 个数的event
events_statements_history_long ##保存最近performance_schema_events_statements_history_long_size个数的event statementmetadata_locks使用
顾名思义，这张表用来展现数据库中的元数据信息锁。
从此表可以获取到的信息有
- 1，谁当前拥有对谁的锁，例如：
mysql> select * from metadata_locks;
+-------------+--------------------+----------------+-----------------------+-------------+---------------+-------------+-------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+----------------+-----------------------+-------------+---------------+-------------+-------------------+-----------------+----------------+
| TABLE | performance_schema | metadata_locks | 140608438136768 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6030 | 68 | 199 |
+-------------+--------------------+----------------+-----------------------+-------------+---------------+-------------+-------------------+-----------------+----------------+
1 row in set (0.00 sec)
- 2，谁正在请求谁的锁，例如：
#THREAD_ID为69的线程已经占有ashe.test表的元数据信息SHARED_READ锁，而THREAD_ID为70的线程正在申请ashe.test表的元数据信息的EXCLUSIVE锁，如果一直获取不到此锁，则等待超时，关于锁超时.
mysql> select * from metadata_locks;
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| TABLE | ashe | test | 140608773683968 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6030 | 69 | 157 |
| GLOBAL | NULL | NULL | 140608505192896 | INTENTION_EXCLUSIVE | STATEMENT | GRANTED | sql_base.cc:5496 | 70 | 73 |
| SCHEMA | ashe | NULL | 140608505178816 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | sql_base.cc:5481 | 70 | 73 |
| TABLE | ashe | test | 140608505192800 | EXCLUSIVE | TRANSACTION | PENDING | sql_parse.cc:6030 | 70 | 73 |
| TABLE | performance_schema | metadata_locks | 140608371049408 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6030 | 71 | 189 |
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
5 rows in set (0.00 sec)
- 3，被死锁检测器杀掉的锁请求，或者是锁请求超时的。
疑问点？元数据信息死锁举例？？
通过 metadata_locks中的信息，可以很清楚的发现各线程之间持有锁与申请锁之间的依赖关系。
与此表相关的全局变量和全局状态值
mysql> show global variables like '%performance_schema_max_metadata_locks%';
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| performance_schema_max_metadata_locks | -1 |
+---------------------------------------+-------+
1 row in set (0.00 sec)
mysql> show global status like '%Performance_schema_metadata_lock_lost%';
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| Performance_schema_metadata_lock_lost | 0 |
+---------------------------------------+-------+
1 row in set (0.00 sec)什么是元数据信息？
什么是元数据信息锁？
使用前开启对元数据信息锁的监控
mysql> select * from setup_instruments where NAME like '%meta%'
-> ;
+------------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+------------------------------------------------------+---------+-------+
| wait/io/file/csv/metadata | YES | YES |
| wait/io/file/archive/metadata | YES | YES |
| stage/sql/Waiting for tablespace metadata lock | NO | NO |
| stage/sql/Waiting for schema metadata lock | NO | NO |
| stage/sql/Waiting for table metadata lock | NO | NO |
| stage/sql/Waiting for stored function metadata lock | NO | NO |
| stage/sql/Waiting for stored procedure metadata lock | NO | NO |
| stage/sql/Waiting for trigger metadata lock | NO | NO |
| stage/sql/Waiting for event metadata lock | NO | NO |
| memory/performance_schema/metadata_locks | YES | NO |
| wait/lock/metadata/sql/mdl | NO | NO |
+------------------------------------------------------+---------+-------+
mysql> update setup_instruments set ENABLED='Yes',TIMED='Yes' where NAME like '%meta%';
Query OK, 9 rows affected (0.00 sec)
Rows matched: 11 Changed: 9 Warnings: 0
#例如当前查询到的metadata_locks表里的数据
mysql> select * from metadata_locks;
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| TABLE | ashe | test_gtid | 140608371049408 | SHARED_WRITE | TRANSACTION | GRANTED | sql_parse.cc:6030 | 60 | 21 |
| GLOBAL | NULL | NULL | 140608303883088 | INTENTION_EXCLUSIVE | STATEMENT | GRANTED | sql_base.cc:5496 | 56 | 141 |
| SCHEMA | ashe | NULL | 140608303950064 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | sql_base.cc:5481 | 56 | 141 |
| TABLE | ashe | test_gtid | 140608303896096 | EXCLUSIVE | TRANSACTION | PENDING | sql_parse.cc:6030 | 56 | 141 |
| TABLE | performance_schema | metadata_locks | 140608572299840 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6030 | 61 | 213 |
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+通过pstack查看mysql线程堆栈信息,可以看到申请mdl锁的线程
Thread 7 (Thread 0x7fe238119700 (LWP 9587)):
#0 0x000000384100ba5e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000c527d0 in MDL_wait::timed_wait(MDL_context_owner*, timespec*, bool, PSI_stage_info_v1 const*) ()
#2 0x0000000000c54ba0 in MDL_context::acquire_lock(MDL_request*, unsigned long) ()
#3 0x0000000000c556e5 in MDL_context::acquire_locks(I_P_List<MDL_request, I_P_List_adapter<MDL_request, &(MDL_request::next_in_list), &(MDL_request::prev_in_list)>, I_P_List_counter, I_P_List_no_push_back<MDL_request> >*, unsigned long) ()
#4 0x0000000000ca2585 in lock_table_names(THD*, TABLE_LIST*, TABLE_LIST*, unsigned long, unsigned int) ()
#5 0x0000000000d67b7d in mysql_rm_table(THD*, TABLE_LIST*, char, char) ()
#6 0x0000000000cfdbf2 in mysql_execute_command(THD*, bool) ()
#7 0x0000000000d022f5 in mysql_parse(THD*, Parser_state*) ()
#8 0x0000000000d034ff in dispatch_command(THD*, COM_DATA const*, enum_server_command) ()
#9 0x0000000000d04374 in do_command(THD*) ()
#10 0x0000000000dd36cc in handle_connection ()
#11 0x0000000000f51911 in pfs_spawn_thread ()
#12 0x0000003841007aa1 in start_thread () from /lib64/libpthread.so.0
#13 0x0000003840ce8aad in clone () from /lib64/libc.so.6
metadata_locks表字段详解
mysql> desc metadata_locks;
+-----------------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------------------+------+-----+---------+-------+
| OBJECT_TYPE | varchar(64) | NO | | NULL | |
| OBJECT_SCHEMA | varchar(64) | YES | | NULL | |
| OBJECT_NAME | varchar(64) | YES | | NULL | |
| OBJECT_INSTANCE_BEGIN | bigint(20) unsigned | NO | | NULL | |
| LOCK_TYPE | varchar(32) | NO | | NULL | |
| LOCK_DURATION | varchar(32) | NO | | NULL | |
| LOCK_STATUS | varchar(32) | NO | | NULL | |
| SOURCE | varchar(64) | YES | | NULL | |
| OWNER_THREAD_ID | bigint(20) unsigned | YES | | NULL | |
| OWNER_EVENT_ID | bigint(20) unsigned | YES | | NULL | |
+-----------------------+---------------------+------+-----+---------+-------+
mutex_instances
什么是mutex？
http://www.tocker.ca/2013/11/27/what-is-a-mutex-anyway.html
简而言之：
mutex是一种互斥锁，是保护临界资源的并发访问的一种机制。
不只是mysql,在大多数多线程程序中，都需要mutex来保护某些临界资源的正确性。mutex跟行锁和表锁是不同的概念。
Some examples
….
update setup_instruments set ENABLED=’yes’,TIMED=’yes’ where name like ‘%mutex%’;
更多的使用用例请看另外一篇 https://blog.csdn.net/sun_ashe/article/details/82111156
最后
以上就是怕孤单戒指为你收集整理的Performance_schema/sys 简介的全部内容，希望文章能够帮你解决Performance_schema/sys 简介所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复