1、性能调优的步骤
1.1、衡量系统现状
包括请求次数、响应时间、资源消耗等;如:A系统目前95%的请求响应为1s。
1.2、设定调优目标
根据用户所能接受的响应速度、系统现有的机器、所支撑的用户量制定出来的,因此通常会设定调优目标:95%的 请求在500ms内返回。
1.3、寻找性能瓶颈
在【2、寻找性能瓶颈】会专门介绍。通常性能瓶颈的表像是:
1.3.1、资源消耗过多(CPU、文件IO、网络IO、内存)
1.3.2、外部系统处理不足(所调用的其他系统提供的功能——多数情况也是资源消耗过多、数据的操作响应速度 不够——根据数据库SQL执行速度、数据库机器的IOPS、数据库的Active Sessions等分析出来的)
1.3.3、程序代码运行效率不够高,未充分使用资源或程序结构不合理。
1.4、性能调优
在后面的【3、性能调优】会专门介绍
1.5、衡量是否达到目标值
优化部署后,达到目标则结束,如果没有则重复1.3、1.4步骤
2、寻找性能瓶颈
2.1、CPU消耗分析(top、pidstat等方式查看cpu消耗状况;vmstat查看cpu的上下文切换、运行队列、利用率)
在Linux中,CPU消耗主要用于中断、内核以及用户进程的任务处理。优先级为:中断>内核>用户进程。cpu消耗
严重时,主要体现在:
①us—用户进程所占的%
过高的原因:1、线程一直处于可运行(Runnable)状态,通常线程在执行无阻塞、循环、正则或纯粹的计算
等动作引起的。
2、频繁的GC操作引起。如:每次请求需要分配较多内存,当访问量高的时,就不断的进行GC,
系统响应速度下降。进而造成堆积的请求更多,消耗内存更严重,最严重的时候可能导致系统 不断的进行FULL GC。可通过JVM内存的消耗分析来查找原因。
可通过kill -3 [javapid]、jstack [pid] | grep 'nid=0X....'的方式dump出应用的java线程信息。通过转换
出的十六进制的值就可以找到对应的nid值的线程。该线程即为消耗CPU的线程。在采样时多执行几次上诉过程,
以确保找到真实的消耗CPU的线程。也可以通过intel vtune这样的商业软件进行分析
②sy—内核线程所占的%
过高的原因:Linux花费更多的时间在进行线程切换。Java应用造成这个原因是:因为启动了的线程比较多,且
这些线程多数都处于不断的阻塞(锁等待、IO等待状态)和执行状态的变化过程,导致了操作系统需要不断的切换
执行的线程。从而产生大量的上下文切换。
可通过kill -3 [javapid]、jstack -1 [javapid]的方式dump出Java应用线程信息,查看线程的状态、锁信息,
找出等待状态或锁竞争过多的线程。结合vvmstat查看CPU消耗状况。如cs(上下文切换)、sy等。
③ni—被nice命令改变优先级的任务所占的%
④id—CPU空闲时间所占的%
⑤wa—执行过程中等待io所占的%
⑥hi—硬件中断所占的%
⑦si—软件中断所占的%
2.2、文件IO消耗分析(通过pidstat、iostat命令分析)
Java应用造成io消耗严重主要是:
① 多个线程需要大量内容写入(如频繁的log写入)动作;
② 磁盘设备本身的处理速度慢
③ 文件系统慢
④ 操作的文件本身已经很大
2.3、网络IO消耗分析(通过sar命令,如需跟着TCP/IP通信过程的信息,则可通过tcpdump来进行)
对于分布式Java应用而言,网络IO的消耗非常值得关注,尤其要注意网络中断是不是均衡地分配到各CPU的
(通过cat/proc/interrupts命令查看)。对于网卡只分配到一个CPU的现象采用修改kernle方法(Google使用)、 采用支持MSI-X的网卡进行修复。
由于没办法分析具体每个线程所消耗的网络IO,因此当网络IO消耗高时,对于Java应用而言只能对线程进dump。
查找产生大量网络IO操作的线程,这些线程的特征是读取或写入网络流,在Java网络通信时,通常要对对象进行序列
化为字节流,进行发送,或者读取。并反序列化为对象。这个过程要消耗JVM堆内存,JVM对内存通常是有限的。因此
Java应用一般不会造成网络IO消耗严重。
2.4、内存消耗分析(vmstat、sar、pidstat、top)
目前Java应用只有在创建线程和使用Direct ByteBuffer时才会操作JVM堆意外的内存。对于JVM堆以外的内存方
面消耗,最为值得关注的是swpd的消耗以及物理内存的消耗(可通过vmstat、sar、top、pidstat等方式查看swap
和物理内存的消耗状况)。
2.5、消耗资源不多,在访问量不大的情况。但程序执行慢的原因,主要有3方面
① 锁竞争激烈(如:数据库连接池数,但是请求数多于连接池数)
② 未充分使用硬件资源(如:多核CPU,但程序却采用单线程串行操作。)
③ 数据量增长(如:数据量的海量增长。可对数据库的表拆分、库拆分)
3、性能调优
3.1JVM调优
3.1.1、代大小调优
① 避免新生代大小设置过小
1、避免频繁进行minor GC;2、可能导致minor GC对象直接进入旧生代,占据旧生代空间,触发FULL GC。
② 避免新生代设置过大
1、导致旧生代变小,可能导致FULL GC频繁执行;2、导致minor GC的耗时大幅度增加。
③ 避免survivor space过小或者过大
④ 根据具体代码合理设置新生代的存活周期。
3.1.1、GC策略调优
串行GC性能太差,因此实际应用时主要是应用并行和并发GC,
大部分Web应用在处理请求时设置了一个最大可同时处理的请求数,当超出此请求数时,会将之后的请求放 入等待队列中,而这个等待队列也限制了大小。当等待队列满了后,仍然有请求进入,那么这些请求将丢弃,所
有的请求又都是有超时限制度。
在这种情况下如果触发了FULL GC造成应用暂停时间较长的FULL GC,则有可能等这次FULL GC之后,应
用中很多请求就超时或者被丢弃了。
从上面可以看出,Web应用非常需要一个对应用造成暂停时间较短的GC,再加上大部分Web应用的瓶颈都
不在CPU上。因此对于Web应用而言,在G1还不够成熟的情况下,CMS GC是不错的选择。
3.2、程序调优
3.2.1、CPU us高的解决方法
① 执行线程无任何挂起动作,且一直运行,导致CPU没有机会去调度执行其他的线程,造成线程饿死的现象。
解决:对这种线程的动作增加Thread.sleep(int),以释放CPU的执行权,降低CPU的消耗。
原理:以损失单次执行性能为代价,但由于降低了CPU消耗,在多线程的情况下,反而提高了平均性能。
② 状态扫描。如:某线程要等其他线程改变了值才可以继续执行。
解决:改为采用wait/notify机制。
③ 循环次数过多、正则、计算等造成CPU us过高的情况。结合业务需求进行调优。code review是王道。
④ 频繁GC造成us高的情况,通过JVM调优或程序调优,降低GC的执行次数。
3.2.2、CPU sy高的解决方法
① 线程运行状态经常切换
解决:减少线程数,且使用线程池
② 线程之间锁竞争激烈
解决:尽可能降低锁的竞争。
1、使用并发包中的类(java.util.concurrent.*)
2、使用Treiber算法
3、使用Michael-Scott非阻塞队列算法(ConcurrentLinkedQueue就是典型的该算法的非阻塞队列)
4、通常没必要对整个方法加锁,只对需要控制资源的地方做加锁操作。
5、拆分锁,把独占锁拆分为多把锁,如:ConcurrentHashMap。很大程度上可以提高读写速度。
6、去除读写操作的互斥锁
③ 较多网络IO操作或者确实需要一些锁竞争机制(如数据库连接池),但为了能够支持高的并发量,在Java
应用中又只能借助更多的线程来支撑。
解决:采用协程(Coroutine)来支持更高的并发量,避免并发量上涨之后造成CPU sy消耗严重、系统load
迅速上涨和系统性能下降。
Java中目前主要可用于实现协程的框架为Kilim,早使用Kilim执行一项任务,并不创建Thread,而是采用
Task。
3.3、文件IO消耗严重的解决方法
从程序角度看,造成文件IO消耗严重的原因主要是多个线程在写大量的数据到同一文件。导致文件很快变大。
从而写入速度越来越慢,并造成各线程激烈争抢文件锁,对于这种情况解决方法:
1、异步写入文件;2、批量读写;3、限流;4、限制文件大小;5、尽可能采用缓冲区等方式来读取文件内容
3.4、网络IO消耗严重的解决方法
从程序角度而言,造成网络IO消耗严重的主要原因是同时需要发送或接受的包太多。可采用限流。限流通常是
限制发送packet的频率,从而在网络IO消耗可接受的情况下来发送packet。
3.5、内存消耗严重的情况
1、对JVM调优;2、代码调优;
代码调优的方式:
① 释放不必要的引用。如使用ThreadLocal,由于线程复用,ThreadLocal中存放的对象如未主动释放的话,
不会被GC。应该在执行完毕执行ThreadLocal.set把对象清除,避免此有不必要的对象引用。
② 使用对象缓存池(享元模式)
③ 采用合理的缓存失效算法(FIFO、LRU、LFU等)
当缓存池达到最大容量后,如果再加入新对象时采用FIFO、LRU、LFU等失效算法。
④ 对于占据内存但又不是必须存在的对象使用SoftReference、WeakReference的方式进行缓存。
SoftReference在内存不够用的情况进行回收;WeakReference在FULL GC的情况下进行回收。
3.6、对于资源消耗不多,但程序执行慢的情况
3.6.1、锁竞争激烈—见3.2.2②
3.6.2、未充分利用硬件资源。
① 未充分利用CPU
启动多线程,但是单线程演变为多线程要加锁,如:单线程计算,拆分为多线程分别计算,最后合并结果 如:JDK7的fork-join框架。
② 未充分使用内存
数据库缓存、耗时资源缓存(数据库连接的创建、网络连接的创建等)、页面片段的缓存等。
结束语:从纯粹的软件角度调优来讲,充分而不过分的使用硬件资源,合理调整JVM以及合理使用JDK包是调优的三大有效原则,调优没有“银弹”。结合系统现状和多尝试不同的调优策略是找到合适调优方法的唯一途径。
以上参考淘宝网 架构师 林昊 著作《分布式JAVA应用 基础与实践》 一书
分享到:
相关推荐
性能测试诊断分析与优化 出版年: 2012-6 页数: 358 《性能测试诊断分析与优化》结合主流性能测试工具LoadRunner,讲解性能测试过程、方法和技术;结合笔者丰富的性能诊断调优经验,讲解如何有效分析和诊断性能问题、...
面向异构融合处理器的性能分析、优化及应用综述.pdf
淘宝前台系统性能分析与优化,包括前台系统优化,应用自身优化,以及其他优化
很高兴能有这样的机会,把我自己多年工作中对服务器硬件、软件方面的性能分析的经验和体会,以及性能优化的经验和各位朋友做一次分享。 这份ppt的内容组织大致是这样的,通过对系统中和性能相关的各个环节的介绍...
对于不断发展的Web应用,性能优化如同逆水行舟,不进则退。一般可以从前端和后端的优化来改善Web站点性能。本文侧重通过对前端性能的分析,为Web站点前端性能优化提供了理论依据和一般的优化策略,并讲述了一些用于B/S...
Intel软件工具介绍及应用性能分析,里边有关于性能优化的介绍。
Paratune机群应用性能分析软件(原Paraview机群应用性能分析软件) Paratune软件介绍: Paratune用于分析Paramon生成的.para应用运行特征文件,显示应用运行时各结点中处理器、内存、网络和磁盘的性能数据,重构...
第2篇为MATLAB高级算法应用设计,包括人脸检测识别、改进的多算子融合图像识别系统设计、罚函数的粒子群算法的函数寻优、车载自组织网络中路边性能及防碰撞算法研究、免疫算法的数值逼近优化分析、启发式算法的函数...
数据库优化包括:实例的性能优化和SQL语句的性能优化,实例优化和sql优化均可以通过AWR报告来分析并作出优化方案。 这篇文档描述了如何调查EBS系统性能下降原因、如何使用和理解AWR报告、分别阐述了数据库层/应用层/...
某微型电动汽车前悬架系统性能分析与优化研究 本文对某微型电动汽车前悬架系统进行性能分析和优化研究。该研究通过应用多体系统动力学和ADAMS/Car建立了悬架仿真模型,并对悬架性能进行了分析研究。在对悬架性能...
Android应用程序的性能优化分析与研究.pdf
基于线性脉动阵列的卷积神经网络计算优化与性能分析 本文主要讨论了基于线性脉动阵列的卷积神经网络(CNN)计算优化与性能分析的问题。CNN 是一种常用的深度学习算法,广泛应用于图像识别、自然语言处理、语音识别...
性能调优是一个系统工程:全面监控分析操作系统、I/O性能、内存、应用及数据库才能快速找到问题根源;深刻理解DB2的锁及并发机制、索引原理、数据库参数、优化器原理、SQL语句调优等内部机理才能针对性地快速提出...
Java企业应用性能优化分析.pptx
针对业务过程性能分析和优化多侧重于对已部署的业务过程进行事后的性能监控、管理和数据分析等问题,详细分析了业务过程性能和仿真优化的研究进展,提出了一种与企业模型和工作流模型相兼容的集成化业务过程仿真建模...
思科系统公司近日推出了思科网络应用性能分析(NAPA)解决方案,这一创新的网络管理产品和客户支持服务系列使IT管理人员可从整体角度了解网络资源和应用性能间的相互关系。思科NAPA解决方案是思科服务导向网络架构...
高并发Web应用系统的性能优化分析与研究.pdf 更多资源请点击:https://blog.csdn.net/weixin_44155966
第1篇 日常应用 第1章 安装和卸载 第2章 数据库管理 第3章 数据库实例管理 ... 第17章 常用性能监测、分析和优化工具 第18章 对SQL语句进行分析和优化 第19章 索引和提示优化 第20章 数据库分区技术