查看: 13603|回复: 16

【话题讨论】面对不可预料的性能问题 如何打破数据库瓶颈

[复制链接]
认证徽章
论坛徽章:
24
技术图书徽章
日期:2013-08-16 14:31:52问答徽章
日期:2013-11-04 08:53:14目光如炬
日期:2013-12-23 06:00:11目光如炬
日期:2013-12-30 06:00:11明星写手
日期:2014-02-22 06:00:12马上有钱
日期:2014-03-31 14:09:05沸羊羊
日期:2015-05-20 12:42:59秀才
日期:2015-06-24 13:05:36秀才
日期:2015-07-13 09:48:14
发表于 2013-10-10 15:01 | 显示全部楼层 |阅读模式
    数据交互复杂度与频度的提升,导致了数据库在运维、迁移和规模扩展进程中的性能问题。作为一项确保企业IT基础部件健康运营的关键技术,数据库性能优化的实现路径和IT系统管理架构越来越密不可分。不管是运维还是开发的同学,总是担心新上线的业务系统会出现不可预料的性能问题,有什么方法可以避免吗? 今天我们就来讨论讨论可能遇见的一些瓶颈问题,以及如何解决。

案例分享:
    首先给大家分享一下上次“
oracle技术嘉年华”简朝阳分享的提高CPU性能 打破数据库瓶颈案例。他在谈到基于硬件来进行数据库性能瓶颈分析的时候,表示不是使用更为强劲的主机或者存储来替换现有的设备就能够打破瓶颈,而是要去分析到底是硬件的哪块短板造成了数据库的性能瓶颈。

    他表示在谈论基于硬件进行优化的时候,不能仅仅将数据库使用的硬件划分为主机和存储两部分,而是需要进一步对硬件进行更细的分解,至少也应该分解到如下范畴:主机的CPU、内存、磁盘、Raid卡、电池等一系列东西。比如说CPU仅仅只能决定运算速度,及时是运算速度都还取决于与内存之间的总线带宽以及内存本身的速度;内存大小决定了所能缓存的数据量,主要决定了热点数据的访问速度;磁盘的转速决定了你每一次IO请求的延时时间,也就是决定了我们常说的IOPS和MBPS。硬件角度所能提供的处理能力,一定是上面所列的多个方面(这里仅仅只是主要部分,可能还有其他)共同决定的整体能力,任何一个方面出现瓶颈,都能导致整体性能上不去,也就是我们常说的木桶原理。

   同时简朝阳老大也指出提高CPU性能问题解决方案:
  
      1、降低逻辑运算量
  ①避免使用函数:将运算转移至易于扩展的应用服务器中如substr等字符运算,dateadd/datesub等日期运算,abs等数学函数
  ②减少排序:利用索引取得有序数据或避免不必要排序如 union all代替 union,order by 索引字段等
  ③禁止类型转换:使用合适类型并保持传入参数类型与数据库字段类型绝对一致如数字就是用tinyint/int/bigint等,必需转换的在传入数据库之前就在应用中转好
  ④简单类型:尽量避免使用复杂类型,降低由于复杂类型带来的附加运算

  2、减少逻辑IO量
  ①Index:优化索引,减少不必要的表扫描如增加索引,调整组合索引字段顺序,去除选择性很差的索引字段等等,更多详见这里
  ②Table:合理拆分,适度冗余如将很少使用的大字段拆分到独立表,非常频繁的小字段冗余到“引用表”,更多详见这里
  ③SQL:调整SQL写法,充分利用现有索引,避免不必要的扫描,排序及其他运算如减少复杂Join,减少order by,尽量union all,避免子查询等,更多详见这里
  ④合理数据类型:够用就好,减少不必要的一味使用大字段如 tinyint够用就别总是int,int够用也别老bigint,date够用也别总是替mestamp

  3、减少请求量
  ①适当缓存:对静态并被频繁请求的数据进行适当的缓存如用户信息,商品信息等等
  ②优化实现:尽量去除不必要的重复请求如禁止同一页面多次重复请求相同数据的问题,通过跨页面参数传递减少访问等
  ③合理需求:评估需求产出比,对于产出比极端低下的需求合理去除

讨论话题:大家平时在数据库性能优化存在很多程式化的内容,每一个的DBA应该都有自己解决问题的套路,欢迎大家分享一下自己在解决性能瓶颈时的经验心得。

讨论时间:2013.10.10.--2013.10.25

讨论奖励:活动结束后将会抽取5名会员赠送社区12周年纪念U型枕一件。
IMG_5045_副本.jpg





PS:第三届Oracle技术嘉年华即将来开帷幕,如果你想让大数据及云计算真正为你所用,创造价值; 如果你想集各家电商之所长,让你的数据架构更加卓越; 如果你疲于应付各种突发数据库问题,希望运维更加便捷; 参加Oracle技术嘉年华,这里不会让你失望!点击查看更多:http://www.itpub.net/thread-1810547-1-1.html
风铃中の鬼
assassinann
nannan5000
求职 : 数据库开发
认证徽章
论坛徽章:
28
ITPUB学员
日期:2009-10-14 18:49:45至尊黑钻
日期:2015-12-31 11:11:56数据库板块每日发贴之星
日期:2009-10-22 01:01:02优秀写手
日期:2014-04-30 06:00:17ITPUB8周年纪念徽章
日期:2009-10-09 21:30:10马上有车
日期:2014-10-09 10:14:53马上有钱
日期:2014-02-18 16:43:09路虎
日期:2013-10-15 15:38:59林肯
日期:2013-09-12 15:57:33ITPUB 11周年纪念徽章
日期:2012-10-09 18:11:48
发表于 2013-10-10 20:21 | 显示全部楼层
本帖最后由 风铃中の鬼 于 2013-10-10 20:22 编辑

我的工作中,大多数的性能问题都是从某个SQL执行缓慢开始发现的,我一般习惯先从SQL层面解决问题,初期都不会去询问硬件什么的

我第一步是先问,因为是各地现场的数据库情况不同,所以先要跟现场人员了解SQL用到的那些表有多大数据量,SQL查询的结果集大概有多少数据量(现场人员水平参差不齐,如果要他们拿出执行计划,参数什么的会花不少功夫,所以能以最简单的方式解决问题是最理想的情况)

第二步是“凭经验看表面”,先看看有没有瞅一遍SQL就能发现的可能引起效率的问题,比如在时间字段上套函数,少条件,用了多余的表,或者有没有数据量比较少表可以替换什么的。

第三步,如果根据表数据量判断这个SQL写的没什么问题的话,那就管现场要表结构,重点是检查是否分区和相应的索引

第四步,以上都没问题,那就要问现场要执行计划了,然后分析到底是哪里出了问题,这里有很多情况都是执行计划走错了,之后根据情况,把SQL拆成几个小SQL,看看执行速度,然后收集统计信息或者修改SQL的写法来改变执行计划,或者看看是否需要添加hints或者改变设计

第五步,通常一个SQL的性能问题在第四步都能解决,但也有很多例外,之后会出现一个选择,要么刨根问底,找出原因,要么做一次汇总(增加一张聚合表),把SQL拆分,通过汇总程序(我们用的是PERL)将数据分时间录入到一张新表里,然后前台的SQL就直接查这个新表就可以。

第六步:做汇总相对比较省事,若是要从SQL层面解决问题,那就要管现场要各种参数,或者用VPN直接联过去看(很慢很卡,通常VPN都是不得已的选择),然后就具体问题具体分析了,检查一下参数及硬件设备情况什么的,一般来部署数据库的是很有经验的工程人员,而且还有一套参数设置的指导文档,数据库的参数设置错误基本很少出现,大多数都是“无论怎么改变SQL写法,执行计划都是错的”这种情况,然后就慢慢查吧,这里有一个很重要的经验,一定要找相似的SQL或者表做对比:


举个例子,是informix的数据库,有一次SQL跑的很慢让我去查,结果发现执行计划里,那一条索引跑了几百遍,选择了多少网元,索引就会扫多少遍,经过上面前4步都不行,然后权衡了一下觉得有必要找出根源所在,所以就找了另一个相似但是效率很高的的SQL去看,对比过程略过,最终对比发现效率低的那个SQL里用到的2个表的索引字段顺序不一样(a表索引字段顺序是(网元,时间,时间粒度),b表的索引字段顺序是(网元,时间粒度,时间)),后来把索引字段顺序改变之后执行计划就正确了(只扫一遍索引)

像上面这样很无奈的情况遇到过不少,还比如某个函数导致不走分片什么的,简单的说如果遇到前4步都无法解决的问题,那就用2个方法:1.拆开SQL分步排查。2.找一个类似的SQL仔细对比

然后还有一个省事的方法就是把SQL拆分成单表的小SQL,用程序将结果汇总到新表里。。。。

使用道具 举报

回复
论坛徽章:
10
2014年新春福章
日期:2014-02-18 16:49:312014年世界杯参赛球队:克罗地亚
日期:2014-07-01 10:49:02优秀写手
日期:2014-07-01 06:00:122014年世界杯参赛球队: 哥斯达黎加
日期:2014-06-24 21:49:572014年世界杯参赛球队: 哥伦比亚
日期:2014-06-24 21:49:572014年世界杯参赛球队: 哥伦比亚
日期:2014-06-24 21:49:572014年世界杯参赛球队: 厄瓜多尔
日期:2014-06-24 21:49:572014年世界杯参赛球队: 英格兰
日期:2014-06-24 21:49:57马上有钱
日期:2014-02-18 16:49:31马上有对象
日期:2015-01-13 09:29:09
发表于 2013-10-12 13:10 | 显示全部楼层
本帖最后由 assassinann 于 2013-10-12 13:10 编辑

面对不可预知的性能瓶颈,技术优化可以从sql、内存、i/o、网络甚至架构等多方面来着手进行调整,但数据库层面的调整就像用西药,治标不治本,不适当的程序并发压力和超大事务不提交你耐它何?数据库是一种稀缺的公共资源,N个应用共用一个数据库服务器。因此还得“对症下药”方可根除隐患。记得坛子里面的某位大牛曾经说过,大意是一个资深的DBA要面临的不仅是数据库技术上的挑战,还要面对开发人员、领导甚至是客户,一个好的DBA一定要对业务有深刻的理解。受该大牛的启发,对未知的性能瓶颈我们何妨拓宽一下解决问题的思路?抛开数据库优化吧,从业务上的优化入手,业务上的优化调整效果和技术上的调整效果往往不在一个数量级。

曾经的一个亲身经历:
数据环境
200G的数据量,包含资讯数据和盘后数字数据。以前采用资讯数据动态加载,数字数据每日生成静态页面的方式。新页面由于要读取的数据量增加,为增加用户体验,页面生成方式改为轮循机制,每10分钟读取一次数据库,生成静态页面,减少用户等待时间。

测试时问题:
1.应用事务并发很高,导致撑爆process最大连接数导致其他连接的拒绝访问。
2.top后发现数据库服务器内存占用率不高,16核CPU每核的占用率均在60%以上,影响到了其他程序读取数据库效率。

分析:
1.程序并发事务量增加;
2.需要读取的数据量增加;
3.生成静态页面时要读取大量的数字数据进行计算,需要占用大量的CPU资源进行数学计算,且每次计算都要占用CPU资源;

事务量增加撑爆process可以调整processes参数解决。需要读取的数据量变大很好理解,毕竟要在原来基础上展示更丰富的内容给客户。
但是请注意,主要是数字数据计算占用CPU资源,而且还是盘后数据而并非实时更新的数据!所以数字数据不需要每次进行计算更新。可以和开发人员进行沟通,商讨重新制定页面生成方案而不是在同一时间同一批次更新所有数据,而是应该分成两个模块生成--定时轮循更新资讯数据,每日盘后定时生成数字数据。调整后数据库压力骤减。

总结:
要快速解决数据库的瓶颈问题,需要快速准确定位问题,定位问题还不够,更重要的是挖掘深背后的业务问题。数据库面临的性能瓶颈,大多数时候是因为新业务的增加导致资源耗尽。因此要解决数据库的性能瓶颈,DBA一定要对数据库的系统的业务了如指掌,评估新业务的影响程度,大方向上优化业务逻辑,再辅以技术优化方为正道。另外除了手上有活,对公司业务的理解程度越高,工作中才越有竞争力。

以上浅见,当抛砖引玉,希望pubers踊跃探讨此话题。

使用道具 举报

回复
论坛徽章:
0
发表于 2013-10-10 15:21 | 显示全部楼层
是一个好活动。支持。
不过,从楼主的说明来看,似乎讨论的重点在查询与编译方面,似乎没有讨论数据库引擎方面的优化。

使用道具 举报

回复
认证徽章
论坛徽章:
24
技术图书徽章
日期:2013-08-16 14:31:52问答徽章
日期:2013-11-04 08:53:14目光如炬
日期:2013-12-23 06:00:11目光如炬
日期:2013-12-30 06:00:11明星写手
日期:2014-02-22 06:00:12马上有钱
日期:2014-03-31 14:09:05沸羊羊
日期:2015-05-20 12:42:59秀才
日期:2015-06-24 13:05:36秀才
日期:2015-07-13 09:48:14
发表于 2013-10-10 15:27 | 显示全部楼层
云天英雄 发表于 2013-10-10 15:21
是一个好活动。支持。
不过,从楼主的说明来看,似乎讨论的重点在查询与编译方面,似乎没有讨论数据库引擎方 ...

哈哈。小的能力有限,大家各方面的优化都可以谈一谈的

使用道具 举报

回复
招聘 : 数据库管理员
论坛徽章:
25
ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25itpub13周年纪念徽章
日期:2014-10-08 16:34:19itpub13周年纪念徽章
日期:2014-10-10 17:49:05马上有车
日期:2014-12-19 09:23:24马上加薪
日期:2014-12-29 20:30:27马上有车
日期:2015-01-20 22:29:13美羊羊
日期:2015-03-04 14:52:282015年新春福章
日期:2015-03-06 11:58:18狮子座
日期:2015-07-14 14:44:11秀才
日期:2015-08-17 13:13:32
发表于 2013-10-10 17:13 | 显示全部楼层
"表示不是使用更为强劲的主机或者存储来替换现有的设备就能够打破瓶颈,而是要去分析到底是硬件的哪块短板造成了数据库的性能瓶颈。"

就算是使用P750的POWER7 如果使用的无限制,性能可能比不上P690 POWER4的性能。

使用道具 举报

回复
论坛徽章:
8
奥运纪念徽章
日期:2013-05-20 09:57:09咸鸭蛋
日期:2013-07-04 19:41:36双黄蛋
日期:2013-07-07 14:20:58福特
日期:2013-10-29 19:43:16凯迪拉克
日期:2013-11-04 23:30:24ITPUB社区12周年站庆徽章
日期:2013-11-07 10:34:332014年新春福章
日期:2014-02-18 16:50:09马上有车
日期:2014-02-18 16:50:09
发表于 2013-10-10 19:44 | 显示全部楼层
不可预料的性能?绝大多数都是sql语句写的烂,哈哈。

使用道具 举报

回复
论坛徽章:
65
林肯
日期:2013-09-12 15:57:33马自达
日期:2013-10-11 13:52:31路虎
日期:2014-01-26 14:35:49三菱
日期:2013-11-25 11:21:19现代
日期:2013-08-29 14:39:50雪佛兰
日期:2013-09-12 15:55:00一汽
日期:2013-11-28 14:15:05技术图书徽章
日期:2013-12-11 10:10:51技术图书徽章
日期:2013-12-11 10:11:35技术图书徽章
日期:2014-01-14 10:54:13
发表于 2013-10-11 13:54 | 显示全部楼层
空间换时间

使用道具 举报

回复
论坛徽章:
0
发表于 2013-10-11 13:58 | 显示全部楼层
我一般的工作顺序:
1.先查找比较慢的sql语句,
2.分析执行计划
3.调整索引
4.查看等到任务类型
5.再确认是IO,还是Memory等硬件信息
6.数据库设计架构忽略(有问题,也费劲)

使用道具 举报

回复
招聘 : 多个岗位招聘
论坛徽章:
33
2010广州亚运会纪念徽章:跆拳道
日期:2010-11-22 15:42:39灰彻蛋
日期:2012-05-16 13:17:56参与WIN7挑战赛纪念
日期:2012-05-24 10:37:35茶鸡蛋
日期:2012-05-28 17:27:32灰彻蛋
日期:2012-06-13 18:48:14双黄蛋
日期:2012-06-14 14:32:02奥运会纪念徽章:帆船
日期:2012-07-10 09:43:29奥运会纪念徽章:足球
日期:2012-08-17 09:17:32奥运会纪念徽章:帆船
日期:2012-07-26 15:46:49奥运会纪念徽章:赛艇
日期:2012-08-20 16:23:58
发表于 2013-10-13 21:47 | 显示全部楼层
讨论话题:大家平时在数据库性能优化存在很多程式化的内容,每一个的DBA应该都有自己解决问题的套路,欢迎大家分享一下自己在解决性能瓶颈时的经验心得。

      干任何工作最重要的就是规范化,这就是规矩。
      也就是我们说的套路,解决问题的思路。
    第一先了解问题,需要我么从现场采集各种指标,收集硬件环境情况、软件环境情况。
    第二分析问题的原因可能性,根据实际情况,分析有哪些可能。
    第三,逐一落实,逐一排除每种可能。
      最后,解决问题~~~

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表