![HS 以插件形式启动，启动后监听2个特殊端口，分别接受读请
●
求和写请求，并且 fork 出可配置数量的服务线程
●这些服务线程将轮番处理客户端请求，并对多次分散的请求做
合并处理
HS 不会不停地打开/关闭表对象句柄，它在打开后会保持一段
●
时间，如果在一段时间内没有请求才会关闭，以方便句柄重用
● HS 自己实现了一套基于文本的通信协议（类似 Memcached 的
协议，很简洁，不用构建语法树也不需要优化），支持 telnet 的
调试
open_index <indexid> <dbname> <tablename>
<indexname> <columns> [<fcolumns>]](https://image.slidesharecdn.com/2011-06-12-lamp-mysql-110614223155-phpapp02/85/2011-06-12-lamp-mysql-11-320.jpg)
2011 06-12-lamp-mysql
- 1. MySQL Handler Socket & MySQL 5.5 部分新特性介绍 完美世界 顾春江 guchunjiang@wanmei.com
- 2. ● Handler Socket 项目的意义 ● Handler Socket 实现的途径 ● MySQL Plugin 体系简介 ● MySQL 5.5 新引入的 semisync 复制 ● MySQL 5.5 值得关注的几个参数及性能变化
- 3. Handler Socket 出现的意义 ●众所周知 RDBMS 的 SQL 引擎存取代价大，对轻量 k/v 型数据没有较好的应用模式 MySQL 和 Memcached 整合后， MC 的数据一致性问 ● 题，服务器管理，可用性管理都需要考虑 Memcached 的持久化问题 ● ●最好有一种方式能跳过 MySQL 耗时的 SQL 语法解析 器而直接访问存储层
- 5. 性能瓶颈 ● 对于 k/v 式操作，即使是用了 prepared statement， 或者 query cache 等各种优化， 每秒执行语句的速度也是 Memcache 的4-5分 之一左右 Vmstat 中 user 的 CPU 时间比 sys 时间多不 ● 少，因此各种 mutex lock 并非是影响性能的主 要瓶颈
- 6. $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 1 us sy id wa st 55 36 9 0 0 53 34 13 0 0 vmstat 的 user 时间占了一半多
- 7. 资源都消耗在哪里 用 OProfile 查看系统调用 samples % app name symbol name 259130 4.5199 mysqld MYSQLparse(void*) 196841 3.4334 mysqld my_pthread_fastmutex_lock 106439 1.8566 libc-2.5.so _int_malloc 67945 1.1851 mysqld ...make_join... 63435 1.1065 mysqld JOIN::optimize() 55825 0.9737 vmlinux wakeup_stack_begin 55054 0.9603 mysqld MYSQLlex(void*, void*) 可以看到， SQL 解析相关的调用占了大部分 CPU 时 间，如果能跳过 SQL 解析层就能好很多
- 8. 如何降低查询开销 一般 MySQL 客户端进行查询，有如下过程: ● SQL Parser 解析 SQL 语句 ● 打开表对象句柄，申请 mutex ● 根据表信息生成 SQL 执行计划 ● IO 读写 ● 释放 mutex， 关闭表对象句柄 这5个步骤中，只有第四步是 IO 向的，其余 都是 CPU 向。
- 9. 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 底层就是基于这个接口来实现的。
- 11. HS 以插件形式启动，启动后监听2个特殊端口，分别接受读请 ● 求和写请求，并且 fork 出可配置数量的服务线程 ●这些服务线程将轮番处理客户端请求，并对多次分散的请求做 合并处理 HS 不会不停地打开/关闭表对象句柄，它在打开后会保持一段 ● 时间，如果在一段时间内没有请求才会关闭，以方便句柄重用 ● HS 自己实现了一套基于文本的通信协议（类似 Memcached 的 协议，很简洁，不用构建语法树也不需要优化），支持 telnet 的 调试 open_index <indexid> <dbname> <tablename> <indexname> <columns> [<fcolumns>]
- 13. 测试效果: 创建带主键的 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
- 14. 再看 OProfile 的数据: 847486 5.0876 ha_innodb_plugin. ut_delay 545303 3.2735 ha_innodb_plugin. btr_search_guess_on_hash 317570 1.9064 ha_innodb_plugin. row_search_for_mysql 298271 1.7906 vmlinux tcp_ack 291739 1.7513 libc-2.5.so vfprintf 264704 1.5891 vmlinux .text.super_90_sync 248546 1.4921 vmlinux blk_recount_segments 244474 1.4676 libc-2.5.so _int_malloc 发现原来占用 CPU 时间非常多的几个 SQL 解析调用都已经不在列表上 了，而且此时的 vmstat 数据 sys 占了几乎80%左右的 CPU 时间，说明 优化已经奏效。
- 15. HandlerSocket 的特点 ● 性能卓越 ● 不再有重复的 Cache， 数据保持一致 ● 不影响正常数据库功能的使用 ● 以插件的形式存在 ● 内置线程池 ● 利用 MySQL 的 Handler 接口，和底层引擎 类型无关
- 16. Handler Socket 的限制 ● 缺乏安全性 ● 对于磁盘 IO 向的场景没有效果 ● 性能瓶颈从 CPU 向转到网卡向 ● 加重 slave 的复制压力
- 18. MySQL Plugin 类型 ● Daemon Plugins ● INFORMATION_SCHEMA Plugins ● Storage Engine Plugins ● FullText Parser Plugins ● Audit Plugins ● Authentication Plugins ● Replication Plugins
- 19. MySQL Server st_mysql_plugin demo1= st_mysql_plugin demo2= { { Int type; Int type; void *info; void *info; ... ... } } Binlog_transmit_observer { rpl_stat_transmit_start, NULL, NULL, rpl_stat_before_send_event, ... }
- 20. MySQL Plugin essentials mysql_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;
- 22. MySQL 5.5 SemiSync ● 修改了原生复制的 packet header, 添加 BINLOG_SEMI_SYNC 0x02 ● session 事务提交成功，如果至少有一个开启 了 semisync 的 slave 的 io thread 接收到 commit 复制事件 ● 如果 master 等待 ack 超时，事务会被提 交， semisync 将被自动关闭，直到有一个 slave 跟上 master ● 支持 GROUP COMMIT
- 24. semisync 效率 1200000 1110723 1000000 800000 异步 600000 semisync 504971 400000 200000 0 2 million, 8G 4 million, 17G
- 26. 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 };
- 27. MySQL 5.5 的变化
- 28. MySQL 5.5 的改进 ● MySQL 全面改用 CMake 作为主编译系统 ● InnoDB 成为默认引擎， Barracuda ● MySQL 在 Win 平台上的性能提升较大 ● 复制能够被更好地监控和管理 ● 执行 SQL 语句时支持自定义异常处理并可 将异常抛会调用程序 ● 新增性能模式库( Performance Schema)
- 29. 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 支持
- 30. 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)
- 31. 磁盘性能 IOPS 带宽 只读 4,159 op/s 297 MB/s 只写 1,592 op/s 176 MB/s 读写 1,296 op/s 4k block
- 32. MySQL 5.5 vs MySQL 5.1 MySQL 5.5 配置 MySQL 5.1 配置 innodb_buffer_pool_size=20G innodb_buffer_pool_size=20G innodb_file_per_table=1 innodb_file_per_table=1 innodb_doublewrite=0 innodb_doublewrite=no innodb_max_dirty_pages_pct=80 innodb_max_dirty_pages_pct=80 innodb_flush_log_at_trx_commi=2 innodb_flush_log_at_trx_commit=2 innodb_log_buffer_size=8M innodb_log_buffer_size=8M innodb_thread_concurrency=0 innodb_thread_concurrency=0 innodb_flush_method = O_DIRECT innodb_flush_method = O_DIRECT innodb_write_io_threads=24 max_connections=3000 innodb_read_io_threads=24 query_cache_size=0 innodb_io_capacity=2700 #IOPS query_cache_type=0 innodb_use_native_aio max_connections=3000 query_cache_size=0 query_cache_type=0
- 33. MyISAM 引擎只读测试
- 34. MyISAM 引擎读写测试
- 35. InnoDB 引擎只读测试
- 36. InnoDB 引擎读写测试
- 37. tpccmysql 测试使用500 w 的数据基数，64个并发线程，200秒预热时间，测试时间:3000秒。
- 38. Q & A