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新技术探索与实践

367 views

Published on

  • Be the first to comment

MySQL新技术探索与实践

  1. 1. MySQL新技术探索与实践 彭立勋 WWW.PengLiXun.COM Alibaba DBA Team
  2. 2. 新技术风起云涌 • 以Percona/XtraDB为代表的MySQL分支 (MariaDB、Drizzle……) • 以HandlerSocket为代表的新接口 (Memcached Plugin……) • 以XFS/EXT4为代表的高性能文件系统(Btrfs、 ZFS……) • 以Flashcache为代表的二级缓存架构 (InnoDB Secondary Buffer Pool……) • 以Fusion-IO为代表的PCI-E SSD • 以Intel C Compiler为代表的高性能编译器 • ……
  3. 3. Topics • ICC • XFS • Percona • HandlerSocket
  4. 4. Why ICC • 为何自己编译MySQL?  官方无静态编译的Innodb Plugin版本  可以加入第三方Patch或修改源码  可以将第三方库静态编译到可执行文件(TCMalloc) • 为何使用ICC编译?  原生Intel SSE2指令集,浮点运算效率高  内置Intel Math Lib,提升数学函数效率  内置Intel Thread Lib,提升多线程稳定性和效率
  5. 5. ICC vs GCC(1) 硬件环境 CPU:Intel Xoen 5410 内存:24G 硬盘:10*15k SAS RAID10
  6. 6. ICC vs GCC(2) 硬件环境 CPU:Intel Xoen 5520 内存:24G 硬盘:10*15k SAS RAID10 MySQL:5.1.40 Enterprise
  7. 7. Why XFS • 为何不使用EXT3?  对SSD设备不友好,SSD是未来数据存储设备的趋势  删除文件速度慢,导致数据库Hang  对大文件读写性能不佳 • 为何选择XFS?  SGI已经在其大型机上应用多年(From 1994),稳定可靠  对SSD设备友好(延迟分配)  高并发下竞争少,性能好(分配组特性)  支持条带化分配,使得文件系统分配与RAID条带完全对 齐,最大化吞吐量  对大文件操作友好(基于Extent的分配方式)
  8. 8. Why NOT EXT4? • EXT4也是一款非常好的文件系统 • 性能与XFS接近,甚至好一些 • 并且可以从EXT3无缝升级 • But ...... • 我们没有运维EXT4的经验
  9. 9. XFS Tips • 分配组(Allocation Groups) • 延时分配(Delay Allocation) • 多线程DirectIO • 全B+ Tree管理空间
  10. 10. EXT3 vs XFS(1) 硬件环境 CPU:Intel Xoen 5520 内存:24G 硬盘:10*15k SAS RAID10 MySQL:5.1.40 Enterprise
  11. 11. EXT3 vs XFS(2) 硬件环境 CPU:Intel Xoen 5520 内存:24G 硬盘:10*15k SAS RAID10 MySQL:5.1.40 Enterprise
  12. 12. Why Percona • Percona的优势  对SSD设备有专门的优化  对Flashcache有SQL层接口  允许XtraDB静态编译  支持多种页大小  提供额外的监控参数  有被生产环境考验过(SOHU) • Percona存在的问题  引入第三方补丁较多,可能存在Bug(可以接受)
  13. 13. New Future(1) • 文件格式  Compressed结构:CPU换IO  Dynamic结构:ROW中不存大字段前缀 • IO参数  IO容量:innodb_io_capacity  IO线程数:innodb_read_io_threads(预读)、 innodb_write_io_threads(赃页回写)、 innodb_use_purge_thread(清理UNDO) • 赃页刷新方式  innodb_adaptive_checkpoint (XtraDB)  innodb_adaptive_flushing (InnoDB Plugin)
  14. 14. New Future(2) • 扩展性  增强多处理机性能(About 24 Cores)  拆分Buffer Pool Mutex(buf_pool_mutex、 LRU_list_mutex、flush_list_mutex、page_hash_latch、 free_list_mutex、zip_free_mutex、zip_hash_mutex) • 功能  可变页大小(innodb_page_size)  可控的Insert Buffering和Adaptive Hash Index  可配置多回滚段(innodb_extra_rsegments)  快速Warn Up(innodb_buffer_pool_shm_key 、 XTRA_LRU_DUMP/XTRA_LRU_RESTORE)  快速创建索引和索引快速重命名
  15. 15. New Future(3) • 监控  扩展information_schema – INDEX_STATISTICS – TABLE_STATISTICS – USER_STATISTICS  扩展InnoDB统计 – INNODB_TABLE_STATS – INNODB_INDEX_STATS  For Example – 可以获取未使用过的索引 – 可以获取索引被用于访问的行数 – 可以获取当前锁定信息 – 可以获取用户连接统计信息 – ……
  16. 16. Percona Performance 每秒处理50~75万行读取 每秒处理2.5K~5K Query 每秒网卡吞吐400~750Mbps
  17. 17. Why Handler Socket • SQL执行的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 …… 63435 1.1065 mysqld JOIN::optimize() 55825 0.9737 vmlinux wakeup_stack_begin 55054 0.9603 mysqld MYSQLlex(void*, void*) 50833 0.8867 libpthread-2.5.so pthread_mutex_trylock 49602 0.8652 ha_innodb_plugin.so.0.0.0 row_search_for_mysql …… 46499 0.8111 libc-2.5.so malloc
  18. 18. Why Handler Socket • HandlerSocket执行的Oprofile samples % app name symbol name 984785 5.9118 bnx2 /bnx2 847486 5.0876 ha_innodb_plugin.so.0.0.0 ut_delay 545303 3.2735 ha_innodb_plugin.so.0.0.0 btr_search_guess_on_hash 317570 1.9064 ha_innodb_plugin.so.0.0.0 row_search_for_mysql …… 206057 1.2370 HandlerSocket.so dena::hstcpsvr_worker::run_one_ep() 183330 1.1006 ha_innodb_plugin.so.0.0.0 mutex_spin_wait 175738 1.0550 HandlerSocket.so dena::dbcontext:: cmd_find_internal(dena::dbcallback_i&, dena::prep_stmt const&, ha_rkey_function, dena::cmd_exec_args const&) …… 149611 0.8981 ha_innodb_plugin.so.0.0.0 row_sel_store_mysql_rec
  19. 19. HS vs MC vs SQL 硬件环境 CPU:Intel Xoen 5520 内存:24G 硬盘:10*15k SAS RAID10 MySQL:5.1.48
  20. 20. Our Solution(1)
  21. 21. Our Solution(2) • RAID卡  关闭预读:预读效果不佳,直接读取磁盘  关闭磁盘Cache:RAID卡缓存已经缓冲了写操作,磁盘 Cache无电池  条带:默认64K,调整为1M • Linux  IO调度:/sys/block/sdb/queue/scheduler,默认cfq, 调整为deadline  减少预读:/sys/block/sdb/queue/read_ahead_kb,默 认128,调整为16  增大队列:/sys/block/sdb/queue/nr_requests,默认 128,调整为512  NUMA策略:numactl --interleave=all 或 -- cpunodebind=0 --localalloc
  22. 22. Our Solution(3) • Flashcache  Block Size=4K:与SSD设备页对齐  dirty_thresh_pct = 90:一个SET内90%都是脏块则刷新  write_merge = 1:写入合并,提升写磁盘的性能  fast_remove = 1:解除绑定时无需将脏块写入磁盘 • Percona  页设置:innodb_page_size=4096、 innodb_fast_checksum=1  刷新策略:innodb_adaptive_checkpoint=3、 innodb_flush_neighbor_pages=0  IO容量:innodb_io_capacity>10000  IO线程:innodb_read_io_threads = 1、 innodb_write_io_threads = 16
  23. 23. Our Solution(4) • 监控  Fusion-IO(fio-status): – Logical bytes written:逻辑写 – Logical bytes read :逻辑读 – Physical bytes written:物理写 – Physical bytes read:物理读  Flashcache(dmsetup status): – read hit percent:读命中 – write hit percent:写命中
  24. 24. Q&A E-Mail: PengLiXun@gmail.com

×