• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
2011 06-12-lamp-mysql-顾春江
 

2011 06-12-lamp-mysql-顾春江

on

  • 4,149 views

 

Statistics

Views

Total Views
4,149
Views on SlideShare
2,466
Embed Views
1,683

Actions

Likes
11
Downloads
91
Comments
1

7 Embeds 1,683

http://www.thinkinlamp.com 894
http://blog.thinkinlamp.com 651
http://thinkinlamp.com 103
http://cache.baidu.com 15
url_unknown 15
http://www.tuicool.com 4
http://blog.thinkinlamp.com} {124788812|||pingback 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    2011 06-12-lamp-mysql-顾春江 2011 06-12-lamp-mysql-顾春江 Presentation Transcript

    • MySQL Handler Socket & MySQL 5.5 部分新特性介绍 完美世界 顾春江    guchunjiang@wanmei.com
    • ●  Handler Socket 项目的意义●  Handler Socket 实现的途径●  MySQL Plugin 体系简介●  MySQL 5.5  新引入的 semi­sync  复制●  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.userwhere 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 ● Full­Text Parser Plugins ● Audit Plugins ● Authentication Plugins  ● Replication Plugins  
    • 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, ...    }
    • 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;
    • MySQL 5.5 Semi­Sync   
    • MySQL 5.5 Semi­Sync ● 修改了原生复制的 packet header,  添加 BINLOG_SEMI_SYNC 0x02 ● session 事务提交成功,如果至少有一个开启 了 semi­sync 的 slave 的 io thread 接收到 commit 复制事件 ● 如果 master 等待 ack 超时,事务会被提 交, semi­sync 将被自动关闭,直到有一个 slave 跟上 master    ● 支持 GROUP COMMIT
    • MySQL 5.5 Semi­Sync   
    • semi­sync 效率 1200000 1110723 1000000 800000 异步 600000 semi­sync 504971 400000 200000  0   2 million, 8G 4 million, 17G
    •    
    • 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.34­hardened­r6  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.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   
    • MyISAM 引擎只读测试   
    • MyISAM 引擎读写测试   
    • InnoDB 引擎只读测试   
    • InnoDB 引擎读写测试   
    • tpcc­mysql   测试使用500 w 的数据基数,64个并发线程,200秒预热时间,测试时间:3000秒。
    • Q & A