Bokaro：blog.sina.com.cn/s/blog_493a84550102z8t2.html

那时chicourt销售业务控制系统操控性难题预测确诊和操控性强化各方面的文本。这首诗重点项目却是谈早已上架的销售业务控制系统先期再次出现操控性问题后的难题确诊和强化重点项目。

控制系统操控性难题预测业务流程

他们具体来说来预测下假如两个销售业务控制系统上架前没操控性难题，而在上架后再次出现了相当严重的操控性难题，所以事实上潜在性的情景主要就源自于下列两个各方面。

销售业务再次出现大mammalian的出访，引致再次出现操控性困局

上架后的控制系统资料库统计数据Lendelin，信息量减少后再次出现操控性困局

其他关键性自然环境发生改变，比如说他们常说的网络连接负面影响

便是虽然那个其原因，当他们辨认出操控性难题的这时候，具体来说就须要推论是N53SI241SV非mammalian状况下这类就有操控性难题，却是说在mammalian状况才存有操控性难题。对N53SI241SV操控性难题常常较为难试验和校正，对mammalian操控性难题他们能在试验自然环境展开冷却系统试验和校正，以推论mammalian下的操控性。

假如是N53SI241SV这类就存有操控性难题，所以大部分难题都出在计算机程序和SQL须要更进一步强化下面。假如是mammalian操控性难题，他们就须要更进一步预测资料库和开发工具这类的状况，看与否须要对开发工具展开操控性Listary。

在冷却系统试验过程中，他们还须要对CPU，内存和JVM展开监控，观察与否存有类似内存泄漏无法释放等情况，即mammalian下操控性难题这类也可能是代码这类其原因引致操控性异常。

操控性难题负面影响因素预测

对操控性难题负面影响因素，简单来说包括了硬件自然环境，软件运行自然环境和软件程序三个各方面的主要文本。下面分别再展开说明下。

硬件自然环境

硬件自然环境就是他们常说的计算，存储和网络资源。

对服务器的计算能力，一般来说厂家都会提供TPMC参数作为两个参考统计数据，但是他们实际看到相同TPMC能力下的X86服务器能力仍然低于小型机的能力。

除了服务器的计算能力参数，另外两个重点项目就是他们说的存储设备，负面影响到存储的重点项目又是IO读写操控性难题。有这时候他们监控辨认出CPU和内存居高不下，而真正的困局通过预测反而辨认出是虽然IO困局引致，虽然读写操控性跟不上，引致大量统计数据无法快速持久化并释放内存资源。

比如说在Linux自然环境下，这类也提供了操控性监控工具方便展开操控性预测。比如说常用的iostat,ps,sar,top,vmstat等，这些工具能对CPU，内存，JVM，磁盘IO等展开操控性监控和预测，以辨认出真正的操控性难题在哪里。

比如说他们常说的内存使用率持续告警，你就必须辨认出是高mammalian调用引致，却是JVM内存泄漏引致，却是这类虽然磁盘IO困局引致。

对CPU，内存，磁盘IO操控性监控和预测的两个思路能参考：

运行自然环境-资料库和应用开发工具

资料库和应用开发工具操控性Listary是另外两个经常再次出现操控性难题的地方。

资料库操控性Listary

拿Oracle资料库来说，负面影响资料库操控性的因素包括：控制系统、资料库、网络。资料库的强化包括：强化资料库磁盘I/O、强化回滚段、强化Rrdo日志、强化控制系统全局区、强化资料库对象。

要调整具体来说就须要对资料库操控性展开监控

他们能在init.ora参数文件中设置TIMED_STATISTICS=TRUE 和在你的会话层设置ALTER SESSION SET STATISTICS=TRUE 。运行svrmgrl 用 connect internal 注册，在你的应用控制系统正常活动期间，运行utlbstat.sql 开始统计控制系统活动，达到一定的时间后，执行utlestat.sql 停止统计。统计结果将产生在report.txt 文件中。

资料库操控性强化应该是两个持续性的工作，两个各方面是这类的操控性和参数巡检，另外两个各方面就是DBA也会经常提取最占用内存的低效SQL语句给开发人员更进一步预测，同时也会从资料库这类的下列告警KPI指标中发现难题。

比如说他们可能会辨认出Oracle资料库再次出现内存使用率高的告警，而通过检查会辨认出是产生了大量的Redo日志引致，所以他们就须要从程序上更进一步预测为何会产生如此多的回滚。

应用开发工具操控性预测和Listary

应用开发工具容器即他们常说的Weblogic, Tomcat等应用开发工具容器或Web容器。应用开发工具Listary两个各方面是这类的配置参数强化设置，两个各方面就是JVM内存启动参数Listary。

对应用开发工具这类的参数设置，主要包括了JVM启动参数设置，线程池设置，连接数的最小最大值设置等。假如是集群自然环境，还涉及到集群相关的配置Listary。

对JVM启动参数Listary，常常也是应用开发工具Listary的两个关键性点，但是一般JVM参数Listary会结合应用程序一起展开预测。

比如说他们常见的JVM堆内存溢出，假如计算机程序没内存泄漏难题的话，我就须要考虑调整JVM启动这时候堆内存设置。在32位操作控制系统下只能够设置到4G，但是在64位操作控制系统下早已能设置到8G甚至更大的值。

其中JVM启动的主要就控制参数说明如下:

-Xmx设置最大堆空间

-Xms设置最小堆空间

-XX:MaxNewSize设置最大新生代空间

-XX:NewSize设置最小新生代空间

-XX:MaxPermSize设置最大永久代空间(注：新内存模型早已替换为Metaspace)

-XX:PermSize设置最小永久代空间(注：新内存模型早已替换为Metaspace)

-Xss设置每个线程的堆栈大小

那么这些值究竟设置多大合适，具体来讲：

Java整个堆大小设置，Xmx 和 Xms设置为老年代存活对象的3-4倍，即FullGC之后的老年代内存占用的3-4倍。永久代 PermSize和MaxPermSize设置为老年代存活对象的1.2-1.5倍。

年轻代Xmn的设置为老年代存活对象的1-1.5倍。

老年代的内存大小设置为老年代存活对象的2-3倍。

注意在新的JVM内存模型下早已没PermSize而是变化为Metaspace，因此须要考虑Heap内存和Metaspace大小的配比，同时还须要考虑相关的垃圾回收机制是采用哪种类型等。

对JVM内存溢出难题，我前面写过一篇专门的预测文章能参考。

从表象到根源-两个软件控制系统JVM内存溢出难题预测解决全过程

软件程序操控性难题预测

在这里具体来说要强调的一点就是，当他们辨认出操控性难题后具体来说想到的就是扩展资源，但是绝大部分的操控性难题这类并不是资源能力不够引致，而是他们程序实现上再次出现明显缺陷。

比如说他们经常看到的大量循环创建连接，资源使用了不释放，SQL语句低效执行等。

为了解决这些操控性难题，最好的方法仍然是在事前控制。其中包括了事前的代码静态检查工具的使用，也包括了开发团队对代码展开的Code Review来辨认出操控性难题。

所有已知的难题都必须形成开发团队的开发规范要求，避免重复再犯。

销售业务控制系统操控性难题扩展思考

对销售业务控制系统的操控性强化，除了下面谈到的标准预测业务流程和预测要素外，再chicourt其他一些操控性难题引发的关键性思考。

上架前的操控性试验与否有用？

有这时候大家可能觉得奇怪，为何他们控制系统上架前都做了操控性试验，为何上架后却是会再次出现控制系统操控性难题。所以他们能考虑下事实上他们上架前操控性试验可能存有的一些无法真实模拟生产自然环境的地方，具体为：

硬件能否完全模拟真实自然环境？最好的操控性试验常常是直接在搭建完成的生产自然环境展开。

信息量能否模拟实际情景？真实情景常常是多个销售业务表都早已存有大信息量的积累而非空表。

mammalian能否模拟真实情景？两个是须要录制复合销售业务情景，两个是须要多台压测机。

而事实上他们在做操控性试验的这时候以上两个点都很难真正做到，因此要想完全模拟出生产真实自然环境是相当困难的，这也引致了很多操控性问题是在真正上架后才辨认出。

控制系统这类水平弹性扩展与否完全解决操控性难题？

第二个点也是他们经常谈的较为多的点，就是他们的销售业务控制系统在展开架构设计的这时候，特别是面对非功能性需求，他们都会谈到控制系统这类的资料库，中间件都采用了集群技术，能够做到弹性水平扩展。所以这种弹性水平扩展能力与否又真正解决了操控性难题？

事实上他们看到对资料库常常很难真正做到无限的弹性水平扩展，即使对Oracle RAC集群常常也是最多扩展到单点的2到3倍操控性。对应用集群常常能做到弹性水平扩展，当前技术也较为成熟。

当开发工具能够做到完全弹性扩展的这时候，事实上仍然可能存有操控性难题，即随着他们控制系统的运行和销售业务信息量的不断积累增值。事实上你能看到常常非mammalian状况下的N53SI241SV出访这类就很慢，而不是说mammalian上来后慢。因此也是他们常说的要给点，即：

单点出访操控性正常的这时候能扩展集群来应对大mammalian状况下的同时出访

单点出访这类操控性就有难题的这时候，要优先强化单节点出访操控性

销售业务控制系统操控性确诊的分类

对销售业务控制系统操控性确诊，假如从静态角度他们能考虑从下列三个各方面展开分类

操作控制系统和存储层面

开发工具层面（包括了资料库，应用服务器开发工具）

软件层面（包括了资料库SQL和存储过程，逻辑层，前端展现层等）

所以两个销售业务控制系统应用功能再次出现难题了，他们当然也能从动态层面来看实际两个应用请求从调用开始究竟经过了哪些代码和硬件基础设施，通过分段方法来定位和查询难题。

比如说他们常见的就是两个查询功能假如再次出现难题了，具体来说就是找到那个查询功能对应的SQL语句在后台查询与否很慢，假如那个SQL这类就慢，所以就要强化强化SQL语句。假如SQL这类快但是查询慢，那就要看下与否是前端操控性问题或者集群难题等。

软件代码的难题常常是最不能忽视的两个操控性难题点

对销售业务控制系统操控性难题，他们经常想到的就是要扩展资料库的硬件操控性，比如说扩展CPU和内存，扩展集群，但是事实上能看到很多应用的操控性难题并不是硬件操控性引致的，而是虽然软件代码操控性引起的。对软件代码常见的操控性难题我在以往的博客文章里面也谈过到，较为典型的包括了。

循环中初始化大的结构对象，资料库连接等

资源不释放引致的内存泄露等

没基于情景需求来适度通过缓存等方式提升操控性

长周期事务处理耗费资源

处理某两个销售业务情景或难题的这时候，没选择最优的统计数据结构或算法

以上都是常见的一些软件代码操控性难题点，而这些常常须要通过他们展开Code Review或代码评审的方式才能够辨认出出来。因此假如要做全面的操控性强化，对软件代码的操控性难题排查是必须的。

通过IT资源监控或APM应用工具来辨认出操控性难题

对操控性难题的辨认出一般有两条路径，两个就是通过他们IT资源的监控，APM的操控性监控和预警来提前辨认出操控性难题，两个是通过销售业务用户在使用过程中的反馈来辨认出操控性难题。

APM应用操控性管理主要就指对企业的关键性销售业务应用展开监测、强化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)。

资源池-》应用层-》销售业务层

那个能理解为APM的两个关键性点，原有的网管类监控软件更多的是资源和操作控制系统层面，包括计算和存储资源的使用和利用率情况，网络这类的操控性情况等。但是当要预测所有的资源层难题如何对应到具体的应用，对应到具体的销售业务功能的这时候很难。

传统模式下，当再次出现CPU或内存满负荷的这时候，假如要查找到具体是哪个应用，哪个进程或者具体哪个销售业务功能，哪个sql语句引致的常常并不是难的事情。在实际的操控性难题强化中常常也须要做大量的日志预测和难题定位，最终才可能找到难题点。

比如说在他们最近的项目实施中，结合APM和服务链监控，他们能快速的辨认出究竟是哪个服务调用再次出现了操控性难题，或者快速的定位出哪个SQL语句有校正的操控性难题。那个都能帮助他们快速的展开操控性难题预测和确诊。

资源上承载的是应用，应用这类又包括了资料库和应用开发工具容器，同时也包括了前端；在应用之上则是对应到具体的销售业务功能。因此APM两个核心就是要将资源-》应用-》功能之间展开整合预测和衔接。

而随着DevOps和自动化运维的思路推进，他们更加希望是通过APM等工具主动监控来辨认出操控性难题，对APM工具最大的好处就是能展开服务全链路的操控性预测，方便他们辨认出操控性难题究竟发生在哪里。比如说他们提交两个表单很慢，通过APM预测他们很难辨认出究竟是调用哪个销售业务服务慢，或者是处理哪个SQL语句慢。这样能极大的提升他们操控性难题预测确诊的效率。

往期推荐

Dubbo服务调用隔离这么玩对么

学习资料领取学习视频

如有收获，点个在看，诚挚感谢