ITPub博客

KDB和Oracle的性能pk小记

原创 作者:jeanron100 时间:2015-08-30 23:15:15 0 删除 编辑
在偶然的机会听到了KDB,然后带着好奇和新鲜感体验了一把这个传说中和Oracle 相似度达到99%的数据库。<br /> 其中一部分的驱动力在于这个活动的奖品很丰厚,参加活动后可以拿到一个iwatch,确实是很划算的一个活动。<br /> 而对于KDB的认识,也是在对比调优中认识到的,其实结果还是大大超出我的预期。<br /> 首先来简单说一下背景,我们一共十来个人,分成两队,红队和蓝队,然后红队调优Oracle,蓝队调优KDB,然后使用benchmark在同样的加压条件下的tpcc值作为参考来对比Oracle和KDB<br /> 乍一看Oracle这边的人很占便宜,至少调优的基准和方式方法感觉都是熟悉的,不用过多的花时间在熟悉KDB上面,而对于KDB这部分,其实我觉得还是占有一定的优势,因为两队都有专门的人来提供额外的信息咨询,原厂在这方面其实更有说服力,更有经验,支持力度更大,这个调优的玄妙之处就在于我们调试的Oracle系统是一个性能很差的一个环境,里面其实还是埋了不少的机关,需要在有限的时间里把tpcc的值跑上去。<br /> 所以分组之后大家简单做了分工,最开始我的脑海中的调优思路是内核调优,参数调优,文件调优,sql调优<br /> 结果一上来开始还是有些着急,其实大家的思路最后都是花更多的时间在数据库参数调优上了。<br /> 我本来准备先查看hugepage准备先查看一下,看没有调优的空间,结果一看aix的小机环境,配置不同,x86上的方式就不管用了,于是就果断放弃了,这个部分还是要好好补补。<br /> 大家抓取性能瓶颈的时候基本大致的一致是sga的部分,结果一时忽略了其实undo的部分是个硬伤,结果回过头来,调整的时候对方的tpcc已经远远领先我们了。这个时候我们所做的调优基本就是设置commit_write为nowait<span style="line-height:1.5;color:#333333;background-color:#FAFAFA;">方式,然后调整sga_max_size,sga_target,<span style="line-height:1.5;white-space:normal;color:#333333;background-color:#FAFAFA;">然后一边开始准备在线调整redo的大小,把原本的redo 50M的日志文件加大到百兆,</span><br style="line-height:16.3636360168457px;white-space:normal;" /> 抓取的addm报告中更多的是sql语句的调优建议,所以暂时没有深究。<br /> 所以第一阶段和第二阶段的调优对比效果还是不理想的。<br /> 这一轮下来,大家的士气也受到了影响,我们认真梳理了一下,在参数的调整上有几个层次,<br /> 隐含参数<br /> 我发现在数据库参数中埋了一个炸弹,就是把一个隐含参数给启用了,参数是_fast_cursor_reexecute而这个参数的默认值是false,所以简单评估之后就把这个值恢复了默认的值<br /> 在sga的调整上给了30G的sga,但是查看内存组件的使用情况,shared pool被压缩到了不到2G,在200多G的内存条件下,就把shared_pool的大小设置保持在10G以上,<br /> pga的部分也进行了调整,把pga的大小进行为了一定的调整。<br /> open_cursors的值太低,在1000个并发的条件下,当时的值是300,所以跑不上去,session_cached_cursors的值也比较低,做了小幅度的调整<br /> audit_trail的部分是DB,其实这个部分暂时还没有这个需求,在这种情况下审计部分的开销就不必要了,果断去除,设置为none<br /> 对于异步io的设置,filesystemio_options设置为setall,尝试启用异步io和direct io<br /> 还有一个坑就是sql_trace给打开了,果断禁用。<br /> 对于sql cursor的解析方式,大家还是建议改为similar,这部分也修改了。<br /> 在曹组系统级,大家把原有的CPU超线程设置给取消了。原来是4个,改为了默认的2个。<br /> </span>等大体这几个部分完成之后,再去跑分,发现和KDB组的成绩很接近了,一段时间还暂时超过了他们,这个时候才感觉到了一丝动力。<br /> 继续调整,抓取的awr报告显示还是存在一定的并发瓶颈,有一些row lock contention,在这个时候我查看了相关的几个表的ini_trans,还是原来的默认值,就简单进行了调整,把ini_trans调大。<br /> 后面的部分,在这个基础上再进行调优,大家就相对比较谨慎了,大家纠结比较多的一个地方就是redo的大小,甚至考虑要把它设置为一个极大的值,根据监控的情况,在过去的一个小时内redo切换次数在7次左右,还是可以进行小幅度的调整即可,不过后来大家大胆尝试的把redo设置为一个极大的值,效果反而还是不够理想,所以就果断放弃了。后面的更多精力就没有放在sql语句上,等到发现的时候时间已经不够了,发现其中一个性能瓶颈在于一个slelect max(xxx) from xxx的查询,其实完全可以在关注更多的细节,比如收集统计信息,比如查看index的设置情况,对面的KDB组还甚至考虑了对表进行重新分区,这些细节的调整还是有很大的作用的,非常值得肯定。这些额外的细节和加分点也着实为KDB的tpcc贡献了一部分分数。<br /> 最后Oracle和KDB的第三轮跑分结果比较相似,tpcc都在近9万,KDB略微要高一些,浪潮团队的之前的测试结果也基本和这个差不多,了解了KDB和其它数据库的对比测试,跑分的差距还是很大的,KDB的性能还是很高。对于这次优化精力我的总结还是在粒度和细节上功夫下的不够,在调优的方法和方式上,还是需要先从整体再到细节部分,不忽略每一个部分潜在的可能的性能问题。逐步深入,调优的改进之处就会更加有条理。<br /> 这种调优方式对我的感触还是很大,因为这种对比pk的方式感受更加直观,对我们分析问题和解决问题是一个非常真实的案例。没有了基准和对比的参考,我们调优的幅度和动力就不会完全发挥出来。看来这种pk的方式可以多推广推广,也非常感谢浪潮本着开放的态度来组织这次活动,无论熟悉还是不熟悉KDB的朋友都会有一些认识和了解,因为时间关系,在集群,容灾,管理方式上还没有进行深入的测试,不过相信结果应该也不赖,相信他们的技术团队在这次活动之后,也经受了很大的压力和考验,可以好好休息一下了。再次感谢。<br />
上一篇: gqlplus的简单使用
请登录后发表评论 登录
全部评论

注册时间:2012-05-14

  • 博文量
    1499
  • 访问量
    14156233