漫漫长路,其修远兮!
分类: Mysql/postgreSQL
2013-01-04 16:00:14
MySQL 5.5新增一个存储引擎:命名PERFORMANCE_SCHEMA ,主要用于收集数据库服务器性能参数。MySQL用户是不能创建存储引擎为PERFORMANCE_SCHEMA的表
performance_schema提供以下功能:
通过以上得到的信息,DBA能够较明细得了解性能降低可能是由于哪些瓶颈?
l performance_schema功能开启和部分表功能
Performance的开启很简单,在my.cnf中[mysqld]加入performanc_schema,检查性能数据库是否启动的命令:
SHOW VARIABLES LIKE ‘performance_schema’;
若是返回的 值为ON,则说明性能数据库正常开启状态。
接下来你能看到每个表的变化:
1.Threads
SHOW PROCESSLIST;
SELECT * FROM performance_schema.threads;
看到theads表的作用了吗?监控服务器所有连接, thread_id这个在接下来非常有用,
2.Performance_timers
设置一些监控信息
root@localhost : performance_schema 05:23:28> SELECT * FROM performance_timers;
+————-+—————–+——————+—————-+
| TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+————-+—————–+——————+—————-+
| CYCLE | 2603393034 | 1 | 66 |
| NANOSECOND | 1000000000 | 1000 | 682 |
| MICROSECOND | 1000000 | 1 | 227 |
| MILLISECOND | 1039 | 1 | 247 |
| TICK | 100 | 1 | 634 |
+————-+—————–+——————+—————-+
Performance_timers指定mysql服务可用的监控周期,CYCLE表示按每秒检测2603393034次。下面会设置监控周期
root@localhost : performance_schema 05:20:33> select * from setup_timers;
+——+————+
| NAME | TIMER_NAME |
+——+————+
| wait | CYCLE |
+——+————+
UPDATE setup_timers SET TIMER_NAME= ‘NANOSECOND’ WHERE NAME=’wait’;
3.Setup_consumers\ Setup_instruments
接下来设置哪些事件能够被收集
root@localhost : performance_schema 05:23:45> SELECT * FROM setup_consumers;
+———————————————-+———+
| NAME | ENABLED |
+———————————————-+———+
| events_waits_current | YES |
| events_waits_history | YES |
| events_waits_history_long | YES |
| events_waits_summary_by_thread_by_event_name | YES |
| events_waits_summary_by_event_name | YES |
| events_waits_summary_by_instance | YES |
| file_summary_by_event_name | YES |
| file_summary_by_instance | YES |
+———————————————-+———+
UPDATE setup_consumers SET ENABLED = ‘YES’ WHERE NAME=’ events_waits_history’;(表示能够被收集)
UPDATE setup_instruments SET ENABLED=’YES’ WHERE NAME=’ wait/synch/mutex/sql/PAGE::locK’;
实验收集等待信息的实例
到目前为止没有测试过是否能够检测到异常进程,见下来看看采集的数据
root@localhost : performance_schema 06:54:34> show processlist;
+——+——+———–+——————–+———+——+
| Id | User | Host | db | Command | Time |
+——+——+———–+——————–+———+——+
| 2731 | root | localhost | test | Query | 67 |
| 2732 | root | localhost | test | Sleep | 139 |
| 2733 | root | localhost | performance_schema | Query | 0 |
+——+——+———–+——————–+———+——+
root@localhost : performance_schema 06:54:16> SELECT * FROM threads where PROCESSLIST_ID IN(2731,2732,2733);
+———–+—————-+—————————+
| THREAD_ID | PROCESSLIST_ID | NAME |
+———–+—————-+—————————+
| 2742 | 2732 | thread/sql/one_connection |
| 2741 | 2731 | thread/sql/one_connection |
| 2743 | 2733 | thread/sql/one_connection |
+———–+—————-+—————————+
Session1 PID=2732; THREAD_ID: 2742 | Session2 PID 2731;THREAD_ID: 2741 | Session3 查看监控信息 | |
1 | LOCK TABLE task WRITE | ||
2 | START TRANSACTIONupdate task set type=3 where uid=1238 and tdid=117004 and date=20110522;wait……………………. | ||
3 | root@localhost : performance_schema 07:00:31> SELECT * FROM events_waits_current WHERE TIMER_END IS NULL\G;*************************** 1. row ***************************THREAD_ID: 2741EVENT_ID: 63EVENT_NAME: wait/synch/cond/sql/MDL_context::COND_wait_statusSOURCE: mdl.cc:983TIMER_START: 99074136559454208TIMER_END: NULLTIMER_WAIT: NULLSPINS: NULL
OBJECT_SCHEMA: NULL OBJECT_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 453433776 NESTING_EVENT_ID: NULL OPERATION: timed_wait NUMBER_OF_BYTES: NULL FLAGS: 0 1 row in set (0.00 sec)
| ||
4 | root@localhost : performance_schema 07:01:51> SELECT * FROM mutex_instances WHERE LOCKED_BY_THREAD_ID IS NOT NULL;+————————————————-+———————–+———————+| NAME | OBJECT_INSTANCE_BEGIN | LOCKED_BY_THREAD_ID |+————————————————-+———————–+———————+| wait/synch/mutex/sql/MDL_wait::LOCK_wait_status | 453433720 | 2741 |+————————————————-+———————–+———————+ | ||
5 | Unlock tables |
在3步的Session3中看到events_waits_current ,看到Seesion2正在等待某个一个前提条件的释放,这个表中包含有正在等待哪个前提条件、OPERATION什么类型、SOURCE源代码位置、OBJECT_INSTANCE_BEGIN内存开始的位置
在4步的session3中mutex_instances表,存储着session2正在等待的是一个MDL的互斥变量的释放,OBJECT_INSTANCE_BEGIN内存开始位置453433720