您的位置:澳门新葡8455最新网站 > 数据库管理 > 焚薮而田数量库卡,数据库优化案例

焚薮而田数量库卡,数据库优化案例

发布时间:2019-10-05 16:07编辑:数据库管理浏览(54)

     

    写在前面

      记得在自己学习数据库知识的时候特别喜欢看案例,因为优化的手段容易掌握的,但是整体的优化思想很难学会的。这也是为什么自己特别喜欢看案例,今天也分享自己做的优化案例。

      之前分享过OA系统、HIS系统,今天我们来一个最常见的ERP,ERP系统各行各业都在用,不同行业也有不同的特点,博主在做研发的时候还自己写过ERP也算是比较熟悉了。

      不管是本文分享的零售类,还是鞋服门店、家居、汽车、地产等等,也不管是某友、某碟,ERP有一个共同的特点,单据流程长,业务复杂,热点表明显,数据量大,涉及众多系统接口,各种大数据的统计报表....传统行业又缺乏DBA精心管理。

      慢是普遍的!

      最近一直很忙,博客产出也少的可怜,今天整理了一下自己做过优化或各种方案的客户已经超过千家,涉及各行各业,今天分享的案例算是在这些客户中比较典型的了!没有什么高大上都是常见的问题!在之前的博客中都有过提及,那么本篇我们就结合之前的技术点来看看这个案例。学习优化手段的看官们可以参见我的优化系列:

     

    写在前面

      本篇是赤果果的产品介绍文章,同时也是向使用数据库的战友们表达一下我们是怎样一步一步打磨产品,又有什么样的远景、动力让我们一直走下去....

      八年数据库之路的感悟 这篇文章最后所提到的数据库管理产品,又经过两年的不懈努力,一群带有热情的老技术打磨,现在3.0版本已经成功上线,并有将近500家线下企业客户使用,2500家线上用户,同时也承载着上千技术爱好者的大力支持。

      在这里也向一直支持我们的技术大牛们表达感谢!!

    SQL SERVER全面优化-------Expert for SQL Server 诊断系列

     

    --------------博客地址---------------------------------------------------------------------------------------

    Expert 诊断优化系列 

     

     

    废话不多说,直接开整-----------------------------------------------------------------------------------------

     

    要做到什么?

      复杂的技术简单化、可视化、自动化、智能化 (都是被无数产品说烂掉的词),解放DBA、解放IT管理人...

    用户现象

      系统慢!保存个单据要好几分钟,很多操作都超时,尤其到下午4点左右各种超时,收款什么的都收不了,

      查个报表一个小时,下班了还没查完,经常因为系统慢而加班,

      业务部门已经怨声载道,这个事情已经上报公司高层IT部分压力非常大!

    1.0的时代

      我们怎么样全面了解客户的数据库运行情况? 脚本? 命令? 又不全又累人,还不及时....我们做了最初的原形Expert for SQL Server ,他能帮助DBA 快速了解分析系统的运行情况,什么时间点出现过什么问题

      这样我们可以对众多服务器、众多客户的系统进行全面分析。而告别个人经验主义、效果看水平,这样的时代我们认准的事——分析全面

      告别:硬件说软件问题,软件说硬件不行,解决数据库问题就是换高速存储换完还不行再换服务器?

      图片 1

     

      同时我也通过1.0的产品写了一整套数据库优化的文章和案例 SQL SERVER全面优化-------Expert for SQL Server 诊断系列

      帮助技术同行解决各种数据库问题,当然最重要的还是告诉大家如何不轻易下结论,一切问题要——全面分析,找到根源

    系统环境

      首先我们来看一下这个系统配置及现状,为什么说这个客户经典?往下看就知道了...

      

      先来看看系统配置 :

      

      图片 2

     

       服务器的配置是:8路 24 core 做了超线程 384个逻辑CPU,内存1T,磁盘全闪

       图片 3

         SQL用了2012版本,补丁已经最新,而且服务器配置全部能够识别

        没错。相当牛逼得配置!

      

         图片 4

      

      数据库的大小在1.2个T

     

      咋一看也许数据量太大了,导致性能的问题!可又一想这么强力的服务器也不至于那么慢呀,难道是代码的问题?难道需要分库分表?

    2.0时代

      SaaS、云已经成为大火和无法阻挡的趋势,我们也同样开放了线上的诊断平台SQL专家云SaaS平台,免费帮助技术同行处理数据库问题,同时我们在1.0的基础上汲取各种场景、解决问题的思路,以1.0时代积累下的3000家客户运行情况提炼分析,把更多的指标,更多的问题场景融入到产品中,也得到广泛的认可。

      同时在2.0的版本中,我们也在智能化的路上前进了一大步,超过3000家的数据库运行情况,上万个问题场景,也酝酿出了 我们自动化解决问题的功能——智能加速与智能运维!

      图片 5

     

     

      SaaS平台的推出,让我们接触到了更多的数据库使用者,也接触到各种不同的系统运行情况,也有很多人在SaaS平台上寻求帮助,自己的系统有问题,又对数据库不懂,无法分析。

      在SaaS平台运行的一年半里,我们大约接到几百位求助者分享给我们的运行情况,我们也为他们全面分析并解决了数据库上的棘手问题,当然更多的是小白问题....哈哈哈哈

      小到解决问题,大到针对系统现状如何规划数据层应用,这样的过程是快乐了,技术是纯粹的,没有谈钱只有技术交流...偶尔大侠赏个红包,技术团队的兄弟也出门吃顿好的...哈哈哈

    数据库指标

      那么我们再看一下数据库的一些表象:

      每秒请求数量:

      图片 6

      用户连接数:

      图片 7

     

     

      语句执行情况:

      图片 8

      图片 9

      

     

     

      等待情况:

      图片 10

     

      图片 11

     

      等待时间:

      图片 12

     

       CPU指标:

      图片 13

     

      内存一些指标:

      图片 14

     

      图片 15

     

     

      磁盘队列:

      图片 16

     

     

     -------------------还很多指标就不一一展示了------------------

     

       看到这些基本的指标,除了慢你能看出什么?问题出在哪里?怎么样快速解决?能有一个优化的步骤呈现在眼前么?

     

     

    分析

      系统是真的很慢,慢语句数量很多系统阻塞也很严重,确实和客户反映的慢可以吻合。那为什么这么慢?什么原因导致的?

      我总结一般性能慢常和6大因素有关:

    1.   业务压力
    2.   硬件
    3.   环境
    4.   代码
    5.   数据库内部运行因素
    6.   架构

     

     奉上一幅草图

      图片 17

      系统压力:访问压力(也是我们常说的并发)其实并不大,用户连接数也没想像的那么多

      硬件:在内存和磁盘IO确实存在压力

      环境 :服务器和数据库版本什么的没什么问题,具体配置一会儿再看。

      代码 :最不想分析代码,我们留到最后

      数据库内部运行因素:从各种指标来分析,系统语句等待时间太长,导致语句完成慢,而等待主要有两部分:

    1.  硬件资源确实有压力
    2.  语句之前的阻塞太严重了,"LCK_M_",而且等待时间过长,竟然平均达到几百秒

      再分析...这么强的硬件,并不大的访问压力,竟然造成瓶颈?语句写的烂?程序实现的不好?缺索引?环境配置不对?

      下面我们来看看....

     

    3.0的时代来了

      在1.0和2.0累积下来的经验看,我们依然有很多不足:包括很多生僻的指标让初级使用者依然很难简单诊断,实时性诊断分析滞后,问题预警缺失,智能解决方案较为单一等等....

      对于使用者的需求我们一一整理足一强化、改善、研发....

      大家都喜欢用老外的产品,外来的就是最好的?我们国内产品差什么? 我们就是要打造No.1

      从功能到使用习惯再到智能化...我们一步一步前行,所有的客户建议都是我们最宝贵的财富...

      现在我们的3.0界面是这样的....

      图片 18

     

     

      首先我们美化了界面,IT的深蓝色调...常规关注指标的布局,使用习惯上页面的调转,目标源头的呈现等等

      并一改2.0重诊断分析问题,而变成简单呈现,简单发现,简单处理为原则。

      页面可能都是花架子,我们来说功能提升!

      

      这样的工具也许就是知道数据库的“昨天、今天、明天”,也就是“过去、现在和将来”

      图片 19

      

      下面列举一些简单又使用的功能

      实时知道运行了那、哪些语句、运行的好不好

      在运行状态的记录和分析基础上,我们最强化了就是方便...易用,如下面:

      任何时间点的运行语句很轻易的就可以呈现出来,点击即可了然于心

      图示是语句

     

     

      知道任何时间点执行的语句这可能只是最基础的功能,就算我知道了15点31分23秒,运行了个语句非常慢,可这个语句平时也不慢,拿下来一执行几毫秒就完成了。我怎么知道是什么原因造成的?当时怎么就执行那么长时间?

      语句实时查看

      图片 20

      分析语句行为,上面的例子有些经验的人都知道是语句执行的时候被阻塞了,而阻塞有两种:硬件的资源等待,或语句资源争用的锁(也是我们常说的锁表/死锁/阻塞)

      那我们就会清楚地知道当时是为什么慢? 卡在硬件还是软件的语句上? 

     

      语句阻塞等待 实时分析

      图片 21

      

      是被哪个语句卡住?为什么卡住?源头是谁?谁执行的从哪来的?什么程序过来的? 接口还是报表?

      语句源头分析 

       图片 22

      如果是被硬件资源卡住,是CPU、内存、还是IO? 

      为什么不够用? 当时硬件资源利用率怎么样? 

      硬件与语句关联分析

      图片 23

      我们经常被问题到底是硬件不够造成的还是软件的问题所困扰,在这样的情况下我们是否可以同时看到语句运行的好不好已经当时的硬件什么压力?这样是不是一下就解决了呢?

     

      硬件压力来源分析

      CPU已经使用到 90% 了? 哪些操作导致CPU高的?

      图片 24

      

      这些语句是否可以优化?

      图片 25

     

      

      数据指标全面,而且对分析问题的流程和逻辑做到只需 “按步骤点击” ,比如突然一个时间点系统慢了,要帮助管理人员清晰的展示出分析问题的逻辑!

      把DBA解决问题的思路融入产品,让非DBA也可以解决DBA问题,您说这样可以吗?

      图片 26

     

      也许这就是所谓的 “工欲善其事,必先利其器”

     

      其他的实时告警、趋势分析、深入体检等等功能,由于篇幅原因,简单贴以下图吧。

       趋势分析

      趋势分析可以拉长时间观察发生问题的规律

      趋势分析也可对系统进行预测分析,比如什么时间点该提升内存?

      图片 27

     

      自动化巡检

      图片 28

     

      其他功能

      图片 29

     

     

    --------------博客地址---------------------------------------------------------------------------------------

    博客地址 

     

     欢迎转载,请注明出处,谢谢!


    优化阶段一(常规优化)

      很多时候系统慢要究其原因,难道上线时候就这么慢?那不可能,厂商根本无法交付的!那么问题来了,什么时候开始慢的?对系统做过哪些调整?

      简单的调研开始...

      我靠!!!厂商完全不配合,工程师对系统及其不熟悉,一问三不知,最近做什么改动也说不清,用户也不知道。厂商给的结论:继续加硬件....更强的IO....数据分离减小数据量!

      协调厂商完全协调不动,基本没戏了!

      既然是数据库问题,那我们就数据库下手吧!从一名数据库从业人员来说,看到这样的系统一定要先解决大面积等待问题!个人经验来看很多系统大面积等待解决系统会有个很大的提升和改善!

      配合一些常规的调优手段阶段一开始了,主要给系统大面积创建影响高开销大的索引,调整系统参数,优化tempDB等....具体不细说了,前面系列文章中都有!

     

      预期:

      一般系统上面一轮优化会有明显的改善,我认为这一轮以后系统会明显变快,语句运行环境合适,索引什么的合理资源消耗自然就少,内存和IO压力也会有所减少。

      结果:

      系统内存,IO压力趋于平稳,慢语句数量有所减少,但依然很多,阻塞依然存在,超过2分钟的语句依然很多。

      

      优化前

      图片 30

     

      优化后

      图片 31

     

     

      优化前

      图片 32

      优化后

      图片 33

     

      

    再说点什么

      生活中的便利大家也都感觉到了,随便一个不方便,可能就有人做了对应的贡献,我们也一样,我们是一群老DBA跟年轻的从业者无法拼创意、无法比精力、体力。但我们也会用我们优势的经验来贡献我们自己的一份力量。

      新入行的DBA越来越少,能踏实肯学的就少之又少,数据作为企业命脉,各个企业都面临着数据库的问题,也许还有一些时间让我们这帮老鸟发挥一些余热。

      希望大家在看完本篇以后,有兴趣的技术咖可以花些时间多尝试一下,多给我们一些宝贵的建议。

      我们会在这样的技术贡献上越走越远,越来越深入,因为我们要打造的是 No.1

     ----------------------------------------------------------------------------------------------------

    如果您也遇到类似问题或者想加入我们欢迎微信交流

     图片 34

    注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
    若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

    优化阶段二(针对语句)

       再次分析解决大面积语句阻塞的系统,发现现在的情况,主要有如下几个:

    1. 内存某些时候还是存在波动,但整体IO 内存已经不是瓶颈。
    2. 系统中有SLEEPING的程序阻塞时间长
    3. 部分功能语句依然慢,消耗的资源很高。

      再次对系统调研:

    1. 执行的慢语句是什么业务,是业务功能?还是报表?还是接口?
    2. 系统中频繁且较慢的语句。
    3. 系统中阻塞的操作是什么。  

      

      调研后,我遇到了最常见也是最大的问题: 语句慢由于程序!在HIS的优化案例中就是因为程序大量使用自定义函数,我们没法改,我们巧妙的绕过。那么这次我们如何绕过?

       

      一:报表

      分析中发现程序系统中消耗最多资源的主要是报表。

      报表通过一系列复杂的查询插入到物理临时表,啥叫物理临时表? 就是非#temp 而是真真正正的插入到表中,用完在delete!

      插入在删除,中间还有跟业务表关联操作,导致报表也会阻塞业务!

      插入删除的数据量是多少? 你们猜一下??

      千万级别....

      

      二:接口

      接口程序中频繁调用业务数据并发更新频繁....导致业务受阻...

     

      三:问题代码

      代码的问题主要有两个:

      1.代码较复杂,需要细致优化。

      2.程序中存在连接泄露,简单理解成程序报错后事务不能有效处理,导致事务未提交阻塞系统

      图片 35

     

      针对第一部分报表,语句更是复杂至极...这东西不是短期就可以优化的,考虑分出去

      针对第二部分接口,修改接口视图,包括写法优化、添加索引、调用频率等;

      针对第三部分业务语句进行细致优化,查询提示,计划向导、重编译等等手段...

      

      

    优化阶段三(报表分离)

      经过前两个阶段的优化一般系都会明显好转,只剩报表没有处理,和一部分高消耗的频繁接口查询,这部分我们采用报表分离的方式去解决。

      这里面我们遇到一个问题,报表要写物理表!用2012 自带的AlwaysOn是没有办法实现的(辅助节点只能读)

      

      使用发布订阅,又不能同时满足数据安全和业务连续的要求,客户又不满意。

      

      我们想到是否可以把写入物理表变成写入#temp 临时表? 软件厂商给出的结论是:不可能....

      

         那这里面我们使用了第三方的产品Moebius集群(这里真的不是广告....)

     

      如何实现:  

      多活集群,几个节点数据实时一致,这样的基本知识就不普及了...集群介绍也免了

      首先程序只有一个连接字符串没法把报表指向到辅助服务器,我们只能通过Moebius集群的前端调度引擎,定制规则把报表所使用的存储过程定点指向到第二台服务器,解决了程序不能分离的问题。

      其次Moebius集群可以实现两个节点都可写,以满足辅助节点报表查询写入物理表的需要。

      再次临时表的写入量太大,千万级别数据同步也是问题,这里好就好在程序中写入的物理临时表都是以“Temp_” 开头并以GUID类型结尾。我们在这里设置了只要这样的表写入不会反向同步给主节点,这样根据规则控制双向同步满足了报表的要求,最终实现了报表的分离。

      报表快了? 当然没有,只是分离不可能快,但是好处有两个:

    1.   OLAP和OLTP分离事务阻塞得到解决
    2.   报表服务器和业务服务器可以根据自身的业务特别进行单独的个性化设置
    3.   根据报表的要求我们配置高速IO的硬件

     

      预期:

      语句已经优化,阻塞情况也被解决,CPU、内存、磁盘压力也没有了,系统肯定快起来了!

      结果:

      系统快起来了!

      

      最终业务系统节点全天24小时的慢语句数量:(虽然还有慢语句存在,毕竟是TB级别的数据量,不影响业务运行客户完全可以接受!)

      图片 36

     

    --------------博客地址---------------------------------------------------------------------------------------

    Expert 诊断优化系列 

     

     


     

      总结 : 系统慢往往我们要全面分析,本文提供的维度:

    1.   业务压力
    2.   硬件
    3.   环境
    4.   代码
    5.   数据库内部运行因素
    6.   架构

     

        往往优化真的不是简单的调一调语句,加一加硬件,全面地分析是根本解决性能问题的首要任务。

      当然不是所有的优化都可以彻底解决,如本文中报表的改善是通过读写分离的方式实现,很多时候在ERP系统中报表的处理方式都是如此,报表如果细致优化,那需要多长时间呀!也许都是重写了。

     

      本文的优化过程主要是:全面分析系统问题——〉宏观层面解决(环境、数据库内部运行因素、硬件压力)——〉低效代码调整——〉架构方案实现(稳定、安全、高效)——〉最终系统顺畅 无压力

     

      当然此案例中客户的数据量已经到了可以做数据分离,分区分表的阶段,但分享本案例的原因也在于,不要认为上TB的数据一定就要分库分表的各种拆分,在性能调优的简单付出中依然可以收获更大的收益,真心希望看官们在选择分库分表付出的极大代价之前可以找专业的人全面分析一下,仔细评估你的系统到底是什么瓶颈!

     

     

     ----------------------------------------------------------------------------------------------------

    注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
    若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

    如果您也遇到类似问题欢迎添加微信技术交流

     图片 37

     

    本文由澳门新葡8455最新网站发布于数据库管理,转载请注明出处:焚薮而田数量库卡,数据库优化案例

    关键词: