系统架构性能优化思路

这篇文章重点仍是谈已经上线的业务系统后续出现性能问题后的问题诊断和优化重点。

系统性能问题分析流程

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

/*
		1.业务出现大并发的访问，致使出现性能瓶颈

    2.上线后的系统数据库数据日积月累，数据量增长后出现性能瓶颈
    3.其它关键环境改变，好比咱们常说的网络带宽影响
*/

正是因为这个缘由，当咱们发现性能问题的时候，首先就须要判断是单用户非并发状态下自己就有性能问题，仍是说在并发状态才存在性能问题。对于单用户性能问题每每比较容易测试和验证，对于并发性能问题咱们能够在测试环境进行加压测试和验证，以判断并发下的性能。

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

在加压测试过程当中，咱们还须要对CPU，内存和JVM进行监控，观察是否存在相似内存泄漏没法释放等状况，即并发下性能问题自己也多是代码自己缘由致使性能异常。

性能问题影响因素分析

对于性能问题影响因素，简单来讲包括了硬件环境，软件运行环境和软件程序三个方面的主要内容。下面分别再展开说明下。

硬件环境

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

对于服务器的计算能力，通常来讲厂家都会提供TPMC参数做为一个参考数据，可是咱们实际看到相同TPMC能力下的X86服务器能力仍然低于小型机的能力。

除了服务器的计算能力参数，另一个重点就是咱们说的存储设备，影响到存储的重点又是IO读写性能问题。有时候咱们监控发现CPU和内存居高不下，而真正的瓶颈经过分析反而发现是因为IO瓶颈致使，因为读写性能跟不上，致使大量数据没法快速持久化并释放内存资源。

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

好比咱们常说的内存使用率持续告警，你就必须发现是高并发调用致使，仍是JVM内存泄漏致使，仍是自己因为磁盘IO瓶颈致使。

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

运行环境-数据库和应用中间件

数据库和应用中间件性能调优是另一个常常出现性能问题的地方。

数据库性能调优

拿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日志致使，那么咱们就须要从程序上进一步分析为什么会产生如此多的回滚。

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

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

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

对于JVM启动参数调优，每每也是应用中间件调优的一个关键点，可是通常JVM参数调优会结合应用程序一块儿进行分析。

好比咱们常见的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来发现性能问题。

全部已知的问题都必须造成开发团队的开发规范要求，避免重复再犯。

业务系统性能问题扩展思考

对于业务系统的性能优化，除了上面谈到的标准分析流程和分析要素外，再谈下其它一些性能问题引起的关键思考。

上线前的性能测试是否有用

有时候你们可能以为奇怪，为什么咱们系统上线前都作了性能测试，为什么上线后仍是会出现系统性能问题。那么咱们能够考虑下实际上咱们上线前性能测试可能存在的一些没法真实模拟生产环境的地方，具体为：

/*
		硬件可否彻底模拟真实环境？最好的性能测试每每是直接在搭建完成的生产环境进行。

    数据量可否模拟实际场景？真实场景每每是多个业务表都已经存在大数据量的积累而非空表。

    并发可否模拟真实场景？一个是须要录制复合业务场景，一个是须要多台压测机。
*/

而实际上咱们在作性能测试的时候以上几个点都很难真正作到，所以要想彻底模拟出生产真实环境是至关困难的，这也致使了不少性能问题是在真正上线后才发现。

系统自己水平弹性扩展是否彻底解决性能问题

第二个点也是咱们常常谈的比较多的点，就是咱们的业务系统在进行架构设计的时候，特别是面对非功能性需求，咱们都会谈到系统自己的数据库，中间件都采用了集群技术，可以作到弹性水平扩展。那么这种弹性水平扩展能力是否又真正解决了性能问题？

实际上咱们看到对于数据库每每很难真正作到无限的弹性水平扩展，即便对于Oracle RAC集群每每也是最多扩展到单点的2到3倍性能。对于应用集群每每能够作到弹性水平扩展，当前技术也比较成熟。

当中间件可以作到彻底弹性扩展的时候，实际上仍然可能存在性能问题，即随着咱们系统的运行和业务数据量的不断积累增值。实际上你能够看到每每非并发状态下的单用户访问自己就很慢，而不是说并发上来后慢。所以也是咱们常说的要给点，即：

/*
		单点访问性能正常的时候能够扩展集群来应对大并发状态下的同时访问

		单点访问自己性能就有问题的时候，要优先优化单节点访问性能
*/

业务系统性能诊断的分类

对于业务系统性能诊断，若是从静态角度咱们能够考虑从如下三个方面进行分类:

/*
		操做系统和存储层面
		中间件层面(包括了数据库,应用服务器中间件)
		软件层面(包括了数据库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语句慢。这样能够极大的提高咱们性能问题分析诊断的效率。

来源 https://4m.cn/rN8IB