注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

风轻扬

活着就是为了追求幸福

 
 
 

日志

 
 
关于我

关注互联网应用架构、分布式与海量数据处理技术、云计算、数据库技术

网易考拉推荐

InnoDB的缓存替换策略及其效果  

2009-01-14 22:14:12|  分类: MySQL |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
我们开发自己的存储引擎页面缓存替换策略的过程中主要是参考了InnoDB与LRU-K算法。InnoDB缓存替换策略使用分代与LRU相结合的方式。分为old和young两个分代,系统维护old分代占总buffer大小的3/8左右。当一个 页面第一次被访问时,是加入到old分代的lru头。并不是每次访问一个页面时就将这个页提到lru的头部,而是在这个页面在LRU中的位置调整后,是否有很多页面已经被替换出去,若有,则将这个页面移到LRU头。系统在每个页记录调整该页在lru中位置当前系统总共替换了多少个数据页,比较页中记录的这 个计数与系统全局页替换计数,就可以发现上次调整这个页在lru链表中位置后,系统中又有多少个页被替换,若比较多,则再次调整该页在lru中的位置。由于第一次访问的页被加入到old分代中,因此一次表扫描不会导致young分代中的页被替换出去。

总的来说InnoDB的缓存替换策略非常简单,性能开销很低,但不知道其效果如何,因此今天进行了测试。测试时的表每条记录包含一个INT和两个CHAR(200)类型的字段,共20万条记录,其访问概率使用screw为1.2的Zip-f分布生成,这样访问概率最高的10%的记录的总访问概率为95%。表大小约占7000个页面,测试时设置InnoDB可用于存储数据的缓存页为730(InnoDB缓存大小必须设置为64个页的整数倍,无法精确控制到700个),约为数据量的10%。这时,理论上最优的缓存失配率应为5%。

使用10个线程进行测试,每个进行100000次随机操作,每个操作根据概率随机访问一条记录。测试之前先进行了一次全表扫描来预热。

测试之前各类读操作统计如下

| Innodb_buffer_pool_reads          | 77        |
| Innodb_data_reads | 7004 |
| Innodb_pages_read | 6994 |

测试之后各类读操作统计如下

| Innodb_buffer_pool_reads          | 72055      |
| Innodb_data_reads | 95197 |
| Innodb_pages_read | 95187 |
如果按Innodb_buffer_pool_reads计算,即不考虑预读时,测试期间读取的页面数为72000左右,失配率为7.2%。如果按Innodb_pages_read计算,即考虑预读时,测试期间读取的页面数为88200左右,失配率为8.8%。如理想的5%相比两者都还是有一定距离的。若能优化到理想状态,大致可以减少40%的IO。

同样的条件对比测试了一下,我们的存储引擎测试期间产生的读操作为62100次,稳定时的失配率为6.1%左右。目前还不清楚为什么我们的存储引擎为什么表现会比InnoDB要好,因为两者的策略是类似的。可能是因为InnoDB中的预读机制在这类纯随机的负载下反而会影响到缓存的命中率。由于Innodb_pages_read明显的超过Innodb_buffer_pool_reads的增长,可以看出测试过程中InnoDB也在不定的进行预读,有可能预读进来无用的页面,导致有用的页面被替换出去。我们的存储引擎的预读检测机制有所不用,在测试期间没有发生预读。
  评论这张
 
阅读(2538)| 评论(1)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017