ITPub博客

KDB和Oracle的性能pk小记

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

注册时间:2012-05-14

  • 博文量
    1667
  • 访问量
    14184597