百度权重3的网站值多少,公司网站建设应符合哪些法规,怎样用手机制作视频,dede如何生成网站源码1、JVM调优的核心关注指标
调优之前首先我们要知道怎样才算是“优”#xff0c;不能笼统的说我的程序性能很好#xff0c;所以就需要有一个具体的指标来衡量性能情况#xff0c;而在JVM里面衡量性能两个指标分别“吞吐量”和“停顿时间”。
吞吐量#xff1a;程序运行过程…1、JVM调优的核心关注指标
调优之前首先我们要知道怎样才算是“优”不能笼统的说我的程序性能很好所以就需要有一个具体的指标来衡量性能情况而在JVM里面衡量性能两个指标分别“吞吐量”和“停顿时间”。
吞吐量程序运行过程中执行两种任务分别是执行业务代码和进行垃圾回收吞吐量大意就是说程序运行业务代码的时间越多程序的吞吐量就越高其计算公式 吞吐量 CPU在用户应用程序运行的时间 / CPU在用户应用程序运行的时间 CPU垃圾回收的时间一般而言GC 的吞吐量不能低于 95%。停顿时间 因为JVM进行垃圾回收的时候某些阶段必须要停止业务线程专心进行垃圾收集停顿时间就是指JVM停止业务线程而去进行垃圾收集的这段时长停顿时间越长就意味着用户线程等待的时间越长停顿时间会直接影响用户使用系统的体验。垃圾回收频率通常来说垃圾回收频率是越低越好垃圾收集的过程是非常占用CPU资源的资源有限如果垃圾收集占用的资源越多那么意味着其他事情所用的资源会减少系统所能做的事情也会越少。当然也不能一味的追求GC次数减少GC次数减少了有可能就会使得单次GC的时间变长那么就可能会增加单次GC的“停顿时长”所以需要在这两者之间做一些平衡。
2、如果获得这些指标?
在项目启动的时候 增加下列参数来收集GC日志然后通过第三方的日志分析工具GCesay:https://gceasy.io/分析收集到的GC日志来得到吞吐量、停顿时间相关的统计数据。 java -XX:PrintGCDetails -XX:PrintGCDateStamps -XX:UseGCLogFileRotation -XX:PrintHeapAtGC -XX:NumberOfGCLogFiles5 -XX:GCLogFileSize20M -Xloggc:/opt/ard-user-gc-%t.log -jar abg-user-1.0-SNAPSHOT.jar -Xloggc:/opt/app/ard-user/ard-user-gc-%t.log 设置日志目录和日志名称-XX:UseGCLogFileRotation 开启滚动生成日志-XX:NumberOfGCLogFiles5 滚动GC日志文件数默认0不滚动-XX:GCLogFileSize20M GC文件滚动大小需开启UseGCLogFileRotation-XX:PrintGCDetails 开启记录GC日志详细信息包括GC类型、各个操作使用的时间,并且在程序运行结束打印出JVM的内存占用情况-XX: PrintGCDateStamps 记录系统的GC时间 -XX:PrintGCCause 产生GC的原因(默认开启)
3、确定调优的标准
JVM调优也没有万能的公式和标准因为每个人所面对的场景是不一样。要想调整到最优的性能其实首先要确认的是自己的需求目标是什么需要做的就是根据这个目标去慢慢的调整各项指标从而达到一个最佳的平衡点。
3.1 吞吐量和停顿时间的选择
调优前首先要确定大方向是选择基于吞吐量调优、还是停顿时间调优哪个是你的硬性指标这个硬性标准就是指导你进行调优的原则。
如果你的应用和用户没有什么交互完全不需要关注用户体验那么你的硬性标准就是不顾一切的提升吞吐量达到程序性能的最优。相反如果你的应用是频繁和用户进行交互的那么提升用户体验就是一个非常重要的指标了这个时候你的原则就是在用户能忍受卡顿时间(停顿时间)范围之内来调整指标来找到停顿时间和吞吐量的一个平衡值 。
举个不是很恰当但有助于你理解这个思路的例子 如果用户在点击一个功能之后500ms之内没有返回就会使用户焦虑那么500ms就是影响用户体验的一个标准了。如果你的业务代码执行到返回的时间需要运行的时间为400ms那么意味着垃圾回收的停顿的时间必须控制在100ms之内才对用户体验没有影响。 所以这个时候你的调优硬性标准就是把停顿时间控制在100ms之内然后在这个时间范围的基础上去调整JVM参数让吞吐量越高越好。 有了指导原则后我们就需要在这两个指标上进行平衡达到最优值了比如这个时候如果有两组指标第一组停顿时间为80ms吞吐量为92第二组停顿时间为98ms,吞吐量为98那么相对而言第二组指标是一个合适调优结果因为它即符合100ms停顿时间的原则又将吞吐量最大化了。 4、常用调优策略
4.1 选择合适的垃圾回收器
CPU单核那么毫无疑问Serial 垃圾收集器是你唯一的选择。CPU多核关注吞吐量 那么选择PSPO组合。CPU多核关注用户停顿时间JDK版本1.6或者1.7那么选择CMS。CPU多核关注用户停顿时间JDK1.8及以上JVM可用内存6G以上那么选择G1。
参数配置 //设置Serial垃圾收集器新生代开启-XX:UseSerialGC//设置PSPO,新生代使用功能Parallel Scavenge 老年代将会使用Parallel Old收集器开启 -XX:UseParallelOldGC//CMS垃圾收集器老年代开启 -XX:UseConcMarkSweepGC//设置G1垃圾收集器开启 -XX:UseG1GC
4.2 增加内存大小 现象垃圾收集频率非常频繁。原因如果内存太小就会导致频繁的需要进行垃圾收集才能释放出足够的空间来创建新的对象所以增加堆内存大小的效果是非常显而易见的。注意如果垃圾收集次数非常频繁但是每次能回收的对象非常少那么这个时候并非内存太小而可能是内存泄漏导致对象无法回收从而造成频繁GC。 参数配置 //设置堆初始值指令1-Xms2g指令2-XX:InitialHeapSize2048m//设置堆区最大值指令1-Xmx2g 指令2 -XX:MaxHeapSize2048m//新生代内存配置指令1-Xmn512m指令2-XX:MaxNewSize512m
4.3 设置符合预期的停顿时间 现象程序间接性的卡顿原因如果没有确切的停顿时间设定垃圾收集器以吞吐量为主那么垃圾收集时间就会不稳定。注意不要设置不切实际的停顿时间单次时间越短也意味着需要更多的GC次数才能回收完原有数量的垃圾. 参数配置 //GC停顿时间垃圾收集器会尝试用各种手段达到这个时间-XX:MaxGCPauseMillis
4.4 调整内存区域大小比率 现象某一个区域的GC频繁其他都正常。原因如果对应区域空间不足导致需要频繁GC来释放空间在JVM堆内存无法增加的情况下可以调整对应区域的大小比率。注意也许并非空间不足而是因为内存泄漏造成内存无法回收。从而导致GC频繁。 参数配置 // survivor区和Eden区大小比率指令-XX:SurvivorRatio6 //S区和Eden区占新生代比率为1:6,两个S区2:6// 新生代和老年代的占比-XX:NewRatio4 //表示新生代:老年代 1:4 即老年代占整个堆的4/5默认值2
4.5 调整对象升老年代的年龄 现象老年代频繁GC每次回收的对象很多。原因如果新升代年龄小新生代的对象很快就进入老年代了导致老年代对象变多而这些对象其实在随后的很短时间内就可以回收这时候可以调整对象的升级老年代的年龄让对象不那么容易进入老年代解决老年代空间不足频繁GC问题。注意增加了年龄之后这些对象在新生代的时间会变长可能导致新生代的GC频率增加并且频繁复制这些对象新生的GC时间也可能变长。 配置参数 // 进入老年代最小的GC年龄,年轻代对象转换为老年代对象最小年龄值默认值7-XX:InitialTenuringThreshol7
4.6 调整大对象的标准 现象老年代频繁GC每次回收的对象很多,而且单个对象的体积都比较大。原因如果大量的大对象直接分配到老年代导致老年代容易被填满而造成频繁GC可设置对象直接进入老年代的标准。注意这些大对象进入新生代后可能会使新生代的GC频率和时间增加。 配置参数 //新生代可容纳的最大对象,大于则直接会分配到老年代0代表没有限制。-XX:PretenureSizeThreshold1000000
4.7 调整GC的触发时机 现象CMSG1 经常 Full GC程序卡顿严重。原因G1和CMS 部分GC阶段是并发进行的业务线程和垃圾收集线程一起工作也就说明垃圾收集的过程中业务线程会生成新的对象所以在GC的时候需要预留一部分内存空间来容纳新产生的对象如果这个时候内存空间不足以容纳新产生的对象那么JVM就会停止并发收集暂停所有业务线程STW来保证垃圾收集的正常运行。这个时候可以调整GC触发的时机比如在老年代占用60%就触发GC这样就可以预留足够的空间来让业务线程创建的对象有足够的空间分配。注意提早触发GC会增加老年代GC的频率。 配置参数 //使用多少比例的老年代后开始CMS收集默认是68%如果频繁发生SerialOld卡顿应该调小-XX:CMSInitiatingOccupancyFraction//G1混合垃圾回收周期中要包括的旧区域设置占用率阈值。默认占用率为 65%-XX:G1MixedGCLiveThresholdPercent65
4.8 调整 JVM本地内存大小 现象GC的次数、时间和回收的对象都正常堆内存空间充足但是报OOM原因 JVM除了堆内存之外还有一块堆外内存这片内存也叫本地内存可是这块内存区域不足了并不会主动触发GC只有在堆内存区域触发的时候顺带会把本地内存回收了而一旦本地内存分配不足就会直接报OOM异常。注意 本地内存异常的时候除了上面的现象之外异常信息可能是OutOfMemoryErrorDirect buffer memory。 解决方式除了调整本地内存大小之外也可以在出现此异常时进行捕获手动触发GCSystem.gc()。 配置参数 XX:MaxDirectMemorySize
4.9 优化业务代码。
绝大部分的问题都出自于业务代码本身的问题在JVM调优里面也不例外要减少GC的频率 其实业务代码做一个很简单的优化就可以达到。
优化代码数据, 比如我们如果业务代码中减少非必要的对象、字段、属性对象变少体积变小可以减少GC次数和时间问题。提升方法的运行效率方法执行完后产生的对象就可以释放进行回收了方法运行时间越长那么这些对象呆在堆内存的时间就越久内存就越容易堆满GC的频率就会增加。避免内存泄漏, 还有由于业务代码的不合理导致的内存泄露长期无法回收这也是JVM最常见的问题。所以解决业务代码的问题有时候远比上面的参数调优要有效得多。
5、JVM调优场景案例
5.1 场景一网站流量浏览量暴增后网站反应页面响很慢。
1、问题推测在测试环境测速度比较快但是一到生产就变慢所以推测可能是因为垃圾收集导致的业务线程停顿。
2、定位为了确认推测的正确性在线上通过jstat -gc 指令 看到JVM进行GC 次数频率非常高GC所占用的时间非常长所以基本推断就是因为GC频率非常高所以导致业务线程经常停顿从而造成网页反应很慢。
3、解决方案因为网页访问量很高所以对象创建速度非常快导致堆内存容易填满从而频繁GC所以这里问题在于新生代内存太小所以这里可以增加JVM内存就行了所以初步从原来的2G内存增加到16G内存。
4、第二个问题增加内存后的确平常的请求比较快了但是又出现了另外一个问题就是不定期的会间断性的卡顿而且单次卡顿的时间要比之前要长很多。
5、问题推测联系到之前优化加大了内存所以推测可能是因为内存加大了从而导致单次GC的时间变长从而导致间接性的卡顿。
6、定位还是通过jstat -gc 指令 查看到 的确FGC次数并不是很高但是花费在FGC上的时间是非常高的,根据GC日志 查看到单次FGC的时间有达到几十秒的。
7、解决方案 因为JVM默认使用的是PSPO的组合PSPO垃圾标记和收集阶段都是STW所以内存加大了之后需要进行垃圾回收的时间就变长了所以这里要想避免单次GC时间过长所以需要更换并发类的收集器因为当前的JDK版本为1.7所以最后选择CMS垃圾收集器根据之前垃圾收集情况设置了一个预期的停顿的时间上线后网站再也没有了卡顿问题。
5.2 场景二后台导出数据引发的OOM
问题描述公司的后台系统偶发性的引发OOM异常堆内存溢出。
1、因为是偶发性的所以第一次简单的认为就是堆内存不足导致所以单方面的加大了堆内存从4G调整到8G。
2、但是问题依然没有解决只能从堆内存信息下手通过开启了-XX:HeapDumpOnOutOfMemoryError参数 获得堆内存的dump文件。
3、VisualVM 对 堆dump文件进行分析通过VisualVM查看到占用内存最大的对象是String对象本来想跟踪着String对象找到其引用的地方但dump文件太大跟踪进去的时候总是卡死而String对象占用比较多也比较正常最开始也没有认定就是这里的问题于是就从线程信息里面找突破点。
4、通过线程进行分析先找到了几个正在运行的业务线程然后逐一跟进业务线程看了下代码发现有个引起我注意的方法导出订单信息。
5、因为订单信息导出这个方法可能会有几万的数据量首先要从数据库里面查询出来订单信息然后把订单信息生成excel这个过程会产生大量的String对象。
6、为了验证自己的猜想于是准备登录后台去测试下结果在测试的过程中发现到处订单的按钮前端居然没有做点击后按钮置灰交互事件结果按钮可以一直点因为导出订单数据本来就非常慢使用的人员可能发现点击后很久后页面都没反应结果就一直点结果就大量的请求进入到后台堆内存产生了大量的订单对象和EXCEL对象而且方法执行非常慢导致这一段时间内这些对象都无法被回收所以最终导致内存溢出。
7、知道了问题就容易解决了最终没有调整任何JVM参数只是在前端的导出订单按钮上加上了置灰状态等后端响应之后按钮才可以进行点击然后减少了查询订单信息的非必要字段来减少生成对象的体积然后问题就解决了。
5.3 场景三单个缓存数据过大导致的系统CPU飚高。
1、系统发布后发现CPU一直飚高到600%发现这个问题后首先要做的是定位到是哪个应用占用CPU高通过top 找到了对应的一个java应用占用CPU资源600%。
2、如果是应用的CPU飚高那么基本上可以定位可能是锁资源竞争或者是频繁GC造成的。
3、所以准备首先从GC的情况排查如果GC正常的话再从线程的角度排查首先使用jstat -gc PID 指令打印出GC的信息结果得到得到的GC 统计信息有明显的异常应用在运行了才几分钟的情况下GC的时间就占用了482秒那么问这很明显就是频繁GC导致的CPU飚高。
4、定位到了是GC的问题那么下一步就是找到频繁GC的原因了所以可以从两方面定位了可能是哪个地方频繁创建对象或者就是有内存泄露导致内存回收不掉。
5、根据这个思路决定把堆内存信息dump下来看一下使用jmap -dump 指令把堆内存信息dump下来堆内存空间大的慎用这个指令否则容易导致会影响应用因为我们的堆内存空间才2G所以也就没考虑这个问题了。
6、把堆内存信息dump下来后就使用visualVM进行离线分析了首先从占用内存最多的对象中查找结果排名第三看到一个业务VO占用堆内存约10%的空间很明显这个对象是有问题的。
7、通过业务对象找到了对应的业务代码通过代码的分析找到了一个可疑之处这个业务对象是查看新闻资讯信息生成的对象由于想提升查询的效率所以把新闻资讯保存到了redis缓存里面每次调用资讯接口都是从缓存里面获取。
8、把新闻保存到redis缓存里面这个方式是没有问题的有问题的是新闻的50000多条数据都是保存在一个key里面这样就导致每次调用查询新闻接口都会从redis里面把50000多条数据都拿出来再做筛选分页拿出10条返回给前端。50000多条数据也就意味着会产生50000多个对象每个对象280个字节左右50000个对象就有13.3M这就意味着只要查看一次新闻信息就会产生至少13.3M的对象那么并发请求量只要到10那么每秒钟都会产生133M的对象而这种大对象会被直接分配到老年代这样的话一个2G大小的老年代内存只需要几秒就会塞满从而触发GC。
9、知道了问题所在后那么就容易解决了问题是因为单个缓存过大造成的那么只需要把缓存减小就行了这里只需要把缓存以页的粒度进行缓存就行了每个key缓存10条作为返回给前端1页的数据这样的话每次查询新闻信息只会从缓存拿出10条数据就避免了此问题的 产生。
5.4 场景四CPU经常100% 问题定位思路。
问题分析CPU高一定是某个程序长期占用了CPU资源。
1、所以先需要找出那个进行占用CPU高。 top 列出系统各个进程的资源占用情况。
2、然后根据找到对应进行里哪个线程占用CPU高。 top -Hp 进程ID 列出对应进程里面的线程占用资源情况
3、找到对应线程ID后再打印出对应线程的堆栈信息 printf %x\n PID 把线程ID转换为16进制。jstack PID 打印出进程的所有线程信息从打印出来的线程信息中找到上一步转换为16进制的线程ID对应的线程信息。
4、最后根据线程的堆栈信息定位到具体业务方法,从代码逻辑中找到问题所在。 查看是否有线程长时间的watting 或blocked如果线程长期处于watting状态下 关注watting on xxxxxx说明线程在等待这把锁然后根据锁的地址找到持有锁的线程。
5.5 场景五内存飚高问题定位思路。
分析 内存飚高如果是发生在java进程上一般是因为创建了大量对象所导致持续飚高说明垃圾回收跟不上对象创建的速度或者内存泄漏导致对象无法回收。
1、观察垃圾回收的情况 jstat -gc PID 1000 查看GC次数时间等信息每隔一秒打印一次。jmap -histo PID | head -20 查看堆内存占用空间最大的前20个对象类型,可初步查看是哪个对象占用了内存。
如果每次GC次数频繁而且每次回收的内存空间也正常那说明是因为对象创建速度快导致内存一直占用很高如果每次回收的内存非常少那么很可能是因为内存泄露导致内存一直无法被回收。
2、导出堆内存文件快照 jmap -dump:live,formatb,file/home/myheapdump.hprof PID dump堆内存信息到文件。
3、使用visualVM对dump文件进行离线分析,找到占用内存高的对象再找到创建该对象的业务代码位置从代码和业务场景中定位具体问题。
