系统环境

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

  

  先来看看系统配置 :

  

  图片 1

 

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

   图片 2

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

    没错。相当牛逼得配置!

  

     图片 3

  

  数据库的大小在1.2个T

 

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

系统环境

  首先我们来看一下这个系统配置及现状,为什么说这个客户经典?那就是因为这个客户已经达到可以慢的地方都慢,不该慢的地方也慢!

  首先这是一套医院的HIS系统,慢到什么程度呢?各种功能卡死不管是交款、医嘱、开药一些列几乎所有的功能都慢。但是卡慢的现象只出现在上午的高峰期!

  先来看看系统配置 :

  图片 4

  图片 5

   图片 6

 

  数据库版本是SQL SERVER 2008R2,数据量大概1个多T,服务器64CPU
、128G内存,服务器只运行数据库。

  咋一看服务器确实有点老了,数据量也大了,内存和CPU什么的明显不够用了!

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

优化阶段三(深入指标分析)

  经过前两个阶段的优化一般系都会明显好转,并且指标正常,这也是前面提到的可以慢的地方慢已经解决,那么为什么CPU、内存压力没有缓解?难道真的是64CPU、128G内存不能支持了?需要加内存换CPU?难道要做负载均衡?各种拆分?

分析

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

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

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

 

 奉上一幅草图

  图片 7

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

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

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

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

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

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

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

  下面我们来看看….

 

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

数据库指标

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

  每秒请求数量:

  图片 8

  语句执行情况:

  图片 9

  等待情况:

  图片 10

  等待时间:

  图片 11

   CPU指标:

  图片 12

  内存一些指标:

  图片 13

  磁盘队列:

  图片 14

 

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

 

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

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

优化阶段二(针对语句)

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

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

  再次对系统调研:

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

  

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

   

  一:报表

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

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

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

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

  千万级别….

  

  二:接口

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

 

  三:问题代码

  代码的问题主要有两个:

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

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

  图片 15

 

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

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

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

  

  

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

————–博客地址—————————————————————————————

Expert 诊断优化系列 

 

 

废话不多说,直接开整—————————————————————————————–

 

系统环境

  首先我们来看一下这个系统配置及现状,为什么说这个客户经典?那就是因为这个客户已经达到可以慢的地方都慢,不该慢的地方也慢!

  首先这是一套医院的HIS系统,慢到什么程度呢?各种功能卡死不管是交款、医嘱、开药一些列几乎所有的功能都慢。但是卡慢的现象只出现在上午的高峰期!

  先来看看系统配置 :

  图片 16

  图片 17

   图片 18

 

  数据库版本是SQL SERVER 2008R2,数据量大概1个多T,服务器64CPU
、128G内存,服务器只运行数据库。

  咋一看服务器确实有点老了,数据量也大了,内存和CPU什么的明显不够用了!

内存分析

  看到了CPU的现象那么内存的问题也有眉目了,这么多编译即席查询,首先看一下内存中缓存了那些数据:

  图片 19

 

  SQLOPTIMIZER
Singlepage占到了80多个G,而在查询数据页的缓存只有20个G,而且仍然在被不断压缩,那么内存没压力就怪了!这个SQLOPTIMIZER
Singlepage尝试了一下是无法通过DBCC
FREExxxxx的操作释放的,所以在半夜直接重启了SQL
服务!将近2年没有重启的SQL服务就这么折在我的手里了!

   重启后页生命周期:

  图片 20

  

  内存这个问题,不知道是不是微软的一个小BUG,查询计划的缓存个人理解不会一直压榨数据缓存的,客户的数据库没有补丁,但是查阅08的各个补丁也没有找到相关问题的修复。

  也请遇到过或了解的朋友给点提示!

 

  预期:

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

  结果:

  系统快起来了!

 

 

 

  总结 :
文章只是简单的描述了一下某医院HIS系统的优化过程,当然一周的工作仅仅通过一篇文章写出全过程细节必然不那么详尽,还望看官们见谅!

      整个的优化过程是程序只修改了2条语句,其他都是通过数据库优化手段完成。而且没有添加任何硬件资源!

优化过程主要分为:

  1. 系统整体调研
    :和科室用户沟通慢的情况,系统最近变更情况,并收集数据。
  2. 常规优化 : 调整数据库参数配置,添加索引,解决阻塞。
  3. 再次调研:系统慢功能,慢语句。
  4. 针对语句优化:写法不足,是否缺失索引,是否能加提示、计划向导等
  5. 整体压力是否缓解:如果仍然压力很大找到瓶颈,是否可以解决?如果不能解决才考虑添加硬件或选用分离、分离等方案。

 

 文章用用到的 Expert FOR SQLSERVER
工具下载链接:
**

 —————————————————————————————————-

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

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注