2011 06-12-lamp-mysql
TRANSCRIPT
● Handler Socket 项目的意义
● Handler Socket 实现的途径
● MySQL Plugin 体系简介
● MySQL 5.5 新引入的 semisync 复制
● MySQL 5.5 值得关注的几个参数及性能变化
Handler Socket 出现的意义
● 众所周知 RDBMS 的 SQL 引擎存取代价大，对轻量 k/v 型数据没有较好的应用模式
● MySQL 和 Memcached 整合后， MC 的数据一致性问题，服务器管理，可用性管理都需要考虑
● Memcached 的持久化问题
● 最好有一种方式能跳过 MySQL 耗时的 SQL 语法解析器而直接访问存储层
性能瓶颈
● 对于 k/v 式操作，即使是用了 prepared statement， 或者 query cache 等各种优化，每秒执行语句的速度也是 Memcache 4-5的 分之一左右
● Vmstat 中 user 的 CPU 时间比 sys 时间多不少，因此各种 mutex lock 并非是影响性能的主要瓶颈
$mysqlslap --query="select user_name from test.user where user_id=1000" –number-of-queries=10000000 --concurrency=30 --host=mysql15 -uxxx -p
$mysqladmin extended-status -i 1 -r -uroot | grep -e "Com_select"
| Com_select | 86234 || Com_select | 82345 || Com_select | 85972 || Com_select | 84270 || Com_select | 84281 || Com_select | 83951 |通过正常的 SQL 接口， MySQL 84可以达到 k/s 的读取次数
$ vmstat 1us sy id wa st55 36 9 0 053 34 13 0 0
vmstat 的 user 时间占了一半多
资源都消耗在哪里
用 OProfile 查看系统调用
samples % app name symbol name259130 4.5199 mysqld MYSQLparse(void*)196841 3.4334 mysqld my_pthread_fastmutex_lock106439 1.8566 libc-2.5.so _int_malloc67945 1.1851 mysqld ...make_join...63435 1.1065 mysqld JOIN::optimize()55825 0.9737 vmlinux wakeup_stack_begin55054 0.9603 mysqld MYSQLlex(void*, void*)
可以看到， SQL 解析相关的调用占了大部分 CPU 时间，如果能跳过 SQL 解析层就能好很多
如何降低查询开销
一般 MySQL :客户端进行查询，有如下过程● SQL Parser 解析 SQL 语句● 打开表对象句柄，申请 mutex● 根据表信息生成 SQL 执行计划● IO 读写● 释放 mutex， 关闭表对象句柄
5这 个步骤中，只有第四步是 IO 向的，其余都是 CPU 向。
MySQL 为能够自定义存储引擎，有一个 Handler 结构专门抽象了底层存储引擎的各个通用接口， SQL 解析器只要调用handlerton(handler singleton) 这个结构体就可以和各种底层存储引擎交互。
handlerton example_hton= { "EXAMPLE", "Example storage engine", DB_TYPE_EXAMPLE_DB, ... NULL, /* commit */ NULL, /* rollback */ NULL, /* prepare */ /* Create a new handler */ example_create_handler, ...};
Handler Socket 底层就是基于这个接口来实现的。
● HS 2以插件形式启动，启动后监听 个特殊端口，分别接受读请求和写请求，并且 fork 出可配置数量的服务线程
● 这些服务线程将轮番处理客户端请求，并对多次分散的请求做合并处理
● HS /不会不停地打开 关闭表对象句柄，它在打开后会保持一段时间，如果在一段时间内没有请求才会关闭，以方便句柄重用
● HS 自己实现了一套基于文本的通信协议（类似Memcached 的协议，很简洁，不用构建语法树也不需要优化），支持 telnet 的调试open_index <indexid> <dbname> <tablename> <indexname> <columns> [<fcolumns>]
:测试效果创建带主键的 InnoDB 5,000,000表，插入随机数据 条，通过 HS 端口
$ mysqladmin extended-status -uxxx -p -i 1 -r | grep "InnoDB_rows_read"
| Innodb_rows_read | 328512 || Innodb_rows_read | 340128 || Innodb_rows_read | 312134 || Innodb_rows_read | 338072 || Innodb_rows_read | 342387 || Innodb_rows_read | 399023 || Innodb_rows_read | 312494 || Innodb_rows_read | 353918 |
SQL 引擎 84270 op/s
HandlerSocket 338072 op/s
再看 OProfile :的数据
847486 5.0876 ha_innodb_plugin. ut_delay545303 3.2735 ha_innodb_plugin. btr_search_guess_on_hash317570 1.9064 ha_innodb_plugin. row_search_for_mysql298271 1.7906 vmlinux tcp_ack291739 1.7513 libc-2.5.so vfprintf264704 1.5891 vmlinux .text.super_90_sync248546 1.4921 vmlinux blk_recount_segments244474 1.4676 libc-2.5.so _int_malloc
发现原来占用 CPU 时间非常多的几个 SQL 解析调用都已经不在列表上了，而且此时的 vmstat 数据 sys 80%占了几乎 左右的 CPU 时间，说明优化已经奏效。
HandlerSocket 的特点
● 性能卓越
● 不再有重复的 Cache， 数据保持一致
● 不影响正常数据库功能的使用
● 以插件的形式存在
● 内置线程池
● 利用 MySQL 的 Handler 接口，和底层引擎
类型无关
Handler Socket 的限制
● 缺乏安全性
● 对于磁盘 IO 向的场景没有效果
● 性能瓶颈从 CPU 向转到网卡向
● 加重 slave 的复制压力
MySQL Plugin 体系介绍
MySQL Plugin类型
● Daemon Plugins● INFORMATION_SCHEMA Plugins● Storage Engine Plugins● FullText Parser Plugins● Audit Plugins● Authentication Plugins● Replication Plugins
MySQL Server
st_mysql_plugin demo1={ Int type; void *info; ...}
st_mysql_plugin demo2={ Int type; void *info; ...}
Binlog_transmit_observer { rpl_stat_transmit_start, NULL, NULL, rpl_stat_before_send_event,...}
MySQL Plugin essentialsmysql_declare_plugin(demo_plugin){ MYSQL_DAEMON_PLUGIN, &simple_parser_descriptor, "simple_parser", "Some Corporation", "Simple DAEMON Plugin", PLUGIN_LICENSE_GPL, simple_parser_plugin_init, simple_parser_plugin_deinit, 0x0001, simple_status, simple_system_variables, NULL}mysql_declare_plugin_end;
MySQL 5.5 SemiSync
MySQL 5.5 SemiSync
● 修改了原生复制的 packet header, 添加BINLOG_SEMI_SYNC 0x02
● session事务提交成功，如果至少有一个开启了 semisync 的 slave 的 io thread 接收到commit 复制事件
● 如果 master 等待 ack超时，事务会被提交， semisync 将被自动关闭，直到有一个slave跟上 master
● 支持 GROUP COMMIT
MySQL 5.5 SemiSync
semisync效率
2 million, 8G 4 million, 17G0
200000
400000
600000
800000
1000000
1200000
504971
1110723
异步
semisync
Binlog Transmit Observer
Binlog_transmit_observer transmit_observer = { sizeof(Binlog_transmit_observer), rpl_stat_transmit_start, //start NULL, // stop NULL, // reserve_header rpl_stat_before_send_event, NULL, // after_send_event NULL, // reset};
MySQL 5.5 的变化
MySQL 5.5 的改进
● MySQL全面改用 CMake 作为主编译系统
● InnoDB 成为默认引擎， Barracuda● MySQL 在 Win平台上的性能提升较大
● 复制能够被更好地监控和管理
● 执行 SQL 语句时支持自定义异常处理并可将异常抛会调用程序
● (新增性能模式库 Performance Schema)
MySQL 5.5 的改进
● InnoDB同时支持多个 BufferPool 实例
● InnoDB提升默认的并发线程策略innodb_thread_concurrency=0
● InnoDB细粒度控制后台 I/O 线程数量innodb_read/write_io_threads
● InnoDB 可配置的主线程 I/O 速率innodb_io_capacity=500
● Linux平台原生异步 I/O支持
MySQL 5.5 性能测试
● Linux Gentoo mysql23 2.6.34hardenedr6 x86_64 GenuineIntel GNU/Linux
● 4*6(core) Intel(R) Xeon(R) CPU X5670 @ 2.93GHz, 12M Cache, 6.40 GT/s Intel® QPI
● 32GB 内存
● : 394存储 G /data, 82G /logs， : 4096, 块大小deadline, AIO
● 存储性能使用 fio(Flexible IO Tester)
磁盘性能
IOPS 带宽
只读 4,159 op/s 297 MB/s
只写 1,592 op/s 176 MB/s
读写 1,296 op/s
4k block
MySQL 5.5 vs MySQL 5.1MySQL 5.5 配置 MySQL 5.1 配置
innodb_buffer_pool_size=20Ginnodb_file_per_table=1innodb_doublewrite=0innodb_max_dirty_pages_pct=80innodb_flush_log_at_trx_commi=2innodb_log_buffer_size=8Minnodb_thread_concurrency=0innodb_flush_method = O_DIRECTinnodb_write_io_threads=24innodb_read_io_threads=24innodb_io_capacity=2700 #IOPSinnodb_use_native_aiomax_connections=3000query_cache_size=0query_cache_type=0
innodb_buffer_pool_size=20Ginnodb_file_per_table=1innodb_doublewrite=noinnodb_max_dirty_pages_pct=80innodb_flush_log_at_trx_commit=2innodb_log_buffer_size=8Minnodb_thread_concurrency=0innodb_flush_method = O_DIRECTmax_connections=3000query_cache_size=0query_cache_type=0
MyISAM 引擎只读测试
MyISAM 引擎读写测试
InnoDB 引擎只读测试
InnoDB 引擎读写测试
tpccmysql
测试使用500 w 的数据基数，64个并发线程，200秒预热时间，测试时间:3000秒。
Q & A