Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MySQL优化、新特性和新架构 彭立勋

1,371 views

Published on

Published in: Technology
  • Be the first to comment

MySQL优化、新特性和新架构 彭立勋

  1. 1. MySQL优化、新特性和新架 构 彭立勋 WWW.PengLiXun.COM Alibaba  DBA  Team
  2. 2. Topics•  挖掘MySQL性能•  InnoDB Plugin新特性•  Percona带来的改进•  “动静结合”的分布式数据库架构•  Q & A
  3. 3. 挖掘MySQL性能•  优化编译:ICC取代GCC•  优化文件系统:XFS取代EXT3•  优化存储:SSD取代SAS•  优化接口:Handler Socket取代SQL
  4. 4. ICC取代GCC•  ICC能有效利用Intel SSE2指令集,浮点 运算效率高•  ICC内置Intel Math Lib,提升数学函数 效率•  ICC内置Intel Thread Lib,提升多线程 稳定性和效率
  5. 5. ICC vs GCC硬件环境CPU:Intel Xoen 5520内存:24G硬盘:10*15k SAS RAID10
  6. 6. XFS取代EXT3•  XFS全B-Tree结构,适合大文件操作•  XFS原生日志设计,日志检查速度远快于 EXT3•  XFS采用延迟分配,提升分配效率
  7. 7. EXT3 vs XFS 64K顺序INSERT效率350   295  300  250   210  200   EXT3  150   140   XFS   100  100   50   0   插入速度(Rows/s)   相对比例(%)  
  8. 8. SSD取代SAS•  一块SSD盘相当于一套高端存储的IO能力•  读写不对称,适合用于二级读缓存和日 志缓冲
  9. 9. SSD vs SAS
  10. 10. Handler Socket取代SQL•  绕过费时的SQL解析,简单SQL通过API直 接访问InnoDB
  11. 11. InnoDB Plugin新特性•  新的文件格式 –  可选择的页大小(Page Size) –  可压缩的Blob Page•  开放IO参数 –  innodb_io_capity –  read/write_io_thread•  脏页刷新方式改进 –  innodb_adaptive_checkpoint(XtraDB) –  innodb_adaptive_flushing(InnoDB Plugin)
  12. 12. Adaptive Flushing•  通过日志剩余空间除以日志产生速度算 出切换前可以使用的时间:time_remainning = log_capacity / redo_gen_rate•  必须在日志切换前完成所有脏页的刷新, 所以可以计算出刷新速度:flush_rate = dirty_page_numbers / time_remaining = dairty_page_numbers * redo_gen_rate / log_capacity•  将刷新速度减掉LRU_List刷新速度就可 以得出Adaptive Flush必须的速度了: adaptive_flush_rate = flush_rate – lru_flush_rate = dairty_page_numbers * redo_gen_rate / log_capacity – lru_flush_rate
  13. 13. Adaptive Checkpoint•  None:关闭自适应刷新•  Reflex:脏页少于1/2则不刷新,超过 1/2则使用Weak Flush,超过3/4则使用 Strong Flush,大于7/8将不断刷新。•  Estimate:脏页少于1/2则不刷新,超过 1/2则基于未刷新的脏页量、日志产生速 度、刷新页的Modified Age来计算刷新 速度,大于7/8将不断刷新。•  keep_average:刷新周期从1s提高到 0.1s
  14. 14. 自适应刷新方式
  15. 15. InnoDB IO流程
  16. 16. Percona带来的改进(1)•  提升Buffer  Pool的扩展性 XtraDB将Buffer  Pool的全局Mutex拆成了多个Mutex以减少争用  •  提高InnoDB  IO扩展性 XtraDB增加了许多变量去调整IO到最佳状态,包括调整 checkpoint、后台读写数据文件线程数等等的参数  •  多个回滚段 为提供一直读,InnoDB将事务修改的数据写到回滚段。回 滚段被一个独立的Mutex保护,这直接导致了写密集型的工作并发 不高。在 XtraDB可以改变回滚段的数目(innodb_extra_rsegments) ,在写密集型操作中可以大幅度提高性能  •  可以更高的并发数 InnoDB在回滚段只提供了1024个回滚槽,如果回滚槽用完 ,新的事务将不能开始,直到有回滚槽被释放,XtraDB提供2047个 事务槽
  17. 17. Percona带来的改进(2)•  专用的Purge线程 如果有很多事务,Purge线程清理空间不够快,共享表空间 将急剧增长。这 将导致性能严重下降,甚至可能用完所有的磁盘 空间。XtraDB使用了专用的线程来清理undo  space,这对undo  space 的清理速度可以提升很多。尽管这可能使整体的性能降低,但是可 以大大提高稳定性,因而整体性能略微降低是值得的  •  可配置的Doublewrite缓冲 XtraDB提供了一个选项将doublewrite  buffer放在一个独立 的磁盘来提升并发性能  •  删除过多的函数调用 当MySQL从socket读数据时,将产生很多fcntl(针对描述符 提供控制的函数)调用,导致并发性能下降。Percona移出了多于 的调 用  •  减少了Buffer  Pool  Mutex竞争 在InnoDB内核操作时减少了Buffer  Pool之间的Mutex争用(拆分 Mutex变量)
  18. 18. 新分布式数据库架构•  静态服务器:主要数据存于静态服务器,除 合并数据时,静态服务器数据不变。静态服 务器为一组服务器池。•  动态服务器:更新操作全部集中更在动态服 务器,在合并数据时,动态服务器数据集中 刷入静态服务器。•  查询:从静态和动态服务器同时查询,合并 结果。
  19. 19. 程序结构
  20. 20. 操作流程
  21. 21. Q&A

×