zoukankan      html  css  js  c++  java
  • 2011年2月2011年7月数据库性能优化过程

    开始暴露问题
        2011年2月下旬的一天早上,昨天更新的系统,早上发现数据库的服务器CPU达到100%,而且持续的时间很长,不得回到昨天更新前的版本,但系统还是有较长时间达到100%的情况,问题没有解决,从这正式开始优化线上数据库性能。
     
    第一阶段优化
       分析问题:
        一开始老是想找出问题的原因,找了3天还没有头绪,列出以下原因:
       1,JOB的耗时存储过程  --太频繁,执行时间长,1,2分钟
       2,频繁执行同样的SQL  --如查询用户表sys_user 几分钟内执行数千次
       3,tempdb太小
       4,运行SQL太慢
       5,数据库阻塞
         但这些原因,都找不出具体的在那块有问题,好像都有,又好像都没有,时间在一天天过去,但是系统还是100%经常发生,严重影响业务使用,这时只能按照以前的优化经验调整优化思路,不找原因,只要是问题就优化,一个一个处理,最终解决系统性能问题:
     主要是执行优化方法:
      1,删除全部的主键聚集索引,改成唯一非聚集索引
      2,删除重建全部索引
      3,删除全部外键约束
      4,持续优化SQL
      5,使用行版本隔离级别
      6,根据SQL建立索引
      7,安装SQL 2008 SP2补丁

      8,禁止读取大量数据未分页的SQL,读出数据必须分页50条。

    第二阶段优化
      经过一个多月的优化,比以前稳定一些,但系统100%的情况还有发生,这时分析下来,可能存在一些原因:
       1,高并发
       2,严重系统缺陷
       3,死锁
       4,缓存问题
       5,循环调用SQL
       6,长事务
       7,未优化的SQL
      为跟踪以上出现的SQL,发现以前用的DMVS性能分析视图远远不够,必须使用SQL Profile等其他工具,这期间的确进步很大
       1,使用SQL Profile监控工具监控高耗CPU的SQL
       2,发现长事务,并优化程序和SQL缺陷
       3,发现SQL事务中的执行语句停顿问题
       4,跟踪引起死锁SQL,并分析死锁原因和优化
       5,使用windows的性能工具分析CPU,Reads发现系统问题
       6,使用SSRS和windows的性能工具每天发送CPU跟踪报表。
       

     第三阶段优化
        经过一,二阶段优化,系统100%比以前的少了很多,但有一天,看SSRS的CPU报表,突然CPU暴涨到100%,而且第二天还有,通过Profile发现是因为缓存更新的原因,由于后台修改数据会触发缓存更新,一旦后台大量更新数据时,前台就会更新大量缓存,这样一来就要很多个SQL请求,CPU就会暴涨到100%,后来修改了程序缓存策略,该问题解决。

        经过这三轮的优化,系统的性能比以前有了明显的改善,系统100%的情况极少。经过这几个月优化,彻底发现以前的知识和经验不足,并一度怀疑自己的能力,为何以前优化系统,1,2个月就大概全部搞定,这次花了这么长时间,可能情况不一样,系统的复杂程度也不一样吧!

      2011年3月3日CPU的趋势图

     

      2011年5月3日CPU的趋势图

     

        2011年7月7日CPU的趋势图

      
  • 相关阅读:
    字在线中
    关于页面显示层叠问题
    左边竖条
    jquery 动态添加元素事件绑定问题
    工作总结
    多文本输入,内容过多时输入框会自动撑开
    lunix常用命令
    springboot整合es availableProcessors is already set to [2], rejecting [2]
    mysql 主从复制架构
    elastic search 第一次安装 报错记录
  • 原文地址:https://www.cnblogs.com/zping/p/2320806.html
Copyright © 2011-2022 走看看