今天聊聊业务系统性能问题的分析诊断和性能优化。本文的重点是谈谈已经上线的业务系统后续出现性能问题后的问题诊断和优化的要点。系统性能问题分析流程我们先来分析一下,如果一个业务系统在上线前没有性能问题,但是上线后出现了严重的性能问题,潜在的场景主要来自以下几个方面。业务并发访问量大,导致性能瓶颈。系统数据库数据上线后会随着时间积累,数据量增大后会出现性能瓶颈。其他关键的环境变化,比如我们常说的网络带宽的影响,都是由于这个原因造成的。当我们发现性能问题时,首先要判断是在单用户非并发状态下出现性能问题,还是在并发状态下出现性能问题。对于单用户性能问题,往往更容易测试和验证。对于并发性能问题,我们可以在测试环境中进行压力测试和验证,判断并发下的性能。如果单个用户本身存在性能问题,那么大部分问题出在需要进一步优化的程序代码和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,在你的session层中设置ALTERSESSIONSETSTATISTICS=TRUE。运行svrmgrl以注册内部连接。在您的应用程序系统正常活动期间,运行utlbstat.sql以开始统计系统活动。一定时间后,执行utlestat.sql停止计数。统计结果会生成在report.txt文件中。数据库性能优化应该是一项持续的工作。一方面是自身的性能和参数检查。另一个方面是,DBA往往会提取最耗内存的低效SQL语句,供开发人员进一步分析。在以下告警KPI指标中发现问题。比如我们可能发现Oracle数据库出现了内存占用高的告警,通过检查会发现是大量的Redolog导致的,那么我们就需要进一步分析为什么会产生这么多的rollbacks程序。应用中间件性能分析与调优应用中间件容器就是我们常说的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#Set每个线程的堆栈大小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内存溢出的问题,之前写了一篇专门的分析文章供参考。软件程序性能问题分析这里首先要强调的是,当我们发现性能问题时,首先想到的是扩展资源,但大多数性能问题本身并不是因为资源能力不足造成的,而是存在明显的缺陷我们的方案实施。比如我们经常看到大量循环创建连接,资源用完不释放,SQL语句执行效率低下。要解决这些性能问题,最好的办法还是提前控制。这包括使用预代码静态检查工具,以及开发团队对代码的CodeReview来发现性能问题。所有已知问题必须形成开发团队的开发规范要求,避免重复。对业务系统性能问题的延伸思考对于业务系统的性能优化,除了上面提到的标准分析流程和分析要素外,再说说性能问题引起的其他一些重点考虑。上线前的性能测试有用吗?有时您可能会疑惑,为什么我们的系统在上线前都经过了测试,为什么上线后仍然存在系统性能问题。那么我们在上线前的性能测试中可以考虑一些可能无法真实模拟生产环境的地方,具体来说:硬件能否完全模拟真实环境?最好的性能测试往往直接在已经搭建好的生产环境中进行。数据量能否模拟实际场景?真实场景往往是多个业务表堆积了大量数据,而不是空表。并发能否模拟真实场景?一是需要记录复合业务场景,二是需要多台压测机。事实上,我们在做性能测试的时候,很难真正做到以上几点,所以要完全模拟真实的生产环境是相当困难的,这也导致了很多性能问题是在实际上线之后才发现的。系统本身的水平弹性扩展是否彻底解决了性能问题?第二点也是我们经常讲的很多的一点,就是我们在设计我们业务系统的架构的时候,尤其是面对非功能性的需求,我们会讲到系统本身的数据库,以及中间件采用集群技术,可以实现弹性水平扩展。那么这种弹性水平扩展能力真的能解决性能问题吗?事实上,我们已经看到,要真正实现数据库的无限弹性水平扩展,往往是很难的。即使是OracleRAC集群,也往往能扩展到单点性能的2~3倍。对于应用集群,往往可以实现弹性水平扩展,目前技术已经比较成熟。当中间件可以实现完全弹性扩展的时候,可能还会存在性能问题,就是随着我们系统的运行和业务数据的不断积累,增值。其实大家可以看到非并发状态下的单用户访问本身就很慢,并不是并发上来就慢了。因此,也就是我们常说的,即在单点访问性能正常的情况下,可以扩展集群来应对大并发状态下单点访问的同时访问。系统性能诊断的分类对于业务系统性能诊断,从静态的角度,我们可以从以下三个方面来考虑分类操作系统和存储层中间件层(包括数据库、应用服务器中间件)软件层(包括数据库SQL和存储过程、逻辑层、前端表现层等)那么一个业务系统的应用功能就出现了问题。当然,我们也可以看看一个实际的应用请求从调用到动态层所经过的代码和硬件基础设施。分段方法定位查询问题。比如我们经常看到的是,如果某个查询函数出现问题,首先要找的是这个查询函数对应的SQL语句在后台查询是不是很慢。如果SQL本身很慢,那么就需要对SQL语句进行优化。如果SQL本身很快但是查询很慢,那要看是前端性能问题还是集群问题。软件代码的问题往往是最不容忽视的性能问题。对于业务系统性能问题,我们往往想到的是扩展数据库的硬件性能,比如扩展CPU和内存,扩展集群。但实际上,我们可以看到很多应用。性能问题不是由硬件性能引起的,而是由软件代码性能引起的。我在之前的博文中也谈到了软件代码常见的性能问题,典型的都包含在内。大结构对象在循环中初始化,数据库连接等资源未释放导致的内存泄漏等未根据场景需求通过缓存等方式进行适当改善。长时间的事务处理会消耗资源。在处理某个业务场景或问题时,别无选择优秀的数据结构或算法以上是一些常见的软件代码性能问题,而这些往往需要通过我们的CodeReview或codereview来发现。因此,要想做全面的性能优化,就必须排查软件代码的性能问题。通过IT资源监控或APM应用工具发现性能问题发现性能问题一般有两种途径。一种是通过我们IT资源的监控,APM性能监控和预警,提前发现性能问题,另一种是通过业务用户在使用过程中的反馈来识别性能问题。APM应用性能管理主要是指对企业关键业务应用进行监控和优化,提高企业应用的可靠性和质量,确保用户得到良好的服务,降低IT总拥有成本(TCO)。-APM核心-资源池-》应用层-》业务层这个可以理解为APM的一个重点。原来的网管监控软件更多的是资源和操作系统层面,包括计算和存储资源的使用和利用率。速率,网络本身的性能等。但是,很难分析所有资源层问题如何对应于特定应用程序和特定业务功能。在传统模式下,当CPU或内存满载时,往往不容易找出是哪个应用程序、哪个进程或具体的业务功能、哪条SQL语句导致了问题。在实际的性能问题优化中,往往需要做大量的日志分析和问题定位,才能最终找到问题点。比如我们在最近的项目实施中,结合APM和服务链监控,可以快速找出是哪个服务调用出现了性能问题,或者是快速定位到是哪个SQL语句出现了校验性能问题。这可以帮助我们快速分析和诊断性能问题。资源承载应用,应用本身包括数据库和应用中间件容器,还有前端;在应用之上,对应具体的业务功能。因此,APM的一个核心就是整合、分析和连接资源-“应用-”功能。随着DevOps和自动化运维的推进,我们希望通过APM等工具主动监控发现性能问题。APM工具最大的优势就是可以对服务的整个链路进行性能分析,这样我们就可以找出是什么性能问题。它发生的地方。比如我们提交一个表单就很慢。通过APM分析,我们可以很容易地找出是哪个业务服务调用慢,或者是哪个SQL语句处理慢。这样可以大大提高我们分析和诊断性能问题的效率。
