云顶娱乐平台 39

云顶娱乐平台:为什么我们用的系统这么烂?

2.0时代

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

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

  云顶娱乐平台 1

 

 

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

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

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

写在前面

  记得在自己学习数据库知识的时候特别喜欢看案例,因为优化的手段容易云顶娱乐平台:为什么我们用的系统这么烂?。掌握的,但是整体的优化思想很难学会的。这也是为什么自己特别喜欢看案例,今天也分享自己做的优化案例。

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

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

  慢是普遍的!

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

 

用户的问题

  在很多传统行业里,IT部门没有专门的DBA,或者所谓的DBA是这样一种角色:往往身兼数职(网管、项目管理、协调厂商、DBA、开发、应用、写报告),既有很多协调性的管理工作,又有一些专业技术工作。这其实和网上产品经理的段子很类似。

  其实也就是说用户没有管理好自己的数据库,很多时候数据库的一些运维配置都停留在软件厂商部署时候的配置,经过几年的业务和数据的积累这些配置可能早就不适用了。再说日常的体检,随着业务增长的长期规划….好吧,那就更是没有了!

  而且更糟的是,在日常的使用过程中对数据库还存在一些改造,比如毫无规划的添加数据表,一些周边功能的开发,其他方案的拼接。

  所以问题慢慢的积累慢慢的爆发。

  看到这有些看官自然会想,我们购买的软件,数据库不应该是软件厂商管的东西么?为什么我们要请DBA呢?

 

3.0的时代来了

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

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

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

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

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

  云顶娱乐平台 2

 

 

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

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

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

  

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

  云顶娱乐平台 3

  

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

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

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

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

  图示是语句

 

 

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

  语句实时查看

  云顶娱乐平台 4

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

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

 

  语句阻塞等待 实时分析

  云顶娱乐平台 5

  

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

  语句源头分析 

   云顶娱乐平台 6

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

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

  硬件与语句关联分析

  云顶娱乐平台 7

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

 

  硬件压力来源分析

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

  云顶娱乐平台 8

  

  这些语句是否可以优化?

  云顶娱乐平台 9

 

  

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

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

  云顶娱乐平台 10

 

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

 

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

   趋势分析

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

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

  云顶娱乐平台 11

 

  自动化巡检

  云顶娱乐平台 12

 

  其他功能

  云顶娱乐平台 13

 

 

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

博客地址 

 

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


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

 

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

Expert 诊断优化系列 

 

 

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

 

软件厂商的问题

  我几年的开发经历中就有过在软件厂商做运维的经历,那个时候真的是头大,天天电话不断今天这问题明天那问题:业务问题,数据不一致问题,功能修改,新功能上线,无聊的会议,客户突发奇想我还得跟着听听吹牛。我可以夸大点说当时在做开发没有转到DBA的时候,我的数据库技能可能是整个运维团队里最好的:基本的调优,索引的应用,一些系统视图的应用,指标的检测,听起来挺厉害了吧!

  所以我就是运维中的DBA了?

  现在回想起来,其实那个时候对数据库的了解根本没有成体系,对问题的分析也是比较片面的。解决问题也是东一锤子西一棒子,加个索引CPU指标降下来了,语句也快起来了,认为问题解决了,其实可能并没有。

  呵呵,但是!在运维的时候我一天天忙的狗一样,客户不反应问题,我肯定不会主动做优化做体检,客户反映问题了,简单看一看能推就推,客户急眼了,能安抚就安抚,迫不得以出手解决一下,长期积累的问题花了很长的时间,还很可能解决不了[苦笑][苦笑]。

  看到几个指标高,又解决不了,那么第一反应基本就是加硬件吧。

 

系统环境

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

  

  先来看看系统配置 :

  

  云顶娱乐平台 14

 

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

   云顶娱乐平台 15

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

    没错。相当牛逼得配置!

  

     云顶娱乐平台 16

  

  数据库的大小在1.2个T

 

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

开篇小故事

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

  故事1:升级硬件

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

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

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

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

  

  故事2:负载均衡

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

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

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

 

  故事3:高配更慢?

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

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

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

1.0的时代

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

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

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

  云顶娱乐平台 17

 

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

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

分析

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

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

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

 

 奉上一幅草图

  云顶娱乐平台 18

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

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

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

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

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

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

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

  下面我们来看看….

 

说说企业运维

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

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

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

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

云顶娱乐平台 19

  

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

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

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

博客地址 

 

 欢迎转载请保留出处


写在前面

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

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

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

优化阶段一(常规优化)

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

  简单的调研开始…

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

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

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

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

 

  预期:

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

  结果:

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

  

  优化前

  云顶娱乐平台 20

 

  优化后

  云顶娱乐平台 21

 

 

  优化前

  云顶娱乐平台 22

  优化后

  云顶娱乐平台 23

 

  

总结

  专业的人干专业的事儿~协作运维的时代已经来临!

  现在自己公司的SQL
Server的SaaS云平台也已经上线,一改传统的观念,跟着这波新的浪潮玩转企业运维,不断学习不断思考,不断的学习…

  充实自己 ~ 写在2016的最后一周~

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

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

 

优化阶段二(针对语句)

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

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

  再次对系统调研:

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

  

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

   

  一:报表

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

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

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

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

  千万级别….

  

  二:接口

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

 

  三:问题代码

  代码的问题主要有两个:

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

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

  云顶娱乐平台 24

 

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

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

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

  

  

矛盾点

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

  矛盾  矛盾  矛盾

  扯皮  扯皮  扯皮

要做到什么?

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

用户现象

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

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

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

这些问题你是否有?

云顶娱乐平台 25

  这样那样的问题到底是什么原因呢?谁又该来改善这样的现状呢?

 

再说点什么

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

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

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

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

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

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

 云顶娱乐平台 26

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

优化阶段三(报表分离)

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

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

  

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

  

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

  

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

 

  如何实现:  

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

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

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

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

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

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

 

  预期:

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

  结果:

  系统快起来了!

  

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

  云顶娱乐平台 27

 

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

Expert 诊断优化系列 

 

 


 

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

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

云顶娱乐平台, 

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

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

 

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

 

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

 

 

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

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

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

 云顶娱乐平台 26

 

数据库指标

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

  每秒请求数量:

  云顶娱乐平台 29

  用户连接数:

  云顶娱乐平台 30

 

 

  语句执行情况:

  云顶娱乐平台 31

  云顶娱乐平台 32

  

 

 

  等待情况:

  云顶娱乐平台 33

 

  云顶娱乐平台 22

 

  等待时间:

  云顶娱乐平台 35

 

   CPU指标:

  云顶娱乐平台 36

 

  内存一些指标:

  云顶娱乐平台 37

 

  云顶娱乐平台 38

 

 

  磁盘队列:

  云顶娱乐平台 39

 

 

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

 

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