杨建荣的学习笔记

每天坚持一点点,个人微信公众号: jianrong-notes 个人邮箱:jeanrock@126.com

  • 博客访问: 13392719
  • 博文数量: 1502
  • 用 户 组: 普通用户
  • 注册时间: 2012-05-14 23:24
  • 认证徽章:
个人简介

每日发文,或技术、或总结,偶有日间小事也以为记,谓之学习笔记,成年累月1400多天,中间几乎没有间断,要旨只有一个:学习交流,共同进步 。 学习笔记精华整理,个人新书《Oracle DBA工作笔记》已开售,在京东,当当,亚马逊,淘宝,天猫均有售,欢迎选购。

文章分类

全部博文(1502)

文章存档

2018年(116)

2017年(321)

2016年(358)

2015年(360)

2014年(278)

2013年(48)

2012年(21)

分类: Oracle

2015-08-30 23:15:15

在偶然的机会听到了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的朋友都会有一些认识和了解,因为时间关系,在集群,容灾,管理方式上还没有进行深入的测试,不过相信结果应该也不赖,相信他们的技术团队在这次活动之后,也经受了很大的压力和考验,可以好好休息一下了。再次感谢。
阅读(15069) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册