MySQL数据库学习研究(细究Percona Server 5.6)

it2022-05-05  227

文献引自: https://www.percona.com/blog/2013/10/08/a-closer-look-at-percona-server-5-6/ Vadim Tkachenk 发表        2013年10月7日,Percona Server 5.6版本发行,是对MySQL官方版本的增强改进。Percona Server 5.6 是最好的免费MySQL分支版本之一,被用于更加苛刻的应用程序。我们第三方的主版本,Percona Server 5.6 做了许多功能方面的改进较比对MySQL 社区版本来说,其中包括扩展性,高可用性,备份,安全等功能。而这些功能只能在MySQL 5.6 商业版本才能看到。 Percona Server 5.6 新特性: 常规性能的提升 通过 TABLE/INDEX/USER STATISTIC  和 slow query log 等提供更广泛的诊断 进程池的插件 插拔式的身份验证模块插件 集成Percona XtraBackup:”真正“增量备份和归档日志备份 语句超时功能 完全兼容MySQL 常规性能的提升      MySQL 5.6 自身已经做了许多性能方面的修订,然而我们发现他们专注的方面是小数据集问题。换言之, 大多都是CPU 密集型工作负载(CPU-bound workloads)。      在我们研究中发现,IO密集型的方面(IO-bound cases),也有我们可以提升的空间。 从Percona Server 5.5 版本中分离出当年不错的缓存互斥对象(buffer mutex)到Percona Server 5.6 版本中。这个将会减少未来对缓存池(buffer pool) 的争用。 完成优先级互斥对象("priority" mutexes)和InnoDB中的读写锁(rw-locks),查看https://blueprints.launchpad.net/percona-server/+spec/xtradb-priority-mutex。空闲列表的优先级会再次被获取mutexes的优先级填满。 完成进程计划("Thread scheduling").目前最大的可能是,改变InnoDB Cleaner thread的优先级(change priority for InnoDB Cleaner thread)。这个可以帮助稳固性能,因此我们可以发现高IO负载的时候,the Cleaner thread 是"饥饿"状态且没有获取足够的CPU时间去工作。 完成新的等待算法(waiting algorithms with exponential wait)用于访问共享资源 对于 页清洗进程(Page Cleaner thread)做额外的优化    更多的性能提升和测试,我想Percona的工程师Laurynas Biveinis 和 Alexey Stroganov会给与我们满意答复,敬请期待。 通过TABLE/INDEX/USER STATISTIC 和slow query log进行诊断 尽管MySQL 5.6有功能丰富的PERFORMANCE_SCHEMA信息表提供,但我们决定保存我们自己的诊断功能,为什么?因为 他们使用简单,查看 Domas’ post  文章。 集成Percona XtraBackup:”真正“增量备份和归档日志备份        Percona Server带来了如下的备份功能: 跟踪数据页的变化做到增量备份(Changed page tracking AKA “Real” incremental backups).使用这一功能可以避免全表扫描,并且修改数据页的信息被有效保存在bitmap文件中。 归档日志(Archive Logs).另外一种执行增量备份的方法,是通过复制InnoDB事务日志并应用他们实行备份。 这些功能在Percona Server中是独一无二的,通过结合Percona XtraBackup,他们允许用户获得在备份架构中更具便利性。 语句超时功能    这个功能移植于Twitter的MySQL分支,用来允许用户控制语句的执行时间 我们如何对Percona Server做QA操作 对于QA测试,我交予 Roel Van De Paar和他的随机查询生成器(Random Query Generator).对Percona特定的功能进行测试,通过使用RQG加一些组合数学的参数的方法,完成测试。我们对Percona Server是有信心的,同样我们有发现,报告,修复的bug平台:quite a large number of bugs for upstream MySQL. 性能结果 当然我会分享基准测试结果,哪一类的性能指标获取可以达到我们预期的性能效果且能满足我上面表述的性能提升的部分呢? 测试,我使用sysbench OLTP 读写负载,并通过帕累托分布图来表示(pareto distribution)。数据集是32张数据表,每张表 有1000万行的数据,总共是77GB的数据。我们的兴趣是集中测试IO密集型负载能力。所以设置 buffer_pool size是25GB并且同时运行250个用户进程。 对于硬件的选择,我使用Cisco UCS 250 服务器。有两个ntel(R) Xeon(R) CPU X5670 内核,Ubuntu 12.04.3 LTS 做为操作系统, 并且使用高端的PCIe SSD 存储设备(有100000 IOPS能力和随机 16KB 写能力)。 让我们来比较Percona Server 5.6 和MySQL 5.6的负载能力,图标显示的是30分钟,以一秒做度量单位的效果图 吞吐量(越多越好) 95%响应时间(越小越好) 我们发现percona server 5.6版本提供了两倍于MySQL-5.6.14版本的性能(在吞吐量和响应时间方面)。 这个提升的可能在于减少InnoDB内部资源的争用,和对page cleaner thread优先排序以及空闲队列再填充。 现在来分享运行时配置的文件的情况如下: [ mysqld ] innodb_data_file_path = ibdata1 : 10M : autoextend innodb_log_files_in_group = 2 innodb_log_file_size = 2G innodb_buffer_pool_size = 25GB innodb_lru_scan_depth = 4000 innodb_flush_neighbors = 0 innodb_log_buffer_size = 256M innodb_io_capacity = 25000 innodb_io_capacity_max = 50000 innodb_flush_log_at_trx_commit = 1 innodb_buffer_pool_instances = 15 innodb_file_format = Barracuda innodb_checksum_algorithm = crc32 innodb_file_per_table = true innodb_doublewrite = 1 innodb_flush_method = O_DIRECT_NO_FSYNC innodb_purge_threads = 4 table_open_cache = 15000 open_files_limit = 15000 max_connections = 15000 innodb_read_io_threads = 8 innodb_write_io_threads = 8 innodb_change_buffering = all loose - innodb_sync_array_size = 16 sync_binlog = 0 query_cache_type = OFF thread_cache_size = 1000 back_log = 2000 connect_timeout = 15 loose - metadata_locks_hash_instances = 256 max_prepared_stmt_count = 1048560 loose - performance_schema = 0 # --- below is Percona Server Specific --- innodb_sched_priority_cleaner = 39    innodb_log_block_size = 4096 innodb_adaptive_hash_index_partitions = 65 对一些参数做一下注解: 1.请注意,我们使用的是全面持久化的设置,如下: innodb_flush_log_at_trx_commit = 1 innodb_doublewrite=1 innodb_checksum_algorithm = crc32 这是为什么不同于MySQL提供的结果,这里,他们为了获取好的性能数字,关闭了数据保护。 2.  innodb_checksum_algorithm = crc32.新的硬件crc32校验编码实际上会提供更好地性能。我们推荐使用它 3.Percona Server 专享的指定参数:

innodb_sched_priority_cleaner=39 – to give highest priority to page cleaner thread(给予page cleaner thread 高优先级设置) innodb_log_block_size=4096 – to use 4096 block size for InnoDB logs(对于InnoDB 日志使用4096 块设置)

innodb_adaptive_hash_index_partitions=65 – to enable partitioning of adaptive hash index, otherwise quite often this is a contention point.(开启自适应哈希索引分区设置,否则这里会是一个争论点)

一些Percona Server使用的默认变量.

innodb_foreground_preflush=exponential_backoffinnodb_empty_free_list_algorithm=backoffinnodb_cleaner_lsn_age_factor=high_checkpoint

做一个免责申明,我认为Percona Server 5.6和MySQL5.6性能区别,在大数据集,和大内存以及快速存储方面距离会越拉越大。

对于小数据集,在低端服务器产品上使用,Percona Server 5.6性能和MySQL 5.6性能是一致的。MySQL在优化InnoDB对于小数据集上做了卓越的贡献。

对于Percona Server 5.6来说,这点特性非常重要,它可以让你通过提高硬件的CPU速度,内存或者升级你的存储设备,来提升你的性能。

欢迎使用Percona 5.6,并期待你的回馈!

未来是?

我们绝不会止步于此,我们期待更好的改进和功能提升。 更多的InnoDB性能提升,我们所做的只是冰山一角,未来还有更广阔的大门为我们敞开。 支持TokuDB引擎 Per query variables. We will add a new scope (in additional to global and session) for MySQL variables: per query. You will be able to change some variable only for one specific query Percona XtraDB Cluster 5.6,将会在几个月之后,基于Percona Server 5.6这个版本退出 你需要任何关于Percona Server 5.6 升级或者迁移的帮助吗?我们这里可以提供帮助,Perconat有经验丰富的技术支持和咨询顾问。 我们随时等待你的电话, Contact us today . Vadim Tkachenko 简介 Vadim 领导Percona 开发团队,管理Percona Server产品,和Percona Server for MongoDB产品,Percona XtraDB CLuster产品 和Percona XtraBackup.他是一个固态存储方面的专家,帮助许多硬件和软件供应商在MySQL市场取得成功。 标签: MySQL替代物,MySQL 5.6社区版本,MySQL基准测试, Vadim Tkachenko drop-in MySQL replacement,   MySQL 5.6 Community Edition,   MySQL benchmarks,   Vadim Tkachenko 类别: 基准测试,MySQL,Percona Server,Percona 软件。 -----循序渐进,脚踏实地,不断学习,文章翻译水平有限,请各位老师专家批评指点------ -----版权所有,文章允许转载,但必须以链接方式注明源地址,否则追究法律责任!-----

最新回复(0)