May 2014

zlib库优化性能测试(port from facebook and intel)

背景 facebook基于zlib 1.2.5 做了些改进,并port了intel的一些相关补丁。本文主要目的是验证其压缩效果 主要有两个补丁: https://github.com/facebook/mysql-5.6/commit/8ac9e7d219c8679b75da26e64d702b5517d05ea8 (Optimize zlib for a non-sliding window.) https://github.com/facebook/mysql-5.6/commit/ed46ec9b4ef367f3335a531999f39cb1d9d40341 (port from intel) intel补丁的主要修改: 1) By default, use CRC32 as the hash, computed using SSE4.2 2) Also provide a better fallback hash in case of no SSE 3) By default use double-byte comparisons by enabling UNALIGNED_OK 4) Use best_len_minus_1 instead of best_len in longest_match() […]

MySQL metadata lock的前世今生(5.1=>5.7)

最近有同事经常问到一些metadata lock相关的问题,就顺便理一下吧,主要是整理下相关的连接和文档,标题写的有点大 🙂 ——————————– 最初为了解决著名的bug#989,在MySQL5.5中开始引入了meta data lock;mdl允许一个事务涉及到的表、库信息直到事务结束都被维持,这样如果一条事务内的某个STATEMENT完成后,其他session发出一条DDL就会被阻塞;这解决了DDL/DML并发导致的复制中断问题。 不过用过5.5的人都知道,这玩意儿实际上太令人讨厌了,尤其是那阴魂不散的“wait for global read lock”或者“wait for table lock”之类的。当备份时的大查询,再来个DDL,哐当~故障发生..直接堵死… 在我们的内部alisql-5.5版本中,我们使用的是和facebook类似的办法(好吧,就是我直接从fb port过来的),即增加接口替换掉flush tables with read lock, 只创建一个read view ,外加返回当前binlog位点;另外percona也实现了一种类似的办法来绕过ftwrl,具体点击文档连接以及percona的博客, 不展开说了。 MDL解决了bug#989,却引入了一个新的热点,所有的mdl对象由于存到全局对象里;对于热点,最正常的想法当然是对其进行分区,不过这也是Mark Callaghan在report了bug#66473后才加入的,当时Mark观察到MDL_map::mutex的锁竞争非常高,进而推动官方改变; 在MySQL5.6.8版本,引入了新参数metadata_locks_hash_instances来控制对mdl hash的分区数(Rev:4350); Oracle的QA dimitrik 对该特性的评测 不过后面的测试又发现哈希函数有问题,类似类似somedb.someprefix1….somedb.someprefix8的hash key值相同,都被hash到同一个桶下面了.相当于hash分区没生效。。。。坑!!具体怎么算的可以看bug#66473后面Dmitry Lenev的分析。 另外Mark也提出了质疑,innodb的hash计算函数比my_hash_sort_bin要更高效, Oracle的开发人员重开了个bug#68487来跟踪该问题,并在MySQL5.6.15对hash key计算函数进行优化,包括fix 上面说的hash计算问题(Rev:5459),使用MurmurHash3算法来计算mdl key的hash值,(有空看看几种hash函数到底哪个性能更好) 往后直到MySQL5.6.18版本都没有针对mdl部分的单独优化;很显然,后面也不会在5.6版本里出现了,因为mdl优化已经在5.7.4版本里展开了。包含3个worklog 1. WL#7304 简化DML操作对MDL锁的持有/释放;大体思路是把MDL锁拆分成两类,一类是DML的mdl(也成为unobtrusive lock),之间互相兼容,另一类是DDL的mdl(也称为obtrusive lock),与其他锁互斥; 针对DML的MDL,避免了复杂的锁检查和对m_waiting/m_granted链表的维护,改而使用计数器的方式来实现(称为fast-path);不过相应的对DDL的MDL锁的管理逻辑就变的复杂了。没有细看,貌似fast-path的mdl在遇到冲突时会进行转换,将其加入到m_granted列表中,并从m_fast_path_state移除 PATCH(Rev:7067, Rev:7129) 2. WL#7305 使用Lock free的hash对象来管理MDL;由于锁冲突被移除,因此metadata_locks_hash_instances及metadata_locks_cache_size在之后的版本中可能被弃用; 基本思路是使用LF_HASH(lock free hash, 而不是分区的hash)来实现MDL_MAP PATCH(Rev:7249) […]

MySQL5.7.4的semisync优化:异步化binlog dump及接受ack

很高兴的看到,在MySQL5.7版本里,semisync开始进行显著的优化,fix了不少遗留bug,例如支持一主多备的半同步;在server层判断备库是否要求半同步以减少Plugin锁冲突;支持在事务commit前等待ACK;解除binlog dump线程和LOCK_log的冲突等等。 在MySQL5.7.4里,俺最关注的改进当然是对发送binlog和接受ack的异步化了。开发者的博客的测试数据还是比较诱人的;偷个懒,直接扣的作者的图 🙂 旧的逻辑:             新的逻辑:                 在开发者的测试中,最大可以达到4x的tps提升,网络延迟越大,TPS提升越明显 详细见开发者博客(貌似要翻墙): http://my-replication-life.blogspot.sg/2014/03/faster-semisync-replication.html 花了一天时间把这些改进port到了我们的内部分支alisql5.5,简单测试了下: 使用sysbench, 20个表,每个表30w数据,负载为update_index.lua,100个session并发 在不开启备库延迟刷mater info的情况下,使用AFTER_COMMIT,从11000TPS上升到20000,而在AFTER_SYNC场景下,从16000上升到25000 测试的两个实例属于同城异地机房,Ping的延迟在0.75ms左右。 从测试的结果来看,性能提升还是非常明显的,具体实现不多说了,worklog上写的非常详细: worklog链接:http://dev.mysql.com/worklog/task/?id=6630 launchpad链接:http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/7351 大体的实现思路是: 备库io线程使用TCP协议和主库交互,读写socket可以同时进行; 在开启主库semisync时,启动一个后台线程,使用select监听备库连接socket; dump线程不再等待备库ACK;在ack reciver线程等待ACK时,dump线程还能继续发送下一组group commit的binlog,进而提升TPS 原创文章,转载请注明: 转载自Simple Life 本文链接地址: MySQL5.7.4的semisync优化:异步化binlog dump及接受ack Post Footer automatically generated by wp-posturl plugin for wordpress.