[MySQL5.6]PerformanceSchema學習：命名規範、狀態變數及其他(2)

zhaiwx_yinfeng發表於2016-05-10
MySqlORM變數

PS Instrument命名規範

 

PS instrument的命名類似於樹形結構，最高層次的是instrument的型別，總共四種：idle/wait/stage/statement;再下一層的命名可能是一個子模組名（例如sync,io）等，再往下一層，例如sync，又可以劃分成mutex/cond/rwlock,之後也許就是具體的某個同步鎖物件，或者下一層的模組。

1.1.idle:
idle物件表示socket空閒資訊，在setup_instrument表裡只包含一列，名字就是idle。它生產的對應事件在socket_instances中.

mysql> select count(*) from setup_instruments where name like ‘idle%`;

+———-+
| count(*) |
+———-+
|        1 |
+———-+
1 row in set (0.00 sec)
1.2.stage
stage的命名規則為stage/code_area/stage_name
其中code_area值為sql/mysys
stage_name表示執行語句過程中的各個階段，例如storing result in query cache、Waiting for global read lock 等等.

mysql> select count(*) from setup_instruments where name like ‘stage%`;

+———-+
| count(*) |
+———-+
|      108 |
+———-+
1 row in set (0.00 sec)
1.3.statement
其命名規則為statement/SQL或者COM
SQL的下一級表示不同的SQL型別，例如statement/sql/xa_commit、statement/sql/rollback
另外文件標明statement/sql/select  用於CREATE DATABASE 和SELECT語句，暫未證實
COM則對應enum_server_command 中的伺服器command型別，例如statement/com/Ping 代表COM_PING 

1.4.wait
wait型別的instrument應該是我們比較關注的部分，因為mysql本身的併發等待是非常值得關注的部分，也一般是導致伺服器異常的罪魁禍首.另外wait型別還包括io相關instrument.

wait/io  
包括對檔案的操作時間統計(wait/io/file/),socket操作(wait/io/socket)；
另外還有表的IO操作(wait/io/table/sql/handler),包括對持久表和臨時表的行級別操作，那些影響到行的操作（fetch,insert,delete..）.和其他wait物件不同的是，表的wait物件可能包含其他等待時間，例如，表的I/O可能包含檔案I/O或記憶體操作。因此在表 events_waits_current 中對錶的IO資訊可能還包括wait/io/file物件，應該包含兩行資料

wait/lock
就一個wait/lock/table/sql/handler ，表上的鎖操作

wait/synch
synch的物件比較多，包括條件變數(wait/synch/cond)、mutex(wait/synch/mutex)、讀寫鎖(wait/synch/rwlock)

PS狀態變數

 

PS提供了一些資訊來顯示由於記憶體限制導致某些統計資訊沒有計入PS中。

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_mutex_classes_lost         | 0     |
| Performance_schema_mutex_instances_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     |
+———————————————–+——-+
23 rows in set (0.00 sec)
而相應的記憶體分配的大小，則取決於如下的系統變數：
mysql> show variables like ‘%perf%`;
+——————————————————–+——–+
| Variable_name                                          | Value  |
+——————————————————–+——–+
| performance_schema                                     | ON     |
| performance_schema_accounts_size                       | 100    |
| 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_waits_history_long_size      | 10000  |
| performance_schema_events_waits_history_size           | 10     |
| performance_schema_hosts_size                          | 100    |
| performance_schema_max_cond_classes                    | 80     |
| performance_schema_max_cond_instances                  | 20900  |
| performance_schema_max_file_classes                    | 50     |
| performance_schema_max_file_handles                    | 32768  |
| performance_schema_max_file_instances                  | 100824 |
| performance_schema_max_mutex_classes                   | 200    |
| performance_schema_max_mutex_instances                 | 35000  |
| performance_schema_max_rwlock_classes                  | 30     |
| performance_schema_max_rwlock_instances                | 12800  |
| performance_schema_max_socket_classes                  | 10     |
| performance_schema_max_socket_instances                | 10020  |
| performance_schema_max_stage_classes                   | 150    |
| performance_schema_max_statement_classes               | 167    |
| performance_schema_max_table_handles                   | 4000   |
| performance_schema_max_table_instances                 | 12500  |
| performance_schema_max_thread_classes                  | 50     |
| performance_schema_max_thread_instances                | 10100  |
| performance_schema_session_connect_attrs_size          | 512    |
| performance_schema_setup_actors_size                   | 100    |
| performance_schema_setup_objects_size                  | 100    |
| performance_schema_users_size                          | 100    |
+——————————————————–+——–+各個選項配置的文件見：http://dev.mysql.com/doc/refman/5.6/en/performance-schema-system-variables.html

 

我們也可以通過SHOW ENGINE PERFORMANCE_SCHEMA STATUSG 來看當前PS的記憶體佔用

詳細介紹點選文件，如果你的記憶體足夠大，可以適當調整這些引數來儲存更多收集的資訊
另外還可以通過選項performance_schema_instrument = ‘%=on’在啟動時開啟所有的instrument

STATEMENT_DIGEST

當開啟statements_digest時,PS會將相同型別的SQL在 events_statements_summary_by_digest表中聚集在一起，SQL中的資料部分被“?”所代替，並調整空白部分，一些標示，例如表名和庫名被保留。這有點和我們內部使用的myawr功能類似，將相似的SQL聚合起來展現。在statement對應的event表中，DIGEST列儲存了SQL的md5值，DIGEST_TEXT儲存了被處理過的SQL。
例如，執行如下SQL:
select * from sbtest where id < 10; 
select * from sbtest where id < 20; 

會被聚合成如下記錄：

                SCHEMA_NAME: sbtest

                     DIGEST: 4c3d9d47ee42d768152f70ee27f8e067
                DIGEST_TEXT: SELECT * FROM `sbtest` WHERE `id` < ?
                 COUNT_STAR: 2
             SUM_TIMER_WAIT: 3477357000
             MIN_TIMER_WAIT: 340011000
             AVG_TIMER_WAIT: 1738678000
             MAX_TIMER_WAIT: 3137346000
              SUM_LOCK_TIME: 284000000
                 SUM_ERRORS: 0
               SUM_WARNINGS: 0
          SUM_ROWS_AFFECTED: 0
              SUM_ROWS_SENT: 28
          SUM_ROWS_EXAMINED: 28
SUM_CREATED_TMP_DISK_TABLES: 0
     SUM_CREATED_TMP_TABLES: 0
       SUM_SELECT_FULL_JOIN: 0
 SUM_SELECT_FULL_RANGE_JOIN: 0
           SUM_SELECT_RANGE: 2
     SUM_SELECT_RANGE_CHECK: 0
            SUM_SELECT_SCAN: 0
      SUM_SORT_MERGE_PASSES: 0
             SUM_SORT_RANGE: 0
              SUM_SORT_ROWS: 0
              SUM_SORT_SCAN: 0
          SUM_NO_INDEX_USED: 0
     SUM_NO_GOOD_INDEX_USED: 0
                 FIRST_SEEN: 2013-03-29 16:55:01
                  LAST_SEEN: 2013-03-29 16:55:04

DIEGEST_TEXT列的長度為1024，超過了就以字串“…”代替。而在events_statements_current, events_statements_history和 events_statements_history_long這三個表中記錄了具體的SQL，而非聚合的結果

events_statements_summary_by_digest表有固定的大小，由引數performance_schema_digests_size控制，預設為10000條記錄。當該表的記錄滿時，有一個特殊的列,其SCHEMA_NAME和DIGEST列設定為NULL，記錄被加入到這個特殊的列中，如果觀察該行記錄的counter明顯很高時，可能需要調整這個表的size。


相關文章