系统慢得一批?看数据库运维老司机如何做优化
副标题[/!--empirenews.page--]
记得在自己学习数据库知识的时候特别喜欢看案例,因为优化的手段是容易掌握的,但是整体的优化思想是很难学会的。这也是为什么自己特别喜欢看案例,今天也分享自己做的优化案例。 之前分享过OA系统、HIS系统,今天我们来一个最常见的ERP。ERP系统各行各业都在用,不同行业也有不同的特点,博主在做研发的时候还自己写过ERP也算是比较熟悉了。 不管是本文分享的零售类,还是鞋服门店、家居、汽车、地产等等,也不管是某友、某碟,ERP有一个共同的特点,单据流程长,业务复杂,热点表明显,数据量大,涉及众多系统接口,各种大数据的统计报表....传统行业又缺乏DBA精心管理。 慢是普遍的! 最近一直很忙,博客产出也少的可怜,今天整理了一下自己做过优化或各种方案的客户已经超过千家,涉及各行各业,今天分享的案例算是在这些客户中比较典型的了,没有什么高大上都是常见的问题。在之前的博客中都有过提及,那么本篇我们就结合之前的技术点来看看这个案例。 用户现象 系统慢!非常慢! 保存个单据要好几分钟,很多操作都超时,尤其到下午4点左右各种超时,收款什么的都收不了,查个报表一个小时,下班了还没查完,经常因为系统慢而加班,业务部门怨声载道。这个事情已经上报公司高层,IT压力非常大! 系统环境 首先我们来看一下这个系统配置及现状,为什么说这个客户经典?往下看就知道了... 先来看看系统配置 : 服务器的配置是:8路 24 core 做了超线程,384个逻辑CPU,内存1T,磁盘全闪: SQL用了2012版本,补丁已经最新,而且服务器配置全部能够识别。 没错。相当牛逼的配置! 数据库的大小在1.2个T。 乍一看也许觉得是数据量太大了导致性能的问题,可又一想这么强力的服务器也不至于那么慢呀?难道是代码的问题?难道需要分库分表? 数据库指标 那么我们再看一下数据库的一些表象: 每秒请求数量: 用户连接数: 语句执行情况: 等待情况: 等待时间: CPU指标: 内存一些指标 磁盘队列: ----------------还很多指标就不一一展示了--------------- 看到这些基本的指标,除了慢你能看出什么?问题出在哪里?怎么样快速解决?能有一个优化的步骤呈现在眼前么? 分析 系统是真的很慢,慢语句数量很多系统阻塞也很严重,确实和客户反映的慢可以吻合。那为什么这么慢?什么原因导致的? 我总结一般性能慢常和6大因素有关:
奉上一幅草图: 系统压力:访问压力(也是我们常说的并发)其实并不大,用户连接数也没想像的那么多; 硬件:在内存和磁盘IO确实存在压力; 环境:服务器和数据库版本什么的没什么问题,具体配置一会儿再看; 代码:最不想分析代码,我们留到最后; 数据库内部运行因素:从各种指标来分析,系统语句等待时间太长,导致语句完成慢,而等待主要有两部分:
再分析...这么强的硬件,并不大的访问压力,竟然造成瓶颈?语句写的烂?程序实现的不好?缺索引?环境配置不对? 下面我们来看看.... 优化阶段一(常规优化) 很多时候系统慢要究其原因,难道上线时候就这么慢?那不可能,厂商根本无法交付的!那么问题来了,系统是什么时候开始慢的?对系统做过哪些调整? 简单的调研,出击! 我靠!!!厂商完全不配合,工程师对系统及其不熟悉,一问三不知,最近做什么改动也说不清,用户也不知道。厂商给的结论:继续加硬件,更强的IO,数据分离减小数据量…… 协调厂商完全协调不动,基本没戏了。 既然是数据库问题,那我们就数据库下手吧!从一名数据库从业人员的角度来说,看到这样的系统一定要先解决大面积等待问题。个人经验来看很多系统大面积等待解决系统会有个很大的提升和改善。 配合一些常规的调优手段,阶段一开始了。主要给系统大面积创建影响高开销大的索引,调整系统参数,优化tempDB等....具体不细说了,前面系列文章中都有。 预期: 一般系统上面一轮优化会有明显的改善,我认为这一轮以后系统会明显变快,语句运行环境合适,索引什么的合理资源消耗自然就少,内存和IO压力也会有所减少。 结果: 系统内存,IO压力趋于平稳,慢语句数量有所减少,但依然很多,阻塞依然存在,超过2分钟的语句依然很多。 优化前: 优化后 优化前 (编辑:西安站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |