业务系统性能问题分析和诊断

我们首先来分析下如果一个业务系统上线前没有性能问题，而在上线后出现了比较严重的性能问题，那么实际上潜在的场景主要来自于以下几个方面。

• 业务出现大并发的访问，导致出现性能瓶颈

• 上线后的系统数据库数据日积月累，数据量增加后出现性能瓶颈

• 其它关键环境改变，比如我们常说的网络带宽影响

正是由于这个原因，当我们发现性能问题的时候，首先就需要判断是单用户非并发状态下本身就有性能问题，还是说在并发状态才存在性能问题。对于单用户性能问题往往比较容易测试和验证，对于并发性能问题我们可以在测试环境进行加压测试和验证，以判断并发下的性能。

如果是单用户本身就存在性能问题，那么大部分问题都出在程序代码和SQL需要进一步优化上面。如果是并发性能问题，我们就需要进一步分析数据库和中间件本身的状态，看是否需要对中间件进行性能调优。

在加压测试过程中，我们还需要对CPU，内存和JVM进行监控，观察是否存在类似内存泄漏无法释放等情况，即并发下性能问题本身也可能是代码本身原因导致性能异常。

性能问题影响因素分析

比如在Linux环境下，本身也提供了性能监控工具方便进行性能分析。比如常用的iostat,ps,sar,top,vmstat等，这些工具可以对CPU，内存，JVM，磁盘IO等进行性能监控和分析，以发现真正的性能问题在哪里。

比如我们常说的内存使用率持续告警，你就必须发现是高并发调用导致，还是JVM内存泄漏导致，还是本身由于磁盘IO瓶颈导致。

对于CPU，内存，磁盘IO性能监控和分析的一个思路可以参考：

要调整首先就需要对数据库性能进行监控

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

数据库性能优化应该是一个持续性的工作，一个方面是本身的性能和参数巡检，另外一个方面就是DBA也会经常提取最占用内存的低效SQL语句给开发人员进一步分析，同时也会从数据库本身的以下告警KPI指标中发现问题。

比如我们可能会发现Oracle数据库出现内存使用率高的告警，而通过检查会发现是产生了大量的Redo日志导致，那么我们就需要从程序上进一步分析为何会产生如此多的回滚。

应用中间件性能分析和调优

应用中间件容器即我们常说的Weblogic, Tomcat等应用中间件容器或Web容器。应用中间件调优一个方面是本身的配置参数优化设置，一个方面就是JVM内存启动参数调优。

对于应用中间件本身的参数设置，主要包括了JVM启动参数设置，线程池设置，连接数的最小最大值设置等。如果是集群环境，还涉及到集群相关的配置调优。

对于JVM启动参数调优，往往也是应用中间件调优的一个关键点，但是一般JVM参数调优会结合应用程序一起进行分析。

 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内存溢出问题分析解决全过程

对于性能问题的发现一般有两条路径，一个就是通过我们IT资源的监控，APM的性能监控和预警来提前发现性能问题，一个是通过业务用户在使用过程中的反馈来发现性能问题。

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

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

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

传统模式下，当出现CPU或内存满负荷的时候，如果要查找到具体是哪个应用，哪个进程或者具体哪个业务功能，哪个sql语句导致的往往并不是容易的事情。在实际的性能问题优化中往往也需要做大量的日志分析和问题定位，最终才可能找到问题点。

比如在我们最近的项目实施中，结合APM和服务链监控，我们可以快速的发现究竟是哪个服务调用出现了性能问题，或者快速的定位出哪个SQL语句有验证的性能问题。这个都可以帮助我们快速的进行性能问题分析和诊断。

资源上承载的是应用，应用本身又包括了数据库和应用中间件容器，同时也包括了前端；在应用之上则是对应到具体的业务功能。因此APM一个核心就是要将资源-》应用-》功能之间进行整合分析和衔接。

而随着DevOps和自动化运维的思路推进，我们更加希望是通过APM等工具主动监控来发现性能问题，对于APM工具最大的好处就是可以进行服务全链路的性能分析，方便我们发现性能问题究竟发生在哪里。比如我们提交一个表单很慢，通过APM分析我们很容易发现究竟是调用哪个业务服务慢，或者是处理哪个SQL语句慢。这样可以极大的提升我们性能问题分析诊断的效率。

有用！分享+在看/strong>

来源：BUG弄潮儿