O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

MySQL新技术探索与实践

376 visualizações

Publicada em

  • Seja o primeiro a comentar

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

×