解决数据库卡、慢,问题多,难管理——老技术

作者:计算机专家

要做到什么?

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

写在前面

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

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

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

  慢是普遍的!

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

 

开篇小故事

  下面的故事都是真实的,犹如雷同纯属同类,请仔细反思。

  故事1:升级硬件

  客户后台数据库存在性能问题,查询特别慢,长时间语句很多。客户因此而苦恼,咨询了软件厂商我该怎么办?软件厂商给出的答案:升级硬件吧,现在的资源不能满足了!

  那么客户是什么硬件配置呢?数据库什么体量呢?

  答:128的CPU、512的内存、高端的存储,跑了一个200G数据量的库,好像硬件满满的够用呀!

  问题的根源就是最基本的大量少索引而已!

  

  故事2:负载均衡

  客户想做数据库的负载均衡,于是找到我们,各种方案各种高大上的说,我深深的被客户的前卫思想洗礼了一下,毕竟传统行业很多对数据库性能,安全方面的一些保障不是很完善。

  前期谈的很愉快,然后我去检查客户的现有环境,更惊奇的事情发生了,2台跑在同一个物理机上的虚拟机要做负载均衡?

  合久必分,分久必合的节奏?

 

  故事3:高配更慢?

  客户在原有64CPU、128内存的服务器进行升级变成128CPU、512内存,升级硬件也是软件厂商建议提高服务器配置,升级完成以后客户发现系统更慢了!这也可以?

  正常的情况添加硬件资源不会出现这样的情况,那么这个客户是为什么呢?找了服务器的厂商各种检测,各种报告分析,无法得知原因,最终换回原配置的服务器。

  这是为什么: 该软件厂商的程序基本是使用定制化模板,根据业务拼接,开发方便,但是后台语句条件复杂,语句庞大在数据量增大以后语句的执行变得很耗资源,也更依赖与CPU的并行,在没有设置并行度的情况下升级硬件(添加CPU),导致并行度过高,语句执行更慢。说白了就是简单的一个参数配置问题!

1.0的时代

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

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

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

  图片 1

 

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

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

优化阶段一(常规优化)

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

  简单的调研开始...

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

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

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

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

 

  预期:

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

  结果:

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

  

  优化前

  图片 2

 

  优化后

  图片 3

 

 

  优化前

  图片 4

  优化后

  图片 5

 

  

说说企业运维

  也许是崇洋媚外,接触过几家国外的软件公司他们的运维保障服务做的确实好,但价钱也确实高,反观国内的一些软件公司很多公司在开发阶段基本是赔钱赚吆喝,而运维保障费用才是收入的开始,但是运维保障的效果确实不怎么理想,当然如果你是大客户给得起钱,那自然驻场工程师多多,服务周到,解决不了的问题也要死磕到天亮。

  慢慢的国内协作运维服务已经热起来,专业的人干专业的事儿~也许这样的第三方运维引入可以解决上面的问题,一部分企业已经先行尝到了这种你好,我好,他也好的甜头。

  企业运维服务已经是这个样子了:

  企业服务市场,横向按客户规模分为大客户市场和中小客户市场,纵向目前最火的三大领域分别是大数据、云计算和运维服务市场,云再细分为SaaS、PaaS和IaaS,这样就构成了如下市场布局:

图片 6

  

  从运维服务产品角度来说,至少分为三层不同的能力,每一层都有各自不同的特点和要求:

  • 可视化统一管理能力:从统一信息采集、监控告警到可视化运维管理能力,这个是ITOM的基础能力,做到运维服务的统一管理和可视化;
  • 自动化运维服务能力:从运维自动化的统一控制、任务编排、网络业务开通和执行到自动化运维服务场景迭代,这是ITOM升级进化的必然之路,做到工具解放人力。
  • 场景化驱动业务能力:运维产品最终要为运维服务、要为业务服务,从敏捷开发到敏捷运维,实现工具优化业务,让运维更敏捷。

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

博客地址 

 

 欢迎转载请保留出处


 

分析

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

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

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

 

 奉上一幅草图

  图片 7

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

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

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

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

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

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

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

  下面我们来看看....

 

矛盾点

  用户不会配置专门的人干这样的事情,感觉都是厂商的问题,而厂商的人手技能也有限,很多软件厂商没有专业的数据库人员,又不一定能做这样的事情,最酷(苦)的就是运维人员、开发人员整天从早忙到晚连口水都喝不上,却被打上差评的标签。厂商在客户面前慢慢的失去了信服力,客户对于迟迟不能解决的问题更是很气愤,还想继续收运维费用?厂商有时也很无奈,很多时候又并不是软件的问题。

  矛盾  矛盾  矛盾

  扯皮  扯皮  扯皮

本文由杏彩发布,转载请注明来源

关键词: